From oej@edvina.net Mon Feb 3 06:01:21 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F28E1A01D4 for ; Mon, 3 Feb 2014 06:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmGtIzDy-rzy for ; Mon, 3 Feb 2014 06:01:19 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 334801A01D7 for ; Mon, 3 Feb 2014 02:01:57 -0800 (PST) Received: from [192.168.40.68] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 7FEF493C2A2; Mon, 3 Feb 2014 10:01:56 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Feb 2014 11:01:55 +0100 Message-Id: <6033D22C-8EB7-405C-AD6A-56C64D44261A@edvina.net> To: DISPATCH Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [dispatch] SIP, TLS and oppurtunistic encryption X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 14:01:21 -0000 Hi! Paul Hoffman has written a document that defines "Oppurtunistic = Encryption" in regards to TLS and separates this from unauthenticated = sessions. It's a good read. (and discussed in the UTA wg) http://tools.ietf.org/html/draft-hoffman-uta-opportunistic-tls-00 This got my head busy with applying this to SIP.=20 In SIP we already have a kind of oppurtunistic encryption where the user = has not required a confidential session. If a service sets up NAPTR = records and SRV ONLY indicating and supporting TLS and _sips there's no = choice for a SIP implementation than to set up a TLS connection. The = user is not involved and a phone should propably not indicate a lock. = The first hop may or may not be TLS, if there is a proxy in the middle. If we follow the thinking in Paul's document and configure a SIP client = to always look for and try to use TLS by using DNS or simply trying a = connection to port 5061 before anything else, then we have oppurtunistic = encryption again. Regardless of SIP uri scheme and ;transport headers. Should the via headers signal TLS or TCP in this case? We use TLS for = authenticated and in some cases encrypted SIP signalling. The use of = "TLS" in the via adds requirements on authentication on the response = path back. Can a proxy add something to the Record-route header to = indicate that it supports TLS if the other end wants to use it - in = order to speed up the process? If we assume we should use "TCP" in the via - should we somehow record = that we actually used TLS? Like every other area in the IETF we need to focus on responding to the = attack on the Internet. Adding oppurtunistic encryption in our = applications seems like a good thing, but it should not cause unexpected = behaviour. /O= From pkyzivat@alum.mit.edu Tue Feb 4 08:27:49 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DB31A011C for ; Tue, 4 Feb 2014 08:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZvMSnZ_CFYz for ; Tue, 4 Feb 2014 08:27:48 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 4C6B11A0100 for ; Tue, 4 Feb 2014 08:27:48 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA11.westchester.pa.mail.comcast.net with comcast id NCGP1n0030QuhwU5BGTnKd; Tue, 04 Feb 2014 16:27:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id NGTl1n00M3ZTu2S3NGTnRg; Tue, 04 Feb 2014 16:27:47 +0000 Message-ID: <52F11501.8050106@alum.mit.edu> Date: Tue, 04 Feb 2014 11:27:45 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <526D51D1.3090106@alum.mit.edu> <03FBA798AC24E3498B74F47FD082A92F3D86D026@US70UWXCHMBA04.zam.alcatel-lucent.com> <526E8BF5.7080206@alum.mit.edu> In-Reply-To: <526E8BF5.7080206@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391531267; bh=pogUrmVTGb4BEucAHrJ7WcE2tcdu5nGto0EdXgJUNKI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=p4/rUW4e05p4Y2lJWwMHQVOHArldl3FaRvJAX09OPLsk6VRpFYLf0VcJEtbjPVbEM /42goLZJD3fmet+CVxPkaZq1AfW55RUlz2vP0QTcoQuXOY7z4SpaM2EaJZtxxiWmke 6qtDf3mlYWHJ5zR8T+XyazTGrUpyCjNFWluyyoHPMAfmPy7ovRiUPlPe8c3qZAm4Xj BEslAMKv0upDUdHXLJ/Uq65Ic3+h2iXfdXcFVwZH35zKwBGr1TQPwb1BdXonUVdaZ/ HrJLlFDw2C5TP2zMmTue+rnE+0mP9Mi7Z2xHSt+gzl3g9T9LiG7/c0+y1dcMmuVsjL 8Mkt/b7z8BrDg== Subject: Re: [dispatch] Comments on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:27:50 -0000 Richard, What is the status of this work? Are you planning on a new version? Also, these naming issues extend to draft-ietf-rtcweb-data-channel-06. Can I get your support in lobbying for naming changes there too? Thanks, Paul On 10/28/13 12:08 PM, Paul Kyzivat wrote: > On 10/28/13 11:07 AM, Ejzak, Richard P (Richard) wrote: >> Thanks, Paul. >> >> I agree that the WebRTC specific aspects need to be clearly separated >> from the core protocol aspects. I'll do that in the next version. > > Thanks! > >> I also agree that "WebRTC" is not needed in either name. Are you ok >> with just "DataChannel" and "dcsa" instead of "WebRTC-DataChannel" and >> "wdcsa"? I'm not really picky about the names and am open to any >> reasonable alternative... > > Its just an esthetic issue, so I'm not too picky. > > DataChannel is better than WebRTC-DataChannel. > But IMO CamelCase identifiers aren't in stylistic agreement with SDP. > So perhaps data-channel? > > "dcsa" seems reasonable. > > Thanks, > Paul > >> BR, Richard >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Sunday, October 27, 2013 12:48 PM >>> To: dispatch@ietf.org >>> Subject: [dispatch] Comments on draft-ejzak-dispatch-webrtc-data- >>> channel-sdpneg-00 >>> >>> In general I think this document is looking pretty good. It is going in >>> the right direction from my perspective. And I think its starting to >>> become clear how to have this be an optional mechanism for webrtc. I'm >>> starting to see how it could be used for CLUE, with and without webrtc. >>> >>> One thing bothers me: this is an ietf document, defining signaling. But >>> it talks quite a lot about the webrtc API. It is certainly possible to >>> use this specification in contexts where there are no browsers and no >>> use of webrtc. ISTM it would be better to segregate all the webrtc >>> stuff into an annex. Or maybe two documents are needed: one for SDP >>> negotiation of sctp data channels, and one for webrtc external >>> negotiation of data channels via the SDP mechanism. >>> >>> Esthetically I find the names "webrtc-DataChannel" and "wdcsa" quite >>> unappealing. In particular, these data channels are usable (and will be >>> used) in non-webrtc applications, so why do we need "webrtc" in the >>> name? >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@alum.mit.edu Tue Feb 4 08:31:46 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311F61A01D5 for ; Tue, 4 Feb 2014 08:31:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1xjAu7epeF2 for ; Tue, 4 Feb 2014 08:31:44 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 89F901A01AE for ; Tue, 4 Feb 2014 08:31:44 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id NCcp1n0041ap0As55GXksf; Tue, 04 Feb 2014 16:31:44 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id NGXj1n00r3ZTu2S3iGXkfu; Tue, 04 Feb 2014 16:31:44 +0000 Message-ID: <52F115EF.8080302@alum.mit.edu> Date: Tue, 04 Feb 2014 11:31:43 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <526D51D1.3090106@alum.mit.edu> <03FBA798AC24E3498B74F47FD082A92F3D86D026@US70UWXCHMBA04.zam.alcatel-lucent.com> <526E8BF5.7080206@alum.mit.edu> In-Reply-To: <526E8BF5.7080206@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391531504; bh=zMSgFqu6KXp7HxPAL6odrHNQ3cbsxha8+Ut46GeLXvI=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tHkikstKpdrsdPU/C/mjb12GaUKiQX1s/jvhx6wZruDFjtm+Nep3im7W23opc4UG4 8yUSOaBcZFe7EXmzY4H2QY+gLuJlH0x3MBg/0bRQ7QXsbt3b5K8J1UziViKjuUid+u BdWRumm+jtyHJ0+3OZGoB0nB1QlgUyYDI1a6jc43ifKcV2cEZHiuvC0S00Ler9VXnI iiHGLM87xNd5DLZ9ILtfuzlny2mM8n5oMmYxLhFDWVANzbmNAr8CFmMf9MtubabqAu 4Oz/zQf4PlBKgcUblSwrulUXzplHiPHyZ069bS50kQ8xnjzCPYgKvZ2YWOn+bVZgVm 64tqPclW61ikg== Subject: Re: [dispatch] Comments on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 (revised) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:31:46 -0000 (I changed the draft reference below) Richard, What is the status of this work? Are you planning on a new version? Also, these naming issues extend to draft-ietf-mmusic-sctp-sdp-05. Can I get your support in lobbying for naming changes there too? Thanks, Paul On 10/28/13 12:08 PM, Paul Kyzivat wrote: > On 10/28/13 11:07 AM, Ejzak, Richard P (Richard) wrote: >> Thanks, Paul. >> >> I agree that the WebRTC specific aspects need to be clearly separated >> from the core protocol aspects. I'll do that in the next version. > > Thanks! > >> I also agree that "WebRTC" is not needed in either name. Are you ok >> with just "DataChannel" and "dcsa" instead of "WebRTC-DataChannel" and >> "wdcsa"? I'm not really picky about the names and am open to any >> reasonable alternative... > > Its just an esthetic issue, so I'm not too picky. > > DataChannel is better than WebRTC-DataChannel. > But IMO CamelCase identifiers aren't in stylistic agreement with SDP. > So perhaps data-channel? > > "dcsa" seems reasonable. > > Thanks, > Paul > >> BR, Richard >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Sunday, October 27, 2013 12:48 PM >>> To: dispatch@ietf.org >>> Subject: [dispatch] Comments on draft-ejzak-dispatch-webrtc-data- >>> channel-sdpneg-00 >>> >>> In general I think this document is looking pretty good. It is going in >>> the right direction from my perspective. And I think its starting to >>> become clear how to have this be an optional mechanism for webrtc. I'm >>> starting to see how it could be used for CLUE, with and without webrtc. >>> >>> One thing bothers me: this is an ietf document, defining signaling. But >>> it talks quite a lot about the webrtc API. It is certainly possible to >>> use this specification in contexts where there are no browsers and no >>> use of webrtc. ISTM it would be better to segregate all the webrtc >>> stuff into an annex. Or maybe two documents are needed: one for SDP >>> negotiation of sctp data channels, and one for webrtc external >>> negotiation of data channels via the SDP mechanism. >>> >>> Esthetically I find the names "webrtc-DataChannel" and "wdcsa" quite >>> unappealing. In particular, these data channels are usable (and will be >>> used) in non-webrtc applications, so why do we need "webrtc" in the >>> name? >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From mary.ietf.barnes@gmail.com Tue Feb 4 08:51:50 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E137D1A00F9 for ; Tue, 4 Feb 2014 08:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxB_1zbLU2Su for ; Tue, 4 Feb 2014 08:51:49 -0800 (PST) Received: from mail-yk0-x22c.google.com (mail-yk0-x22c.google.com [IPv6:2607:f8b0:4002:c07::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA0A1A0032 for ; Tue, 4 Feb 2014 08:51:48 -0800 (PST) Received: by mail-yk0-f172.google.com with SMTP id 200so23983319ykr.3 for ; Tue, 04 Feb 2014 08:51:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5+VgUm3FDMWRXxpXgQBPHqWxDgMtKOfQ5QOrxO1pm7I=; b=eoEvtRDlJMqK8H05V2xn0wSEXpx4d8FxtK6QqYjhraqQ5Eiv6elJcGRRFlkFtmyBKO dNw7LVVLL0FypoCCrw3mSE2PEaQu5ZVbZZ5EU9vjimVuKc7hasBlXwh5+JkuAwzQNEei vsg0xx5Mt7TuyTtEVValZeWprsdbcb7id31E6xLpEiHnoEkdfeNVEL6+9d/LoSyLcf9c enb9qXtIvMNEnPdwsX4847FHeQgRcKwReJbeqxhAKdkPI5Ro5CkeXxERG9CCjW4ZvlRs ptwTMwQebtXzmOwkJ+/0w8Gw52lvh09MIB+yOMjUSxDLgn4dxI3uEj7fsPNjaRfigT63 JVZQ== MIME-Version: 1.0 X-Received: by 10.236.184.136 with SMTP id s8mr361491yhm.132.1391532706875; Tue, 04 Feb 2014 08:51:46 -0800 (PST) Received: by 10.170.46.143 with HTTP; Tue, 4 Feb 2014 08:51:46 -0800 (PST) In-Reply-To: <52F115EF.8080302@alum.mit.edu> References: <526D51D1.3090106@alum.mit.edu> <03FBA798AC24E3498B74F47FD082A92F3D86D026@US70UWXCHMBA04.zam.alcatel-lucent.com> <526E8BF5.7080206@alum.mit.edu> <52F115EF.8080302@alum.mit.edu> Date: Tue, 4 Feb 2014 10:51:46 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=20cf3040ee3aafcbf904f1977473 Cc: DISPATCH Subject: Re: [dispatch] Comments on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 (revised) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2014 16:51:51 -0000 --20cf3040ee3aafcbf904f1977473 Content-Type: text/plain; charset=ISO-8859-1 This discussion should be on the MMUSIC WG mailing list. We dispatched this document at IETF-88: http://trac.tools.ietf.org/wg/dispatch/trac/wiki Thanks, Mary. On Tue, Feb 4, 2014 at 10:31 AM, Paul Kyzivat wrote: > (I changed the draft reference below) > > Richard, > > What is the status of this work? > Are you planning on a new version? > > Also, these naming issues extend to draft-ietf-mmusic-sctp-sdp-05. > Can I get your support in lobbying for naming changes there too? > > Thanks, > Paul > > On 10/28/13 12:08 PM, Paul Kyzivat wrote: > >> On 10/28/13 11:07 AM, Ejzak, Richard P (Richard) wrote: >> >>> Thanks, Paul. >>> >>> I agree that the WebRTC specific aspects need to be clearly separated >>> from the core protocol aspects. I'll do that in the next version. >>> >> >> Thanks! >> >> I also agree that "WebRTC" is not needed in either name. Are you ok >>> with just "DataChannel" and "dcsa" instead of "WebRTC-DataChannel" and >>> "wdcsa"? I'm not really picky about the names and am open to any >>> reasonable alternative... >>> >> >> Its just an esthetic issue, so I'm not too picky. >> >> DataChannel is better than WebRTC-DataChannel. >> But IMO CamelCase identifiers aren't in stylistic agreement with SDP. >> So perhaps data-channel? >> >> "dcsa" seems reasonable. >> >> Thanks, >> Paul >> >> BR, Richard >>> >>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat >>>> Sent: Sunday, October 27, 2013 12:48 PM >>>> To: dispatch@ietf.org >>>> Subject: [dispatch] Comments on draft-ejzak-dispatch-webrtc-data- >>>> channel-sdpneg-00 >>>> >>>> In general I think this document is looking pretty good. It is going in >>>> the right direction from my perspective. And I think its starting to >>>> become clear how to have this be an optional mechanism for webrtc. I'm >>>> starting to see how it could be used for CLUE, with and without webrtc. >>>> >>>> One thing bothers me: this is an ietf document, defining signaling. But >>>> it talks quite a lot about the webrtc API. It is certainly possible to >>>> use this specification in contexts where there are no browsers and no >>>> use of webrtc. ISTM it would be better to segregate all the webrtc >>>> stuff into an annex. Or maybe two documents are needed: one for SDP >>>> negotiation of sctp data channels, and one for webrtc external >>>> negotiation of data channels via the SDP mechanism. >>>> >>>> Esthetically I find the names "webrtc-DataChannel" and "wdcsa" quite >>>> unappealing. In particular, these data channels are usable (and will be >>>> used) in non-webrtc applications, so why do we need "webrtc" in the >>>> name? >>>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --20cf3040ee3aafcbf904f1977473 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This discussion should be on the MMUSIC WG mailing list. = =A0We dispatched this document at IETF-88: =A0http://trac.tools.ietf.org/wg/dispatch/trac= /wiki

Thanks,
Mary.


On Tue, Feb 4, 2014 at 10:31 AM, Paul = Kyzivat <pkyzivat@alum.mit.edu> wrote:
(I changed the draft reference below)

Richard,

What is the status of this work?
Are you planning on a new version?

Also, these naming issues extend to draft-ietf-mmusic-sctp-sdp-05.
Can I get your support in lobbying for naming changes there too?

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

On 10/28/13 12:08 PM, Paul Kyzivat wrote:
On 10/28/13 11:07 AM, Ejzak, Richard P (Richard) wrote:
Thanks, Paul.

I agree that the WebRTC specific aspects need to be clearly separated
from the core protocol aspects. =A0I'll do that in the next version.

Thanks!

I also agree that "WebRTC" is not needed in either name. =A0Are y= ou ok
with just "DataChannel" and "dcsa" instead of "Web= RTC-DataChannel" and
"wdcsa"? =A0I'm not really picky about the names and am open = to any
reasonable alternative...

Its just an esthetic issue, so I'm not too picky.

DataChannel is better than WebRTC-DataChannel.
But IMO CamelCase identifiers aren't in stylistic agreement with SDP. So perhaps data-channel?

"dcsa" seems reasonable.

=A0 =A0 =A0Thanks,
=A0 =A0 =A0Paul

BR, Richard

-----Original Message-----
From: dispat= ch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
Behalf Of Paul Kyzivat
Sent: Sunday, October 27, 2013 12:48 PM
To: dispatch@ietf.or= g
Subject: [dispatch] Comments on draft-ejzak-dispatch-webrtc-data- channel-sdpneg-00

In general I think this document is looking pretty good. It is going in
the right direction from my perspective. And I think its starting to
become clear how to have this be an optional mechanism for webrtc. I'm<= br> starting to see how it could be used for CLUE, with and without webrtc.

One thing bothers me: this is an ietf document, defining signaling. But
it talks quite a lot about the webrtc API. It is certainly possible to
use this specification in contexts where there are no browsers and no
use of webrtc. ISTM it would be better to segregate all the webrtc
stuff into an annex. Or maybe two documents are needed: one for SDP
negotiation of sctp data channels, and one for webrtc external
negotiation of data channels via the SDP mechanism.

Esthetically I find the names "webrtc-DataChannel" and "wdcs= a" quite
unappealing. In particular, these data channels are usable (and will be
used) in non-webrtc applications, so why do we need "webrtc" in t= he
name?

=A0 =A0 Thanks,
=A0 =A0 Paul
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


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


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

--20cf3040ee3aafcbf904f1977473-- From jim.forster@rangenetworks.com Tue Feb 4 22:39:52 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D065F1A0052 for ; Tue, 4 Feb 2014 22:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7M4D56KG24P for ; Tue, 4 Feb 2014 22:39:50 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0186.outbound.protection.outlook.com [207.46.163.186]) by ietfa.amsl.com (Postfix) with ESMTP id B10EE1A004C for ; Tue, 4 Feb 2014 22:39:48 -0800 (PST) Received: from DM2PR03MB415.namprd03.prod.outlook.com (10.141.84.146) by DM2PR03MB415.namprd03.prod.outlook.com (10.141.84.146) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 06:39:45 +0000 Received: from DM2PR03MB415.namprd03.prod.outlook.com ([10.141.84.146]) by DM2PR03MB415.namprd03.prod.outlook.com ([10.141.84.146]) with mapi id 15.00.0868.013; Wed, 5 Feb 2014 06:39:45 +0000 From: Jim Forster To: "dispatch@ietf.org" Thread-Topic: SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQXw== Date: Wed, 5 Feb 2014 06:39:45 +0000 Message-ID: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [59.145.188.106] x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(189002)(199002)(51414003)(36756003)(66066001)(80022001)(65816001)(31966008)(56816005)(79102001)(76482001)(63696002)(46102001)(74662001)(81816001)(15975445006)(76176001)(47446002)(83072002)(77982001)(74502001)(56776001)(81686001)(59766001)(54316002)(74366001)(15202345003)(85852003)(92726001)(80976001)(74876001)(87266001)(53806001)(2656002)(47736001)(50986001)(76796001)(94946001)(47976001)(83716003)(90146001)(85306002)(81542001)(16236675002)(16601075003)(19580395003)(83322001)(93136001)(82746002)(74706001)(54356001)(94316002)(69226001)(76786001)(51856001)(92566001)(33656001)(49866001)(93516002)(81342001)(4396001)(87936001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB415; H:DM2PR03MB415.namprd03.prod.outlook.com; CLIP:59.145.188.106; FPR:ACF8C25D.A4F615CE.B3D3FD7B.4AE5D171.2053B; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_1DC06AF3-95E5-4A61-BBCA-E55BFC313E2A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: rangenetworks.com Subject: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 06:39:53 -0000 --Apple-Mail=_1DC06AF3-95E5-4A61-BBCA-E55BFC313E2A Content-Type: multipart/alternative; boundary="Apple-Mail=_2F3790E2-CBC9-41E1-97BF-018F51781BAC" --Apple-Mail=_2F3790E2-CBC9-41E1-97BF-018F51781BAC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear DISPATCH group, OpenBTS and OpenBSC are projects are combining GSM phones and SIP in new = and interesting ways. I think there is some value to the community in = discussing these in the DISPATCH mailing list and having an related = meeting at the London IETF. There is both some short-term, relatively = straightforward work to be done to agree on the usage of SIP in these = existing implementations. There may also be some very interesting work = to be done on more advanced approaches. First, some background: OpenBTS is an open source project started by the = founders of Range Networks to make a 'GSM system in a box', by = implementing a system which supports the air interface for GSM phones = (Um) using a Software Defined Radio (SDR) for the RF. While the GSM & = 3GPP defined air interface to the phones is supported, OpenBTS diverges = from these standards by immediately gatewaying the call to SIP. Each = GSM or UMTS phone can then appear on the Internet as a SIP endpoint. A = local SIP switching decision is made to route the call; Asterix, = Freeswitch, Yate have been. The call is then sent to another local = connected phone or to some other SIP service point on the Internet. With this in place, because the air interface to the phones is supported = with no changes, standard GSM/UMTS phones can make calls to other phones = on the same OpenBTS system or to any SIP endpoint on the Internet, and = thence to the PSTN via any of the many SIP-PSTN gateways in operation. A fair question would be "Why do all this? What's wrong with GSM & 3GPP = systems?". One reason is that the OpenBTS approach allows very small, = stand alone systems, which efficiently connect GSM and UMTS phones to = the Internet based SIP systems with a minimum of other systems. = Certainly GSM/3GPP based micro cells exist, but are tied to the 3GPP = 'Core' which is usually beyond the means of smaller users. OpenBTS = aspires to be the simplest way for a GSM/UMTS phone to make phone calls = to the SIP & PSTN world. At least several hundred, and likely several thousand of these systems = are deployed already. Many are in labs, but others are production usage = on all continents. Universities find these systems very attractive for = teaching and researching: all the code from RF to Signaling is visible = and may be changed as desired. Furthermore, additional SDRs are popping up all the time. There are 3-4 = separate SDR based systems that run OpenBTS and more are coming. Right = now they range from $2000 up, but it's easy to see them dropping to $500 = or so this year; even Kickstarter campaigns are funding some of them. = There's no natural floor below that; adding GSM/UMTS to a home router = and making it a micro-cell running SIP to the Internet could conceivably = be a $10 HW delta and some more SW. Secondly, there are several = countries that have unlicensed GSM band (Sweden, Netherlands, UK?) so = some efforts are underway to do exactly that. When facing the Internet, OpenBTS is simply a SIP client. However, to = assure interoperability, there may be value in standardized behavior, = including these issues: * Which elements of SIP are needed for this operation? * Should these be documented in a profile of SIP usage to be OpenBTS = Ready? * Should ICE be recommended or possibly be required for operation behind = NATs? * What about BTS-BTS neighbor discovery * Use of SIP Re-invite for hand-over when a mobile phone moves from one = BTS to a neighbor * For somewhat different use cases: one could separate signaling from = media transport and thus might support WebRTC or other such systems. = E.164 addresses are used in phones, but temporary numbers can be = assigned as needed (as done in Roaming) and not surfaced to the WebRTC = level. * What Changes required for IPv6? * Required and recommended security provisions * Is IETF an appropriate forum for this, or should it be in 3GPP, or = Sipforum.org, or a separate industry group formed? I look forward to discussion on the mailing list, and hopefully meeting = and discussing in London. Yours, Jim Forster Range Networks --Apple-Mail=_2F3790E2-CBC9-41E1-97BF-018F51781BAC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = DISPATCH group,

OpenBTS and OpenBSC are projects = are combining GSM phones and SIP in new and interesting ways.  I = think there is some value to the community in discussing these in the = DISPATCH mailing list and having an related meeting at the London IETF. =  There is both some short-term, relatively straightforward work to = be done to agree on the usage of SIP in these existing implementations. = There may also be some very interesting work to be done on more advanced = approaches.

First, some background: OpenBTS is an open source = project started by the founders of Range Networks to make a 'GSM system = in a box', by implementing a system which supports the air interface for = GSM phones (Um) using a Software Defined Radio (SDR) for the RF. =  While the GSM & 3GPP defined air interface to the phones is = supported, OpenBTS diverges from these standards by immediately = gatewaying the call to SIP.  Each GSM or UMTS phone can then appear = on the Internet as a SIP endpoint.  A local SIP switching decision = is made to route the call; Asterix, Freeswitch, Yate have been. =  The call is then sent to another local connected phone or to some = other SIP service point on the Internet.

With this in place, = because the air interface to the phones is supported with no changes, = standard GSM/UMTS phones can make calls to other phones on the same = OpenBTS system or to any SIP endpoint on the Internet, and thence to the = PSTN via any of the many SIP-PSTN gateways in operation.

A fair = question would be "Why do all this?  What's wrong with GSM & = 3GPP systems?".  One reason is that the OpenBTS approach allows = very small, stand alone systems, which efficiently connect GSM and UMTS = phones to the Internet based SIP systems with a minimum of other = systems.  Certainly GSM/3GPP based micro cells exist, but are tied = to the 3GPP 'Core' which is usually beyond the means of smaller users. = OpenBTS aspires to be the simplest way for a GSM/UMTS phone to make = phone calls to the SIP & PSTN world.

At least several = hundred, and likely several thousand of these systems are deployed = already.  Many are in labs, but others are production usage on all = continents.  Universities find these systems very attractive for = teaching and researching: all the code from RF to Signaling is visible = and may be changed as desired.

Furthermore, additional SDRs are = popping up all the time.  There are 3-4 separate SDR based systems = that run OpenBTS and more are coming.  Right now they range from = $2000 up, but it's easy to see them dropping to $500 or so this year; = even Kickstarter campaigns are funding some of them.  There's no = natural floor below that; adding GSM/UMTS to a home router and making it = a micro-cell running SIP to the Internet could conceivably be a $10 HW = delta and some more SW.  Secondly, there are several countries that = have unlicensed GSM band (Sweden, Netherlands, UK?) so some efforts are = underway to do exactly that.

When facing the Internet, OpenBTS is = simply a SIP client.  However, to assure interoperability, there = may be value in standardized behavior, including these issues:

* = Which elements of SIP are needed for this operation?
* Should these = be documented in a profile of SIP usage to be OpenBTS Ready?
* Should = ICE be recommended or possibly be required for operation behind = NATs?
* What about BTS-BTS neighbor discovery
* Use of SIP = Re-invite for hand-over when a mobile phone moves from one BTS to a = neighbor
* For somewhat different use cases: one could separate = signaling from media transport and thus might support WebRTC or other = such systems.  E.164 addresses are used in phones, but temporary = numbers can be assigned as needed (as done in Roaming) and not surfaced = to the WebRTC level.
* What Changes required for IPv6?
* = Required and recommended security provisions
* Is IETF an appropriate = forum for this, or should it be in 3GPP, or Sipforum.org,  or a separate = industry group formed?

I look forward to = discussion on the mailing list, and hopefully meeting and discussing in = London.

Yours,

Jim = Forster
Range Networks
= --Apple-Mail=_2F3790E2-CBC9-41E1-97BF-018F51781BAC-- --Apple-Mail=_1DC06AF3-95E5-4A61-BBCA-E55BFC313E2A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJS8dytAAoJECAtT58A/2SKoe4H/2m30+RVGSAxQuKE7eGqnszw 5SsYZtBBQDJrxcP+l/CHCA/7a16DuCK6AUVqBuZBccIux+y5mIyivq+YcVSqCLfZ RzSqEHEVM83rbjj/T3mVL9qrhbWByGWgLtCY2jfyMIC7vRr8Z+WiWBSMCpQKcSne AeUSC/pUMmjzg22NnXkhl0IPAzNFsKLSwlHZDqNPz6Uh/NZkr2OikzhOLFy7yiTF jkfCuGIBh8/YpcpGJ51udJ7Pbk37qBo9/ypkHi8dsp1j12bCfpvJ2KBIVNhuZFH5 tUxqyK0wFghi4zJ2atOJ9LOZ38vkOWBV/Sotg9P4bcx3+2v2VKUAk5HkBNulxdI= =h11u -----END PGP SIGNATURE----- --Apple-Mail=_1DC06AF3-95E5-4A61-BBCA-E55BFC313E2A-- From thp@westhawk.co.uk Wed Feb 5 02:47:28 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE3A71A00D3 for ; Wed, 5 Feb 2014 02:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c8e38YRyRWGR for ; Wed, 5 Feb 2014 02:47:26 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id BC6D51A00CF for ; Wed, 5 Feb 2014 02:47:25 -0800 (PST) Received: (qmail 13884 invoked from network); 5 Feb 2014 10:47:23 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 4043 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 5 Feb 2014 10:47:23 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id DBDD718A043F; Wed, 5 Feb 2014 10:47:21 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 9D23818A00FD; Wed, 5 Feb 2014 10:47:21 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_B28D2BB7-C27D-4F65-AAA7-924489A90B94" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton new In-Reply-To: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> Date: Wed, 5 Feb 2014 10:47:19 +0000 Message-Id: References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> To: "dispatch@ietf.org" X-Mailer: Apple Mail (2.1827) Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 10:47:29 -0000 --Apple-Mail=_B28D2BB7-C27D-4F65-AAA7-924489A90B94 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 5 Feb 2014, at 06:39, Jim Forster = wrote: >=20 > When facing the Internet, OpenBTS is simply a SIP client. However, to = assure interoperability, there may be value in standardized behavior, = including these issues: It may be a SIP client, but in some ways it is a non-traditional one, a = single BTS may well present as multiple phones (possibly thousands) like = a giant ATA bank of old. >=20 > * Which elements of SIP are needed for this operation? We need to go through the uM (GSM air interface) and document how that = maps to SIP, this will give us a=20 list of SIP actions that need to be supported to make a working UM cell > * Should these be documented in a profile of SIP usage to be OpenBTS = Ready? Yes, but we need a better name - UMSIP perhaps?=20 > * Should ICE be recommended or possibly be required for operation = behind NATs? My experience of trying to install these things is that NAT is a = persistent problem, getting an internet connection into a village in the middle of nowhere is hard enough, expecting it to have = an unfiltered public IP address is too much to ask. Fall back methods of running a VPN or using rfc5456 are both = unsatisfactory. ICE will help with the RTP streams,=20 but we need to get the SIP flowing too - perhaps SIP over TCP or even = websockets is a better fit? > * What about BTS-BTS neighbor discovery In order to handover a moving call to the next cell, a BTS need to know = where the next cells are, at the moment openBTS uses a private protocol/config. It would be great if we could = use a suitable pre-existing SIP mechanism and document that usage. > * Use of SIP Re-invite for hand-over when a mobile phone moves from = one BTS to a neighbor Or some other mechanism. > * For somewhat different use cases: one could separate signaling from = media transport and thus might support WebRTC or other such systems. = E.164 addresses are used in phones, but temporary numbers can be = assigned as needed (as done in Roaming) and not surfaced to the WebRTC = level. > * What Changes required for IPv6? > * Required and recommended security provisions > * Is IETF an appropriate forum for this, or should it be in 3GPP, or = Sipforum.org, or a separate industry group formed? I think the IETF has solved most of these problems in other cases, so it = makes sense to try and leverage that knowledge in this space,=20 and try to produce a document that lets multiple UMSIP vendors = interoperate and SIP trunk/PBX vendors know what they need to do to = support these new devices. Tim.= --Apple-Mail=_B28D2BB7-C27D-4F65-AAA7-924489A90B94 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On 5 Feb 2014, at 06:39, Jim Forster = <jim.forster@rangenetworks.co= m> wrote:

When facing the Internet, OpenBTS is simply = a SIP client.  However, to assure interoperability, there may be = value in standardized behavior, including these = issues:

It may be a SIP = client, but in some ways it is a non-traditional one, a single BTS may = well present as multiple phones (possibly thousands) like a giant ATA = bank of old.


* Which elements of SIP are needed for this = operation?

We need to go = through the uM (GSM air interface) and document how that maps to SIP, = this will give us a 
list of SIP actions that need to be = supported to make a working UM cell

* Should these be = documented in a profile of SIP usage to be OpenBTS = Ready?

Yes, but we need = a better name - UMSIP  perhaps? 

* Should ICE be = recommended or possibly be required for operation behind = NATs?

My experience of = trying to install these things is that NAT is a persistent problem, = getting an internet connection into
a village in the middle of = nowhere is hard enough, expecting it to have an unfiltered public IP = address is too much to ask.
Fall back methods of running a VPN = or using rfc5456 are both unsatisfactory. ICE will help with the = RTP streams, 
but we need to get the SIP flowing too - = perhaps SIP over TCP or even websockets is a better = fit?

* What about BTS-BTS neighbor = discovery

In order to = handover a moving call to the next cell, a BTS need to know where the = next cells are, at the moment
openBTS uses a private = protocol/config. It would be great if we could use a suitable = pre-existing SIP mechanism and document = that
usage.

* Use of SIP Re-invite for = hand-over when a mobile phone moves from one BTS to a = neighbor

Or some other = mechanism.

* For somewhat different use cases: one could = separate signaling from media transport and thus might support WebRTC or = other such systems.  E.164 addresses are used in phones, but = temporary numbers can be assigned as needed (as done in Roaming) and not = surfaced to the WebRTC level.
* What Changes required for = IPv6?
* Required and recommended security provisions
* Is IETF an = appropriate forum for this, or should it be in 3GPP, or Sipforum.org,  or a separate = industry group formed?
I think the IETF has = solved most of these problems in other cases, so it makes sense to try = and leverage that knowledge in this space, 
and try to produce = a document that lets multiple UMSIP vendors interoperate and SIP = trunk/PBX  vendors know what they need to do to support these new = devices.

Tim.
= --Apple-Mail=_B28D2BB7-C27D-4F65-AAA7-924489A90B94-- From jim.forster@rangenetworks.com Wed Feb 5 04:06:30 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC6811A00EF for ; Wed, 5 Feb 2014 04:06:30 -0800 (PST) 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=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q14Mky7dvtFU for ; Wed, 5 Feb 2014 04:06:28 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 94A701A00F1 for ; Wed, 5 Feb 2014 04:06:27 -0800 (PST) Received: from BL2PR03MB404.namprd03.prod.outlook.com (10.141.91.149) by BL2PR03MB404.namprd03.prod.outlook.com (10.141.91.149) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 12:06:26 +0000 Received: from BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) by BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) with mapi id 15.00.0868.013; Wed, 5 Feb 2014 12:06:26 +0000 From: Jim Forster To: Tim Panton Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmes6AgAAWF4A= Date: Wed, 5 Feb 2014 12:06:25 +0000 Message-ID: <6D9CF39E-90AC-4B46-A612-EC7A49D43D1B@rangenetworks.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [50.22.74.2] x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(199002)(189002)(51704005)(377454003)(24454002)(77982001)(94946001)(86362001)(93516002)(83322001)(87266001)(63696002)(47976001)(49866001)(66066001)(54316002)(85306002)(54356001)(94316002)(82746002)(93136001)(83716003)(59766001)(74366001)(19580405001)(79102001)(76482001)(90146001)(46102001)(50986001)(47736001)(81816001)(31966008)(74662001)(76786001)(36756003)(56776001)(81686001)(87936001)(83072002)(2656002)(19580395003)(74876001)(81342001)(85852003)(92566001)(92726001)(76796001)(74502001)(74706001)(33656001)(69226001)(56816005)(4396001)(80022001)(80976001)(65816001)(51856001)(47446002)(81542001)(53806001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB404; H:BL2PR03MB404.namprd03.prod.outlook.com; CLIP:50.22.74.2; FPR:6EB8FC1C.A61317C1.70F43644.4CC4C161.202C6; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_FEE7AC4C-A2E1-48A7-BE93-F1A1EB766D8C"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: rangenetworks.com Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 12:06:31 -0000 --Apple-Mail=_FEE7AC4C-A2E1-48A7-BE93-F1A1EB766D8C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 5, 2014, at 4:17 PM, Tim Panton new wrote: >> When facing the Internet, OpenBTS is simply a SIP client. However, = to assure interoperability, there may be value in standardized behavior, = including these issues: >=20 > It may be a SIP client, but in some ways it is a non-traditional one, = a single BTS may well present as multiple phones (possibly thousands) = like a giant ATA bank of old. Yes, you're right. >> * Should ICE be recommended or possibly be required for operation = behind NATs? >=20 > My experience of trying to install these things is that NAT is a = persistent problem, getting an internet connection into > a village in the middle of nowhere is hard enough, expecting it to = have an unfiltered public IP address is too much to ask. > Fall back methods of running a VPN or using rfc5456 are both = unsatisfactory. ICE will help with the RTP streams,=20 > but we need to get the SIP flowing too - perhaps SIP over TCP or even = websockets is a better fit? Very good point! It would be wonderful to have a good solution the NAT = issues. I don't have the experience to know what's the best approach = for SIP. >=20 >> * What about BTS-BTS neighbor discovery >=20 > In order to handover a moving call to the next cell, a BTS need to = know where the next cells are, at the moment > openBTS uses a private protocol/config. It would be great if we could = use a suitable pre-existing SIP mechanism and document that usage. For instance? -- Jim --Apple-Mail=_FEE7AC4C-A2E1-48A7-BE93-F1A1EB766D8C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJS8ik/AAoJECAtT58A/2SK1dwH/A7diUlzSTFWuifsKtxTIFQO qzK8rTTyVOXRtH3cClvATexeu2oCvjglgvuv65wwtAIz0qBMoUc0cdly6SnG8T+Q DUUwgAGpR0xSsKGGM+fUEWU5iXPkeRH1DpmQ19N2u+xDDPS/ZTENYpgGcjdAjOy3 KB9rUuB/HIrdrnfgM+NmYmL9BVHTPF3iELs8As6yP9XH20i8GPuuRJyuwPkop6cB eG3h7TrwpUgrIB1RH/Ai6NjYvcC7L+4O6LpFJT8Mx6OVzdYN3ZlfCncVW7hf2aJA EUkeZp9bsKUXN3axtl8diIQoFaGS5BL/vkISbRWSzmCKb1ukfLi8rbCCmj7rha0= =GOhg -----END PGP SIGNATURE----- --Apple-Mail=_FEE7AC4C-A2E1-48A7-BE93-F1A1EB766D8C-- From gullik.webjorn@corevalue.se Wed Feb 5 06:00:24 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CCE1A013C for ; Wed, 5 Feb 2014 06:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byvsMvE3hNom for ; Wed, 5 Feb 2014 06:00:21 -0800 (PST) Received: from mailgw18.surf-town.net (mail3.surf-town.net [212.97.132.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5615F1A0134 for ; Wed, 5 Feb 2014 06:00:20 -0800 (PST) Received: by mailgw18.surf-town.net (Postfix, from userid 65534) id 9E0F81B3C4; Wed, 5 Feb 2014 15:00:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mailgw18.surf-town.net (Postfix) with ESMTP id 8333A1B3C3 for ; Wed, 5 Feb 2014 15:00:19 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mailgw18.surf-town.net Received: from mailgw18.surf-town.net ([127.0.0.1]) by localhost (mailgw18.surf-town.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id zxrPE8y2IHeZ for ; Wed, 5 Feb 2014 15:00:16 +0100 (CET) Received: from [192.168.1.102] (78-72-48-131-no186.tbcn.telia.com [78.72.48.131]) (Authenticated sender: gullik.webjorn@corevalue.se) by mailgw18.surf-town.net (Postfix) with ESMTPSA id 9899F1B30C for ; Wed, 5 Feb 2014 15:00:16 +0100 (CET) Message-ID: <52F243EE.7080103@corevalue.se> Date: Wed, 05 Feb 2014 15:00:14 +0100 From: =?ISO-8859-1?Q?Gullik_Webj=F6rn?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080408050004020706010402" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 14:00:24 -0000 This is a multi-part message in MIME format. --------------080408050004020706010402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02/05/2014 11:47 AM, Tim Panton new wrote: > > On 5 Feb 2014, at 06:39, Jim Forster > wrote: >> >> When facing the Internet, OpenBTS is simply a SIP client. However, >> to assure interoperability, there may be value in standardized >> behavior, including these issues: > > It may be a SIP client, but in some ways it is a non-traditional one, > a single BTS may well present as multiple phones (possibly thousands) > like a giant ATA bank of old. > >> >> * Which elements of SIP are needed for this operation? > > We need to go through the uM (GSM air interface) and document how that > maps to SIP, this will give us a > list of SIP actions that need to be supported to make a working UM cell > >> * Should these be documented in a profile of SIP usage to be OpenBTS >> Ready? > > Yes, but we need a better name - UMSIP perhaps? > >> * Should ICE be recommended or possibly be required for operation >> behind NATs? > > My experience of trying to install these things is that NAT is a > persistent problem, getting an internet connection into > a village in the middle of nowhere is hard enough, expecting it to > have an unfiltered public IP address is too much to ask. > Fall back methods of running a VPN or using rfc5456 are both > unsatisfactory. ICE will help with the RTP streams, > but we need to get the SIP flowing too - perhaps SIP over TCP or even > websockets is a better fit? > >> * What about BTS-BTS neighbor discovery > > In order to handover a moving call to the next cell, a BTS need to > know where the next cells are, at the moment > openBTS uses a private protocol/config. It would be great if we could > use a suitable pre-existing SIP mechanism and document that > usage. > >> * Use of SIP Re-invite for hand-over when a mobile phone moves from >> one BTS to a neighbor > > Or some other mechanism. Here is room for some enhancements, adding to preconfigured handover / roaming. A simple mechanism to propagate and apply a ruleset, such that each BTS responsible for the registration can indicate whether a) A foreign MS is allowed to handover / roam to this BTS, and b) A local MS is allowed to request its information via a foreign BTS. This will allow policy based mobility, i.e. bilateral agreements between BTS's. My 2 c worth. Gullik > >> * For somewhat different use cases: one could separate signaling from >> media transport and thus might support WebRTC or other such systems. >> E.164 addresses are used in phones, but temporary numbers can be >> assigned as needed (as done in Roaming) and not surfaced to the >> WebRTC level. >> * What Changes required for IPv6? >> * Required and recommended security provisions >> * Is IETF an appropriate forum for this, or should it be in 3GPP, or >> Sipforum.org , or a separate industry group >> formed? > I think the IETF has solved most of these problems in other cases, so > it makes sense to try and leverage that knowledge in this space, > and try to produce a document that lets multiple UMSIP vendors > interoperate and SIP trunk/PBX vendors know what they need to do to > support these new devices. > > Tim. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------080408050004020706010402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 02/05/2014 11:47 AM, Tim Panton new wrote:

On 5 Feb 2014, at 06:39, Jim Forster <jim.forster@rangenetworks.com> wrote:

When facing the Internet, OpenBTS is simply a SIP client.  However, to assure interoperability, there may be value in standardized behavior, including these issues:

It may be a SIP client, but in some ways it is a non-traditional one, a single BTS may well present as multiple phones (possibly thousands) like a giant ATA bank of old.


* Which elements of SIP are needed for this operation?

We need to go through the uM (GSM air interface) and document how that maps to SIP, this will give us a 
list of SIP actions that need to be supported to make a working UM cell

* Should these be documented in a profile of SIP usage to be OpenBTS Ready?

Yes, but we need a better name - UMSIP  perhaps? 

* Should ICE be recommended or possibly be required for operation behind NATs?

My experience of trying to install these things is that NAT is a persistent problem, getting an internet connection into
a village in the middle of nowhere is hard enough, expecting it to have an unfiltered public IP address is too much to ask.
Fall back methods of running a VPN or using rfc5456 are both unsatisfactory. ICE will help with the RTP streams, 
but we need to get the SIP flowing too - perhaps SIP over TCP or even websockets is a better fit?

* What about BTS-BTS neighbor discovery

In order to handover a moving call to the next cell, a BTS need to know where the next cells are, at the moment
openBTS uses a private protocol/config. It would be great if we could use a suitable pre-existing SIP mechanism and document that
usage.

* Use of SIP Re-invite for hand-over when a mobile phone moves from one BTS to a neighbor

Or some other mechanism.
Here is room for some enhancements, adding to preconfigured handover / roaming.

A simple mechanism to propagate and apply a ruleset, such that each BTS responsible for the registration
can indicate whether a) A foreign MS is allowed to handover / roam to this BTS, and b) A local MS is allowed to request its information via a foreign
BTS. This will allow policy based mobility, i.e. bilateral agreements between BTS's. My 2 c worth.

Gullik


* For somewhat different use cases: one could separate signaling from media transport and thus might support WebRTC or other such systems.  E.164 addresses are used in phones, but temporary numbers can be assigned as needed (as done in Roaming) and not surfaced to the WebRTC level.
* What Changes required for IPv6?
* Required and recommended security provisions
* Is IETF an appropriate forum for this, or should it be in 3GPP, or Sipforum.org,  or a separate industry group formed?
I think the IETF has solved most of these problems in other cases, so it makes sense to try and leverage that knowledge in this space, 
and try to produce a document that lets multiple UMSIP vendors interoperate and SIP trunk/PBX  vendors know what they need to do to support these new devices.

Tim.


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

--------------080408050004020706010402-- From pkyzivat@alum.mit.edu Wed Feb 5 07:02:00 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF25A1A016E for ; Wed, 5 Feb 2014 07:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NGvtkdxMO78 for ; Wed, 5 Feb 2014 07:01:59 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9BE1A00FD for ; Wed, 5 Feb 2014 07:01:59 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta12.westchester.pa.mail.comcast.net with comcast id NdrE1n0030mv7h05Cf1yof; Wed, 05 Feb 2014 15:01:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id Nf1y1n0023ZTu2S3Xf1yyf; Wed, 05 Feb 2014 15:01:58 +0000 Message-ID: <52F25265.5070108@alum.mit.edu> Date: Wed, 05 Feb 2014 10:01:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> In-Reply-To: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391612518; bh=x/4es6pD1BRqA7ISbrR8StFSHu7T3bwzcWq75QPFmGQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=k5tW5I+/UYZO3G6h2UFrg8mL5MBlZpqEyjhE8W2WGDmPvHesBWv/qPsSd7xpj7DM2 czmvIK69H5OajL6ek989NzryNn8JOMK0rHwRwHg5aK8DULSqUT3fVls6gx6kGsoEox zFOxswVcIQiMyZfeA3El0IxHjAqRKJMSvS/mI2He8ongsWxxlLZ07z5NGImlyTGkGN xZiP4r18QlVysAaztOosCWfqhxCkiNwUUG+WmQnyRAWIdjuSgaaiqBtG18waqTr/Wz gWNoUtnp8FGDsQdZ0Z4eFBnIWeq/+WilE+C7KKzMsYvmYwTYzKYXknDqjU940VKlJT ujpPvDkZQQKjw== Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 15:02:01 -0000 Jim, I'd be interested in hearing more about this. But you are tardy in bringing this up for London. The deadline for scheduling BOFs has passed. (And you would have need to do quite a bit more to stimulate interest to get one scheduled.) In principle you could ask for agenda time in dispatch. But that is typically only granted for subjects that have had discussion and interest on the dispatch mailing list. So you are doing the right thing to get started, by beginning discussion on the dispatch list. But it is unlikely that you can do anything about it *formally* in live sessions in London. You might want to set yourself a goal to generate sufficient interest to do something at the following ietf in Toronto. For the London meeting you could make an effort to set up something informal, such as a "Bar BOF". But the main thing, even for that, is to develop a set of interested followers via email. Best wishes, Paul On 2/5/14 1:39 AM, Jim Forster wrote: > Dear DISPATCH group, > > OpenBTS and OpenBSC are projects are combining GSM phones and SIP in new > and interesting ways. I think there is some value to the community in > discussing these in the DISPATCH mailing list and having an related > meeting at the London IETF. There is both some short-term, relatively > straightforward work to be done to agree on the usage of SIP in these > existing implementations. There may also be some very interesting work > to be done on more advanced approaches. > > First, some background: OpenBTS is an open source project started by the > founders of Range Networks to make a 'GSM system in a box', by > implementing a system which supports the air interface for GSM phones > (Um) using a Software Defined Radio (SDR) for the RF. While the GSM & > 3GPP defined air interface to the phones is supported, OpenBTS diverges > from these standards by immediately gatewaying the call to SIP. Each > GSM or UMTS phone can then appear on the Internet as a SIP endpoint. A > local SIP switching decision is made to route the call; Asterix, > Freeswitch, Yate have been. The call is then sent to another local > connected phone or to some other SIP service point on the Internet. > > With this in place, because the air interface to the phones is supported > with no changes, standard GSM/UMTS phones can make calls to other phones > on the same OpenBTS system or to any SIP endpoint on the Internet, and > thence to the PSTN via any of the many SIP-PSTN gateways in operation. > > A fair question would be "Why do all this? What's wrong with GSM & 3GPP > systems?". One reason is that the OpenBTS approach allows very small, > stand alone systems, which efficiently connect GSM and UMTS phones to > the Internet based SIP systems with a minimum of other systems. > Certainly GSM/3GPP based micro cells exist, but are tied to the 3GPP > 'Core' which is usually beyond the means of smaller users. OpenBTS > aspires to be the simplest way for a GSM/UMTS phone to make phone calls > to the SIP & PSTN world. > > At least several hundred, and likely several thousand of these systems > are deployed already. Many are in labs, but others are production usage > on all continents. Universities find these systems very attractive for > teaching and researching: all the code from RF to Signaling is visible > and may be changed as desired. > > Furthermore, additional SDRs are popping up all the time. There are 3-4 > separate SDR based systems that run OpenBTS and more are coming. Right > now they range from $2000 up, but it's easy to see them dropping to $500 > or so this year; even Kickstarter campaigns are funding some of them. > There's no natural floor below that; adding GSM/UMTS to a home router > and making it a micro-cell running SIP to the Internet could conceivably > be a $10 HW delta and some more SW. Secondly, there are several > countries that have unlicensed GSM band (Sweden, Netherlands, UK?) so > some efforts are underway to do exactly that. > > When facing the Internet, OpenBTS is simply a SIP client. However, to > assure interoperability, there may be value in standardized behavior, > including these issues: > > * Which elements of SIP are needed for this operation? > * Should these be documented in a profile of SIP usage to be OpenBTS Ready? > * Should ICE be recommended or possibly be required for operation behind > NATs? > * What about BTS-BTS neighbor discovery > * Use of SIP Re-invite for hand-over when a mobile phone moves from one > BTS to a neighbor > * For somewhat different use cases: one could separate signaling from > media transport and thus might support WebRTC or other such systems. > E.164 addresses are used in phones, but temporary numbers can be > assigned as needed (as done in Roaming) and not surfaced to the WebRTC > level. > * What Changes required for IPv6? > * Required and recommended security provisions > * Is IETF an appropriate forum for this, or should it be in 3GPP, or > Sipforum.org , or a separate industry group formed? > > I look forward to discussion on the mailing list, and hopefully meeting > and discussing in London. > > Yours, > > Jim Forster > Range Networks > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From mary.ietf.barnes@gmail.com Wed Feb 5 07:17:58 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73391A01FD for ; Wed, 5 Feb 2014 07:17:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XD--t90mD2iu for ; Wed, 5 Feb 2014 07:17:50 -0800 (PST) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 083771A0204 for ; Wed, 5 Feb 2014 07:17:49 -0800 (PST) Received: by mail-yh0-f49.google.com with SMTP id t59so507793yho.8 for ; Wed, 05 Feb 2014 07:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kNftQyB/qEKCDLvjpQRWfz5WU1Q5muab2t2/Qk1x9Xg=; b=VQvlaV3t2hC0WX9dblAHxlei2UTgYu/Y+VJx5VoQ5cze/fRn0aPIY43eTGzXUID4xs M4LKuhdTU+qEC4rQJQA68fDGY1cPORggy1wHLoezSDy3g45+jJpXhNjcEFmFFbcBpL6G J/EkqCxOJZ4hARzYgHKv7sVnK93Glo+07e2LgLPDOMzNo/jyZJnkjevyeTRtR3AMPn62 1cLOBTy82WsDiIcjrHQS8LsOILsS7jnA3F2OrZ/eIrZ8PGM3zTjTB4c0HuKzRwdnoyRN 4CgzmoFn4ngpxqUtD94CVGmTxj5bKUmPAeyyJ1LoTB+Ak7LEYN/DsNEJ3hsdu8qvL3ks wHBw== MIME-Version: 1.0 X-Received: by 10.236.193.200 with SMTP id k48mr79163yhn.159.1391613468944; Wed, 05 Feb 2014 07:17:48 -0800 (PST) Received: by 10.170.46.143 with HTTP; Wed, 5 Feb 2014 07:17:48 -0800 (PST) In-Reply-To: <52F25265.5070108@alum.mit.edu> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <52F25265.5070108@alum.mit.edu> Date: Wed, 5 Feb 2014 09:17:48 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=bcaec50dc1c07b2dd304f1aa42b8 Cc: DISPATCH Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 15:17:58 -0000 --bcaec50dc1c07b2dd304f1aa42b8 Content-Type: text/plain; charset=ISO-8859-1 He is just a couple days late for the DISPATCH process: http://tools.ietf.org/wg/dispatch/trac/wiki The chairs were aware of this request within the required timeframe. Jim had originally contact ADs about a Bof and they referred JIm to the DISPATCH chairs. There is no requirement whatsoever that work goes through an official IETF Bof prior to being chartered. Depending upon how this mailing list discussion goes, the DISPATCH chairs will decide whether this topic gets agenda time in DISPATCH or whether a less formal discussion would be optimal (although, scheduling time for that in a venue that will be expeditious will be difficult given the current RAI schedule). Mary. DISPATCH WG co-chair On Wed, Feb 5, 2014 at 9:01 AM, Paul Kyzivat wrote: > Jim, > > I'd be interested in hearing more about this. > But you are tardy in bringing this up for London. > The deadline for scheduling BOFs has passed. (And you would have need to > do quite a bit more to stimulate interest to get one scheduled.) > > In principle you could ask for agenda time in dispatch. But that is > typically only granted for subjects that have had discussion and interest > on the dispatch mailing list. > > So you are doing the right thing to get started, by beginning discussion > on the dispatch list. But it is unlikely that you can do anything about it > *formally* in live sessions in London. You might want to set yourself a > goal to generate sufficient interest to do something at the following ietf > in Toronto. > > For the London meeting you could make an effort to set up something > informal, such as a "Bar BOF". But the main thing, even for that, is to > develop a set of interested followers via email. > > Best wishes, > Paul > > > On 2/5/14 1:39 AM, Jim Forster wrote: > >> Dear DISPATCH group, >> >> OpenBTS and OpenBSC are projects are combining GSM phones and SIP in new >> and interesting ways. I think there is some value to the community in >> discussing these in the DISPATCH mailing list and having an related >> meeting at the London IETF. There is both some short-term, relatively >> straightforward work to be done to agree on the usage of SIP in these >> existing implementations. There may also be some very interesting work >> to be done on more advanced approaches. >> >> First, some background: OpenBTS is an open source project started by the >> founders of Range Networks to make a 'GSM system in a box', by >> implementing a system which supports the air interface for GSM phones >> (Um) using a Software Defined Radio (SDR) for the RF. While the GSM & >> 3GPP defined air interface to the phones is supported, OpenBTS diverges >> from these standards by immediately gatewaying the call to SIP. Each >> GSM or UMTS phone can then appear on the Internet as a SIP endpoint. A >> local SIP switching decision is made to route the call; Asterix, >> Freeswitch, Yate have been. The call is then sent to another local >> connected phone or to some other SIP service point on the Internet. >> >> With this in place, because the air interface to the phones is supported >> with no changes, standard GSM/UMTS phones can make calls to other phones >> on the same OpenBTS system or to any SIP endpoint on the Internet, and >> thence to the PSTN via any of the many SIP-PSTN gateways in operation. >> >> A fair question would be "Why do all this? What's wrong with GSM & 3GPP >> systems?". One reason is that the OpenBTS approach allows very small, >> stand alone systems, which efficiently connect GSM and UMTS phones to >> the Internet based SIP systems with a minimum of other systems. >> Certainly GSM/3GPP based micro cells exist, but are tied to the 3GPP >> 'Core' which is usually beyond the means of smaller users. OpenBTS >> aspires to be the simplest way for a GSM/UMTS phone to make phone calls >> to the SIP & PSTN world. >> >> At least several hundred, and likely several thousand of these systems >> are deployed already. Many are in labs, but others are production usage >> on all continents. Universities find these systems very attractive for >> teaching and researching: all the code from RF to Signaling is visible >> and may be changed as desired. >> >> Furthermore, additional SDRs are popping up all the time. There are 3-4 >> separate SDR based systems that run OpenBTS and more are coming. Right >> now they range from $2000 up, but it's easy to see them dropping to $500 >> or so this year; even Kickstarter campaigns are funding some of them. >> There's no natural floor below that; adding GSM/UMTS to a home router >> and making it a micro-cell running SIP to the Internet could conceivably >> be a $10 HW delta and some more SW. Secondly, there are several >> countries that have unlicensed GSM band (Sweden, Netherlands, UK?) so >> some efforts are underway to do exactly that. >> >> When facing the Internet, OpenBTS is simply a SIP client. However, to >> assure interoperability, there may be value in standardized behavior, >> including these issues: >> >> * Which elements of SIP are needed for this operation? >> * Should these be documented in a profile of SIP usage to be OpenBTS >> Ready? >> * Should ICE be recommended or possibly be required for operation behind >> NATs? >> * What about BTS-BTS neighbor discovery >> * Use of SIP Re-invite for hand-over when a mobile phone moves from one >> BTS to a neighbor >> * For somewhat different use cases: one could separate signaling from >> media transport and thus might support WebRTC or other such systems. >> E.164 addresses are used in phones, but temporary numbers can be >> assigned as needed (as done in Roaming) and not surfaced to the WebRTC >> level. >> * What Changes required for IPv6? >> * Required and recommended security provisions >> * Is IETF an appropriate forum for this, or should it be in 3GPP, or >> Sipforum.org , or a separate industry group formed? >> >> >> I look forward to discussion on the mailing list, and hopefully meeting >> and discussing in London. >> >> Yours, >> >> Jim Forster >> Range Networks >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --bcaec50dc1c07b2dd304f1aa42b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
He is just a couple days =A0late for the DISPATCH process:=
The chairs were aware of th= is request within the required timeframe. =A0Jim had originally contact ADs= about a Bof and they referred JIm to the DISPATCH chairs.

There is no requirement whatsoever that work goes= through an official IETF Bof prior to being chartered. =A0Depending upon h= ow this mailing list discussion goes, the DISPATCH chairs will decide wheth= er this topic gets agenda time in DISPATCH or whether a less formal discuss= ion would be optimal (although, scheduling time for that in a venue that wi= ll be expeditious will be difficult given the current RAI schedule).

Mary.=A0
DISPATCH WG co-chair


On Wed= , Feb 5, 2014 at 9:01 AM, Paul Kyzivat <pkyzivat@alum.mit.edu><= /span> wrote:
Jim,

I'd be interested in hearing more about this.
But you are tardy in bringing this up for London.
The deadline for scheduling BOFs has passed. (And you would have need to do= quite a bit more to stimulate interest to get one scheduled.)

In principle you could ask for agenda time in dispatch. But that is typical= ly only granted for subjects that have had discussion and interest on the d= ispatch mailing list.

So you are doing the right thing to get started, by beginning discussion on= the dispatch list. But it is unlikely that you can do anything about it *f= ormally* in live sessions in London. You might want to set yourself a goal = to generate sufficient interest to do something at the following ietf in To= ronto.

For the London meeting you could make an effort to set up something informa= l, such as a "Bar BOF". But the main thing, even for that, is to = develop a set of interested followers via email.

=A0 =A0 =A0 =A0 Best wishes,
=A0 =A0 =A0 =A0 Paul


On 2/5/14 1:39 AM, Jim Forster wrote:
Dear DISPATCH group,

OpenBTS and OpenBSC are projects are combining GSM phones and SIP in new and interesting ways. =A0I think there is some value to the community in discussing these in the DISPATCH mailing list and having an related
meeting at the London IETF. =A0There is both some short-term, relatively straightforward work to be done to agree on the usage of SIP in these
existing implementations. There may also be some very interesting work
to be done on more advanced approaches.

First, some background: OpenBTS is an open source project started by the founders of Range Networks to make a 'GSM system in a box', by
implementing a system which supports the air interface for GSM phones
(Um) using a Software Defined Radio (SDR) for the RF. =A0While the GSM &= ;
3GPP defined air interface to the phones is supported, OpenBTS diverges
from these standards by immediately gatewaying the call to SIP. =A0Each
GSM or UMTS phone can then appear on the Internet as a SIP endpoint. =A0A local SIP switching decision is made to route the call; Asterix,
Freeswitch, Yate have been. =A0The call is then sent to another local
connected phone or to some other SIP service point on the Internet.

With this in place, because the air interface to the phones is supported with no changes, standard GSM/UMTS phones can make calls to other phones on the same OpenBTS system or to any SIP endpoint on the Internet, and
thence to the PSTN via any of the many SIP-PSTN gateways in operation.

A fair question would be "Why do all this? =A0What's wrong with GS= M & 3GPP
systems?". =A0One reason is that the OpenBTS approach allows very smal= l,
stand alone systems, which efficiently connect GSM and UMTS phones to
the Internet based SIP systems with a minimum of other systems.
=A0 Certainly GSM/3GPP based micro cells exist, but are tied to the 3GPP 'Core' which is usually beyond the means of smaller users. OpenBTS<= br> aspires to be the simplest way for a GSM/UMTS phone to make phone calls
to the SIP & PSTN world.

At least several hundred, and likely several thousand of these systems
are deployed already. =A0Many are in labs, but others are production usage<= br> on all continents. =A0Universities find these systems very attractive for teaching and researching: all the code from RF to Signaling is visible
and may be changed as desired.

Furthermore, additional SDRs are popping up all the time. =A0There are 3-4<= br> separate SDR based systems that run OpenBTS and more are coming. =A0Right now they range from $2000 up, but it's easy to see them dropping to $50= 0
or so this year; even Kickstarter campaigns are funding some of them.
=A0 There's no natural floor below that; adding GSM/UMTS to a home rout= er
and making it a micro-cell running SIP to the Internet could conceivably be a $10 HW delta and some more SW. =A0Secondly, there are several
countries that have unlicensed GSM band (Sweden, Netherlands, UK?) so
some efforts are underway to do exactly that.

When facing the Internet, OpenBTS is simply a SIP client. =A0However, to assure interoperability, there may be value in standardized behavior,
including these issues:

* Which elements of SIP are needed for this operation?
* Should these be documented in a profile of SIP usage to be OpenBTS Ready?=
* Should ICE be recommended or possibly be required for operation behind NATs?
* What about BTS-BTS neighbor discovery
* Use of SIP Re-invite for hand-over when a mobile phone moves from one
BTS to a neighbor
* For somewhat different use cases: one could separate signaling from
media transport and thus might support WebRTC or other such systems.
=A0 E.164 addresses are used in phones, but temporary numbers can be
assigned as needed (as done in Roaming) and not surfaced to the WebRTC
level.
* What Changes required for IPv6?
* Required and recommended security provisions
* Is IETF an appropriate forum for this, or should it be in 3GPP, or
Sipforum.org <http://S= ipforum.org>, =A0or a separate industry group formed?


I look forward to discussion on the mailing list, and hopefully meeting
and discussing in London.

Yours,

Jim Forster
Range Networks


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


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

--bcaec50dc1c07b2dd304f1aa42b8-- From michael.hammer@yaanatech.com Wed Feb 5 07:18:17 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09071A01FD for ; Wed, 5 Feb 2014 07:18:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOHqbcxirmUg for ; Wed, 5 Feb 2014 07:18:14 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB1D1A0189 for ; Wed, 5 Feb 2014 07:18:14 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 07:18:14 -0800 From: Michael Hammer To: "pkyzivat@alum.mit.edu" , "dispatch@ietf.org" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qnSA+A//9+EdA= Date: Wed, 5 Feb 2014 15:18:11 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF2361F@sc9-ex2k10mb1.corp.yaanatech.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <52F25265.5070108@alum.mit.edu> In-Reply-To: <52F25265.5070108@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.48] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0007_01CF225B.9223ECF0" MIME-Version: 1.0 Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 15:18:18 -0000 ------=_NextPart_000_0007_01CF225B.9223ECF0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Jim, Is the end result of this improvements to the SIP or other IETF protocols? Or, does this attempt to standardize an architecture? Also, is there any IPR attached to this? Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, February 05, 2014 10:02 AM To: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS Jim, I'd be interested in hearing more about this. But you are tardy in bringing this up for London. The deadline for scheduling BOFs has passed. (And you would have need to do quite a bit more to stimulate interest to get one scheduled.) In principle you could ask for agenda time in dispatch. But that is typically only granted for subjects that have had discussion and interest on the dispatch mailing list. So you are doing the right thing to get started, by beginning discussion on the dispatch list. But it is unlikely that you can do anything about it *formally* in live sessions in London. You might want to set yourself a goal to generate sufficient interest to do something at the following ietf in Toronto. For the London meeting you could make an effort to set up something informal, such as a "Bar BOF". But the main thing, even for that, is to develop a set of interested followers via email. Best wishes, Paul On 2/5/14 1:39 AM, Jim Forster wrote: > Dear DISPATCH group, > > OpenBTS and OpenBSC are projects are combining GSM phones and SIP in > new and interesting ways. I think there is some value to the > community in discussing these in the DISPATCH mailing list and having > an related meeting at the London IETF. There is both some short-term, > relatively straightforward work to be done to agree on the usage of > SIP in these existing implementations. There may also be some very > interesting work to be done on more advanced approaches. > > First, some background: OpenBTS is an open source project started by > the founders of Range Networks to make a 'GSM system in a box', by > implementing a system which supports the air interface for GSM phones > (Um) using a Software Defined Radio (SDR) for the RF. While the GSM & > 3GPP defined air interface to the phones is supported, OpenBTS > diverges from these standards by immediately gatewaying the call to > SIP. Each GSM or UMTS phone can then appear on the Internet as a SIP > endpoint. A local SIP switching decision is made to route the call; > Asterix, Freeswitch, Yate have been. The call is then sent to another > local connected phone or to some other SIP service point on the Internet. > > With this in place, because the air interface to the phones is > supported with no changes, standard GSM/UMTS phones can make calls to > other phones on the same OpenBTS system or to any SIP endpoint on the > Internet, and thence to the PSTN via any of the many SIP-PSTN gateways in operation. > > A fair question would be "Why do all this? What's wrong with GSM & > 3GPP systems?". One reason is that the OpenBTS approach allows very > small, stand alone systems, which efficiently connect GSM and UMTS > phones to the Internet based SIP systems with a minimum of other systems. > Certainly GSM/3GPP based micro cells exist, but are tied to the 3GPP > 'Core' which is usually beyond the means of smaller users. OpenBTS > aspires to be the simplest way for a GSM/UMTS phone to make phone > calls to the SIP & PSTN world. > > At least several hundred, and likely several thousand of these systems > are deployed already. Many are in labs, but others are production > usage on all continents. Universities find these systems very > attractive for teaching and researching: all the code from RF to > Signaling is visible and may be changed as desired. > > Furthermore, additional SDRs are popping up all the time. There are > 3-4 separate SDR based systems that run OpenBTS and more are coming. > Right now they range from $2000 up, but it's easy to see them dropping > to $500 or so this year; even Kickstarter campaigns are funding some of them. > There's no natural floor below that; adding GSM/UMTS to a home > router and making it a micro-cell running SIP to the Internet could > conceivably be a $10 HW delta and some more SW. Secondly, there are > several countries that have unlicensed GSM band (Sweden, Netherlands, > UK?) so some efforts are underway to do exactly that. > > When facing the Internet, OpenBTS is simply a SIP client. However, to > assure interoperability, there may be value in standardized behavior, > including these issues: > > * Which elements of SIP are needed for this operation? > * Should these be documented in a profile of SIP usage to be OpenBTS Ready? > * Should ICE be recommended or possibly be required for operation > behind NATs? > * What about BTS-BTS neighbor discovery > * Use of SIP Re-invite for hand-over when a mobile phone moves from > one BTS to a neighbor > * For somewhat different use cases: one could separate signaling from > media transport and thus might support WebRTC or other such systems. > E.164 addresses are used in phones, but temporary numbers can be > assigned as needed (as done in Roaming) and not surfaced to the WebRTC > level. > * What Changes required for IPv6? > * Required and recommended security provisions > * Is IETF an appropriate forum for this, or should it be in 3GPP, or > Sipforum.org , or a separate industry group formed? > > I look forward to discussion on the mailing list, and hopefully > meeting and discussing in London. > > Yours, > > Jim Forster > Range Networks > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_0007_01CF225B.9223ECF0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIw NTE1MTgxMFowIwYJKoZIhvcNAQkEMRYEFDHDLN7X+VNbIjv4POv7EPlSqLI+MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEARKWqTCgg5h7Yp3jXoyatVl/eKh0sUQzyM25UjnYG cDjyUlB4D2g8e8QRElG4Cdy14qDFgmpT9VbB0ze8CRpfWktkMkfPZlwvszyhqadRd7SE0aBxioll tM6jkQvyJF3c+1QGm6zToF3Gf++C+BbDozp1tCrBIei1dTY4+CH8lQC78RXkTzZEpTFPOLjJe7Cb 4Ciw6oH3yCCj+CQdT4jwGa72cdqtyeBE3//GTJ0F+N5bQIDC01AO+Y+Bm8rDL5AF7zAOQ4ZUj+ry YCWj9cLyp4vQmOERLWTI2Xw0Nm0G1creduZsRyQBEx1ZvHWYWtZ8dxlBX1XMhVO8KQysGEReOAAA AAAAAA== ------=_NextPart_000_0007_01CF225B.9223ECF0-- From thp@westhawk.co.uk Wed Feb 5 07:39:14 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D01A1A01AF for ; Wed, 5 Feb 2014 07:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoAfyRa-Nokm for ; Wed, 5 Feb 2014 07:39:12 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE741A0192 for ; Wed, 5 Feb 2014 07:39:12 -0800 (PST) Received: (qmail 42026 invoked from network); 5 Feb 2014 15:39:03 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 11718 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 5 Feb 2014 15:39:03 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id E25C518A0451; Wed, 5 Feb 2014 15:39:02 +0000 (GMT) Received: from [172.16.0.102] (unknown [37.191.118.68]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id B05A918A0205; Wed, 5 Feb 2014 15:39:02 +0000 (GMT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: tim panton In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF2361F@sc9-ex2k10mb1.corp.yaanatech.com> Date: Wed, 5 Feb 2014 15:39:01 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <52F25265.5070108@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BBF2361F@sc9-ex2k10mb1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 15:39:14 -0000 On 5 Feb 2014, at 15:18, Michael Hammer = wrote: >=20 > Is the end result of this improvements to the SIP or other IETF = protocols? Speaking entirely for myself (as one does in the IETF) I=92d guess that = the outcome might be some small improvements in SIP and other protocols (SDP or RTP = perhaps) due to the fact that the usage is slightly out of the ordinary so may well trip an edge = case or something. > Or, does this attempt to standardize an architecture? I=92d like it to standardise an _interface_ so that multiple = architectures can interoperate. >=20 > Also, is there any IPR attached to this? I=92ll let Jim answer that when he wakes up in India, but as an old (but = lapsed) IETF hand I=92m sure=20 he=92s aware of the IPR rules. >=20 > Michael Hammer > Principal Engineer > michael.hammer@yaanatech.com > Mobile: +1 408-202-9291 > 500 Yosemite Drive Suite 120 > Milpitas, CA 95035 USA >=20 >=20 From keith.drage@alcatel-lucent.com Wed Feb 5 07:56:39 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADE41A01BB for ; Wed, 5 Feb 2014 07:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnp-f1obiT75 for ; Wed, 5 Feb 2014 07:56:36 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 2295E1A01F1 for ; Wed, 5 Feb 2014 07:56:36 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s15FuUiZ028819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 09:56:32 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s15FuSHR005285 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 16:56:30 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 5 Feb 2014 16:56:28 +0100 From: "DRAGE, Keith (Keith)" To: Jim Forster , "dispatch@ietf.org" Thread-Topic: SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3Rg Date: Wed, 5 Feb 2014 15:56:28 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> In-Reply-To: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B12A6DEFR712WXCHMBA11zeu_" MIME-Version: 1.0 Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 15:56:39 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B12A6DEFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A good question for you to answer would be as to which of the requirements = of 3GPP TS 22.228 you would support and which you would not support. http://www.3gpp.org/DynaReport/22228.htm These requirements led to the development of IMS as it is now, and the IMS = architecture is as it is because of those requirements. How much are you trying to design something new, versus integrating a P-CSC= F and a BTS economically in the same box, which network virtualisation will= ultimately do? regards Keith Drage ________________________________ From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Jim Forster Sent: 05 February 2014 06:40 To: dispatch@ietf.org Subject: [dispatch] SIP and GSM/UMTS with OpenBTS Dear DISPATCH group, OpenBTS and OpenBSC are projects are combining GSM phones and SIP in new an= d interesting ways. I think there is some value to the community in discus= sing these in the DISPATCH mailing list and having an related meeting at th= e London IETF. There is both some short-term, relatively straightforward w= ork to be done to agree on the usage of SIP in these existing implementatio= ns. There may also be some very interesting work to be done on more advance= d approaches. First, some background: OpenBTS is an open source project started by the fo= unders of Range Networks to make a 'GSM system in a box', by implementing a= system which supports the air interface for GSM phones (Um) using a Softwa= re Defined Radio (SDR) for the RF. While the GSM & 3GPP defined air interf= ace to the phones is supported, OpenBTS diverges from these standards by im= mediately gatewaying the call to SIP. Each GSM or UMTS phone can then appe= ar on the Internet as a SIP endpoint. A local SIP switching decision is ma= de to route the call; Asterix, Freeswitch, Yate have been. The call is the= n sent to another local connected phone or to some other SIP service point = on the Internet. With this in place, because the air interface to the phones is supported wi= th no changes, standard GSM/UMTS phones can make calls to other phones on t= he same OpenBTS system or to any SIP endpoint on the Internet, and thence t= o the PSTN via any of the many SIP-PSTN gateways in operation. A fair question would be "Why do all this? What's wrong with GSM & 3GPP sy= stems?". One reason is that the OpenBTS approach allows very small, stand = alone systems, which efficiently connect GSM and UMTS phones to the Interne= t based SIP systems with a minimum of other systems. Certainly GSM/3GPP ba= sed micro cells exist, but are tied to the 3GPP 'Core' which is usually bey= ond the means of smaller users. OpenBTS aspires to be the simplest way for = a GSM/UMTS phone to make phone calls to the SIP & PSTN world. At least several hundred, and likely several thousand of these systems are = deployed already. Many are in labs, but others are production usage on all= continents. Universities find these systems very attractive for teaching = and researching: all the code from RF to Signaling is visible and may be ch= anged as desired. Furthermore, additional SDRs are popping up all the time. There are 3-4 se= parate SDR based systems that run OpenBTS and more are coming. Right now t= hey range from $2000 up, but it's easy to see them dropping to $500 or so t= his year; even Kickstarter campaigns are funding some of them. There's no = natural floor below that; adding GSM/UMTS to a home router and making it a = micro-cell running SIP to the Internet could conceivably be a $10 HW delta = and some more SW. Secondly, there are several countries that have unlicens= ed GSM band (Sweden, Netherlands, UK?) so some efforts are underway to do e= xactly that. When facing the Internet, OpenBTS is simply a SIP client. However, to assu= re interoperability, there may be value in standardized behavior, including= these issues: * Which elements of SIP are needed for this operation? * Should these be documented in a profile of SIP usage to be OpenBTS Ready? * Should ICE be recommended or possibly be required for operation behind NA= Ts? * What about BTS-BTS neighbor discovery * Use of SIP Re-invite for hand-over when a mobile phone moves from one BTS= to a neighbor * For somewhat different use cases: one could separate signaling from media= transport and thus might support WebRTC or other such systems. E.164 addr= esses are used in phones, but temporary numbers can be assigned as needed (= as done in Roaming) and not surfaced to the WebRTC level. * What Changes required for IPv6? * Required and recommended security provisions * Is IETF an appropriate forum for this, or should it be in 3GPP, or Sipfor= um.org, or a separate industry group formed? I look forward to discussion on the mailing list, and hopefully meeting and= discussing in London. Yours, Jim Forster Range Networks --_000_949EF20990823C4C85C18D59AA11AD8B12A6DEFR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
A good question for you to answer= would be as to which of the requirements of 3GPP TS 22.228 you would suppo= rt and which you would not support.
 
 
These requirements led to the dev= elopment of IMS as it is now, and the IMS architecture is as it is because = of those requirements.
 
How much are you trying to design= something new, versus integrating a P-CSCF and a BTS economically in the s= ame box, which network virtualisation will ultimately do?
 
regards
 
Keith Drage

From: dispatch [mailto:dispatch-bou= nces@ietf.org] On Behalf Of Jim Forster
Sent: 05 February 2014 06:40
To: dispatch@ietf.org
Subject: [dispatch] SIP and GSM/UMTS with OpenBTS

Dear DISPATCH group,

OpenBTS and OpenBSC are projects are combining GSM phones and SIP in n= ew and interesting ways.  I think there is some value to the community= in discussing these in the DISPATCH mailing list and having an related mee= ting at the London IETF.  There is both some short-term, relatively straightforward work to be done to agree on th= e usage of SIP in these existing implementations. There may also be some ve= ry interesting work to be done on more advanced approaches.

First, some background: OpenBTS is an open source project started by the fo= unders of Range Networks to make a 'GSM system in a box', by implementing a= system which supports the air interface for GSM phones (Um) using a Softwa= re Defined Radio (SDR) for the RF.  While the GSM & 3GPP defined air interface to the phones is supp= orted, OpenBTS diverges from these standards by immediately gatewaying the = call to SIP.  Each GSM or UMTS phone can then appear on the Internet a= s a SIP endpoint.  A local SIP switching decision is made to route the call; Asterix, Freeswitch, Yate have been.  The = call is then sent to another local connected phone or to some other SIP ser= vice point on the Internet.

With this in place, because the air interface to the phones is supported wi= th no changes, standard GSM/UMTS phones can make calls to other phones on t= he same OpenBTS system or to any SIP endpoint on the Internet, and thence t= o the PSTN via any of the many SIP-PSTN gateways in operation.

A fair question would be "Why do all this?  What's wrong with GSM= & 3GPP systems?".  One reason is that the OpenBTS approach a= llows very small, stand alone systems, which efficiently connect GSM and UM= TS phones to the Internet based SIP systems with a minimum of other systems.  Certainly GSM/3GPP based micro cells exist, but ar= e tied to the 3GPP 'Core' which is usually beyond the means of smaller user= s. OpenBTS aspires to be the simplest way for a GSM/UMTS phone to make phon= e calls to the SIP & PSTN world.

At least several hundred, and likely several thousand of these systems are = deployed already.  Many are in labs, but others are production usage o= n all continents.  Universities find these systems very attractive for= teaching and researching: all the code from RF to Signaling is visible and may be changed as desired.

Furthermore, additional SDRs are popping up all the time.  There are 3= -4 separate SDR based systems that run OpenBTS and more are coming.  R= ight now they range from $2000 up, but it's easy to see them dropping to $5= 00 or so this year; even Kickstarter campaigns are funding some of them.  There's no natural floor below that; addin= g GSM/UMTS to a home router and making it a micro-cell running SIP to the I= nternet could conceivably be a $10 HW delta and some more SW.  Secondl= y, there are several countries that have unlicensed GSM band (Sweden, Netherlands, UK?) so some efforts are underway to do exa= ctly that.

When facing the Internet, OpenBTS is simply a SIP client.  However, to= assure interoperability, there may be value in standardized behavior, incl= uding these issues:

* Which elements of SIP are needed for this operation?
* Should these be documented in a profile of SIP usage to be OpenBTS Ready?=
* Should ICE be recommended or possibly be required for operation behind NA= Ts?
* What about BTS-BTS neighbor discovery
* Use of SIP Re-invite for hand-over when a mobile phone moves from one BTS= to a neighbor
* For somewhat different use cases: one could separate signaling from media= transport and thus might support WebRTC or other such systems.  E.164= addresses are used in phones, but temporary numbers can be assigned as nee= ded (as done in Roaming) and not surfaced to the WebRTC level.
* What Changes required for IPv6?
* Required and recommended security provisions
* Is IETF an appropriate forum for this, or should it be in 3GPP, or <= a href=3D"http://Sipforum.org">Sipforum.org,  or a separate indust= ry group formed?

I look forward to discussion on the mailing list, and hopefully meetin= g and discussing in London.

Yours,

Jim Forster
Range Networks
--_000_949EF20990823C4C85C18D59AA11AD8B12A6DEFR712WXCHMBA11zeu_-- From jim.forster@rangenetworks.com Wed Feb 5 09:58:55 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B55A1A001A for ; Wed, 5 Feb 2014 09:58:55 -0800 (PST) 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=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IB8jrOp69w82 for ; Wed, 5 Feb 2014 09:58:53 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0149.outbound.protection.outlook.com [207.46.163.149]) by ietfa.amsl.com (Postfix) with ESMTP id 84FF41A010D for ; Wed, 5 Feb 2014 09:58:53 -0800 (PST) Received: from BL2PR03MB404.namprd03.prod.outlook.com (10.141.91.149) by BL2PR03MB403.namprd03.prod.outlook.com (10.141.91.148) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 17:58:51 +0000 Received: from BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) by BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) with mapi id 15.00.0868.013; Wed, 5 Feb 2014 17:58:50 +0000 From: Jim Forster To: Tim Panton Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmwfOAgAAEiYCAAAXSgIAAJw4A Date: Wed, 5 Feb 2014 17:58:50 +0000 Message-ID: References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <52F25265.5070108@alum.mit.edu> <00C069FD01E0324C9FFCADF539701DB3BBF2361F@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [114.69.245.154] x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(51704005)(199002)(189002)(66066001)(59766001)(77982001)(81542001)(81342001)(79102001)(65816001)(80022001)(76796001)(80976001)(49866001)(47736001)(50986001)(47976001)(63696002)(81816001)(83322001)(83716003)(76786001)(74706001)(46102001)(93516002)(93136001)(94316002)(87266001)(53806001)(56776001)(92566001)(92726001)(33656001)(94946001)(54316002)(54356001)(36756003)(74502001)(47446002)(90146001)(76482001)(2656002)(74876001)(82746002)(74662001)(81686001)(56816005)(87936001)(85852003)(83072002)(31966008)(4396001)(69226001)(86362001)(51856001)(85306002)(74366001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB403; H:BL2PR03MB404.namprd03.prod.outlook.com; CLIP:114.69.245.154; FPR:B7F4FCD5.AEB58485.4FDF3F78.6E1AB3D.201CD; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_6C31AD36-80C3-4D8A-93D3-52813EC950B3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: rangenetworks.com Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 17:58:55 -0000 --Apple-Mail=_6C31AD36-80C3-4D8A-93D3-52813EC950B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >> Is the end result of this improvements to the SIP or other IETF = protocols? >=20 > Speaking entirely for myself (as one does in the IETF) I=92d guess = that the outcome might > be some small improvements in SIP and other protocols (SDP or RTP = perhaps) due to the fact > that the usage is slightly out of the ordinary so may well trip an = edge case or something. >=20 >> Or, does this attempt to standardize an architecture? >=20 > I=92d like it to standardise an _interface_ so that multiple = architectures can interoperate. Agreed. >> Also, is there any IPR attached to this? >=20 > I=92ll let Jim answer that when he wakes up in India, but as an old = (but lapsed) IETF hand I=92m sure=20 > he=92s aware of the IPR rules. Yes, lapsed IETF hand and certainly older now, so I should review the = rules, etc. I certainly believe there's no lurking patent issues from = Range Networks. I'll double check on that as well. -- Jim --Apple-Mail=_6C31AD36-80C3-4D8A-93D3-52813EC950B3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJS8nvYAAoJECAtT58A/2SK+YsH/ihCxghL+Dylkxg0/sv2UyZL 8UctS/eJkGXe0ukL/Rj9H+RZmDmbzI2Li3uGwHJb7RA5LtJJwUASuqptov3XfSUU +PrJNwpznIZcr77s8J1TkTbw/Kz/8byHh3H2KCDqO5MsgWBRSp++5nOR0PqZlhgp ZnVERu/avEeDJUbN04PK382Cxtr/S6g60F4fbY+x8BI6o6ORt2XdSiEkv60kHE4Q boRuFNTyTc9mZB/NA40aSyGT0sPg+u91NJNsvurJZ8OlsoNcQxHcSgNciEo8bzOT hwrXULAI3ClaxOiPKdidPg2qxgt5oJ1MuWfleais1WDEFIkJVnk0NNd8HBZd8k0= =sUIX -----END PGP SIGNATURE----- --Apple-Mail=_6C31AD36-80C3-4D8A-93D3-52813EC950B3-- From jim.forster@rangenetworks.com Wed Feb 5 10:16:09 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 297D11A01A9 for ; Wed, 5 Feb 2014 10:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZVjc-YjBNPd for ; Wed, 5 Feb 2014 10:16:07 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id CA59D1A011B for ; Wed, 5 Feb 2014 10:16:06 -0800 (PST) Received: from BL2PR03MB404.namprd03.prod.outlook.com (10.141.91.149) by BL2PR03MB402.namprd03.prod.outlook.com (10.141.91.146) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 18:16:04 +0000 Received: from BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) by BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) with mapi id 15.00.0868.013; Wed, 5 Feb 2014 18:16:03 +0000 From: Jim Forster To: "DRAGE, Keith (Keith)" Thread-Topic: SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQA= Date: Wed, 5 Feb 2014 18:16:03 +0000 Message-ID: <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [114.69.245.154] x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(199002)(189002)(53474002)(2656002)(81542001)(80976001)(63696002)(93136001)(66066001)(81342001)(92726001)(59766001)(77982001)(47976001)(80022001)(47736001)(74662001)(74502001)(49866001)(65816001)(83322001)(31966008)(87266001)(81686001)(4396001)(19580395003)(54356001)(79102001)(15202345003)(74366001)(76482001)(76796001)(51856001)(94316002)(46102001)(50986001)(15975445006)(33656001)(93516002)(83716003)(86362001)(56816005)(74876001)(90146001)(36756003)(92566001)(81816001)(53806001)(56776001)(82746002)(47446002)(76786001)(87936001)(69226001)(74706001)(94946001)(16236675002)(83072002)(54316002)(85306002)(85852003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB402; H:BL2PR03MB404.namprd03.prod.outlook.com; CLIP:114.69.245.154; FPR:8E6BD195.A4D28CE5.BA679685.14D0400D.202DF; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_F5E73F63-A330-4254-B422-387646BFF3B9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: rangenetworks.com Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 18:16:09 -0000 --Apple-Mail=_F5E73F63-A330-4254-B422-387646BFF3B9 Content-Type: multipart/alternative; boundary="Apple-Mail=_465AB595-ABDC-41A5-BE02-E94CD85C7CF4" --Apple-Mail=_465AB595-ABDC-41A5-BE02-E94CD85C7CF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 > A good question for you to answer would be as to which of the = requirements of 3GPP TS 22.228 you would support and which you would not = support. > =20 > http://www.3gpp.org/DynaReport/22228.htm Wow, that would be quite a job! Well, I guess it should be looked at. > =20 > These requirements led to the development of IMS as it is now, and the = IMS architecture is as it is because of those requirements. Yes, but it starts out with the title: > Service requirements for the Internet Protocol (IP) multimedia core = network subsystem (IMS); Stage 1 Offhand, I don't immediately see the need to have such a thing as an = "Internet Protocol (IP) multimedia core network subsystem". OK, = certainly a large community (3GPP) does, which is fine and I use that = stuff all the time on my phone and so am happy/grateful that it works, = but does the rest of the Internet community accept those requirements = for other things? What's the boundary for those requirements? Are they = a part of some RTAI or other IETF spec? I think lots of interesting = multimedia activity and specs happen without conformance to those = particular requirements. I'll readily admit to a lot of ignorance and = naivet=E9, but it doesn't seem SIP or WebRTC aspires to support those = requirements. To some degree, OpenBTS is just trying to connect a bunch = of nice phones with an OK air interface, to the Internet architecture, = which another large set of people seem to like. OK, I'll duck while the missiles fly overhead :-) . > How much are you trying to design something new, versus integrating a = P-CSCF and a BTS economically in the same box, which network = virtualisation will ultimately do? Umm, I don't know what a P-CSCF is, so I'll have to look into it, or = please help me/us. -- Jim --Apple-Mail=_465AB595-ABDC-41A5-BE02-E94CD85C7CF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
A good question for you to answer would be as to which of the = requirements of 3GPP TS 22.228 you would support and which you would not = support.
 
http://www.3gpp.org/Dyna= Report/22228.htm

Wow, = that would be quite a job!  Well, I guess it should be looked = at.
 
These requirements led to the development of IMS as it is = now, and the IMS architecture is as it is because of those = requirements.

Yes, but it = starts out with the title:

Service requirements for the Internet Protocol (IP) = multimedia core network subsystem (IMS); Stage = 1

Offhand, I don't immediately see = the need to have such a thing as an "Internet Protocol (IP) multimedia = core network subsystem". OK, certainly a large community (3GPP) does, = which is fine and I use that stuff all the time on my phone and so am = happy/grateful that it works, but does the rest of the Internet = community accept those requirements for other things? What's the = boundary for those requirements?  Are they a part of some RTAI or = other IETF spec?  I think lots of interesting multimedia activity = and specs happen without conformance to those particular requirements. =  I'll readily admit to a lot of ignorance and naivet=E9, but it = doesn't seem SIP or WebRTC aspires to support those requirements. =  To some degree, OpenBTS is just trying to connect a bunch of nice = phones with an OK air interface, to the Internet architecture, which = another large set of people seem to like.

OK, = I'll duck while the missiles fly overhead = :-)
.
 How much are you trying to design = something new, versus integrating a P-CSCF and a BTS economically in the = same box, which network virtualisation will ultimately = do?

Umm, I don't  know what = a P-CSCF is, so I'll have to look into it, or please help = me/us.

 -- Jim

= --Apple-Mail=_465AB595-ABDC-41A5-BE02-E94CD85C7CF4-- --Apple-Mail=_F5E73F63-A330-4254-B422-387646BFF3B9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJS8n/cAAoJECAtT58A/2SKOmgIALaAU8oPa4OSkJ2QnMN/5TzC arAHa2mrb9/eSV0hKInop3IgNw5w1WG0moDmxUH5aKBER7CJNWzwfy7kJ8OKApCc bvBZN16Kmwvxb02pjynb8RUIpPPturjbXg7QuZfiHzXUfNkYrapfAmLVXfF+BYjM uuXZj9z6WI4yNxfo7FZWXc1y52DI/4LMxnuR15K0mrqT8yGHq9ZBmM/GZws9cjt4 UZwCy3QArwhjTl2hR9RFmXvsltrXO7vMQ9AsFV5gDuK7bfNXM7wjH24V4t9togab 2prD8+Y6SJPhSehW8ojReImFOjsS8eaVObZIJPZpDM3kwMmNlBFzHI11VBIzZ/g= =/Obc -----END PGP SIGNATURE----- --Apple-Mail=_F5E73F63-A330-4254-B422-387646BFF3B9-- From harvind@rangenetworks.com Wed Feb 5 11:00:47 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A851A0159 for ; Wed, 5 Feb 2014 11:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwR3sWnE6q_a for ; Wed, 5 Feb 2014 11:00:45 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 878FA1A0138 for ; Wed, 5 Feb 2014 11:00:45 -0800 (PST) Received: from BN1PR03MB201.namprd03.prod.outlook.com (10.255.200.141) by DM2PR03MB414.namprd03.prod.outlook.com (10.141.84.145) with Microsoft SMTP Server (TLS) id 15.0.868.8; Wed, 5 Feb 2014 19:00:42 +0000 Received: from BN1PR03MB201.namprd03.prod.outlook.com ([169.254.11.42]) by BN1PR03MB201.namprd03.prod.outlook.com ([169.254.11.42]) with mapi id 15.00.0868.013; Wed, 5 Feb 2014 19:00:41 +0000 From: Harvind Samra To: Jim Forster Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAA== Date: Wed, 5 Feb 2014 19:00:40 +0000 Message-ID: <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> In-Reply-To: <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [76.126.41.69] x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(377454003)(24454002)(199002)(189002)(53474002)(31966008)(80976001)(83322001)(19580405001)(50986001)(19580395003)(49866001)(47736001)(47976001)(33656001)(4396001)(81542001)(74502001)(74662001)(16601075003)(81342001)(74366001)(95416001)(69226001)(77096001)(76786001)(76796001)(15202345003)(47446002)(36756003)(92726001)(74876001)(63696002)(93516002)(87266001)(56816005)(81686001)(90146001)(79102001)(66066001)(16236675002)(94316002)(65816001)(93136001)(92566001)(80022001)(15975445006)(82746002)(81816001)(56776001)(87936001)(83716003)(85852003)(51856001)(74706001)(54356001)(85306002)(54316002)(53806001)(77982001)(76482001)(46102001)(83072002)(86362001)(94946001)(2656002)(59766001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR03MB414; H:BN1PR03MB201.namprd03.prod.outlook.com; CLIP:76.126.41.69; FPR:8E6BD195.A6D2BEE5.B2E39685.14D041CD.203B1; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_7723B448642F413889DD379ACC7FA593rangenetworkscom_" MIME-Version: 1.0 X-OriginatorOrg: rangenetworks.com Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 19:02:47 -0000 --_000_7723B448642F413889DD379ACC7FA593rangenetworkscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I=92ve run into very few mobile folks who think IMS was a good idea. One o= f the chief reasons is that SIP, upon which IMS was developed, is a verbose= /chatty protocol that occupies way too much bandwidth. Some of the alternatives may be webRTC, DIAMETER=85 On Feb 5, 2014, at 10:16 AM, Jim Forster > wrote: A good question for you to answer would be as to which of the requirements = of 3GPP TS 22.228 you would support and which you would not support. http://www.3gpp.org/DynaReport/22228.htm Wow, that would be quite a job! Well, I guess it should be looked at. These requirements led to the development of IMS as it is now, and the IMS = architecture is as it is because of those requirements. Yes, but it starts out with the title: Service requirements for the Internet Protocol (IP) multimedia core network= subsystem (IMS); Stage 1 Offhand, I don't immediately see the need to have such a thing as an "Inter= net Protocol (IP) multimedia core network subsystem". OK, certainly a large= community (3GPP) does, which is fine and I use that stuff all the time on = my phone and so am happy/grateful that it works, but does the rest of the I= nternet community accept those requirements for other things? What's the bo= undary for those requirements? Are they a part of some RTAI or other IETF = spec? I think lots of interesting multimedia activity and specs happen wit= hout conformance to those particular requirements. I'll readily admit to a= lot of ignorance and naivet=E9, but it doesn't seem SIP or WebRTC aspires = to support those requirements. To some degree, OpenBTS is just trying to c= onnect a bunch of nice phones with an OK air interface, to the Internet arc= hitecture, which another large set of people seem to like. OK, I'll duck while the missiles fly overhead :-) . How much are you trying to design something new, versus integrating a P-CS= CF and a BTS economically in the same box, which network virtualisation wil= l ultimately do? Umm, I don't know what a P-CSCF is, so I'll have to look into it, or pleas= e help me/us. -- Jim _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch Harvind Samra Founder, CTO Range Networks San Francisco, CA ____________________________________________ Cellular networks made simple and affordable. http://www.rangenetworks.com ____________________________________________ --_000_7723B448642F413889DD379ACC7FA593rangenetworkscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0B0FE651D8558C419C6FC1C4CD6C8E91@namprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable I=92ve run into very few mobile folks who think IMS was a good idea.  = One of the chief reasons is that SIP, upon which IMS was developed, is a ve= rbose/chatty protocol that occupies way too much bandwidth.  

Some of the alternatives may be webRTC, DIAMETER=85

On Feb 5, 2014, at 10:16 AM, Jim Forster <jim.forster@rangenetworks.com> wrote:


A good question for you to answer would be as to which of the req= uirements of 3GPP TS 22.228 you would support and which you would not suppo= rt.
 

Wow, that would be quite a job!  Well, I guess it should be looked at.=
 
These requirements led to the development of IMS as it is now, an= d the IMS architecture is as it is because of those requirements.

Yes, but it starts out with the title:

Service requirements for the Internet Protocol (I= P) multimedia core network subsystem (IMS); Stage 1

Offhand, I don't immediately see the need to have such a thing as an &= quot;Internet Protocol (IP) multimedia core network subsystem". OK, ce= rtainly a large community (3GPP) does, which is fine and I use that stuff a= ll the time on my phone and so am happy/grateful that it works, but does the rest of the Internet community accept those re= quirements for other things? What's the boundary for those requirements? &n= bsp;Are they a part of some RTAI or other IETF spec?  I think lots of = interesting multimedia activity and specs happen without conformance to those particular requirements.  I'll re= adily admit to a lot of ignorance and naivet=E9, but it doesn't seem SIP or= WebRTC aspires to support those requirements.  To some degree, OpenBT= S is just trying to connect a bunch of nice phones with an OK air interface, to the Internet architecture, which anoth= er large set of people seem to like.

OK, I'll duck while the missiles fly overhead :-)
.
 How much are you trying to design something= new, versus integrating a P-CSCF and a BTS economically in the same box, which network virtualisation will ultimately do?

Umm, I don't  know what a P-CSCF is, so I'll have to look into it= , or please help me/us.

 -- Jim

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

Harvind Samra
Founder, CTO
Range Networks
San Francisco, CA  
____________________________________________

Cellular networks made simple and affo= rdable.  
______________________________________= ______




--_000_7723B448642F413889DD379ACC7FA593rangenetworkscom_-- From Raju.Makaraju@alcatel-lucent.com Wed Feb 5 12:13:40 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469C11A0124 for ; Wed, 5 Feb 2014 12:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjMRNINqgowW for ; Wed, 5 Feb 2014 12:13:37 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id E3E671A00A7 for ; Wed, 5 Feb 2014 12:13:36 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s15KDYxS014658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 14:13:34 -0600 (CST) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s15KDWkQ007742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 15:13:34 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.02.0247.003; Wed, 5 Feb 2014 15:13:32 -0500 From: "Makaraju, Maridi Raju (Raju)" To: Harvind Samra , Jim Forster Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQ Date: Wed, 5 Feb 2014 20:13:32 +0000 Message-ID: References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> In-Reply-To: <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17826DFCD495US70UWXCHMBA02z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 20:13:40 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17826DFCD495US70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've run into very few mobile folks who think IMS was a good idea. One of = the chief reasons is that SIP, upon which IMS was developed, is a verbose/c= hatty protocol that occupies way too much bandwidth. [Raju] I am not sure what these "mobile folks" think about alternatives lik= e XMPP?! :) Not knowing XMPP I think it is complicated! Some of the alternatives may be webRTC, DIAMETER... [Raju] WebRTC is NOT a signaling protocol!! Neither Diameter is!! WebRTC on= ly deals with bearer representation (via SDP) and transport while diameter = is an "authentication, authorization, and accounting" protocol and not suit= able for signaling. That's pretty much leaves us with, whether we like it o= r not, SIP. Trying to come up with another protocol (and architecture) is l= ike reinventing the SIP/IMS-wheel in another form, which may not please the= same folks who don't like IMS/SIP. We can surely debate on chatty nature of SIP, which I really don't think th= at chatty. SIP does many things like routing, signaling NAT traversal facil= itation, topology hiding, SDP transport etc. I believe, the SDP is the one= which makes it look "chatty", rest of them are headers just like HTTP head= ers (they are even designed after HTTP/SMTP). Btw, though it is not signaling, WebRTC is far from simple!! Basically, "it= 's the devil you know vs. the angel you don't now!"!! :) -Raju --_000_E1FE4C082A89A246A11D7F32A95A17826DFCD495US70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 <= /p>

 

I’ve run into very few mobile folks who think = IMS was a good idea.  One of the chief reasons is that SIP, upon which= IMS was developed, is a verbose/chatty protocol that occupies way too much= bandwidth.  

[Raju] I am not sur= e what these “mobile folks” think about alternatives like XMPP?= ! J Not knowin= g XMPP I think it is complicated!

 

Some of the alternatives may be webRTC, DIAMETERR= 30;

 

[Raju] WebRTC is NO= T a signaling protocol!! Neither Diameter is!! WebRTC only deals with beare= r representation (via SDP) and transport while diameter is an “authentication, authorization, and accounting“ protocol= and not suitable for signaling. That’s pretty much leaves us with, w= hether we like it or not, SIP. Trying to come up with another protocol (and= architecture) is like reinventing the SIP/IMS-wheel in another form, which may not please the same folks who don’t like = IMS/SIP.

We can surely debat= e on chatty nature of SIP, which I really don’t think that chatty. SI= P does many things like routing, signaling NAT traversal facilitation, topology hiding, SDP transport etc.  I believe, the SDP is the one wh= ich makes it look “chatty”, rest of them are headers just like = HTTP headers (they are even designed after HTTP/SMTP).

Btw, though it is n= ot signaling, WebRTC is far from simple!! Basically, “it’s the = devil you know vs. the angel you don’t now!”!! J=

 

-Raju

--_000_E1FE4C082A89A246A11D7F32A95A17826DFCD495US70UWXCHMBA02z_-- From keith.drage@alcatel-lucent.com Wed Feb 5 13:43:18 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596B71A0129 for ; Wed, 5 Feb 2014 13:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iALM9NcjtftA for ; Wed, 5 Feb 2014 13:43:15 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 43AA21A002B for ; Wed, 5 Feb 2014 13:43:15 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s15LhAPG022939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 15:43:11 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s15Lh9Nv028834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 22:43:09 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 5 Feb 2014 22:43:08 +0100 From: "DRAGE, Keith (Keith)" To: Jim Forster Thread-Topic: SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAABBgYA== Date: Wed, 5 Feb 2014 21:43:08 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B12ACA2@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> In-Reply-To: <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B12ACA2FR712WXCHMBA11zeu_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 21:43:18 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B12ACA2FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The requirements cover things like whether you support subscriptions, suppo= rt roaming between operators, support charging of sessions as opposed to ju= st charging for bandwidth or whatever. That is what you need to identify in= order to design a system. Core network is a 3GPP definition. It is all equipment that is not part of = the access network (i.e. not GERAN or UTRAN or E-UTRAN). For what you are t= alking about, the access network provides an means of communicating using I= P, nothing more. So you need a core network. 3GPP may not define it, but as= soon as you say something is an activity above IP, a call/session control = entity of some sort, that is a core network. The P-CSCF is an inbound and outbound proxy. It also provides an endpoint f= or security mechanisms. It also provides the endpoint for policy control fo= r the access network - with restricted bandwidth you may well need that pol= icy control. The definitions are in 3GPP TS 23.228. http://www.3gpp.org/DynaReport/23228.htm but you can find a summary (incomplete) in https://datatracker.ietf.org/doc/rfc4083/ regards Keith ________________________________ From: Jim Forster [mailto:jim.forster@rangenetworks.com] Sent: 05 February 2014 18:16 To: DRAGE, Keith (Keith) Cc: dispatch@ietf.org Subject: Re: SIP and GSM/UMTS with OpenBTS A good question for you to answer would be as to which of the requirements = of 3GPP TS 22.228 you would support and which you would not support. http://www.3gpp.org/DynaReport/22228.htm Wow, that would be quite a job! Well, I guess it should be looked at. These requirements led to the development of IMS as it is now, and the IMS = architecture is as it is because of those requirements. Yes, but it starts out with the title: Service requirements for the Internet Protocol (IP) multimedia core network= subsystem (IMS); Stage 1 Offhand, I don't immediately see the need to have such a thing as an "Inter= net Protocol (IP) multimedia core network subsystem". OK, certainly a large= community (3GPP) does, which is fine and I use that stuff all the time on = my phone and so am happy/grateful that it works, but does the rest of the I= nternet community accept those requirements for other things? What's the bo= undary for those requirements? Are they a part of some RTAI or other IETF = spec? I think lots of interesting multimedia activity and specs happen wit= hout conformance to those particular requirements. I'll readily admit to a= lot of ignorance and naivet=E9, but it doesn't seem SIP or WebRTC aspires = to support those requirements. To some degree, OpenBTS is just trying to c= onnect a bunch of nice phones with an OK air interface, to the Internet arc= hitecture, which another large set of people seem to like. OK, I'll duck while the missiles fly overhead :-) . How much are you trying to design something new, versus integrating a P-CS= CF and a BTS economically in the same box, which network virtualisation wil= l ultimately do? Umm, I don't know what a P-CSCF is, so I'll have to look into it, or pleas= e help me/us. -- Jim --_000_949EF20990823C4C85C18D59AA11AD8B12ACA2FR712WXCHMBA11zeu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The requirements cover things lik= e whether you support subscriptions, support roaming between operators, sup= port charging of sessions as opposed to just charging for bandwidth or whatever. That is what you need to identify in o= rder to design a system.
 
Core network is a 3GPP definition= . It is all equipment that is not part of the access network (i.e. not GERA= N or UTRAN or E-UTRAN). For what you are talking about, the access network provides an means of communicating using IP,&nbs= p;nothing more. So you need a core network. 3GPP may not define it, bu= t as soon as you say something is an activity above IP, a call/session= control entity of some sort, that is a core network.
 
The P-CSCF is an inbound and outb= ound proxy. It also provides an endpoint for security mechanisms. It also p= rovides the endpoint for policy control for the access network - with restricted bandwidth you may well need that poli= cy control. The definitions are in 3GPP TS 23.228.
 
http://www.3gpp.org/DynaRepor= t/23228.htm
 
but you can find a summary (in= complete) in
 
 
regards
 
Keith

From: Jim Forster [mailto:jim.forst= er@rangenetworks.com]
Sent: 05 February 2014 18:16
To: DRAGE, Keith (Keith)
Cc: dispatch@ietf.org
Subject: Re: SIP and GSM/UMTS with OpenBTS


A good question for you to answer would be as to which of the req= uirements of 3GPP TS 22.228 you would support and which you would not suppo= rt.
 

Wow, that would be quite a job!  Well, I guess it should be looked at.=
 
These requirements led to the development of IMS as it is now, an= d the IMS architecture is as it is because of those requirements.

Yes, but it starts out with the title:

Service requirements for the Internet Protocol (I= P) multimedia core network subsystem (IMS); Stage 1

Offhand, I don't immediately see the need to have such a thing as an &= quot;Internet Protocol (IP) multimedia core network subsystem". OK, ce= rtainly a large community (3GPP) does, which is fine and I use that stuff a= ll the time on my phone and so am happy/grateful that it works, but does the rest of the Internet community accept those re= quirements for other things? What's the boundary for those requirements? &n= bsp;Are they a part of some RTAI or other IETF spec?  I think lots of = interesting multimedia activity and specs happen without conformance to those particular requirements.  I'll re= adily admit to a lot of ignorance and naivet=E9, but it doesn't seem SIP or= WebRTC aspires to support those requirements.  To some degree, OpenBT= S is just trying to connect a bunch of nice phones with an OK air interface, to the Internet architecture, which anoth= er large set of people seem to like.

OK, I'll duck while the missiles fly overhead :-)
.
 How much are you trying to design something ne= w, versus integrating a P-CSCF and a BTS economically in the same box, which network virtualisation will ultimately do?

Umm, I don't  know what a P-CSCF is, so I'll have to look into it= , or please help me/us.

 -- Jim

--_000_949EF20990823C4C85C18D59AA11AD8B12ACA2FR712WXCHMBA11zeu_-- From keith.drage@alcatel-lucent.com Wed Feb 5 13:43:19 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD871A0129 for ; Wed, 5 Feb 2014 13:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kELgTlovlcxP for ; Wed, 5 Feb 2014 13:43:15 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 6C55D1A0100 for ; Wed, 5 Feb 2014 13:43:15 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s15LhA8F022938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 15:43:11 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s15Lh96V028839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 22:43:09 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 5 Feb 2014 22:43:09 +0100 From: "DRAGE, Keith (Keith)" To: Harvind Samra , Jim Forster Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAACbRQ Date: Wed, 5 Feb 2014 21:43:09 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B12ACA7@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> In-Reply-To: <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B12ACA7FR712WXCHMBA11zeu_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 21:43:19 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B12ACA7FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe it was someone from rangenetworks that said: "OpenBTS diverges from these standards by immediately gatewaying the call t= o SIP. Each GSM or UMTS phone can then appear on the Internet as a SIP end= point. " If you meant something else, then perhaps... But in any case, the questions I asked about requirements apply to any prot= ocol. The key parts of 3GPP TS 22.228 were written before SIP was identifie= d as a protocol to support the requirements. amd H.323 was still in the fra= me. regards Keith Drage ________________________________ From: Harvind Samra [mailto:harvind@rangenetworks.com] Sent: 05 February 2014 19:01 To: Jim Forster Cc: DRAGE, Keith (Keith); dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS I've run into very few mobile folks who think IMS was a good idea. One of = the chief reasons is that SIP, upon which IMS was developed, is a verbose/c= hatty protocol that occupies way too much bandwidth. Some of the alternatives may be webRTC, DIAMETER... On Feb 5, 2014, at 10:16 AM, Jim Forster > wrote: A good question for you to answer would be as to which of the requirements = of 3GPP TS 22.228 you would support and which you would not support. http://www.3gpp.org/DynaReport/22228.htm Wow, that would be quite a job! Well, I guess it should be looked at. These requirements led to the development of IMS as it is now, and the IMS = architecture is as it is because of those requirements. Yes, but it starts out with the title: Service requirements for the Internet Protocol (IP) multimedia core network= subsystem (IMS); Stage 1 Offhand, I don't immediately see the need to have such a thing as an "Inter= net Protocol (IP) multimedia core network subsystem". OK, certainly a large= community (3GPP) does, which is fine and I use that stuff all the time on = my phone and so am happy/grateful that it works, but does the rest of the I= nternet community accept those requirements for other things? What's the bo= undary for those requirements? Are they a part of some RTAI or other IETF = spec? I think lots of interesting multimedia activity and specs happen wit= hout conformance to those particular requirements. I'll readily admit to a= lot of ignorance and naivet=E9, but it doesn't seem SIP or WebRTC aspires = to support those requirements. To some degree, OpenBTS is just trying to c= onnect a bunch of nice phones with an OK air interface, to the Internet arc= hitecture, which another large set of people seem to like. OK, I'll duck while the missiles fly overhead :-) . How much are you trying to design something new, versus integrating a P-CS= CF and a BTS economically in the same box, which network virtualisation wil= l ultimately do? Umm, I don't know what a P-CSCF is, so I'll have to look into it, or pleas= e help me/us. -- Jim _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch Harvind Samra Founder, CTO Range Networks San Francisco, CA ____________________________________________ Cellular networks made simple and affordable. http://www.rangenetworks.com ____________________________________________ --_000_949EF20990823C4C85C18D59AA11AD8B12ACA7FR712WXCHMBA11zeu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I believe it was someone from ran= genetworks that said:
 
"OpenBTS diverges from these standards by i= mmediately gatewaying the call to SIP.  Each GSM or UMTS phone can then appear on the Internet as a SIP endpoint. "
 
If you meant something else, then perhaps...
 
But in any case, the questions I asked about requirements ap= ply to any protocol. The key parts of 3GPP TS 22.228 were written before SI= P was identified as a protocol to support the requirements. amd H.323 was still in the frame.
 
regards
 
Keith Drage
 

From: Harvind Samra [mailto:harvind= @rangenetworks.com]
Sent: 05 February 2014 19:01
To: Jim Forster
Cc: DRAGE, Keith (Keith); dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

I’ve run into very few mobile folks who think IMS was a good idea. &n= bsp;One of the chief reasons is that SIP, upon which IMS was developed, is = a verbose/chatty protocol that occupies way too much bandwidth.  

Some of the alternatives may be webRTC, DIAMETER…

On Feb 5, 2014, at 10:16 AM, Jim Forster <jim.forster@rangenetworks.com> wrote:


A good question for you to answer would be as to which of the req= uirements of 3GPP TS 22.228 you would support and which you would not suppo= rt.
 

Wow, that would be quite a job!  Well, I guess it should be looked at.=
 
These requirements led to the development of IMS as it is now, an= d the IMS architecture is as it is because of those requirements.

Yes, but it starts out with the title:

Service requirements for the Internet Protocol (I= P) multimedia core network subsystem (IMS); Stage 1

Offhand, I don't immediately see the need to have such a thing as an &= quot;Internet Protocol (IP) multimedia core network subsystem". OK, ce= rtainly a large community (3GPP) does, which is fine and I use that stuff a= ll the time on my phone and so am happy/grateful that it works, but does the rest of the Internet community accept those re= quirements for other things? What's the boundary for those requirements? &n= bsp;Are they a part of some RTAI or other IETF spec?  I think lots of = interesting multimedia activity and specs happen without conformance to those particular requirements.  I'll re= adily admit to a lot of ignorance and naivet=E9, but it doesn't seem SIP or= WebRTC aspires to support those requirements.  To some degree, OpenBT= S is just trying to connect a bunch of nice phones with an OK air interface, to the Internet architecture, which anoth= er large set of people seem to like.

OK, I'll duck while the missiles fly overhead :-)
.
 How much are you trying to design something ne= w, versus integrating a P-CSCF and a BTS economically in the same box, which network virtualisation will ultimately do?

Umm, I don't  know what a P-CSCF is, so I'll have to look into it= , or please help me/us.

 -- Jim

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

Harvind Samra
Founder, CTO
Range Networks
San Francisco, CA  
____________________________________________

Cellular networks made simple and afford= able.  
________________________________________= ____




--_000_949EF20990823C4C85C18D59AA11AD8B12ACA7FR712WXCHMBA11zeu_-- From a.james.winterbottom@gmail.com Wed Feb 5 14:21:48 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA2A1A0209 for ; Wed, 5 Feb 2014 14:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZhysaEvcDn4 for ; Wed, 5 Feb 2014 14:21:41 -0800 (PST) Received: from mail-pb0-x230.google.com (mail-pb0-x230.google.com [IPv6:2607:f8b0:400e:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id B64631A012F for ; Wed, 5 Feb 2014 14:21:41 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id rr13so938265pbb.21 for ; Wed, 05 Feb 2014 14:21:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LiyYtYBP+XbbpZjs2dATXqufE56r6NGgktw03kguNEM=; b=fSW2rTpo66+ptDMxeXiQQI/TbO8j59GIlK7nLynoZLSbRug4LI9vHEpbYi4SuzI9Ms u0u/4uh9B4fqEgEEKkHvTqHuvJPnGnn/Qn3UzpJKp6BzQE2Q8idDKXM5bVLCVlludMmy 83KTPXfC79Z+F23aubt0+8OUQHizeALu3mDkMpCVYqNPxUJ13aMMkm66Izl9k3IKEgH9 Dvov6c/VZD6YmaOhDl7o2Pb+Ow4cxtWeCmpZVMgm9+1jza2b1LL4oSSHSYZmCLZ9PME5 KyaPAaF3P9qY1FA+Kxp5YXwFh5D/rTX+JiNLJr20o5uyLvKzw0FwxUqsvsFdNqBGcVTQ P2Pw== X-Received: by 10.68.133.229 with SMTP id pf5mr5868256pbb.115.1391638900965; Wed, 05 Feb 2014 14:21:40 -0800 (PST) Received: from [192.168.1.7] (124-149-100-27.dyn.iinet.net.au. [124.149.100.27]) by mx.google.com with ESMTPSA id eb5sm205369020pad.22.2014.02.05.14.21.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Feb 2014 14:21:40 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D1B2A9D1-1042-4126-A429-39EB12785746" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: James Winterbottom In-Reply-To: Date: Thu, 6 Feb 2014 09:21:35 +1100 Message-Id: References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> To: "Makaraju, Maridi Raju (Raju)" X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 22:21:49 -0000 --Apple-Mail=_D1B2A9D1-1042-4126-A429-39EB12785746 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 DIAMETER is used to carry signalling information through out IMS. On 6 Feb 2014, at 7:13 am, Makaraju, Maridi Raju (Raju) = wrote: >=20 > =20 > [Raju] WebRTC is NOT a signaling protocol!! Neither Diameter is!! = WebRTC only deals with bearer representation (via SDP) and transport = while diameter is an =93authentication, authorization, and accounting=93 = protocol and not suitable for signaling. That=92s pretty much leaves us = with, whether we like it or not, SIP. Trying to come up with another = protocol (and architecture) is like reinventing the SIP/IMS-wheel in = another form, which may not please the same folks who don=92t like = IMS/SIP. > We can surely debate on chatty nature of SIP, which I really don=92t = think that chatty. SIP does many things like routing, signaling NAT = traversal facilitation, topology hiding, SDP transport etc. I believe, = the SDP is the one which makes it look =93chatty=94, rest of them are = headers just like HTTP headers (they are even designed after HTTP/SMTP). > Btw, though it is not signaling, WebRTC is far from simple!! = Basically, =93it=92s the devil you know vs. the angel you don=92t = now!=94!! J > =20 --Apple-Mail=_D1B2A9D1-1042-4126-A429-39EB12785746 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 DIAMETER is used to carry signalling information = through out IMS.


On 6 Feb 2014, at 7:13 = am, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-luc= ent.com> wrote:


 
[Raju] WebRTC is NOT a = signaling protocol!! Neither Diameter is!! WebRTC only deals with bearer = representation (via SDP) and transport while diameter is an = =93authentication, authorization, and accounting=93 protocol and not = suitable for signaling. That=92s pretty much leaves us with, whether we = like it or not, SIP. Trying to come up with another protocol (and = architecture) is like reinventing the SIP/IMS-wheel in another form, = which may not please the same folks who don=92t like = IMS/SIP.
We can surely debate on chatty = nature of SIP, which I really don=92t think that chatty. SIP does many = things like routing, signaling NAT traversal facilitation, topology = hiding, SDP transport etc.  I believe, the SDP is the one which = makes it look =93chatty=94, rest of them are headers just like HTTP = headers (they are even designed after = HTTP/SMTP).
Btw, though it is not signaling, = WebRTC is far from simple!! Basically, =93it=92s the devil you know vs. = the angel you don=92t now!=94!! J
 

= --Apple-Mail=_D1B2A9D1-1042-4126-A429-39EB12785746-- From Raju.Makaraju@alcatel-lucent.com Wed Feb 5 14:31:37 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BA21A025B for ; Wed, 5 Feb 2014 14:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mL03YJRg6D9c for ; Wed, 5 Feb 2014 14:31:35 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 20EED1A01FC for ; Wed, 5 Feb 2014 14:31:35 -0800 (PST) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s15MVV2k016977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 16:31:31 -0600 (CST) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s15MVUmr031770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Feb 2014 17:31:30 -0500 Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Wed, 5 Feb 2014 17:31:30 -0500 From: "Makaraju, Maridi Raju (Raju)" To: James Winterbottom Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgACK0YD//63rQA== Date: Wed, 5 Feb 2014 22:31:30 +0000 Message-ID: References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17826DFCD852US70UWXCHMBA02z_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 22:31:37 -0000 --_000_E1FE4C082A89A246A11D7F32A95A17826DFCD852US70UWXCHMBA02z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DIAMETER is used to carry signalling information through out IMS. [Raju] Which interface? and what kind of signaling? To the best of my knowl= edge, diameter is only used for "authentication, authorization, and account= ing". The Rx diameter interface used between P-CSCF and PCRF is not really = call processing related signaling but rather used for "authorization" of th= e media flow. -Raju --_000_E1FE4C082A89A246A11D7F32A95A17826DFCD852US70UWXCHMBA02z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

DIAMETER is used to carry signalling information thr= ough out IMS.

[Raju] Which interf= ace? and what kind of signaling? To the best of my knowledge, diameter is o= nly used for “authentication, auth= orization, and accounting“. The Rx diameter interface used between P-= CSCF and PCRF is not really call processing related signaling but rather used for “authorization” of the media flow.<= /span>

 

-Raju

--_000_E1FE4C082A89A246A11D7F32A95A17826DFCD852US70UWXCHMBA02z_-- From a.james.winterbottom@gmail.com Wed Feb 5 14:32:44 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E78921A01FC for ; Wed, 5 Feb 2014 14:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7o2t3XWB0MK for ; Wed, 5 Feb 2014 14:32:43 -0800 (PST) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 313821A012C for ; Wed, 5 Feb 2014 14:32:43 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id up15so957954pbc.0 for ; Wed, 05 Feb 2014 14:32:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=RNBHbJSiG7ex263qauhd73hS8kWGCrQOIfYU9P+YfLE=; b=PnWaa0PbwjBhABusuh2kwFlOhy/k1zmvQ6wuiNDNP2pCthkOEZymdqDMWK/Y7jf8zP W3Fz1I+oGLllbizgmE1PPsD6NcYzC3PkDhHDcqaKxxb8GPPBX5I+7fyMiHI+xDsQKkBI RunB5LfJW8KTUHnUFkp3QEvFQbL1XG9iu4cbekFtbqg6dIKdGpfQPxk3Z++z897lt0nj SHgKInZ2OusBjUvpPMHUMXixIrnZ0iq7VVxOCAmC0wnyv8lti4Kcb5mXNYdWqoLruweV GWMPKdNdQd7zS2SFxDM58ewjUjylb9PjA5GnQFkEHi3/1gB2a+TJsVH2LCTJX2l+vVO4 fHyg== X-Received: by 10.68.197.66 with SMTP id is2mr6050545pbc.96.1391639562454; Wed, 05 Feb 2014 14:32:42 -0800 (PST) Received: from [192.168.1.7] (124-149-100-27.dyn.iinet.net.au. [124.149.100.27]) by mx.google.com with ESMTPSA id id1sm80135044pbc.11.2014.02.05.14.32.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Feb 2014 14:32:41 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_B8ADB74F-218F-422D-82CC-A1BDBF4A07C1" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: James Winterbottom In-Reply-To: Date: Thu, 6 Feb 2014 09:32:37 +1100 Message-Id: <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> To: "Makaraju, Maridi Raju (Raju)" X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 22:32:45 -0000 --Apple-Mail=_B8ADB74F-218F-422D-82CC-A1BDBF4A07C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Check out SLh. Check out SLg On 6 Feb 2014, at 9:31 am, Makaraju, Maridi Raju (Raju) = wrote: > =20 > DIAMETER is used to carry signalling information through out IMS. > [Raju] Which interface? and what kind of signaling? To the best of my = knowledge, diameter is only used for =93authentication, authorization, = and accounting=93. The Rx diameter interface used between P-CSCF and = PCRF is not really call processing related signaling but rather used for = =93authorization=94 of the media flow. > =20 > -Raju --Apple-Mail=_B8ADB74F-218F-422D-82CC-A1BDBF4A07C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Check = out SLh.
Check out SLg

On 6 Feb 2014, at = 9:31 am, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-luc= ent.com> wrote:

 
DIAMETER is = used to carry signalling information through out = IMS.
[Raju] Which interface? and what kind of signaling? = To the best of my knowledge, diameter is only used for =93authentication, authorization, and accounting=93. = The Rx diameter interface used between P-CSCF and PCRF is not really = call processing related signaling but rather used for =93authorization=94 = of the media flow.
 
-Raju

= --Apple-Mail=_B8ADB74F-218F-422D-82CC-A1BDBF4A07C1-- From michael.hammer@yaanatech.com Wed Feb 5 14:34:06 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF611A021F for ; Wed, 5 Feb 2014 14:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yx_PVc3mfICI for ; Wed, 5 Feb 2014 14:34:03 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 87E3E1A0263 for ; Wed, 5 Feb 2014 14:34:03 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 14:34:03 -0800 From: Michael Hammer To: "a.james.winterbottom@gmail.com" , "Raju.Makaraju@alcatel-lucent.com" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAC9HICAAALFAIAAAFCA//96B5A= Date: Wed, 5 Feb 2014 22:34:01 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> In-Reply-To: <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.48] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0114_01CF2298.74A0EAB0" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 22:34:06 -0000 ------=_NextPart_000_0114_01CF2298.74A0EAB0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0115_01CF2298.74A0EAB0" ------=_NextPart_001_0115_01CF2298.74A0EAB0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Could we take debates about 3GPP off-line? Seems to be getting off-topic. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of James Winterbottom Sent: Wednesday, February 05, 2014 5:33 PM To: Makaraju, Maridi Raju (Raju) Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS Check out SLh. Check out SLg On 6 Feb 2014, at 9:31 am, Makaraju, Maridi Raju (Raju) wrote: DIAMETER is used to carry signalling information through out IMS. [Raju] Which interface? and what kind of signaling? To the best of my knowledge, diameter is only used for "authentication, authorization, and accounting". The Rx diameter interface used between P-CSCF and PCRF is not really call processing related signaling but rather used for "authorization" of the media flow. -Raju ------=_NextPart_001_0115_01CF2298.74A0EAB0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Could we take debates about 3GPP off-line?

Seems to be getting off-topic.

 

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com

Mobile: +1 408-202-9291

500 Yosemite Drive Suite = 120

Milpitas, CA 95035 = USA

 

From:= = dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of James = Winterbottom
Sent: Wednesday, February 05, 2014 5:33 = PM
To: Makaraju, Maridi Raju (Raju)
Cc: = dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS = with OpenBTS

 

Check out = SLh.

Check out = SLg

 

On = 6 Feb 2014, at 9:31 am, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lu= cent.com> wrote:



 

DIAMETER is used to carry signalling information = through out IMS.

[Raju] Which interface? and what kind of signaling? To the best of my = knowledge, diameter is only used for “authentication, = authorization, and accounting“. The Rx diameter interface used = between P-CSCF and PCRF is not really call processing related signaling = but rather used for “authorization” of the media = flow.

 

-Raju

 

------=_NextPart_001_0115_01CF2298.74A0EAB0-- ------=_NextPart_000_0114_01CF2298.74A0EAB0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIw NTIyMzQwMFowIwYJKoZIhvcNAQkEMRYEFKuMMtI3fSRlBPp6diToLQf3NFFtMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAPoAIfv9iuE3SLh+e0NE6/m8DrX+liOzhf68Bjm1b 1ilvfCPp9++TZQFurmuEP6YahaKw/nVTTYiZaAyyejrKpAY++cFHJRy3n8q5J3COBej04QVyrccm Z6rxtMuO5k2b+Jgq8WQrfNcpB4BFcx7DtnT6kbztBA5RKYGcJOE64oR6Bt5ZVHgspnfZrNYslvP1 W1VUWtRAkZB6SmqXGdoSiJp7lqhXXcHUKVBG7QCIZohEq3GvyUuFvXR6wTKAVBnLskjYo74kWaAc r28hDkMGxrDhH/guSX4SwmeYVdMsdD7twBqvM6wIH64R19BrdICERHeqCB8LlQXjbC3Rxx77owAA AAAAAA== ------=_NextPart_000_0114_01CF2298.74A0EAB0-- From mary.ietf.barnes@gmail.com Wed Feb 5 15:00:15 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64DAE1A026A for ; Wed, 5 Feb 2014 15:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1GC6XjhIE0r for ; Wed, 5 Feb 2014 15:00:12 -0800 (PST) Received: from mail-yk0-x229.google.com (mail-yk0-x229.google.com [IPv6:2607:f8b0:4002:c07::229]) by ietfa.amsl.com (Postfix) with ESMTP id 5647B1A016B for ; Wed, 5 Feb 2014 15:00:12 -0800 (PST) Received: by mail-yk0-f169.google.com with SMTP id q9so2856650ykb.0 for ; Wed, 05 Feb 2014 15:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BmpsUgf43py6v4xHWHgaQPrS8v+dFXQx50AFKNvOXB0=; b=Ka0FHr8j4ilIDVzg0aXBJ2rmWl7XmXa5d99eXKpgHs/XDUXwe+Rl3bcF9W/EqmQpPL mkl83zjKtK3UDbiOSnKn6SgjUK5JichqTeGm6OWU/ELE2qn6mt7cT0jLS7e05Mivq1YH bHyjLDPOnJiFH83uM6Zvh0+BOZ0VYlYKVcOyEeKZ9/ycjUvI/sRrAc1qEIMNUTT+5/BU O32jViyVgbr6TKVR5tCHZ+BzSKHnbsY7RK4zQ5784dhrldEYYp+85IhFN6M6xEVdZb+3 AygQT0vPax+eNiyqPta2Y7T/S2bHs3IhWWE/gytuU7zMXDKLDLRu60jON2TGtPoLuo+s STpA== MIME-Version: 1.0 X-Received: by 10.236.131.19 with SMTP id l19mr3844076yhi.0.1391641211458; Wed, 05 Feb 2014 15:00:11 -0800 (PST) Received: by 10.170.46.143 with HTTP; Wed, 5 Feb 2014 15:00:11 -0800 (PST) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> Date: Wed, 5 Feb 2014 17:00:11 -0600 Message-ID: From: Mary Barnes To: Michael Hammer Content-Type: multipart/alternative; boundary=20cf3010e96d1058ae04f1b0b8a3 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:00:15 -0000 --20cf3010e96d1058ae04f1b0b8a3 Content-Type: text/plain; charset=ISO-8859-1 I don't necessarily think 3GPP is out of scope in that I think it's very important that if IETF decides that we will be documenting or even defining protocol elements to support OpenBTS, it needs to be clear why 3GPP Call control/SIP specifications aren't being used. In offline in discussions with the proponents, it's my understanding that OpenBTS is being used in very specific environments where there is no full MSC deployments (i.e., remote locations that have no deployed IMS networks). The intent isn't to replicate a full IMS system, but rather to provide basic connectivity to the Internet and use SIP in a non-IMS context to complete the calls. So, I think more detail about this context would be very helpful. I think it would really help if there were some diagrams showing what IMS protocols are being used. My understanding is that current implementations have various ways in which they are interworking the Radio Layer Call Control messages to SIP messages. I think the motivation is to improve interop by defining a consistent "mapping" if you will. It's not clear to me how exactly registration is being handled - perhaps mapping some of the Radio Layer mobility management messages. My understanding is that there can be no change to the existing messages from the cell phone to the BTS for obvious reasons, so all the interworking needs to happen in the BTS. Regards, Mary. On Wed, Feb 5, 2014 at 4:34 PM, Michael Hammer wrote: > Could we take debates about 3GPP off-line? > > Seems to be getting off-topic. > > > > *Michael Hammer* > > *Principal Engineer* > > *michael.hammer@yaanatech.com * > > *Mobile: *+1 408-202-9291 > > 500 Yosemite Drive Suite 120 > > Milpitas, CA 95035 USA > > > > *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *James > Winterbottom > *Sent:* Wednesday, February 05, 2014 5:33 PM > *To:* Makaraju, Maridi Raju (Raju) > *Cc:* dispatch@ietf.org > *Subject:* Re: [dispatch] SIP and GSM/UMTS with OpenBTS > > > > Check out SLh. > > Check out SLg > > > > On 6 Feb 2014, at 9:31 am, Makaraju, Maridi Raju (Raju) < > Raju.Makaraju@alcatel-lucent.com> wrote: > > > > > > DIAMETER is used to carry signalling information through out IMS. > > *[Raju] Which interface? and what kind of signaling? To the best of my > knowledge, diameter is only used for "authentication, authorization, and > accounting". The Rx diameter interface used between P-CSCF and PCRF is not > really call processing related signaling but rather used for > "authorization" of the media flow.* > > > > *-Raju* > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --20cf3010e96d1058ae04f1b0b8a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't necessarily think 3GPP is out of scope in that= I think it's very important that if IETF decides that we will be docum= enting or even defining protocol elements to support OpenBTS, it needs to b= e clear why 3GPP Call control/SIP specifications aren't being used.&nbs= p;

In offline in discussions with the proponents, it's my u= nderstanding that OpenBTS is being used in very specific environments where= there is no full MSC deployments (i.e., remote locations that have no depl= oyed IMS networks).  The intent isn't to replicate a full IMS syst= em, but rather to provide basic connectivity to the Internet and use SIP in= a non-IMS context to complete the calls.   So, I think more detail ab= out this context would be very helpful.  

I think it would really help if there were some diagram= s showing what IMS protocols are being used.  My understanding is that= current implementations have various ways in which they are interworking t= he Radio Layer Call Control messages to SIP messages.  I think the mot= ivation is to improve interop by defining a consistent "mapping" = if you will.  It's not clear to me how exactly registration is bei= ng handled - perhaps mapping some of the Radio Layer mobility management me= ssages.   My understanding is that there can be no change to the exist= ing messages from the cell phone to the BTS for obvious reasons, so all the= interworking needs to happen in the BTS.  

Regards,
Mary. 


On Wed, Feb 5, 2014 at 4:3= 4 PM, Michael Hammer <michael.hammer@yaanatech.com> wrote:

Could we take= debates about 3GPP off-line?

Seems to be getting off-t= opic.

 

<= b>Michael HammerPrincipal Enginee= r

michael.hammer@yaanatech.com= =

Mobile: +1 408-202-9291

500 Yosemite Drive Suite 120=

Milpitas, CA 95035 USA

 

 <= /u>

Check out SLh.

Check out SLg

 

On 6 Feb 2014, at 9:31 am, Makaraju, Marid= i Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:<= /p>



 

DIAMETER is used to carry signalling information through out IMS.=

[Ra= ju] Which interface? and what kind of signaling? To the best of my knowledg= e, diameter is only used for “authentication, autho= rization, and accounting“. The Rx diameter interface used between P-C= SCF and PCRF is not really call processing related signaling but rather use= d for “authorization” of the media flow.<= u>

 

-Raju

 


_______________________________________= ________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--20cf3010e96d1058ae04f1b0b8a3-- From michael.hammer@yaanatech.com Wed Feb 5 15:19:42 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051771A02B5 for ; Wed, 5 Feb 2014 15:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S6dc8gPBGMv for ; Wed, 5 Feb 2014 15:19:38 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 33E5D1A021F for ; Wed, 5 Feb 2014 15:19:38 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 15:19:37 -0800 From: Michael Hammer To: "mary.ietf.barnes@gmail.com" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAC9HICAAALFAIAAAFCA//96B5CAAI2tgP//fihg Date: Wed, 5 Feb 2014 23:19:35 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF23F45@sc9-ex2k10mb1.corp.yaanatech.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.48] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0140_01CF229E.D2A6FD10" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:19:42 -0000 ------=_NextPart_000_0140_01CF229E.D2A6FD10 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0141_01CF229E.D2A6FD10" ------=_NextPart_001_0141_01CF229E.D2A6FD10 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Mary, What I was hoping to avoid was full-blown tutorials on 3GPP and IMS. As well as discussion about what parts of 3GPP are signaling versus something else. Distinguishing what the impacts of OpenBTS on SIP are versus what is in use for 3GPP could clarify if we would be doing the same thing but with redundant headers, for example, would be useful. Just didn't want to lose sight of the touchstone (how does this impact SIP). Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Wednesday, February 05, 2014 6:00 PM To: Michael Hammer Cc: a.james.winterbottom@gmail.com; Raju.Makaraju@alcatel-lucent.com; dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS I don't necessarily think 3GPP is out of scope in that I think it's very important that if IETF decides that we will be documenting or even defining protocol elements to support OpenBTS, it needs to be clear why 3GPP Call control/SIP specifications aren't being used. In offline in discussions with the proponents, it's my understanding that OpenBTS is being used in very specific environments where there is no full MSC deployments (i.e., remote locations that have no deployed IMS networks). The intent isn't to replicate a full IMS system, but rather to provide basic connectivity to the Internet and use SIP in a non-IMS context to complete the calls. So, I think more detail about this context would be very helpful. I think it would really help if there were some diagrams showing what IMS protocols are being used. My understanding is that current implementations have various ways in which they are interworking the Radio Layer Call Control messages to SIP messages. I think the motivation is to improve interop by defining a consistent "mapping" if you will. It's not clear to me how exactly registration is being handled - perhaps mapping some of the Radio Layer mobility management messages. My understanding is that there can be no change to the existing messages from the cell phone to the BTS for obvious reasons, so all the interworking needs to happen in the BTS. Regards, Mary. On Wed, Feb 5, 2014 at 4:34 PM, Michael Hammer wrote: Could we take debates about 3GPP off-line? Seems to be getting off-topic. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of James Winterbottom Sent: Wednesday, February 05, 2014 5:33 PM To: Makaraju, Maridi Raju (Raju) Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS Check out SLh. Check out SLg On 6 Feb 2014, at 9:31 am, Makaraju, Maridi Raju (Raju) wrote: DIAMETER is used to carry signalling information through out IMS. [Raju] Which interface? and what kind of signaling? To the best of my knowledge, diameter is only used for "authentication, authorization, and accounting". The Rx diameter interface used between P-CSCF and PCRF is not really call processing related signaling but rather used for "authorization" of the media flow. -Raju _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_001_0141_01CF229E.D2A6FD10 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Mary,

 

What I was hoping to avoid was full-blown tutorials on 3GPP and = IMS.

As well as discussion about what parts of 3GPP are signaling versus = something else.

 

Distinguishing what the impacts of OpenBTS on SIP are versus what is = in use for 3GPP

could clarify if we would be doing the same thing but with redundant = headers, for example, would be useful.

 

Just didn’t want to lose sight of the touchstone (how does this = impact SIP).

 

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com

Mobile: +1 408-202-9291

500 Yosemite Drive Suite = 120

Milpitas, CA 95035 = USA

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: = Wednesday, February 05, 2014 6:00 PM
To: Michael = Hammer
Cc: a.james.winterbottom@gmail.com; = Raju.Makaraju@alcatel-lucent.com; dispatch@ietf.org
Subject: = Re: [dispatch] SIP and GSM/UMTS with OpenBTS

 

I don't = necessarily think 3GPP is out of scope in that I think it's very = important that if IETF decides that we will be documenting or even = defining protocol elements to support OpenBTS, it needs to be clear why = 3GPP Call control/SIP specifications aren't being = used. 

 

In offline in discussions with the proponents, it's my = understanding that OpenBTS is being used in very specific environments = where there is no full MSC deployments (i.e., remote locations that have = no deployed IMS networks).  The intent isn't to replicate a full = IMS system, but rather to provide basic connectivity to the Internet and = use SIP in a non-IMS context to complete the calls.   So, I think = more detail about this context would be very helpful. =  

 

I = think it would really help if there were some diagrams showing what IMS = protocols are being used.  My understanding is that current = implementations have various ways in which they are interworking the = Radio Layer Call Control messages to SIP messages.  I think the = motivation is to improve interop by defining a consistent = "mapping" if you will.  It's not clear to me how exactly = registration is being handled - perhaps mapping some of the Radio Layer = mobility management messages.   My understanding is that there can = be no change to the existing messages from the cell phone to the BTS for = obvious reasons, so all the interworking needs to happen in the BTS. =  

 

Regards,

Mary. 

 

On Wed, Feb 5, 2014 at 4:34 PM, Michael Hammer <michael.hammer@yaanatech.com> = wrote:

Could we take debates about 3GPP off-line?

Seems to be getting off-topic.

 

Michael = Hammer

Principal = Engineer

michael.hammer@yaanatech.com<= /p>

Mobile: +1 = 408-202-9291

500 = Yosemite Drive Suite 120

Milpitas, CA 95035 = USA

 

From:= = dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of = James Winterbottom
Sent: Wednesday, February 05, 2014 5:33 = PM
To: Makaraju, Maridi Raju (Raju)
Cc: dispatch@ietf.org
Subject: Re: = [dispatch] SIP and GSM/UMTS with = OpenBTS

 <= /o:p>

Check out = SLh.

Check out = SLg

 <= /o:p>

On 6 Feb = 2014, at 9:31 am, Makaraju, Maridi Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> = wrote:

 <= /p>

 <= /o:p>

DIAMETER is = used to carry signalling information through out = IMS.

[Raju] Which interface? and what kind of signaling? To the best of my = knowledge, diameter is only used for “authentication, = authorization, and accounting“. The Rx diameter interface used = between P-CSCF and PCRF is not really call processing related signaling = but rather used for “authorization” of the media = flow.

 

-Raju

 <= /o:p>


______________________________________= _________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch=

 

------=_NextPart_001_0141_01CF229E.D2A6FD10-- ------=_NextPart_000_0140_01CF229E.D2A6FD10 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIw NTIzMTkzNVowIwYJKoZIhvcNAQkEMRYEFDaaBytXZmFbKnpz4CxyjSwGuQtXMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEARN3dXQk9fmlMwY9RXs6I2o1OCvCOIgGdzN90f7en dQnhxzLIpSrcYprKGmMeJINMwmFN/f2AZ6puqhpESSK9lDCTOg8kq3oZXfqWDaykag363hfgwgms VsiNiwMHzSN/68KmR6weS+s/lJsF+yr/Xi4cx6RtFvU9IqaZH2Rqd+y4v6QkaZtxAMGNQbdko79S c6mTGuzvK4vqzlF+X/+srMGwNGw4O2TtJjOi/4F1d/NJvORHL/QU7+tSf9vi7K72jCwK/d/7ovIJ HOJYzDL6HefSMyAE3hqEyOxtgJzSHoO29UVFLTqmWAHTHFWuc2HI9bw3T55b/pLcbRLgGX68wwAA AAAAAA== ------=_NextPart_000_0140_01CF229E.D2A6FD10-- From mary.ietf.barnes@gmail.com Wed Feb 5 15:21:25 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E645F1A02C5 for ; Wed, 5 Feb 2014 15:21:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQMIDe_jQLlF for ; Wed, 5 Feb 2014 15:21:19 -0800 (PST) Received: from mail-yh0-x235.google.com (mail-yh0-x235.google.com [IPv6:2607:f8b0:4002:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 671ED1A02D4 for ; Wed, 5 Feb 2014 15:21:19 -0800 (PST) Received: by mail-yh0-f53.google.com with SMTP id v1so1238399yhn.40 for ; Wed, 05 Feb 2014 15:21:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZtQgeRZOL7jgzlRiBfqH11ek3O/J1150Sphu5HwNcbk=; b=Sj/63o2xc70RwOAGVHRcLxBu1cJdkUktAWbJqzJlqzSp7vec9TiQ5Hc96cWtV/qMm5 k/u+mApE30Mnjc50/NIuflhkmpiTyHqbpzvtd6kczf/hPp+FrxO5Eqk7Iviwuz1s4uHb MsehWqT7lfRPAksCW2X5+/7BTwnxppX9dB4I+zJWkZKvObuy5fo8DRK/JK69k9OOkUqZ L70caGhXdfyNMXiU24x0OXNAArzMzzcYAokxrpZCoo+tq3bcOwsixV82Beq9wmc9RF/b 4PpRzqiguFaW5mwZljoEEhsL4DF1w4JO/lyVedKP8Nr1flZ6VnhX3dSp8mAMlj0aN7BE eQSA== MIME-Version: 1.0 X-Received: by 10.236.100.173 with SMTP id z33mr3812884yhf.9.1391642478506; Wed, 05 Feb 2014 15:21:18 -0800 (PST) Received: by 10.170.46.143 with HTTP; Wed, 5 Feb 2014 15:21:18 -0800 (PST) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF23F45@sc9-ex2k10mb1.corp.yaanatech.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBF23F45@sc9-ex2k10mb1.corp.yaanatech.com> Date: Wed, 5 Feb 2014 17:21:18 -0600 Message-ID: From: Mary Barnes To: Michael Hammer Content-Type: multipart/alternative; boundary=20cf3005e01895f8a204f1b103b4 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2014 23:21:26 -0000 --20cf3005e01895f8a204f1b103b4 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 5, 2014 at 5:19 PM, Michael Hammer wrote: > Mary, > > > > What I was hoping to avoid was full-blown tutorials on 3GPP and IMS. > > As well as discussion about what parts of 3GPP are signaling versus > something else. > [MB] Yes, I totally agree. Thanks for that clarification. [/MB] > > > Distinguishing what the impacts of OpenBTS on SIP are versus what is in > use for 3GPP > > could clarify if we would be doing the same thing but with redundant > headers, for example, would be useful. > > > > Just didn't want to lose sight of the touchstone (how does this impact > SIP). > > > > *Michael Hammer* > > *Principal Engineer* > > *michael.hammer@yaanatech.com * > > *Mobile: *+1 408-202-9291 > > 500 Yosemite Drive Suite 120 > > Milpitas, CA 95035 USA > > > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* Wednesday, February 05, 2014 6:00 PM > *To:* Michael Hammer > *Cc:* a.james.winterbottom@gmail.com; Raju.Makaraju@alcatel-lucent.com; > dispatch@ietf.org > > *Subject:* Re: [dispatch] SIP and GSM/UMTS with OpenBTS > > > > I don't necessarily think 3GPP is out of scope in that I think it's very > important that if IETF decides that we will be documenting or even defining > protocol elements to support OpenBTS, it needs to be clear why 3GPP Call > control/SIP specifications aren't being used. > > > > In offline in discussions with the proponents, it's my understanding that > OpenBTS is being used in very specific environments where there is no full > MSC deployments (i.e., remote locations that have no deployed IMS > networks). The intent isn't to replicate a full IMS system, but rather to > provide basic connectivity to the Internet and use SIP in a non-IMS context > to complete the calls. So, I think more detail about this context would > be very helpful. > > > > I think it would really help if there were some diagrams showing what IMS > protocols are being used. My understanding is that current implementations > have various ways in which they are interworking the Radio Layer Call > Control messages to SIP messages. I think the motivation is to improve > interop by defining a consistent "mapping" if you will. It's not clear to > me how exactly registration is being handled - perhaps mapping some of the > Radio Layer mobility management messages. My understanding is that there > can be no change to the existing messages from the cell phone to the BTS > for obvious reasons, so all the interworking needs to happen in the BTS. > > > > Regards, > > Mary. > > > > On Wed, Feb 5, 2014 at 4:34 PM, Michael Hammer < > michael.hammer@yaanatech.com> wrote: > > Could we take debates about 3GPP off-line? > > Seems to be getting off-topic. > > > > *Michael Hammer* > > *Principal Engineer* > > *michael.hammer@yaanatech.com * > > *Mobile: *+1 408-202-9291 > > 500 Yosemite Drive Suite 120 > > Milpitas, CA 95035 USA > > > > *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *James > Winterbottom > *Sent:* Wednesday, February 05, 2014 5:33 PM > *To:* Makaraju, Maridi Raju (Raju) > *Cc:* dispatch@ietf.org > *Subject:* Re: [dispatch] SIP and GSM/UMTS with OpenBTS > > > > Check out SLh. > > Check out SLg > > > > On 6 Feb 2014, at 9:31 am, Makaraju, Maridi Raju (Raju) < > Raju.Makaraju@alcatel-lucent.com> wrote: > > > > > > DIAMETER is used to carry signalling information through out IMS. > > *[Raju] Which interface? and what kind of signaling? To the best of my > knowledge, diameter is only used for "authentication, authorization, and > accounting". The Rx diameter interface used between P-CSCF and PCRF is not > really call processing related signaling but rather used for > "authorization" of the media flow.* > > > > *-Raju* > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > --20cf3005e01895f8a204f1b103b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Feb 5, 2014 at 5:19 PM, Michael Hammer &l= t;michael= .hammer@yaanatech.com> wrote:

Mary,<= u>

 

What I was hoping t= o avoid was full-blown tutorials on 3GPP and IMS.

As well as discussion abo= ut what parts of 3GPP are signaling versus something else.

[MB] Yes, I totally agree. Thanks for that clarific= ation. [/MB] 

 =

Distinguishing what the i= mpacts of OpenBTS on SIP are versus what is in use for 3GPP <= /span>

could clarify if we would= be doing the same thing but with redundant headers, for example, would be = useful.

 

Just didn’t w= ant to lose sight of the touchstone (how does this impact SIP).

=  

Michael Hammer

Principal Enginee= r

michael.hammer@yaanatech.com= =

Mobile: +1 408-202-9291

500 Yosemite Drive Suite 120=

Milpitas, CA 95035 USA

 

From: Mary Barnes [mailto= :mary.ietf.= barnes@gmail.com]
Sent: Wednesday, February 05, 2014 6:00 PM
To: Michael Ham= mer
Cc: a.james.winterbottom@gmail.com; Raju.Makaraju@alcatel-lucent.com= ; dispatch@ietf.= org


Subject: Re: [dispatch] SIP and GSM/UMTS = with OpenBTS

 

I don&#= 39;t necessarily think 3GPP is out of scope in that I think it's very i= mportant that if IETF decides that we will be documenting or even defining = protocol elements to support OpenBTS, it needs to be clear why 3GPP Call co= ntrol/SIP specifications aren't being used. 

 

In offline in discussions with the proponents, it's my under= standing that OpenBTS is being used in very specific environments where the= re is no full MSC deployments (i.e., remote locations that have no deployed= IMS networks).  The intent isn't to replicate a full IMS system, = but rather to provide basic connectivity to the Internet and use SIP in a n= on-IMS context to complete the calls.   So, I think more detail about = this context would be very helpful.  

 

I think it would really help if there were some diagrams s= howing what IMS protocols are being used.  My understanding is that cu= rrent implementations have various ways in which they are interworking the = Radio Layer Call Control messages to SIP messages.  I think the motiva= tion is to improve interop by defining a consistent "mapping" if = you will.  It's not clear to me how exactly registration is being = handled - perhaps mapping some of the Radio Layer mobility management messa= ges.   My understanding is that there can be no change to the existing= messages from the cell phone to the BTS for obvious reasons, so all the in= terworking needs to happen in the BTS.  

 

Regards,

Mary. 

 

On Wed, Feb 5, 2014 at = 4:34 PM, Michael Hammer <michael.hammer@yaanatech.com> wrote:

Could we take debate= s about 3GPP off-line?

Seems to be getting off-topic.

 =

Michael Hammer<= /p>

Principal Engi= neer

michael.hammer@yaanatech.com

Mobile: +1 408-202-929= 1

500 Yosemite Drive Suite 120

Milpitas, CA 95035 USA

 

From:<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif""> dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of James W= interbottom
Sent: Wednesday, February 05, 2014 5:33 PM
To: Makaraju, M= aridi Raju (Raju)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP and= GSM/UMTS with OpenBTS

 

Check out SLh.

Check out SLg

 

On 6 Feb 2014, at 9:31 am, Makaraju, Marid= i Raju (Raju) <Raju.Makaraju@alcatel-lucent.com> wrote:<= /p>

 

 

DIAMETER is used to carry signalling information through out IMS.=

[Raju] Which interface? and what kind of signaling? To the best of my = knowledge, diameter is only used for “authentication, authorizat= ion, and accounting“. The Rx diameter interface used between P-CSCF a= nd PCRF is not really call processing related signaling but rather used for= “authorization” of the media flow.

 

-Raju

 


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

=

 


--20cf3005e01895f8a204f1b103b4-- From keith.drage@alcatel-lucent.com Wed Feb 5 16:18:47 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD191A02A1 for ; Wed, 5 Feb 2014 16:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMSmp7HGnwVD for ; Wed, 5 Feb 2014 16:18:43 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 7015B1A021F for ; Wed, 5 Feb 2014 16:18:43 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s160IeVN021434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2014 18:18:41 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s160IdvD010235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 01:18:39 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 6 Feb 2014 01:18:39 +0100 From: "DRAGE, Keith (Keith)" To: Mary Barnes , Michael Hammer Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIsChkF9riHfhQ0Se4gDBfVRQX5qnLcIAgAAAUICAAABkgIAAB1CAgAAFbICAAAB6AIAAH4Dw Date: Thu, 6 Feb 2014 00:18:38 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B12AEA6@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBF23F45@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B12AEA6FR712WXCHMBA11zeu_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 00:18:47 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B12AEA6FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable To impact SIP we need some clearer requirements. Use of GERAN as an access = technology hardly allows to concept of a network architecture. That is where my points have been going. 3GPP started with a set of requirements, many of which will be applicable h= ere, and we need to know which, and any additional ones. Keith ________________________________ From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 05 February 2014 23:21 To: Michael Hammer Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS On Wed, Feb 5, 2014 at 5:19 PM, Michael Hammer > wrote: Mary, What I was hoping to avoid was full-blown tutorials on 3GPP and IMS. As well as discussion about what parts of 3GPP are signaling versus somethi= ng else. [MB] Yes, I totally agree. Thanks for that clarification. [/MB] Distinguishing what the impacts of OpenBTS on SIP are versus what is in use= for 3GPP could clarify if we would be doing the same thing but with redundant header= s, for example, would be useful. Just didn't want to lose sight of the touchstone (how does this impact SIP)= . Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Wednesday, February 05, 2014 6:00 PM To: Michael Hammer Cc: a.james.winterbottom@gmail.com; = Raju.Makaraju@alcatel-lucent.com; = dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS I don't necessarily think 3GPP is out of scope in that I think it's very im= portant that if IETF decides that we will be documenting or even defining p= rotocol elements to support OpenBTS, it needs to be clear why 3GPP Call con= trol/SIP specifications aren't being used. In offline in discussions with the proponents, it's my understanding that O= penBTS is being used in very specific environments where there is no full M= SC deployments (i.e., remote locations that have no deployed IMS networks).= The intent isn't to replicate a full IMS system, but rather to provide ba= sic connectivity to the Internet and use SIP in a non-IMS context to comple= te the calls. So, I think more detail about this context would be very he= lpful. I think it would really help if there were some diagrams showing what IMS p= rotocols are being used. My understanding is that current implementations = have various ways in which they are interworking the Radio Layer Call Contr= ol messages to SIP messages. I think the motivation is to improve interop = by defining a consistent "mapping" if you will. It's not clear to me how e= xactly registration is being handled - perhaps mapping some of the Radio La= yer mobility management messages. My understanding is that there can be n= o change to the existing messages from the cell phone to the BTS for obviou= s reasons, so all the interworking needs to happen in the BTS. Regards, Mary. On Wed, Feb 5, 2014 at 4:34 PM, Michael Hammer > wrote: Could we take debates about 3GPP off-line? Seems to be getting off-topic. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of James Winterbottom Sent: Wednesday, February 05, 2014 5:33 PM To: Makaraju, Maridi Raju (Raju) Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS Check out SLh. Check out SLg On 6 Feb 2014, at 9:31 am, Makaraju, Maridi Raju (Raju) > wrote: DIAMETER is used to carry signalling information through out IMS. [Raju] Which interface? and what kind of signaling? To the best of my knowl= edge, diameter is only used for "authentication, authorization, and account= ing". The Rx diameter interface used between P-CSCF and PCRF is not really = call processing related signaling but rather used for "authorization" of th= e media flow. -Raju _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_949EF20990823C4C85C18D59AA11AD8B12AEA6FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
To impact SIP we need some cleare= r requirements. Use of GERAN as an access technology hardly allows to conce= pt of a network architecture.
 
That is where my points have been= going.
 
3GPP started with a set of requir= ements, many of which will be applicable here, and we need to know which, a= nd any additional ones.
 
Keith

From: dispatch [mailto:dispatch-bou= nces@ietf.org] On Behalf Of Mary Barnes
Sent: 05 February 2014 23:21
To: Michael Hammer
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS




On Wed, Feb 5, 2014 at 5:19 PM, Michael Hammer <= span dir=3D"ltr"> <micha= el.hammer@yaanatech.com> wrote:

Mary,

 

What I was hoping to avoid was full-blown = tutorials on 3GPP and IMS.

As well as discussion about what parts of = 3GPP are signaling versus something else.

[MB] Yes, I totally agree. Thanks for that clarification. [/MB] <= /div>

 

Distinguishing what the impacts of OpenBTS= on SIP are versus what is in use for 3GPP

could clarify if we would be doing the sam= e thing but with redundant headers, for example, would be useful.=

 

Just didn’t want to lose sight of th= e touchstone (how does this impact SIP).

 

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com

Mobile: +1 408-202-9291

500 Yo= semite Drive Suite 120

Milpit= as, CA 95035 USA

 

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: Wednesday, February 05, 2014 6:00 PM
To: Michael Hammer
Cc: a.james.winterbottom@gmail.com; Raju.= Makaraju@alcatel-lucent.com; dispatch@ietf.org


Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS<= /div>

 

I don't necessarily think 3GPP is out of scope in th= at I think it's very important that if IETF decides that we will be documen= ting or even defining protocol elements to support OpenBTS, it needs to be = clear why 3GPP Call control/SIP specifications aren't being used. 

 

In offline in discussions with the proponents, it's = my understanding that OpenBTS is being used in very specific environments w= here there is no full MSC deployments (i.e., remote locations that have no = deployed IMS networks).  The intent isn't to replicate a full IMS system, but rather to provide basic connecti= vity to the Internet and use SIP in a non-IMS context to complete the calls= .   So, I think more detail about this context would be very helpful. =  

 

I think it would really help if there were some diag= rams showing what IMS protocols are being used.  My understanding is t= hat current implementations have various ways in which they are interworkin= g the Radio Layer Call Control messages to SIP messages.  I think the motivation is to improve interop by def= ining a consistent "mapping" if you will.  It's not clear to= me how exactly registration is being handled - perhaps mapping some of the= Radio Layer mobility management messages.   My understanding is that there can be no change to the existing messages from the cell phon= e to the BTS for obvious reasons, so all the interworking needs to happen i= n the BTS.  

 

Regards,

Mary. 

 

On Wed, Feb 5, 2014 at 4:34 PM, Michael Hammer <<= a href=3D"mailto:michael.hammer@yaanatech.com" target=3D"_blank">michael.ha= mmer@yaanatech.com> wrote:

Could we take debates about 3GPP off-line?=

Seems to be getting off-topic.

 

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com

Mobile: +1 408-202-9291<= u>

500 Yo= semite Drive Suite 120

Milpit= as, CA 95035 USA

 

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of James Winterbottom
Sent: Wednesday, February 05, 2014 5:33 PM
To: Makaraju, Maridi Raju (Raju)
Cc: dispatch@= ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS<= u>

 

Check out SLh.

Check out SLg

 

On 6 Feb 2014, at 9:31 am, Makaraju, Maridi Raju (Ra= ju) <Raju.Makaraju@alcatel-lucent.com> wrote:

 

 

DIAMETER is used to carry signalling information thr= ough out IMS.

[Raju] Which interface? and what kin= d of signaling? To the best of my knowledge, diameter is only used for = ;“authentication, authorization, and accounting“. The Rx diameter interface used between P-CSCF and PCRF is not really call = processing related signaling but rather used for “authorization”= ; of the media flow.

 <= /p>

-Raju

 


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

 


--_000_949EF20990823C4C85C18D59AA11AD8B12AEA6FR712WXCHMBA11zeu_-- From jim.forster@rangenetworks.com Wed Feb 5 17:46:33 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7C201A0137 for ; Wed, 5 Feb 2014 17:46:33 -0800 (PST) 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=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUOvCiVJEiyE for ; Wed, 5 Feb 2014 17:46:31 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0181.outbound.protection.outlook.com [207.46.163.181]) by ietfa.amsl.com (Postfix) with ESMTP id C27821A0194 for ; Wed, 5 Feb 2014 17:46:30 -0800 (PST) Received: from BL2PR03MB404.namprd03.prod.outlook.com (10.141.91.149) by BL2PR03MB402.namprd03.prod.outlook.com (10.141.91.146) with Microsoft SMTP Server (TLS) id 15.0.868.8; Thu, 6 Feb 2014 01:46:28 +0000 Received: from BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) by BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) with mapi id 15.00.0868.013; Thu, 6 Feb 2014 01:46:27 +0000 From: Jim Forster To: Mary Barnes Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKA Date: Thu, 6 Feb 2014 01:46:26 +0000 Message-ID: <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [114.69.245.154] x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(199002)(189002)(2656002)(81542001)(80976001)(66066001)(93136001)(81342001)(63696002)(92726001)(59766001)(74502001)(47976001)(74662001)(77982001)(80022001)(47736001)(49866001)(65816001)(83322001)(31966008)(81686001)(87266001)(4396001)(54356001)(74366001)(76482001)(79102001)(76796001)(46102001)(51856001)(94316002)(50986001)(33656001)(93516002)(83716003)(86362001)(90146001)(74876001)(36756003)(92566001)(56816005)(81816001)(87936001)(53806001)(82746002)(47446002)(56776001)(76786001)(74706001)(69226001)(94946001)(83072002)(54316002)(85306002)(85852003)(95416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB402; H:BL2PR03MB404.namprd03.prod.outlook.com; CLIP:114.69.245.154; FPR:FEABF214.AC3E9F01.81D59D7B.8AF5E278.20401; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_B724CE4B-3D09-4F84-9D21-4030379F2D76"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: rangenetworks.com Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 01:46:34 -0000 --Apple-Mail=_B724CE4B-3D09-4F84-9D21-4030379F2D76 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Mary, all, Lots to read and consider. I'll be offline for 12 hours as we drive to = Delhi. > I don't necessarily think 3GPP is out of scope in that I think it's = very important that if IETF decides that we will be documenting or even = defining protocol elements to support OpenBTS, it needs to be clear why = 3GPP Call control/SIP specifications aren't being used.=20 Umm, one possible reason but I need to read and think, would be the = question of whether 3GPP Call control/SIP is in some ways tied to 4G/LTE = in some way. OpenBTS puts 2G/3G phones on the Internet. > In offline in discussions with the proponents, it's my understanding = that OpenBTS is being used in very specific environments where there is = no full MSC deployments (i.e., remote locations that have no deployed = IMS networks). The intent isn't to replicate a full IMS system, but = rather to provide basic connectivity to the Internet and use SIP in a = non-IMS context to complete the calls. So, I think more detail about = this context would be very helpful. Yes, that's correct. No full MSC; in fact only Asterix or Freeswitch or = Yate, usually embedded in the same device as the RF and signaling. The goal was and is to make really small, low power, devices that can be = deployed where classic systems don't fit, usually because they cost too = much and take too much power. Small islands, Antarctic research = stations, the jungle of Paupua Indonesia, etc.=20 This very reduced system, which might possibly be called IMS Lite for = 2G/3G phones, seems to be very useful to people that want to make calls = and send SMS in those places. It's not clear (largely because of my = ignorance) how a full IMS benefits those scenarios, while the simple = OpenBTS translation/gateway of 2G & 3G calls to SIP is a package that = people want. Well, to be clear, people with phones don't care what = protocols are used, they care about other aspects, like power and cost. > I think it would really help if there were some diagrams showing what = IMS protocols are being used. Well, I can certainly provide some diagrams that show how the system = works. > My understanding is that current implementations have various ways in = which they are interworking the Radio Layer Call Control messages to SIP = messages. I think the motivation is to improve interop by defining a = consistent "mapping" if you will. Correct. > It's not clear to me how exactly registration is being handled - = perhaps mapping some of the Radio Layer mobility management messages. = My understanding is that there can be no change to the existing messages = from the cell phone to the BTS for obvious reasons, so all the = interworking needs to happen in the BTS. =20 Correct. -- Jim --Apple-Mail=_B724CE4B-3D09-4F84-9D21-4030379F2D76 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJS8ulyAAoJECAtT58A/2SKEmwH/iOyg3AILsS0J63oLEn+GlOi SZGRQIEx4YTynbGODKLPBsz5Hbm1KT27cde7H8sRUG043Ai/LoAP1upOsvaWFjdB i1nfl+cu3lvPvTN5Y0Ndj+Tl1kBDy7Vrkf4E9wTjov5ySiRjlDFaXZnQbitMFwpU 9ALtFALNhpVV8pjEeW5PPDeQhSHaxpa51liG9YDHU/SdT/Aoberhh/vOo7NCuk8F NEyl9WjQXQ+3Ei/rY48uQVth/5XOkacsLg7gKX7/aBtYPCr0UBtHtd6qVo/AslJq bEzQw9ZvlVEYNZkIsHden/EN1gbo8A4F3lwaP+444WVPA3rHd4G1dLgt1xT1kOw= =Nz45 -----END PGP SIGNATURE----- --Apple-Mail=_B724CE4B-3D09-4F84-9D21-4030379F2D76-- From michael.hammer@yaanatech.com Wed Feb 5 18:39:38 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2291A0277 for ; Wed, 5 Feb 2014 18:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpgbi9DuMIfa for ; Wed, 5 Feb 2014 18:39:36 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 567581A0207 for ; Wed, 5 Feb 2014 18:39:36 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Wed, 5 Feb 2014 18:39:35 -0800 From: Michael Hammer To: "jim.forster@rangenetworks.com" , "mary.ietf.barnes@gmail.com" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAC9HICAAALFAIAAAFCA//96B5CAAI2tgIAALnMA//+H5WA= Date: Thu, 6 Feb 2014 02:39:34 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF241C5@sc9-ex2k10mb1.corp.yaanatech.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> In-Reply-To: <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.48] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_022F_01CF22BA.C23C0AD0" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 02:39:38 -0000 ------=_NextPart_000_022F_01CF22BA.C23C0AD0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Interesting. But, the 4G/LTE network is an IP internet of sorts. The SIP/IMS components do not need to be in the radio network, and thus not at the locations where the power is constrained. But, I'll mind my own suggestion and not go there. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA -----Original Message----- From: Jim Forster [mailto:jim.forster@rangenetworks.com] Sent: Wednesday, February 05, 2014 8:46 PM To: Mary Barnes Cc: Michael Hammer; dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS Mary, all, Lots to read and consider. I'll be offline for 12 hours as we drive to Delhi. > I don't necessarily think 3GPP is out of scope in that I think it's very important that if IETF decides that we will be documenting or even defining protocol elements to support OpenBTS, it needs to be clear why 3GPP Call control/SIP specifications aren't being used. Umm, one possible reason but I need to read and think, would be the question of whether 3GPP Call control/SIP is in some ways tied to 4G/LTE in some way. OpenBTS puts 2G/3G phones on the Internet. > In offline in discussions with the proponents, it's my understanding that OpenBTS is being used in very specific environments where there is no full MSC deployments (i.e., remote locations that have no deployed IMS networks). The intent isn't to replicate a full IMS system, but rather to provide basic connectivity to the Internet and use SIP in a non-IMS context to complete the calls. So, I think more detail about this context would be very helpful. Yes, that's correct. No full MSC; in fact only Asterix or Freeswitch or Yate, usually embedded in the same device as the RF and signaling. The goal was and is to make really small, low power, devices that can be deployed where classic systems don't fit, usually because they cost too much and take too much power. Small islands, Antarctic research stations, the jungle of Paupua Indonesia, etc. This very reduced system, which might possibly be called IMS Lite for 2G/3G phones, seems to be very useful to people that want to make calls and send SMS in those places. It's not clear (largely because of my ignorance) how a full IMS benefits those scenarios, while the simple OpenBTS translation/gateway of 2G & 3G calls to SIP is a package that people want. Well, to be clear, people with phones don't care what protocols are used, they care about other aspects, like power and cost. > I think it would really help if there were some diagrams showing what IMS protocols are being used. Well, I can certainly provide some diagrams that show how the system works. > My understanding is that current implementations have various ways in which they are interworking the Radio Layer Call Control messages to SIP messages. I think the motivation is to improve interop by defining a consistent "mapping" if you will. Correct. > It's not clear to me how exactly registration is being handled - perhaps mapping some of the Radio Layer mobility management messages. My understanding is that there can be no change to the existing messages from the cell phone to the BTS for obvious reasons, so all the interworking needs to happen in the BTS. Correct. -- Jim ------=_NextPart_000_022F_01CF22BA.C23C0AD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIw NjAyMzkzM1owIwYJKoZIhvcNAQkEMRYEFJOQQjWE9atniaYLf11ABknTJDDJMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAez/a41FIjtZ6hrS8wm4lPKakeJXvom0wAhQfXYQA njFUcg6zA8HsxZhnwDMjzcmXPSKnzPhpIMhV5OZs+Tu1L2qy1MuBHzL2ZFZcmrW76bGBJgQ5vDAi oaYDBROZflZmcjWRIJHaCevxTaMB0kRYhrIstrI0N4tClLM+ORdxUYY8B4EAF9vKrMaRwDHzKAPI pyc8Kx5U+4Z7Y6VHsZH5dn5lbUT65rkldqznwhuemhft9VvRP2CZLIw5q7mODH0bs076nasCr7sZ ZKKKMvQluT+H3MmGe7U5fjbNupBdEadO3ClaJ5xFTEC6/SkJdP6mMBPuxUJivtizdZnxUBEXTgAA AAAAAA== ------=_NextPart_000_022F_01CF22BA.C23C0AD0-- From Gerben.Stam@nice.com Thu Feb 6 02:28:50 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A348D1A00C4 for ; Thu, 6 Feb 2014 02:28:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ntjA8OJGXhp for ; Thu, 6 Feb 2014 02:28:48 -0800 (PST) Received: from soumd01.eu.nice.com (ukemail.nice.com [195.99.0.242]) by ietfa.amsl.com (Postfix) with ESMTP id 75FD01A0274 for ; Thu, 6 Feb 2014 02:28:46 -0800 (PST) Received: from SOUCAS02.eu.nice.com ([10.1.1.10]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Feb 2014 10:28:02 +0000 Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS02.eu.nice.com ([::1]) with mapi; Thu, 6 Feb 2014 10:28:01 +0000 From: Gerben Stam To: Gerben Stam Date: Thu, 6 Feb 2014 10:28:00 +0000 Thread-Topic: Lossless Recording in SIPREC Thread-Index: Ac8jGmh7wCiRtzx+S36/BLPSWhJNog== Message-ID: <4BEAD79F6904AC4FB1917EBA8006628905C0685ACE@SOUEXC01.eu.nice.com> 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_4BEAD79F6904AC4FB1917EBA8006628905C0685ACESOUEXC01eunic_" MIME-Version: 1.0 X-OriginalArrivalTime: 06 Feb 2014 10:28:02.0730 (UTC) FILETIME=[1D7A08A0:01CF2326] X-Mailman-Approved-At: Thu, 06 Feb 2014 06:27:42 -0800 Cc: "dispatch@ietf.org" Subject: [dispatch] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 10:31:50 -0000 --_000_4BEAD79F6904AC4FB1917EBA8006628905C0685ACESOUEXC01eunic_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear DISPATCH group, SIPREC is a great initiative to standardize the interface for capturing Com= munication Sessions. Session Recording is becoming more and more critical due to Compliance and = regulatory changes over the last years. The compliance market is requesting more than capture only these days Confirmation is needed to acknowledge the entire Communication Session was = captured correctly. RTCP Reports (rfc3611) will help to confirm complete handover of RTP conten= t. New requirement is 'lossless' Session Capturing. Lossless indicating handover of content (RTP) is acknowledged by the receiv= er AND in case of receiving issues, the sender will resend. Reasons for loss may be UDP packet loss or receiver failing(over) and tempo= rary not able to accept content. Current approach to address this 'lossless' requirement is using 2 independ= ent parallel receivers. This requires the sender to send 2 individual streams, in fact 2 independen= t SIPREC sessions. Not sure if this is covered currently as supported SIPREC deployment. We do= see implementations based on SIPREC supporting it. Alternative is quick failover at receiver in case of failure but as sender = will send only once, this may lead to loss during failover. I am not aware of any rfc covering lossless content handover, but there may= be standards covering this already. Looking forward to discussion on the mailing list. I may be at the London e= vent. Regards, Gerben Stam, NICE Systems --_000_4BEAD79F6904AC4FB1917EBA8006628905C0685ACESOUEXC01eunic_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear DISP= ATCH group,

 

SIPREC is a great initiative to s= tandardize the interface for capturing Communication Sessions.

Session Recording is becoming more and= more critical due to Compliance and regulatory changes over the last years= .

 =

The compliance market is requesting more th= an capture only these days

Confirmation is needed to acknowledge the entire Communication Session was= captured correctly.

RTCP= Reports (rfc3611) will help to confirm complete handover of RTP content. <= br>

New requirement is= ‘lossless’ Session Capturing.

Lossless indicating handover of content (RTP) is acknowled= ged by the receiver AND in case of receiving issues, the sender will resend= .

Reasons for loss may be = UDP packet loss or receiver failing(over) and temporary not able to accept = content.

Current approach = to address this ‘lossless’ requirement is using 2 independent p= arallel receivers.
This requires the sender to send 2 individual stream= s, in fact 2 independent SIPREC sessions.
Not sure if this is covered c= urrently as supported SIPREC deployment. We do see implementations based on= SIPREC supporting it.

Alt= ernative is quick failover at receiver in case of failure but as sender wil= l send only once, this may lead to loss during failover.<= /p>

 

I am not aware of any rfc covering lossless content handover, b= ut there may be standards covering this already.

<= /p>

Looking forward to discussion on the mailing= list. I may be at the London event.

 

Regards,=

 <= /p>

Gerben Stam,

NICE Systems

=   

= --_000_4BEAD79F6904AC4FB1917EBA8006628905C0685ACESOUEXC01eunic_-- From rmohanr@cisco.com Thu Feb 6 06:45:33 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0DF1A013F for ; Thu, 6 Feb 2014 06:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qu8X8nkPdsv0 for ; Thu, 6 Feb 2014 06:45:32 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2BBC41A013C for ; Thu, 6 Feb 2014 06:45:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2156; q=dns/txt; s=iport; t=1391697931; x=1392907531; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=3U9TGHQAEPuSXSzMB7x2yJkicAC5E/eoTl9RyqPtet0=; b=ZOc+NX64jvEyj811qcQcbcZHx4VNnCX4HXA6+VhMcyiqM6bnw9WlUylj 7WG23BRr3tMs+J6MOFMDIZkQZbhPQ/wtWFWtpbA7ezziLvf5iv9m4a8dO 9dnegXSz4x2LISRw1aBJ4pSGIS8J4X7xkgRZSrcJ2WLb7AGchceF/YukE U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHyf81KtJV2a/2dsb2JhbABZgwyBD75xgQkWdIIlAQIEbgsSAQgRAwECYR0KBA4FiAXOQBeOJlSEPwEDmCuSIYMtgWgkHg X-IronPort-AV: E=Sophos;i="4.95,793,1384300800"; d="scan'208";a="18455516" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 06 Feb 2014 14:45:30 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s16EjTge024793 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 14:45:30 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.191]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 08:45:29 -0600 From: "Ram Mohan R (rmohanr)" To: Gerben Stam Thread-Topic: [dispatch] Lossless Recording in SIPREC Thread-Index: AQHPI0oUlxg3oGMnMkuQdmHH8d3jZA== Date: Thu, 6 Feb 2014 14:45:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.70.221] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 14:45:33 -0000 Hi, Is there a reason why you want to have this discussion in dispatch and not in SIPREC WG which is meant to discuss the issues around SIP recording ? If you don=B9t have any specific reason to do it here you may want to start this discussion in SIPREC WG. I do have some comments on this topic but I think SIPREC WG is the right place to have those discussions. Regards, Ram From: Gerben Stam Date: Thursday, 6 February 2014 3:58 pm To: Gerben Stam Cc: "dispatch@ietf.org" Subject: [dispatch] Lossless Recording in SIPREC Dear DISPATCH group, =20 SIPREC is a great initiative to standardize the interface for capturing Communication Sessions. Session Recording is becoming more and more critical due to Compliance and regulatory changes over the last years. =20 The compliance market is requesting more than capture only these days Confirmation is needed to acknowledge the entire Communication Session was captured correctly. RTCP Reports (rfc3611) will help to confirm complete handover of RTP content. New requirement is =8Clossless=B9 Session Capturing. Lossless indicating handover of content (RTP) is acknowledged by the receiver AND in case of receiving issues, the sender will resend. Reasons for loss may be UDP packet loss or receiver failing(over) and temporary not able to accept content. Current approach to address this =8Clossless=B9 requirement is using 2 independent parallel receivers. This requires the sender to send 2 individual streams, in fact 2 independent SIPREC sessions. Not sure if this is covered currently as supported SIPREC deployment. We do see implementations based on SIPREC supporting it. Alternative is quick failover at receiver in case of failure but as sender will send only once, this may lead to loss during failover. =20 I am not aware of any rfc covering lossless content handover, but there may be standards covering this already. Looking forward to discussion on the mailing list. I may be at the London event. =20 Regards, =20 Gerben Stam, NICE Systems =20 From Gerben.Stam@nice.com Thu Feb 6 07:10:51 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733EC1A0184 for ; Thu, 6 Feb 2014 07:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rii6JHh-6kbD for ; Thu, 6 Feb 2014 07:10:49 -0800 (PST) Received: from soumd01.eu.nice.com (ukemail.nice.com [195.99.0.242]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9571A013C for ; Thu, 6 Feb 2014 07:10:49 -0800 (PST) Received: from SOUCAS02.eu.nice.com ([10.1.1.10]) by soumd01.eu.nice.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 6 Feb 2014 15:10:14 +0000 Received: from SOUEXC01.eu.nice.com ([fe80::759b:eded:96a6:f00e]) by SOUCAS02.eu.nice.com ([::1]) with mapi; Thu, 6 Feb 2014 15:10:14 +0000 From: Gerben Stam To: "Ram Mohan R (rmohanr)" Date: Thu, 6 Feb 2014 15:10:12 +0000 Thread-Topic: [dispatch] Lossless Recording in SIPREC Thread-Index: AQHPI0oUlxg3oGMnMkuQdmHH8d3jZJqoU3/Q Message-ID: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 06 Feb 2014 15:10:14.0996 (UTC) FILETIME=[89E4C940:01CF234D] Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 15:10:51 -0000 Hey Ram, I have had an off-line discussion with Andrew Hutton, chairman of the SIPRE= C group. He suggested to post this on the IETF dispatch group as it is a good topic = to discuss in the team. What would I need to do to bend this to SIPREC WG instead of Dispatch? Regards, Gerben -----Original Message----- From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]=20 Sent: donderdag 6 februari 2014 15:45 To: Gerben Stam Cc: dispatch@ietf.org Subject: Re: [dispatch] Lossless Recording in SIPREC Hi, Is there a reason why you want to have this discussion in dispatch and not = in SIPREC WG which is meant to discuss the issues around SIP recording ? If you don=B9t have any specific reason to do it here you may want to start= this discussion in SIPREC WG. I do have some comments on this topic but I think SIPREC WG is the right pl= ace to have those discussions. Regards, Ram From: Gerben Stam Date: Thursday, 6 February 2014 3:58 pm To: Gerben Stam Cc: "dispatch@ietf.org" Subject: [dispatch] Lossless Recording in SIPREC Dear DISPATCH group, =20 SIPREC is a great initiative to standardize the interface for capturing Com= munication Sessions. Session Recording is becoming more and more critical due to Compliance and = regulatory changes over the last years. =20 The compliance market is requesting more than capture only these days Confi= rmation is needed to acknowledge the entire Communication Session was captu= red correctly. RTCP Reports (rfc3611) will help to confirm complete handover of RTP conten= t. New requirement is =8Clossless=B9 Session Capturing. Lossless indicating handover of content (RTP) is acknowledged by the receiv= er AND in case of receiving issues, the sender will resend. Reasons for loss may be UDP packet loss or receiver failing(over) and tempo= rary not able to accept content. Current approach to address this =8Clossless=B9 requirement is using 2 inde= pendent parallel receivers. This requires the sender to send 2 individual streams, in fact 2 independen= t SIPREC sessions. Not sure if this is covered currently as supported SIPREC deployment. We do= see implementations based on SIPREC supporting it. Alternative is quick failover at receiver in case of failure but as sender = will send only once, this may lead to loss during failover. =20 I am not aware of any rfc covering lossless content handover, but there may= be standards covering this already. Looking forward to discussion on the mailing list. I may be at the London e= vent. =20 Regards, =20 Gerben Stam, NICE Systems =20 From pkyzivat@alum.mit.edu Thu Feb 6 07:33:12 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCCB1A0186 for ; Thu, 6 Feb 2014 07:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5t329uQ_SQFj for ; Thu, 6 Feb 2014 07:33:09 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id AC4B61A013D for ; Thu, 6 Feb 2014 07:33:09 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta04.westchester.pa.mail.comcast.net with comcast id P0PA1n0040cZkys543Z8sN; Thu, 06 Feb 2014 15:33:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id P3Z81n00s3ZTu2S3W3Z8lx; Thu, 06 Feb 2014 15:33:08 +0000 Message-ID: <52F3AB34.5000508@alum.mit.edu> Date: Thu, 06 Feb 2014 10:33:08 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <4BEAD79F6904AC4FB1917EBA8006628905C0685ACE@SOUEXC01.eu.nice.com> In-Reply-To: <4BEAD79F6904AC4FB1917EBA8006628905C0685ACE@SOUEXC01.eu.nice.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391700788; bh=N60DKlyFk56zyhXreJc8S+gStqmTMsusyJ2953QhEDE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oI/0dk+gaacaRHAXfJG2cjogPzIuJgO+LKvuWaNWPgQnvjJgG6L5g2Kxrke8S+9BH lMs0/wBncwbGoK3ptvAf6b7so+HHLElIo4tUrUStzpflG5h/SJPAfXftJTs04L7qEv xoex16fWRLJ+v6hBhAPP/hzNuCxHv57F8auOoCnW88A/t2PHf6VIoJDFWNWaxdS6Ys uldVdYtCxLGxNETWZ0ZmnSM1hO+uCri6Na/NCNtuPzpT/gQofG4fumC6OAed0nuyr5 hcR6Fq8SUXiGzADUX39qlbQKM384Z7IkRBrwS8w8Af9P13B/AR1c+VqCIl4RL644Z/ S9u3hCvnaLK0Q== Subject: Re: [dispatch] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 15:33:12 -0000 On 2/6/14 5:28 AM, Gerben Stam wrote: > Dear DISPATCH group, > > SIPREC is a great initiative to standardize the interface for capturing > Communication Sessions. > > Session Recording is becoming more and more critical due to Compliance > and regulatory changes over the last years. > > The compliance market is requesting more than capture only these days > > Confirmation is needed to acknowledge the entire Communication Session > was captured correctly. > > RTCP Reports (rfc3611) will help to confirm complete handover of RTP > content. > > New requirement is ‘lossless’ Session Capturing. > > Lossless indicating handover of content (RTP) is acknowledged by the > receiver AND in case of receiving issues, the sender will resend. I am a novice at this subject, but ISTM that trying to invent something new to achieve reliability here is a bad idea. There are already RTP mechanisms that increase reliability of delivery. (E.g., FEC) And if that isn't good enough, then it is possible to use a reliable transport. But a reliable transport ceases to be real-time. That is presumably ok for recording, but in turn it means the SRC would need to buffer - potentially an arbitrary amount of buffering. > Reasons for loss may be UDP packet loss or receiver failing(over) and > temporary not able to accept content. > > Current approach to address this ‘lossless’ requirement is using 2 > independent parallel receivers. > This requires the sender to send 2 individual streams, in fact 2 > independent SIPREC sessions. > Not sure if this is covered currently as supported SIPREC deployment. We > do see implementations based on SIPREC supporting it. It is certainly acceptable for an SRC to establish sessions with multiple SRSs. We don't need any specific language to permit that. And if you prefer, and can arrange it, you can have two different SRCs in the same CS, each recording to the same, or different, SRSs. Thanks, Paul > Alternative is quick failover at receiver in case of failure but as > sender will send only once, this may lead to loss during failover. > > I am not aware of any rfc covering lossless content handover, but there > may be standards covering this already. > > Looking forward to discussion on the mailing list. I may be at the > London event. > > Regards, > > Gerben Stam, > > NICE Systems > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From rmohanr@cisco.com Thu Feb 6 08:19:57 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5EC1A03CB for ; Thu, 6 Feb 2014 08:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.036 X-Spam-Level: X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcy8HaJOFOlg for ; Thu, 6 Feb 2014 08:19:55 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id E10AD1A03C5 for ; Thu, 6 Feb 2014 08:19:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5006; q=dns/txt; s=iport; t=1391703594; x=1392913194; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=E40FflHB52wMKlRea17F7BA23XEJczeyZPcpSYIjYWg=; b=Mh+dNqdK5snjDVdW0eftZAsrJ06pY7VT2lOd5LU6Syn1YITUdttd1JBy d+obNNEEd6oRZkMfy2qLo1kmFIpaEDhhbJS/zXBmGsDytwX+ZLFReHb+9 s2iu1iOk/Pp0VgRofqIenLNrIs9jL5iETApkvNgsHav4i9Tey4NQklOAr k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAEy181KtJXHB/2dsb2JhbABZgwyBD4MBu3AYcxZ0giUBAQEDASMROgsFBwQCAQgRAwEBAQMCIwMCAgIwFAEICAIEDgWHfQisd6EiF4EpjH0hCCsHBAKCaYFJAQOYK5Ihgy2BaCQe X-IronPort-AV: E=Sophos;i="4.95,793,1384300800"; d="scan'208";a="18481953" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-6.cisco.com with ESMTP; 06 Feb 2014 16:19:53 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s16GJrYe006698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 16:19:53 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.191]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 10:19:53 -0600 From: "Ram Mohan R (rmohanr)" To: Gerben Stam Thread-Topic: [dispatch] Lossless Recording in SIPREC Thread-Index: AQHPI1dDJyXBrcc2c0ma7EaQoC0IXw== Date: Thu, 6 Feb 2014 16:19:52 +0000 Message-ID: References: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> In-Reply-To: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.65.70.221] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 16:19:57 -0000 SGksDQoNClBsZWFzZSBzZWUgaW5saW5lDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBHZXJiZW4gU3RhbSA8R2VyYmVuLlN0YW1AbmljZS5jb20+DQpEYXRlOiBUaHVyc2RheSwg NiBGZWJydWFyeSAyMDE0IDg6NDAgcG0NClRvOiBDaXNjbyBFbXBsb3llZSA8cm1vaGFuckBjaXNj by5jb20+DQpDYzogImRpc3BhdGNoQGlldGYub3JnIiA8ZGlzcGF0Y2hAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSRTogW2Rpc3BhdGNoXSBMb3NzbGVzcyBSZWNvcmRpbmcgaW4gU0lQUkVDDQoNCj5IZXkg UmFtLA0KPg0KPkkgaGF2ZSBoYWQgYW4gb2ZmLWxpbmUgZGlzY3Vzc2lvbiB3aXRoIEFuZHJldyBI dXR0b24sIGNoYWlybWFuIG9mIHRoZQ0KPlNJUFJFQyBncm91cC4NCj5IZSBzdWdnZXN0ZWQgdG8g cG9zdCB0aGlzIG9uIHRoZSBJRVRGIGRpc3BhdGNoIGdyb3VwIGFzIGl0IGlzIGEgZ29vZA0KPnRv cGljIHRvIGRpc2N1c3MgaW4gdGhlIHRlYW0uDQoNCk9rLiBJIHdhcyBub3QgYXdhcmUgb2YgdGhp cy4NCg0KPg0KPldoYXQgd291bGQgSSBuZWVkIHRvIGRvIHRvIGJlbmQgdGhpcyB0byBTSVBSRUMg V0cgaW5zdGVhZCBvZiBEaXNwYXRjaD8NCj4NCj5SZWdhcmRzLA0KPg0KPkdlcmJlbg0KPg0KPi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogUmFtIE1vaGFuIFIgKHJtb2hhbnIpIFtt YWlsdG86cm1vaGFuckBjaXNjby5jb21dDQo+U2VudDogZG9uZGVyZGFnIDYgZmVicnVhcmkgMjAx NCAxNTo0NQ0KPlRvOiBHZXJiZW4gU3RhbQ0KPkNjOiBkaXNwYXRjaEBpZXRmLm9yZw0KPlN1Ympl Y3Q6IFJlOiBbZGlzcGF0Y2hdIExvc3NsZXNzIFJlY29yZGluZyBpbiBTSVBSRUMNCj4NCj5IaSwN Cj4NCj5JcyB0aGVyZSBhIHJlYXNvbiB3aHkgeW91IHdhbnQgdG8gaGF2ZSB0aGlzIGRpc2N1c3Np b24gaW4gZGlzcGF0Y2ggYW5kDQo+bm90IGluIFNJUFJFQyBXRyB3aGljaCBpcyBtZWFudCB0byBk aXNjdXNzIHRoZSBpc3N1ZXMgYXJvdW5kIFNJUA0KPnJlY29yZGluZyA/DQo+SWYgeW91IGRvbsK5 dCBoYXZlIGFueSBzcGVjaWZpYyByZWFzb24gdG8gZG8gaXQgaGVyZSB5b3UgbWF5IHdhbnQgdG8g c3RhcnQNCj50aGlzIGRpc2N1c3Npb24gaW4gU0lQUkVDIFdHLg0KPg0KPkkgZG8gaGF2ZSBzb21l IGNvbW1lbnRzIG9uIHRoaXMgdG9waWMgYnV0IEkgdGhpbmsgU0lQUkVDIFdHIGlzIHRoZSByaWdo dA0KPnBsYWNlIHRvIGhhdmUgdGhvc2UgZGlzY3Vzc2lvbnMuDQo+DQo+DQo+UmVnYXJkcywNCj5S YW0NCj4NCj5Gcm9tOiAgR2VyYmVuIFN0YW0gPEdlcmJlbi5TdGFtQG5pY2UuY29tPg0KPkRhdGU6 ICBUaHVyc2RheSwgNiBGZWJydWFyeSAyMDE0IDM6NTggcG0NCj5UbzogIEdlcmJlbiBTdGFtIDxH ZXJiZW4uU3RhbUBuaWNlLmNvbT4NCj5DYzogICJkaXNwYXRjaEBpZXRmLm9yZyIgPGRpc3BhdGNo QGlldGYub3JnPg0KPlN1YmplY3Q6ICBbZGlzcGF0Y2hdIExvc3NsZXNzIFJlY29yZGluZyBpbiBT SVBSRUMNCj4NCj4NCj5EZWFyIERJU1BBVENIIGdyb3VwLA0KPiANCj5TSVBSRUMgaXMgYSBncmVh dCBpbml0aWF0aXZlIHRvIHN0YW5kYXJkaXplIHRoZSBpbnRlcmZhY2UgZm9yIGNhcHR1cmluZw0K PkNvbW11bmljYXRpb24gU2Vzc2lvbnMuDQo+U2Vzc2lvbiBSZWNvcmRpbmcgaXMgYmVjb21pbmcg bW9yZSBhbmQgbW9yZSBjcml0aWNhbCBkdWUgdG8gQ29tcGxpYW5jZQ0KPmFuZCByZWd1bGF0b3J5 IGNoYW5nZXMgb3ZlciB0aGUgbGFzdCB5ZWFycy4NCj4gDQo+VGhlIGNvbXBsaWFuY2UgbWFya2V0 IGlzIHJlcXVlc3RpbmcgbW9yZSB0aGFuIGNhcHR1cmUgb25seSB0aGVzZSBkYXlzDQo+Q29uZmly bWF0aW9uIGlzIG5lZWRlZCB0byBhY2tub3dsZWRnZSB0aGUgZW50aXJlIENvbW11bmljYXRpb24g U2Vzc2lvbg0KPndhcyBjYXB0dXJlZCBjb3JyZWN0bHkuDQo+UlRDUCBSZXBvcnRzIChyZmMzNjEx KSB3aWxsIGhlbHAgdG8gY29uZmlybSBjb21wbGV0ZSBoYW5kb3ZlciBvZiBSVFANCj5jb250ZW50 Lg0KPg0KPg0KPg0KPk5ldyByZXF1aXJlbWVudCBpcyDFkmxvc3NsZXNzwrkgU2Vzc2lvbiBDYXB0 dXJpbmcuDQoNCldoeSBpcyB0aGlzIGEgbmV3IHJlcXVpcmVtZW50ID8gUkZDIDYzNDEgKFNJUFJF QyByZXF1aXJlbWVudHMpIGFscmVhZHkgaGFzDQphIHJlcXVpcmVtZW50IGZvciBMb3NzbGVzcyBy ZWNvcmRpbmcuIFNlZSBSRVEgMDA1Lg0KDQoNCj5Mb3NzbGVzcyBpbmRpY2F0aW5nIGhhbmRvdmVy IG9mIGNvbnRlbnQgKFJUUCkgaXMgYWNrbm93bGVkZ2VkIGJ5IHRoZQ0KPnJlY2VpdmVyIEFORCBp biBjYXNlIG9mIHJlY2VpdmluZyBpc3N1ZXMsIHRoZSBzZW5kZXIgd2lsbCByZXNlbmQuDQo+UmVh c29ucyBmb3IgbG9zcyBtYXkgYmUgVURQIHBhY2tldCBsb3NzIG9yIHJlY2VpdmVyIGZhaWxpbmco b3ZlcikgYW5kDQo+dGVtcG9yYXJ5IG5vdCBhYmxlIHRvIGFjY2VwdCBjb250ZW50Lg0KPkN1cnJl bnQgYXBwcm9hY2ggdG8gYWRkcmVzcyB0aGlzIMWSbG9zc2xlc3PCuSByZXF1aXJlbWVudCBpcyB1 c2luZyAyDQo+aW5kZXBlbmRlbnQgcGFyYWxsZWwgcmVjZWl2ZXJzLg0KDQpUaGVyZSBtYXkgYmUg b3RoZXIgYXBwcm9hY2hlcyB3ZWxsLiBGb3IgZXhhbXBsZSBhbiBTUkMgbWF5IGJ1ZmZlciBmb3Ig YQ0Kc21hbGwgZHVyYXRpb24gdG8gdGFrZSBjYXJlIG9mIHRoZSBsb3NzLiBUd28gcGFyYWxsZWwg cmVjZWl2ZXJzIHN0aWxsIGRvZXMNCm5vdCBndWFyYW50ZWUgdGhhdCByZWNvcmRpbmcgaXMgbG9z ZWxlc3MgYXMgeW91IGNhbiBoYXZlIFVEUCBwYWNrZXQgbG9zcw0Kb24gYm90aCBwYXRocy4NCg0K Pg0KPlRoaXMgcmVxdWlyZXMgdGhlIHNlbmRlciB0byBzZW5kIDIgaW5kaXZpZHVhbCBzdHJlYW1z LCBpbiBmYWN0IDINCj5pbmRlcGVuZGVudCBTSVBSRUMgc2Vzc2lvbnMuDQo+DQo+Tm90IHN1cmUg aWYgdGhpcyBpcyBjb3ZlcmVkIGN1cnJlbnRseSBhcyBzdXBwb3J0ZWQgU0lQUkVDIGRlcGxveW1l bnQuDQoNCg0KQ3VycmVudCBTSVBSRUMgZG9lcyBub3QgaGF2ZSBhbnkgc3VjaCBjb25zdHJhaW50 cy4gRGVwZW5kaW5nIG9uIHlvdXINCmltcGxlbWVudGF0aW9uIG1vZGVsIHlvdSBjYW4gaGF2ZSB0 aGUgc2FtZSBDUyByZWNvcmRlZCBieSBtdWx0aXBsZSBTUkMgb3INCmhhdmUgc2FtZSBTUkMgZG8g bXVsdGlwbGUgcmVjb3JkaW5ncyBvZiBzYW1lIENTLg0KDQpSZWdhcmRzLA0KUmFtDQoNCj4gV2Ug ZG8gc2VlIGltcGxlbWVudGF0aW9ucyBiYXNlZCBvbiBTSVBSRUMgc3VwcG9ydGluZyBpdC4NCj5B bHRlcm5hdGl2ZSBpcyBxdWljayBmYWlsb3ZlciBhdCByZWNlaXZlciBpbiBjYXNlIG9mIGZhaWx1 cmUgYnV0IGFzDQo+c2VuZGVyIHdpbGwgc2VuZCBvbmx5IG9uY2UsIHRoaXMgbWF5IGxlYWQgdG8g bG9zcyBkdXJpbmcgZmFpbG92ZXIuDQo+IA0KPkkgYW0gbm90IGF3YXJlIG9mIGFueSByZmMgY292 ZXJpbmcgbG9zc2xlc3MgY29udGVudCBoYW5kb3ZlciwgYnV0IHRoZXJlDQo+bWF5IGJlIHN0YW5k YXJkcyBjb3ZlcmluZyB0aGlzIGFscmVhZHkuDQo+DQo+DQo+TG9va2luZyBmb3J3YXJkIHRvIGRp c2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdC4gSSBtYXkgYmUgYXQgdGhlIExvbmRvbg0KPmV2 ZW50Lg0KPiANCj5SZWdhcmRzLA0KPiANCj5HZXJiZW4gU3RhbSwNCj5OSUNFIFN5c3RlbXMNCj4g IA0KPg0KDQo= From partha@parthasarathi.co.in Thu Feb 6 08:51:23 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C5E1A0426; Thu, 6 Feb 2014 08:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVolrR65g9Ph; Thu, 6 Feb 2014 08:51:22 -0800 (PST) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.234]) by ietfa.amsl.com (Postfix) with ESMTP id C52661A0434; Thu, 6 Feb 2014 08:51:19 -0800 (PST) Received: from userPC (unknown [122.166.182.79]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 2DE89639140; Thu, 6 Feb 2014 16:51:12 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1391705478; bh=4kwcp91q7+Gyh8VMzBLoBEmcUYsI+93jdmnj6rpkgrE=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Iy1q9QfHuB9DzpT4s8+JNGa/irX3lRutteUat4fNCiw2xxhP4jbI4g6tx6A2lEdqe j4QlowHTMfZBy6am51AfEP8mb64iVEMlaN+oNQGdImTZkBxtOu2ze4dmrCQIznAI3x IWaiv9n6JS8wlWklEvolhstjFSlacjvYolsOXg8k= From: "Parthasarathi R" To: "'Ram Mohan R \(rmohanr\)'" , "'Gerben Stam'" References: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> In-Reply-To: Date: Thu, 6 Feb 2014 22:21:06 +0530 Message-ID: <00dd01cf235b$a5401470$efc03d50$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHPI1dDJyXBrcc2c0ma7EaQoC0IX5qobTRg Content-Language: en-us X-CTCH-RefID: str=0001.0A020201.52F3BD86.012C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: siprec@ietf.org, dispatch@ietf.org Subject: Re: [dispatch] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 16:51:24 -0000 Hi Gerben, I agree with Ram that lossless recording is within SIPREC requirement as = mentioned in RFC 6341. Apart from REQ-5 in RFC 6341, some of the text = related to High availability is mentioned in the note of this mail. Also, the lossless recording shall be achieved by multiple means. One of = the mechanism is explained in draft-ietf-avtext-rtp-duplication-04. IMO, = let us discuss in SIPREC about the specific technical issue in lossless = recording which is not possible to be achieved through the existing = mechanism=20 Including SIPREC mailing alias in this mail thread. Thanks Partha Note: Use Case 10: High availability and continuous recording. Specific deployment scenarios present different requirements for system availability, error handling, etc., including the following: o An SRS must always be available at call setup time. o No loss of media recording can occur, including during failure of an SRS. o The Communication Session must be terminated (or suitable notification given to parties) in the event of a recording failure. REQ-021: The mechanism MUST NOT prevent high-availability deployments.=20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ram > Mohan R (rmohanr) > Sent: Thursday, February 06, 2014 9:50 PM > To: Gerben Stam > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Lossless Recording in SIPREC >=20 > Hi, >=20 > Please see inline >=20 > -----Original Message----- > From: Gerben Stam > Date: Thursday, 6 February 2014 8:40 pm > To: Cisco Employee > Cc: "dispatch@ietf.org" > Subject: RE: [dispatch] Lossless Recording in SIPREC >=20 > >Hey Ram, > > > >I have had an off-line discussion with Andrew Hutton, chairman of the > >SIPREC group. > >He suggested to post this on the IETF dispatch group as it is a good > >topic to discuss in the team. >=20 > Ok. I was not aware of this. >=20 > > > >What would I need to do to bend this to SIPREC WG instead of = Dispatch? > > > >Regards, > > > >Gerben > > > >-----Original Message----- > >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >Sent: donderdag 6 februari 2014 15:45 > >To: Gerben Stam > >Cc: dispatch@ietf.org > >Subject: Re: [dispatch] Lossless Recording in SIPREC > > > >Hi, > > > >Is there a reason why you want to have this discussion in dispatch = and > >not in SIPREC WG which is meant to discuss the issues around SIP > >recording ? > >If you don=C2=B9t have any specific reason to do it here you may want = to > start > >this discussion in SIPREC WG. > > > >I do have some comments on this topic but I think SIPREC WG is the > right > >place to have those discussions. > > > > > >Regards, > >Ram > > > >From: Gerben Stam > >Date: Thursday, 6 February 2014 3:58 pm > >To: Gerben Stam > >Cc: "dispatch@ietf.org" > >Subject: [dispatch] Lossless Recording in SIPREC > > > > > >Dear DISPATCH group, > > > >SIPREC is a great initiative to standardize the interface for > capturing > >Communication Sessions. > >Session Recording is becoming more and more critical due to = Compliance > >and regulatory changes over the last years. > > > >The compliance market is requesting more than capture only these days > >Confirmation is needed to acknowledge the entire Communication = Session > >was captured correctly. > >RTCP Reports (rfc3611) will help to confirm complete handover of RTP > >content. > > > > > > > >New requirement is =C5=92lossless=C2=B9 Session Capturing. >=20 > Why is this a new requirement ? RFC 6341 (SIPREC requirements) already > has > a requirement for Lossless recording. See REQ 005. >=20 >=20 > >Lossless indicating handover of content (RTP) is acknowledged by the > >receiver AND in case of receiving issues, the sender will resend. > >Reasons for loss may be UDP packet loss or receiver failing(over) and > >temporary not able to accept content. > >Current approach to address this =C5=92lossless=C2=B9 requirement is = using 2 > >independent parallel receivers. >=20 > There may be other approaches well. For example an SRC may buffer for = a > small duration to take care of the loss. Two parallel receivers still > does > not guarantee that recording is loseless as you can have UDP packet > loss > on both paths. >=20 > > > >This requires the sender to send 2 individual streams, in fact 2 > >independent SIPREC sessions. > > > >Not sure if this is covered currently as supported SIPREC deployment. >=20 >=20 > Current SIPREC does not have any such constraints. Depending on your > implementation model you can have the same CS recorded by multiple SRC > or > have same SRC do multiple recordings of same CS. >=20 > Regards, > Ram >=20 > > We do see implementations based on SIPREC supporting it. > >Alternative is quick failover at receiver in case of failure but as > >sender will send only once, this may lead to loss during failover. > > > >I am not aware of any rfc covering lossless content handover, but > there > >may be standards covering this already. > > > > > >Looking forward to discussion on the mailing list. I may be at the > London > >event. > > > >Regards, > > > >Gerben Stam, > >NICE Systems > > > > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Thu Feb 6 09:12:18 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276F31A03F2; Thu, 6 Feb 2014 09:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIwwbF7Z4D0L; Thu, 6 Feb 2014 09:12:13 -0800 (PST) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 927E91A03E1; Thu, 6 Feb 2014 09:12:13 -0800 (PST) Received: by mail-ie0-f182.google.com with SMTP id lx4so838048iec.13 for ; Thu, 06 Feb 2014 09:12:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iaUOFBbOtP1LCDT54dZqhbl/gMtjjCahEdBECaBOe3M=; b=yeJCOfzBDSXMjkBR1bYO2GmSsIAJgvFbTlZTDTLdMMF1LzUvN137L6Dd3TeZIXOuwU m4w+uw2Nn1fuYQE77TkuPLyhm+GSXSKYRBTtipPXTWVbV6JRnaqD1s8ixVPRm66v7HZP xNckyfola82e2sPK/hP+V1E7J75bL8hIE5/9IYJDAJUlOBq96nKiDDWMNZ/mG/W7+me7 MOnCl6OgHatZa6Rvb4SEFSD6R2zuMBmytQ0jQUIzcKKhGJw2O0+wFLjw/9t4cJoZMUIu li66cQUYr8FXBeFyhUAn1m7q04cN3rEZl3ZWwGWR56JATQxynfwIItKfmXu2msNsBQv9 pJDA== MIME-Version: 1.0 X-Received: by 10.50.114.4 with SMTP id jc4mr822953igb.0.1391706722913; Thu, 06 Feb 2014 09:12:02 -0800 (PST) Received: by 10.43.58.137 with HTTP; Thu, 6 Feb 2014 09:12:02 -0800 (PST) In-Reply-To: <00dd01cf235b$a5401470$efc03d50$@co.in> References: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <00dd01cf235b$a5401470$efc03d50$@co.in> Date: Thu, 6 Feb 2014 11:12:02 -0600 Message-ID: From: Mary Barnes To: Parthasarathi R Content-Type: multipart/alternative; boundary=047d7b2e0983da759104f1bff830 Cc: Gerben Stam , "siprec@ietf.org" , DISPATCH Subject: Re: [dispatch] [siprec] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 17:12:18 -0000 --047d7b2e0983da759104f1bff830 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please don't cross post as that makes it a nightmare for people who like to put emails for various WGs in separate folders. The IETF email system is setup to avoid duplicates and also people are not subscribed always to both lists and that results in messages in moderator queues. It is a good idea however to post a note to the SIPREC mailing list that this discussion is happening on the DISPATCH WG mailing list - including a link to the discussion thread. Thanks, Mary. On Thu, Feb 6, 2014 at 10:51 AM, Parthasarathi R wrote: > Hi Gerben, > > I agree with Ram that lossless recording is within SIPREC requirement as > mentioned in RFC 6341. Apart from REQ-5 in RFC 6341, some of the text > related to High availability is mentioned in the note of this mail. > > Also, the lossless recording shall be achieved by multiple means. One of > the mechanism is explained in draft-ietf-avtext-rtp-duplication-04. IMO, > let us discuss in SIPREC about the specific technical issue in lossless > recording which is not possible to be achieved through the existing > mechanism > > Including SIPREC mailing alias in this mail thread. > > Thanks > Partha > > Note: > > Use Case 10: High availability and continuous recording. > > Specific deployment scenarios present different requirements for > system availability, error handling, etc., including the > following: > > o An SRS must always be available at call setup time. > > o No loss of media recording can occur, including during failure > of an SRS. > > o The Communication Session must be terminated (or suitable > notification given to parties) in the event of a recording > failure. > > > REQ-021: The mechanism MUST NOT prevent high-availability > deployments. > > > -----Original Message----- > > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ram > > Mohan R (rmohanr) > > Sent: Thursday, February 06, 2014 9:50 PM > > To: Gerben Stam > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] Lossless Recording in SIPREC > > > > Hi, > > > > Please see inline > > > > -----Original Message----- > > From: Gerben Stam > > Date: Thursday, 6 February 2014 8:40 pm > > To: Cisco Employee > > Cc: "dispatch@ietf.org" > > Subject: RE: [dispatch] Lossless Recording in SIPREC > > > > >Hey Ram, > > > > > >I have had an off-line discussion with Andrew Hutton, chairman of the > > >SIPREC group. > > >He suggested to post this on the IETF dispatch group as it is a good > > >topic to discuss in the team. > > > > Ok. I was not aware of this. > > > > > > > >What would I need to do to bend this to SIPREC WG instead of Dispatch? > > > > > >Regards, > > > > > >Gerben > > > > > >-----Original Message----- > > >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > >Sent: donderdag 6 februari 2014 15:45 > > >To: Gerben Stam > > >Cc: dispatch@ietf.org > > >Subject: Re: [dispatch] Lossless Recording in SIPREC > > > > > >Hi, > > > > > >Is there a reason why you want to have this discussion in dispatch and > > >not in SIPREC WG which is meant to discuss the issues around SIP > > >recording ? > > >If you don=B9t have any specific reason to do it here you may want to > > start > > >this discussion in SIPREC WG. > > > > > >I do have some comments on this topic but I think SIPREC WG is the > > right > > >place to have those discussions. > > > > > > > > >Regards, > > >Ram > > > > > >From: Gerben Stam > > >Date: Thursday, 6 February 2014 3:58 pm > > >To: Gerben Stam > > >Cc: "dispatch@ietf.org" > > >Subject: [dispatch] Lossless Recording in SIPREC > > > > > > > > >Dear DISPATCH group, > > > > > >SIPREC is a great initiative to standardize the interface for > > capturing > > >Communication Sessions. > > >Session Recording is becoming more and more critical due to Compliance > > >and regulatory changes over the last years. > > > > > >The compliance market is requesting more than capture only these days > > >Confirmation is needed to acknowledge the entire Communication Session > > >was captured correctly. > > >RTCP Reports (rfc3611) will help to confirm complete handover of RTP > > >content. > > > > > > > > > > > >New requirement is OElossless=B9 Session Capturing. > > > > Why is this a new requirement ? RFC 6341 (SIPREC requirements) already > > has > > a requirement for Lossless recording. See REQ 005. > > > > > > >Lossless indicating handover of content (RTP) is acknowledged by the > > >receiver AND in case of receiving issues, the sender will resend. > > >Reasons for loss may be UDP packet loss or receiver failing(over) and > > >temporary not able to accept content. > > >Current approach to address this OElossless=B9 requirement is using 2 > > >independent parallel receivers. > > > > There may be other approaches well. For example an SRC may buffer for a > > small duration to take care of the loss. Two parallel receivers still > > does > > not guarantee that recording is loseless as you can have UDP packet > > loss > > on both paths. > > > > > > > >This requires the sender to send 2 individual streams, in fact 2 > > >independent SIPREC sessions. > > > > > >Not sure if this is covered currently as supported SIPREC deployment. > > > > > > Current SIPREC does not have any such constraints. Depending on your > > implementation model you can have the same CS recorded by multiple SRC > > or > > have same SRC do multiple recordings of same CS. > > > > Regards, > > Ram > > > > > We do see implementations based on SIPREC supporting it. > > >Alternative is quick failover at receiver in case of failure but as > > >sender will send only once, this may lead to loss during failover. > > > > > >I am not aware of any rfc covering lossless content handover, but > > there > > >may be standards covering this already. > > > > > > > > >Looking forward to discussion on the mailing list. I may be at the > > London > > >event. > > > > > >Regards, > > > > > >Gerben Stam, > > >NICE Systems > > > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > siprec mailing list > siprec@ietf.org > https://www.ietf.org/mailman/listinfo/siprec > --047d7b2e0983da759104f1bff830 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please don't cross post as that makes it a nightmare f= or people who like to put emails for various WGs in separate folders.  = ;The IETF email system is setup to avoid duplicates and also people are not= subscribed always to both lists and that results in messages in moderator = queues.

It is a good idea however to post a note to the SIPREC maili= ng list that this discussion is happening on the DISPATCH WG mailing list -= including a link to the discussion thread.

Thanks= ,
Mary.


On Thu, Feb 6, 2014 at 10:51 AM, Parthasarathi R <partha= @parthasarathi.co.in> wrote:
Hi Gerben,

I agree with Ram that lossless recording is within SIPREC requirement as me= ntioned in RFC 6341. Apart from REQ-5 in RFC 6341, some of the text related= to High availability is mentioned in the note of this mail.

Also, the lossless recording shall be achieved by multiple means. One of th= e mechanism is explained in draft-ietf-avtext-rtp-duplication-04. IMO, let = us discuss in SIPREC about the specific technical issue in lossless recordi= ng which is not possible to be achieved through the existing mechanism

Including SIPREC mailing alias in this mail thread.

Thanks
Partha

Note:

 Use Case 10: High availability and continuous recording.

      Specific deployment scenarios present different requir= ements for
      system availability, error handling, etc., including t= he
      following:

      o  An SRS must always be available at call setup = time.

      o  No loss of media recording can occur, includin= g during failure
         of an SRS.

      o  The Communication Session must be terminated (= or suitable
         notification given to parties) in the eve= nt of a recording
         failure.


REQ-021: The mechanism MUST NOT prevent high-availability
      deployments.

> -----Original Message-----
> From: dispatch [mailto:di= spatch-bounces@ietf.org] On Behalf Of Ram
> Mohan R (rmohanr)
> Sent: Thursday, February 06, 2014 9:50 PM
> To: Gerben Stam
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] Lossless Recording in SIPREC
>
> Hi,
>
> Please see inline
>
> -----Original Message-----
> From: Gerben Stam <Gerben.S= tam@nice.com>
> Date: Thursday, 6 February 2014 8:40 pm
> To: Cisco Employee <rmohanr@ci= sco.com>
> Cc: "dispatch@ietf.org&q= uot; <dispatch@ietf.org>
> Subject: RE: [dispatch] Lossless Recording in SIPREC
>
> >Hey Ram,
> >
> >I have had an off-line discussion with Andrew Hutton, chairman of = the
> >SIPREC group.
> >He suggested to post this on the IETF dispatch group as it is a go= od
> >topic to discuss in the team.
>
> Ok. I was not aware of this.
>
> >
> >What would I need to do to bend this to SIPREC WG instead of Dispa= tch?
> >
> >Regards,
> >
> >Gerben
> >
> >-----Original Message-----
> >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]
> >Sent: donderdag 6 februari 2014 15:45
> >To: Gerben Stam
> >Cc: dispatch@ietf.org
> >Subject: Re: [dispatch] Lossless Recording in SIPREC
> >
> >Hi,
> >
> >Is there a reason why you want to have this discussion in dispatch= and
> >not in SIPREC WG which is meant to discuss the issues around SIP > >recording ?
> >If you don=B9t have any specific reason to do it here you may want= to
> start
> >this discussion in SIPREC WG.
> >
> >I do have some comments on this topic but I think SIPREC WG is the=
> right
> >place to have those discussions.
> >
> >
> >Regards,
> >Ram
> >
> >From:  Gerben Stam <Gerben.Stam@nice.com>
> >Date:  Thursday, 6 February 2014 3:58 pm
> >To:  Gerben Stam <= Gerben.Stam@nice.com>
> >Cc:  "dispatch@ietf= .org" <dispatch@ietf.org>
> >Subject:  [dispatch] Lossless Recording in SIPREC
> >
> >
> >Dear DISPATCH group,
> >
> >SIPREC is a great initiative to standardize the interface for
> capturing
> >Communication Sessions.
> >Session Recording is becoming more and more critical due to Compli= ance
> >and regulatory changes over the last years.
> >
> >The compliance market is requesting more than capture only these d= ays
> >Confirmation is needed to acknowledge the entire Communication Ses= sion
> >was captured correctly.
> >RTCP Reports (rfc3611) will help to confirm complete handover of R= TP
> >content.
> >
> >
> >
> >New requirement is Œlossless=B9 Session Capturing.
>
> Why is this a new requirement ? RFC 6341 (SIPREC requirements) already=
> has
> a requirement for Lossless recording. See REQ 005.
>
>
> >Lossless indicating handover of content (RTP) is acknowledged by t= he
> >receiver AND in case of receiving issues, the sender will resend.<= br> > >Reasons for loss may be UDP packet loss or receiver failing(over) = and
> >temporary not able to accept content.
> >Current approach to address this Œlossless=B9 requirement is= using 2
> >independent parallel receivers.
>
> There may be other approaches well. For example an SRC may buffer for = a
> small duration to take care of the loss. Two parallel receivers still<= br> > does
> not guarantee that recording is loseless as you can have UDP packet > loss
> on both paths.
>
> >
> >This requires the sender to send 2 individual streams, in fact 2 > >independent SIPREC sessions.
> >
> >Not sure if this is covered currently as supported SIPREC deployme= nt.
>
>
> Current SIPREC does not have any such constraints. Depending on your > implementation model you can have the same CS recorded by multiple SRC=
> or
> have same SRC do multiple recordings of same CS.
>
> Regards,
> Ram
>
> > We do see implementations based on SIPREC supporting it.
> >Alternative is quick failover at receiver in case of failure but a= s
> >sender will send only once, this may lead to loss during failover.=
> >
> >I am not aware of any rfc covering lossless content handover, but<= br> > there
> >may be standards covering this already.
> >
> >
> >Looking forward to discussion on the mailing list. I may be at the=
> London
> >event.
> >
> >Regards,
> >
> >Gerben Stam,
> >NICE Systems
> >
> >
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

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

--047d7b2e0983da759104f1bff830-- From worley@shell01.TheWorld.com Thu Feb 6 11:21:28 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36631A0469 for ; Thu, 6 Feb 2014 11:21:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gWPVeSBwg4Ge for ; Thu, 6 Feb 2014 11:21:27 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id A47751A045A for ; Thu, 6 Feb 2014 11:21:27 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s16JKGfl012342; Thu, 6 Feb 2014 14:20:18 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s16JF2av4389550; Thu, 6 Feb 2014 14:15:02 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s16JEva54399000; Thu, 6 Feb 2014 14:14:57 -0500 (EST) Date: Thu, 6 Feb 2014 14:14:57 -0500 (EST) Message-Id: <201402061914.s16JEva54399000@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Jim Forster In-reply-to: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> (jim.forster@rangenetworks.com) References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 19:21:29 -0000 It's certainly an interesting project. It looks to me like you're looking for support in regard to which SIP standards the user agent should support. The best practices of implementing SIP user agents, as it were. If you are making an organized project of this, I can see the value of clearly documenting it. > Use of SIP Re-invite for hand-over when a mobile phone moves from > one BTS to a neighbor In practice, I would expect INVITE-with-Replaces to be used for handovers. But I suspect that you haven't designed how to do handovers yet. That's going to be an interesting problem... Dale From dave@cridland.net Thu Feb 6 15:02:51 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090B61A0525 for ; Thu, 6 Feb 2014 15:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZsmWLv9Shnly for ; Thu, 6 Feb 2014 15:02:49 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5831A0521 for ; Thu, 6 Feb 2014 15:02:49 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id vb8so3085797obc.17 for ; Thu, 06 Feb 2014 15:02:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=oVeB7wfFaXE5+k5jcRknXZsEJdGY1wolqNWeac//I4k=; b=G601cPwtoXoi6KblfAmDVL2MMlomTrOYG/evvOEx2M+B0ZSHtzH6+T1nfW8cTOnoW/ FzAS+1sHY/yv0xFagbEb5ZmeeaIw2Te+iR4n4shVF6PB1zpwdAA8XfmLUCLxfERBKs3I jJH1Ztm9UMaomDtskFjsnUQKNPuHTXf3OX8I0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc :content-type; bh=oVeB7wfFaXE5+k5jcRknXZsEJdGY1wolqNWeac//I4k=; b=PC0fBuaOsq7WrkVRfrKSYsRmHBWW6KuKiKk7DzoMJOBoajZwu+aJyovoI86CtX4s3x hfbQkYOzz1dH9vlR7/yMLcENwmS/H7WRCJuYKPkf2oGp7+GBCsXchgarREQO8ARCmSD5 kekAZPY1W863POvVHB/hJb2kGl6gfp10sXL2pzKSM5cE/Vvnw8dEe3o0zoAB4QbCtRA4 D3kRky71XrpyFiPyZxU6lfvi4r6dqEb7zzXB0ildYNTvejiF69n/Fb1kvCr8cLvkKCMh yNTAq0TMFMHOk2LwItjC197vQfrMOF/O5jEUH4wYaW/Keg6SF6EZcgNhWsE6AIBAD/DY GcMw== X-Gm-Message-State: ALoCoQkZ06u14atAVmImYhZz3dOtFtv0etuq/uUQ3JCUQDziR2DAHIJ3nh8bKNh4q7D3Yn687BMN MIME-Version: 1.0 X-Received: by 10.60.165.72 with SMTP id yw8mr4543409oeb.71.1391727767907; Thu, 06 Feb 2014 15:02:47 -0800 (PST) Received: by 10.60.55.138 with HTTP; Thu, 6 Feb 2014 15:02:47 -0800 (PST) Date: Thu, 6 Feb 2014 23:02:47 +0000 Message-ID: From: Dave Cridland To: Olle E Johansson , dispatch@ietf.org Content-Type: multipart/alternative; boundary=047d7b41904b3b081c04f1c4dfd0 X-Mailman-Approved-At: Thu, 06 Feb 2014 15:06:55 -0800 Subject: [dispatch] Review of draft-johansson-dispatch-dane-sip-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 23:02:51 -0000 --047d7b41904b3b081c04f1c4dfd0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Olle, Richard Barnes asked me to read this one over. Sorry to be the harbinger of doom, here - I'll buy you a pint in London. draft-johansson-dispatch-dane-sip-01 TL;DR: I'm not convinced that this document should be adopted or taken further. The reason is that much of what is discusses is actually already covered by RFC 6125, as (hopefully to be) updated by draft-ietf-dane-srv. Energy should be redirected to either dane-srv, or a revision of RFC 6125, or both. Issues (some of which minor): 1) It appears to discuss only server authentication by an end-user client, and not mutual peer authentication of servers. I suspect both are important in SIP (as they are in XMPP). 2) It conflates DANE (which provides constraints on certificates) with DNSSEC (which allows a validating party to use additional reference identifiers securely as in RFC 6125 =A7 6.2.1, as well as providing securit= y for TLSA records). 3) It refers to the AD flag as a definitive guide to the security (in the sense of DNSSEC) of a DNS RR, whereas I thought a client actually has to either check the signatures locally (and essentially disregard this flag) or else have a secure link to a trusted resolver (largely impossible, perhaps loopback). 4) "CNAME" is used without expansion in a document describing both DNS and X.509. 5) It's not using the terms of art established in RFC 6125. This is not to say the document is not valuable - it's sufficiently valuable that we have an RFC covering this area and a further draft expanding upon it - the subject matter is clearly important. I personally think RFC 6125 is very useful, but it might warrant a revisit once DANE-SRV is complete, and I would encourage the author to place any remaining energy in that direction, as well as DANE-SRV itself. This should apply to not only SIP, but other protocols too, and therefore be of wider benefit. As it stands, the draft already restates some of RFC 6125, but lacks much of the depth and coverage - entirely understandable in an early stage draft, but it does suggest there's a lot of work to be done, and the work has been done already. The additional discussion of TLSA records this draft has would - one hopes - be covered by DANE-SRV. It is possible that between the two documents there may be some SIP specific information that implementors would find useful; in particular RFC 6125 is fairly light in discussion of NAPTR records, for instance. But I suspect a document filling those gaps might only need to be an informational document providing better examples, or else would be better folded into an update to (or revision of) RFC 6125. (Please explicitly copy me on responses; I am not subscribed to the dispatch mailing list) Dave. --047d7b41904b3b081c04f1c4dfd0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Olle,

Richard Barnes asked m= e to read this one over. Sorry to be the harbinger of doom, here - I'll= buy you a pint in London.


draft-jo= hansson-dispatch-dane-sip-01

TL;DR: I'm not convinced that this document s= hould be adopted or taken further. The reason is that much of what is discu= sses is actually already covered by RFC 6125, as (hopefully to be) updated = by draft-ietf-dane-srv. Energy should be redirected to either dane-srv, or = a revision of RFC 6125, or both.

Issues (some of which minor):

= 1) It appears to discuss only server authentication by an end-user client, = and not mutual peer authentication of servers. I suspect both are important= in SIP (as they are in XMPP).

2) It conflates DANE (which provides constraints on cer= tificates) with DNSSEC (which allows a validating party to use additional r= eference identifiers securely as in RFC 6125 =A7 6.2.1, as well as providin= g security for TLSA records).

3) It refers to the AD flag as a definitive guide to th= e security (in the sense of DNSSEC) of a DNS RR, whereas I thought a client= actually has to either check the signatures locally (and essentially disre= gard this flag) or else have a secure link to a trusted resolver (largely i= mpossible, perhaps loopback).

4) "CNAME" is used without expansion in a doc= ument describing both DNS and X.509.

5) It's n= ot using the terms of art established in RFC 6125.

This is not to say the document is not valuable - it's sufficientl= y valuable that we have an RFC covering this area and a further draft expan= ding upon it - the subject matter is clearly important.

I personally think RFC 6125 is very useful, but it might warrant a rev= isit once DANE-SRV is complete, and I would encourage the author to place a= ny remaining energy in that direction, as well as DANE-SRV itself. This sho= uld apply to not only SIP, but other protocols too, and therefore be of wid= er benefit.

As it stands, the draft already restates some of RFC 61= 25, but lacks much of the depth and coverage - entirely understandable in a= n early stage draft, but it does suggest there's a lot of work to be do= ne, and the work has been done already. The additional discussion of TLSA r= ecords this draft has would - one hopes - be covered by DANE-SRV.

It is possible that between the two documents there may= be some SIP specific information that implementors would find useful; in p= articular RFC 6125 is fairly light in discussion of NAPTR records, for inst= ance. But I suspect a document filling those gaps might only need to be an = informational document providing better examples, or else would be better f= olded into an update to (or revision of) RFC 6125.

(Please explicitly copy me on responses; I am not subsc= ribed to the dispatch mailing list)

Dave.
--047d7b41904b3b081c04f1c4dfd0-- From oej@edvina.net Fri Feb 7 00:41:06 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1881A05E5 for ; Fri, 7 Feb 2014 00:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPQracWnoGcJ for ; Fri, 7 Feb 2014 00:41:03 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 818091A05E1 for ; Fri, 7 Feb 2014 00:41:01 -0800 (PST) Received: from [10.10.1.149] (h217-27-188-82.cust.tyfon.se [217.27.188.82]) by smtp7.webway.se (Postfix) with ESMTPA id 9D87993C2A2; Fri, 7 Feb 2014 08:40:59 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 7 Feb 2014 09:40:58 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Dave Cridland X-Mailer: Apple Mail (2.1827) Cc: DISPATCH Subject: Re: [dispatch] Review of draft-johansson-dispatch-dane-sip-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 08:41:06 -0000 On 07 Feb 2014, at 00:02, Dave Cridland wrote: > Olle, >=20 > Richard Barnes asked me to read this one over. Sorry to be the = harbinger of doom, here - I'll buy you a pint in London. Thank you for doing this. There has been very little discussion about = it, a few questions about backwards compatibility and a lot of support = for doing something. I look forward to a good Ale with you in London! >=20 >=20 > draft-johansson-dispatch-dane-sip-01 >=20 > TL;DR: I'm not convinced that this document should be adopted or taken = further. The reason is that much of what is discusses is actually = already covered by RFC 6125, as (hopefully to be) updated by = draft-ietf-dane-srv. Energy should be redirected to either dane-srv, or = a revision of RFC 6125, or both. Well, obviously I am. Note that I'm new in the IETF draft-writing = business, so there's a lot of stuff to do with the document as you = clearly say. I got to a point when I was asking myself why no one was = doing anything and got surprised one morning when I realised that no one = was me, myself and I.=20 The issue at hand is not really RFC 6125 but RFC 5922 that updates RFC = 3261. That document clearly defines how to verify a TLS server = certificate with a given SIP URI using domains. The DANE srv goes = against this and goes back to SRV host names in the certificate. I = wanted to write a document that documents an alternative to 5922 for SIP = developers and also clearly defines how certificates can be constructed = and how these can be or not be compatible with 5922.=20 SIP and TLS has a long history of confusion and we need to clear that = up. The DANE documents clearly states that listing all the service names in the certificate is not = viable for hosting situations and that we need to change that practise. I agree with that. Now is this document ends up as BCP, informative or actually will have = normative changes to 5922/3261 in it's final form, I don't know. But I = do want to defend production of a document in the RAI area to help = already confused SIP implementors on where to go and point them towards = the DANE document output. In addition, as you know, the DANE wg charter clearly states that = protocol specific issues, which I think that the potential issue with = 5922 is, should not be handled by the DANE wg if there are working = groups covering those protocols. (Just to explain to list readers why I = submitted this to dispatch and not DANE). >=20 > Issues (some of which minor): >=20 > 1) It appears to discuss only server authentication by an end-user = client, and not mutual peer authentication of servers. I suspect both = are important in SIP (as they are in XMPP). I attempted to start a discussion with Robert Sparks about how DANE can = apply to SIP connection reuse and client auth in Berlin, but was in a = clear RJS way told that DANE had nothing to do with client = authentication. Well, it may not be DANE but end up as ENAD, but I do = think that we can leverage on DNSsec here. I took it out of scope now = since I heard from Robert's reaction that I propably should stick with = server authentication for now... :-) >=20 > 2) It conflates DANE (which provides constraints on certificates) with = DNSSEC (which allows a validating party to use additional reference = identifiers securely as in RFC 6125 =A7 6.2.1, as well as providing = security for TLSA records). >=20 > 3) It refers to the AD flag as a definitive guide to the security (in = the sense of DNSSEC) of a DNS RR, whereas I thought a client actually = has to either check the signatures locally (and essentially disregard = this flag) or else have a secure link to a trusted resolver (largely = impossible, perhaps loopback). >=20 > 4) "CNAME" is used without expansion in a document describing both DNS = and X.509. >=20 > 5) It's not using the terms of art established in RFC 6125. Good feedback all of these. Let's work on that. I've already accepted an = offer from Gonzalo Salguiero to co-author and help me clear up things = like this. He has far more experience than me in using the right = language. I just wanted to get the discussion started and get the topic = into the proper wg. >=20 > This is not to say the document is not valuable - it's sufficiently = valuable that we have an RFC covering this area and a further draft = expanding upon it - the subject matter is clearly important. Agree. >=20 > I personally think RFC 6125 is very useful, but it might warrant a = revisit once DANE-SRV is complete, and I would encourage the author to = place any remaining energy in that direction, as well as DANE-SRV = itself. This should apply to not only SIP, but other protocols too, and = therefore be of wider benefit. I am following DANE-SRV as well as the SMIME work. The authors there are = doing a fine job. >=20 > As it stands, the draft already restates some of RFC 6125, but lacks = much of the depth and coverage - entirely understandable in an early = stage draft, but it does suggest there's a lot of work to be done, and = the work has been done already. The additional discussion of TLSA = records this draft has would - one hopes - be covered by DANE-SRV. I don't think the work has been done already. You are missing the issue = with RFC 5922 that stands in the way. >=20 > It is possible that between the two documents there may be some SIP = specific information that implementors would find useful; in particular = RFC 6125 is fairly light in discussion of NAPTR records, for instance. = But I suspect a document filling those gaps might only need to be an = informational document providing better examples, or else would be = better folded into an update to (or revision of) RFC 6125. I am always in favour of helping implementors to navigate across the sea = of drafts and RFCs that defines what we call the SIP protocol. /O >=20 > (Please explicitly copy me on responses; I am not subscribed to the = dispatch mailing list) >=20 > Dave. From dave@cridland.net Fri Feb 7 04:23:59 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD291A03A6 for ; Fri, 7 Feb 2014 04:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeSz1AzaffQQ for ; Fri, 7 Feb 2014 04:23:57 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCB01A0398 for ; Fri, 7 Feb 2014 04:23:57 -0800 (PST) Received: by mail-ob0-f178.google.com with SMTP id wn1so3857812obc.23 for ; Fri, 07 Feb 2014 04:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lSlI82A1L3GEeVS/1JA0WJgth6g5rOQG4F0xhfeX8Cs=; b=GcHlj/fTX9xnp/FhWRSbXjJomUGdVNgy6Li/JFipzXQJYIhobxB4DoJq63Od+IGjg4 0Tf8A3sOE1NCFnwUoOr/TisS8Vr3m1bSMNctatmxcMTVWfJ0HHEPPmRBgSktl3xHrbb4 1QA0siUECp3m7Q3bDqpV4pyYsZlW9Fa4nm3p4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lSlI82A1L3GEeVS/1JA0WJgth6g5rOQG4F0xhfeX8Cs=; b=VOMa0y72itc2l7P8CWmwhlBct80xdTPCsg54jI11wLTCuWtFmaM8Kr0FNZXq/irOkV d1U6W8yKatDqqBo21k2RqxBrt4a3okHDeEEednSylpU0aOOUD17rE2Vaj7NsRdjk4NWB fN0Py+oJYWHyn7nBTzfjbvx5nJW4cvc17EeOzWRqCt0yxMePHbitUe2shimarJnPws0L Pzs5sScV0p1fOlLhgWSRT8scpXU9FgAd/hjBobzzDlO2CBQc2+XqwGGVdJnY2Erm/sP8 YdMpjuF0pym7YiISOxWs/n2h+u+8PQUMdvv/Et0GGXMNs4Fw/EYlEuPqoFcsGIDFi43V rqMg== X-Gm-Message-State: ALoCoQmwHvjXqvo/MPlyLp9ZtQIwTBcNhl3Dp0X+5MD7ojhSm96qF4SYn86axfz9CSnXWjSkew9k MIME-Version: 1.0 X-Received: by 10.182.113.195 with SMTP id ja3mr12759288obb.46.1391775836900; Fri, 07 Feb 2014 04:23:56 -0800 (PST) Received: by 10.60.55.138 with HTTP; Fri, 7 Feb 2014 04:23:56 -0800 (PST) In-Reply-To: References: Date: Fri, 7 Feb 2014 12:23:56 +0000 Message-ID: From: Dave Cridland To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=089e013d0db05daa9904f1d010b7 Cc: DISPATCH Subject: Re: [dispatch] Review of draft-johansson-dispatch-dane-sip-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 12:23:59 -0000 --089e013d0db05daa9904f1d010b7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Feb 7, 2014 at 8:40 AM, Olle E. Johansson wrote: > > On 07 Feb 2014, at 00:02, Dave Cridland wrote: > > > Olle, > > > > Richard Barnes asked me to read this one over. Sorry to be the harbinge= r > of doom, here - I'll buy you a pint in London. > Thank you for doing this. There has been very little discussion about it, > a few questions about backwards compatibility and a lot of support for > doing something. I look forward to a good Ale with you in London! > > > > > > > draft-johansson-dispatch-dane-sip-01 > > > > TL;DR: I'm not convinced that this document should be adopted or taken > further. The reason is that much of what is discusses is actually already > covered by RFC 6125, as (hopefully to be) updated by draft-ietf-dane-srv. > Energy should be redirected to either dane-srv, or a revision of RFC 6125= , > or both. > Well, obviously I am. Note that I'm new in the IETF draft-writing > business, so there's a lot of stuff to do with the document as you clearl= y > say. I got to a point when I was asking myself why no one was doing > anything and got surprised one morning when I realised that no one was me= , > myself and I. > > The issue at hand is not really RFC 6125 but RFC 5922 that updates RFC > 3261. That document clearly defines how to verify a TLS server certificat= e > with a given SIP URI using domains. The DANE srv goes against this and go= es > back to SRV host names in the certificate. I wanted to write a document > that documents an alternative to 5922 for SIP developers and also clearly > defines how certificates can be constructed and how these can be or not b= e > compatible with 5922. > > SIP and TLS has a long history of confusion and we need to clear that up. > The DANE documents clearly > states that listing all the service names in the certificate is not viabl= e > for hosting situations and that we need > to change that practise. I agree with that. > > As an aside, this can be addressed using pure DNSSEC and the reference identifier "gathering" discussed in RFC 6125 =A7 6.2.1 - the XMPP community has been experimenting which this (see in particular Kim Alvefur's "DANE-lite" work in the Prosody open-source XMPP server). There's also POSH, which might well be applicable (draft-miller-posh-03), and uses a different trust path to emulate something close to DANE, and is under discussion within the XMPP working group. DANE offers somewhat more, and more flexible, ways of specifying additional reference identifiers and certificate constraints, but arguably for a SRV based protocol - such as SIP or XMPP - DANE doesn't add much more to the solution for mass-hosting providers than DNSSEC alone. > Now is this document ends up as BCP, informative or actually will have > normative changes to 5922/3261 in it's final form, I don't know. But I do > want to defend production of a document in the RAI area to help already > confused SIP implementors on where to go and point them towards the DANE > document output. > > In addition, as you know, the DANE wg charter clearly states that protoco= l > specific issues, which I think that the potential issue with 5922 is, > should not be handled by the DANE wg if there are working groups covering > those protocols. (Just to explain to list readers why I submitted this to > dispatch and not DANE). > > Right, I accept that RFC 5922 details issues that are specific to SIP, as well as discussing more general issues. Having quickly whistled through RFC 5922, I further accept that a possibly updated RFC 6125 + DANE-SRV will still fall short due to the SIP specific issues. I think - and I could be *way* off here - that the primary specifics for SIP are NAPTR lookups (which I don't really see well-covered in RFC 6125), and authenticating a calling proxy (because - in the language of RFC 6125 - the correct reference identifiers are largely unknown). My gut feeling is therefore that the work needed is: a) Complete DANE-SRV (draft-ietf-dane-srv), ensuring particular attention is paid to the SIP cases. b) An update to RFC 6125 to ensure knowledge about DNSSEC derivation of additional reference identifiers is properly discussed, and (possibly) better discussion of NAPTR lookup related issues. c) A document which obsoletes RFC 5922, normatively references DANE-SRV and RFC 6125bis, and builds upon those foundations to discuss SIP-specific issues. Does that seem like a reasonable work plan? Dave. --089e013d0db05daa9904f1d010b7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 7, 2014 at 8:40 AM, Olle E. Johansson <oej@edvina.net> = wrote:

On 07 Feb 2014, at 00:02, Dave Cridland <dave@cridland.net> wrote:

> Olle,
>
> Richard Barnes asked me to read this one over. Sorry to be the harbing= er of doom, here - I'll buy you a pint in London.
Thank you for doing this. There has been very little discussion about= it, a few questions about backwards compatibility and a lot of support for= doing something. I look forward to a good Ale with you in London!

>
>
> draft-johansson-dispatch-dane-sip-01
>
> TL;DR: I'm not convinced that this document should be adopted or t= aken further. The reason is that much of what is discusses is actually alre= ady covered by RFC 6125, as (hopefully to be) updated by draft-ietf-dane-sr= v. Energy should be redirected to either dane-srv, or a revision of RFC 612= 5, or both.
Well, obviously I am. Note that I'm new in the IETF draft-writing= business, so there's a lot of stuff to do with the document as you cle= arly say. I got to a point when I was asking myself why no one was doing an= ything and got surprised one morning when I realised that no one was me, my= self and I.

The issue at hand is not really RFC 6125 but RFC 5922 that updates RFC 3261= . That document clearly defines how to verify a TLS server certificate with= a given SIP URI using domains. The DANE srv goes against this and goes bac= k to SRV host names in the certificate. I wanted to write a document that d= ocuments an alternative to 5922 for SIP developers and also clearly defines= how certificates can be constructed and how these can be or not be compati= ble with 5922.

SIP and TLS has a long history of confusion and we need to clear that up. T= he DANE documents clearly
states that listing all the service names in the certificate is not viable = for hosting situations and that we need
to change that practise. I agree with that.


As an aside, this can be addressed usi= ng pure DNSSEC and the reference identifier "gathering" discussed= in RFC 6125 =A7 6.2.1 - the XMPP community has been experimenting which th= is (see in particular Kim Alvefur's "DANE-lite" work in the P= rosody open-source XMPP server). There's also POSH, which might well be= applicable (draft-miller-posh-03), and uses a different trust path to emul= ate something close to DANE, and is under discussion within the XMPP workin= g group.

DANE offers somewhat more, and more flexible, ways of s= pecifying additional reference identifiers and certificate constraints, but= arguably for a SRV based protocol - such as SIP or XMPP - DANE doesn't= add much more to the solution for mass-hosting providers than DNSSEC alone= .
=A0
Now is this document ends up as BCP, informative or actually will have norm= ative changes to 5922/3261 in it's final form, I don't know. But I = do want to defend production of a document in the RAI area to help already = confused SIP implementors on where to go and point them towards the DANE do= cument output.

In addition, as you know, the DANE wg charter clearly states that protocol = specific issues, which I think that the potential issue with 5922 is, shoul= d not be handled by the DANE wg if there are working groups covering those = protocols. (Just to explain to list readers why I submitted this to dispatc= h and not DANE).


Right, I accept = that RFC 5922 details issues that are specific to SIP, as well as discussin= g more general issues. Having quickly whistled through RFC 5922, I further = accept that a possibly updated RFC 6125 + DANE-SRV will still fall short du= e to the SIP specific issues.

I think - and I could be *way* off here - that th= e primary specifics for SIP are NAPTR lookups (which I don't really see= well-covered in RFC 6125), and authenticating a calling proxy (because - i= n the language of RFC 6125 - the correct reference identifiers are largely = unknown).

My gut feeling is therefore that the work needed = is:

a) Complete DANE-SRV (draft-ietf-dane-srv), en= suring particular attention is paid to the SIP cases.

b) An update to RFC 6125 to ensure knowledge about DNSSEC derivation o= f additional reference identifiers is properly discussed, and (possibly) be= tter discussion of NAPTR lookup related issues.

c) A document which obsoletes RFC 5922, normatively references DANE-SRV and= RFC 6125bis, and builds upon those foundations to discuss SIP-specific iss= ues.

Does that seem like a reasonable work plan?

Dave.
--089e013d0db05daa9904f1d010b7-- From thp@westhawk.co.uk Fri Feb 7 04:45:52 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5838B1A03A8 for ; Fri, 7 Feb 2014 04:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yD7tQjAUTMc for ; Fri, 7 Feb 2014 04:45:50 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 747C21A03A7 for ; Fri, 7 Feb 2014 04:45:50 -0800 (PST) Received: (qmail 85183 invoked from network); 7 Feb 2014 12:45:49 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 6961 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 7 Feb 2014 12:45:49 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 4983318A024C; Fri, 7 Feb 2014 12:45:49 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id DC84E18A0205; Fri, 7 Feb 2014 12:45:48 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton new In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF241C5@sc9-ex2k10mb1.corp.yaanatech.com> Date: Fri, 7 Feb 2014 12:45:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <00C069FD01E0324C9FFCADF539701DB3BBF241C5@sc9-ex2k10mb1.corp.yaanatech.com> To: Michael Hammer X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 12:45:52 -0000 On 6 Feb 2014, at 02:39, Michael Hammer = wrote: > Interesting. But, the 4G/LTE network is an IP internet of sorts. > The SIP/IMS components do not need to be in the radio network,=20 > and thus not at the locations where the power is constrained. One of the nice properties of an openBTS install in a remote location is = that it can still function as a local 'pbx' at times when the internet link is = down. This turns out to=20 be fabulously useful in a crisis. If you delegate all the logic out to a = cloud service that stops being true. Tim.= From oej@edvina.net Fri Feb 7 05:36:23 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3D111A1EF8 for ; Fri, 7 Feb 2014 05:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOoSqz2CYWXa for ; Fri, 7 Feb 2014 05:36:20 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 177A61A0103 for ; Fri, 7 Feb 2014 05:36:18 -0800 (PST) Received: from [192.168.1.205] (h217-27-188-82.cust.tyfon.se [217.27.188.82]) by smtp7.webway.se (Postfix) with ESMTPA id 1BEDC93C2A3; Fri, 7 Feb 2014 13:36:17 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_177E554C-454B-4F59-BB69-43BD32F42BC6" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 7 Feb 2014 14:36:16 +0100 Message-Id: References: To: Dave Cridland X-Mailer: Apple Mail (2.1827) Cc: DISPATCH Subject: Re: [dispatch] Review of draft-johansson-dispatch-dane-sip-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 13:36:23 -0000 --Apple-Mail=_177E554C-454B-4F59-BB69-43BD32F42BC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 07 Feb 2014, at 13:23, Dave Cridland wrote: > On Fri, Feb 7, 2014 at 8:40 AM, Olle E. Johansson = wrote: >=20 > On 07 Feb 2014, at 00:02, Dave Cridland wrote: >=20 > > Olle, > > > > Richard Barnes asked me to read this one over. Sorry to be the = harbinger of doom, here - I'll buy you a pint in London. > Thank you for doing this. There has been very little discussion about = it, a few questions about backwards compatibility and a lot of support = for doing something. I look forward to a good Ale with you in London! >=20 > > > > > > draft-johansson-dispatch-dane-sip-01 > > > > TL;DR: I'm not convinced that this document should be adopted or = taken further. The reason is that much of what is discusses is actually = already covered by RFC 6125, as (hopefully to be) updated by = draft-ietf-dane-srv. Energy should be redirected to either dane-srv, or = a revision of RFC 6125, or both. > Well, obviously I am. Note that I'm new in the IETF draft-writing = business, so there's a lot of stuff to do with the document as you = clearly say. I got to a point when I was asking myself why no one was = doing anything and got surprised one morning when I realised that no one = was me, myself and I. >=20 > The issue at hand is not really RFC 6125 but RFC 5922 that updates RFC = 3261. That document clearly defines how to verify a TLS server = certificate with a given SIP URI using domains. The DANE srv goes = against this and goes back to SRV host names in the certificate. I = wanted to write a document that documents an alternative to 5922 for SIP = developers and also clearly defines how certificates can be constructed = and how these can be or not be compatible with 5922. >=20 > SIP and TLS has a long history of confusion and we need to clear that = up. The DANE documents clearly > states that listing all the service names in the certificate is not = viable for hosting situations and that we need > to change that practise. I agree with that. >=20 >=20 > As an aside, this can be addressed using pure DNSSEC and the reference = identifier "gathering" discussed in RFC 6125 =A7 6.2.1 - the XMPP = community has been experimenting which this (see in particular Kim = Alvefur's "DANE-lite" work in the Prosody open-source XMPP server). = There's also POSH, which might well be applicable = (draft-miller-posh-03), and uses a different trust path to emulate = something close to DANE, and is under discussion within the XMPP working = group. I am aware of that work. >=20 > DANE offers somewhat more, and more flexible, ways of specifying = additional reference identifiers and certificate constraints, but = arguably for a SRV based protocol - such as SIP or XMPP - DANE doesn't = add much more to the solution for mass-hosting providers than DNSSEC = alone. I am not sure I agree with you here. Beer bof it is. > =20 > Now is this document ends up as BCP, informative or actually will have = normative changes to 5922/3261 in it's final form, I don't know. But I = do want to defend production of a document in the RAI area to help = already confused SIP implementors on where to go and point them towards = the DANE document output. >=20 > In addition, as you know, the DANE wg charter clearly states that = protocol specific issues, which I think that the potential issue with = 5922 is, should not be handled by the DANE wg if there are working = groups covering those protocols. (Just to explain to list readers why I = submitted this to dispatch and not DANE). >=20 >=20 > Right, I accept that RFC 5922 details issues that are specific to SIP, = as well as discussing more general issues. Having quickly whistled = through RFC 5922, I further accept that a possibly updated RFC 6125 + = DANE-SRV will still fall short due to the SIP specific issues. >=20 > I think - and I could be *way* off here - that the primary specifics = for SIP are NAPTR lookups (which I don't really see well-covered in RFC = 6125), and authenticating a calling proxy (because - in the language of = RFC 6125 - the correct reference identifiers are largely unknown). NAPTR is there and is used in many places, but most devices go for SRV = directly. >=20 > My gut feeling is therefore that the work needed is: >=20 > a) Complete DANE-SRV (draft-ietf-dane-srv), ensuring particular = attention is paid to the SIP cases. Yes. And possibly inject some SIP into DANE S/MIME. >=20 > b) An update to RFC 6125 to ensure knowledge about DNSSEC derivation = of additional reference identifiers is properly discussed, and = (possibly) better discussion of NAPTR lookup related issues. Can't say much about that right now, will have to investigate and come = back to you on that. Sounds fair. >=20 > c) A document which obsoletes RFC 5922, normatively references = DANE-SRV and RFC 6125bis, and builds upon those foundations to discuss = SIP-specific issues. I do not think we can or should obsolete 5922. But we need an = alternative and that needs to be documented just because 5922 updates = RFC 3261. >=20 > Does that seem like a reasonable work plan? There is still room for discussion, but I think we now agrees that there = is work to be done in the RAI area too and that my draft is a starting = point (but not the final document) for this work. Greetings, /O >=20 > Dave. --Apple-Mail=_177E554C-454B-4F59-BB69-43BD32F42BC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On 07 Feb 2014, at 13:23, Dave = Cridland <dave@cridland.net> = wrote:

On Fri, Feb 7, 2014 at 8:40 AM, Olle E. Johansson = <oej@edvina.net> wrote:

On 07 Feb 2014, at 00:02, Dave Cridland <dave@cridland.net> wrote:

> Olle,
>
> Richard Barnes asked me to read this one over. Sorry to be the = harbinger of doom, here - I'll buy you a pint in London.
Thank you for doing this. There has been very little discussion = about it, a few questions about backwards compatibility and a lot of = support for doing something. I look forward to a good Ale with you in = London!

>
>
> draft-johansson-dispatch-dane-sip-01
>
> TL;DR: I'm not convinced that this document should be adopted or = taken further. The reason is that much of what is discusses is actually = already covered by RFC 6125, as (hopefully to be) updated by = draft-ietf-dane-srv. Energy should be redirected to either dane-srv, or = a revision of RFC 6125, or both.
Well, obviously I am. Note that I'm new in the IETF draft-writing = business, so there's a lot of stuff to do with the document as you = clearly say. I got to a point when I was asking myself why no one was = doing anything and got surprised one morning when I realised that no one = was me, myself and I.

The issue at hand is not really RFC 6125 but RFC 5922 that updates RFC = 3261. That document clearly defines how to verify a TLS server = certificate with a given SIP URI using domains. The DANE srv goes = against this and goes back to SRV host names in the certificate. I = wanted to write a document that documents an alternative to 5922 for SIP = developers and also clearly defines how certificates can be constructed = and how these can be or not be compatible with 5922.

SIP and TLS has a long history of confusion and we need to clear that = up. The DANE documents clearly
states that listing all the service names in the certificate is not = viable for hosting situations and that we need
to change that practise. I agree with that.


As an aside, this can be addressed = using pure DNSSEC and the reference identifier "gathering" discussed in = RFC 6125 =A7 6.2.1 - the XMPP community has been experimenting which = this (see in particular Kim Alvefur's "DANE-lite" work in the Prosody = open-source XMPP server). There's also POSH, which might well be = applicable (draft-miller-posh-03), and uses a different trust path to = emulate something close to DANE, and is under discussion within the XMPP = working group.
I am aware of that = work.

DANE offers somewhat more, and more flexible, ways = of specifying additional reference identifiers and certificate = constraints, but arguably for a SRV based protocol - such as SIP or XMPP = - DANE doesn't add much more to the solution for mass-hosting providers = than DNSSEC alone.
I am not sure I = agree with you here. Beer bof it is.
 
Now is this document ends up as BCP, informative or actually will have = normative changes to 5922/3261 in it's final form, I don't know. But I = do want to defend production of a document in the RAI area to help = already confused SIP implementors on where to go and point them towards = the DANE document output.

In addition, as you know, the DANE wg charter clearly states that = protocol specific issues, which I think that the potential issue with = 5922 is, should not be handled by the DANE wg if there are working = groups covering those protocols. (Just to explain to list readers why I = submitted this to dispatch and not DANE).


Right, I = accept that RFC 5922 details issues that are specific to SIP, as well as = discussing more general issues. Having quickly whistled through RFC = 5922, I further accept that a possibly updated RFC 6125 + DANE-SRV will = still fall short due to the SIP specific issues.

I think - and I could be *way* off here - that = the primary specifics for SIP are NAPTR lookups (which I don't really = see well-covered in RFC 6125), and authenticating a calling proxy = (because - in the language of RFC 6125 - the correct reference = identifiers are largely = unknown).
NAPTR is there and is = used in many places, but most devices go for SRV = directly.

My gut feeling is therefore that the work = needed is:

a) Complete DANE-SRV = (draft-ietf-dane-srv), ensuring particular attention is paid to the SIP = cases.
Yes. And possibly inject some = SIP into DANE S/MIME.

b) An update to RFC 6125 to ensure knowledge about DNSSEC = derivation of additional reference identifiers is properly discussed, = and (possibly) better discussion of NAPTR lookup related = issues.
Can't say much about that = right now, will have to investigate and come back to you on that. Sounds = fair.


c) A document which obsoletes RFC 5922, normatively references DANE-SRV = and RFC 6125bis, and builds upon those foundations to discuss = SIP-specific issues.
I do not think = we can or should obsolete 5922. But we need an alternative and that = needs to be documented just because 5922 updates RFC = 3261.


Does = that seem like a reasonable work = plan?
There is still room for = discussion, but I think we now agrees that there is work to be done in = the RAI area  too and that my draft is a starting point (but not = the final document) for this = work.

Greetings,
/O

Dave.

= --Apple-Mail=_177E554C-454B-4F59-BB69-43BD32F42BC6-- From oej@edvina.net Fri Feb 7 06:00:19 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0657D1A1EFC for ; Fri, 7 Feb 2014 06:00:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WLmnx6gz8f9r for ; Fri, 7 Feb 2014 06:00:17 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 85B0D1A03C3 for ; Fri, 7 Feb 2014 06:00:17 -0800 (PST) Received: from [192.168.1.205] (h217-27-188-82.cust.tyfon.se [217.27.188.82]) by smtp7.webway.se (Postfix) with ESMTPA id BDF6493C2A3; Fri, 7 Feb 2014 14:00:16 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_E3AA8DA0-2065-40DD-B826-01A3965AAE76" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 7 Feb 2014 15:00:16 +0100 Message-Id: <9A6E5F3D-7512-4179-97D0-EDA3DD3A3205@edvina.net> References: To: Dave Cridland X-Mailer: Apple Mail (2.1827) Cc: DISPATCH Subject: Re: [dispatch] Review of draft-johansson-dispatch-dane-sip-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 14:00:19 -0000 --Apple-Mail=_E3AA8DA0-2065-40DD-B826-01A3965AAE76 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 To add - the DANE srv draft says this: "Separate documents describe how to apply this specification to particular application protocols. If you are writing such as document the following points ought to be covered:" What I tried to write was such as separate document... :-) Section 6 of http://tools.ietf.org/html/draft-ietf-dane-srv-03 /O --Apple-Mail=_E3AA8DA0-2065-40DD-B826-01A3965AAE76 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 To add - the DANE srv draft says this:

"Separate documents describe how to apply this specification to
   particular application protocols.  If you are writing such as
   document the following points ought to be covered:"


What I tried to write was such as separate document... :-)


/O
--Apple-Mail=_E3AA8DA0-2065-40DD-B826-01A3965AAE76-- From gullik.webjorn@corevalue.se Fri Feb 7 06:11:56 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3111D1A1F3D for ; Fri, 7 Feb 2014 06:11:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.6 X-Spam-Level: X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kevx3c0C1B7R for ; Fri, 7 Feb 2014 06:11:53 -0800 (PST) Received: from mailgw8.surf-town.net (mail4.surf-town.net [212.97.132.44]) by ietfa.amsl.com (Postfix) with ESMTP id 93BE11A1F4A for ; Fri, 7 Feb 2014 06:11:53 -0800 (PST) Received: by mailgw8.surf-town.net (Postfix, from userid 65534) id AC906AFC99; Fri, 7 Feb 2014 15:11:52 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mailgw8.surf-town.net (Postfix) with ESMTP id 9CC5CAFDB1 for ; Fri, 7 Feb 2014 15:11:52 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mailgw8.surf-town.net Received: from mailgw8.surf-town.net ([127.0.0.1]) by localhost (mailgw8.surf-town.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FIZAQ5QC5tzS for ; Fri, 7 Feb 2014 15:11:50 +0100 (CET) Received: from [192.168.1.102] (78-72-48-131-no186.tbcn.telia.com [78.72.48.131]) (Authenticated sender: gullik.webjorn@corevalue.se) by mailgw8.surf-town.net (Postfix) with ESMTPSA id 20EC7AFC99 for ; Fri, 7 Feb 2014 15:11:49 +0100 (CET) Message-ID: <52F4E9A4.5000203@corevalue.se> Date: Fri, 07 Feb 2014 15:11:48 +0100 From: =?ISO-8859-1?Q?Gullik_Webj=F6rn?= User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <00C069FD01E0324C9FFCADF539701DB3BBF241C5@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 14:11:56 -0000 On 02/07/2014 01:45 PM, Tim Panton new wrote: > On 6 Feb 2014, at 02:39, Michael Hammer wrote: > >> Interesting. But, the 4G/LTE network is an IP internet of sorts. >> The SIP/IMS components do not need to be in the radio network, >> and thus not at the locations where the power is constrained. > One of the nice properties of an openBTS install in a remote location is that it > can still function as a local 'pbx' at times when the internet link is down. This turns out to > be fabulously useful in a crisis. If you delegate all the logic out to a cloud service that stops being true. > > Tim. I agree violently, the challenge here is to design the distributed protocol(s) add-ons that would enable building a sip/GSM network out of hundreds or more autonomous BTS's. Gullik > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Fri Feb 7 08:14:30 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACCD1A01DA for ; Fri, 7 Feb 2014 08:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_qppuuuTuNa for ; Fri, 7 Feb 2014 08:14:29 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id E666C1A0193 for ; Fri, 7 Feb 2014 08:14:28 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta04.westchester.pa.mail.comcast.net with comcast id PT101n0021ap0As54UEUYy; Fri, 07 Feb 2014 16:14:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id PUEU1n00T3ZTu2S3iUEUXP; Fri, 07 Feb 2014 16:14:28 +0000 Message-ID: <52F50664.6010502@alum.mit.edu> Date: Fri, 07 Feb 2014 11:14:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1391789668; bh=agQ9PNZOEoQIUF+S95a7VrhN+tatmNL2/Gh2WwGfLvE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=CTnbz6wKoMqqujVWOytbxb57HPSuHY4+V0PsIbKLDtw+qRa0wWb8DBw62LR7k7W4V TxNfZ0LABxHHCyd275Lc4vbxjWNNrXlcETYWxFSh0vNirwPJO/aAbZtE+BP9Q2GvYr jL+mWPZRxdAhZnQ/5JBig31d+8qXTadMliXBVu4xNsMoZ+O3VXBK/vh/bRNvOfP2fv orAMEu3pyViod6KLyGrwdFJtzHy91FDONONeQuN+iPMnbv31rlDmxTMZ2UvEzL0H0X CfHKodYLcSeMcfhE/t0kOYl8LAAcPf9cVAnz+LmlW09tw+1Hfac4o4Hu+qCAR4GDD1 dpfGFTyZwfwxg== Subject: Re: [dispatch] Review of draft-johansson-dispatch-dane-sip-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 16:14:30 -0000 On 2/7/14 8:36 AM, Olle E. Johansson wrote: [snip] >> My gut feeling is therefore that the work needed is: >> >> a) Complete DANE-SRV (draft-ietf-dane-srv), ensuring particular >> attention is paid to the SIP cases. > Yes. And possibly inject some SIP into DANE S/MIME. >> >> b) An update to RFC 6125 to ensure knowledge about DNSSEC derivation >> of additional reference identifiers is properly discussed, and >> (possibly) better discussion of NAPTR lookup related issues. > Can't say much about that right now, will have to investigate and come > back to you on that. Sounds fair. > >> >> c) A document which obsoletes RFC 5922, normatively references >> DANE-SRV and RFC 6125bis, and builds upon those foundations to discuss >> SIP-specific issues. > I do not think we can or should obsolete 5922. But we need an > alternative and that needs to be documented just because 5922 updates > RFC 3261. > >> >> Does that seem like a reasonable work plan? > There is still room for discussion, but I think we now agrees that there > is work to be done in the RAI area too and that my draft is a starting > point (but not the final document) for this work. +1 I have been pleased to see that someone has taken on the task of starting to figure out how to exploit DANE and DNSSEC for SIP. I know very little about DANE, but enough to see that it is probably important. I'm also pleased that it isn't just Olle - that Dave is taking the role of devil's advocate here. And hopefully that will stimulate more debate. That should lead to the best result. (I'm getting more educated by following the draft and the debate.) This is starting in dispatch because it wasn't immediately clear if it fell entirely in the scope of sipcore. I'm ok with it staying in dispatch until we figure out exactly what the scope of the required work is. Thanks, Paul From jim.forster@rangenetworks.com Fri Feb 7 10:56:26 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58EF21AC7F1 for ; Fri, 7 Feb 2014 10:56:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcc8c8a_42sw for ; Fri, 7 Feb 2014 10:56:24 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id 79AD91A0459 for ; Fri, 7 Feb 2014 10:56:23 -0800 (PST) Received: from BL2PR03MB404.namprd03.prod.outlook.com (10.141.91.149) by BL2PR03MB401.namprd03.prod.outlook.com (10.141.91.145) with Microsoft SMTP Server (TLS) id 15.0.868.8; Fri, 7 Feb 2014 18:56:22 +0000 Received: from BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) by BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) with mapi id 15.00.0868.013; Fri, 7 Feb 2014 18:56:21 +0000 From: Jim Forster To: =?iso-8859-1?Q?Gullik_Webj=F6rn?= Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAAO2QCAAjuzgIAAGAoAgABPewA= Date: Fri, 7 Feb 2014 18:56:20 +0000 Message-ID: References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <00C069FD01E0324C9FFCADF539701DB3BBF241C5@sc9-ex2k10mb1.corp.yaanatech.com> <52F4E9A4.5000203@corevalue.se> In-Reply-To: <52F4E9A4.5000203@corevalue.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [61.12.100.227] x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(189002)(199002)(51704005)(76796001)(81542001)(50986001)(74366001)(93136001)(63696002)(74876001)(76786001)(46102001)(36756003)(47976001)(80022001)(87266001)(66066001)(94946001)(65816001)(74706001)(69226001)(53806001)(74662001)(33656001)(92726001)(59766001)(54356001)(86362001)(94316002)(92566001)(74502001)(31966008)(87936001)(83716003)(81686001)(81816001)(82746002)(85306002)(81342001)(85852003)(77982001)(83322001)(93516002)(54316002)(80976001)(4396001)(2656002)(83072002)(47446002)(49866001)(56776001)(47736001)(95416001)(51856001)(56816005)(90146001)(79102001)(76482001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB401; H:BL2PR03MB404.namprd03.prod.outlook.com; CLIP:61.12.100.227; FPR:FEFAF5D8.AF1435A7.B9E417B7.44EDEB61.202C4; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_4725560E-F4E5-4370-B26E-4FC6BF78C112"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: rangenetworks.com Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2014 18:56:26 -0000 --Apple-Mail=_4725560E-F4E5-4370-B26E-4FC6BF78C112 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii >>> Interesting. But, the 4G/LTE network is an IP internet of sorts. >>> The SIP/IMS components do not need to be in the radio network, >>> and thus not at the locations where the power is constrained. >> One of the nice properties of an openBTS install in a remote location = is that it >> can still function as a local 'pbx' at times when the internet link = is down. This turns out to >> be fabulously useful in a crisis. If you delegate all the logic out = to a cloud service that stops being true. >>=20 >> Tim. > I agree violently, the challenge here is to design the distributed = protocol(s) add-ons that would enable > building a sip/GSM network out of hundreds or more autonomous BTS's. >=20 > Gullik I agree mostly with both of you: * Standalone/disconnected OpenBTS's have good value in emergency = response or remote work environments. Turn it on phones in the = footprint can call each other; no backhaul or Core Network. In some = cases that are connected, over a thin link, there is a great bandwidth = savings, and reliability improvement, by having a local switch. I = believe the Antarctic research station paid for its OpenBTS in a few = months of operation, due to savings in satellite bandwidth over the GSM = standard approach with the BSC/MSC on the other side of the satellite = link. Plus, solar storms would knock out the link and and disable even = local calls. * There are indeed challenges (and value) in large networks I still owe the list a diagram which would facilitate understanding and = discussion. -- JIm --Apple-Mail=_4725560E-F4E5-4370-B26E-4FC6BF78C112 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJS9SxRAAoJECAtT58A/2SKo34IAK6tllgnxe8l8U+p8zXO+Syj 89GswyFCziyOsowbjGNixt//CUQ3ZLbLwq+bdZ64ph7ridqm6oKHCwaMgkmewty+ 8fLHAdlslxs67/tXc3QDpPddsIjR5q1Uj1fbld8MpUU34T4cbTqiFRTNOO/nsxN+ n/iPStTRmuVapMdyWypb1vQI7Iu67kQ8UOL8gqiT/HVS2b+uUthgsM2PpN7oJmh8 zyby0RW+r4t9LIXMlUDt4+DdqTldo7EOQ+9IK6bGjPWSTcgKDqwE93gVooZ6TTHI 54AkfyQpNITimGsSX9zhL3nZO8h6rd0lzovOmkeGvJulBTbveZbZjrU5utP+Zj4= =0LUV -----END PGP SIGNATURE----- --Apple-Mail=_4725560E-F4E5-4370-B26E-4FC6BF78C112-- From rlb@ipv.sx Sat Feb 8 10:57:04 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E48B1A0443 for ; Sat, 8 Feb 2014 10:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOQgHq7eZJCw for ; Sat, 8 Feb 2014 10:57:02 -0800 (PST) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9361A0451 for ; Sat, 8 Feb 2014 10:57:01 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id uy5so5539996obc.5 for ; Sat, 08 Feb 2014 10:57:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=2R4s2aJaHtjjr20GiIS0Cj98XAJ+YmbnjxWDuXFaqao=; b=NkujIpiQf3y+okmNpnT5nxmjv4dV7Ma7/QvzjXr3Euhgp5CLHvrfIkDWsVhYmRFXKU Sp5p2AHAXQ7gyEvIPJw/bUh4T6vclmFMjVu2CNlMg7GhbgB5ofzzYjdJxDnhAKSFHHWF DFwSKtxyGTTqDI7NxtBpjvegnFf40J1lfLM+y9Fz3zziFH8NTFRyA13JhvtxPR1HdiEM RdBO9K4q+0tWAZFEuoDpSpT1+Av82iRpFt0KTwJA9le5Y4blgg1rkCe1yizrhWE2YRsh BhxvMQuVuoRSeilta9LCTiZzsEKPvIZyCcwqNUndAXmy/56KUpBrxKA1FqxD7CU+xuTD UCvg== X-Gm-Message-State: ALoCoQlgH5QleQvE0H9xhygJaJKUycwUlQL6F7T5hhuBpop2zh5n8ovaym6gdd/XTsbfS0pa8y/u MIME-Version: 1.0 X-Received: by 10.60.229.4 with SMTP id sm4mr18942025oec.9.1391885821520; Sat, 08 Feb 2014 10:57:01 -0800 (PST) Received: by 10.60.69.102 with HTTP; Sat, 8 Feb 2014 10:57:01 -0800 (PST) Date: Sat, 8 Feb 2014 13:57:01 -0500 Message-ID: From: Richard Barnes To: "rai-chairs@tools.ietf.org" , DISPATCH , "rai@ietf.org" Content-Type: multipart/alternative; boundary=001a11362860f5cc7c04f1e9ab37 Subject: [dispatch] Reminder: Draft deadline for IETF 89 earlier than usual X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 18:57:04 -0000 --001a11362860f5cc7c04f1e9ab37 Content-Type: text/plain; charset=ISO-8859-1 Dear RAI folks, This is a friendly reminder that the Internet-draft deadline for the London IETF is slightly earlier than usual. While it's usually the Monday a few weeks out from the IETF, this time it is on a Friday, 2/14 -- Happy Valentine's Day, easy to remember. Please keep this in mind as you're preparing drafts for this meeting. Thanks, --Richard --001a11362860f5cc7c04f1e9ab37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear RAI folks,

This is a friendly remi= nder that the Internet-draft deadline for the London IETF is slightly earli= er than usual. =A0While it's usually the Monday a few weeks out from th= e IETF, this time it is on a Friday, 2/14 -- Happy Valentine's Day, eas= y to remember.

Please keep this in mind as you're preparing drafts= for this meeting. =A0

Thanks,
--Richard=
--001a11362860f5cc7c04f1e9ab37-- From jim.forster@rangenetworks.com Sun Feb 9 20:34:59 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94AA91A02EE for ; Sun, 9 Feb 2014 20:34:59 -0800 (PST) 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=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0a4SZz0uqp2S for ; Sun, 9 Feb 2014 20:34:56 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 801811A0237 for ; Sun, 9 Feb 2014 20:34:54 -0800 (PST) Received: from BLUPR03MB406.namprd03.prod.outlook.com (10.141.78.23) by BLUPR03MB408.namprd03.prod.outlook.com (10.141.78.25) with Microsoft SMTP Server (TLS) id 15.0.873.15; Mon, 10 Feb 2014 04:34:44 +0000 Received: from BLUPR03MB406.namprd03.prod.outlook.com ([10.141.78.23]) by BLUPR03MB406.namprd03.prod.outlook.com ([10.141.78.23]) with mapi id 15.00.0873.009; Mon, 10 Feb 2014 04:34:44 +0000 From: Jim Forster To: Mary Barnes Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwA= Date: Mon, 10 Feb 2014 04:34:43 +0000 Message-ID: <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> In-Reply-To: <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [50.22.74.2] x-forefront-prvs: 0118CD8765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(24454002)(199002)(189002)(377454003)(51704005)(93136001)(86362001)(94946001)(63696002)(76786001)(76796001)(77982001)(54316002)(94316002)(93516002)(79102001)(59766001)(56776001)(36756003)(74662001)(47446002)(31966008)(74366001)(74502001)(15975445006)(74876001)(81816001)(74706001)(83322001)(87936001)(46102001)(81542001)(19580405001)(90146001)(56816005)(83072002)(51856001)(81342001)(19580395003)(85852003)(53806001)(50986001)(65816001)(2656002)(95416001)(85306002)(76482001)(80976001)(54356001)(33656001)(82746002)(47736001)(87266001)(92726001)(69226001)(4396001)(83716003)(66066001)(81686001)(92566001)(80022001)(49866001)(47976001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB408; H:BLUPR03MB406.namprd03.prod.outlook.com; CLIP:50.22.74.2; FPR:7EE4C77B.2FD61521.71F22B8A.84E05168.20164; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_D1597216-296C-4A84-9595-AFA16499F0A3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: rangenetworks.com Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 04:34:59 -0000 --Apple-Mail=_D1597216-296C-4A84-9595-AFA16499F0A3 Content-Type: multipart/mixed; boundary="Apple-Mail=_87E19733-3E4F-474A-A8B1-169B0B6F1F71" --Apple-Mail=_87E19733-3E4F-474A-A8B1-169B0B6F1F71 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 6, 2014, at 8:46 AM, Jim Forster = wrote: >>=20 >> I think it would really help if there were some diagrams showing what = IMS protocols are being used. >=20 > Well, I can certainly provide some diagrams that show how the system = works. Much delayed; apologies. It's a bit simplified, and where it calls out = Asterix, one should read "any SIP switching module". For those of you that are inclined to read code, it's all available, as = well as web site, mailing list, and wiki. OpenBTS.org, = openbts-discuss@lists.sourceforge.net, = https://wush.net/trac/rangepublic. We plan on bringing a Dev Kit and = can demo somewhere. -- Jim --Apple-Mail=_87E19733-3E4F-474A-A8B1-169B0B6F1F71 Content-Disposition: inline; filename="OpenBTS Diagram for DISPATCH.pdf" Content-Type: application/pdf; x-unix-mode=0644; name="OpenBTS Diagram for DISPATCH.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjMKJcTl8uXrp/Og0MTGCjQgMCBvYmoKPDwgL0xlbmd0aCA1IDAgUiAvRmlsdGVyIC9G bGF0ZURlY29kZSA+PgpzdHJlYW0KeAG1Wcty3DYQvOMroEhWuIoNASAJkInzspxDcoqrWJVDnENK JZeTkpJIcj4p/5nGawgusVyuHrJLyyWJxmDQ0zMD3fJ3/JbXBv+FxI/mVvWixw9vG8nvrvgv/C9+ fnGv+OU9V/7f/aUb0No2vHfDbRsuGd27pnsJuObX2TTu20f+4czPHoF63vQyQjKr6nBJ9wCZ7qne YjwNC18/ekut4e6rqW0YrvuGpUX8fHV3efXPp39/v+Z3f2DV9JLkkuNFHgdf3vDzH28Uf/s3zFty DyFf3GvnHocjOdxzCz+5S8V7LZT3puq0aDig3wxcmfDUfbzCl+GGnQ+Dc+7wgVf/bfjwJ/9hwNTJ 74cDt8JI1Rrt8NmABQ1DHfGPJvgPNFxr0Xq6jPhtwP+VV0efbfgrieVWxyf+SvHqhb/QvKI7R6f+ Vs2rzzdcCjx6X22YH4Z3fuPDT8EJq52ppBa2U3Xm09EmMolmfb9x08K0sy+SkfTs5cQAtnI3VdsJ VesuGuCcHg1wq/abyhyf1sIZJWw7B4OHj8lVr9wi4EPh19Dy6jwtRuIdPMMuqMlqdkzPtrmpVYPp 7dJqfHTMV2Nq0czgEtWdVx5K9SJwTnWE0mOonuGDv+B3w4fLLFxz1sepRobpGp4HnRry9o7NdrNE JfCTIOzzSZpOmL6tE409i8BAJw0nLxKPFjw/ExkjRac71RTjQkeOOOM9WWSbrog/iIbwjAIlxg7b HzsFtmXrH5VQtVZYbYwzMgrW6FrSDPgWlgSpCNwm28p0Z6VoKxqgZStUI70B070Nwcu8Ipfgmob2 c1zPEt3Bi1XKXgTeorvLHA9V9iJ+zvHZRhjrNwAyQztBezNXeEN62m1YYBDJVJ+AiGUAWhb9aC6b ZFCFosAUtw0ySdZ+6VgO2tD0khhMdKdnRClo6yqLpjldWSN0o/PU+2xM3rGDcElrJgIScvM+Juv2 mZhcBH5CJhfxF5n8VdI0KgyWahV6W3gi52mWaCOJ7ci368oYZ/YsUSqJvNubvpj4yVqaLC9jXJAh A9GzaRlTkOKi3xQShmo6X3lMFYDKmB3pZwdcLSz4WFR2V8gEZx1ayBSVvWiAVkZYWxcqqX3xIM0z xUMR+AnjoYi/GA+v3TaAO4cpfBiFMmDMvklqz74eoyDQMk8HsaCg4InpgLkeYGXwFNeoOgRP3Osp d1elA17tTAes2psOihbpxop6WsaHag4GUe6kbErLpyQ0enZvGe/mn8kJGlt0Rb2ay0k5mlEchY61 rXvR2qaPiLX2TSs+lFJC+4DGl1Bw25BfsCR0l6FCg1L5xiST1RMvniRQuEDnh7chp2Hd6GOCnKFp OYs8CDUnbsAjXlW9UDSJKaH1SXIbiHZOsDLhJ0lOqL7sxdhY9rKK3kxPsCUelbCoQt5RqDRoP+Ec 1+fPNmGpGlzu85dQtwTj8M5nCTxXi2k9jF3+xjkH+0cFFhGY9nheDqZBZ9SiEtsf4NIeXZRWXTlN kl2y2NyzUlmXOWPWQikXC21jZ0HEykG0iNUgwnDKNseCY8mPeQ4Hq8F/mThMj6iGpovoULar5V+y S8tOdHJ7jcz3neOR0dgARaxiM1XmO1txrrWEmvM9ivthrc8SeM73WeZI1P3W6wl0gwhGEr6L70iO h/K96FKcJJrOtuW2guxKHDmj/DFOns67KOpi9mXVdy6cnfim5Lsj1Sz5TxlLITL132KIFNeK8KAQ mWIhRMj15dgutmyZ4TNt1goJesb7cN6ywHvXes2wyrxfc54bLSyi5ryPUvwg3mfg/uCpnR485REw U3yLUs8J/vf+wx1ELYlo1peWZjK9P1lMHao7wxhbZOtYiKnAQfwGNfFbvNxRfGVuC6LNxiMYhY1t uiade/mDNIBB0MAiittU+L6J+f6Y+PWoJaq2FzDAhyucubXE+uLiNKwPdcdCMtr2ozsqzFaoUYlJ owudjVth2KrTt86fe+aYEVk3vehUCXkxmosN7aODooj6VEFRBF8MhcSY9EmEgcNRzPqSIBSi85yQ xqxqmF67P4eA/SVqLu1o1gVT9GWscepaLGZcXNi11Mz8VjrF1rpGXR/+urUVeUVeZu18jOlsFWNM a4Miu4CbsZK9+x+MPbyUCmVuZHN0cmVhbQplbmRvYmoKNSAwIG9iagoxNTkwCmVuZG9iagoyIDAg b2JqCjw8IC9UeXBlIC9QYWdlIC9QYXJlbnQgMyAwIFIgL1Jlc291cmNlcyA2IDAgUiAvQ29udGVu dHMgNCAwIFIgL01lZGlhQm94IFswIDAgNzkyIDYxMl0KPj4KZW5kb2JqCjYgMCBvYmoKPDwgL1By b2NTZXQgWyAvUERGIC9UZXh0IC9JbWFnZUIgL0ltYWdlQyAvSW1hZ2VJIF0gL0NvbG9yU3BhY2Ug PDwgL0NzMiAxMCAwIFIKL0NzMSA3IDAgUiA+PiAvRm9udCA8PCAvVFQ1IDE1IDAgUiAvVFQxIDEx IDAgUiAvVFQ3IDE3IDAgUiAvVFQzIDEzIDAgUiA+PgovWE9iamVjdCA8PCAvSW0xIDggMCBSID4+ ID4+CmVuZG9iago4IDAgb2JqCjw8IC9MZW5ndGggOSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5 cGUgL0ltYWdlIC9XaWR0aCA2MzggL0hlaWdodCAyOTQgL0ludGVycG9sYXRlCnRydWUgL0NvbG9y U3BhY2UgMTggMCBSIC9JbnRlbnQgL1BlcmNlcHR1YWwgL1NNYXNrIDE5IDAgUiAvQml0c1BlckNv bXBvbmVudAo4IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4Aey9B1xUx9o/ntzylv/7 /m7vN8UKtlhSNPUmmh5TTTXF5MaoUdr2XbqI2EsSe6+x9wio9LqU7QuogICA9L4sHfb/fWZ215WY BLyu4nv3fIbhnNk558w8z8zzneeZZ+ZYLK7DRQEXBVwUcFHARQEXBVwUcFHARQEXBVwUcFHARQEX BVwUcFHARQEXBVwUcFHARQEXBVwUcFHARQEXBVwUcFHARQEXBVwUcFHARQEXBVwUcFHARQEXBVwU cFHARQEXBVwUcFHARQEXBVwUcFHARQEXBVwUcFHARQEXBVwUcFHARQEXBW4tBXqsr8N/Hn7gutti 4eHWFq+Pb7OX3lYd3GdPsz1jYJbfoVT2Ettq8b0EW63Yf1Yv3N77YHfxdGfHtldfU1Beo+4eCwVr s7Fn4Hdce8mvrM+65sL2/IH2H4VkB6+j9YqX3KH8tlzO5kLfn3+1/VyforYSX//XOzHVoUacMw4J 19TH1lyvSbzpF7wMjo+1l6pXwb6f0/GuO/LcoUqOtXZIHnjVQuHsQuynEZD3xD7UAo9F3h4CqS6L pdPS3WV/i+0n+o1EaCcPdANSBk7gBe5Bqbot3VfLhgKyGlFMNaBid1Kg/APnQGFQJFYqlBJXCCgx 4h5LV7elAzFLYLXo7u7q4NfIi3tYPl4jfqc1Znzk6c6O8UZGX1ZgVn5GZ0snyt5l6eywtPVYOqiw xB1WE2IG4xSY1UnFg8TrtHSh4Vlhmlhp5RnlHWgHiolisfqiwB2W9k5LJ/UanogK8QZn61OsCs7m Qt+f323pYmQGS3DCDlxbk67Wi2rD/hh/BxoL+l4eVIMH4lgP2MS6BufW1Z9YXSH6wEdIOSdWGWXh 3ZlqQCSmCMxjPYR+siZRGUgUs07BU+/U2Na6qEYkBFjv5nRAxe3BWncbAZBhIATGDpSZA4e9sNRC ePGulpKyIh156NefPnA/J8lVIrBuyJ/LfqKHs755TbOkRGvjYRlu3zmVw8ZTCHOUmRUerLRTihXW TsC+UYYeewsOFIYXE8VjJec0tw0iUIuWDggEwFhnF2AX7RbZwQmLpZ2y89tt9/An0BNJwljJwk+c FdtIhFfbSkGFZEIMkNRuaSeB1tVBYwYMI/ALHTbkBd5S04Lk6WLVspUZ/5FqjehkAB2cyOiLXSg5 WNPRaenoAMk5BVg1GAUgNq0g7EAaVsGrlLodl3hnV3dXDxWvs7sLJ53dHVfxmFEeVcGvdDAu8NM7 MiamsDEQqwrvF1erxipra2kgCEdeJ1aUExZtBQeTqURfYgQLdIE/HlgXRoEp8U4+rLWhf7Zez5IQ 2SuOE1zaKs7OecrtjhnhGbhYWcQZhXZjKy2ri7XE1jzsV3bnj0W4ERlZ3t50sD/8ey8hKt1umtjL gGIjWA8HOuCU/4SYZ75aVVv2gfDf3gPtZbefgOW2krM6kKRnXbTb0gpEtvQwJO6ibkyHtX4cnJHR 2rLZU/CrkwIKxQPhLQt4EaWQimHV2VEYO484U4jytnriP0+kytoSccLTKXEgHUAqKhmrHs6h0TPL BBvyUfVRcyiTrWAREBlZkeAkyt/QY9GESMFi2h/UX5QOxCfdiqlXnIXUyjCuA1MGGvH73RCoejAb UWPCqbVh4ims2lRD1PjWVtJWBjQYkJwru2ROZE0KIyAEa6nwH6m3tnT9JvBP3sDIzqqBM1AbtUId 7cZJ+/08nzU3b4cDIabyoVC2gxXJsahIuPozL7At74//x1227Di19UEij+Pj+Tme9P3E25vCGycX 7CjJtQcJQVs7v/aXgXTFCUjtkXU0XhecQ7R3o33igHBv6yQYs9Ea/9ssBL5MPHKZST/aM/CH0CVr GLb77L/fzBN7se1cQAoFVICJeAiXFlZgVieAEaCLfqKD/QOT+C10hT8e+EPsOVn2gRFZmWKrAykw VDBbsVmTg6W9jelQVytkr9ltPwELzD2dzd2wQcDKT4yy6bwYKYA51KLs3BwYNL/RUqCGaF6IrfxB j+qysgRsRLNjP1mfjnPHyxt954/fh+bBuiWPQWY2eOtBV2Z4BG7YSI/S4dT5Jfrx8v6rv14lKs6s VefIyxqbdfqPCQv+K1XYkUS399wqmq5pKbxKjvENEglVowbAAjojBdjQbLYXAi/rg4km1mbr+Nrb eM4bJy86zh3o41gp/M6qwAt6g1Ry4m0oFy+8vSIkvQlrUezuzvaO8oqapDRVrFITlZwZl5Qclxwf lRp/ThkbnRobm0IBKXFJiQmJyQjIEJ2cGp1M54nWlES6K+nmx7HJyQjRKYkoDwJeSpcsTkpJTElJ SUxKS0jRnE1VRaelXjyf2dZcAU2Q61NoWPzgotHKHP6P/XQtQ51I/349urW9JfvihfiktKj41Ngk ZUJKWkxCclyiMi4xMxYhKT02KTU2OTGWcYSR3SmUvzFugjXRaWlnUpVnk1M1ORepM0MKYoxAZIf0 Y8MiEoa26U7GiH7RZwBmRiXQlljngvZLfYoqy0asGDWxC2YzIlFHJ0497K/DW0ArIjwL1n+8oIjZ eIH9H4AU7WuRHChvFXFUZzrADQzJoUDYAy5hw0M6Y9BAiamgkFeIr/LCyjDekDjzeKX6FfNq2oYf VHGiAANfPuvh8HycMsJx6g2QGARxDLxUjH3WujCyoei2Ft4v8tyqzCg2aoESI1iFAyxRXe0QEeig m3btlS1e5RW2ek7oKu+w5d5hy7wWLfNavMR7EcIiFi8RhC0TLMRPK70WrZy3eKXHopWChQhIWe61 yIkxHu6xeNm8JYvmLVmCc7wdr8aJIHSxcP5iwfzV3qFrZy/6GnkWLg+9fDm7pdPM6mhTFVFfqyXQ RmvGQk6Qq63d9uPt/Y/yqC9krd27V4xqhqyYt2AFmOITukqw6GtU02vhWo+wbzwWrQYRQHZGfzpx Kv379XyPxcu/WLBs7qJVnqHLl23aWVpaQxIO/OCEJjcJiAJIACQBIqz9/fbS/F95u70VcZnOaskE mk2wE9ZSYMctr6+95VMB+NtROs4L6hRUtn+l+gPhXlQLFUJAk+INjdePXdnBl8GuNQurMlHE1vxu 3znejDJzTYGXwsomjNesPYef3Ailrz4QzwBRECPJmmo754+3/2prtyw3/+22xzaSWGmA8oBmdobi 8ppq3QilnHSPjdr8P+trfFzMh0Pd7d2WMU8///I88St+S14O+eaFQHv4+oVACs8HUUD680HfPBe0 dkrw2qfnU8A5S/lmSjDSnRLjsRSCv54csnLy/NXPB659PnA9CoDEV4K/fjXgm5f9Nj/nv/np4M3P +q8Y/PTkb08erW9u4M3GOmGKCnOj+vfIayPM9364fQnog54LFz41c/ZTHgpU8MX5a54PXvOc/1eg 8/OBG58L3DglCGE9UT5w7QsB6xEYR5xF//5ylvPrtflfPz1X/sI/PfceiaBZ36uERsMjAYlpR6vM x0938oHiQ2iR3LKN7pCCftUO1zIaZEDvteoXtwzjSNV1LI2tYLycDvTmEgzsINl1xx4oPBfCVAte R8cY9b1uQGZOitse89IS/VEUVAKBSszPeGehkRsvJ2Xr24H8vZ+M66vP52+xpVhfakvk77u9McoK WUGBDdGvqTWRxRasxOkvfa55npMu7NSm5/MLhrwQCeShQ+aYMS++vjg8canqUpCqJFhTG6ypX6Cq X6CuRQjR1ARpKbD02iBNvb+uXqGv99PXBmhrg1jAiZMCno/34u0BugqEEJRHXY8yUHkyryzUVIek NwamNcw3tIaprwx56a3DUVE1dbVclyd3ZmbqIwimit8BB3ghWr76jYAFs3edXJBRtEBXHqyvnK8u n6+uJDpo6gO0CET2YE0NSEHUcBrxb4Cn4AuKulB5ec7WYx/4Ldq67wSwh0kSHvEWSGAEYCJ+DMQO 0792Yq0BF2uAObi+dVkaOjorzWaEqmZTtclc24TQUm2yBn7ppLjebDa1tnTAHd7W10FkrvxyUcxj NhLgOfpX3wGWG6IM9gZmcmCcQNSXYG96nH23K2bEBBeYgEIhOEN4BWj8RANUFvrdUfAMDOMR+MjX ShQ83/Zw28uoCNY0VpqBEqFMNHRFM2YDWAJYx4NTCrG18L1+dsx6287t3LR3RU5o7gFosTRbLCOn vhsYoZyvuSLRN4izWn20rQpdm1xlkmtNCoNZamiWGc0ynQlBojcJDSaBEXGTRN8k01Hs1MDe2yQx 1Mn0dX4ak5/aLNGZ8Uaptsrf0OCrMYszTRJN4yJd9bBXPzgYea6xvoktxAG/4O0CczobHZGFkwjB W7KVF5wOt40x13kxyipdtPJd37DPtx0HO3yNtSJdlVxf7Wusk+vqpLp6mbFZpK0Ta2qlulq5Hhxx LvH7y1mUx1/fHJhW/sW2k6jFtn1HaWaJ0RkRd3UGV7inJdWfus6dfKBWaGYYwULGwSWx02I29aiz C7ccOb1g0w7F6nWKpWt8F3/jG7bGb/EG3+WbZEs3yJeukS/72mnxV8Frvtmwf1+awdhoboELBxWP ArV/NH70CibOyMmDDpT/Tj9oPh2OBGzoQzW0OxUw/YK1PaomNTuH2vLTWxlz7HB8I1Ko2J09Ha0k pmiwhFKy/kJzgFBaadyKgHN+n+3fT/MMlDB3tvLVlLwLciJQj6NncWFIyG5/y08/9FbmoDqDg4ws XO1lJACF7AdlcQj29IFyYi0ckZr1Plu5WDrY2mixuL063S9S5a+pERhaPYxtXsZOua4jMLtbrG4S ahsF+iaRDiBrRV4xgW+T2NAk0zfIdQ1c+DspxmMdkLfBirx6E94uNwB6ajA28DO0+Ge1QOcd/vL7 hyJjaqobqbHSKBI1pCp3dUOVZPhrG0MSCaw/shMbSW77fxTcN3Tl+5KFs3efCzbWequrhVkmeXYj cBawK9HWSQ0mgK88y6Qw0rBHqm10EuWBuTfwZNwCjsBOAuSdJgnaefAY7xsdbe2tWHXNeMKX+oL8 WIRN/LmzDyYcuMNwp6W0pPH9meL7Hn9p3LufP/ml9B9zfV/wCHzFK2Sqx4IXPUKf9Qp9xmvBs97B Tgw+AZO9ZOPfnzF0yotfBi5IzNR1YMsZGH+AvD3tPWzxO62Cp4Vp1PJtAHwH84DgixWfbUcA2OWV vWqlRAYuDyACMD66XTGGPvztEEbghF0koWycF/SPC2laDUBX9mLj/GqevvIKz+JMt8I3EYqkIgv0 OCRw2LVmsP3Gc9zmGAXkEoNKioPGVEQUGpEwauC/PVDSADx4+YjifIRjBSGeDFYAed2nTg+I0AQC Z/XtgvNtPtBn02pCoPCqa/z09VC4YFsOUtcgBGoo+GurAzXVsCuGqGALrQ5S49xZMX9joKYySIPX 1YRk1mGE4Ket9tOW+qmK/VEALUziVYuSch5565P9J89V1rbxzsXbdlsPdzdFGgJGf0QE4hLqzxsX TgbMgb7mH/rVB5Kln24966drFBjMopw2oaraF6ZmfSNMzfLMWjqHhVld7ZdRHagC2cEXJ9K/n5xF YerCVBWzNh+ZJg7YfuAQ6SA2GdJGEgXjejqI5GAI/g8k+ve/IXS3d5lhPEdjKzV1PPDiO8/M8ws6 mxmUct5XmRekKg7NLA1JLQlKKvJPLJKlXpanlSAonBl804v8UnIDozVD3v58yJTXvpAGgsyM0B09 PS0oLbQIIjn+7nz6oxLmbiuKYUSHKrW3mXq62zDB1NrWkZ1btOdopDzsm0+FwR/7zP9EFPahMPQj Qejtij8SLeRl+NBnAcrwqWTxF/Ilq7cd0lwoNmGvOjQjQKUViYk//yry9nSdOn1y6bo1YRs2Ldiw deGG7YvW7lixfvfyNduXrd22eP2WhRs3hbKwcMOWsA1bFq/fNHAClWfrrvnrNi/bsO1UdGxVHWDK Cr688YI4nFTUmK2inM4G3kHNkg1yaOjFR1+csxx5A8N1QSqTWNfuqa1T5DQEpld+uDNhfOCmccEb HwjeMDZow6SgzY8Gbn4k2BomBW98PJDCo0FODHjpI8FbH56PeCPeiAI8GkiXE0I2PhSy7pEF6yfO 3/RI4PpJgeuf8V3x2wn/+MBT7r9qW9Da3aGb9i5Yv23h+s3fJSSaO2nczwQNZA0PjD8gyQCT/Cil b8iKD+TLZ+yIkmnrvfRmH6M5yNgkTy4e77/x0dCdDwZvQ3g4eCuRJWjLowt2EF+cyYJ+PRyFmRC4 7dHgLSM/Fw+d+va0OZ6L120MXbdp0aYdC9ZtWbp+K6Y70VMYAtM/bDx2Rx+sQ8FW2HWpvn7oMy+9 olgcHKsLUJXIDNViQ53Q2OCjqhakVyv0Jr+sFgnmaLKaMVkjNJidF3z0LbBKydLLQ5RFb4auf/Cd z77adQDtisl0kBuhk5Y1IYkHJrnuUC6g7Fya8YVrqFo3qfaWkqqGTzwUYya/d99j742Y6jHsFe8h rwlGTFPcP1Uw9DXxbQmDpwqHvCrir8YJD+6vCd2e//zvD019a6Y8xVCMuoAnJK7YyMiRRYxLXGD1 iVfIf/RUxPPvTB/72rQXhIrnZCHPysOeEy581nPBS96hL/iETBHNf1psDc8KQ54XhCAeaOF5n8An pn/xxBvvbd1/mCiAP/LeIQrQKYvZVT8o0yfy/cuZUCoeGMbQGBeX+GdDXpr0MdE87/tBp1XzM00y batQXxWUU+NzSn330Kcf9V83UrJ0tGLFGPmKcaIV40UrHhCv5AHnE4QUcIKfnBfwujESBLwab6G3 43KUdMUYybKx8mXjZasfECx7ULLiccmScZ94vegd/KJw8RSfhS+KQl8SBLzmLf+12+jcK5VslM8M gwMeef2XrHpTMv/jPWdlWXWCrGZZtlmhvPLXT33/9425I3zCRouXj5atfEC6kiouXjlWssp5lL+B J4M1I6RrRkhXjxGGjJ8ne9JD+opk/mSfgOcEga9Kgv4w4bHglV8VlJai1d35Up93zu72DnNTZ9va g8eGvfJuUGTGQk25TF0NZwmMmkQ5HZKsDqmxVW5sg7OEUNMg1jWJtS3OCwJdm6e+28vQJctqg2ko KP7CnI0Hn/zgi+ziKhLpHaQMWgc+kFX/N3jA1QnINZuRtq7N8vdxL/7lsY8f+nTVQ/P2jJi1d5zg 1BjhaTePY+OlEWMEx29LGO1zrFcY6XXkAY99j8zb/vA/l987edYfx089FJUJ4wmqYjUK2aS3gwwn UO7LAd7uPHDqpc883w1Z4RuZ7HE6ZW64SnBGL43IEp/Si77TekdoPM6o5p3ReEZqRKc1SBGe1vqE D6AgjtApwjNmrd374pfCTYePk8rU0UYWczbtSwy30YdhcV8p0xfq/et5UDwUGCW0Ii9joUOZYQrs YMj7TmBERpCqSaJrFRtr/HTlskjjXeNf9zqR4XNO73lGOzdcLYjQCcINnmcMnpFZCF6RWbhE8Ip0 YqDX9QqRWR5nECgdpfKM0HuE63widT7hGlmEVvydSvCdBk1IEp4pOx4v2nn0z49O1hZcgbspM0gA fGl0xMhgZ9u/Tuab9gQwS75o+TRF6Mf7z0kMNT66BszkLtHW/vl90WO+38w+lOARofaI1MyLUHud 1c+L0HlE6p1K//4+HKyZe+7CbPDorM7rTKbPqRTR6QzhGXTtjMDTaf+YLZItXZ1bXMxMawS+UFXu /KO7pLr2HR/ZtAVfLcq47KupBtR6atsExm4fQ6eXtkWgwXR8k6+2wU9bhykDf00DBXWTM2I4Qsi0 7XJjl1hV55dZEarMVxyNmfKFYPfpWKt1oRvYy4jOdq5jIutO5gAXcNSnyY4CH6rmTstc/6//Z8wb 4z79aqzHodGS+BGytOHy9KGy1CHixKGiODdpops0/tbHI+TJ7rIE/l53WdIIeSLFkrgxosixngfH f7F+0EueT77vqb2EvYA48lKtOG+s8oou8WOfDvB416Gz0zwDZ248sFBXJNOXSbPryA1D1eivNvlp yEsHZhmxoQEngWoKaKLw2xk4Qaqpwwyjx8HYF0TB3xw+gTEJVZ88Fhj42uQ3iDNgkZdxi2l84AcC GEi8xD/ogm0mS5f7a2/6Rab7aRrgYeVjqBepysXhF+56/JNFqtpAVZVCXRVoqA9Q1fqp62XaRmAB DzhnoR7OP84LMLqy0Pu9AQazQgWfqwZ/baOvtkmiaYADNtQKtC6FtjZQX71IU7o8Ofsvz7yalluK NctUa9S9F/L2qRXfukzglGzJird8Q6fvOgsHZuhK8OVelFp1z/vy11YeDEwuCtBV+eqqZepKXwP1 EV9Dk/MofwNPRnvw1ZjADkxSk+e5FqEJ7vGYng5JLnxRtkQYtqLwSgkaXlcntvz8P3H0WIoq6ya8 /YnXvkhF2mV5lnluRrP0vEVssAjUbWJts392q5+62vOs8YPtZ15e/u0rK/a+smK30+K9ry7dN3XJ t6+u2vfqyh1vr9r6sv+icW98+ME8CbZ6a6g3o+N3kjWTFv12dMEwi15xJx9cjpFLcDu+MAJHgkhl 1uCnpz/y+fKHhEdGymKHyNPukabfK04dJk8Z7Zs0QhrjboXdZAaCtzQeLkkYJk4cJo4fLknibx8m TR6qSB8mjp0gPvHQ7DWDpnziv2or5mNQF5JUbDjBYIV4BGaBe33kFkTdtv3fTfMJ+WzzMX91iY++ xifH7K0ziY3tEl27WN+KaSyvLApwJpHpKIj1dD5wgiirFeA7+0jKq4Er1h49SW0XzZUvVyExTtc8 0L8B1pJRIrAKXKCCUfu0IS8hEf448va4vTYNyOurqwM7sGII8lwI5H30IywXBbRhUARPV4WuWa5v kRjahEZrEBnaEITGFucFkbFFZGyWGBC38HfxExRDqm8TadgKI51ZqDWLsto9jB2eWZ0CYwcm0aQG DO2uhCZm/fHp11QFFTT3Q1VmrGI8Il4NvAPMkixa9oY89NP9ccSFjKYgXdvS9Pp73vd9afkBv5Ri 8AjDVKEOi7/MPjo2Y+hM+veXs+AOzCYKQ6tI2yjUmsAyH32bMKsb/ArV1k+WLhMv+yavsIBaJXYS hpIC9+Y7/eixFFTWD3ruTcnJJH8dVgdgDrdLoO8S6zrlWjO6j2dU7ktrToyVrR4rWjpRvvIhyRKE R8ROiSeKlzwmXPKYz+JHRYseky0Z7x040dt//Ayvxz6a4zV/VejKDUkZOhp+Qgz0wOsDGAxN4k5m AWoCIdxOiwcxd93cYwnZ8O1fp3z+iNf2BySnB0li7pNn3u+rHSRLHyKJHyU9O1pyZrTk7ChJ1Ghx VF9iZLu5YYwkmgf+2JHS+KGSlFG+qWOEpyZ6bxv/juTpd2aRckf16iWyIBsQ+soscHnHgePTfAI/ 2nTCT1uDxSDwMRDpSJYCdoX6Vo6wPkactMIxgC0XdaL7wY05NmDoPutwysuKJRsOHePtlshCRCA6 cCJRAj/DyYA5epfNsYQ0bCBWYj2v+9T3AyIyYA1jcsMEnVEWmX3X4+8FqslAIdI3wi0E/OIsc6Qh y397+IURmj3wIqEJIaBRsUsT/J9DE3Kg82oulWIIaecOcQqMY/9YNGC4xfghXQxrc9jHu6PQ6qTa Zj9t88KM6r98pHhx1SFZSolC34hugorbqnx7iO/YBr5/zvjCCmnt4xhmm+GDPVmxUrB4ZUHxZWvf GWjU739DQA0gEHIr6wZPfjU4IgPWIeoRetIpyPaSWamIyZ329Yl7Pgn8+2fBEwI3PL5419NL9yJM XuKUePLS3VOW7HpuyY7nl+x+dunup5fufmrprqfDtj+3YNNkYdiE92bP8l+UqDa2t3V3t2L5Ma06 4UKs/1UfGHeAAeja+AgAHG8slrq29rc8/Aa/6feA94FR0gg3v8S/iVPuk6mHSzNGyRLdBafHiU+M 9Tk4cs5Ot5lb3WdtHzFr+/CZW3GOFPcvtrl9sa1XjMsRM50Y3GfuGDpzz9CZu9zmbBvz+aqH3pf/ ddwLxvzqnNwruQWVRSU1LeYONjUPA1GLpQssI8Tpy8GQ9+g0gf8Hm0/RcF1vwqgYbgbkb0Cwy4Uk NNx2jrwEzc50/LuBh0OMQAbOOZTyimLJxkNHmMrPxDbJDaID/vNg+9cXwty6PL3KZistSs4D20nj FawqwnreOkYfQl55pOGux99FClgm0DcxecJAjeHaQJb8NDxgTchXV8ORV5tfTCsOUHP7DK+t7pQ2 kA6ID4a8oTN2RaG/AHnhFrsgs/pPH8ue++qQNLUEu2cQ8a2IRqahG2jSTr2FF4kND2i0xrs5RtRA 3md87cjL+sxAovyNlQXtByy7UFU31AF5GeyaAnIafeIuvLXm6P/3/MxngncHJ5UF62r9DbVwfEK3 wpjWOTFW/FUGasuxzg67nGG7OWzAgu6MxXeLtRUhUdp7X3x/6BPPa3MKeHfolxp1YyRy7l1gABdj rCfXtLT+Y/q8Qe8sHCv6zl1yZqg8fqivaphM5S5KGi2IGuF9ZJTnvr+8u+L/vRx891Piux7zuftJ 0c/+IbGf47JX+NkTIh5+/jid3PQYD/zlE/K7n5Tc/aTwZ0/O+59JM34x/IU35oROmx38offikDUH D0cqzxeUNbU24sOgNL9J6476RFEX8vaJTM7MBEYRr6z/rP/Z/I4LefvYip3Jnmuf7ULea+kx0K/Q q8AypvO+HhyRyXVejrxeiYUPLtjy3298OXXFgaXqhvkZtQotnK9qsU0cApvBcUrM3Gaw4xncAGi7 G7bdHGyJDXJVZai6bHla3tjpc2f6hxkLSmHVtG6pMdDJ/GPlY1OikG+QZpba1rZxr3w09L3l40Rn 3cWx7grlIFEyPKxG+ZwDFt//zy13PTTv7od87p4c/Os3Vv5u2le/fWt1X8JvplE2Z8S/f3P1n95a +adpq3791vLfvb38j6+H3v922N+n+g9+M+i+1/x//48v//zYjH98INx2/GxFEzxhoT6guVFNf/Jw Ie9PksjZGVzI69J5nark9nr4v5vOCxGXV1E3aMrrQZGZvqoqogYzNX9yUj1MtHSkeEWougKwG6Rp lBrrvbTIADSEZQ9bsDojNnllmeCtwZmCE0zksbk8szynRa6pWqApW5Ge5zb1o01Hz1Q2w0o74Aaf /ZWHzHkFTiyoiqWpo2vcyx8CeccIzo6SJQ/2SXjAX+0uiBkvDB80Y9Ndf5v285dCRvmcGieNmiCP GSM6M9InHDEuER4Qn/2hgKlhJ4Wx4jPjhd+NF57ErPRYReQo7+MPScgkTlZx0fEHBYcfnrvj7y8I /3fsyx8Jgxpb4J/eJ9gFKVzI29+GdNPzu5DXhby9wNGpl/9WyIveiv7FkTfQirzk9oZJ3ufXHRvs tfC9fTEhhlppWpUffBf1jYJswCIFUMk5sdkzqx0Bjm0CXYu3ocUbJzSXh5QWTBvJdNULVaVPe88X Lt+cW1xD6+vu5APFB8TQTBJbzGtqb3/kjRmD310M5B0ujAPsDhPEjhVFuX++/a4xM+96aO542akx spgRkng3Uay7OA6Tv6PlSSOlCcOFlPj9AEdoJ4e40dJYN3HUcHHUCEUCFhm5iWLGBKQMRaIsZqx/ wnjpuQleBwe9Pf++yZ8ErdqCNRp95JgLeW97uwaniFnWf9b/LmszHz32sRnfMia6rM23jNQ37UU9 lkvlDfdNedP/jJrpvIS8MPbCu2lS8LqZ4Wq5phKT9XBuEeW0QCEVZDlxLYAgq807qwsBXl58hp38 Z3Q4b/cB/tKrG/wySj5ctWe6JCwr70pf5fhNI9ZNfhD6LyAGvYbLtbrm5kmvf3z/26FjJedGSJOw hOcBacKwWQd/9XzgXRPnjhceHCP+zl0ah7U8CMNlKYhpka8kCXZpnngbYnkKVjwNliTi1SPl6cOk qfdLkgfJkwfLkweJ44aL4uEFPcZrv/v7wY9M/ayyCXtM9ulwIW+fyOTMTFbIdSEvoaxtDw0y2pDd htIG0uFC3oHEjb6VhSHvvVOm+THkZT6iJnjHPbNox6MBa+bGZIv1tbR1VVarp7GZlk/qWkTODAxz 4UzeiqXE+NAJAvbxwLm3phlrxGDiVqjKPlt76ANRiM6YT6A10PpA36jOc6HsqAGBEevQ9aamia9/ OOjdkNGSiKHSuMHiuAcV8X99b93/e0b6p6nBE0SnRojOYhuNIdIkhOGKVDdfJVAP5wC+obLk6wan YjH297hHqhzkmzlImjZUkuomSXWXpQwSJwzzSxmmSHD3TRksSholTxkljhz5z7UjXphx+EyCC3lZ i7VKbzQAar/Wf/1pOs7P26ts/NKl87qQ10k25383azN6fV5Fwz3PTlOc1cLDyo68z4Zuxepdr6R8 IXzUja0APu/sNgSoonDBImR0WoyHsy9pQvuGkxXtLYMAdhNrspoD9LUffP3tO4KgnIsF3EjrfCHk rDdAml1F3k5Lc4t54qvvD5m+wE14Csg1wl/p5nnqr++u+c8nvO6dtmSC5BxMx0OlCVAnSc2UJwNz B8mSALhDFCmIkdIrxqWzkfdeWdr9CtVQabq7NM1dkox9Ntz90gZL4ofLEwaJYt0UGUPE0IUTRs7e NuLFmev3HHEhrwt5rX15gC1sgUDjmOJaVeQkbP3xx/7bIS/N8zb87bl35Gf1duTF0vjnQzc/IV/t EZeHDyWgTYoMHdzZiVOPr8u76TEeSJhLH7AG7Jp8shoEWbT1CnybgbnehmbsBA4X64/WHXxT4G/I ze+7r6yzsPNfey6QF0gE8OU6r8ncDOQd/H7oCPHpwfJEIOkY6bnfv7XqF4/OG/T+amxhgW0rgKRD ZYnDZFByfzpGNgS235RTYhRmsCwVmi9pu5LkEZJEd5v2PUwWj1cPpj1A0mA5Hzl7x5iXPluxbqsL eV3ICxnCxeyPi+Jb/KsLeW8xwXu97t8QebGqyI68/FNEQN4XFmx+CjpvbL7E0Ezqrb4DU672HQx6 Ee1mXRLysv2IcIL1RF7ZTV7ZDZjbpX3PrMjbAuSdvv7wG8JAfV4+Qy0y3N2hB0decjtCJXosDHmn D3kvbIQ4ElOlg+Spo6XRHHnv/2A1fJmGSFJJhyUw7VPs7B0mCdnZpDPBrpiQF2+Eog0s5j8BeWGI hgl65KxdDHk3u5DXhbwQFy7kvbkiC6N3104aN5ekzn4ahD9HXsUZI3ReO/K+tGDzP2QrvWPypdhz FeZffYd9TIhe46SALsl1XrwLKM825uU25yZM8sK9GVu/YmON6euOviYM1uVd4nMuziaRM58Pzw1s gdthRd7mlolTPx7y3pIRoqhBciUC0BZLcX/+qCeQd4QsdpAUOm8qYNcdk6p9i6GNMnB0Wsx0aiAv Cxx5SQvmL8W+lzbk3TPmxc9dOi+6mwt5Xch700WKC3lvOkmd/UCoW7mVNfdMedcv0sh9m4Gq2PXu hdCN0Hm9YwrkujZCXkMbty3bew0ftd7c+CryMn9mL2M7TNwYDPDNA8m5y9Dmq67/aO3xNwQhmvxC pis6m0JOfT503bYefPUUErnH0mhumzh1xpB3V4wUxgyWfQ955dGY1QXyAnb7GBjsAgSdF/gnGxL5 i6DwQtUF7JL9menCVAtpKtywR8zeM/KlWcvX7XDpvC7ktcsQnAycYNcsXPO8t4UpHEr+TXaPhM6I 7w4Aee+b/G5ghBV5AXZYVfTswo1PKK4iL33vw0Bzr5wpHIVveowHgvJM7W3HJxuEegTaNBtfoqHP jrAN8wNU9Z+sOf6mT6guDxto3+kHR15saEzyuMHcjqU3Q99Zgb0iMX96dZ53kjd03pGyc4NkCdAl AXN9D4BdDoVOirluC6syQBbbXdL0LishjM+Y80UVMFoYLk9ym73X7SWPReu/pUntPhwA6B0HXPs2 94FSTsvCBoOsXZKizseGiNFieXDt2+w00vf/wS6dt/80u513oB8BefMqqwY9825QOJC3BrOrQF5s DjklbOPj+EJEdIFCB223lb76RJvS075VAN+bjrm2Z5JtGa/Al+AkWnwviT6ZJNPi8w0mTDcL9E2I 8blPhrwhurzC20m7m/Nuq84L2QasqTN3cuTFThq0abM8boz0LM3zTvIe9P5Xo2XnhmB5L9MlmY5J EMxh7kdihrw08cqnX29uTO+FnisFvKYjDGZlxiVUco68qMUQWZy7PN5t9p7hL3stWr/PhbwunRed nSs4fBg/QGKXznt7GfFvpfMy5O0A8g5+5t3g01bkhY0XX9WcHLbxUXwhIrpIoe2gTS2yWrCWVmBs ADTfXAvzNU8jr6o68qrC2iVdpxV5ydUZH4kzeRsbEftpqj5ee/hNAc3z/p+wNuP7gF2AXUBSbQsh 7/B3ljwgOO0mixomPztW+t0f3lr2y4neQ977CttrYEkRM+cS2JFv80/FVg8o7gflhBiwi42zSLeV Ke/DxLQifrCCNvpgyAuTOIzPcUNl0SMRZu1yJ53XqcjLx4RXv0nHLVfcVsPHimhsCMy0Yo25tOHp FBvxEB4cDKG29SbIbL+X3Xi9zGRBpXTkdH2rCCRFX7YGRr2rBGektvt1UJdnOUnC0E90I0/ht3DK 28hO3OFc47/aXwHK255g5Y6duVdz2u6l4tnCvx3yslZtI87VjyTyXgNqE2WYvw051nImcrpx7lyl m1URQ35Hjjjwy9oGQGHrY2332onP70Vse/v/8W8VcWszQ953rDovbQvZCp336UWbJ/mu9gby6mgN L9/FgoEvIS9v23auMbdnK9lZIvyjrPIHJ/TVbEdSEzcdM9vPKR2wS4uJiNdWazPjjgkbVwJ5RUYg b8XHbFXR/wkPK7Li4cu8jsg79F1CXnfZWTf5GSDv74G8kzwZ8kYDeQG49sBWHlkvCWSZsxM/QczU W+4CbV1SBEy0/3rNCdejmQILMGXBthDYhtc8nZ7A9Vzb665FXpiXrdZmq8OVLM5Neg4e2lhVBGtz mDORF20DUxISVYdQRduNosXShzYM9QJDrSirUaQxYQcYYTZ5Doi1LTJNM01h0KfTTD6GJuwS45GF AF962pacraRDfv5FYHzDvYNtXgonf/IAZJ4PJCLIPkOO901MXFilE7Vt2tKcEl3ISx2fC20m5+2C FwIEo2h8wFehbvLVmKX6DpG2Q6zBYLtdkN2I4TeRkTxMMOtE29lBCMDbBB+1x4fdcSO+7e6lbQYr hdncHIfMHchJc1JsTYQnOE4A0eRjaGQb3prZDnhtYiNtiAfxgntZ4KKJhkk/grzd3fgaOL4JbrW0 97DdXm+O0euHnwKxYD94ru5uFOD6R/+tzWiunA4kn2mHQHQZg5kas65ehv2L4FiLGUa0fEO7t77D RwcGERCAmJDDAj11DRbTTkfMJoltfvErl/at6Gt4AgKeSem0GzBxkzhImE6dzj5AQgqehpxUANYl +YgLN/7QVwJBGU6Ijg7sBk+HPYVfDqgYjOtVPOIs1vNinnfKNP9I7KRRQ9XXt0JiTA7bOsn3ay94 WOnxLXKzyAjK8DEk0YdkC9q/oclbZ8bWymAQPp8q0Df56BrRZUTZXR5aE8SXxNjopTfx/Tf4LC11 DW2bj9YsOd86T1OH7SIhDL205Losy+nxUZllgGkNdN5Ogb6T9m3ObvEwtnhmQeluA6PxedZAdcUn 6/ZNE/jpcwuZ4c7SRSqjNeaN8/tN1F5x+4kja3ol9rpEzus+0DFbL9o6/oTb+aVjIj+nksPej8Kz DyfUt3aMf/mT4dOXjxKEj5TFuktjRkvO/PatVeTb/P5XD0hjsFEk8JTtnpE41Jdt0qigLTUAoyPl pH6OEMbjUwtAveGSJOxiMUyuBGJat27Gkh/mEc0x1I7LBMHwl7Z6bSVjyyksvx3OvpE0REobdCB2 k6eyTaHZE5BTGo+ttBgKW2ecYc3GGqj7FIg51tOEL/KMwubSouix4ljovEOmeszf8C0+qNyXAxzt 1zwvk7FNaLoKXY9M3wO3BIhckb4en74SGuvQVllfJtjFqnC0Z7Rqha4FMeYvaMEa7RKDzVHNXvpG H10DEAESgHBcRwIZLZz2D9dz5G3F9AdQABkAu9ciL5fqrHcAkV3I+yPf54ViCyIbmuT6ZoxkAJo0 r6TpgmT2zqr1yqmBQMAeAhI95pvaIVsQMF4SaoERNDQC/mJXPcgHTx0JcJLYyKYlHuFXjNIRwHS7 /uujb/bWmSB2EAjHbaoc4TsT+Ezm92EnDRojkzCwyv2+NOWbkQeCwlF6fP+R/UdeRgeS5MxE4IC8 GK/CxohtA+HRSnQzIGa4qSfjJ23Xn0XfyEa/AFMk2S0KQ7MccImBkNbMJHYbeh/6Dka2lKhvAXYT QBi6CLvV1ImILzBjWk1DNOwhTOkn8joS5Pvy+fskGggpjjBByFtRd++zb2L3SIWqjpHUjPW8kxdu n+jHkbeZ1thCQFkpQ8MSLnMAx+TzjF6jbZPgY0b4nC6+YI4tH7M6QXAZ/VqHkSfyS1QNGNzKMZTS NMi1JoyR+HcGwSBskCXOavbBx7UzG/wMbcjjCxDXdQB5xTktGF8Beb2yO4h3OhpEBaqqPlm3902h Qp97GR0AvQDV4TVCDPI6cqQXtfGT46/svh8cRl73UY639yuD/Ub7ibVsGD+zbtVp6ak1tz702owh 7y/HR4jw9QEEfGMIX/f72eNe905fDeQF2NkcpZKxYyQw915JAjk8yxLxAYURwtiRkpSRMlo/O0gY 7+abfq84HtBJv9IeF5gXVlJw8EAm9LQhL7yR6SdsQoUdoUUp2JNqOJymsDUWUFWcwJ4AjMYG0UoO 5VQSKXughCaRSQFns8mEuTAyM28r4PUoYdxYcbwVeTfudRry0gAP+AgBLjW2A3O9DTUwnnjn0Ac+ IBAE+i60KEgSn6wmBAgciAUIc4gXDK0hFqSGTtKwtNTG0NoRMMyD9ECrw/yLdw5Q28wG+bR7KuE4 dQc8h9RbOqedxnnAT5D5Lp2XpCuJU4Z0FAMfmYxlpDPj6+3o/p7n2+fm0NgGJCUrhAZwTOMZ0B8p ULUg9jnaYkUhhaxmiBQpXEEgkSAo8HxtIxNQQGdowaQO0G63AA7YzYyAgDagOcCdsRWcJT0Cweq3 yfbiQ07KbOWp+fu+zV1dHQBbhrak9t4a5IWg4GINgqKzE9BKBxdx/Nwx7i/yoomSeotNigx1wFka ScK2QE3aBGlMgxas4iRQtu5lhMz4ldZ16lvRv7DIFL2AehMBcZ1IXytXNco0LQJjl092Nw2TaONB MlPgFnQfgZEJcAPwl+8LwVigJyAA7/BSoHl/kRdik1PDTiVHggycczsfcYKDF4zK3D/kJWDlLINe INI2StUmmbJJllSrSK6QpZTJM6qEygpxZj1+EmkbhKpKafoVRUqJIqE4IKXMN7VUnFwoU5ZKU0vk yQUBqiuy9EpBarl3WrF3WhF+kmfivESGLyJpSeL5Gs0SbR2UZQyiyEyhpY6Ded6P1u97Q+hHvs3W elBteKXsg0N7E0W6/ZzXmurPDn7J73XMY/udnm4/d7zFntnxV8en2dPtT0DB7Oc8J3oTZaNkOvCt 4bqWtklvfX7vtEX43t8PIG/qCBn2acxwlyoHixLcfGl75KG+qfC8gs47EuqwNHWIInOwQjnEL9kt OOk+WQzpobJ0QCQQ002c6SZJZyiZjBSWSMt/aAUQ9ptSxAzyjQGADlUwdymZEhAMt+TB/sp75aT8 QjW+T04/EQpL4wmRoVOz3avYjlVxPB2qLraOtA8SoH2PESeM+WLX8FfmhG7Y6TzkheGREJY5BAoM 9cLsemEO22nc2OEFqaLrEeq60MdF2U3eOY1eBuikJBmQn27RdcKjT6aFOx8ZxKjJoZ1jxAixoDV5 6c1esLpAyGBkTkhNZjo6J9EEiUQ6F4NdcsVnApyECZ7vsjaTOL0e8oI4sDmA/nOy277IaZvHjMYQ LBi9E6oymQwuAHnJ2mDEYB7GNCs+Emt0MGg0EpGzrDvNglm4JHeULNK2YJfAe3ELkBdvAcojEXns gfKwbDSIYjkZ40j5+j7yAvEgC5iwIeRFb3UQPKz33qoIAuO6r7oB5AXgQv1hGhDoaR00gl/eMPtg SAnGAYKNdWJjDbbux1AWXECDB31AMeTneyvBgoT5QQA0vqrjCzJmtaGnkMkIDGJb/vLRETCajJ+0 CWEbzRGwnYdBfzmMn3qmdPcfeYkL11LDLpavS6LbmNirnLwkYGQ/dV5qvUywmESqeqmyJlRZ81Vm 7VfpZctSCxanF/rFX1TE5UkTi0TKMr/MihWaslVpBV8rC79S5q9Qnl+ecXFF5qUVGYVfay4vTsn3 PZfjG3cxOC1vzYWKzdnlYck50qRcsboCwI1RKwSXTFsP1uCcIy9GU76a6ukb9r0m8tfklaDwTM2l qnBo4yf2c17HG4i/TyvHFMfzfj3c8UbeTjCaRiIO6LxA3kfe+AzIi+/tAnndxbG9dF6gmLtY6SZM dhcnuOGTfDD5MuSFTjpcHAtD8X0+AETlvTBK+6cASRGAvIBLrPrB1sqAXei8mIqFKxS3MJP9mdmZ Ab6A3fv8Yu6XJQG+AanQl4eLYxCwlAmJ0K8BtdcgL/sgEZm18YkEq205cZQY081QtMmCDWQHTMNY PUac9MDMXVjPG7Z+u3Xs/lNU66+1GULbR18HTRODapqqMAJhzZjU89a0iI3dwFyFziJVd2I0KIYj QXYd1GGmOpGpE6oubvHRdfoYSC+GWIDQoIElewgN4KElkYJGEy4Q5rCeUTDawBcQTBoTPYS5BbZT fhLyLuT9EZ2X9B1oRh7GtrnZpPZikh0CXJpFupKcLWcADYmbNJNlAvJaBT5kPm0vQBoujXz0zbKs DjZYaiFrJ8E0bNQdAFxo3LgRGhxiZpdoErCpBDCRiS9Su3jAA+nhP6zzcuSF2tvd1dHTTU34+vj3 U636xn7n0gwxP7nuQ/qPvERkBOj+aPA+hk4vYydAk8350mASJgLMxQCXMRYCldALwAJRTgMGtN76 BpAa3UpsZENNskW0AKYBzT7Gai99Jca9IDshcnajxFiPD7sDwdHpPLLrPbIw7U7YjX6H0RGUKYyv OEcI6wnW+ejINnDSm4LUNc/A13fxyoJitoyUkR4CE3SACGWy08oNnnhd+tzeRHvBwEGucKE8KHTf kRcUgy8EbMvMg6UNJmLf9NJd2bUpFZ3K0qaky5Wx5dUnC0q3ZeYuOqdbqCzdeNGcWNuTXNaQWl6X WlGVUlGcUlGadKUutaoNt+xMzVsartmXVR1T2aJqbDdWNSQX1+64UOObfFmeUUNGaXW1wkiTbuhE 1NegiTDk/WDDgali/8z8ErQ3lJ83SHCB22Ts1USKY1vlPOLM4ozgGRDzS2Rw/JWIw47r/opfemXA 5Y/czh/CMyDGwfPzPoxyAmtgbZ4w9eNB7y4dJYj4PvJi3+bhkgTAHEfkBxTRQ8XR+DYBtFFsVTFU EPuAJHGCJHGMMM5NDFuxEinuMnhk0S6UCDAOA2QBi4P8zg7yO4NJZOYcxfyQRenuYqAzzdICKPHl QTdFIpyrR4nDH5BEjBDG4KUAU7ahJWnK3C5NuC+LpyLRjpHkaD1KhMVE3PLMdep0QmqGvOM+3zXm xS+WrNtmU/E5PX4w7j/yNgh1NZDbaJ+CzFahpgEgK2KuOxAsEMV+OoskrVmqqsInngVqyinQVIg1 lZj+gKgHbpKhzNCJhk3DPE2DJLNSmFnmrUKeWmze4odsWswak0MCZPv3kNeq87qQVx5puOvxd/01 dRCh6LY/pPNC2ELngnoLgzAsFR7aeg91lUBTLtFWSTWQyZ3cOAzDl1DdBK5JVRW+WvLFUqhbpBkm UVq1IL0cPJKo68EvyCVuRhZqWgUqkzitVpRaIU4tk6SXiVVVYDfN+Gc1Y3YY5XEMTNRftTzjEqGX ztsDJwwa4HP9is7Raju7rNL+B1vwv/wDRASXP1zU/PjzbgB5Md5AyweqgiAwCOOr6Bx5RTAjYKoF xsyMOkV6OYIko1asqgMlZXp0nAYaxgB5VS3C9HpharUwo8Y7s8ZTW+9trBcbq8X6Kvhooad46qq8 1GUwb8pSL0vTSySaMuAyJvHRKsgKgdERvOlgQdIz+xJZs7lC3VfkvSpCmeD9cfrcxl/BPkj3Xkwk zvYTeX113RJ1OxQEjPM9Msr8lQWnC+srLZYiU3teXVNhV0e5xaKva9kSr1uRUrQzvyWz0aKtbTPU NSFPo6U7r7FGW9Wore9Jr7HsS7+0IzHnfIvlisViKKvNulJTbbEkmSyhyUUKZYW/vlmiJUZjiMUm dxiPuM67/sCrIivyMgclq9mhqalJp9PxOvJ2ayc4LnE4XtrP+Ynjr0ghyvCuxn7+/q+OKb0y89v5 Y3ncKwMuMUjAceHCheKiEp6fz/NC5x383jJube6l8wJ5h4ljR4gj/rEw/tn5Zx8UHadP0isIUmmT KGkSNOVpy5RPSU89IIrBctrRkiS2kTLWBcdzjRV6KKzKg3yjBvueHSGNGiWJIW8r6LxiQl6yP8vg PaWE0XikJPKZJUnPhZ6dJD0xVnBuDDdHwxBN20IyryosHZLG42PBDH9pxhm3uzNrNiE422sLOYH4 +KASrM0ceZet3e405G0iT2b04vRmaVrzfG1DoKoaEkOe1YL2A+UI8lmorJqvrlyorZEkVUnTaxXa Epn2slhdDmyFkgvRDdUJ5i8Ibb/0ipC00sCUAkVKoW9qkb/ysiLlsiKzEuBLqhYsZnD4hGVbz7Rg aF4kz8leRz4PVtXJpfP+BPJikhHjH7JJZtb6ZlTMV5cHqUpEqUUQ6WJtj0TfDRj1yqiB6Wx+atHi jNLA9BJ56hVJcqUsuSI4tXhhWiEEhX9yqSCtBq7OUkOjFHCfWidLqAhJvrw0tXhZypWw5CsBiSXi xBJhSqVY3cBsqrBsQL8joIHfJn1wHK7ssLuiAWAAdj3kZWNjK/JC5zU3N3V0OB93beKDi46Ghgau RODS9ss1//uLvGQuYHO4mKWF2wPbpxcKL9nnCQ3V9RjbyFNL5ysvhSrzg1IL/ZIvK5KKQH8+nytT NksTa0D8hRmlYZmlAWnFgvRKH3W9XNcEfx5JeoMotdonsdgvpXRJSuny5OKwxMLApEuAYHFGmUxV L1GTRxy6DLAeJmhO//4iL+oPIVxXV2cnBC5x2C8H2kl7e3tLS4udj/1CXoxV/DQdClWbRNuJ+a85 JJqyTxdVV1ksKfmlx5Sa7wznASQ1FsuhlJywKOOStJIt+tod6ivbU7Iu9VgaLJZIXfaujPytmisb 9aXr03NPZpcAkbPKzXtiMrYqL0TVWyLrLIuVxYq0SrjMYaQqzGr0xPxCFnZsJkEHIxJ20vh43YE3 hLA2X4YY5y2xsbERmHvo0KFjx44B0RzbJ3jBK8sZgZ8cudPrEj853otbeAZ7Yq+nIQNScNgfbs/J 78WlPQUnjpnBhZ07d+7bu1+tVldWVgJ561vbJ775z7+/ufC6Hlb4xPxw0Znh83b5nipc/F3uFNGe 0cKzwDt8hg/f44PZecqSpDVxxdKdieMEB5ATM79uothRkiiALGZvYUAeKs2EzZnpv3CEjoPjMQdl +1QvTmDNdveJGuN9IDDySuiJ3BflBx7wOD1SmEIOWtYFRwyssVcGm+2F2ku+VYq0wXLVYKl2qERL c83SBO6FRUqxNHaMJB7zvKNenLNk7U7nIS+G2WRMVtYsVDfsuti8QV/pm1YOcxncdXwM9T6aGrHy 8jfG8o3ZVX6xJdLYy6vOVywyFAaoSqQqqFo1AG6ZthFOhrKky8vU5duyKncbyjZqS77JLFiZkBMS pQ9i4AspgaZIHpt6MsJYTdAEvpBaDHxdyNsnndcMzAXLvNXVImXJ8szS7dlVoPb8hPOK1CoCX02n MKNJnFwcnJS7MS1/t75kqTLfPy5HcS5rWVrh/vyak5fr9+hKlsSfl6WUimDEABOTCxVnLy6Murgl o+D4harTuY2HjTUb0osXxeUHxhX6Kyt9AQo6mhfAwMkReTEGAFuh/f0I8nZ0deKDJkWFl/Q6TXl5 5fXxj0uBmxRzqQLZBYUiKSnp0qVLkHL2RTS9XtJf5CVXtKwGrN5CzJC3lfygmJsZ6ABLgn9GxVJ1 6VZ94R7j5a3a4g2ZRctijSEx2YrEK34p9QFxlSExlzdklhwvqDuaX7NRdzk4pUCeDLldq1DWyRPK fKMuhcXmbVGXfZfXHJln3q8rW5NwISzufEBivm9apSwTq1fojeACkBfmEbJ+9FPnraqqys/PT09P b2tr49Swy+FexLm9lxx9ULYrV65kZWUVFhY2NzdzVOiPtdmMhZDQC3wN8PZvmpdSpEg5f6qgstRi OaI0BGzYLV+3TVlc3QyE1eQvijHIoy/6xRX4n8kW7DmjbrIAoNefip//ncY3+qIgyhCWduHs5dqi NsvJBM2inccVR+OkERkbsspDlQWwM0O5gLbijbl+qC1AYUw0kKBrC1TVfrrmwDSBP/k2Y9fjtrbS 0tIzZ8688cYbv/nNb4BlRUVFvLL4qaampry8HC0WOYHIGCCh+nwACVKgSQPykAcgiAwgSEVFBRja 2toKyuB25EcKshGhenpwI26vra3Fvbg0mUx4OM+P23EXzpHfbDbjEiMc/nbchfw4kB+vQwbeferr 62Uy2UMTHp44ceLSpUuLy64UllfC2jxs+speHlZ3P+Z5zwerGPJGuM/dEl1nye20zAg9OkF4ZqhP EvyZRxDARc8+kI9hT/Jl0yTxt8NFsFdjhVEiZopHSc8CAUldlaRTYOZiwO4ILFMiddi6EJgDKzbB GOUd+aT0UEqTRVVl+XThsbFeJ9yEiTAj07ZU1vVEpPkCefEK7JUxTBGPDwQPk6UNk5AHF01Ai8+i Cgjusig3SfRolOSLPe4vzV28di9ERF+O/lqbYQETXMAazwpB4oWDpS0wvCQV1YVlXhFlVpPXvaHR U1UsStZldlkKLBbZqQzBicy4JkuWxbJaXSpLzJdpyqTGWpm2Fg6BPpHq5C4LnoAxIWLYYcraLKnF DQujjRjDk2IFPwdMC8KDWgOJ0Qz4IA3COtuL6UIIcCZGtKYAg2nOoZQXpWFbjh5nu9Yw/YmkNrNY dpPqRFf447abvpDmVuXB8lVr2eif9VPYbO+abj7X2dBtGfHyB0FnNPCTlODL3QYTvmbSV2szPJn1 3T5qk5eu1isuO9lEdC5us5zLq8HyRmlyiUTVJEgsFx5PVbeR3Mhv7tmpL5SfiDqYlVdmISsZZA5G +HkWy6LkPFnSJXHc+eAYw77MS8UdllqLpR47wmH6hgXkP55f/42qeEFGib+mhgZjTMjbzc7MiZd4 el3k7eqA5Gg3ZmctWbZ0yuSnP//np62t7a1tHejvTj24isS1pNdff/3ZZ59duHAhRul4KQrEWwGk CgQRzvuLvLy5EtSydkuTvEaaasElmrQo5UpQQl5GtwWkAxlBZ1CyAlK9oGRR7EW/iAsLwg0p1cSy mh76FT0lvb5tTVquLCZPFlcUEKE5cZHUMYjdKpaB8yLLbDl4sd437oI0o5zEezbZjsjhimZwqAfh 7ehcLFyd552vrcM8r3fY8sKSYhKjnV0Q1MDcefPmDR48WKlU8gEJpC7SIbSdypQbeDg4CFby4r3/ /vsvv/zyV199dfHixWZzK5D375Nf9z+rwXwWps5lWW1Y2PsDq4rgi05fyyWXBo3JM7XCNyn/+KVa CKhDKbpFuw4Fbdp5ocbU1GkJz7wQGp+tSC/zz6zxTSwWHUtNM1EP2hKtDY277Jte55NeKk29uDfn Mhha3ND+bWTCwmPn5kcrQ5VZvhmXPDXVWMeBGQfwgi/ioJEYrQhohc772ZoDb3v5GXMudTS3pCvT 3n333f/6r//65S9/6ebm9tRTTz333HMFBQVgUWpq6qxZs1566SVvb280TlBgzpw5zz//fEBAANAQ Kdu3b58yZcr06dNPnz6N/Bg+4fKZZ54BNwGOcXFxYrEYKSKRCM0bNA8ODp48eTIewk0cISEhb775 5ttvv3348GHcDkjlt4eHhyOz0Wj8/PPPkfLll18CkQG7X3/9NcqGWzg0r127FoX521/+ftddd/3i F78YPW7s6g2bHnz1E1ibRwsjv+/bDOQdKogYPHPD2WrLBZNlumz7gx4nxgiSxoviR3qdHis5+8XW TNQqI696ks9ON++IkZjn9Y4eIYxwE4a7iWKg/46UJgz3jhklSnbziXUTnHWXRA8WRA2RxGNWd7A4 Dot2aS0SsNXj2GNfbtfUWbQlXZ8EbBnlue9+IdTt5MGecSOhXIuiByG/IgUOXcMEUcMlkcMlEUOE EbBdjxXGjfM56+5xaIL4+IPeRx7wOuomjhwCbzFsN/3F3pFTBQudhrywGc4zNnhoy73iDfsvVQIU 0nNLQ5PyMQklV5mgzHqk5XqciTe2mostFsnReO8D8UnVrbk9ljVw84s+L80shQ+nSFcjTrsy76Qy qdlS3m2JTFXHZOXnmzqbeyzlHZYTRa1+cflyGLHhuqPDQJ3WxZCbECEvfEuY6LApvEhBBrgIzjqQ 9HrAis1HjrW2t0BEcizDKhVIifbOjo5OQjeaSaQfBtbBS0tlY9IdWGNubemCJyDbtxmDW5PFMvaN GX6nMwK09bD39hN526U6C6bFvXT1c8+p4fgBIuOrXdXtln2a3PlRasG58/OOpsVXdUC845X5VbUb k1Qro5Mh5JESYcg5kJJpqK6/ZLGExWVLzxggbcJLmtD+a7ssRZ2WqPwrJzVZMblFxsbOQkBGWdta fen8tCJ/baVMj09+k+M6GERTA7RGlcIPIe/F8xe8vDzuue/en//yF7//3W/envbml1/O8/Ty8XTy 4eXlBcEF6QGIee+99373u99BUPz5z3+ePXu2SqVCWwELOOzipP/Ii/pa50e4EYDrvESWzHoa+YRn Ks0EuLFqQ5QmP6vaVGNpL+3p/NZQLt2fuDstD3K7qtPyXaLymDIzv9uib7FsVJ4XHc/8SlWW1tQD UQ9EzqlqPJuTe0xniC8sLbDQoPfoJZN/Qi5m7bFwCcjLLEW0QSIt2fsB5IXl6rnAr4VLVgF5ITlj oqJnzJjx61//+u677x4xYgSYACrhgJTm505mS78f7+Pj4+HhAW7iBLD7q1/96mc/+9m99947z8Mr PDFt6MvvSU4p4UYiyeqAGfmH1/PS6i2Y76CBYpLdM7XSN6nou/wGdAcMStVltRiIovFfrq7dcvzM ksQL0uRioLk0tVRwKiOlhZB3a7Q+JKEUwtBbVeeReCks9YKRDZnA4pSS6iWnY/yjUoC8kvPYPaN9 nppWc8P/Tcb8XoC86B1+atJ53/Hxy84t6OnoLLxUsGTJkmHDhv3nf/4nhkCgC6pZXV2NYQZmUQF2 0Cs3bNiAhorhEAYbUqkUejFXcqEp49dly5ZlZmYiQ3Z2NqAWh8FgwO2Azq1bt0okki1btvB2vnv3 bqFQiGdCXUWb37Nnj7+/f1hYGJAaGYC8uBf5cYm+AKvCihUr0B6AsBiV4e0nT55EBtyChyP/8ePH P/3007Fjxv3Hf/wHutX0Tz4+E5+IVUX3vb14vCz6usg73CdixJyt3xVZyqDzSjc8+uW+UbOPjZ97 bKLgxEOCg8LtKc1dFu3Fkie9Nrp9+e1DXkcmeh9+aN7Ohzz3POh9dJzg9GhB+Fhh+Li5Bx+et2/C vB0TRQcmeB2eIAh39/pujCxmhOAM7eDhsf8hj+1P/3OVrtRiLG6du3CH+6z1I0THx3geetjj8CTv /eO9Dw8ShANPh847Ml5wdKzntgne2x4W7JvofXDcrG8fnL37Ca/txwoss79JeFF2aJznt+Nlp2Hx Hj5r97CXPBes2QMR0ZfjRnReeLHq6z1jc/bk10LlScopDYy5KEmvk2c0+WY2CFIvCU7HnTebizst 4sOJnkDeisZLnZYNCRcDzuZIMsswrwHTCiYWZx/XxTWSVrV05wnR1kOLw5Oj8qqA14lNFlmk0U9N yOujbkRrxDIKmYZMphx5IT0wUGSBZg/l2e18VdHz4tBNh49CW4RbDuFYZ1dsbPQ777yTlZN9Fd1w NsAOlKilrRVDAhQ6JUUZFBzyzdo1jaYGUnjZWjhYdkZN/dA/PBP+VCQQ+qfzwmLQjclcT3WdR4Q6 s6LFzPYiAt+Lm5s3nouW7D11MLsYShNSoHKWm0w7UjQrwxMqWizGwmrxmkNBR5Lkh6JWp12kgdMp zZHsciByVXtXSnGF4FjS7O/UonMGr9MZgkj1AnUpJpEDdDVyTZUMIyIb7GJiF8ZngK89cPb18rA6 fPDQ008/9Yv/+OVdd9/161/97/hxDzz11NOPPvbE404+Jk2a9OSTTz7BjnHjxgFrMD7/+c9//sgj j+zduxfyxLG9gHj9/j4vqzif3SaXZvhCYGMTXVOgsUWeWi47Y0hqs1zssczffViyJ1yy+7i2sgxS +rC+dPFJZVxRObSt7Wcig7894HcqTnw6bbW2IuCccXHchYjSZjDicnfPAWOJ+Eic16kEeYLG53SS 14mkZarSRZkV0rQykZb2KKNpZYh3ZiP6cZ33H/LlHguWXLpcBKG6fOmyhx9+GKSA2PzjH/8I8oBQ jz76KMiCEyfz5EYe/9hjj+E2lBAHhgpAXoyg/vu///vhRyZ9vX0vdtKAzotJLui8QN5AQ+N1dV7Q B5MCCHAywe5VnqnVgYmXz16sg6AD4MKkwA10jd3tZzI0oadSg+KLFJnVYmWJz3cZSa2EvNtiMkIT L/upmgUqsyC9UZBQqDhniK7uxo3oZRXQQRI0vjEGOL2wMVg7Oa6raUkRdQpa3N3qq6n9aO3+N4V+ hkuF3GqHFghoAwL+4Q9/2LhxI9RPHLxZAgF7neCSJwI6kY0PGhHzRKTYb7Hn5ECJS7uRhz/T/hZ7 Bp7Cn8nz2O/ij3V8OH7CQOjxR5+AapyRkYGC1jS3QOd1+2j1cI+T10de7Co5c0NksaXEbPnYe9HE j5dOmLnx4dlbxs5Y/cgXX3msPACtQXs+9+kvF70cuPegpjq9pONCVc85bdWXy86M+2zzw9LjK5Xt R9R1m46m6CvaVFc6t5+8OCc0fOKc3RO+PPDgl3tnrIqNL7WkFLYYSruaMP9e0vKp37op4q3zdijj SzuMVR2JhmrF2qiJomNungcm+mxdE38pqbj5QpPlHBZXrop4cs43T81ZnXSpBz00taDlXHbT4r2q d4NPjvfeP3ru1qEvzF666aCTkBdCA1OumO/zjMn9tqCpuscSp84JOpYiCTfKwnMEJ1SexxMVRyLz 6hvKui3So8lz98enVjQWdFo2xl8MPHcRs4Q+55uxZ4tHev2sE7pEs6Wk27Ji93Hhlv2rYpQpVxpg xo+tseAb1r7qStiuyaXH2I6ZFwWU32uRl0sSwJBA08SR9zX/5RsPHQHytrS2JyQmT3lm8p/+9Ie3 3nor+3zOlbKKcsxvVFSW42yAHeWVFZXVVZXlFQ119cXFpb5+AX/6y5+HDBs8PzjQ1NSARg7kHTzl rcBINZDXG9vQ9Qd5oeyItLQIyyuz3idSp61sa263VDU0aC9kt1q6L5tNh1IzoLrCdqE2ZJvNpsLq 6m0p2hURqZjJqjVbjqeXzj+UFBieGpKYJYk6vyqjLLOiDSqYsawq5Ei4ICF/rqqGlpSq6uYpKwTq OqGGvG1xAi8gWqWIldrMrZdjLpxsaROVH7Y2m0yNBw8f+vDjj4YOGeTt5VFf3whTYdMtOWArg3nk 448/Hjly5KuvvgqtAa/ligMECExzXNr0V+eFOEV9MfCAezNIQcZnbDkIH0Vs4Kaswc4M4khNvNkC ZTZ457fe246GnYzNb2qotvQcM14JO5GEURAM0RiOrgyPlB6NlZ/L8oMkP5u9Ma0gvwcW5u4zORcU p9IUyiu+umqhulSoLvNIKYRBCdKb3NHZUl+BHl7NNMmLlkP95Qd03mBN7WS/VXxVESrb2d5x+fLl iIgImDeBvFCvOImgDuMExy1hSz9eAvsqTKAoGLj2xRdfDB06FArXkSNHGpuaL5bh+7xvyE6ny+BJ aGhT5HT8sLWZeESWAXIZbfRKrQhKyD93kVSMM9rzyw4eWRlxJjwvr9rSDRT+7kI1JtlhKxClFgN5 rTpvTOqCxDw/db0vbB0ZTd7JVyQJl3zD1avPqWGdwHN0jZaliTlYEeBN+5+0YTssKNfY54oGRXhp NlYc1H+49sBrPr6aggLsvUje/gw3QXngb0JCAm+KdiTlk6o80Y6GvRCQHuHgeYVfrwuyyNPrRsdL +y3IZn+RHZ2RwjPgFp4IXkDXzs+9xPsRdtJoaOt4+PVPsaqIr+cF+Dqu56V5XsHp4TPXR5VZqrss cdrCU/qGQ/q2Y1mdhzXNx3WNxgoyWhov5P9j1sI9xlbYH4CeTR2Wxg5LZl7XZ8GHH5y9LqGORjiN bfQE/FpvssSkVHksP/e8z475+3UXO8mUh0FUTTdZ7YC8M2SrFp/K0nfSXejdUNZ1RR2T5m59WLA3 poymgZAZc+TmbktRg2Xx3sTThjqkmPCtYWZu+k7VPGd14kPCQ2PmbRv63MyFa52l80IPxfydOKPC Kzpv76VGlOFKZVXqhdLEgprEouro/PLogqr4vNLGzg4QSXg4Ye7BxOTKJui8a5JyZVEXRJpy2l5D b/JMr5p5XJnYaqkk68GF5IJLeWbYMDtKzK0ncipDE3Il6VewsFGcTVvkYVWFH2ZAHJCXSTOovSRJ oBT76RphMn1BshA6b3HpZT//wN/9/o///Z//hUEv5kdgwLz3vkEI991zL8JAO/7817+ghIPuu//P f/zT3/52z29/9wcoff/xX7/81f/7n0cnPQKJBxAc+cp0zPPC2txfnRfIi03DaB8kmCMijeqyjvpW i+py6bL9ewrboDR1N3RagOyRhry1R0+V1Nbk1tTsUOcGHk1IOF+Hb2pWN1kuVLWtPZcUGJkkjMpa Y6wx1rXn1jQcSDeERCRLUvPlOc0AFLmxi16Bdb5amiDA3h3B5zt9NWzrJObJbJP2fDvQ68/zQuXv 6urA1ADGIVqNav++vdXVtbdsWh6yAsi7efPm5ORkTHJByjmKF0gVZICIuzHkxYpaXw2t6uWjDoxJ MHtCAYuJYtSp5k70I8Oli+ri8ittPS0d7XlXyr6JVPofTwk5p4HLBNSlK12WtOL65ScwClKJjiQe 0hbCWJRV3bAmMsk/Nk+hYvtyY0MkuENgw08sNIMJVNtEG2jQ7nDNAF8I9h9HXqznhc7rs2hFUWkJ KktmI0gYkwlTipgljIyM5ELYLn7tsnfgnHAMgsL+7bffarVamGRhsgBI5JbX/u2Z16DzBjLXEei8 GJlcV+eFsZd55reKsLZdVyNILoAvYkRuFZTZw6pLYadSFN8lzdt9XFlRC5mcWGBaEZXtpyyBzis6 pVE206zB9ujkBSk5fpoyuaoSyzTkymJJ/AVRuBazRfJ9ZzBrA8atiTbAXx3LQLywUyuQFyv+dNj/ BK7vNDWAUdkH6w69IvDPKChsY67NdpqjgkAxMMIOo46tlJ87xmAN7rXnsT+nF8uQgTOXp/NLjp72 nMjgmAePcsyAWxwvcRcuoSnjlvZW647ffCcN6LzYPZKv5/0+8mKed+isTecqiJI10BHIqmMpxSAT 1oYOC5mfWi2G7NJJn68+XmrZFFU0Q/bNws2n0i82FJX1rNl+7tkvFqeVE1DuO5X4luzr0H2pJVUW XVZt0IaIGfPhhN6J5+yM0b7mETYjYOf5ekv25VaPoNVLTirhylZY3SqRzw9ctO5AYt6E2d98lVwD TiVoskJWb5wpDFq17QSgVpXbPMM7TJlbWd5lWbUtenbQoZf9Tj3qe9bdJ3LE7F2jX/dcsn6Xk3Re IK9C3yjPrPWOKdh5oR6FwaissYuGEBjRoV4I5Z0WWPkBqYKDMV6HYW1uyO22fM2RV0XWZuy0I0iv nn0yDaNEGj+0m6stnRifNLc3GfLzlh6Lx6ARY3hmW4ZbSIdE1QyDM+QJLHVYlwExDiWCGTAJfKH8 KjT1X+xPfNVvGTysMEN6ubh0y9bto0eOAvLCOeHo8WPRMXEIcTGx8bFxsQPsSExOSkhKjD4XlZSQ GB0dO3vO3N/87re//f1vZs+aqcpMRwvHPC+szVBtoPNChKLKffewAq3IRU3X7J1ZKwg3ZFxpqeuy pJRWSrbsXHEmCu0NsK69XBt2ImFZRFJRU1N+Q+PmzIuSowmrIrTnMOkI7jAnq2+z8j2PJq1Tl+bU tGaX1R7Q5C2IMwTrK7H/A8l2TSvbSqVdmt1JtojMBjhuQezb17GiGDbwZXO+TO3qZW1mU/DdMLxD VMLS3mI2kYCx93ynndjlCUgNpQkSAyeQJPyFOLcbnJGzv8hLtWY6L99PA+fQgoG8FGDMTCiSnstI M3c2W3rautvBCz7wLm8wH0nLCj2V7HvW4H9Wl1TbjoE6ulhuQ/fqc5l++88dV+XCbmmobFx2Mt4/ pTgopwvrgrGGiFYqGbBRP9YFYCtC2k+MdG2m7WK/LG7ktzGit4cVlgdinhceVvlFhVR3B9KDLJCi IAWnCWKOcfbLgXDiKPkxcOIlRIx6XKpqgLVZHp4BwQUSoTv8kLWZIS99T4S+hqCtwn6PhLx51Zht 35dyXrz1hNfO8IDDMYVdpDolFDWtxiqAtBJxaqnopC7dRHixLTYlWJkj15ZLM8rw0/qClr1XOqGD +OyO9Nx8MA/rgiG0w1PlCQVYiQk2kVUKRmYdNjTDNBzAtxUC9qN1h18VBKgKYI4iPqBqaJC8Tdpj e31xQtW0tVg7a+gGWyLnHb8FzZif2C85+5DHblW2MxR57B0EidQFHJoBT+mVwfFeOmcNCc/B5jiw NmPf5uEfrnLzPHVdazOQd8isTZEVlhL4M3x7LHjTiYBt0UFbYwM2RYVsPrs/Qg291JhT/tis9Y/M 3f3C7BWeC3fujLrw/1P3HuBVXEnasHdnw/99O7szu57xBK9tDCYH42zPeMbGBgMG2+CEMRgwSQjl G5XIOdqYnHPOCIQIklCOVzkiQAQJlHNO93+rqvvqAsLoYjT2189Rq+/p06dPV9Wp91SdlHS7pbio YcvW44PGzUgswl6E5nGu81+cvPLzRadScxpv5tXtOR/vunRzYbM5o7BimNOSv05Z8dbElbFFsHnr HLxXeu8JSKgmTXjtRtmWvaeHT/HqP2HhiSvkoCirrr9WVB+RUZCZb86vN98qNX8x2etwWBJgzn3p ife/Xf+y0/He2MoBC3RM3tnzQ/t5qza1VhILIdq6gO/dph0TgLxYG9wYU+bkf31rZjkEMutOrk9c +v6YzD1J2Tvis7dEXdsfmZ5fVYPRmIZ95x33+l4qyE83t6wOyfQ4nwFLFkMHYR/pIkodjsVE1VDD JigqJuTqNWQFvM64dWfewYte/qkeycXYz2g6PD9J9R5JDVAgQBwVeQG79byfAtQ4DQgUmxdjm9cf PAxvc119Y0FhMcYELlq0YNiwYRguC/8zAhxoleUVUCO/qKO8sgJwg1G8NVXVMTEmg9HD3mH6SZ8T aanJ0s8LV3Cfj8bC5kWPku02r0BepXNkgcuZuOhC6hyMzqvwOuinORO+PqPIVGneEnrV2SdpdkDq 5Yqqa2Vl2+OzvC+Y9H4xswMTV4emmippGM/lmvrlZyMPxN1Kz69Nz68+lHDLcDzaO6YIA9ohEm68 +YUGK5IlVLA/vBrOCmj41oDuMzWI/sf5HuRlI4tsXMteRRBYjDdrS2wfcxzUAg6LmpLcoU/uiUE8 qpWt/bzUzZqkWLswaiDV8N5QPYIfPiJfcy4+tIparUf8QzEsdnfE1YQ7tTnV5pultafiMvWnIrQX UuYEpm2KuQyfMzycMflVS/b5HgtLv91kziyrWXLygnv4VUd0NZrKvFJpkTEXrOfJO4VR+xZvYZQn KxhtNuA+qXpUJbKLOdCANxQPybyi84G88DajnxdfimES1jQBKUTBWhT7Y+bB48gOhQR2WHONmAit klv47MCR0s8LHxq11R80thnUSKQV9jAmHK1Kt9Cbs4Ov+F4tAqRmFdcm3SpOzq3MyKsuqW26Xd98 PDMX4/yNkbcwwsrtVAJ6aFBTNgVEe0Vku8I9FV0yK6ZwZ1ZlhtlsKmjwT75mup4DRmc2Nq0IjtZH XHVNLMdUBXSWoY3qlQxbm1aygrrzjKsYt+bYSOeZSVngOcGuhTZyjQ+Ub7xfRCUeZ2GW/LQ8ZclH LuSuvML6LZKt5CAp73kRHsRh/QiuEWPJ1tJYpTSySyBnV17f+OLQr5/7fPGDvM1A3q5Tt/jmmG/W mqd7//Ce04a/6Y685Xbobf2RAYZDHluDUAETM26+MWnp6OVnT5tuZebXpRSbc2vM+Xkl23YdHTRp QTA81Q3mT6fPfWHqho+/v5Rc0HSrsHr/pRTNks0Y4pJxo+zVr5e9OnXn3xw3RBaZE25UTtKvGOSw wXVdWHR2E2zqazfy9p0KeHvC7JA75Ay8kp0Xlph9KTE3MKEgKLXsgP/lj6bM2R2chm4A5wXHPrTf 8aabb1fH8100QV0m7+n9kf3yjbuUfnehxYPPj4C81JCOKXO4cG3n1WoIUuTlyyv9QhcEJM0KSp8d muV5Pnm+T9jV0vL85hb3g+fdDp4H8qa1tKwOTvPySzGEZ+vj87FQjz6sYPqRuNAKaslvPnBsY0B4 aH55fp0ZA3tOJF6ffc5kjLoBb7NrRqM9OkESG/RYnVKa7uiCgR6TtQ2570xsXswqgs277sChRrSt oL0hrS3mjIw0jNZDRyrGXPHgZmmA4Z5FmC0X1jSSBG3eekAyvFKROyWBRChxrT8oZ7QNrHJRy9VE /r3bt/P8zl0IDLpUWQ0fAJqbhDsQgK4ffOHtGzsjAfN0qAVik82LTit4IJ0j7rj4RkeXVeY2N4fm lM46HqYJzMTcrs0ZVRgg5xJyx+PSlczquuzSkt2mTHefMK+AOO2FaOfjIT+EpWVU16P5tzskYX94 RlxORXa1GT1fc05Gegdc944tNZjydXF5NIw28jZcGXByYpFndCig9Y4AZqHM0PbcakIkfJ6k+RHu QV4QEI1uIRUzSGqtFak6/lIUCL34vkMUi63IC+I7plKQsVUgAjw5jLzkq3ENz3c7mxheS91Ji3cf m+8TMfNExJZLaXG3qipqG03Zt4zHL+kC0t38Ujx94/bHpSLZnRbzuiPn911KvFFnvlXVeMSU5no2 RhdzB4N1dVF5GLuLPNHKcorFsidlgryYvqT4nMGLByMvZhWJt/lGbg59LAmmYm3JheWMC4uaxfXD DpL5H01zz937f94T86OZWZVNGgn4DIzYf+79kehsxThkuIBobHNiKXYJVPcqor3SlBUDaNFa2r8P TVwgL6Z9zQ65dvJ6mUx7hDVRWEdeoJuVjYFXc5eFJM0Iy8ImCEYMcjiTcqmOeuTXhKR7Rt1BDzuQ 1zuyYLUpN7GJEDmnjizimy3mAxlXZgabdPE5jljcIJVejWUksS4KTd+AWy8ROyaUfbP68Egnr2S0 togJyiFQaN3ykRg5W4QWrLFwx9rUVbMhnsojFNNyV/PS8qAlsaQEklNaFVsVwtJ76JBbUgDrYki8 kgP8JC3N5bW1rw0f2+nLBb01GA/sjym36Nv97chV2Kvoua++o35eF9/uU7eczTHfqDZ/o1/1uv2O flo/TCDC1KEezkdcdsRUNJmxeeLbUxZsxDKdNeZzQTHbToT6hqcV5BVu2rpvwPg5kYVmxH/mtqSP y74PVwTF5dXmllXtOGdyWripshGWXe0gu/Wvfruh/9g5CRXm5JwqhxlrhzhuGzfv7LxN5/yCsD6Y Oft2ycdOy33TG0rqzRExaWt3nXJfstVr2S7jsn1rj5kGTpq7Jzwb3kL3lT4fTPj+L9N2v+p2GhsF dp+yq/eHdgtXb+kg5IXSwJRel+h8R3/q5wXyBiSnzfdP0IZccwu/hfmDjv4ZmpPB6ZVVueYW7eGL TvsvhBSUXzGbV15I0B0L1/kn6MIyXC+luwVcnnIi/nyV+TYG+x064br79Kqoy6biOnRpXS6v//70 pdlByUbTbU0ajb2HJ9OY3CB7b5G+Ik1ORgTaANKTJSOsPnRfLCOsIAosDeA81Vn52RqDCTvqnB02 YljFSCJKjj/oV0Ae7RVLT1kfEqXcQBpKRo9Yx/M17HcEuOLpLpiBQNvOolVQ18Q54xFOiLdYFaC1 tPwgPU5uEPTzAnnhbWbMsg15QSuoEY2pwMk3Iry0MNdcH1lQOeNkOFYycYsuQBcVHBEukbdnhV9J Kau8VV5+IDJ50cmgXbGX550OwUSMbzcfD7hJK+P5xGftuGQ6m3EHo+AuFzfuCUyY72vy8k/3CMrU B2YYA67MNxXPiCiYYaqg+TJs6GHiKtpI1LlJhhUA6CHIC1oppBW63U9/hRcW4tx/0coKJa2FNZyn mr81U224fiTkrZyeVjmdwJeczBjVzJJMGxI5ReTr/ZLDqs03WsxL9p8yHj2nOXzR60DgxfSCiobm zDt5C09dWBZ7zc031fFIhGbbway6Jgxc3Hzy4lb/2NRyc1mdOSO/ctFZk+fFNMwhMgSkzAy/ZgzM mImFyLAEJWYHxJXJHhbkc8b4LnY7PMjmbXPdZhtIY0naSnBEgaGQcK4j+IVbcrSyARxUaxDdovSt aYhl+MkxSn1Rbrb7HzJsvpyX32nACO/T8TOwwh4WeKEdM0veWbiJkfe6O2/+wt4kGr6oxYZ93LeF XYTgRp4RcXPb5QosShBabg4pMoeVmEOKzYculy0KSjcEpHvF3J6ZWA6A1gZmHyg1+1SZF0XnwnsA m9oQU6ALuTEvJmfvrYbgGjP8e+HFLecLm9wDU90irrvFw39FG4FBoUEq0Dqi+d3okU+pQbt67NqD vJJGdrs/896EKqWlgrTetTCHE0BxMfFxn3/LXXCBGWFhF3HhbnuhNcN2XKEhq6yoUF5d9frw0Z1H zemjOdZXe6G3NhDrQP73iNX/8pZLp1ErMNoKM3O7TFx//o75Rq15rPYHzPFBsq5uF3mdST+H7XHo LEu7mjvIbl5EHg2sWrpyk8uM9VsPBpUUle/be/TzaUviCqid87Hzov4Ouz9bFpCcX3u1sGT3xYSJ szeklFKX8ZyNPmMNq8Z5/pBRbk6+VeY2d43bKr+F++Inu3+/avPe+oYmDKYa7bF948WcvAZzYEz6 ys1HJrjMdZuxQjNv/cZTiR/YLd0enguv0LYT4U4z1jktPfLl7BP9px/qN3FLj/e/XbZ2Z8chrz6t BjLpevHKnssVaMUFZF6fE5KlMxVj9w2M63CNyNWfi02pqYN+1h0LdjoYFHSn7EqDeVdE5jLfqMUX o5aHJSwPTVwWnvHt7gtBDWYkW3nyrNEvDipoU2R2Co9S8M/MmeMXOycuD3NhnNOw5yBmtVdjxA5U FgQV5gOMKTjxoExEpTwS8pLIqGqBBQ/yReKHf8BTOB7IdmZ5bEu46IaSjDSDJLWcVX3B4qoiL+cs yCvpGXM7GnlrMYTSOa4KS504n4mIrii/bW6KKKrG6B2gpBHbz8UVuSQW2Yfnwl9xubrpRln1wejM df5xV5vNB02Zc31CF/hGBGaXoC/gqClj8YmLG6OzsOYGeuezy5vRxbAyIHa5f+ziC3HrIrPPFJoP 55lXZzZgNXgSBm4gQdEBeWVkkTicodYeZPNa1Xeq+8ygtojPmoETSDLrM5GWmjnynIUj9JuSSUSb mbYnEnrKJm8zy2olmhyMvBDXSiyLzWJMA1mdIu/ozybG1JhzGs1bzwQuPXNx2YUIjDBMrzDn1TaY blzfFBYTWm9eEZI1zydq5YnzAOjsJgwsiZh9MvhA8u3rlcSI+BLzprC0ZReill2MXuwXvsV0LbTR fCjPPDPmDsYR4Y1UTWTLBnAERvcDvM2PE3lBaYUBCvJSRbDwgggtLBOSs/Lnu1IjFEZQDkjGjVvl LnHWxoMKcKWgEMjr5RPnGYsecGyIiZ2Oi95ZuOENj+/Qa2aFvHDIYEcYbN1Fo9GMKdUAaICvNiDL eD7V7WSs29EIt2PRet8ktDMxk1cfjeXoSxA8kqpcQnIdAm84XboOFEYnsjGuyAurtsbmuYZeh5UB r4UWb/eJM/ql6CLyadVQuJoxv4x8/uz5x/ZhvFgfI28hVo8cQWtYZdv4sa3JiXh0WNOZfjMh1Qoi Nogk5bPcVZ7ipg49Q5moAM2/bTkR/a2Qt+b14V8//9Wc3poTvbWweS/11QT+duTaf3nLCchLS0K5 +XWdtt3ntjmzxjzGa+crzodgF7+ADQ70wVgucur2FHSWhSffGuq43D/bnFdnDo3P9U8qv1KGwULm 5Ky8BVsDw3LNmXXmYdp1/ex3j1x8Kb7QfKXCvM3/8geO3y84mhBXSSvVZJSYk0tpqFvcrbqpMzf8 cOZqWpP5chWt0VHeaL5ebh7qsgV4GnStCSCe22jOKjdnFtG8MHQNv++4XrczOqWZ1iO6VmbOrDKv OH31b9qTL03e2m+o3dJ1HeVths2LZduNMGoCbuzOrMa47vNZBXNDbmDBQPTGamPKjWGF3udS48qa sprNmmORDgeDgwvLUX50S6EJgRZLCVbsqWtKK6/T7zwWUtF0jczhS56hV6f7XZl5/tr+hJLcFvO1 RvN3YVc1/pcxCIG6yRJopjnpEBpkVY11gLHnDja8o9FWvJ+aDchLAqZIIy5hk3IbWzojRFvgLmAX 4+NwblUgci2SqSh2ai42cKMRF3JfEezWH/wueYreTEerJhGRZm2jVgn1P2kqtZw/zeat1aWaXU01 WFtbg/m8ZXWYZx1d2DLvdJJ3eKE7NrDAco5p1TC+5obdzKo2pxfUbQi/uvhi4lVeWCyrphmgAMc3 zpuC42b6Rrj5xGzPLE2roREm6HbECPbrFTV5jeRJgyRjJY1V8TnukTd0tGszLVMs3gllWo3S5/jT kVco2fZZqK3cs5CeqG8hKS4e8QCnbUJegjk2+WUVKWha6haHeqclJcu0plzvc7Expc0YRl5a1VDU SB2+oCRCZO6tEylJ6yNirqHuoEYUVRfU1YPg0RUty8IyHX2TZ4bd2p9emMWUx7isnJq6nJoGiAqw GE5pv1s1CyOve5vyaCYCrCoakUjbu2OIhTR7WOdD7bf28z5O5G2lNtUIrmWgOTVQ4c2jm1J3lOrF fEEs3UJ9ZO7wT6kglpYtZ/UIjGuG1fPse596nInHatiYxQPT0jO+8L0F697wXOEUcAV7RYEO6P/l tiINLKG9WpKpxwTD0gCRGuzqghU7I3IxjNkj/KYhDM69fIyDgsWKkVGoQYBpQ3I1mx4lNMkOO1kn VTnHw9vPm2zGFmoj73jArRR1e2ZMvjsNjaA53ew/lJ4XQnyMV0FfPOYRi837yMirUE6hE9PWimZy F2c+mClyyVHqs9YcIaYQI9QEyqPt/UcKtpFtXqjNsurG14ZNfParpVj6SdZyxAKP//UpeZsZecm8 7ep4ZOtls2+u+eOZx/o4HcfyUM/rQjsbI7Al7mdrE+OqzD5JpW9NWzP/9M3oYnN8mTm8xByaZ86q MUfnNHruCj96xRxQYn7PfX8f15MjVyUeSTefTG+ZeSjrNbstf3M7NPPErehyM9aFi60xo8Xrk9Y0 Zu5Ru03xR2+Y4+ooNwzQWuOb9fLU7S/a7XLZFHEkqTa20hxRYk6sMgfkmueduv7KtC2vOG3fk2lO qDInVpgDb5u1e9NecT3effyGbkMmz1uzTQGDh9EH1LB1hJVXap0uslgbeGvndXMyRoZkV8wOz8Oa LajXtBVgSIG3/9XIenO82Ww8n67xSzpdXBPf2ALzHG0GqJTSZhr2nFVr9jxwNrCKki0MjsYMRE1M pcelgnkXrp3Pacoym89Um92Cs6EfsGkv7ZVG2oPOqBFAXsAu952h14z6DW1EXiKKyNhdyCuxJGYq 8qqCCMGTS/UpajSyNCqO67vvsqDiRAhN1+AFe55FePkuPY4Ddzra5q2Grx6LwWIpEreLmecKGlOb zP6FZu+z6V5RpfAYYG0r9Dxi5POc2EJ40sILzGuTSnVnk/ZfKbhiNmdjVD9GYzab90Snz7sYPyfq hiEi194nAVukXbxRfrmJ0BZsBV5cbTAH3anaEHNlYdQVL9MtrBEqyIuWEqBHvBNif4n9S1xLKJoX lPbHd4fHX7lJo6pARJXORFsKQjH8t+EQXigPWDNGydOa/jZkK0nBMJuQF58pqKesZMUGDoSWRg9i nfOYHIyOCCtjwEWLFK1TjPFoMF/KLVkREOZ1+sLsi+HnCurQcC1spHZOeGHlgoBEXeAV54h8h9Db 6JpfdikpprAGTyFg5hHq1+Vy86UbVRujsudEXHfHFmAJ2F4ZFYeGRiBYHA7/GOQV8lM9APmAtoK8 FAtCoglqxV9OyifiO93guqNIQutdumnj0Yx+3qffG2k8m6A3lcPmBTLOjC96f/66Nz2WOcGeTSSX rwwzRkMRPiK3lGaX1EbHpDoHeAlSavRpte7ptIU9TGCPpDLPZOAsjV6DLnLBCpBpdcBoEBljCwHE 8FrDZNak1NOGL2n1zqlYeR75V3omV3vFl2NCMWoBEZ8xHU9xIBP7fuRNyELls/lgUlmeulfa5S7O fNBdJT3/U66lprTGqP4Ka35Z3vCwCwC3YvNiR4kq8yvDpmCJ5hd0F7C7HwIj73f/8pYDkJd2CdRc wpTeztP2veS8/0WnA32wgYIuCBvyPotdd7HBkMa35zffvTVt3UvTd/ay2/aGy66/uu7qP21j/ymr huq3vO+6vv/k1X2mbcGt3i5HaIKS48n+Dvv7221/yfFAf6djvR1P9Jp+qPfETf0mruk+/vtu41b1 nbD2VYc93ez2d5u6p/fEDYP0e/86ZW3/iev7uZzs7erT32Hvy3abX52+8QPvA39x2tB/6to+drt7 Tjvc2+VYt8nb39Ptf9d5+xuOO/rY7+rpeKrX1F3dPpy+YOMeqPr2HKgUNiEvZMYxstiIrUJjSqYF ZjkHJrkFp7vHlmHLOV1Kk2MsTWRwDbnh5GfSBabA9+IccnPqBdNkn2D7E+HTDoQ67Al23huqPxqJ 9Zw1/lennE5y9Y/XRGQ6xBVjxRhDdKk24CrWFnDzi3W8lOEYfXs6tijNwPZ2VRgEqIKvLMcHByb5 7kSZ24C8UqetHJIQDMZfvkGVHn+qGxmXqvg1kfMZ6oJi0G5nZULNOQEI/ETgQzpEIGsceGAXeAEs R1JkRulV+eY4vIuE3xIpN5V2JhXmJ/XzokbrsW5SQrmDqWxa2G23oCsOZxJcz132iCjEXjZQy7o0 2g0W+Ds9LAdrv3tcyHLyv+kcesfeP93uTIzTmRiMy3I+FYGeXEw+paFxcTWa6DJN0HVnv+RpJ8Jd fCN1ZyLcToVqfKKMF5KwqjNtVBdfQNtnUK8ibF7SLWCWBL7uWJuXaGw5VGoy6UFMS+AUrYywPPCQ CzDRduRVwFcdkE9mJgwrLGFEWjr4ptOpeMcDwVhn1e5gyLd7gtxOJOp807AtkTbsqj4i2/l8isuh SMPRWINPPNqxMLhgEwE7wFb74By34OuuPglOR8O1Z0wa3xjX01FY0kHvn2YIycaej1jYBPadGN2g vLi+VY6Iq7MDbF4rEkKMQWOuLK1VCTEs7cQL5ZYSY6kEUlUogeRguUHP2n5gPi8h77lE6l7Botnx 5bMSit9fsPZNz6VOAZm8i4SCvGggaeIBzbL5eBOMX7AJ+IvtNbGRHw1aw6BlXp/ECbNxE6nbC7AL dMaoQnATwxv0aViWqh7w7ZRQC+zG4wjo04c9i/Yn7Gu2ICphSrOxXM39yyryYlIY27xj1h6Ezfs4 kLeVWG0Ku0SqHCEyK3pMSa0ySPmJBGCKzQcUJp7Euayq+eXhk54evZyRl3YlwDir/x753b++5fDc 6GW9DeexBxDWVe7i6veC85lurmd7GgJ6uocBeZ83Rj+nC+uqDXjdeK73tP29XE719/B/wel4L+3Z PpqzvZ1PAVj7ORzq7+bTy+U0nsXGvl30QT09grGZQi+3kz1dT2FbwF4eAYBjQGpX+0N9XI+/pPd9 UYP1JP26arE/74X+ujMvOR991eUkVqHE0s3dPUK6Op3tq0Hw6e5wAFDe0/FEb9cA7GqEHRyw29GL zkh/so/TyT6u5/obw3rZHXp+sMPMNbs6Dnl50f5qcowkljtiZYy4O1iB3DWhzimhXpPahAqONeto ALPpDrY0gn5wSy6aHn3TOSJXG1GoDS01hJUZIkv0USVu0VgzDXvl5GuSCpzSqpzTayHVXqllumgs 45/jhoV/M2vsEkpg20KwMdOckZecZqLBAPHoL8N4FbhubEJeiFZrfSeJIORFILFDINGCfuWAS/KA UXpGXviWVeXN4ItEkpXiQ6OnMHOfNAY19KiRT4Iq2XFKvqW8yHKnY5EXrWtdajVm6ENLwAMGpU3z bdFpnlKDVUCxl7pjUiFMMKzYA0sKjSjqE4TGiCu1j8nTmPLQI+YWjQvaItCQ1uRkAn/roD1co4uw 85RjBHEWC/VoIvPBBbjgDLw1EiZlAPRFyUMkJLA3j1S9/Owgm1flEFGe+GUJ9JvpT2c+WhmhRDz0 H1hpE/Lik7nJQT3d6oB8usDoWbeUFpcEmgekiSnWRRa4hediG0dItT6yQhdRTiufYN1ydAWaUGWK 3MMwzrYUi7mhxYslsJwTioECsMWwqzI8qDRGOrbQKeYOAtqrDpF30EcpAGGBXZQEbSGMLScvBJWq 45BXJa817VUuKCTnf1z1iD90KDHqT4m52yLjdI9yupxX+Oz7nxl849EhC0BEawRrnKo2LyEvvBBQ MjQmIaHePbERdgSmqEOnYYggtZEwqiQNA0vEw0abcoKAsGoxewtASUKeUoXJQSC4Jq4SjEP1Yd81 PQvb2S29GctlEPhiNmUSBYgEagcCYPdnQl6qCCA5azamOdcMRRMqxCe9JfqNUhBXqSH0KAzAQ8xf Qt6PJv7vV0uxDQE2mseefS9qz//+k5X/+sY0IG8P48XnDCHYihehm0cU7cyr8ceOvdgP9xlNCLYK wuSdnprAvvogTKF9QecPmMaG9Z3dLvXQh3XXBvU1hOAu9t7trA/r6hndSRvSSRsEH3UXfUAP98AX jP7Pas539wrtaQzqiU0TtBcwaqunIZy2INSHISU2R3jRGNTD6XxvY9hz+uBn9aE9PKJfcAvq4oYN EQIQsClhT31MN62pG+3SG9HLLaivLhhd1V3dAnu4Br/w7a4uQ50WbTrYQcgLaXGMKwcOUgMvDaJV QftbpTVAnh2S6yBmkGpAIbwxaNTBzQIRRccWxufr48vdk7BvDm0IC/FGf5PGBLWD5iWWli2enlTq gH0qU4qdUwo9Mqp0yeVOWCkRXVTpaFKWo15gfiirC8Vpxh482Lw8L/KRkJclgaRNAJElCpLG+KsK JEkZLFeGTj6RfUoPsrziBEsWgUjNcqVGiHDyw4S6lruI4VfcFUPyj6DmoPxX4JtK8BNtXtKx4Jp9 QiUW7XRMpka1xXuPxj9czQS76dVuGdgNvBJtIbe4Mupeh98ssdw9sRTDnmkYCcZews9volvgL1Zp oJTY8Bcbeae26BOa9HEN2HNQb6rGAlZgNDKhZBzAOAT48WRc3CMhr5AUxGjPQRrDwsr7HmC+KES/ 7+bDIpCvTcgLmKMeQx4QCAogKFCIEbYJDQhYwB9eSlLmMKlgxsbQaGQPzP3BYnGXG+DzgbPCI6nF EF3vFWfWRNeB/trUMrfUIreUfCyyhG5csAaL82O4DmbhYS9IQ2qlR0YNZliLYgcKEOizzwExBDHM jo5EXiIiBFhobC3bcoPF3SLnTPG72EG8pqeUM/OLf/LJJkmQTMjbjHl5xpNRXvGVjlg2KpnGDw9Y sAn9vA6BWdbIi2anu6kKgzkhxmQXwDuBldkSiGioEbAjDKnV6MMlkMU4ZBqLVe4aV+aeXuuZUmuE 3ourwDq3uKZlTFIaALVkGsdXwaGHKgDMRSUS8JWmqaVdBNYgHukfp80rRFTpaEVjMQoIVaWqkLbB j2b8RNcYqzh6Fu47BOYF/hHh7+EFkffhB55lhYmM0M/7yvAJz45e0EN7Gvvx9dZces3t7J8/Xvzv b9g999WK7saAZ40RzzgHdnePIg+zNqSXZ0g3QyA2G+rpGUU72mP7Py020g3vpg3p5h76vHvE03pC ZGwLCLTtogt7QRPa0zPmGU3wczrGTX04HNqdDEHdPCJ6ekc/o8VOgqHPa4J6e0aQW1sX8rwmtIt7 TCePqM4ekWgG9NKHY8ciWOIveEU/7wkrG53LUV2NIT29wp5xvYimQnd9dGdXvCWsmzEScI9M0FsN RKbGALzNQ+3mrd0OkrbnAEls8jZjJABm+lD7kIcZW5qFMKnQqQElA4GE1EmrD808bIMFI8s9FfEV JIdx8MM001jlpAaNqR4b2CEerXddOjUpCXxTK+C9Abgb0hsgnJBqOnMjk6WUtn2hpikrExQGATrE VpuXxEpsUm7FsdMYqKqqa/5NBGSxwwVZxOSCvhd5LW5kSokM1XFZ/BziEMN5KgKLxwHU+EE5q2mU C/WfJV6eocQ/ZYQV6jvog0oNRhAEwPGVVI8GOUwt9nqxPyG1Znoiloiv4amONMeBvNBJNdDn7slQ +2XYwhs8hfZGc4tuJWJhPSwEVENWMxr58fXOJuTZpEts4mE8NBwOWku8ang7yoAA0KF+sQfvVURf rqprphJ9O8XRwUSTyx8/E1lBc+am+vDdTzBhKdnd0e37haxtQl62NJUPF+RFjGAfMNfJVAmt7pZa 65xa5ZBS4Yj2ahrtAklES6mChxOmliYTnTg1hkSzIa5Fb6IlwlwSS1xSi5yT8g2ptIwJ9D/1KuKc TP2JaE0xLpBdpqI818pE4ixQQ9iBlBw6yNtMxpGAr0WgFXqTI4j0OSjJMcxZtTowo3GHbkE1qQms WqftlwSVoSjG9cLifkO+8DwUhK1vMc5fm16vjSt8ZyHN53UIuIamC9o8JP88UREbrsGTxq16qjji RgbRALtEXl40RqgHYiIgHs46OPbJuOBZY1hehvqOSQ3S42oO1ACGKgMHmQX8MwGGdi1+gnfQmY8L efnTWc6FCKBjK4URBWyFImoAhaHBALWkqfDjAchLeSAzYgb+gTvMMopt34EH+Q14jpD3o3HPj5qH sc20dKQ28HU3nz9/vEiQt4d70LPGqO7u0d104cBTmLqddQGwbXu6h3TRYEvckB76iBc0ET3cTV3c QjrrQzp7hHcyhiMZdubFECygbRd9xLNuQT28AMRByKSrNgy3YP8+4xLUWRfZzT2azGH3yOdcOTdD ZFdjDHqQn0OMLhTpexoiu+sjKRN96NOaoG5ecXgKL3oOWwd6RgC1u2rDexmjgLZwZQORO2kDu7rD cr/Uw/V8v6nb+wyzm792K4lvO45HQF5YSWg5o4MVc2mNcY26eOw3Ct2i6hNakxYdW7I2vqJyWf9Q N5PMUoekQfwM8ViHCsnIEUcaO6ERd5UEiY2IF3+yVAGkp7ew84fOpMOrYaxhGA/k2QbkZSEkkKQh PRA6iBxWb8CKhTXmFnImN5D4kRjijLTora3H6iz4hY0LWjAElWUY8ipeaJJB3GpQll1qplUA8VQN BvMx8ZsasS9BA4mq4DIloCYlmpvyCiAEl8jyT/lJdUEJPx15idrAQQ5Eal7JEB4D4g7MMYxYAzFx TTSntYUVnUzpE+E6g3sTMVDRMj4HGgMqvREB2SIxhIG7dOVMXFYhhubwCsrQI+xe48xJ1SDY4m0m Qt9/gKjUhXTXgSjwEevdNvIqTERPMNEqFRNWIfpdT7bnB6TCJuTFZ7J/hsaYIeAnyIUaRI3G5DIE V3SI8zhnnGV/Oog0EggXpOKIyczVhCoLdDU1olLAOzKopcqg+oCzXKeEiUoyrinECKpxPC5CiC/5 S27gF1j82MY2kywrPThEdvyB5Nw7U1tfZ26qwSJz0gZtJIcTFuukuoQrStxUT+xTKyCo3VCPhWQo Ha4pI9Qmyq69B5ek8U552Sg73TdzNs4Ou42VXtDUcUso+fvCbW96rZ3unw2PvSO8ZxnUFsVdyLw2 CR4DUixCK/VMWMnxzD5OwNxUvNAgKRpCliAUxiNqGmIrs57EQIkXNwj/pGHnibXOSWSPj1lDs4oe uZ+XqcNyLnRiaSc+gBzEi0Yzr1dKio8Ii+gGYgDpOqyPiisc9DhW4sVTtCoR3+UY6D78bv+BxKQh se4knqusMb8+/NtnP5vVV3cKm91jU92XNaee+mThv75l/9zXP/TQhzwPd64ugqxaPWzP0BcM2NSe dtSFgdxdF0rxtDF9FJmldPcSNr6XMy4oGOgRmMnd9XA7S3qkjMCO9uqm9hHs5Q7uoaW7wOXnjaEI eBA/Le/FTw7UE00v0lvShPbQBXfX+3cz+ON1z3OAN7uf7mLfyVt6Dv520dptLKgPpw8oaqvNK5oB VRXI62FqNMRDCUMVKOIHiSKFzHoAFyRgirFDHUwATfzkNDTNUGAX1Z8gGPkkNLkkYem2FlyQGkng ObzU/qQ8KR9BXoZdvJE7rah22Iq8XMmhjpvNWAKf6nLllSsJs2Z6fvzJZ+MnOZoSLxcUFf6wZtWA gUPddF43b9+ZMdPdwW6MXmPv6KRZ8d3m3LxykkYcLQ0bVi4Iu3imur6hGmPnW+pCA899t35T6rVc 7AgMNRIfE7lhzera6gZs+95UX3Dp/BGDk7PdRHtv7/kRsUniqQYLSOdw7bD8f1zIyyqXkBT84hYR IICW7udr0gDQ6jz3h64FI8AdYhCvEkYTHwAQ0AzsagALGGer0U1JPZXUXCddxPBBrSDpRoS2p5RK IPDFU5QnOyhYKuh1Px15iQV8YOUcdfEc4kJdZXFKgmnJkiX1DS313JxXiMz6hLX4XWCsZvPw/4+E vNTIIYLDYrIgbzLUO/YvBvIS3aT64CfHUFVS9TZRT12BRDZeJEsWxAfgKqN3eM0lVB9pylpas1Rf 2MnAwE35WNAfxZD8Oxh5VcFmva2woLZwzdI5l0JNOSV1DU2NObeyt23cmhSP+ZRmMAvOzpwrmVVV WKnIXMutU9LzLU24BuVpSTeghi2aHzk2mBvK6muOnrnU7Z0vZpxOmpNQijnsHiml7yzY9ophlXPA Lc+0Zhi8jhg9hS715CoIPFpBrOXIyQwyspyTxErVwFkBU2XQmvQmEIUtCZi88oi0tfAIMdqCvGoO VE0kZziiHWIw3LEBc4HHrT88wtkD83nva1g+XERJmdABDWWBSJJ2ae3TXTRvqosXzfZMzLh2p6qh vqWusak2PjZ1zaotqETs8KMHsX0JkZwrCqiOh3BY7tKPdh2SIWolsmiuqm35eJKh00jPHs4HgY/o w+2v9/vdyKVPvOnw9Jff93AL6KqHwUvIi+5aMi0ZAe9GXkCnhFDkAAR8AfkYVPxl5AXs8qLQwa3g C7AmyI6AYavMZiLkJZhmvAa+IzFeKlhPPykw5pIBTl5rclwjQQ/dpe6GCy8YLzzvHtjJPRihiz6w jy6g7+StPQZPXrR2R0ciL6YiQoQIDaWa41qECnIF3Us2FAYQkk/YUsFJ8Ciomod/kgCLzoFSEr0E XeGURPgLaaf81dHLrCLE1UyCKjmznNO1DchLFZnEgNt+0MFoRdeZm0s3rl7gpHGe6qTVGOYeO+aX mpY48tPhTq76qdO1aelZy5YuWDTb1X7K10OGjxpv53mrqBGgSQ82lTiNGjp22IC0rGuYAAzY1bs6 Dv1ynG9IDF7RVF64dPasd/7y99w7laRY6nLWfec9adSouZ4LnJ287F28yupbIM6KRuog5AWblJmD 1IYXbaxqEkJD0F8NbECB/uxJAMHR+FEYRBhKBi/Yh1molAAtKIAvRzIvFCVDOoQeVAJxjXSXonzw OmuN9BOR16KUSF3QD1E1hLw3s1LXr/4BG8mmZlxFwx51AfulsEZS05AYkOLgU7s0iCRCVjbZvJZv ByUpCDVYRSvtEJrpgzYnWpstQE/QHG0eZpA0aYg7hLypaAIBqRHIHEYyJTFXE7AAqIqzUJuauOzE IHbwG/GTDWTxSFAkMwLsIFiBVKD2PT6bl0wrSHWrYOMKjVwwormuLCdl6Duvec5cEpWA7QBakhJN 346dEHgxhBiIVWbKSnZtWFdUmF/bSHofAZzFEoggew2Zxlx5idHtPQjLzY2V9bVYgHfIV9PGLNg6 J+TqzPgC9+ibAxdsfstjjYv/Lew0QQNXUqsxJ1eLzi+4/WmxNaoOoAwLOWke8EXIJSRlVpKic0pG E4haQWQX0CMCwVQRlCBMV3WdwhQxVSQNt3UFeeEJx/bWWElDWcMKtLTxUB4gWtHD/JPEHkyoqmvk qMaWsjsjBr/rczEEy+Zj7GhJcf7F85HDBn/ZXF/X0FCB/cI4GSFvPSqO5AJSkt5EpA0HHmUxgJpt Qnmw6adm/g9/HjL9FcNR+Jbh++1jCPyvT1f/01tuz4xe+6L2Yi8DvL6EjwRw+kvo7e1kJDcvgyBb rwy7cAgjhgxbPWAXECm3CB8RD7O0lxaWKRvLZPkq5jNjLkXiQsVZQLYAdzCDssWOtgJfRu0u+ii8 tLs2AsYyEL+L0b+T+6Vn3UOfdQ+HO7q3LqjPpN3dBk9fsHZvxyEvlADpXlRtslWhY6FXIa7iN4PQ 0koXopNJ09Li8ISqnIbBlyBYSQwhR4DRJGkYCMgjTQ40MY3lFmkViLFoJEVp0COK1Wwj8gIxeeQA CSVEsrHeXF809rOBs+fPOx8SHW26dvKk/9nTx994o29W9s3DJ3xv5OalpyVdT4mc56n9fKzdNI9l 6HilBiBcKFV3xgx8tcuT/7Zw6bLIhGRPjctLfXu98PJfT4dEmxuqym9dHvDaa1079zx2JqyktqW8 8trKJdrv5i24jH0lNh/947N9bpdVwCvaqqC4krSKORWOlMxP6eeFHgBVxUXGMEq6V1o7HN8KBxxP +hnMRUpGT2gS1tjkqWC1g0Y+s4w0jIq8SAmDTtQ+q3RCAbHyJFJy5pJQMoFjpPyJyCv1H5oZ/kph JJxmLWBuXUXwhTMTx33Tt++Lq9ZsxD0JCp2Z5Zzeopds0CTI6pGQVySfWj4ciCnSCIF3SBvfoo03 IxjimrgpK6Qm1iAZ6CZMEeRlVoLCcCxTjwzT09K4Ipimpq+ySifVO/ACpFb4yCawyggpQEcgL1Ws u0bJgvQIRPmagDP7Xu7Z6f0PPtmx7xTgNTY2esj7Q/ds35d9BWtVV8PunW3QY8vQ4tKSm3cKLmff LCuvRm4gO2WAqwalCdVOnuGJmias12qurWn8bu3ONz6fbLf+sPs507yIy4Nmrnrb/XvXi9cNmPCO nQswkpznajENCXYZRglzqWOFW0QK8loglRaiEecDnVXkJRYz5jJeq4lBdgm4xfWC+WuFvBghQyOi afXIwq9X7/tc401rWOEDbDyUJ9pCXpCR7jbXNxfdfL13130nzuVUNNY1VlVVlpw5Fdaty5tVZaUl hTdzcnKyr9+sqi67du1Kbk5RWRmt5odnUWFsLQ7SA6rxLOk5eK9bmnyCo55+d0yPCd9hci5mCWEO 729G/PDEX3WdvlnXH8truFxgGAXyEqp2MkQ9a4xhPGWrUx8B+KPACEsuaP0lQC0BMbmgFYwGqvbQ oqeYDGHALluyhLCMubggVLXgLCOvYt5SVuy1xgUFxfLFGwl2EdgeF3Rmg9eoIG9PfUivyXu6DXGa 39HIi3Xv2bSBw9lAs9sIeaGToStY6qj3lqs86XzRMKITgLlw5lh6UgDHuKsAKCwsdiZzH2I9twwp Z36chjSTMFvhiCUe1cEmm7elGbBJ4/rI7IVMoEFdWzjLw8He3u771VtiTdklJQ2X/P3efL3X7t07 r1y/UdnchJ2OsFPpxC+/tjfOxZ4j6HkiCUSXcH3NpwPf+OqTd19+pd+oUaNGfDDwlRf7vTHoY7+w mOaqwsBje17q3k2vnfnFRP31kvqK+jtrVs/0ctUFn43csc2n36vv3cjHAgnUFqXc8Ef/lP/UwFTC T0be1totfYsl7EAmDrJWEd3SSnAQGSQ1xhETwTVW49SUAihIJO4yO6TjQECW1LjauCIWi+MU7INI CPKywFDvP7JlPj425BVCURc9uRAaGqtKls2f+e7bf12yeMXf3huSWwQXlxmWr0LnfyzyMjEJAVlc ceaOWhZjqgsk3rW6+CaMnmLYRRtGnD/cIiK3EqVnFACAUl0g4CYggFOoEfHAWfbwt2I0NX15gwao d27/SIaEv1Zvx7UU6fEjrwgy7FdWuqoUo7I1lTU3FNpN+HLuDI93/v6+0X3GtZu5iUlpHw4e8eXI r1YsWrJ93fr6sspta9fl5+acPXtm8fIVRu9ZaPrWcX8BOSnUrKmetO/AE+zhgsFFTy/dvLv/x6M/ 8Vo8dd2et+wM7xiWYlUBrLxHw5gxFEp1GlDjRK0dCuaqyMs0VCjJDgoa8IAgDVHSfvwsJeNHKI0w XaohXwvyctOX+CJtYIxZdU+jlS0944vGYT6vs3t8xlUqtI2H8gR79nBNP4HC5uaaBmqh0gGPXXX+ 317ptc/nInb5AacqywpPHQnt+vxfUhOTNC5Tlyye7+3tvX3vztnzF8z1Xrh319HqBjJXAMAWR5Pk 9NAz3k4qlssBgxp5FFbXDJ+q7/yRS3/7Hf1dTr2l8/3dxyueeN3pma9X9Tec7mm4yH5dQl6E5w1R nQwxBKzs78VgKhlPJVaw9AVTejaEOQ0c1EBVckfjgq+p91ZQmK1jglR2YpP3GPGAY8FZjsQtekrK IMhrHS94TT287oHSyQtvM0Zz9USYsrvrUPsF63crRH4YaaCObO3ndSV4hWSSRJE3mAckQOtyPCoy jbmCLYxb1GJnpzSki7UEaQ/ArpG7bik92VZwWQOmyZkD9Q7RRbYW1Ea2JJZKLWDXJZvMgh1KpbAN eUkUG0gWqCrLCANzU0VR3pXJE755qd9rgz/4Mjk5u6qy9LsVc55/9k/u7obC6ioQMy4o8uP3hi9a sxXLBJXUVl2/fi3nRh6katDbr505vnvjhtXv/PVN38MHN636Ycxk+zOBQWW52Q5jv9A5OJ6/GPmf //vS2ajUWyXXlyyb8cxTzz79P1379nl7wZI1GLtV30LtSQT6o3/K/8eHvBZ4BfVgHJHHElywUJVs LmrVUMNG9UuTYmEOkpeYdTua64gh5BWjTNKzMmfDimCXehwkCPJiqAkyBHZbIS9l+xiRV3Uyw4cG aCXYxejx1LjIqePGfPbJiEuBod17v+pzHisf0xA6MJEJLO0t0kUqyR9WSazuIxObbF6QSPw5DL5k q4oqBv1dUkvQXoUSRgzDbiPTH40WRliuZaAVeMHIS7iAesF1RGkswRYW8xZEZgUutYw67kFzJOaG cSvyIjcL8TsaeWFrUgCJQWkiNACw6HJKQNeuz5w7d9bL6D5l0tSz5wOjYpOHDf183KjxqEJ//M// SDMlff7Rp1EhIfZTJo4cOVJj9DrmG1QD3tGOOoSewkIrhjz8Eg/xQRyHfJwOiZw+Z8kbX4x/+m+D X7czYAVmL5qcXgry0th+wkHIv4KtIL4lyC2qOOSvAHmpRkh1QBrSURYMbSsHVmKUjDNU0ZZfx3ny rpE0cL3KK6H4mzUHPnX2SLp8lYX04d9onUL53vuQF6qe2p/YuwC7uRVde+flXgfPBGFbn2b4A8qL /U5Eduv0dmhwxP/37/+8f8eGyZPG/WXgoFUbttmPnzZy8IgbhcXk6KMaY9uBB/BeCrBTsOt2HfYL aopKu/L82590G67t9dXSt6dve/ajOb96a9r/jv6ut/40+m1lyJMgLyAV4MtWMMGlZTQUIynjIyUQ JzMPyiI7Fx2vMFGjJDEgmOESdi5bx5wYwMpPYVgy9SYzghMQy1ArhlrOk2xezhB58lAuZMX4TqYx bomBjH5eRt6dXT+0W7B+ZwchLyosajSEh90s6AckM4pGwMpoeSjwhCY0yJFG2vkipZA3csWQx5J2 PfCII6FFzwj80lZyjmzJb6Y2+8lBR5qcxsoq0IDE5KlOKWF7ASWh3i4Upv02LySB9DBqMBpxEE6Q CWLR0liPDQ/rK6MuBblMM47/ZnpVTWVDQ1lOVtIf/ufXe44cK6xq1Ou8F85bHh6dXFReFRh45o9/ erJT9xev3iga8Le/+xw7VF1Tlp2d3lJacHDzhjFjRp+9cD4lOvLPv/3Nf/7Hf/36t3/61ZNdnGYt M2Wm/rB+9crlm0oLWkpKq1ASaUDSBcRZ+af8f3zIq/Q3qa0aojCRkd2e4AtxSnHmk24Hv0Rvk25h dgCmodjR1hJ1hAfBEUW306gt6inAU2okudoISlSlxOnpEUAzCQ+ZWqTcEH66t5lHVRGSirUL5K2p Kdmzdf3LPbr95j9+/bsn//TUn7t++Ok3aGqj8aQiL/6LA+wfgbzURrUEaF2MPGSJJYqllqDTHHe5 AQkbtp770Gk7KosmlwsZ20xtIey9S61ZcFBW/aULxICw4t4HQ4XgeC/YqlYlpfGD3ChDLg8e4UBY QCx7fP28qiCD6gBfbt8S+DaaG3LWLHV7+tnf//q3v/ndf/z6qf/87cw5i89dih429MuQi6H1hXkf vfO273Hfrz4bnRwXc/r44a9Hj+rep//xC1GlqLF0wGaz3d2JN+PtKAdtvop5BwAfwl/seb1iz8FP Zy75dn+QF22gwNNvkzDnkeQc1OBKQdcgF0QXAbqIetmUUVIszDJwjh6hKgBekHaioPBFSC1ncEQC CM7ZyiMiHvQsTZCPp4oG5P1w7upJs5Zm3boNsKLS23KQMsHRFvIiL3L0gQDltwa92R/Ie6MSHKqv Livy2e/f47m/BAfF9+nTq7bw6pZ1S3ce98stNx/avMtjulN2EW2Og8cxUlSyb/+Ze+otYkC1Fc9e yS1668Nxvd4b13fIlN+/+dWvXhn9zJjl3XV+wL5ONNI4GKtKYq8EOIrFzJQuWjI2jQSCNLqYeoHJ IkZfMLASgGtxJgtei4EMoBTkRQ5iHeMuJeC3AHPlFQqeqh3KlAYObRV55YLKQH2+sMGpMYBnuVTB XTE9Skc2b7ehUxbagrzbDh4e4eY5etMJ2uKTls2p0kCdJtVABkRhkuCxoiaZZGFD/YUmJ4VAckiw S3VcUeDke0FKabpz7SblL211eZyclvE0JoF7hBXxJgXCFrFBUeaMvBB4ZZYKGWWsdqyRl5Q8Gp9e cWXYn9d6l0ASDFUFyH8RSJwBu1yVYfhibBXphvq6mq2b1l7PTL6Vlblny/53/zYk4FKg3zkfc335 x0MH7Tt8PDr58tsDBvv4+lfXYORHY0Xp7aDgi2FxqaW15r+/PeDkkYOVVSUtLTXIcN+GtWPHjDpx 4tiyBQvGfvkVsBXDMgNiUp7v98YR37PzlyzfuGFfHZsCGE9IJWS1wGLMwsmlxIn/U+FwQf28w0Z5 +0Z7xRVxBccugYXGs0lPvPUFPhz1Gu1kmEXcPhG9iorMNbq1Ka5ALfEFyoTYQQHJSMmQEpbWOCkH oCoCsYNukYYXzYPEIhKcAHyhu2AWkpFeIjhWRtax04MGvYM7ABQ22SBLpF4Y96V4lR4JhXOCad3m uKs3lbHirXYoM0ahA5OnrZOlh7eJnWGNTTXZ1zI93JznerrXVlZVV9XHJKT9+fmeSZk3SGm0UhW/ EH4S8o7ddcGIqZ0JpLSx5PVTYw0Dvz+gjbhhlAHMTF6QyzqAgBYvDcjLHTTQ0uTSQTzY4ZhW5pjG yKv2rRCzmCOgIRlZqGIy2pxGW7F1zAYyWGDdsX43Z0FtBXmRFVUiqkckBpK5RKL+zo4tGuC+QrNw xbWbvFywKoVtEf7H4tTnyP9A8i2/Mdqn8ka/rk/6+J2sqKtDf+7uTVunObjOnr8CNi8AtzL3Zren /xAXZRr79Xggb/bltPi42DUbNr/+7vDc4jpybqC2kvH7Y69u+57iIwXHCXwJd7jrwSc47FPdjM9X 7ZsTV4RN/VALsIqFc0oDCKIiL6oAVQQW77aRFwqNq480aMkMgT5kCKYWEdFWDRZJQIySLYmH1ER6 Cy1WQ1OJy+bG5cEY91675U5RKQ8DafuzHhQLetNByKtKOLNAqQKgJCjQWOJmN+6bqU4HfQNr6ipj IkI/GviFznFeWETKH/7wp8by3A0/LNx+5MyNgvojW3fNcHG5ll+MbVOY9q0KS97TrjMKgIfh3qNx Vo3N6LzDYu9ljQdO+Ntp53T/+4j/+9LHnUYv7KE/h8UxBBNlfHLbyMvzhoCz6AVm5KVRVRbkJYQl Q7jVFsZdgUhBXnZEYzIReZUZeQmaVRe0ZSgX2baWPBl5aRwXrV5FC1hFYaiVrOmBSKzI0Vt3qc/k 7T2HTF68bjvo3J4D9NhyCMjrPnbjsRlxhXAd01o6ULbYwow0sKIf2OqhBjOqv6XCkiyJOlXaz9aS RvXdKigSCBXBgWRPRNEqDaWHYpE0Eo/8+RUWAUYaaU9KU59aApgjMzO2zP5g6HAj1u46Au4qsifK m38I57niUt2tw6w1AV3USmxJ39y4dMmCLs/976+eeKJX157HjpwMDgn7n989+at/fqJfv36Xr93Y tH2X0Wtm5tXrSs78LPLBPIj3B7znf86vprqcRL258cDuHdPspmzevPn1V1+LiogEC/AIRnh88tmX S1d+p9UZtm7Z2UiT2/A0yTD7S/EfCor6o0RNqaWlX3DOAHlhuXmfjXCPycce96jaxrh8j7MJT7zx BXY9g/PBIbnBOcNsGZbGJFL0Oal61h6qBhCmtNJTpbbE0F2V5swOpTEvT7XelTTqs2o8A40oFrxU An6KnDAfkZIaVGQUYI2OxPw5wSlPDfgw5tpN8rnzoX67gryIQ4x6U0mj/KN6DPUuKcFEmgq6bOlC D70uOioCbEWyktLymbPm6fQetXWWNyC6NfO7c3z4L8iNfvHyEe5zv9rhhxUaAYgA33lxxb/7Wvf+ qgNuEViWoRzVR9ohbUl4K+UVOljp5/tiFLITtZOEnhLTWgUs1ceaF8xrqWhWOVBVRQD4UnOIpUJh Da6xd+HcmMKBhhXahSuuWyNv26R/OKG4bSO1jHw7YMfeXZs/HjYw906O7I5x/doNN43htdf/MmrU 6H/753/6P//yxMI5M8pKSr8dP8EUGz3D27N3797/9Zv/njTVoZKGNZOx9kBJeFhx+EFFTiQXxNwo KnFdsrLf11PmBibOT8jTJxTSeiZpWA2SVBx0neXM9LQwji74lqSRZJYY5a6aBneVYN3mwV28BT5A x5RGBNgg+GlIqJgRVzQ38qbLvvOdBo7wi0nEhLgHiP7DPliVcGuK4ZoOctpjhYGa0ryb0FT/+8xz //Srf37yd085OGhLS+ujo5O6dOlaW1m25vsV+w8dz8srO7Brj87ZOScvH7xUcpB82n1W34vn8T2o sFJnFZ2HbI6dDfhgkv7ZEfoXDX4ARywd2UUX8oIWk3dCurtTDy8WeHyBRjiTi1iCOIQZXtk4vWtA FNCTfMVkCEv8XWeGVO7qlbvsam4zJUUCstEGAMozmpPBC8zFwOnemuCe2MTBLbyzZ2JnYyR2Fu4/ ZX2vD8btOOQDzd6eA/Rk5PUcu+EEphWA+1inCLO5sSaVIC/0PAfS5LBlYMWQfaQ25H72C1QBuOBg +k07FPqh+6INh45gCJ3Ca6lq/AMnEASTAnn5ZaUpiMHzYD/7cxrraiuLizCLN7+qorKuDm1sc1Fx aU5ufmUVD4xsbCqpoJlBmKWLLicQlqGTCFxaUtTYgNY49AIGggA6mzAHoqGhoaoKgEnJeEoExmdV wjVaW1tbU0PtPYmkviuCYBwW5EWhSVMhFqVELD4HGXUbNnLW+WjvRKy0idHFZZ6JRTPOJT/x5pcz 4qs1yc2ovNO5IqP+SstE0dVKr+JdSuPnZpkgO2EHdmqbF5T21LvDYwV5QVf2JvJ/+nq+EE3JRLr3 JAxuJvpDMdNkz+bamqqGunpwkGhKnjUzaA5eqHS+Nwtbf6O+eCxe9oXXwjE7z6OyCPLOiS74w9f6 gd/vB/Iak0pdaRcbAmVmxy+K+IwLPKYC1RlCQi1qRmT01wB53zcu1yxaDpuXRFyO1is15uH/Fb6Q VPMBORdRr6iA5aQc9fWN6HNEvairrS4suF2Qn1tdhR0Om6sqy1F9UE3KysoKCwtLyypQBGVW6SMp fxYkkiXlwBX/gN/5wNnzo3Ser05wWBKeMS8xzy0Wy4JhU4NKLEXlmdAhZ8+Ecs/EUgSscI5VK5VV sJKqED8jtmBRdI7X8dAn/thj0bZ9tzGoG+VEwVuLrn7CQ/4L/SmRfKuc1SrQ3NJQKyuWVBXlV5YW 5d7OKyitwPgraLq6+uaKytrG+iboHe6ZNdejzVpHPkIwBfnwkkEPef09t+XtXBQUDCqX2lF0QF9W ow3QGJ+YoFu69o8Dxr9pOIm1Nbq4BhDeGUI6a4Ox0iPm7BAcu0cK8t5zxs+24PWBSGpzYnZiw+ZV 7WtMCg7HWs1Y9xKrR2KhrafdQrGOZT/nwy+PX9zz7yOv3MpXvk6+8cFnQt6Dx0e4zhi74TQsR/is sK6jawJcLljRgqb2UFuaewbRTibkRS8Vg6+lLffzXpACoeWgSyYeDf7Ac8G6w0d4tDBXNBFAJoRw n+sgja3C4jmIURaegvOlHh5oSc0Na0gsyzv6NJAMedVjkSorMRZyQpnggoGbnhX7C45rRELzq3Ku kB6JBW3xG7fkWblHudABViBQyQG7SiQVoxnaqsuQEUbfSNRWLL/smFyhg817JvGJV0fOMpXD6ueV IS2NbViUNM6cOwLIxvl5GXT/28ng4j6CGaayhYGX//T3EfFXclHTubVBX45vx1fztBS5FvrcdyZG UguFmifMvqY65iMzH6kFeUXn3/fwI0bgTYY58752n/ftdj9PUykW4cQ6vQsjC54eYxz83X59GIbr FMNnCLIT7Ca2mjz30+Fni1Ebz4K80nGJGjTblP+ux3KnJUsv52bXg7TEAqostlIKzUkaDaVUqNan La1N4QtuAHxxttQgy4UkkGrCwkBigBYv8JcWqLH5kKqtPqbmiP/l9Y1BCamDJzp0+XDMhDWHloTf nBuRMyfm9uzY2x10nhOTMz/mBsK8mFsIc2LpjJ+Lo7Ln+yd8Pm9116Gj3FduzC2rIZ8NrcajaCS1 9O353/q96rcyAWlWNA7Kl9xr1NuFxirhoCxaAp5JevxrqGsUHhLRaVwWbpLCRIJHPChrfjXJFb+I tB0CjJSKU0GRf/7LyC5fLnhZc+JFYyD25O2mC8T+gMBf4BqsYKAwQFPMWOszIanM/emYMzzS3PUc jmUtEYC/wHr2UQdj+4ZeHuG93INf0p/u/MX8Z94ePdXVu7Hd8omvB/J+4jprzIYzM0wVNPQ0sQnI i2V4eaAU7UePtj1MS1Ij3FrGGde/kAD9Btsc43W/PRY8yMsaeVliwVlVnFhmiNMiPyJC9SrmMmLS 3UZ4kBlSUceRRgQfV7iWGFxAM4hy4DM9ZXkc1/RGzgHiCoMLP+vrlTEiFvBFpAizpXj8IGoBYYlI Jr2SZ8BhElO3YZ97nI3FxqBwTGFrA0N8MSHvG5/PSSjXxPLqCim0BxkCWkowJ1XkBQoT+P5CmMXF UMfgxTdC3hYGXgHyJmYx8hIhiVv4bih8kIIvQKG2D9EJ/Ixi9qJqoxElrLFu24DUEtl2RrbEgjUe 8xePNs6dvOO8dyxtHuSdUL04uuiZrwV5r3nR5iBKfRG/Lp9/KfUFLJCWM7UN2OYVsxfdTDNNhYy8 y+9GXtGPNtDoQciLLKzln39SZQGzxWtBrFQgW0kpdhZEAdVQ6iBEwvZDBMv6OY5BC8FsrqhtiEi5 bFi+cbi910tfOPX7yrXvOJfeHRfGO/Ud6yihzzd88Y1Dv7H2L42xe/Hzb0a6GH/Yd/RaUWllHTf6 8dmigKzL/vDr1u+VGnRXPWqGVw79Mlgkl4aYYnlb3AWPEWDT4rqBlnMmpliCZVQVnISIfpTDkhux kQaNIVBW+IMBbm6+llcwZ93+f+/90UuT1vR3PYqN//pq/XDuqTnbR3++j/FCT51fL90F2vLvnjN+ dmToob8ga0Vi0DUusHoVYuSN/Tz8e7ic7O92+IWvFv+6/6evDBmTkJzBMtwuCoECWw4d/cTNa8zG UzNMJcBZzOambeASG2DeogsVHUDo9GezFzqc+pt+UYE71LAJiNi8i9YfJm+zdVuddTjYzQcLAJQw /WdwBKHUUTokrmz8KnTDfU4OJYBbdMBUtVbgkoMao+SD3FohVcVfeRxnaB5Jb1FBlrcI1rA/XGkT 0negqM1Y+tncfegXXn4muASx0wqt7BpX6nEaI6y+BPJiFzkaB5VQTsto88ImaCYRj9iRyF2Hvyiu YVQ83Ck0HdUzrmJe0OWn3h0RdzUHCobJTVwQUnDttFCujQtBXtBHbCWrPt/WxFDd8kNlU+utR7tC fTEu/X6EYd6Enf5epgq36Arsa7MguvCpUfA2H9CEX4dfAkvlA+BoSCEvNoLG4S+qyhD4cocRSsVe cZIWHmFVMsD4neui767eumVVXx7B5vox0qLW3MsLMFwqJhZYVduo1lngEamJKAoWnLS+1a5reZiT Kt9FLTy2+5obIDaIzMkrD4/L8o+8fCkhOyA+zT8xqaNCQop/Qrp/fCbCxYRMuqaQFpCQEpaSbsq6 UlBVjWY6t72pLogPrV2f2ZqIHmz9JRULeaqcRNOIKgsbvNQ71kwGLcgqyCsPUpunicwQSz7gmuhS S0y7L7g8wgVmNd6Fb6RR5oikid5YOas+u6Bs1b5zv3n506eHeXUa/X1vu6197bf3mLS599Rtfafv 7Dl1ay+7Hdjy/r7zjp52HR56oTBTN/e120hh6maUDSV5YcK6HuNWPD3ErfP7E+1nrgqMSuLeLZXK D6MOiCDIi7HNGDoLHe6WXIMdiOBz5rkhtUbMvaUZuzQqBs1jaSGrWl0ZjfNz/uSWANoGUw5LP+8x 8BOIJVwFYxmIWQ75h4gkQyhESUQUq4TXk/ZGe5ua3AzGjLYkF/jjw4K/+EWqgA/lHv2jrBq4wxF3 JF4gWPQMzha0pdTMJFw8CHkpBygZEksatttz8KczTkfOioMnE67mstnoKvKJe+LNzzAkAyzTYx2w BNpXl2cXsl5lJzzzhczeX1AgfhEkQf9jLP3s4IzfDxiOEVZwbwoN1doNwWQZBi1VFhBNrA/EY9lI 6jqg/nrSIdThrnSsW1O7TX1unVP7r6Ex3BavHKafN3GX/9zECjQeZidULonO+9MY/fvfH3KNuGnk jZwYbRl8BXZ/SSzgDgjqmyCpYPAFL9DNNDu2bIBxlevCVVjggmgOhqA24Pwg+refalYpRfKljoBH xCbkD67D2cMvQgJrH4WkxB3UWcCuzWXhzOUVKIX84q8iqDHz0itkAPINVEZUOL4kacSvDjgTUa2D pYD8dfRS7FOARRqtXXNW9GvPJRXbOp3lFTJGhUhKeo2qDH8gYS6uEIUD7yam4ODHrNmBx2xdPZLy YTJKbjgjV+ROyCvyBXCn0eZUoFtFlcalm4fYze/3uccLw117jNB1/0TbdTiFzsM1XT7SPiDoO3/c saHLx249hjv3HD4dodtHjvjZ+WNt549cX/7SMNJhrufyTYGR8egot9hc/NUPOYEIFuTF2ilwVDqn 1jhiEbNkskqoP477eVFJMc4Za+PAtYvaSg7MX0aAfYfh1vBb2h8M+0S/eOv+E/hgFixiJcQJ8zhh SBIVIIz4zxLGm6RQHFYFt+qTIom1UI9Bj+REcb8gWyRVBkThQWREByJxiD6xRN4TLz8pNR9Ij/84 i4TjB/2mM9U7DvybbV5B3leGfeG++7T3xXRD0DVtYKZXcIbz3nNPvPUJBim58qK+zjQmnOZYSY8A PJw8jYu06y+EU/cUA15xFH52SMqT7w2Jvn6tlprA5GwXChC3oA/BEItGYJLccyKyM/lIbxPDiYNC XkkJzLVQ+55nH+0n1IV26fefGOeN33jc6J+u9c/AeaZfwtNfOWFss3PkTcwNwV5vwDJ8L75Rwj3f /rP+JM+VOgyPWmUwewV5MczjXffVLotWX715mwQSfyD+j9LfJhoKI6SO4Kyod64IloojbSRrDlJB uN7dE9neV7N4iJBYvollDLqgob6uUvAX7TfFvqMv50MuOuBMjW1kS6JK0sqB7QOgj8WBA8kWkOLx nGqZ2vlfsm5NjLdJELNX+SZVa+EnmCyeZAtT5GHLT9gU6JhDWWEJtObb3isuD16D//xukF6Ql9wN CHBMNdRi3BcaG/klFXuPn3NfsHbMNPfRUw0IX0zRj7Izjrb3+Gqa+/1h1DT3UdM8Oy58ae/5uf3M z+29v5qmH2OnHTPN7St77efT3T+b7jlOO9+weM3BU+cyrmSL/lfhpV10AR23HTyK+bxjNmI+byHm emBoPfZPd06hEVZQ4NJ1KE5dwC7VU1Ipv5SA4sHWmxlb6XAg4hP90q37TwpzhaX4OiAvAjEcfFdJ g59CK44lwRC7CZKPhBZ5s/hnoBnarPiSidwS7SHX1oktuVERUJ8Ydq15I0XlGBZRRTz5H5cAZXpz 2KfjZy0fu2z7qJW7v1ixbez3276cvfKJ/u95JxU6p1XaJ5XS1vaJZO0CfC34izaSIO8vh1/cUpJJ xBVe8flzQpJ/b4W8oP1dyAv+IRDz2jiEkoqtpBBR+EiJLcrcmkdt5GJjFHgxY/mqL7Ven8/4bszK naNX7hizcvukldt+895ng77fC5sXo1WxLTVjK4YmwlmEVapoWugvJnBjQJlYrfhDUFp4m2eaSt51 X+W0eFXWrVxQncj+o/S3kXKUXFjWZheAhU0KW6Hj1fQPqlntKoAIhiIe1t8E0xLqv6GpGZ05NOAW obVX1fqpDr9GC5MDfFw0OaJV4DHSGL9sPxQ1Ynnwni9otXyFyS1K9xa3YukhaxbgJ2swylOtm5aM 23WhfAL+IQ8uCtoZcOfB0KXKTQ0Rqq48pxIcYQ0MdStl4zIhmVjlIo+WMz3HAc/gooPOcDkiIH+l SNxsQAzKSvNe8FXw29PulrScMCQJydpzINnOg0dGuXhhX6oZpjwDtgrFLlpYvCIFS4iTzQs3FMxe 1E3prhKVYplF2M4LWp1DDdRZTNt504Tcnx6g0DC+1COm3P5Q5HD9sk37ThF/VSrh61qRFz9IfCzy 1R7ycBo8aAkPeMhyHxe2HuojVLjWF3GOMjsG7F28ev0ErecXbjO+0M78WuM92tUwws7l3/r/fVbs befEMsAuAqaDSTvEPaHOPb4BnmcQ59H41SZfwDLMJhb2SQLhaZuJHxSJIkGijIk1WMrMKzpvfkDS 0wOGJ2TfbKBNyJgCwj+5RoRQ1laadmT6xMTk735YP2qSyzhX77GuHl876xH+8NfBHy7bqom8QcjL i6BiVq8mpdQ1qZgNzLZFHQR0ScBA6EpcSI0QCj+Iej89Hs0AWiZC3UZWTHKc0ak0x1T8jvty56Ur M3OwixArEKhkwYKOpGf78rbIBi5sPKxESC6tzoIm5BZDaJ0WYeMbbEwu36LKtlVpHpO0q/nfXaz7 32Mdc3fax/YLrxDMUj6N1C+KR96tu/oBqSiIB3Bxz5H6fusS3n+NVBIpr+igM+qCYLqlAHiR8lG4 Q93l6OTCmSLVePUDHvwfue3Ye/hLZ8/xa4/OjLnjkVyiSSnHYhoOtI4ZzbiHMmez1zJFglrvP0UD QMlAvTw+DYOsqDN68sHw4R4rtx/1AwXwUTAW5WAWg8sUyX/qjQfT5N47FopTFm0f7UjS9oOIRUtS AR3xr8ovzhEnSCoKD3FEKwsTezFnqZbH+2P5tSdffX9+XD54gY4AhxTsK1ojuAbkVRZYTqoDcR4X +ArXhH04P6oMQH5qtfE1wN+ZcaWLgy///i8fJly9RSYOfy3zCFQRKjyQaD/bDRSSuiapjYR2OIwS 1EqwZtg050+Wb9NF3kRlcY6vd0lEw7VKl1yuSy61jE68h2IWeoKYP4GebWP6Pe+y+qlY31SvAcFc u3HGQMqZMfkDPFe4LFuZcetqbXM99+jhS/F94MXPfog8PIpUcE36sfKjAooVBuRFaK2PlorZERco luWQIrLiUuXfcu8RLtqmkvoSesP94RFe055H8CLBI0pM+g0VR6AMtUccXJyNFIggTuSN6pcc8t/6 rNwAUyhWhLOjzngDgsCHXMjn0Jvp1QBc6acmZ4UkUIv3kP/IZ9uBk5+7zP52s898mt9d6mgqhosS Ni833WndDIJaWfdGmclrs+sM6/xgSVIJtBkWB2T70wNUilMi6bcJR0IGuS9Zd8inBj17+Gj8SSD+ 0kB5NTyaA+chZPwpt7mms7xBMqWUYCnPpJBfdTzwnl4hX4RWRVNLzp2SP7w6cKGpENjqmFzlnF7r TH7OKpBUk1Cjiat1i6t1SqxGJJD3p9OZs61yMZWDiZLbo/ERDnCMInBAN2hKI4Zqzwm68ud3P4u/ mgfTSvl2Yp58KHGKf1HML+YAb7DSQDWGwUBd4xqL78FcHzJp+ogV2w0ROUbMhTc1aTDtPb5OH18F Ly6NlGhL1K2rg4Wqlos2H/npkeiSgC8L+19Lu1rtoajFCO1ZMYUDPFc6L11xNe+mAkD4xjrMacNn /r96QH6kErUKEq7wQZaAn3xP/iOxXHTQmV5MzTal8SZktbzL6u2KMQ546gjSW96Iiw49kL/Qn99i +XZ8FIKAL5NfCkSJhDFMn1YmcSSV1cI2XEga5MPXHXUWfKdC4kOk3DgLp5TyKNxUUvKXPvyETLYe Pv2R86zRa096Ree7xxdr4kuMaTX6ZCypUadLqqPVRJOq6CKxzghjCn7CRIp5hICNpxEoN+iihIpH yOH+R3Q0PrPYIyV/0vHAge4LNh7zEbLw8lRMGGaxEI17EX7JyMsFRlkhStyCkt4NQDN1QMMfizMt PdnY0tCYfTP/mTeHzgq95WoqhfXkkgSnJdYfq9SnVBGRE2uw8jZ8FxiRDv/n/XR7tBjawFTkAf7J lBrhpk1Z0aI9GQ3TeQg9hM37YuozA78wZd2mriYJ/OEs50r308OF+B+aAvKDDkFwhi+wHAHZwObh ds4jl2/RhWZ7xtdh4yH3+CZ4HvQm2h/kQfVFaoHQENUB9ESwiZiPkJikIrmBxk8m16F7AnKCgBJ6 xZdj9Wnsmjd94ZKs29frlMnSrOhI4/2/eojChGQpH4F//E2KsEld4+r2D/xCvA8iI+Wggt0XJAHS wNclKR9z6azf+Jizvjs7vEit1rgBrJQg345Pg1l01+fz03KXz7h912F1SyFgB8fc3UzCt6DQ8kU4 q6XjFgXKIx9zV4Ef+ANgtPbgqY91i8Zv8cOS6TPjizHCGasBaCPy3ePKKcQXU+Brz9hyrNuDyaSG +EcMmP4j4ZFzuOdB7B3gGXd7Tmy287Hzg3We6w4cInYKTcAToo7CXyGacuuB9LjnhrD1nsjH/pPf cp8ISkRNA817o3qKD6HJ7w0Yj40KielvT77y7vK4PO/EshkppbrYHPeEPAOFAn18AVjmmVhsTC7S JhZg2Y17iPZoP8E4POiBXS1MxQi4wE99XImNuRUbEovcTLeNiYULkgsWBiU/+dZA7JhA7SEhtoq8 DG2PndSPJUN1mBwKzEwCO4ZNtv/qhx36oAzv2GJMNUKARa/HUvyJD6wpmPkr9AQNQU9aTtBmYj4w 8wcxRZ9QqkksR9AnFBsSCj3iKHiaimnpQtOdAYbFrkuXZd3GJC/W+OABvrFDDmG2nDvkBZIp+CN6 UqlEFvVokTdLQZiVivLsyGuURLo4+dz6QoUKeLVUdgWkoLE6igetb6SXdtSh0hIfojYkJIq+S3E4 KxF3F0N9sJVESrKOKmmb+bLipW5cBDQbKA1OqlBZHrGIUXuZBXJsO3pqyFS3ge4rx2/3m7Dj3Ddb fSfuODdl98UJOy6M34lwdtyus+N2XkBADG4hUn7aev5mx/mx288h4MLWZx+UfvzOc1N3+03bcXLC ys3DHN0279+LsTr1mBskBAIZGHkfQC4L3R50IfR80N0Oi2cJo4HQimqnF5HZC+TlkQlQjFfv5D/V 780pG49/A5JuPfntrtMU9pwZu/vM6B2nx27zHbfDb8zuU1/vOjlu17kHUc+meGHchN3+X289i2tc jNnmN37XRZsy4cKcnrz//Pjdft9uOzF1zc7/6NEv7foNWkyMv1akGmdF4fAV/frFHMpgdSkoBATV scX8ybdTPp6xYNyWw5N2+mGqL6oS6P/1Lr+xe85jV6M2SSTVAQQEGZEAFyAsqNpm4scVicKM2Y1w DpV6/K4zE3aeRUAlQr2euu3MG9+6eK1YcTk7E1uKoAahvS+qpgNoLzXrH1G/wChVnPh19FWqeSL3 /pFnLozobaJwK4G5SARGaiFRThmPxKXvABaoWVoVQo16rP+5/NyrS+5lylp5I76U2hXKL04mL5ZL iRcqWWilJLYqoMR00Jnfczf4EoOUL8BLlQTMtfvLptxv+19zalqivVb37jdTBtkbh0w3DJriOmSy 6zA77VA7zWA7zQf2LgPtXd6f7jbQ3m3wNLehdgiI17U/DJpC6YdM0yPg4oOpWvnZ/hx+NKVh0GT3 QRN1H05xnWzwDAwKQMtKGpNEHRBJaTq2injbZGg7lmqBDfS0Iem975NH+UwvRcBEJ5rNdDeX0b0o w4CLC4tGjZ04ZJJu8PSZH07VDQenJjsPmaYd7OAxyN5j8FTPIXYeYN8gO1ecf5SA7WWlMO7D6UZc 4AxuvjPecZiDu02ZD52qG/Sty3B747uTNQMmuYyc5jzgkxGlZYU8PpCqIaoY/uGr6RBKKD8k6mc+ CzuokJgGIcWrg4Y079izd8A3E96f5gxqDJtmGDzJBa3Z9+30AyDw036MwkPtDaAnyIgL0BOEtYme j5pYg4r84VSqyyjewGnu70/zHDBFP/CbyT5nTjVUgh3o6VU50SH0F9pZnzuas/IuCJcEpV5bVLoq bUjWwYfIkLxEucZLSfglSBzOUjZbS2OdvfqskrPlFeoF37e8DxcdcSgFAuxif2Qme2sRLR9upeak GGph7v4l5VNbKa35dES5KU+8QcSFXyAQTG+XN3PZ5BPIeAe/bGFZc0N16SmfY9sPHdly9PTmA8d2 HT2558jxHQcO7zx0fMfho9uOHNl69Mjmo0e3Hj2648iRnYePIp7DyXaef9i8a/2OvVv3yYMndxw8 tvNQe599aErsyrT98DmEHYdO+wYE5d3B8jvYaYNa7HQQaVjqcLIiFt9rz4melefak1p5RbuS3psI bxGutbrFqOTc7OVCqHcpDuJQX1np54uv9t1y6OzuIz7b9x1ZuX7Lup37tx7y2XbkLOJ3HTqz4/Bx sNVWfv0IzcG7XYdPbT9wFG/ctPvAinVbcf0j6duSkJN7j5zeedBny8FTu076bT94+Nipk7R4e2M1 eyespBcUIfILE+8l18/1G4USjwpqGq6peGBMQ+OVy1lbDx/eePgoVkHfc/T0zgPHdh85uf2Yz9Yj PjsOP0Tat+47DHrivHL9ti17D9lIT1TGh+TfFheO7zp0FAG3th0+ufnI6U1HfLcc89u450BxQa65 oRIr5iufJmL3+MktrLU+P/53KDmCTwqr5HWEcQIB+DgJ/FMpjCTvoDMVqY2s8WoL8tJ9KRWiHoH8 kv3d1LSms/U1p7Iuz92PPZ5fSoFQY2R0hEIAzlwtzF1l4Mi2PuOuRxTtgMQdeKAUcDAi4ILLDdgV 3OcYejMKoEiUKkvtLw99KZ4SRguv8SLJR+Jxy3LXEn//BShricS1/Nx78Mjeg4cKSyuQg3UCS8rH dUHEoYN4oV5zRBu/1fhf0v97y3x32azv0lrT1CKgbhLZZ+TK1ezZ8xdcvZEjnMKC66Bqe1hmK/HB Qck2v7jETe+Os3UOwt8ffy/KLY9IMv4ukkAL41q/FFetP+4mx8/3SwrVWi61kNYER5z8/BFSWG4J SdOzrvz/7L0HfBzHlSYur/Xftb2WfSvbZ6+9DrvrtHs+n2/X5921ZNNKlGTLkryOsmxLpERRBIk4 GAwSSQAkRVIkJYoUc5aYMwiQRM5xckbOOWMAzGAS0P/vVfU0hgEkABIkRE7/Go2e6urqqq9eve/V q6ru+IRVfbYh3IjFSjj6Nxb/c1y69Z3nmqeDnPAdP6kWaICGqRdf0e4e2LPxZNIPfOPlw/Eub5SD iVzhh5Sxu5+32waN2MBvW3p3KiFeF+LTrvgh5UCsu+tflGLN2on0gib+Cjg+HIZ3QbzyyisvvPCC yWTir6nhz+evSZm1vNzLCUuv9JHejgVgDx06hC+JnzlzBt+i5djyo/S+oNuFCE8Wn0+9fPnyV77y lfT0dJ4yMhOo0+mCjNqR3rW1Z8+er3/963q9nn/BWQLTv9VMN/1A/AACAQTuEwSuUhQ6ne4f//Ef P/OZzxw5cqSvrw8gSHxxnwBy24spISwpZ3yLcP78+Z/85CcXL15cXl6OJ0r6/LY/nSdeXV29aNGi v/qrv3ruuefwdJ4TZIznTcrYbDz9nkmTY8WLgw/E/+hHP/r4xz8eHx/f1taGQN5MUI+zWpX3DJiB ggQQuG8RkHo99IUp9jYLhKDD+6lPferBBx989tlnz58/L6kR6eS+hetWCi5RGz+BVfPFL37xgQce +Pu///v169cPDQ1Bq+OSv26/lcfxe/mzkKbNZrtw4cJDDz30sY99DM8tKytDBIRj4zEDlTtFtDm9 wnRBDX72s58F8371q19NS0vj3V6eCEc1AOkUIQ1ECyAQQKCuru6f//mf0ef9xje+8bWvfS0pKWlw cBCaRCKOAEQzQwAA8lc6c9X9xBNPfO9733v44Ye//OUv/+Uvf4EfGMlykG8j1FJS2dnZ6FyjQtHn Rf2i24suG57I2YFH4xmbWenun7s4VrBk/uu//uub3/zm5z//+S996Utr1qyBp0gyYyTY7x9YAiUN IBBAYFoISLY61AW2zMxMDO++/PLL//3f/33p0qWCggKoFIRPK81A5KsQkL42y9mtoaEBzoQDBw58 61vfQneppKQkNTWV621Je1+Vwox/cm5FnZ44ccJisaDbW1RUhCFmMK80oMxqPlDFN8eYg2m325ub m8+ePbt//36M86KBYLAe2KJyef0Cz0CH9+ZoBmIEELjvEZB0BVQHFPKrr7765z//2WAwwKvGsUH4 bSeF+wr1q8gXBg9U97e//W04fgEs19gS1LcdGdQjngKHxic+8Qk8Eb1v3gHHgzhHBJhiWpgDTAB4 +PBhMG9ra+u1rQN4BuzVaUEaiBxA4P5BgCsHqe8j6f+FCxf+6le/gqIGFPxqQI3cFqmAxsbGkzp+ /DjmNufk5OCnRHzS1dvyuKvqt6amBn1ePqEL6eNZvMb5Q2/vo29L/udgIhKlAq6jR49ikLexsRH5 BNQcQKk1BZrMHKy+QJYCCMxlBBYsWPD73/++oqJCymRAjUhQ3PoJB/PUqVPf/e534WqeDNvJwqeV ASkRnMCU+vSnP82nV904EUTGdlWca0OuinC//cQkKwydw/M8s4IzjCcOkyUSgH0yZALhAQTuMQQC zDurFcp16U2Z96o8zEwDS3fhZOrMe4NHIx1sV0W4P3/eIvNOEbQA2lMEKhAtgMBHHYEA885qDXJd Ol3mnVmWJL2Nk5syrxT5xs+aYrQbJ3IPXL0V5r0KQ/wMePvvAZEIFCGAwK0gEGDeW0HvpvdyrXsD 5kWEq7abpjlZBKTDL+Hkpszrn4h/BvzDA+cSArfCvFIigZMAAgEEAghwBALMO6uSwNnwpswr5UEi QSlk6if8WYiPkxkwr/Sga/MgpSzFud9ObgvzAkb0dgNg3m/CEyhvAIFrEQgw77WY3MYQrmZvwLzX fdbMvJGSSsfJFJkXMbFdNw+BQH8EZsy81yJ8bYj/gwLnAQQCCNwPCASYd1ZrmfPajZkXcbCARVrD MuP88GfhdpxMhXkRDZv0OJxf2yPzjyDFvA9PZsy8HCtU7lXWVADY+1CKAkUOICAhsHDBK3/4/W8r KqoQAi08Ln5ylv0QD/hHHybDVfadMunWwMnNEeAKdnLmxXfbR8fcwyMO++DIqN2Bl5sQ0PzzcH6k iAfR0uCJkOs9WVLmOJkm8yLxsXG3yzXqlDJAz/K4x90er/jFS3okAvku/rjy62kUeI9uEvNOFP/K kl6BDF1in/OjT9h7naN2m2140GYfdnicXsHrcbmcDrQo1DLuoo3+iUu/2e/AIYBAAIF7G4Gx1xf8 6Y+/+3WltQat3yWMufAZFq4PoAnG6VOk4GLBaRPGnW5BcEq64t5G5faV7ibMO45PnHennNw5/+fP fu+H80LDE/JyNXavgLeJAWooZ1LJ+MMbOcbxsV8/XX29HF6XeXEXJcI3/oP9dnspQVQuOtxkWXmd YyMDcRGyHds+7Oj22Nh3fj2D/VGLg9o6bQ48f4zeAQKywHeoyQDDzSDpcQjFfUEZnHmbWpp9RhHZ Kr6dwODhdCQ8xgTPqDA2gt050L125fKH/vZ/fOkfvvX8H9/QWBqSz544uG/n+fS8IV7FVA2sfvFZ 5/sDTFEaA/8CCNy/CPiY11ILBQDmdTJ9CjzcNscffvW7hpbWEZddGBvOvXRu294PPjyfTlo3sE0Z gZsxL5Rz065N8t/86S/7T2Y894s/L1saV6ix2gUiX3AcKoWpdZF5RS6e5OnXMm9peRknBfEOUvI8 UfrvHh8D/5K2B/PCsurr+NOLL379K//yixdf63UK4NTx/oHfPflkbUMrzAB+44h3HHmDDIB1OV/f J2RxFfMyPH3MO87AHCPEgAyAZXg6BM9AV4P1xz/80XPPvlhSrFJpLeu3Hzh+PmX/+28nRoeu27IH zMtN2TEXDDDcLXhBwYEtgEAAgXsfgbGFC/5M3mZrLZnrtMPyhvIYc/f2fPPLX7JW14x6oYX7zx7b Fx63JmnLIWjqwDZ1BKbAvA17N0e/vixKWdG98NWlYcGRRdrqAca8Is9SbWAXvf2k2CfZZsC8LDX4 mdFBGxWG+5a++qf5Tz3xu5cWBoW97XQI433Dv35yXmWd1T7uOnn81JqkDeezS2o6bU6Ws3Hqo90v 4nB95iWihN1C9YEDp13mQxgVxoeG2iuPHtrzre/9tLLFBWcBXPm9tr4xty3t6JbXfv3kDx95Yv3O U6l5egfZMGT8AMqAT2kS0Q4EBxC41xBYsOAVvD3SXFkjmutQA3Aww4to6/qnLzxksVaCiwVh4IP9 W0PjN67cfPh+UbW3qZ6nwrwfbE94+Cv/+tmv/N/Pf/YLwUuCSk1NvDcE5Emp4w81wDpWUh1dN3fX Mi/eHom7KRG+8R/sNw5IzUcb8Da7nH1d4W++9v7W9zKz8p967A/L5RvHbc7f/GJ+U4s1boX82Wd/ sXrt5h0fJudrqtzID9uumjUkht6L/64zzktgAj8fhACTBmYQirHdEUGw9TToViXELQhbO8gu5eek X7hwUleeeW5X0qJfP/Wf856OXr/vOz96tkBpoXoYc9vd43B0sMq5FxEMlCmAQAABPwQwt/l3v3/J VFUlUipZ8dDyTqG3/nv/8Nl//+GPfvyznz4573vf/faXf/rCa2/tSIYLNLBNHYGbM6+7ft+WFU+8 8MrmA6m7tm5bsuCV18MSetBFIiXM6gS6eIJ5GRdP8vhpMS8S4jxO7An68Lrt3Z3Bry/avetQT/fQ sT37nviP/9i5fcdzz/28q6Hu2cfmHT+TrK9uaeoaHvJQ3pzo2omcM0lu7q1giXlFaiTa9WNetBi2 sarC8LddGLf1tZreXpvwiz8G2xBxXLhw6siLL/x8RWz4rrfkibI3FSvfzjG1L4haG7fuvXFMrxhz oTpQ3wHmvbcEJ1CaAALXR+DVBa/95g8vGTjzotlTRwidLYcw0vKN//GxRW+8KYuJiVW8/uKLTz7z UvCaXakB5r0+jpOE3oR5BYcw1rpnS+LLi2XwNpcVFL3+8p9+8uxvu1yceRm3oVL8mHeS51DwVJmX JYFUuZ5nHg5008ac/X2LX120beshDDl2VOnfig15+tlnfvDD/2ixWH4x77FzqWldDi9od4jlDfdy 4r5Bfu6lSxPMy0sF+GhnRgs/F0uLqsL09BFhfHC4u+r0iYPf/8/H0osNTseoUaN8Y/HS119/fW1M SFJ06Pqte8vq+hcq1q16by9V8JgbFpCbmVr3Em6BsgQQCCBwXQQ485qqKqBISZngHwalxhzuzup/ /Ye/Kykp6+4fcI127tm35Q3F+sStpwLMe10YJwu8CfPCt+Du2vP+6l/+4S/bPzi7e9ue1/+88LWl 8vZhGvVDbTD1Lh555Uz2IIoLEmUbTqRVRQgSQ+kSeTTEOKhnqdOKGGNjw909YN69u497UcejPXXm 4nnzHvv0Qw/3t7UveX1BTEzM6dRLxcbq+q4ByAi+4YxOGqZH+yXOE743j5Mwr18FieUGvKg6pzA+ Irj72hpMTz41TyYLz0nPLsgtW7RsxZLQ5e++/VZE6BuvLg3efjLl+QVhZzPKMLucpldgtJ0t37s3 EQyUKoBAAAE/BBa8ugjeZnOVBXpU1PPo84ARhrq+/j8fqqqi8V9hzHby1IeyhM1J7wXGef2wm8Lp TZgX/SPvYObFE/Off/HRp557fN4z69a8U6Y3YaYNYBdJDf/Qt2JjvlQXk2/TYl5Ou0S57ElYtztq s23b/H5KcpZzFJSMqbk2s6nymad/2d3eVmk2vPzyS48+/nhU4toSnZXuYqx94/xMntOP3pWbMC8r EMcfX0Kmbq8X3oxhwTvU2VSxbPFrP/lPgPfcI0/87tj53NycrOXxiv8372ePPf+bhE3bBzC4i83l YnPFYfSIphELDRwCCAQQuDcRWPjqoj/87qWKStM4VpnwPhExr9th63/kP37U0NjKRhadKannkjZu 2/bBqftH2d6W+r4Z88LacQiCA8gTAdJwIXEudDf95Dm4Nea9shTE4BOp4owSl3ZiU/6LuT5857Ro 1+3CGyHGBBekBJ5RZBfxKCnk9L5gCol5RXyuhHUCQjEcSDL+BXQwcbxjLpfL4QUZ0yACIYb1XG4B TgNcxGWAep/AeCVsgV8BBO5XBMaF11957Y+/+31lhQnalbkPMeQH5p1QwpiB48VrAeglGwK9UeF+ hWpm5b4Z84K2iNdAYQAWbMsJlzMbzsXN1+e9MfjX7fP6kuD/8TiRKDlZiNXJf7Cn8DxQrIm6phwy ImGT79hjWE7EsCsfcW/+8mNesjukQorIScYLO6GrBBBDkCEJhsXqaTZZHbYWmpjPr4y2xl6aIqUj pRw4CSAQQOCeRWBcWPSX117+rcS8RL6MefH2KmGUuZ8lFTzqwdUA805PFqbAvOAvAE1amp2x9Fnf 8yrmxQXGd5Nm4PrMy3W6eBOjgWsTEOMQoeCU17L4LPqHfLH+ON2Ic6fvksQfdOHe3q5iXmYaUb+f 7xJiUog/GjyQQuiNJeRQkniXhnVoF2EPtC9/3ALnAQTuWQT8mBcuLy/r9gr0OkHSsGzMCZY65moy FYNZIGSiB7ZpIHAz5kVSjA0ZwiLz+jQ1/vs2FodXgi/o2v+3kXmRE+J9ygEeTf9p9hb9xBXIAAUy a4F16+jHPb5JzIuy+2hXZF4AdS3zElRX8SmC0PWl92IjOq9QUPAE8+I6pRjYAggEELjnEfB5mysq LCBbMC9RLtMK0LAY12OONQ9fuul2o7PDVO49D8vtK+BNmVfUtcCVRnjJIUkPv54G5gr/Blm7KfP6 UYavHvGgiWcRp/CHczbxEYRfFDE+41+cs2zfIEv3zCV/5mXFppJxMERIrikqDxdHcHhsH0njEiNr bsYwS0ZK65p0AgEBBAII3HsILHz1td9jbnMlVhVB8UIV0JwP7NAMoGEWQpqByNdfSd97QMxOiabE vBNaF/hjZxsCqSbEjUURmdEXdvX/W2NeSpwxr1jR9HwuCuzZnJR9AUxUWPjVmbhHf1/NvAwdlJVj 4PvFWo6v1nyXMIIPJzNrXmhUiOJ7hwkHXGx0iM0uUYqBLYBAAIF7HYEFC17DqiLxTRqkIpg5Dvpl A4+jbny1BtOrKNzl9q0XvdcxuY3luynzEuDMLUmaV5xJBV67QqezKIjFFfukubsF5qWUGRFw6mc+ ZMqEzxKT+uO+3IJD7qttgnl9lXFN8YEhR4+BRnjyuuW1hiP/SUfxjDU1xKYQKVD8wYMCxwACAQTu DgK8/V7/2fyaL4bPhL5+3MlCr2RepnKZIwyq2Ds2ytY7YDSKPhCH58AfjeM0N6Z5rswqT0EKExPk v6eZ+nWiX5kuftF2ZSAPuwPHKTIv6/Aw5mXZJZKlDLMQpsP9mI5TJB3ZXROFoGex2+GxqK2v+duH PlVWVjJxmTDwv9f/CiXFroqsweHi8ek5rJtGnnAGIw6ijNC1O7Kx59LTfUW4rU9F2XnJKFV+PnHG Hnr46Idf/fo/NDc3ipcp8KoNUEjMSzCK6Imx6BEAjV9gYQQdDxErd+LBV6U8Cz/FZyEPtPNfON75 baLQUiYm8kEQTQA+EfXOZ/M2PpFj7ktw8kJNfsV3b+D/rCEA8Hlj5rXgfySBRB2i0WLHOfu0Lr6u y7xaV0srv9GFD52zuPgYGU748S+vvvLHP71sqap0sg+28qLAtcxiTmgPfuN0jyyLrARs7i5lFXlm qeCAX7jGss+kkRMNLkxvo3uZlmO38XQ5JkREfOSUUZgPSvb860N065c4qux55CLgJydPn/ruv/5L YXERQjxjZMPwE991fLCA+fd94LDM4VY+zxzuSpqUQ5tYIg/7jDIvD+5h0XmiONLcdFdNc/WnHv6b wrJ8pMuzJF2XMiCF+J2ISpieJVYUP2WPEE/Fc7+7ZjdEzAqBgz9IOO3ARAzn+cAPnPBAujD1DUXG G8Po1cms7RDUItp4As7cNPnh0PGDX/r6Fxvb6qku6DPF9DTUEH84R5g9HffQzsNvcOQpIALS4tF4 jm9wy225RE8RE2ICRkiS0kA2eE4mItAZA5lOZmVDRoA8zSzBGUebMsEBpHqhUPyULrHs3BYc7koi rDjwH7JyAVFeahSKmcxMpKnsbKfqmKiRWYE/kOikCKBmfHQhxpEEhmoNFcMv44QEmBQyZ178xvVr j1icSymMj+PDrD09PV093QsXLvzlC8/jozaDQ7aBgQFcdZOquc6916Z20xAmQjyLrHFxYfJJGr+A oyhyxLy+fLMMTO1AgooUeJ5FWJjIIgSJc41KSfGni/GmlvaMYgFA6T6c40WOJ06c+O53v5uVldXf 39/V1YWrHno9JFz6PgwY8yJrVJP4R5lEuTjzojoY8/rCwTsoFOkr7BSTbWi8uNkjDPT0NrU3m6qN D37qgcKS3PrGOlwGWdC6bEYZ+Cn5pfmtc/aIwrGaZICguD7mhagzmWHhIizsnDCZzkb3Eoxc//OU uJjwDxeTAI26G5rqDx47+JVv/L2l2tzS1jw8PMwBBKTYpvO8OROXF5wo4ArmFfOHq7QRMvxslo54 jijJOGPSy+ubCTxknteyTy0gL2LGZik7dyBZlIWYlxeXnoczVi4mdaTH6DfThFwOP/IlvgOgzuoj UAGcmHzmtFhrE+JKtQbaFXPBK8z/iElSULzjgtNJ6wexZaZnbNiw4Zn5Tz/33HOhwSH79u2zmMzc Y0m84H/vLZxfIT9IhzcfliAy7NtZrhHIHySWYWr/xKR8Kho3sXRwIK0pCPiSO3b+PkZKkV29A8cx j9fjctsGBmMU0bHRMV//6tfiYmK3v7/tzKnTYg69Y0AbmofZBpR/ZFJ6byR+UjOkSucosZyzdokL VGj8SeDinF/yCuVFqrVvbXh/246/fvD/e2fjprCQ0MH+AYrs28WPDPl+SuFz8cRXxImKE8vB5Fwq Al3GxiHg51M7IgUfhjjlCPBU6RwCNDzW1dApC4+KjY3/0v/8+41vb0INmgxGtxMve6T4HyUwxYL5 kMFPETEIGJVG3CbOSPB8obPyH49i3W0IOcsL6oKdAnjWFujtPTjnVcTPKR+I/BHdKeNkbUMvYUeJ UDReFATynxMFZJdmBfdAolNBgFcMTGua80S65Qq2QoBPdVAV8m1ysfTiXURU915oDJDCt/75m599 6DOf+7uHwQub33kX4dhFUZg8kalHQBqSREm5Y/nkSlI6snzzJ/oKMdX/LF0cuAzTXSwdHPBotF8u 5DjBT4rLrpJGwcnsHfHGInI/oHfqfuWPf/nC5z7/8EN/BypcvPANq9mCcKoIqlLSLTxvHCj85BnE T+x84yFihjlmPMi/6n23acv1iqi4T33yM3/9sb/53Kf/ThERZR8eIXS4HkU0DsTslf22poz88prl 5fNB4oOJh+JIG4eGn0/tiBs50DwdnnNm2JCXAT/hvXAJv3rhN5996OG/+/TDD/31Q1vf2VJXU0uX cAtaJJwV9FjGUSxkduXK99yZP8UPuSsw4gjwoxhn1pkXGeDajIqDndU0/qNOGPOKlYNg7GgaYotA jFvH4a6k4CuIVDoUhYEwUVIKwR/f2dXA4e4gwKvAj3mh0JlzjKSRNmr4PlHkIdc7shlSdMHlEuUX 5ytWJDz00Gc/9rGPv/lmUHFxKUatuPOMH6+XzPTCkHc8DE2GtxrWsJACsotgvrOs36KkMVXpS9wn tD7R9f1n4XgafmObtSO5fP3SB6QGnflrX/vGxx548Pvf/8G+PQfdeGGJ/9NZdArhecMJUmCjvgAI v3gAjrTx3/ycforGGO844NXK3AtaXFKGJz74wMf/6SvfaG5sQUS8DYU2Xr++Iw+Z60cfAkBFrGKA wKSGocHP6HgVNlSum25SUmJMng75jrDjIh4BG0ml0nzuc18Anj/8P/+u15qoddDYMONcFoeHUBp0 z9w+stwhmxxMXkaGJL8g4skIUSwNK9JsHdiDWEcXWWHA8rxN1LUv/COALaF5w9pHBL5zOKloTIom 02CESGC7qwhQfYmNgjOvxGWULalCcTJ5zcM8l66i1wvVMWgb/l//638//LkvZGXlQNGAJlgCt/Mo USxOWGtCJnxhNOTha3S8CJTBaW7sRhzEpoq78YPLMx7FkxWRE5v2NB8wk+iwcwhMPJ1tWDH9iU98 asOGTfj2k5ScaAJRbq/cURKGig8xsRD8Rl4gdhRvYzNkPE4BDlC8g5/6KfXNTcuXL//bv/7UskVB vC6JGthGfPHR2hiGgERCYwIuQsEnSzNjXkDB0vfDE64KjLXAJUFHMlLGaFTuhRde+PgDf3X00JGB vkGOnwQppcES+YjgSmKD/AJSvoviRRBA7DieJEW4ekeKxcSYni4+z/ef/cRFnktq0T5d8REB+jrZ RNlYcVlhYV6jUJhdiY4UQn0ATEDBo14nmUDQbCPAKwGiJ20IwU80Dz4+iDqbaCAsNo9w3SPuQotC fJebptogjmtsPDFpdXT88obGZoRAEKBrEI6Y102B3zX1IxLx26k5s/mKvHVTdq5gXqmQ0zphD5Ce Ikq2yOksfU5j00rzFiLzWUw08waT2ZhGxlGv18+fP1+lUl2VMJ9nRRjxBknZZs2QTT4HQBxqus42 nFA1+cI5uExJogGDKTx2t4N31urrG//9+z/sau0kdyjb/Od98ZCPwpFLiEgEHA1Rd1Gx8IfOPHaS JS4D0y0Uv0tMmW4mEWVz2JyjXjvOmdAK5eXlTz7+VEdzOw0i+G1SLfuFzeVT4Mlb34Qg+TVR6SoB PjM8p114/hjfw6RflI70gzodyLZY0dN+xFy8gZWIv8SbvlCD0onFnSi1KOhzMff3fJ4gepKanRBD CuQOZ1K2XNNKUPhH8z/na0nQtHigdNLW0T5gG8RVKcT/rls8p1xREhAz3nZ4q8eRhVyVulSGaZ3w RES5neRB7HFMmZBKEZ8+ayde8u1OPAU/0W+qq6txOvGZOEwwpqseTE8W46C0iMyRwSXeDEnvSVXv w4Myj0BExRERpA3hzHSGI5tOUJUwoqsqqn2RJjLDHzpOPvGrA+doCPV0CBxWfaxAkthQEYAYHydH tCtBkdCZ/EQCmePJIWUPIvLFy1SZKYovhaCyhJqqWtQkTtiMdJhVMLLEiv4o4QkwCc9rBYzLA5dD usrRmBy823SFP4k9TDoVHy39Zg0E7xbwfU7xIyK61zSxiQKxEvmkd4J5J0CnqLyYtwnnQDLTRAAK RVqPCQObtZgxTN/xGYFMV4t6e+4JJNo4sgqWocaOWUekJJni8kNhQhxnImnEIUQ8IpWwtilqD6IS njhrAqz/MqHApcfexROGApV6DHOceSXCDGYnTJlT9lH7PBpCUFDGraL5hKvcewwOYHyBq9wS47fQ fXexdLf+aFaDkHl85daHD8TIN1COIvt0F2pcqmuG1tQOBK/PjOG5xWo73Mo8zBAV7HiYKDM8yVsv 1F1MgVACmNgJOhItbnIwDQO2pSIz8ZuQn6kBeQuxxMZLjVjakT02WiPSP5N8qgu2i1bBXYTx1h8N vFiTJ+09zmdwU7GovNKEHLZK8A5WxC3U4T16K8CnWqFuKa8HXvFoNOSswLfK6XPl2KmmZrBTG7ze PoOkrr0FmaSlTCBfp7/ypGFQHykQN9CGPMy01QMePJpQcnvGnOAmvBXEX6Midf44XOLhc+SIXPEG R91UlklJGbLlKhO9Ko4PtVaqdDYFHY0W/Vtf0XwFRAgliX2OlPFWsiEWhMZGUNTRMa+TKWGp1FTj jHwZ83IpZsI05QPd4yWDEGQrvuGEP5TJDKSF7/cCmD5Rod46xweDHT45gX2MkhLzMnvGT6qmDOWt RKRs0CpXD+MjVpH4gV9MjLleYEJAWf9I71JZUDYUxI1uCXu1DloslqqxVg9ZBALYZiLQt1ILgXsn ECAtwL4s5tOlcHcRqVA420nNUjdHCpu4dw6cIY/QZzhKHTdaTcM2qQQ4YRvEjEsllzox9Kb/YBsz QeVSOubyOC11dYUaXWaJMrNEnVWkzS7S5haqc4uUbC/LLSrNLS6eK0dkpkiZX0w5xDGnWJdZpMou U+eWKutq6qnlUYfX4/Hy13iCnjHrBzaMW3CMVpoqioqVhWXajOySrNySvEJlXmFZXlEp31HA7OKy rJKy7OK5VN5pIo/MpxeVZRaXVlVVkfHGLEyI+ijeCiK2AMgM9xKgN8d0lU+ebio5otTBkkEf0OXU latKipUFxerMnGLgWcDAJDlhkOIIMO8BPDNKSjKLS8yVNaOjtCSZ9e7R6RLfzQJNQrBc0zinBuZM YkF/4WmoTfYFUqYBMMnB7Wlt7igqUheVGdCEM4o0GcWqLFRNwRxrv9OWZ7RHXVaRLrtQl1uizy5B ucqzS8sLy1QDAzYf7DQgRTVDjX960jyTCgjcc10EYAg5RjMzsw8cPnbw1Ln95y7tP3d5z4kLB89c Ongy5dDJcxR4+sy+0+f2nDm373QK9v2nkqe1Hzh94br7tBKZLPK+08l7z6TuOZ2y69jJi9l57d19 E6X0tTiuQpnSnBHz8hThN4PxODZW29wckbAqaOXqJas3LV6z+c3VW7AvTdq8dNW7y5I2ifuqDXQy F45Jm5au2rRs9eZlSZuXrdoatHrrm6s3B619d+nKtxSKlV3NHZx5oZaoB0BOe1oJjG+8ttY3BofJ QxPWBSVsCFn9nmz9jpDEd2lP2hSStCE0cQOOQODNNSz9uVDSGeUB4ASt2xKy9p0weczgAITHPeYd dY6T69lPbKCmIDkzZV4vXizjqTRbFgeFBscmLV2+PnLttvDVWzmYXE4AJqTlXsBz9YagtZsWxSeu fHtzmUoPs33c7cJYNhsQIqcnUKVtJjYMv3PaR3Qb8FDaaUBK1AC1tfU79334hiwe8rw4adOSNe+h LQevfT9s3ftzpeXOVJ6XrNq8ZBU00vu8sb+5+t2gVW+/ER2/5+BhzryoEVQAmBcDHwHenbY83b4b TObKZbKYp/7wys8Xh84Pino6NO6poNinlsQ8/abimTflTy+RPxUkezJIjh2BbFc8tWQa+/yg6Ovu 00pksshPBimeCo55/E3Z06+FvKZYkVlUzps2nyDKbV2EMAGjzh3bmdU9DQCZ94yZzkgnq1T1he// vyeWRDwVtXpe9Pqfxmz4afTGedEbcP6z6LU/w1Gx8WdR7/wsavOcOCqQt/WUT/n6x6I3zaOsrp8X s+ZnSyP/70+f1qiNpBupo0c+QPJEAZtxYXjUmVWq+eL/+a9fKFb/NGrNz2I2/UTOCoWiKTY8HrXh iaj1jyuo7I/GbJynQGHnTHmnmxPFxkdla5+JSHj4G/9SV9vEZwtASqCbSGboj8SGQcT6BwyfacgO SwN95t1HTv3jfz3xVOjyn8lWPxXz7qMRbxNoVDsbOKRA9R7A8/GojfNkiT94+fX/fP6lnQeOMYYl AOFnZmslfKiKMJL+nxaYM4iMOuQ7VSVNchjDsNq59MxfvxH8g1/98ZmoVY/FvPWzuA0/Vqz/SdT6 H8vWMmH+yMpz1Duki2IhV7Q/qlg/T/HWT4Jjvvf8719c8CbaOVEu+XYIdr4ycQaQBm65dQTASofP pP56UfjvoleH7D/9yu6TL+89+8q+Cwv2XXxtX8rre1Ne25eMfcF+7CkIFHecT3l/dd+F6+5TT+HG Mf+yN/n1fWcXbNz7q9DYvWcuOsEevnYNfCBrnHlxwuRtBi0dt5ALHssukVSRseafHn/h3TzduvKa BHXLck17vKYTx5Wa1pWaFjqqu1eqehJUPXf4mKjuTVD3Xn3U9CzXtS1HrpQdieou5C1R156gaUjI KHnk+T+pVBYmQh7n2Ci9WoOBBfRsLm+Wzvrt536/rsSSpGuJ17bHqbtWaHoSaO9K1HSsVnUkqTuW 6zridF3L71J5bwvCCaruVbqO95R1//Sf89va+qjL73ES8wIK7KzmGXHQPCjCiokRA21KB0THbdB0 a/ccfmyRbFWOfpWqabmyFWDyfbm2a4W2K0lNqOIEP++W/NwmPDvX61sjTmf8JnLVriPJBCDEaswF bzuMGUKQo8raJDiAjfzOoElOCXweiR4I9xcNSYnMi4fvOX72jVUbXntv/wZlVaKmboWudYW+fZW+ G+INkbjDLfe2IC/mGY1R3b5C24ZjgqYjXt2WpGlemaNbuHnfM68sRhUQ/tT3F1+xTmMqge1uIIA6 2HYs5fnglYt2nlivboCWjjX3Rhl6Y4yDsbr+OG0v9lgd3/tjtYO06/qntcfpB667TyuRySP3xul6 kjStYSdznolI2nI8hc1lgXShlaFw1JWDcLGGzqVu2ig73Xg9JOvvYKrZmJCtq/vyvF+tL7Amqdti 9L1R+qFIw3CUflihH1LoBxX6fhyjDDiZK0e5eVButMVoh+N1o3KtI9o4Emvsjs3U/fS3iwuLDQwO QMSaIBQUOaIEu8ubrjZ954WX12hqY42dEYY+mXlEZhhGSbGjpHFMEiINgzIjFXNOlXeayPdHaDrf 0rZ/7ZFfNrYOMKbASjrGEYw1mOiAIOAvpaGxaUsPuwGgJr2//4mgmJUFljhdh0zbE10xCjz5HmkY itFhH2Sy9NHGU2HojdK2Lj5f+Mvo9duPXyLA0MukxePXogqRuyVUp1gXRDUQajLH0YqpIUMb7D2Z 8nLcusW7T60ztMbo2uX6Hpl+AIIdrbVNU37mUEtHztlOKggFiTGOQKLiDX1xhTV/eu/Qs6+HQpHx Pi9sIQwtcWSmCGMg2u1FAEpm9+m058JXvbzzDAwkuaU/osIepO0PMzvCjPZw347zMONouIHtdG6n c3bCLlGIuJuGw43YxZ+hJjvfZQY79jDTcCjbccITQbJ0I3767UhhIkFfUiwzPHEWmYebhmV6G8h3 yanCpyPX7jiTRtRBjYxNeBaZl2gFYkab+I//mNIR+pZaLLQv88lmaqq+Mf+lVfmVy7U90JmspK5w g0tmgC61y4wIGQozYaes4icL4aWjcFxl+8RVFmcw3DSIcI4SA1C8hQKNdIkH0tE0GGYaBIwEIB4B Bc7iIBqdiPqcLuEuyol5BDEj9S653huidaLiwJjyLOOPf/tGcbkZEKANcuYlmJh+sjvc6UrDd371 5yRNY6SxN8wyvMzkCDWhpmhHkaP0dlAwykjZ4IVC/iljlE9fHnwZMLGMUSbF7CGOdC/lkCfCUuB5 ZpkniFjBCbFrUub48DhiNIYDB1y8haV8VUweWcwk5dZqRyf0K4++0NA+SOKBAX10fIELoOCA0NIY Wtg+M+aF5CC1dXs++MliuSLPpDCSGRNiJDz5zmoHFUTNjdcpx4dn3h8EhoZUZBFDsQoI5EEReVHG CAR2OxWZ4cxDxHAJHF8cikbCRvVIiSMcCfoyQFdveo7bo8z9r54tfka+bsfJNOpo0hIt8B7aD8FJ CHNgqYnOHNUpNV0WSZzVz/u8cDW7yOe6//TFPy3fuGjvefQNZcywBPIRekeUEQ2ZSnolXNeGiO2L YSKBzLGSjoQzl3k/hKWrlCZrs762z1qHD2FKk9cCrwKcT7Q1v/qlGp/4iTTtchNp2nCdPcrsDtUP y/UD8oLal7YceXpBiAPIo/BsAR11STDXHj8D291AAG1h74lzL4Ytf2n3efRtqRLNIxHoxxkdPj3A FYKocn0iZJfpiWu4eDBuFQkUzZZpAFGNBJuHgyz2YLNdoRtV6BA4FGwZDLb0h5oHQQEyvQechQch PMzcH8rDmaKmlI2ctSllxOEyBrLjksZFEdKIcPSIF58s+nk0Gvt5lMgnTcQiEDD85DsB7Ls2A7B5 Irlay1ef/G1ifjUeytBgRgiYlwCh1oQ2i1yFGomOFdQRHkL+gUCoeQg7ZxBWHCIvmA0Koy3S2C+j fShS54nUeZEUCI6pZTSrQbqKlH1mT4R1MMQ6EGQZXWYm9KCx0eWU6/uiDP0ABz9BskiHEkE26InD YYaRCJMjTO+IMLpRa+ihR2VZH/n9awVKDcMDY71+uIwLdoczW234zgsvJWpakQGqIP50A6tlIzVt at1gCuhnM3Ybqo9qEI8DL+tcURqn3AARGkZ1o1rR6YYdLtcNyXQjcoMb2VhmHmWCwS0xVPQwbg83 9XP0kAgQYE+ZgJSlDCkaVejdkQZ3iMGJnaSIWXRAXqEbjqZeOWk8sRaY4UdmpJ8lCTBxCwOKHY0O OHu/9sizTe3dE7LCK5sfJ2SFJGri1xTPYLAJwvo9Bx5bIpPnV94YT0CKmgo3OVH7y4x0RKlZhpl9 xXLOYEH4KIQKGC4xO9DKIsx9CuMAgaN1Qa4iSAIHAAI3CAkNM7PWiFKZSFDjEqmf6pdXsXEYhhZE kbdo3AuU8DhRzrk9jBRwLxDmtU/3ksLHkVCF/8cw+NqZMvR5t524QAYMhmh8MEqg+kKoeU4RxVuP hqfzDSeYsfnHFRsX7r0A+9nHXNTEfEUeBqTYIUgAH6WDnLP2S7YllV3vDtM7EYifiIMIEGk0xjCj C+ES5rCQqa0RhtRnIcSMdrnRA+mlcwM1fAAOsYfaJOh8aPOHBptcUCNoMhH6kaUmxxLzCGvOlAf2 XFJ9JMaMfOkW6FIoBKMT8SOM1DRQKaiOyMKml7Yc/fmrwWT5kIijK0HL8314BP7fBQRQFweOn/nv sLg/7L4QoycNj4Yv0w/JjSNMVKiDQ4IHiSJNyO0rEkUiGiII0plopzhhMYc487IGS5IG5bDMQhGg jaETIKs+5oWTFvrTG24AfYyS8KMfZwYvQ4yRvkS7RL4scSZmYJZrmBfPhadu8cliMO/Ok6clqmUk S9J1TXufCc5SIrlaE2dePFQsNfLP0GA5p0ZBxTRRMwQXKBjzLrPYl5qHloldQsKK1BRrNXKoO5MN rc/HvOMM2FFqdzBfqScLivdxH9q42QaglpldwSaRedGHpSaMI7XEUU7faINUNWbCkzHvSKiB2iOU ABq4j3nVzFBhE6skVBjz5qh1330ezNtGlU48S0oJ2UCRUTqef8oV+8mKDIUwiN4x5IfXtUznYAJA 3IpaAxQor9zgxFXkzY95ISREAaTliOXFqse9hA/pItJvRM0UQsyCFGCzhRo9DGQSM1ZMPMIerRmB 6IJ3YECGw9gwE3nxHQKMmDzPrERioaCpwLxff2R+U3sXMQU2qmw2vuATHokpuB+ax5rqkTHvht37 wLyRBVUooD+eHECeH543OpKWnsg2QgACKVhxx0+Kg3IBRuzgCJkJg0T9AEeh9UDxhhpJSFBTYjtl ksAqbjjCYIOkMTToKdiRFN8pfSNZUGi2wBbg+7hAxA0A8h2yxE8m8kyZJBZARS86XfZ89LptJ8/B AUVre0nZMyhZt3diYdFUEby1eHg626QmjNwcPHUGzIv5J3Fabj+TzmE4i8YGIWBmJdJT62bVwe3Y oQjTCBQXApmsDnDmJT2mhzbjvi9qKSHWYTQHwlDroLagR3PgaJP8A3CgTc5ho43LKrVKHWtldIkA B+1Ch/B2x9sLq0FRQ3LkeRthsgGRcIUZPJBnau84krT7mPe948+9upQQYH3/Ceb1gXNrEAfunjYC 02VeiBlqH3VKgmdwQWdCPkmZoL8mciLJMJMHrj1IK5LAMMmELOEWJhJopIx59ZBhL2x1SB106TKT F4SCaLQzgx+p8R2CyoUNR6QAVQyFgyN+zinmJSvCiIyRYkSrARQgjhDLyBKzE3QJ7kAT40XgxWGN muIAW7qqgzeYznkKPJwjhmQBAmxgRCONSi2UWAnmCpo5M1GgQlEvHjRYup2Qp8zMKvOKettI/SxS SkaHWPukalzBRm+okdtXlDF0DVB8KAqqPrKysEPDeMIMXnTVQanoEVOIeTDENIBoQEOO8hIjkBSh UKSL9C44BqFbUGQYM8uYKULgaN1yLXXqiQKQDaMTO36i+LQzIwHPZTtZdDw1pDOnmBeZR7XCfog0 jrAic8uTQCPBYD55Zo+RAwE7q19bhGEABnMU85lAogAL4KXWwbwxTOdTClE6W7QWA5qDqCN6EFk7 xMKoRCQO4w0CA1OZsTniD6HH5N/ufBIrZon/lI4E+0eceVEWVl6oOGpKMGKjtF6ZbhysShjCkoEP CrAwmwQn9BNmM4SfIY+GiYpDICwfGNuAkRhW50DVkAwzgwrwomoYUPYYLdo7hH881DBO0XQwj53U HMhjBkVB5hayBFmFmsWR3wVtiQcxHYiKIJZnLY5rRTt5twLMO20mvNM3zIR5GfFxfQvDGExKVc/U AoSW9Bvrm0A2ILo4J12B1m3wQLqghJkhxwQSMklaER03D3nJdHTOFTVOSPZYK+DKgTUHEjOE851n gMWZQ8xLudWTh4qYxYwMk32C4oMEl5jcsCvALAqDA00YERhW6NtS3w3NiriDMAGY5LHnVxFIO++V MOaN0DkZSRGDRxhsISa08SHmuYXpQkYvjqwXKbI5MkMt0TQ7fV4yLbinnfJP1Y1euX4IOwqC4qPS g42od25NUbXSJQYIlDzEhuwQyAlTXNBy0HUoLBzUIeY+ggJdeNqRLFkRnC4RAZfwIMAoMS/OuXVH gFME2vntiMzkB1YKp10ciXaZKLrmGvOypjSsYA0KRQ4xwlVC48K8OTDzhhu6ZN9CV3NLhpURcLEu kskBSw92aYhxBNLCjWQUE/5/cshrmP/B5zsCsLwRRRE7EMKwD7HjBNVE5OJn8SImwc41ADvnIfxI 9fXRZ16pxQE3DP1E6sCJxLwAEI2INXCbj0nJ1GTxqSdCrZKsSu6+G3zThIEAJ6lHkyPSBFMK9UV6 jwwbZnMiMg0N6LxheoGYlySWxJKUKnnMMKpCY1XAlkxE6mJQjZOqxF16Mq1B7qwjA/qmNkLibUaX 3EHtPdDnvdNcOr3nzZx5Wbsj9QU/IZMZ3vYZOYoaj5EO95eCj+CNGZe6Y2i8kGGiJDYSB9Nasq5J gDFQSFYlTG6Mg5AflRQvp10DWsE4mkOUdjxG44VvDfI8d/q8UFPUR2P9XOqSM/OVl5QY1ujFNCfG vMTFhB5REvUKydjgO5kcTLX6SIeA5d5sZjNzvoAWpREBdK6ZZmYNkNMu8TizkLl9Tn2W2WNeqItY LdUCHgGCgJGPHRoARSbj32DHUCzyQ3a+2CuHrhCdFcgY1AjMftABqhsSAu+HyLxs3IFEy+QO5YYK hikxN4C5BJE+KIlRBrn+8BPdXnLmwwNjcQMfDhFG3NA15sSNZ2Hnt9DtxB1kxUFE55S3GYixkUHq 3nKxQW5RmyhakIUIkUwXIw1zQyR8bY07CtApwwjvEGbU0PAEjbyTexOtifzzrIfLkCH3AlLAmEW4 ZYD3y4DMRPeK0INMit0uf2K96Tkyfw8wLxcVlAVqjVlxogMZXhQEMiki+UGLw0QL2NJM2OzgO/go cDXMQCYifFBLzSOwh7EDZFQiLkEtQBpDdXZYRCBf9HyZcejCvex2SgFqgfkc2Agvs75wC0Xjbh/e E2faAK2Dqs9CvAzmRRWjjxNmGqQWEWDe6dHgXYg9E+YlvUcGGHamwUhEfdRA2gA/mbojgWGtFUoS 402YO+ThIXQXU87klmF2GrhVmiBEUsQESWJeRGPPok4x9AaYF1Yo+kdQ+Mz8m1vMi/aFFso6aDTP iulDPkhHgGBdDxoRayOYquEKgXPVAMahQSIUjXqsNOJJ7ZTjgKQwbMc8UcQjaFM0xMZGTmFFA14O ONMSpCiYdqUOC4tD9gweRy1xdvq8KFG0zg0CRZ6l7hKrXEz6GojUDobrbCGGwRBzT6ill4Zf2dA/ yBckyLQ0MS8tVdPbkHkUn7gSGWYDu1QWvTtUNxqiHw4xYNpPHyakgVzoKo1fU48MkdGJDjYOLjUN LjXaoNPQxcAMJQ4Isse0JSlM2plzlZ1P6NW5xrwkPzooT2o1UMXkczajA2vHHBv0fKkPC486TU30 wCyRSkp0acDVfpm2K1LXHa7vJ31O/VwndDL6uXKNLURvX0oSQhxNnihTP6luzOsgDU89MmJzJoQM N6kVUz93KjugZnX6ER7nRTGZwHA7TfSQQGwgadQM0RgZS0LCIWkAM0gHrw5apW8UgPkHoN8ghBEw Qc0OcvvDf6WjtiDX2ZhZRY8ANYNhadKjFgLcSwv32L0wL9kwAcxCtCl6LtcDNE2CPGniGBZSYOzv 80JjlApiQ/PS0VUJMO9dYNLpPnK6zMvscKhNnxKDKoNCozFfPsGAXIVMdLkAk36DcQgVijiQDQV1 Y8EF5E3lahOiDl6A9wYTX8FKMh10JvPQiunwJsAaPuvxQWlA/CCWjL5JCSMDc6fPC2S4jiI3FC3n ITYEb0ZpR2I1fTHq7khNH6lHmjQF5vWE6FyRWptcOxipsYdrR7EWIFRvC9UPwo3MGRxdWuyR2uFI 9aBM3S9Td8vVHZHazkhtF1YgEg6YUyG6uRhWDCVeCwxhwmf2mJcVltMof5CHuBI0qu2LUHUht5Ga HpkGK1ibZNoWKB9AASYNhxrR9WLHqgfwJi0YNwxASDCbFzfKdd3QUTSCqbOHqe0RSmeEyh6h7g/T doJWIvTdGESD6oPAcEwiVD24ih34RKj68BR6kN7GVJlYHdCN+En8IrIM5JMMIexzinmpObC5VSBE nMA9ApUbgbl8GpSuV67qjVL2o9QwRaDwUe9wfWC4YYmpDysBl2mwNrkXmAOQMGVvuHaQZMkAGG0K ZXd0WVeksi9CbQvV2MKAj7YPy4rDdT3hekoN/gFyNNHUNS/IHfhjODhGZYtWkQ9HatFctm9wBMjI 8Ed8hhVMDigc8twus/YHW3sxew2eN1414ErgCegIZ2V/hBIttw9LwiGcYboeiDcqheoFBrZmNFI9 ApmUK7tiytpjyltZQ+iK1vVh+TZQpcauGQ5RoVLawzXtwbqhZfoR0DSMTFQKBJiN3YOsycMco7Xj FtRmiMFGZhVbWIFWgB0ZIzFmzEt6NcC802XBuxH/VpiXdVQHQaZoa5hWCvGAeYZG6t8woT34jCmE RzHvMfq2EA/qfRiInaE/FZrBaHW/QtUXpRqEVoFuZPxFEkX0SiSLnQbveMpM3miVBK1OstDUxDnF vKLFa6JuJm8U6KRAgyWWtSaW1ceUNyo07VH6bgz9gDTBtjHKjuXlLbHl3bFlvbHlnbHKtmh1Z5Sm K1pPXmsM84Ua+qNVffGl7SuLGxKLaxOKqlYU18SX1itUHeghwubhznmGKnzLEqeQ9sCOkNljXtQF FBR8XOiAw56H0g7TjkSquqJKm2OLGpDhVSVNyPPKInNcUUVsaVu0ciCqfFhRPhBf1hyjbIjQogi9 0boezPkhv7RuKFrZGF9et6K8M07ZE1XeE1XSk1DYl1jQuaK4Ka60PkZZF6VugV5CwaOVQ7FFXTGF 9XGFSL8pqbg5qbBhZUFdbHFzdHm7Qt2FlVYAmdk/JEjAAXhKO35ycZpTzIt8hljIPy+O9BkceCVC ZHknFoYkFjWsKqxPKqpfXtoMHQ7di54sdHiorjNY3RxR0hhdVL+ipCGxtAloLC9oiClqkpe1h2r7 Q9U9sSWNCQW1uDehpBHnUaWtuASUlpc2oiJA6DIa/KUBxAidG/Sh0HbR649K2xNLu5ABJlQEIEfs Bsd7gHnRmtD9Rxn9mReNKwJj3/AqqAciSztiiuuWF1UnFjQmFULwGpcXQ+qqY0ubotU2uIDAlVBl 8sLuWMhtYfOqwob1BXVrCqtXlCJOTVxpQ1xpR3Rpf1TZoKK0O7a0ZWVpXWJ5Q3RZS2R5ezjsalU7 FMJKJsMwkKAPwbkw3eWaYZkG5ne3QtUmV7VS/4V7cujIdSNzBAWY924w6XSfOW3mZcuOSJPTyiOI hC1a0xtX0pJQ2pKo6owubQeTQnsEgz0tjDeJGog0yX6D3WiCgoUMj0LNYtBqqWYworRVUVgD0V1R 3igvrIbijVQ1LCuplxl6ZOaRpfBVmt3hFUIwm0pNypPNwIQJylLD8k8Sv7nGvNTREFlvWG5yRWhc YQWdW4w9+ys6N6qq44ut8vIW2CEYrYso6cHrpPZZ2ncau98uqNlWXHXA2LJd37qyoBZcDPJF/ze4 rO0tVec+Q9cxbcMJTc1hZd3u0tp1adrE3MoY9F/YaCb1biy0HgTt1Oempmnn2KFDZo95UUyY6Bg0 jGITL5GNoMKmyFzz6mz9roLKC8au9BpHiqX/hLZxW6FpVbYpobAxPr/7rZLug5VdOwy1ETkqhbaZ /NJGZ7DGvjSvYZOq8pCpfr+hPSnDArJYnm46WFRd0GBLqenYp6l6u0iXVF4XUtgpV7vi83sS0mrW XS4/oqnKbBy8XNl1Vl2xt0C3NtOAG+OKG2O13XIsrsEMATNf+UuOFzYOwjBhc+Ph94b/cO7MbUbb QW6DMdMGbiKLG84BOV5rk121Ist0TN+aUdN7sapjd1lFQqEprrwhFi2uvCMyr3plnnVThibZ0pZe 13PR2nZW03CgwPJehnpNriU8vzkkvykx03DK2p5W155S2bSzxLImxxieWRlf2HDQ0HxA27gyq1JR 0KxQDcRY3DBpZJqByJLad0zNhywtOw2tkcUt1O7YKCfnXCAGibou/1JjNNhfP1X6q7gNm4+cxKoi WkHqex84XqgBhcNXFdGbWGll6eyvKmULZ7CaBv+xVAwvbcb/AydPT7aqCP55Yl7yHWEIlTqV5Ccx OkPMmArlCM2pW55tXZtWerDMnGLtSqsZSKnoO6Kq35WjXZ+uicslGMPVXSFFdYo089vZldsLK8+Z OxDtUlXvB+rKd3LU6/LN8TmV0XntiuymDcU1B3VNF6v7Uiu695dZ387VyLNNa8obT5v7dhXWxBfU LitpBOmjlZGvu6wvIqf5/YqRbabO5flmmbId/RcFuRxpVhX82yQ8mN/Iaicww4rEaw5vM2BeqHo4 DOXWUXQ9wlV9soJGyM+Ryq6dmoakghrYz5ABGr2FxFaMhsAlCHWHJR6mgTBzL8xIjI/IrGPLtPYQ 9VBoQXNMunG7qu5Da8ephr6jjf07LK1vFZsTii2KwmpYgOQ5wZRgoxsdZ3R7OfNyfzVMPjhsIZMI nFPMSxoJzZYNhcM+QZsNVY8G57elDgkVgnCxtfedUiNs5khlT2gpmlL9Xn1drSCUOoT9qsa8xr56 Qcju8SzP0CVpemOxmgB9lpLmAzV2xBkQhL5xoU0Qmtm+o8ASlVcXUtYjM7nC8WINK81Bgr3NliqQ 84FPwKD2CEtpdsZ5gT8c/pEW1CaEoT+4qDEy37LHUKcbGcOHf7q9QrNbaGZ5rkO5+oU1uRVx6fWH KlyNgoCS7ijXy9PK0ImA425pZu3K/CqDS+gWBPOI8H6GZkVySdGQMCgIXW4qdZMglDmFtUUVEXmt EdltKy/WXKpxdOEpQGNcaGUnHYJgFYQjDaOxedWK0uYYLDiiGWiOUAtNYCPPP83+JeaFfGKWC8ba IK5zinnRQDA+KDOxhZmagSVZRKx4vzZK2jsutGCHFPV5k0qqYkvqI9KMq9O0ee0uoN3iEFD8dkHo FIQeQWgcE05WdMszKmKzKyuB3jhdAowA6qilIza3FvZJhZNiptfbVmcY40tb4dCGKzVU2bVc1XCh 3wXASwa9Ebk1YVpxlHMqzIuqXHxW+UvF2p1nLjhEusObrGhdL74GjW/FgnkpmF4oKa6fnl0FiZe+ ulyceUG7eDKYd/+JU9dlXrRciAdJCBvzgrcNIdBgEJulWvub+S2JOdXHjG3144QbyaRXgCSjarCb XcKqgqaYso7QPIs8Q3mxdcRsp7rAXj8mNDABRuT0btf6woqQc5pTrYLRSVdxb8e4gBos7RmVnS88 WNXXOSY02oSdpTXoWS/NrYrC3EIdjUmFX6rQCgKEYVOBHuKNYQgY8PBLU72w4QlkOMC8sytOtyn1 6TOvPcLoDdY6ZfCJaQeitEMhFw3qEdJ+ml7bsYq2iPwGsC3UGoafQM0wFxWY7qKzYRAEPbIIqwNj GZhaGVbcK7tcvT6jstZFhIK9l0kg5Bl77Zhw2NydkFezAsNbupFgTAisGIf/jc0+QrsgtkWLoMFl TE8yzKEZVmAiGMzoOIB5yQ2LrgFGujX2ZQUtGzUtJSNClcN7sbo5JtOADouspDPovLJ8xANluEdd s/5yaUF9V7VDSKnvj7mslpe0wNwN0vUsyq3aY+kB2zYODJVZq85qq6wOQqxxVFiZrotRdgINDKYH WWnOMDq8MRo+l5WmPCEcrXL2mJf3C4INNryZJ6SgQ5ZuOlLVgeKMQOG4hezKrl0lNbvVLZfaXEZB 0I0L7xRUxGdW79F2gU/xhu2ecWFzasHK3JrQS+bll5Ql/W7onyFBqOy170jJPVxWCeUGvXSmTHdA ZdXgcxWjwqbi+ojLZijA4i4BCqpfECqGxk5bej4w952sG1QJglIQPmy041218pImqCxiWJqGSlN2 OfPSiBhNgaNllXOuz4tcVdgwVTtcMwILKrKkJzqnEuYH2pelve9UbtkZS1OZR0jtFd4qbIi4pIFv odEr2ID2uJBV17tbWbnP0HC2rk/lEKoFIbV5KPpCSXqfB6hae7v2F6uPV7bihaHHqgfAyPEZptpR YWRcGBwTzqsrYi8Wr9B2KAwjwaVdcECldNnbx4TCpi5ZhjVMbePzi2BC4+TGfd7lFhfGeX8euRrM O1mflxMydBgR4ixv9B4Ptjnd9KZifMgbr0s9fI7eYXXtmzSosbA34TD1wka4DNwD7wxW9gZd0qc3 DAFqVIdhwHXWSh6Dfer2c3V2o5tMvnXazujcmpgLhXonMSns5NqR8QvW1h2lNbsNbZd7XCDNEo+Q kFa6Pl+v8widXk9tb+9pdc0xZWPrmKC3CSHHc45V9w0TMkLTkPeDEnNShiEKnV9le0h5e9A5tQ48 Lgib0wpiCmvDtQOYEBKGkV/q7Y6iTwQJh6lP7T2wqkis9jn6b2bMS90HiwvdsbCi9qhUDaxrh0DN v7C1T3bJgFkuYcaBSCs5ytAbBTszzyrG5nppbAK+LPWgIq9pW2EdBBhqtt8r6NoGUzTV2eZ2dfNo s4vMyJOVA6vz65ar+9gaHDdWi/gxLzQnaNdFL43BizjmEvPCKuDMC9ol5oXzB31eTEgu64xIMxy1 tMGusPTbV1wqxVitIqc6Pl2LLkzNmLA8OXdNmqqwoQfK8GLjYFy6lpylFejyDy7Nr95n7kI0paXi g/PJcfuObThzuc/hGQSR5Zvh6oe2hD2DHi58yxiloj6vHsaJuHbmDjAvion5JEsv1h6rsZkdpHMs HT1rj6UuP50H15wiu0KWoo27rNuqboTDOTrdcsjcZUeDwPfJoUZsQsSBVNmH6eU9owAH4Xive2WP 7WBawWVzM7ppR7MLkw4cSTifFZ1ctE3XsTLTlJBjgk8enNvtEc4o9TFHLsSkGqPSqhUZlqCzxW+V 1a9WNcUrm6I1XTBdMFCOkdOlWCPM1hBBWmiolw2QgXyxg0fmUJ8XJqt1YBmmnJk80Sq7QtkbcVFX PkwGxnv7D286fHp1SnFSTuWaopblWTVri6oyOkdhw7Q5xlcfT1uZUgaLLjxdF51hjEpVrUo37NC2 hJzK0+DjU4Kwcc/2lceS488Xb8yzrM6xQvaQTvUIoQ0TCHbvzkJlXIZaXtwZUdIdX1R7udPR7RrX dwxEZpjDNfQ6We5wBvNyicLx2p3kXz248EQxvM3bT50H87KPPlOfF5/6MhgMNQ31TvpOL74aCN1z J7a+nt7c3Fyid+ZtxhHd78m8zWRJ0vo1/nYRLEygMtLYt3okvKh5fWkt7ECI6DlN5dtppdEXSxXp hsScuqhkXeTZrM26+sj8mtCL2rTGXvRk4fDJMlW9k5obey43Jtssz7ZGpCplqWXbzV0rs7Q79DVg 6ur25lMXU1fsP7PqTHHSqfxjFX1hZ4uPVvV2Qp+OC6Mg32HhtKE1KcsoL28KL28ITi7To+/sFnak 5cfkV2PeHWiXxlOYnw2zLGgwJcC8d0KsbvUZ02fe4TANVit46b182t4lF3UX2pxoth6BmlPtsOv9 snpyWynbw5Rt8eUdUfmNESWdsfphrByRFTVjEkh0Qc3SywZFannTGNGupsP5bpoyOqUY6iI61Rqf WrHysn6bsWOtrhO9QlA2ZjXAVQjNCemidk0vkKG1JNCf3CM0R5nX1+eFYsckH0w6Dc+p3qZpha5r dQrH9bUJFwsV54tS2xzoIWZXN8dfUkIfZtf2N3mES00jiovEvJjEGKzuDs6u/MDY1ToulBqtHySn yvd+uDElY2h8vM8rbMjUxZe0xKGXbXTzldFoepgqQ8wizmEj79ns9XlJ95ox93U4stQmv1ilHCQX XFlr55aMgoR8SxR6napuWWlXZFFHRH6zoqQVL2/HzKvduibwRUdnd98oM9iqOkqq2wa8Qo/LXT84 1DjqrRjxbr+U/2GeEVwM6dp+LjXh5KWVaeUrCqrCLqt2GhvhlEbxCytrEtLz4sqqY8p7Y8oGIgub 48paZUUNkcoWmaYTHV742DFriybDm/EyPer+Aw0SHmkHC8+td1jh7Y590ZYRmWo4onwEU5SDMvVF zANf3TG46eC5mOMFcdl18rxGeVb1e8U1cAg3jY3vzMxdkWXA9LwoTU9YeVdEcUdkQbsiv12e0xSW Xp05RCBXt7avOXgx4XT5qlwME9cFpRrW5FRZbd62kVFVWztwhhm8/kz6mvwW3BVXUHmxfQTdYU1d ryKjAsxL68cNtKAVQ88k0tejXQbvMCYnBCVr8PbILcdO8z6va9RZVlj6wi9f/Ld/+7emtlb/t0e6 3TC+ZnfraGt/+umn58+fn56ZYR914HPwYOBDp89et88LJeOzmWliJ1EwFskaRuSq/tB04+VuD6ms mtb1aWWx+RWyslaItyK3bWVhO+aoxGhbMNqyNFlZ7yHNdlpdsS5TLcvQx6pb8cEgWUkrmoC8qA3j 5mgFq0oqVG4aSanr6Hr3ZGZicmlsviVe2bjkohreZtiupYa6xkGyuGptwhFlrSJNqSiwBJ8tMGFs xSNsTc2Oy69Bn5d8aya4mmkZHX+tCqop0OedXZG6HalPl3mhsmCNYz48RqOCipuXnSvQuUg3qkym 6uY2OA8v1fWDVePLW+Dr2145dKZbeEvTFVvcKsupX6vuOtZkP1w3uDzHiMkbkLquUfeaUznoFkWU NWARYjy+YVfSF5nfEKfuUGi70UFGQ0BvDn0W7mfG00G7bOfMS6Mw0AZzapwXnVzkCs0BjQJudrAS TXLWDy7Jql2ZV3u5up+GhAYcq46cXX0uF44jtLJtFwui0wxx2RW5jbYGh5Bc3b8Cdoimiy0fGJTl 1B02khXd0N2vq6vLb2xD/xf9lLrBkZWXlCs0vXIlTSqGWxU7mJdmmIsLV8k5MMvMS6XDeJOstHdV QYuuX2hxC2dNtfIzWbLSJqx7Qk8hNKt66QU9HGURGabILHNsQc0Bc3uH3WGsrFy7/yyGJiEJsPHR lfggNS2norbOLej7Xe9dyN+QXISxM+ADxIra+t9OK444X7zsTP6RqnbgBuHZei4lOk8bqmmPxgIc rSvO7IjSDSjMeA/2MFZQkj3g5x2FLKFGqFLYcmlYbjQHFTMWDHPo7ZEkLbp+mrho8GDHz+DC2jWl JpQXSrjDK5y39q3JtkZnmaIuaw4bWhsEwThkW3X+YlRBNcbZw5Xdi7NqlqSag85pI1IMkRdNYelV 64sb4DoAF3SMCRfMAytTyhVpWnmmBf6HymF3dZ8tfPt+5QD1nVu8wroLytgLmsRc8+W2EZtT0NV1 K9LI20yOAual58w7Gfkiw1jpgD7vL+RrwLy9IyOZmem/ePbnn/nkQx974K8eeeSRBYteX7j4tYUL X1+6ZNmiRYuWLVu2eJa3oDeXzJs378EHH/ybT37i8SefSLmYOjQ0ONl7m4l5GZfR6kVQGL7iYemj RXBl5HzQjxOMhzPzE/OM6FyEYqVbSZf8coXsvHrJmaLFF8oxJv5WnrVpxN3pcG3J1sRkWSMwP03b F5RbA/s5JMW47Jw6LAPTM6owUnChwwUzFbC3eYXkmp6wCwXheYZlGdrdFd2NbuFUpupwvqmkbRT1 3uARdhSbY5ILYs7mGTB3wiO8fykX7QgLx9ikGnrhDGlC6pLAOxFYz3s7qHGW05g+89JChjBl31Ld QFBB9X5TU924YO0e3nLwRHqpGYOPlkHPpvQS9E0isyxHqgYw2HSu2b6hqDLygmqvtVfrFPI6R6LP 5J6t7sBQYKZOm5Chj1J1Bhu6gk1Y2oAv+dpJf+IrA1qYmlifDuHHfC2asycqTDbIS7Y3OZznHPOS bjfTGw94DwsLS6FFaXYTXgEBH3t+6z59TwVmwjhch5KTT5WboBKNXaNvn8uPzKmIya8qbOlvdwuX arviL5dHqdvgtAd3h2RUf6DvRpcEbDs65gJDYWAOOu29M8mRaTp6hNZJXwSDl8yCb16QhmQTn+6E t5lXCma5BxW2JBU3VHmE+tHx3cWW5TlmrOeNUHck5ZvSOkd0dsFkF4q7RjfnaGPTDPsNzUPjbmNd VeSHF7eVN6DDBf2TrKlac/RiiqkRA5fVNlj1pXGXylakq4q6R8G8KH79qOdAkXXlidyDykqMR7Q6 hI1nsuLLGhVWR1g5qAGfiSHkl2JhDtAw0ItHQKzRWH+EITANfbgHXRga22UvNIZEMc/znFvPq7Bg nsAIlpvJjWMoF01ZzK9MKjIavQQCsFK19x1SG9en5R1T1cBuKe/sjjt5PlHVjqV5oRkVZ3uF8lGM GLrN/QOZtS2YCRCbYXo3z1AxRgZMi0fQDbjhKYUB81a+wdo31DjsijxwIe5UfqWbTbGA2yo1Nyml 6GJDH4ZFDY0dmKPrz7x8nPcGfV7MbX7tZMlvVryDcd72/v4jRz78/vf+94MPfBzM+6Mf/ejx+U/9 4sXnfvOb3z3381+iK/rL2d+efmr+o48++gC2jz3wre98e+fuXQ7HyGTeZrKZsXQIn/TCumY95rn1 Rpr78LKLqOLeqEtGI5PDHRlZUcXWZaoueXn/2vKey+0Ow7DXNDyuHxF2K5s2XypHC7W2t2/M1Ydn VSnK+7GSGkNL6TZBPSToBz1lg971WbqYtIr49MpD+mZ1L9k8PWOCdWR81YWssEsF+2o6YSNdLLUk ns56v8yU29GFejf0OLedL4zfm1w5SjPl3r2cG11QByUJEwhGAob/6GgciDBjmUCAeWeZNW9H8jdi Xhq1F4dyaPiefasINhW9DUM/FFTeteiCWjnkBdseyyxauXX/3nPZ1s6RNsdYurV+xWWlPEV5qroX tnpqbefWfL0iuXSvqRNTg1RdNvmHKReq2wfHx7MtltgcS4imBypRVunAJD0MUMLCJLcV3r/B3nIP 8qXF4/j0DHvbJJ/PjAgsS/TKrDnlbQbzYrCVvwYBHS6ssUKJcMJeVmMPzm1dX96W2jAIO9ZSV1fT OwxFeqykemOWKSy3bqWyKbuhq8nuxXH5pVIsXMVqHRB3aEYV5puBj5oG+3TVZn1dO5p2v91zrEAV laGLxJp6LMmHT55GlvkSP9QavWME06vY4CbetkGv9QCe6I8DLurrZVb++A/4SiD/VhENgE1sV3yr qAO9GLA56zuzyVqs58j8iqJshOjovR9YZgj/m2F4DBNFzlpaI5NLIrHcuLx1dYEB41k07DUudLiE fdnq2FT1IWt7n3tYV18lP1csu2RKb7EVdgxvyjRGHs7MrLfVu4XKvvEdaeUYdozNN63P0X+gtII1 IGn6Dvvbx9KPqupA8c0O4b3knOjC6hBVd5yJPqwAUcFyNnhjyGDDu7CMeDsEvc0A5YULDkYCZ156 lSW9Uht9BLbOiHmbv/bo/IYO/28V0UAbNhzov/gPMPkjNYHZjc78v1UEDyF718rkePLXD6JvjheS uBV40bdygObaZeneytMmVzXBAwCTtbCxfm9O7ikVzUCzDtkTT57Hcq3Yku64nJpCN83AAVZOYdTQ 3rQytQCDjLFpGng+0+u6AGOHW8ipaUnKVCddLq4ZHq4fdsqP5cjPlm/MVGH+OdIvq2l672JhZlWr bXRY39wanSEyL3c4g3lJnvH2G1i/Pv0gnUBa8FGGN86UY4YVxnlHvN72zjadRpuwIvHb3/zOD37w g/TsLIPVqFarTQaz1Wo1Go0mA+1Go9nAd5PRYqDdaNQbTHoeAUf/zWDCLzM7+gdf5xwplxQVP/bY Y1//x2/ExMUWFhe1dbTjY8GSt9n3rU9aCUulwKiW3slezkmffMIn/OQmMK89sqQ37Lzawtwve3Ly YgoMeJtNeG7butLu8hGaUg7A0ZaT9c3bU/L7PN4mu2Nzrk6eZlyp6lEUNa8oqICXGASKho9hoy0Z RUnZNZGXKldmGbYUGk6rq+A2BP8qO/qWHkk+XNsFQUwtMSaklWPm/1aloXxwFPVibLEnbT3S7iK3 0qa0XHg5qHsCl7jeTW/Aw1cLYahbBmDnU3s3XedbRdD2fLgb3yry9/nfSHoD12YHAT/mTcXbDEgt 4L1ntBaGzaPwtSxGc+S3hBuTRBTjC0WdsZdN7V6aoaGta04t1RRWN9Tb7PiJSZhvncuPPVNwsrID SiCjofPdDGXkeeUuQ7fZPl7W1hN75GKylegjw1ARnWWI0HRjFhY6JhhO4s2ZJAcaXg/j00kzlEDH ZuiiQTh/0K2jnU1e8uXqzs1tBlzS93kBF+uMk03CR5yBHmdeUbHTZB7aoeERgbpg6r6o7KqtZdVo qt1Oj93l7nYKGy7rVxW2ywpaVhTVZzcNNLqEzLqOFSmFWPMLxyMcApiaddDUirnNRXXVpwoL9+fq 1Z3jmP2ob7ElppfJS2rwqo1QK72mEnqDAQhfAa10Zm+KHmcmMTEvoyTyhJOjlTFvvkpDjRGi5c8n xLzuHJUBXwlM0HRwpsBdtKNS/JgXz8JP9DGpm1/aFpNt1A3T+oiSpt5NaWWKggpZeaMs1wrv2XFd Iwx1TArdfrks9pJ+j6m1b9yha66Hwg/LaHhX379Z36vIrJed1abV2xo9NF15y6WCNTk6iEdIqiY6 XXVAW9nA5kvvPpO1v6jCMCr0eDzJKmVMemFYcTWNTWj6wpWd4ar28NLGSHUrXiuEJeTIMF6Ty99y DLJDEZBhXmuoEbzOlHaDGzOsvvbo0w0d3R7+qXCRZznf4oOm7IuBBBM2f6R4yM2OYN5xYcNu+j5v REENeUWYhr8GT1/7MvXTqzIrvEvwAWLdUIy6PyG/Aeuawy8qV+ebMhr7sJKlyu44XFC0J7sUJk3n 2PiuS1mJadbl+Z3hl6t2WYePW3pVXSM2YUzX2RqbmhuTZ45O10WllG3Kt16u64bkmJrbtuebVyXn Vw8N1bmdkWdy4nIqoy4oT1QNwJnQbBcKLQ01Xb1293B5c4Miw4w3X6F5ksHGfM7c7cyPpBP8dowH 4RPJr58ufj527ZYTZ6ENgB4W9VRaq/bs2iuTyRqaGhEy5mGfDgRyBLUIL0QR48I40veMvYAdi47c FAFxGfiMNXjAxJES8Nt9lYFqEneM88bGxu7YtVNvNLg8bkT2jLn3nRLX84J5USOMdsV5SmitaKo0 bcmEVxagL4B3ldhlqoGwFG3pCPFjjqky6XJuXKExLLcxuqBjt27glL7bYhtjzGvZcPIMmBHTwk+p rGsvlaBRRJfUopHuqOw9q2sm5hWEdy6nr8jUYqBWnq6OulyO1dZHza3g1ibnWOj+s8et7bZxMK8+ Mas6PLsBVbNN3ViHG11CocZq84y1u13vZuYoiqyYaQM/M174iU900RgTXi9pJA9bGPMWkpzTYmRM sGn6w5bjP391KTV2JuEeiXl9eAX+32EEUBf4Pu+L9H3eyZiXeqA+jkMrG8a7HfBKwJDLFcerbTC/ R1xC6+gYqKTOS7YfZmX0OcePFhpiD6eer26HwKRVt27N1oScLt6qaaoc9Srbu+KOXoIqhgwbO4fh UYzIraK3RigHsBIQXTzMEoko78Bb19CK0ZsD/8J+Q7cXDYGTL2iFtRTxCz5o+HdgnBf1whv4zZiX VlRB5gEaVD2nXc68eFNcpGYA86wwiFbY50EbhIJR1rQkpptjSnvCCtsSCutzmgcbHN40S03csQsR 6bqQTIvskl5+tuCIqbnaKxTXN+/PKoJJs6u8saqf7Ofkmi4ZFoNY+98s72ZfHMDIIKZbYPSnF1YK 41x8oU/s807GvCRy0FIoHt/GrmZeYlu2sJFOQBykqUR9i3B6jX+FM1jVEZamP1/TW2enCZk51e1v F5iCk4siLqlCT2ZF7jpVNSy0uoVdGSrFeRVmWPWMO7XNjQlZVvjx8CYfvKRLVtwTkmK+2Gir8whm m2vr5cL3iyr3VPZFpKojkgvf3P6hxUErlfZcyMO8svON/dBUjY7hXSqzLLUkJqsCA5fIAFjmPVPX O8au5Zp2vGATsgqrIMLsCcYn2PyMB2DCaode9IeucaKPeTHdh2DgNU3/iXaxSyG3yLyY+0oA+vCk ljWBJ2NeeBjY9w6AaniVsEzTF5pbfbLRvbOsQZZcsuRo2vuZ6ophoWbUc7xUvT4lt6SXekP61p6d BTVxySb5RUPIyYIlO0+f19dgRFLf3hpxNPlIq2NzaW3cueI3D6VuySnvc4229PUfKLCuPV9UOTRs ddijUgvl+TUxhY1wqJ6ptoEasNxgBJOfxkaUzc1R6aZQ1WAUfXzBjjk81xIuSiHt0A/wib12qgjM u+3MObuA6eu0aNft9nrdY1VVVYODg+JsZw4yVvniZRqMfCeYF2/e8Hrc3lEv7kU0CKdUL+JSYLFC xDR8NYafvg33iLtjxF5ZWUlLeieije0/LX6f9wrmhWBDMMhOHsWiSGgbBZuJh1WN5NfNrt6rb4OK g7o7qtatulyAic0RKabQw0XyfZdTDLW4dNlatfb4mYLGbtiZ5m57mrXp3Txd6Nnc4NSyoGNZ4e8f Q2XVeVwbU1PX5up3WHrXFWOMuGDxh5nxp7KxRA7cLdt/7pS5vW3UdUlnTSxolpcOYF5WdKb1A3MP DQp7yDjpHh9bn5oRU1QRpu2mZSZ6b5TGiddLou2TX2uCeampXsu8gCjAvD45uWv/p8u83KaNKmyC J9DgEfrHBWNjH97/kNzQm9bpyGjur+x2gI7zahsTDh1PsTShFWdUdGxMKQo+nb3b2lRht5e3tMac +P/Zew/wrKps8fu7z3Pv993nf797v7l3Zu6dGYdOEpqAOo46FuzjOAIqIALSVUBa8tYkgCBib9gd BURsVOk1JCEhvRdARZr03kJC+vv91trnPXlDU7wIAc/77Jycss8+e6+99mp77bWXvxqXKxbIQGBq yvpJcfkYxHxrN49O3jYqcRNGyxeyt4/P2R1TcBDh7SlClW6w9kCHWiJ1a7BK2d1GbIlolD835w2O ZzNyE/OKG93d45mkjbB7UV5Uf2G0CmEXQyLiAUdZ1AONUjIV1HkxfhaUeNN2jk/6jthBQGZvVeCL lPynkzYRI3d4yk6WoCbsOLizvCL1mw1vfTX/zTVZr60pfCchb/KSlCWF3zPu8r4/Pj2xmCAbMavy Fmzci+VwS3Xg1eXpuGY9zdpqhF4TJkKMAwjDh30S2FPqIDaEoM5rYGhbm63GhXLe2kBZWXlCTn49 nVebeTrnpfm4wCFpwONGr9n8ZvrWlJ0VB5mGrg4s/3r3+4nZbyxPen1x3Afzl2wvraC7P1qZMnFJ 7vTc7YcCtSmbNsUsL/BlHYzM3EOkx8jsvcOW5i7cfpQ1VkVHK99dlvpJzta8qsB7q/OZz3133nLM y7trA++uzmZpxss5m76pkonL4qOBT5I2Tp6f/c6KvMkJ2R/nbkzYWfXVxtK38w/AT715B0cS3Xpd mVghlMdZ8ptuWwzmkJgpeyZ3j7E2/0ycF+b96odT0XnhvJYNQQUzoGdqxYmpDEdidPvXV40gDifS Ts4e75r1+TWBVVsOvpWQ/cL8uPlp6/CN/64sMD2jaMyS9E827AWRoOdxGw68t6rgtfjMF1Ykvrxg ZdLGrcerqwq2bZs0d0V2Ocv9Tn6wIv3Z+Ss+z80/VFu+cf/+D+ILnvsqeWNJ+fryau+yLF/W7ujc /cPjNjyf8t3KnaX0FBS+sqI07/td3rh1oxCDCYDDOjXdx0GbIEgeBGndCTfBOjhvZ/9z78+dj2eC 4bxC4BTVCKYhPLE2UF3JeghuGbYrd7gQZVdywnDpCmGdkk0fwY0lB69oOSEUkwdn/+krRlkmXhax O0wFiKTx2LhXB01ZNCZPws8andcey3BedF5uQu7okeHFlUQVG5X6/dOJ67OPyOLodcePf5mV825c xhvL0icvTX9/eUrOroMADYHnpXlxM9K//bZc/Mk3H6qML9j6j2VphIWZvDzjrQWrGMX019tL4t5L LE49gj3w2Ptx2S/OW/PRirQjgdo9VZXeTxfM+nYP/uqLN2wU7+W0A97MA5Hx32EpSjkiwjYKC2z9 paVrxqz9VlZMSMQPs8uq0CKqLTO/Ym0uo3ekO4iTv3Z7rzdnPxDUeQEWkk19efLsAHSe/DwQ+Amc 15VxwJ+06bWkfBBg84kA827j5iV5Fqbg8c6Ky/dXCUvdXln9xsy5X6RvYNVDwrrt7y1K8H6+8OO8 DXuqa4r3H3F/tjR2YVr6YUFCCvky4+tXVmfFLEn2LE6dsCrvzeTi1UcCn+6sZIUIIWfxaiaMxnC2 LWPz9HzZnIj1qhIjWjwtL4qHFYM3ONj5X8d5C1AqLWk/lPPqQBbOa5IZzlBRdoph5oglNpGrvp6Y uO5bzPIEvVmUzBIDNteWycrMbSt3HYWbMLg4flsrE3bAJ33n8WXFO/BnTvz2+CfZO1lrOTKhOGZ5 WiFKHyR3y7Hn4r8Zn7UfmDAMIRRQDCZ8RWIvOIo7HNTDcF4ZlTLPi82wBCn65p6DmOfVltVYBI0L TUHO2/OZ3F1KlBjCpZAjjkpsZUaMcvRbpcbNFWF7FNFo4775R8b29F01qLegAYbF/IMnNpVXI8xD NLbWBuDFE5cWTMuTdc2puw9gyaSSLKKJLDo0OnffkJX5c3aVMJuWUxJ4e2XOhxlbv1YI4F6yv0aM 1ZmHqt5IWTcyrnDU6oIpRVsAIOUwR7b7ZGDT8cBWJWsQt4TtgddTdz6duoONGITVInWsRzyAQajZ RDZT48TISFL/n5fzKnThvHcOdXuSv7XhqaIanSW1MsDkiCQZU1CF8XB0Pm4zKJj7Rq3MScFcwLIg bEQnBYy7q4BDzVup3zANEbU0Z9XuY1trRIil4TnHKooqqxl04A8MIuP73RO+SsgsF2PU9mqJmASI yLn6u22vrCx4YWkui69xehyxOJNJeR/T3xm7Rq/e8GraxqIyYRyHT1anbN2P7x8xc9CkqKraYOWI IKeYIO70oYnWwXmf/Codzvv2zDlwXjEasIC2urayvEqiR6LeQviDmCbnVpJ7cF7RkOWAnRnWXE3k Se7DhisMzxXt2H7llBN58ww//ZbYt+t+NTPmzT8L55WJIUV1YceMHc5lN8B1FaOyD46OW/922teA cYtCGIeEoqNVuFd9x4I4xb1F3x16bnmeb27a7E0lxawf1CAnu8oChftrvy2TTqEjvqkJvLEs9YUl 2dklMrqZO9h4MrBD11yn7djjmbVyyte7vmEZ+9ebYjO2+rEhrCtlkwU8omMXZYIAFLKVGFYJ+cTB U84ro15mARjm9EWQ8wr/FepUj/MKJBQadIjVC4CQO87vokPgFM4Ls6DL3BKT2Z7nFaoL4yApfShh knfk8qK1h2rAgUXfHHh2OVrbd0wI+jN2jFxZ/ErqZhb+42+wMnfdS4tSNuN7UB3YsmPPFl22wOKR on3Hxi3MxCwWszBjnSIwZrEdZTU7qwJby2oJNkixIOScjSdYg8P+PrhzMF85org20tqZV7bmEaG0 mB1LZftLEOxntjaHDvDAmtzixnd1exadF86rdldhQyE6r+G8SmCFvBvjM85Org2VVBXAulJ3IbrM PRyYs6tizOqCmMJ9eFINydrnz9k7b28lMNkE24Uv6xEArvr+OFM/3F+6PTA5+4A3a/eQ1C2Rqd++ kLOJnPCmt3P2j888DNGWqV4dbqh46KH22uezcd6UrCwRfUmWKqHntTVlZWVrsnNbdRHOq+uCRfI3 nELprcV59VvcFxmDSQFMkdjMWWf6fPKmj4v35tZKK2AZyAxMUuedCHyxae+ExMKnk7b8Y8NxFmgQ q8G7ZjOhgdzr2Mb3GJNWI9Zs/GxPZQasoSTwbFwRtuilRwQOW7Sc/OOB97O24pLnytkZlbvdnVD4 UvL69P1CzUAeGD2wIi7Qip01U/KOPJ24lTh+MeoVL8Kb7L0ohIhkOgUQGSihHZzKeQGDkiPhGprk 0iJQPDvPnxZhOK836dsQeFKfepyXS+W8NZ7scl9hjcC86PCIhHVv5+5IOipwgPkyNNZsq3g3fUvs 6g1+wpdl7By5LPOt3K1pRwXISGKk73CFrQrgQ/tRzsYRC1KfT9uaVyZiDxnAlvlbDzwXn+ddUvz8 2u2pJwLJJwOYmqNyDkhAdUSg7P3DlhW9l7sdjey7ysCirSeYJTQujobVGvIuxzMl4bz5x4jM1jXm hbe+nG3meQVeQQDyH4XLugQyNTBZxTrNAjniWp1/VO2tgeWKFowCzn26oqaiXDivKMXBJE9MssqR z+nP9Jg1p2wqoHiOIv1xiM5ryBo4LAyXrSrFSZh+kf2RGUF0ivpLyNaKrOqNjt84ZnEWESBzygS9 DW7DKL+uIgBOyaT4jeNTd3sz9g5ZUTwp85u52w+vr1L8DAj8kYiyTgSmf7NnYmLRmJVFn28ug1Qy hDfrkE/dV/paXNbI+elvf3csPRD4x6ZdjHRcXEbkMXVbwi4kiEDPri5A3s6sDkxK/hp6y9I5MTcV Q5ll/b74WGpkGMY7MrbFeXGITd7ee7LovAIQgITZwHBeAzADJgtmzr+LBAGwOnSelx78Qc47PPOA a+02GAErywjDOwlpOXsv242huLHvmz9l26uZW76Dw5YFXLMSZm85QUxd3CkJKsvM07elgcR9J8cn boxJ2cGitqgFycxUbq4Q5MRZC196BPIthJLYWvrymo3sPjMeEY71vLiaFNeg8zKjIZv86p7gkM2G wnkLxcxry8lBzms0LF3JInvByx40Q7JZZFpKyKnRKTsIs+lfuzkmczu+QOxjjlMuUfsIdMN03ujZ qyLnxBHBdcQXq/1frSWsYvTKXM/ywtjVW8aky+aA/o0nh2XvHJqw3rM0e+zSgvFJO6LTDsIZ8WTW 4Sbx9sWruciwRcvaHPRtFp3Xt1p03jNxXghaKOfdqZxC1Fub8zK6lWUI4+C+K589c0vwQmEzF9+6 MpaUjlizyZ34NR5BNOEZFgfNSYyZmxizON2XsIHYGgge7jVbEDnGxBf7MvdhWZXQ3KyjyT8WlQZW fDdyQRbVG5eyDb6MqD9ibupYnKxmU1R+bNy3bLgmGwUW7o/K3iHhr+dkxX6Z8cxXuWPnpLLg0bNw rW9ZYSxLwrP2jZX9bctG5LGhnkTVo/7aChHVoFfIQibBeSfmWNZmKLhNnRiBSq2F+cpotAiUnp/X 6Dwn54WFkULgyQ7O5ex34y2sxL0Kbsg6dwISehbmjpqfiiv4MwtyJi1fN2b1xvF5h3zFx1nbwtKt KPyjFhfEzEudsJAFQUmeuWs98zLc89PHJG7wpG7HtzZmQd64uWn+OWtjl2TFYjBJ3comUITfJ4Ak a44ik7b6WPgG6VZBBRcLdobyLs55ennRuIRNBBgHpdF5RdU1FmbZIlmqfXqCgMB5h8xL7xL9/Luz 56HzimETRQsg4GemUDScN2htlicGwjwOcl4yIg2eDFTBusU/raxW1F7JKAxXGUbd8Qc4r3ScvEgF qi0uHKiZMWeB6rxLxhDhR3BbpMcg5xU3PEF72VJNnE51NFWPYhOioiq22YpJ3uFeUoCLfvT8lNhF a70L1ri/SvAvWMtyubGpe2NyTjAWmKB/KnlDpJjyUsD/SYtyJi7M9s9Z41+S7kv6Jjrjew/xXhK+ 9S/Ojf4qjSn4ccRAWJo5Lv4bovaNXrPFFV/gT/uaKRis3O6vq2QDmqLj3py93sSNriV5/uVFBLAS Z5vCo0pYypTmiJxPj4i2K9Zmw3kZ7A7nBXUa3O8ncF4Jy5xzYPDS7FGri9guAYcoNwskvykdplFw h6TsGpm0edTKPFdcXizS8tJiUMWzJD9qXv7oBQXDF2dHJqxzp+/AGTUya/vo9O9YPP7EV4lEF4xe XOiakxa9JC9yUZY7bh2bZ7FtKyEaZNRvkHkWxgXE00ye6vypUH5D/C+azssgVmtzN5nnVWszgxRr gFqo4HQMEKMeUjFDlyxBVGiahlFidwNhAfknxJeMVHjUW4wpD6+bk7iTsWDfn4b1YBc7AHpSdvnS 9kgcMCJB5ckOnmygwEpqJt3E34xVQgVH2UzQh1Nx5uGxhYw+S4kTusHO6QXVQjFU1zM6bz0PK+W8 p1qbhcWIJbBU5nktnVeVdzU146klPEuUHYF80NQ/prgiBqafXzo0//jIDWWjvymLXM/WoodwMyZu jy91x7isvYRXikrZzWJtOk6WNhcepYGobKz9ZDXE8Lxyz/oA8b1jco+MzWarxP049EZlHQTN3IWH cFomUhAbq7Ea+um8kjGsNcs9SGxStrLihC2Px2Ts5unY7P1sTejKYCPgfV4izMvuiiykKossqGRh LBs1+vJlO0UjIwFtsxMf8IFShXJeGaKAQbiEHNC/9PR/wXlDrM31dV7bel8HT6CKxxfSJmvroKIj NAaXP+eYN/0g87BsKOlP/p6ZBU/Gfr9SY8wFMiJyjqKOMay86ZvY7QtJmA0WJ8BAcw8LzDMPx6bt ZZdJHwFtMvaMTNutRtQKlqnGZu4Zl7UbEYXt52QRzbpK5pdH5ZWNY2e6tJ1RqXuI0i+SlW5UBBaJ oIVNTGY0zpwomYB1T8xJfcDHqqKvjLUZI7PoWApH9iyorK6Qc5MEzPwE8eCNQNvKKJmxkJWJgVp1 2krplJpAJbyYs2B3SDZ5NyTJw3o/8ijnNTelMjVV02d9ZXNebYvdBUaEFuMtbJcpG0kWtuMGXxOZ fRJ3puiso4RNA0SezF2RWTtZYcTqe7A0OvdEdGGNhPhjIQNL/PJ2+DO/9xO4L3UHezJGpm325su2 mCz/odhR7GKJJpu6IyZtO2NkTPZBT8YhNuHy5tJlu325xGOHLFSMKjgpGxSK02YJxNafsfvprP2x uKEWHiPqONoHgw5UITN1ZuWXrPlSr1SpdtGpnFenvLH/A1S1+QtU60HLubg4EKAD0HkfDvo2031n 03mV8UnvgwbDiKWGQzuba7PvcxHLVWTPl+Ebyp5C4pLNzdnIW9xmWNoPKyGcHSxm6Jq9rmz8oo8N zdyHdizy5Hq2Czw0Entm3r7I1P3utMPInyOTv2dtCOuMIM6gFn4dCNti7DJMzQrNpNH/lIwbFnxx OK8K56fO84LeynklGr+iukSRIil1EkYMC2BckGQXeIhqviTl1CcZIFAzCbgkqwAqGbDoO/hE4UcK VWSbVKLFEovPV8C02jGmbmElwrjZOUJiiJUROlssUbhRFZJHPsFIJFENcdnNl915YL5UjxfR7JTz SqwbgIZSaa/nlTFYR5rqcd4Jeczz2kRJZhygAKoZybk2HB2NTcBLIdqIFtCBYetOjPim9KlC2Zbd W1xqmAjcBA4LB2T6kpqjPYE2bnY3K5CoBSOLqkexYWL+MWal2fcwJg8CIqufXFCVoqPsFEn9yc+K XYEPe7gDyYLjzJurXAHojrKmWJYVIxKsOzZqw7GRG0qGsz8gxEqi6lV4C8yyC/FkFs290Ko8r9ME w3mb3Hzv97uD63mD5AiadAE4r+JN0Nr8HUMM3NBkaiLwpEp2rdinnllU2oJGg9O42C7YOkHW1uGy jgosjnOCAwgV6u+ELMHeYYimCGO41Y3M309fgyGAkSR7tTO5zxbYzB9JUJcyVsrTBcxd0nxGWXTh EQoU9g3SUhRzOutqCDyCodX7LdqW1A16bvqRahsuHGyCaUjdEeJPJz45Nw2d951Zc+GdouHyA5To rZWyqEc4rPpNcab+TjwG4qi2JJVzyFRTs3fXpjlzPrn55pv/53eN7u/cffacBQFh2Wi4prC6o5Qv JZikV/ZBihKFF44Dz5V8ciR6ZJ3OewrnZXgaCV/tt0dHrDsSWSijTCQiBm9xrbuoFkEuMqfUW3xy JJt4Yq1iFTnWifVlZPAUVo/Oq2SrKfoLEheZL6YJXgfnwcynig7RTSPA3q9Ln8K7Qyb1SshABGY6 0VVY4y0I+PFVZmjkH5YxxeJidb/X8S5W5WiZXBOTPoSRwU609lHrReqmByEd0eSXsSbrQU7nvPSE 4bxiiABc2hk2qJyTiwkBw3kfGh3LqiL4Fz1LJ0ISSZwYViKYGVRwwBNDr8CHoLOTyof6Itm4j2bB I5L4HsPK8XIpPAYKjS4AG6sw/YFvsuG7WJKP+1jJmwtFhfCyxQbRv49IiPsi1VZgNPlCn90F6FBs 7yuUB1lRFvOKklhXK8N5/x7z0gez55rBC04JXslgDBmhPxXTcAsBTc3b8fnFV93TY0LyRkgWTrNC 24tZdFwNB4HiQdmwE/qJgQCjKSyDXyA8CNcoOsHWD5LkfqXszCv5SbxOISS5yVNiLpmQBZxTDkOJ S3FogRoXybCyk0zlrJPXZaPkomOEr0HZHLmBnPKh2HzKkdXQkg1YQY2FE8F5YUDCeW98ZODa3DyM eDICg5AxhsET5VXxOfmtH+rzdLZwXsQDLUdqS+HBVpvKS9u1ORAlbQj0XxjHCdMKXtQ2SnupOVUC IJqEI5inbIeBKR4JxF90DCmCF4MFCgPiPqVRJk3gvoC3UICJAhJFlCeWEq/HgYojFTsRub4EIMB/ WQDOW7AJTQZocs7NUxI4PzFnV5Nb7v5+zx4h6/yENiu5vhCcF7xhlJn1vLKqCHaZD/NlaAAT6T6a EASvSC+oMKM2IN8eYWNNhaS0GljRqMgN3JGoMtjnSdpAaSOFAEAgALg0CR6iFIMYCh/BH4GkhYoC meB9yW+6g65BRAGkUUiA9BF8QQFL3WyUO/1Ea26hGef0XXSeWJu7+p5758s5zM8KhednI5i5Yy45 yg8EhBGg1HKEF1fi91yQljJ4UN8O17T79JMZhfnrFi5YNnqkq7aiDM4Le6ZY8JbOArClFfKWVZIp TfvP4LX9XZ6YbHpkVdH8XuNeGfjRYqR9wVs1pyOGoe+DYDqEaXUZIhxbRxGegr5giIGKgBp8BlYM T14kWcOZ+4qiZBCYyKVEIVBkE/GSoWdQ1FAD6USGklIAg5CRxdWRxXDeGplrAP6S+JBQALCdAsnP p7nJHUMlzE3uc5P6xOZL8uk0E4KZsHVx2jnmStrW+605f+v/FODSH8gtSeAUAjjrofPvokDA5rw9 /7HYcF56U6wWRQxVGdFBzJHBZQiXQQBFzmrhDoahKDEUugreFlT780EhmBHkgt4XV1Ix7mGEKcRR KmgFFTZ9UhyV87ABcrNKRTiC+7EJtSCqGcjUxNAQSAGeSCCzEFih/1AtyQMRo+ZPzkq5P/rF92fN AaMMYilSXQDOGzJg2XElEJdT/Ie7uz+z9jtCBBsJwZg0ES3gUCQ3MrMkPI5EU0C6UOHhOPGsRGtD luA+YkaBbNc+gh23iyTmIYWgAKI/SgZ9Rc7zyklkRulDIEGU5Zyk5VMyN2V8iVhSyP5Qh0YVHxku q4c0dlbeceQW8gAfqRgxFQkrhwosUnSpJ+7rm5jnzcMjyRp8Ohen1Kk2UHKyclVmTkRXiaSBJI9A hZIlDZTwjJQvcpFJUgFEqULdmIxqa+XrWi0VENuXySyVCUJDSzMFlg0vLqPaCF00RN/lFRP+8bg0 DdJReIz1lfpdbb75UF5NZH4N4cJMkw0oEOdEQzFJdGouZa9GAKiP5NJ6ijSoCc47KWdXs9vu3b53 r0Wa6PIg51UapUPRolHKR85rbOoc5UsfTL19qAc/drEPQ1GL2XtOmi8Vo3cESooSRL9EJ4LJFh3C Yi9VBYXodHIilK6jiwUO7FgtVgKFJy1S9BAsoqUKQI7STBqIvVoK1FlaRUWJigZIRQULJoEJRSla GtlYXxcZWF60qif9eMZE52pD5Eg5aGTD5mc+HPPiB3PmG84r/slAVgGooymobRmQijkZqAJx4mcA WXZS2ed6oi/hnGfNW1BZXsHd8rKqksPHAydLVy5ePO3TWeOee2PJ6rRvthIUzXKuqqi0us4UZR31 Y5Ro/occZT3vYxNeD+4SKDMg2EwUz6us8YVWyzzIuhNMojGs6A6GGD2i8Fc8x59Qx7sZpJwDLqCq aGYeWbinPUtpdBkDWQY4pAAIS69ZY0feghTQrfQCGQCjdKWOdF+e5CczfSFdjChOtNjccs1mplQE f8gsN/PKZJ5CxjuWDZFXcQsJ5bwKBGPVDy6NPi9kdjJfIAiAr0x5GGvzKZyX7pNBp4TLjDjFB5CE YcugFoKmxJAxq5ZARRglgIbS6lMUW3TDoiNCAdCYCtBtBaVJilfCa6AqYCBPDd7yUf2uoSGCopBr IQXCxSxs1/poIQUSIeEUzmsNOP7JiK4bd9bZeYIOakBJAAomRYrPWw/nfXbtplg2pFahV2QSVjyJ YqKCiqhyIhJI0gwqvlqaL+dGpEFyQE8xYgYnRsgxeqKReEX105JVYBaJWoUiVOMa+ZxocydUnSxD JkEmF8kEwVgkZ31q6TInsIlJxdZhWS01+61TMqG04Lxrc/PRHQROHJXHmPOyypq4rPzwLr3hvIhe xAARHU1bRD2lqqZ1onSX0QTUNLKpjCTqtiq21Ep0Lm5qc0Ro1yYoHBAzilCvqqm/aHlaAuqq6AhS snkEPMUUr7rGMTRZJC7yk0HFOdF5PQUBCwKWXiZarVbD+ihVlRpukKQSo5VBq6R6NGXmH5uYtaPx zXdt2727gr4GBJKk1/VUOIICyPz7KZwXtHn5H9PuGObFixhGTzRCkkLJMhTY8NQKA5MTCJnSraL4 WDovEAY+Cv9yNFOgRAl0JYA1iCHKl4rH+paADkDJ9prrRY6VctSAID1i6VBIsJIoWUoASejQoDZt burnpMfPkQxgg+A94cs5ghjcxTvp3ZmyV5HxpzKgBIIGpNalgaz6SsGdGWhiCeayZMej990UE/30 zr0lcN7d27cuW7I0fuWq8sMHhwwc2OOxx6MnTX6w95Nvf/TF4dKacjVnW30kXUQRIUkf6EdlCJsE pptIGv0+WsB6XmQht5Apnc5GIhIMZJShOFSPXE8CeoLeGAcwOKAFYwoAwoBRbyo+67lBb+kOqxcU 2aSPxHhlVGMRurTXFAPJqfqFaNNHjIXBjBoKUVQXqqKdJR/FnAWhoINEtcGqxkBjJkh7kEFkqc+M jqJSqZiOd07wJHEnf9/7rVlG51VQhHBeg9TO8aJD4HTOS8fB6cRKbGisjkpDGczgFXPWOkv9tOxR YnKRRAYGIEYVoY1GOV2PtVBoiJJNMoj9xCChXSYf4i0SrytCCmLbSdFbaYtFXVWtVoOtscIx5WRz 3p/D2qzaj0jj0E/AlVSw/qo7u01Y860sslOhF3nAUnJV0UBsQPxQLc8WXZBSLA2LEwQMo24gjRg5 VgQYEWZUwRHpwpaWywjKin1eZRKVdtA7mMCVOdygUERmS1tEOAl9aglIdCUdCsGnWBgoeZgnxdoM 503OyUOLN1TL5ryoJ3BerM2tHuzNchs6Aika9yejwpu6GSlIBSHUIklUHk1K5Pm8oLIviqfs3O0S xVNAYZQCfVdEd9M0YKVwEJio0KX3tdXaRgoRyAAf1A0DcKN3ILmJFKdwEE0hz6qh6N2aeCTqYfEJ pp5VLxaxTTUOOVIr0wv4Yz+Xu7vprffs2LeP/pWfkKcLx3nVNPrqR9PvGi6cVwxKmGSLZH6ceipw LKlS4an6L/qOQE9AR39Zwqoim5E5XXj451WaEgQCYi0RVcj0Ed2tLwJz7AmVIwinj8QLbihekYfE KwJtS0cz+VULk+4QywbFyqflLc324458d2xR6bC5Ym1+b9Y8i/OaIaR4Zih/KOfF30l4peYRJKwo r9i//rEHbvH7nt6y7UhVZfnGr4ueGT/hsUd7Hd7x/UP3/S0qesLSpNyb73koesIre49UmFGpyrLp vBC2KyxYfvpRm+1yKZy3z7iXBny4gHWLDA04r4glBaXiPqrjF+xSLVVsC6ImKBxAmOHrJAFJ7Tgz BgU/NXFTtAMDN3NuoE1PmWQgD/DNU+lNrGS2Ng2GMxFcdMQMBPpdqiGQP4YZZLgkUZO5KaXlo5Ic MdNzYvkplnFEx1ExWoT9HC2eWvkKD3uTtz06+UvDeVW0DHJeAx3neCkgAKnBwyp0nhc+KIRauq8U LkwPyjE4zwuKRqm/vYRGwQNEPF1LUaYkAyxbXhE0Dj6V9WWYmnkFnwGNPYWvXSlzweTHHx7zsjrK mqVzEpYKJwG/7siAg4d+SxyHKB/jCROUeICIv4FOJRtHJgZLKOe1rc0yyuVPhp4Zd9Yd+XfeP15i qteUg28znHfimm+JOweGQ0hJzGhTedqoMDGtlpor9MxRgMAktZmnlpV3Olst4DKLGop0FrsIzVQ8 tYAqyWx5IF5Ssl5AjPYKary52JqkNKR8CpdyFDISi1gszOqEzFFIff4xxGMoOTSfeorvzaoNtzw6 OCUnD19TAw6b80IDy05WrM7Kjuj8yDPZO+kI/G0Y5tpASpN+p6Um8VR7ispLpGiDKnQTFTDtpZna 0daKJ6m/SYJRoIFggiF9QTTjjnFXM95cgmCCYwJMg5NsfMBc/1F5S/17absiA4hBURQrflPmaCCp FRAU4inxRoizZ0J7mZKhVM9kbkfnreO8dDVgOZPOy4OfgD2IN3hY3TXMw5JM5BMkH2/uMXGlYzeN EHgqMDU4G2NEW6e4QVukxw2sOMooED9t2kJmay0MzhXiua3N17dkSKqLHfM41czm8JaBvPQOru/i EGjGLHWQ3uQIJIGz6S/wUMcaQKPL5NE5jqYHOVLIGNwp56TZnBeI/YC1mcFlHK4YriAjMk/lnpef HtX/scEvv/ze7l07Dh7YPX3ax//n//6Xwzu2PnD3HdM/m7fzcOX93Qe4YiftPlRKiElbetSuMZy3 Xi+ZkWsf+Q67BPYf/+oT0xZNKBRfMtmZsehYDKSP9XE6NqUtGqsHcOEVH7qYEfjI6JNBqiiq+RU5 5RXrLe0IusCCuYxNQ/rkLca1DgR1VgF7wYEihg80gehzMo60fOloHUcgP3NwRyUJwYTiMU9XKjSW QKPFEsSeKuFqxVNyKoJJb8p4X3cipugo/vC93/zi7/2HAl2H89bDjEt3YTivsTZjPkXBwfVRaDUn Z+S8Rj4MGarCW4VfyAg1A5BONwOZUcxTUIVha0I+UrLgjEZ95JHs17ZOWJIh5sJ2JUkAOgqhNEMK hPAqLQUVDedVSis8VwZIURk1HzI71fawEsJphtkF4rzGK5Iiwds1eYVN7+nxfPLGMXkHTUv9GqRR 2Fn+USRMt/JQkaIFDkIbrebo/SjYkyaymVYzL0YJ+iKB7IwMQ8MFLJqkmWaUScnCZeSOoYRSgpBu vmU4L1xVGCsw5I7JQ+FEpySbl4XATMfnl4zJL4ldtf6WngPSc3NFtZNmGUEFW6vwG1lVlJndpmvP ibk7Y9efwC2Wt6RYrSdVJfCUnWg15+ynBhGQVkv/inOdCE5GWoBpWhxBpDJJss+yJNOPWpSE6eZd 7hgxRuuPvAEQpL0CTGmplKAAPMwlL1IZBSOlGUZGq4Uq6isCBF5UOAibVqmjNJbVNAoi7oOi4LxY m2+6E2szaGMgcAadVwfpT+O8GLFf+ceUe55ys5YzZh07XJfihqQII/1uw5MWkeR+nmmLwR9rvNAi k4ASw0S7QyBg4GY3n0sBrOIDJFr5rMVDzSPJKdH1LRCBnHSrQUJgpTgmC3vpMvMVMhhEPf0oFRaU sI6UQ31YGmZ0XuNhdS5rswVSvKoMEpoIG8QN35e0cu6IocMeerAHmwwmJK767PMvw8NaHNq+qfPd nT79Yt432w507TFwzMRXd+0/KrzawmBDRs/AeXlgEJyj/mo+mTOvV8zzgz+cPyH/MG4k4jFeeDhG bMglZnjSKEVLib+KtKb+oka0UwVZR5zhqoqiZrDrQBahVBGvbpyCk4L2wAdwGfzUMSsDgfsCQB3F MjSKhIBwX8aRRTrMqBEmK+UEH/kLqPNBdlMyZEGQHNf3Imtsml6LLj6Oac6TuKnPG58/0G+oAIEB LgKOJAsYzr9LAQHDedF58bCCPjPnhXHDxEZgbCrRE5IepJyMVhnXDF44IGIzI1SUVga4RlSW8a44 JtqHKrYi2jE3Z2aRxANTrMr45uGDJ1oYk1lqWOaEpCZr/H8ssmAII7RRkpJTg+paMUFmK+Ufo+ZM Ldmc14wyGWwXhvPWiL+lFCUnKfnFTe/uPmZpLgv0iPzjyj7gyTrETp3ezEPerH2yNV6OJM5ZUxmd ccgkX8YhIhKQWXatZREfm3tm7WPjTvZKiEknzwHzomxunn2YnN6sPd7snQSxIdaEZMvYE525xypB y4/KkRAKEm6XBb8UnsmLh6gPb0Vn7pT8lKlfJO6rJ5MlXftkuVY21TjkzzroX5p344O907OzTLss wiQDE+pXU1pampSd065LT0JJsyiMtaLaRpp5wLSO2spSRG2FNJxPyJ3d0uqMQ76MowAk2FgCz3Ln MPdpFHk0pzSHZN6lwiRK4xXJnHmAVpNZviW7oBoYAk8uD9BG1vlyn0u6QAqh2BDY8lTgIMAHbvs0 g8Bck9zXfpFP8EXAODrn0NNpW+C8eFhZpEkYsEgjikgixNm/n8Z5q6pr3/hwyt3DXOzpMDpjL7Ul iKhpexCeUhmT9L5gC5dU0iQAS07COEu/C0zAEPIDT2m+BaucukuBCQUKIgmmmeZTlMT1ytgD6Hhq OkjyaAfRZfQyBfIhA0NAR9wSAyjtYvkuL9pHKVxrYo7acQc86fvQefGwYp7XrOe1sEvhaEAq8Axe GtYJ4lWUnxBsFMgTOrL8m+Lc8WP9LcOb/aFxo+ZhbQYOHFh9fJ9vxOBFi5fvOlg2ZLjnrXen7D90 3Ox6JKuTpECLm+hXrM+avjN3zDnZZsyeN2j8awM/mBebvsudc5A9LgGRO/Mgq8h1UAO03QwukoCX VssYlwQ0AItJ0gV0E0Cznsqw1VEgbwENXmRUsgvqiLx9o/Ls3pEeMZipvSAw1MyHGcWm3/VbB0wF dEDJd6VwPkce7SlqaEiE9oLUDYSnYiwrNp2rDTngSt/pjt/Y/+1ZhvOqTgJKBzmv9kIQLM7/iwcB 0H7azNkPjfD2e/OLZ1K2xKZsHZP+/ZjUbWPTvo9N2xaTxqaf22JTt8ek7SRxwiOCC41J3R5LCMS0 XcQu8GWQjfvb9f6W2LQt8lYqmXfpW7xrJX/6dnfmdl4Zt3bnhOTt41LJvJkC+YQ/YzPJfEtWnUv6 Ploi7dQlf/o2EoWT/OlbJGVsjiGMXsrWiSlbRn6yvKv7mQ9n4tusyBUCwvqDLuTBjz1F5dWpKKLg VFWk5xc1vfne0R/OGTht8WPTl/f9eHm/aStJA6au7Pfx0n4fLyYNmLZ04NSlg6csHzxl5eMfreQ4 cKpmmGbyLzcZHp+yXJJkWM5bfT9e2vfjlX2nrZKn0xYOnLZgMGnq4senLH3iI44Uq69/vLDfxwv7 TpcPDZ66kAwU3m/aqsc+XvnY9KX9pn818OOvyDx46lLy95vGt5b3nbak3/RllN9v+gqqOvDjFX1f nfbnv3ZJyyBMneoIwmsMOOQSzrs2Ozfizr+N+GRx7ylLeKX/x6ukgVKBpfppWqqJ8k3TPuZz1ERa PXAKmVeRmTx8nerRRlpKowZI5WmIVXOekqSZ0xZw09RWCqFR0ySntNFAaYqAlK8DcxI5gT/ZtPlS E1Mx6gYQ6BQy23AjJ+VIBuqsX+QpiS9y59Epi0fOWPLriPbbdu4KwsDivEDEmE9sTPlpnJdi35oy 7c6+jz/x4dw+U6UO/T9eUQfPICRN9Qw6kYdGUUkFxWIDN23dYo5gCMnAx0C173RQYiEtItFeAabp EUEkwRYSRYEYjwvOCGzlcwYg0oPSZdKVWqwiNp9e+PjUBQoo6aZzpIFT5ak5Dv5kVd/Jn3cd6X/v 85kMG0UwPShwOYTCkEtIUDAb8algoKqQVRElEr5dXl55suRkOXnkV10aqCpBaZMFSBRpiUZGj+Ox YrJm1K+ci/N+NmvuQP/EHmNfY9OEx6Yt6//JcgYIMJcByIhW0AHzIMZaaCO4KnilYJwi2K6tFujJ AJcuA+yC5LxITgBCab0/Wd5rxtJeM0zHyVskkFNHqHQT2ZQ+rB4wdbUWKI/MUyEFU1YNliQoLZ9Q aqNoLFgh3S0FCpExZQ78eFnfqctolKFOXD4xZSEt7dL3cYGNCJLCefnn/C4hBID/ghVxN/71gbDb 7rn38VG3Dxpx2+ARnR4fefPAp24dPOLWwaOCKfLWwZG3DRpFMndueXwU6S9PkEZwojfJz7lJ8vT0 pPkls5YjOUNeOf1Fu7SznvD6nYNG3tF36N29n7izW++pn8+kRSHuFjZozaisG5v2gx9zghROsSZ9 /d2m4V7/7V2739Hjsdt69uv0SGh6rNMjJLlzRw+TBtzRw0qdegwIzRzMQDYyBAshj2aj8GCScu7s Lsfg66FfIZuUwFu3PTJA62NeDM3Pi+YVq26Uc1f3Pv2eHHrw8CFpVDDIgGkgAKmsqtmxZ+9Dffre 0b3PbT363vno4Fu79Tul/sHK6P1g07QyVn3sDEEIcP/Umps8pqW3dOtzx6MDbu/Zv1O3x0h3PtKX T9/a3TRQmmMgQBsN2IPfsu7bnwt9auBmXrQzcGKXxjlfubdnv14DBx84dFBtcYGqCt0W9sdgxo/L A5nbuOX7uzp3vb1bb2mgwZkg0EIrJufam+am3UYbr0zrQl8JQjUUtjaq0FLBh/ql1d2xyjFfDPlu EIYWLoV+7oznBsKmtrd373v7Q49Gxo7V2KQCIHYIOgecbKxT1qkZuWWxUQZsCAOVMBpSVMgrmv+c BzNVRBb7pLy8fN/+g8+//uat9z8IhtMjt/fsC4Sl5nbvSB8ZQNWNGtpu94g54c7t3fvf1r2/jEHT rTrWbu/e585H+lMgKA0wb+814BY64tEB4HOnHoNue2QQRy3tsTse6SMdxPjtMZhEsXf26HNP9z53 dX+MbLc88gQ3JXOwfErTZLpb6hYcX0JGSOCz1Kpnf8nWg0HU555H+/+9d//PZ8+rrK6DHg4eAmbn d4kgAPBxy18anwjPmvLFzHenz3j7kxlvfvLJ+19++c6nX4SkmZy/O2Pmu+bmZ5/JowZwfPfTzz74 9PMPZnw25bMv45NTDx8vpUVsBnoaOIXnqqQnY/m8fmaYS7HVVQZdT1aU2zevjBPjP2YEDOQW0yj4 rzmx7/zcjeVDTDHv3rNv/4FDfPvn/pwpH2TAVinmSj0xuGEuzwtPzpbZboh9gvHZPr84bbyYXwEO 8LhQACLPGJHmbCC6CPdPqQPRtPioEQnMOZemkhcQVvbAYbkxxZpOB8/gfxyVSFm6AE8tqUJgYTaD kDs4h5uc9Y9molYenV5b2xdUvqi2e5MH8sVJRRX+aHVvkVk+6PwuEQQgBRWVtUQuYjkJvoLHKqqO V1Yfr661U0lloKSqtrQyUFrJkVTTcI7UFvw8WlpOrUBF2nI2KP40zgtyhiKwwVtz58xH85mGc9TR d3pVaciJMhFUECd4yglHe9iWV8g4hVYY6gEX5vxnTYY6zfj0c4/X/8bkt/iuTa9+1u+CLWybbnDG 0F5bOTobIp3XfcBIOlkuFM/muT9riy5t4TaTNfzXvjwvoF3wzKdX4+RJ2Y6Bn+luMiAtcH6+0DPD 5PS3uG/GzqHDRzlnBJlLcpoomTLoGHCSRBIznJdLneauZLDV5bQol0yBY2jXozw9QwphtXz0lGSz XcOFeUpRBgjO8RJAwO4eKANqTlDXCJWyTJa6jqSWpscu9ZHvIy0YpOVo6ilNMBWrD00Lf+vf/MEr U6ZhSYweg7Q26lpftD99+ZzIwNfa2i0ybWQ429ouGQy5uAjNVPGv+qGHu//u91fdcefd2AMvwkf5 hPnZ5JdLob5nRKBg5vP6DzxDG8IlIKWxoTevpHOAA/RCAQhH43deQLuwmUPrQ01MX5tP2Aqv/cUL 1RfIjcdLSleuWj1+wkS7TBsZ9HPomxAtS+s0efTS0DPlivWRJ8hs62GUXfg5TijLaBDkgYiRODEU wG64c3JRIUAHQAiQ+ausjhZBig62N5I23WmMIvZRu026nzuX9qjfB1MZ2Iam1UHP1FyvzWnIjbpc 53sWSlLO992Glp+22HNwhhzZFNI001zaKuHPXf/PP/88IiLin//5nxs1ajR58mQ+F0okf6avm9bR XtNYGwIX6nOmCQae5ng6tb9Q32oI5dBefrTU/C55lUxlzlgN+5GN4dT5jDl/2s358+c/9NBDN9xw Q2ZmJiXzuZByOA9y2JC7SlKD908lWDb9DXkhJI+eWp84R0PsatgnIcU5pxcLAtJbGrXNTB1waYtl pk/lTjDB3uybDeREp19FnDPCYXDgCEMxNVRAhlb2J0P2FCb1k8tpaC8ySEMpj7HC2Y2ltmTg93NX m+/269fvD3/4w69+9avf/OY3nTt33ruX7e4v3s/wXNjiz0GRTpFhLjh/v3hgOs8vgTnA8+cA6XlW pB4an4LP5jIU58+38NPz79q165lnngGff/3rX0dGRpKBTpcPWXTJUFWYbJBXKnHVS+W84k4W1Ibq SLB5K+RrIePy3DY9EDu01QYDQ++EFOqcXgwIWNHbdLGqYbHB5avBr4fyLe3ooNEDdtcgEtW2UAhT XnADsiCGSytCWxBs1Y/9b40XZUC8w2VDICM/tvZnzwfEzOizs5xRFzvjTfuVC3iybdu2iRMn3nPP Pddff/0tt9zy7LPP5ufnX8Dyz1YU9PZ0+nMKZM727o+8j2BjF2jI++lf/JFFXRbZGCA2VBtOS6mJ qYx9Qj1DBS27j/6XQDblL126FOkRA86//du/gdJbtmyhWK0A/PRUlgqBMrN7+mmeqpOVxZThtkYL Nmw6+K4haiF1taix+fxpRzuj3TXcMdhoP3JOLi4EaqpqJFIEHcf0fQgzFYZV76fXZNBNSxvEUepc A+VUY7OsBAyKlAYtgw2wr4I36jXrBy8Mq9VRY+U1d37wxYacwW6OITihY9BunU2L7Ds/X4vWrVuH UW7ChAkPP/zwk08+yWVaWtrP97mzlXzBJQ3gbEPPwNOG/NnqcFnft3GGVtgttU8uftP4tPmd49N0 EHnIEFr5c+Q/xyPKoRBG0/jx4++7776mTZtiwLnpppsWLVqkaGDYaCj3FDWWb+PkF/Tz44bhvMKO ufhxnJdCcN2CO5/1Z+MhOahk6OVZ33Ee/GwQoNONFdkIXacceWonqsB5gzpqdQR16yW7xqa6mslU u/6N4APnf4OBwMsvv9y9e3eXy2UoYYOpl1MRBwJnhsDpiIrwVlJS8umnn7711lvR0dGdOnVKTEyc MWOG8nfoq6quhkZxJZO/eNXUEDekzBBbrHYsvK0VVxt4sWRUzaKOxHHrFBVDqvbDnPfMDXDuXiII 0I10sX2Ujj4tUTVuNtRffbYLFw5tQEilze2QG85pg4OAw3kbXJc4FfpxEAhlwUZ3LigoYKr3/vvv pwDzVKPhmUVFSlLrOG9VqXJeuK6oEcp5OT1RGyjHA9b6CaGTyUEMe6csOZAMcF5JwczO/8sAAoar nou32jkM92pQR6PwhlbpMgC5U8UzQ8DhvGeGi3O3oULAZricnGK/LS4unjRp0gMPPGDuEzuLRih/ VEUGkiW8lHus9ZagBGJt1pu15RJFrbxWAmgatUiWodn28FBaZ84FOA7nFShc3r/Te/aUOzSPOw3h KNVQ9A2toVbNOVyOEHA47+XYa7/kOodyW5sLG4Dk5eXhKNilSxe1MyupkkUYQjvlwj4TN2Y8baoq Kk6aNQTGA4u7YoKuqK2oFv6Lmmupv3UvBgvR7zk672WGh6f347nvGLRpGMfzA7Vp1/m94+S+qBBw OO9FBbfzsZ8HAqKg1tauX7/e6Lx8pG7hXpByWl8WooQBmaBVZQFMzvhnqfKL/ltZK2Gv4L8mGeWX 7MrrjbYsCrP9c8ibDYrL6cR02xmPNIP7IT9z1RCOIZX6EaemdT8io5PlUkHA4byXCvLOd/83EDCs 9pQSioqK8NU387w8Io8crUwwTQnQqrfQZssDR3e/4BuVmhyf//XXD/QZdN3t93br1m3a1I+2bt8n hmhlwYb56iSyw3lPAfZleRlEhlMqb3Wuztpbkwh1M/jmnYZwDKk11bFTyO2Qu6bC9Z45Fw0IAg7n bUCd4VTlx0HAsN3TmW9hYeHzzz//4IMP4u3MU8subSiUmJfZ/VBCzQvNYlfEvZu739IxfsWiuNSU +/sN+WDOopdefH5Q395u3/iSKpkCRvM9yQJKrZK9b2loBa2CQ2855w0YAqa/Tu81M2tw+lGaEvrO JT8PgW1oXUJu169wvQfORcOCgMN5G1Z/OLX5IQgYTTY0l30HnRffZjyseGpuyhIiiJT8DOfVK+5U lQUObu18TYsVS+YkZmcPin42e/Me1rOPHDKk68N9TlTW6bzGqdlyblH3LFOcc3Qg4EDAgcBPhoDD eX8y6JwXGxoE4Lx4WBHJ6kwVQ4XV9Y/Ci1nAWxI48F3X61uuWDE3Pju7yXW3tb35/quvvbF3r37T p8+0PKyCCgSvBd8M2pxtleNMX3LuORBwIOBA4NwQcDjvueHjPL2MIHAOzmtN22FrlrnbqkDNscCB jV1vDF+w6MvVOdk3/b1nryd97tiJM2d9tXHjdviqUXXN0ew0FKL2njWCwWUEK6eqDgQcCFxCCDic 9xIC3/n0hYXAWTivKKoW5zU6K1O4tSWBg5u7/qX14qWzE3JyBkSOS87bUlYZKK+QVUj8GZ7LiVim dY8/h/Ne2M5ySnMg8EuGgMN5f8m9f4W1/UdzXpRWnef9S9sVKxeuTE0dHjNp3eaDxvkKVmv4r2HB HOXEHEwoA3NlHnB0fg4EHAg4EDhPCDic9zwB5mRvuBA4O+eVAJJSb9V5hVsSrerQ9scfvjctPTGl oGDMi2+u27RH1F2U3KAtmUtJwnODb5pC9FoOmt++ck4cCDgQcCDwIyHgcN4fCSgnW8OHwJk4r7Ev q3sVDbA5L67OVSWBqqPVNSeJW3UyGEmSPU9ZRwRHNXZmTtiL3HrNvBwKBYfzhkLDOXcg4EDgR0PA 4bw/GlROxoYOgXNzXvik0VLFqsxUb3VZ4OQRE8D5BFfmqexeKGt4YbiSX37cIogzzw0LNjedowMB BwIOBH46BBzO+9Nh57zZwCBwJs5LFeGYovMazitcVapNjKoytgpkq3SJ4AxPlgeYlslsWZHlRjUP z67zSjnOz4GAAwEHAucHAYL8vPbaa8T88Xg8KusLcXJ+DgQaMgRUJZUKnoKxXK5bt47okSaShtk3 UBtis06LpcJ5BdEJ3VzLpkW6OYJcmmTs0vYroSdamHNwIOBAwIHA/wICGzduPHLkyHPPPffwww9H RUUdPXr0m2++sQLu/S+KdV51IHBxIBDKgquq4JgBOO/48eO7du1qozFhJEOU1lM4r6XhWoyY98W5 yuG8F6f3nK84EPiFQmDPnj2jRo266667/vKXv9xwww2c5+fn29TsFwoUp9mXCQRCERX19uTJkydO nIDzEj3SxLA6fPiwpfYaZVbbZem1qt1abNicm1YL5w1Vcjl3fg4EHAg4ELiQEIBYuVyuJk2a/Mu/ /Mt//dd/9e/f//jx46EE7UJ+zCnLgcDPBgE4bHl5+UsvvQQOd+/evXXr1mi+b7zxhvXBM3HeM9TF yuZw3jPAxrnlQMCBwAWEwPLlyyMiIv71X/+1WbNmU6ZMge06nPcCgtcp6uJAAKSF+TLDiwEHfP7P //zP22+/fd68eXzdUnvPXY9QTfiU83O/6Dx1IOBAwIHAeUIAesU8L6Y5FN5OnTox7WvPjp1nSU52 BwIXDwJnEw4RI1F4/+mf/glJ8pZbbjl48CB1Eo9lS5k1NTQqrZzX3eYsdMWQ/Yrcd34OBBwIOBC4 wBCA1WKU69Onj9frNUUbT5UL/BmnOAcCFw4CoZw39LyiogJH/aZNm/7xj3+cNGkSHzQKbx2HlTrA eY0P1Rk4b13OUOZ7Lv5bx8cvXPuckhwIOBC4fCBgUQ1cREJdRuTqbD+oFj/U3uLi4vXr15NNFAT9 Bf9bl/oPIsPPHPX0DAdDiEKPZ8jk3HIgcCYIhKDNaThsbpwJLSmpDidTUlJYH9elSxfcq4wBx2x8 YL+uMSStD1kfkULtT2u9zB05hvxM7uDN+lch2ZxTBwIOBK4MCNiD3JwgyYdwV1inMlf1yaypljUR xj+zppY9wXlDIu+Y8LN6rAcS6A05Qn6SP+QtzoORfCiDxY+UH1yjoZWRbcfrrHZcoE2QwU6iXGhG +Y6dQj7onF7xELCZmn1yapNBDOV9ijzVJwM1YJrckCAWit3gMAnMJtBUCC4LXgdftAqvqa5k0uTL L780MqQUQ4wqfd0uRJCa23ZYKrBaBo6MoJoqTviofipk3OhNHWLq+czrpjSOWvlTW+RcOxBwIHDZ Q0BIQUgKORW2C2URhhhCFpR31lZDRoRsGf5rCgAUXNrprJDhPShZ8AeNoiyhYUGV2PZaqYaGBesT pIHklMwhySrIbkSwYOf/LwECoZhgzk9tNYhRXUu05CB3hfGRMYguoHN5tXA6xXVwutIgJDgpKC5v WZ+wvRQsIzPPYKbKuymssqqmokriZmg5Fte2X6mqqNShRGEwYkaToHEwp1ZY3tRRJugtj/iwSTxx fg4EHAhcmRBQkmGRI2gA9ET4oNIclcN5VFFZDSlAUeAo1EBE93LZDU3uVdUi0IsWYZVRvzxuQ1Ug VBVCXpD8peCaQEWFJCE48pZQPTZQq7E+AUmUbPJIFAs9SjZJUr3QL1lKhEOprkzk/OFWGVwxx5Dc IAl4pQncAI3AKJEYq+VeTW15TW2FIhm5aqqrTtYS71ECT8GaBSdN4hSE5QXYqo1gaqsJfhQErgaN FQmrymsqGBHyPpkNMvMu5xbGGlatdTRfMGVKBm7KLV41VbaYr9x3fg4EHAhckRAwVMAchUrA2yAG QSIg50I9oAiQKklibeaqPFBdygmPYJqHTlQWbto+Z0XSCx/McE2aPNj7bK8Rsd2e9PQY4u03asyI cS9MeP0fb0z5fGl8RvHGnSUQuRBIwmcpzmzpQvmcy1OhkXKlnNeie3zLpBDmazivxZ1DSnVOfyEQ CDJBkdVCfophlokXtOGhYrgewBZ4qeCM9YLcFYZbVSkIVloR2LBl39LE7A8+X/r069OeGvPKAPek R4bFPjTIBT4PH/Ni5NMvPff2tJmLVmcWfLPv8AkKFxONfFEK4T+FmPECVnMuT/Qn3wme859zspGs PPKYEqRFp+QMeck5dSDgQOByhICM62A6rf7WgNcMoqhWYQ8mE8ShvFbEcXhhKTa6QOBoZXVKfvGH MxdGTnjtju6DW3fq3vz2R1vcO6hl55EtH/SG9RjXpNuYxg+NbdrtaY6/7+z9/f3uxn93NfnrU406 9Ym4o/c9vUd6Jr42c+GybzZvK68W9k06WVVdySdFQzYEiaNFgkwGc6SOFv0ytZXrs7fotCY6Ny5n CJiOPksLQrFXmaBgFQltV6VJQWNBYBEcSTwRBszNqsCW7/cvT8r1vTjlvkExEXf2bXlX/7C/DWt8 77Cr7hnZtLOv0QO+8B7PhD88PvyhsU3uc0d08be4z9XyryOb3zO42R29/9JtyBP+5yZ/+GlSSuah Q4cMNrJdgmCyfAg1G8ZcVVldYb4r2EuiKapKczNU4NT71NfkldHn/BwIOBC4/CFgM6mzD2rluZbm axEJi+0ergisKfwudvK0vz3uv/HR0df2cLd5yNX24ZiOfZ/vMOiNNoPeDh/8YfjQGS2GfNZ86Bct npoZPnJOxMg5LYZ93vzJT8OenN52yNS2A95q2+eltj2fbv+w6/puw+/uM7LbE1GT3vxH3tebypQQ QZOwXVfXQCMhXfJ5uRMklZzLz/pnLvTSKAun3A8+d/5fKRAw2HuW1tD7ggAmD8ijxhS4GtiDSbm2 qrwW07CwOWNg4Vi4Zfdb0+c9NmriPb08N3XztO8e0/qR8a16TWrd99W2g98RdB32WevhX7YeOTf8 qVlhT37RftTc1k9+3m7oFxGDprUe+GHrge+E9X6+Rbcx7R+J+XMP15+7PtGlf5Rv4uvLE9IOHisV pOWzOmNSVX0S5ssdqYupJ9UMwW0YLY9CjDky/aJtOUtjndsOBBwIXB4QMBQp9HhqvYMzUaoiCLMl c6CyGrtcYPeBI+9Nn/XgYNfNPUe36eZu3m1sxMC3w56Y0XLorFYjF7RzLW/ni2/ljQ/zJJLCo5Mj fEkR3sQIz+rW7lVtPSs7eFdd44trG7m0g2dlO9eKiBHzw4fMavX49FZ932jd/emOXSJveXjYI49H zZi18NDh4xZpgnKiceu8mxAxQ7WkShAlktTKJGkGZ2aG7tQ2OddXEgROw14bCewTm/NyAmtD9eQl TsR6Q0L3PFkRqJq7fOVg7/hOvUe3fygq4uFx7fq82W7wlFaDP243bOY1rkXXeJe196wEdcPcgtJN ouJaxaa1iUlpFrXKwmrf6vb+1R39K9u7l7SNXNhy6JctB33c7vGpHftNbtXZf+sj3vseHf36e59u +X53VZVV58qKUoO3gqv8TIW1SnBnw5SF+VqPmHR2OK8Cyjk4ELi8IWBRAKU/5vzU9kCqLKpg/Q+U nazac/Do7EWrx7025a99Pa3+NrRpZ39Y38ntRs1s7VoS7l0T5ktv6U9v7kmT5M8iNfWmNfGktvCl tfSmhXuTW3mS23qS2rgTW0XFcx7uTeG+ppQI75qIyKVth88K7/Nmy66x7f7+VNcnxo5/5aOV8RnH jp9UtgvZFM2XWllEScipIUowX7FFhxArobTO74qGQCgOa0Pp8VOS8LK6JD7GJoNy3mPHjqXl5Lzw zofdh8e07Ty0eRdvi0dfFTU2alnrqLh2noSrvYKr4a6EME9SuD8tLDqjqTe1RXRGM19aY/fa5v70 8Jj0Fr7kpu7EMP/alu6EVv5kTpp71kQInq+JeGpBy35Tmz04qdm9kXf0jnY9+/7n81Zs3Lxd3SfA ZPwSLX4aRFWqaiTJEGSWllFtS/S9ojvUaZwDgSseAnXkiHGtk13yz6zoqdJVPLqotopVEox5yMGB 4+X5G7ZNnbX8gYG+393wyO/ujrp+1OftR89vFbXsmjHJ4e44qA2c9GwpwpNySlK2m9LSx1uSONG0 JtyzOiJqQashU//rHtd/39Tr0ZET5yxN3Lpte1nJ4QBO0cHZXlHJoZ9iWIaIwZThukKvNHFCA53f lQ2BUBzWlpruN7f1BhscCNsSC4jgNOGnBElqqkpLS3bu3bMyOROPqT/c2L3xfZERfd5pP3zu1e64 1t4k8BAGCj4jHJI4sZPBVfsYRFpB3Wb+FBKMuKVvjYiR3sRWnsQ2nvirfXERw774TZcJ/98tg2/u 5X55yuyC9d8eObw/wJriavyfUYNlCphUhRuhILPhyJYlxwiTVN75ORBwIHD5QyCUalmkyqxPhP8K QxM9F5YrVtwTVYGth8pnxuX8bVD0727oHvaA+7on3rvevaBt1LJWCPa+1Obu5JZ1PNciUzyykyFc IRpuutFzbQomnNeb0syX3tSf3siXFj42M8yzsr1r/o2jpv72lsFX3dQjatK7q9PyDxwtkUWXtTXK c4XLCs2iikKYrBZBY4N+LJd/LzktOBcEQnFY8xlMEGRQaVL30jX3hPMKrtSUV1Ycq6hKK/72mXc+ bdmp929vHnDdoPc6PjWro3tVe39K6+j0Ft50rDSkll7B0nAPthqERsHqOnwWxromiL3YbcR0gyIM 54UFB+8LSmPtaeFLaeFefbVvxbWjv7jqfs9vbujRdejYGQvitu86WFGBkCt2nErhv1I9je9hzDjI DOX2dLBB83MBw3nmQMCBQMOEgKFBp9WNEMrwWXX/sEJLkVG0RxHCq44dL4tPL+z6eEyTOwf9/oGY iMc/aj1qPrNa7dBMI1ejIIS5Uxu7MlrG5kN5IDJGC8DyLFNgdUnIlCFEwl59mRxRgUWncEPWhL5B 6Fp4M0lh/symUcnh6AuuVR3dy//sXtSi34f/3inyqk4Dva/PyNywtYypOTUy11aiwqh8YNuZRVSo 1GhByo1Pa6xz48qEgMHtIIaLVTkokSE+4ievNpDy0rKj3+7Y9cLU2c3uHvAftw5r+ujb13tXt4ta LSwVVwRfEtO4LTxrQcUwf3YzXyZyoI3VILCt+epJijBlT3pLD0ibDd4aHq039b43naea0iLcia2j VnZwLfuza0GHIdP/+NBz/3HT47f19M5ckXGoXOzIWJVqa8prK/HzQurlkvrjai3JILPDeQVIzs+B wOUIgSBdOmPdeXiyAoVSxr11ZLnQyRrMy81v7NroriGt+79+nX+ZmIJjM5p5xKrcijmvSIzD6S2j 8/7oEhplrG3G4BbuSzQJ/gsjhiPDl8kDNWvsN5w3uY0bvRiCJkRMVQyhVC1dUnIr79oIdxKcnQRh xCmr5YD3/uMvA6/vPGTW4niNBSSWQ2gq/1APIF9QJyVZnBrB4YwNdW5eiRAwuK1Hm+2WV1sLhUAI TLfHSk8kZuXc2WvIf9/8aETfV5koaTE6LtwnTBM9F4ZrOQSKiJje0peFfAiiBpkv+GlmUmyVNoi0 wnkz4b/ByRRVk0Fji/OmcR8cZtq3rTseazYuha1GLWkz5ItGfx/7m+sf8bwydXeJGJy1jui8YmwC k5XhIkaSrDmUK7HbnDY5EPgFQCCEOoW21lAqWFjocwb80ZOBHk9G/8+NPSMemdhh5Mz2/jiMZuHR KU3da6FUaKZKsjLD/ZkR3gy0VLGqCXuVxFSXnQzbVc5rMV/Do4N6MeqwbbhTm553bWtfCjqIKCAu vKOT+CjnV/vXtB8+O+zBcb+/rstr739aWiEzd9Aow3lhvmgIaiRXMubw3tA+vvLP61meQQPjnwDP BT1IJwKBSe9//t9/eqDp/ZHtHn+/g2dpC1d8xNgcPADB5AhvemtPals38l4qsyfgZxNERF82qZlX lF/Dnc0UidiWLZ8E45lgHXVuV3yrbGtz8ETsP+GeBFyjW3vXXB2T0taPzLkC1n/1oPf+/bpHb+s5 csve44LJFVifBKWptkmqqoPP8GGQ3fk5EHAgcBlCIJSz1q++WJuV87LIkCHOcdvekk7dhre456k2 fV/tEDm7bXRCc29SE28yjp0RsVnNvalNovDhTAuPzmqB67IrqXV06unkSLkw7LguCdXSZPFov8Wg lfnK3BmEC25LaRyb4QIdm9YqJoNXmnmSm7iSw6JWdxw155oBrze9tU//yAlHKgMnq42CIEdqLpzX NNPo7fWb6VxduRCox3mZOgEf0HONVFZaG3A9+zbeeiwe7zj80/auxcIHozMae1MbudaCwOHuteFR ya2j8KoS/BRfKaZOZPrDmgGxzmU+RZLgcNAhEAlTsBcLjwiQ9VJQ+ExuwaQMLlsxqRybRcY3j0pA sGzjT+zoWdrxiY+uunNY2K09czbuqdC5XmpuJ+0v5bwySe38HAg4ELgMIXAWzmtuw7YMs+Jy2/e7 r7+75687jegw/MsOkQuujY5vMXqV0I3oNFZVoPNCedrGpreNTmsZJWoplxjrghK+5XACgWIyF31B VQYhYuKvEnRWIXNTf1pjChR3UHt2GH0hJdyfER6TCVtngRKvNIlE7V3Lmo6IcVks32gbk4TC0mHI h7/6c5+bugw+dKK2WhZpqnszfs72j2Y4v18CBAz6ysSopSnKDgbKvLjGEnKorKb/ENcf/9Tl2ic+ bB+1lGmLVpEr0DpbusU5sFVMliwX8qHqWggsLFUZq/FPVmZqXBRAVHWjqs9/yWC0XXnLpKDNB/HS MPHmMWK1buxGgBT0bhOTYWTLcFf8n/zx1wz7rNkDMY1v7pW/6SARnsWHQQKbg9LGdfCX0ItOGx0I XLkQEGZkVANrTMsN/alDipwx0Vv03fZm19zR9I7HO4ycHeZa1c4niyNa+8WGhuKJpgBDhFKFu5Nw gkJ0h/KISM8dXRwE61T6IyqDYbvGWKfTuBbnZW7X4rx+nJnN7LAwX/MuOkgzdyqcNyImG84LT28b mwl/bxyV2DI2vXl0alPX6mtj4joM/fh//jJgQOQLJSWEsKwwzNdQXdMo5/iLgEAdVhvcliP3UBFR ePeV1KDtNrq+8w0DX7rWvbTZqNXtYlPB2zDW3vqS8CVo6U7GMx8cw6SjsyS6nkiRGRMx0WBsLwWw 2jgqGLXX0nxl8lemSDgKrhp1WBk3+Gzyo1mr7TqT5e0tfRmgN5IkSWxBDJyo+Gv9q9sP+7zpA2Ou 6zI8c/0Omf2B8yJMcqJDlIP+/0X05+XVSKYDCA1qJgXM2szLq/5ObS8CBNhUVPSC2kpddyP7pzCZ KyOao8b2KS+ryFu37uGh3v+rVbc2j3/a1h0XZKaGsARFeuWtopza63AtblsvgyFEhkxxrkky6Ity IpRH1Ac5UWYdejT51axnf47oHCxf8qe2JGqBL7GtZ1mbgf9odOeIgZEv7Nh9SNfzSpxJHQVCtKRt dvoB+FoCyQ/kch43JAjAocxCIYkorqxWkDn4Y8bkYElN1DNv/vrartc88W7b0XNhozbSBhE7FOVO PQ/m0WncIIafCVcFpU9DYOtOEMltM3UdSoP8zXFp8Ce1iFx2TUxSm6dm/u5u762P+uLW5p04XiIL 1Vk/pzZmaZ3xgA62zvnfQCAAtZEFa5ZGAxlxfg4EToOADGOxyDGRawxzXIuFWa3MhEYuXLfZ9ewr V3Xq+fuHXm7vE0n+bPTkktzHDQa3Z1UlktFQWkUntRm9KLzX5JZ3Pvni+7N37D4gmw/K5F4VTtpC hPmz02nAqH/D4bz14XHZXIG+9LgouSge4DMnumVW4NiJqk/mxXe4f8jv/uoOHzEbbLHMyGfnkhcZ q9V8lNoqNiXMKzGyWKbXos8Hje6KHOh7Zf6yBGmSNEZ6Qv8rD75s+uWXUlG6xvk5EPgBCAjHFbbL LqO4oIhLFeMaca2a2bDAuq+3DfW/3LbzsDZ9nv+TZxHR8xoa5yU0pTjDiKK9hkh9KAtX+xOIWh/R 44VWf33y0/nxO3buVs7LEkihw/JzBoaC4Yo8mL4120fSQORHkSS10/ftPTRnccJfHhwa9vDY66Jm X+2TAMtgzkXmref+HNwWH0JmcAhBGeZaQ7DK6z3Lw3u93uSuIQO8Lyek55kGEoZLVx84+lRDxGIC odjVMpGI7EvnxIGABQGUAjFfCecVYZqBbTGmqt0HDn/45fKbHvG1eOS5a6K+6uBZ3poFRA2MUjG/ zHwcnjCt8Cb1JODWwuxzG0/cjb7F/32P+8GhE+ctTSwpOVZTjb+zqL7ysxpoLpzjFQUB4xAY3OVP CCDiFv1eUVmbkJzdb/QzV3UafF3krLDIJWzV0SZaHKjOzQov5lMqgzDQOnptE7ypY7JEyh258hpv wvWuheG9Xw772/Bn3vl8886DIkjwYz5IYrg6vwYHAbMkUxcz6rS8LM10fg4E6kGAwMbKbHEJIDAs nJcAthVMjFbUVi5MSOsybFKzzmPbRS5El2wZGdcm+gxzuxeTNJ3+LabMmBeDZMFwia2BmsDiJu40 j1z1J9f8X93QDzNdwfrvECqM7qNjAIJsUj1QOBdXAASwx1pkzppGkain8Ketuw+OHPdqo1v6tOn3 evvoRNYH4b3cdPTq0zHqEt4BjQl13i5WIqY28aS38qeJx5dnDTsiXR21oPmjL9zUx//69K8I3Co/ aaqKyldAt12JTcCWaJpVDQo6PwcC9SFgKJU4pUjoRaZD0Q8I81O1fuv3f+0X+d+3D2039DMUSaED LKF1r7mEdOmMn8b1lOldnEI1KJAcCYPAYg22jGnlWtmy12st7xn69CtT2MGwXD1vQtwenOFQHxWu lCvxo7N+kD7xs2Jfj9emzm5z36BmD4693r+kqSuhsT8bpVImVRvMDC81gfOGueNaulabJQDNiaEa nU7C2znCG3/16Lm/v8/1p4dHLEvOsyZ8Hc4b7OkG+B9boqXVOJy3AXbPJa2ScFozCwbDFXc8FaQD ZcerynqNiG3x1yERg99v549juW6T6BxZh6shBRoQsWKNBmE3opOY6m3BgiNvBkmoVnRGE4J7xKy9 zrMsoueLf+4W5X/hPY1+Kw6Hdgpqvo7+e0mx8EJ/XChe3Q9jTvXHsxbdPSC66YPR17kXEKoCBEY8 I654i+jsuiU/DYEF+5LbxrK8SJbjEZqGpb6NXMnIkKz/Zdq3rXd1y4Eftuo+5sbOAw6Xqj5lLFZ1 jXXOGgQEJHKPwUFoTVUt7vYNolpOJRoMBEI4Lzv51Mhax1oCQJUuXrv29zc93HHwW22iFrLld8TY 3MYe1uGmNzQdQVya/YlhMawqYv/fjDBvVpgvA2uzBvpj/98UtmO7dtTcRve5b3x4eFrBt0gWNtvl xOG8DQYTL1xFIHrVlkbIPzCczaPv7vlE47+NaDf8kwhfHM5LEoYUU7Mnq3l0bsPivF4Coq6lbiwo RjxAgGSLruYxaYSJ06DoyR19ceF9327aqd+L731qWO+FA5xT0gWDAEqMzXlBQcfJ6oJB9kopCLqk zIjNP8vlDMW3NlAaCHS4v0d4t7HhT37aypdAkApZ5q9st6GRKeW8a5r5CcQnAf1aegiykW6WZxKR D6MinlcdvHEt+7wd9vfIvz82AsmCVsp+gnq0Oa9ZAaqXV0rX/nLbIQIV/WvWEzF3MnrMC+0feDKs /5vNIxcRdIVIpzgKtnWj+aY3cWc2MJRmYa/uqiAL25MJ5kYCvSXgpFv2EGnjS2k74qt2jz7X7Obu 2/YdVbw1Ycmlv3HpMb9fbuc3mJar2quSn2xvDj46PwcCdRAAIYhPJWjBhFGFeDfDmN6buajRnY+1 efLDCNey8Ni1cF62/GPUYwFrQHZmtQ2i1UKXdC8kJVkeNmWD8+IguqZF1Oqrx2YyU9Y8Mq5j1MJ2 j73a7r4BM5cloSnQXvEkk/+Io9DmUOW3DjjO2eUIAXX3FfOemUbJ2bDtmvsHtHlkXMTIOU19SS1i szCPtHGtvpqdETQCsx3LpWHgdhrbG0lSzts0OpnEfAor5tr4JY50i6gU1tR3GDKjyT1PeZ97i9Fq 0BhnWuNPezl22ZVZZ1CQxEEojPNzIHAqBAwbsnhRTeBEeeCGh4Y27za2NRvgmilU1jyyXQvOHuwT hIezCWDbECbFNOCVxJnU6Hyi6up+5YbzEgmQNSNwXi6v8ccTEr/53yLv7us+EQytIHyXaW7xPzwz 5yWDyXMqyJzrBg0B6U2meuk7ArKNnjC58d14CU4jaEbTGDYYSmMWVXVedgjCJf6sYaYuESNOC3dn y96+IlJizFnDZIoVApq16kR1c6W29qV1cK9u029y05u7bNt/0FqibmGydIyj9jYI9BSFBrFIPVcb RIWcSjQsCIAfldU4AQgDYpeBuNTC/76xb4enZoR5VzdiCxVvPLF0YLskKAB7rzQ0zqv7L9h7LkjI PlgtiUVGbP4C/SS8c0TUKrZ4uHrg27+9oXfm1zvZ/IVWk/gZQ9AZrc12nobVYU5tzgkB27JH9+3Y f6LN7T07DpgcMWIeRuZGPrbQWisrvmVz50Q2pidWcwNjvmzjKzqvbKkgO3Yp2/WY5XKr2sYQ1Tmt mSuljTftutHzfndzr8mfzCkNsl6j8zps95zYcREfisKr2ylLhE9DbC7i151PNXgIWPxFFj8GSk6U DfZMavK3mA6jFss8KZ4e7IzgWyP7k2JtZmNcb8PivGKUC+52ZBiuHkWRQbUxQgJ3ItwJ7VzLO46c +4d7vf4XPzR2yAoWLuuAEFotJ6dqvhZkGnwPOhW0IWC6rAJHfQ3K9tmCBBbwdhgynUWyskLWmyEK L2wXV2HW7wjbbXCr5JguwQCucyhwXpnbbeVOE9HXl9DSH9/Ut5aGkKfd6KUR3cfd1H3InqMnbWED ODjOPDYyXOqTGgkDKGwXa7MSmktdIef7DQoC6H+KFjJPtH3/oUZ/vr9937c7RMXhUtXcn4F5GT1X d11RuxwbEzQwA51YmNk68LRaiVdYtASfb+7B7JyMgfHqqFURvd+89q+PMRJ0TtvMw1gRqh3O26DQ 8qdVBkwWDzp5WQKnPDjQG9HZ027EbNl9zysbUwojYysir0RfITUoA47BYWO0MaZmWHCEO71NVCbM F7bbLDq+cUxyi9hMbM7tIuM6PP7ef1zTOa1gY6ieazRfc/xpMHTeukAQkJBEuqujrhi5QIU6xVwZ EDCUSoyvNTUVFVVfxSf/W/u7rx8241q2+XPDZCUwI3ou2gEqcIto2dGsQfmCQqbauLHFsfOaRM9g Fo8JMqVd7KGQwZpNdb5KZoYatZec7Z/8tMn1nbML1pWrLxnNF6lDHSEcznsFoDS9WaHz+IhT+4+U tri5xzV9X2YfwDAXi3TE+x0hTXbik+3/1jbxsU+fLD07XWy7hHfUaLOmpT+OGV7MzhGu/DZRua1c uGHHNRu35qqxa5tIPOfkjq6Ea0fO+tVfBjz/zicVFdB262f0X4fzBuFxaf5XVhq/zapAFWqvw3kv TS805K9CqSrF5srWYzUHDpcMmzD5t7cP+lPk3DauBDgva2NlPwKvqL3h0azozzptFUadslmPgskm 4FY43OA8WsgupUY/1TwsnTD7n5KfEuoVEpyxNZwUiqR5TDnWd5Xzrjkj52UnX+xyzO4187DXOfsF J7eMWntd5OKmtw144e1PSghopR3DLhH8t+x1yoaVBcszrkwezegcLgMI0F+ouuKyUFU9f2UqHgvX PTWdZWUSm8LNDrxsIU3QKvEKwFHfrJa1JEnFRoNplu6pthTuyKXB55Cj+DxowGdeD8Vbc6ncU4cA r4RaY7QExXnD7kFjxWS5Lw7M5kWxgfvjZSURvvru/FZRuWi+uDs2HZP0e38i3he4WrUZvbp91NI/ dn36nt4jDx4tkb6pxatMfqf3UxCTzXzK6c+dOxcYAgRvsSKHO9bmCwzaK6c427no2x2Hfn9r/9YD 32k3ejHRYoWGWFOoEsUdamCtmVVaodQGoiFzUsoQNdKOR/RNJtEw8KIpExAggs3E3XA9ZmOzm3mJ F2S28xNiJYTFl9iMCLosmlBPEjRWcT31pfKi2LpFmRVnmAgXs8xpBI5G9cYA3lSjVIXHZGJPNlTU kEdD9EIInfBo+ZChnMLHU9q7V0T0fCHs9j4S+bZaNxnHLFkrlskgwVLqpBdBenXl9PUvoSVmiWvJ ifLew8f/4f4x7d1LWrhXMWnCjAmmZrNaFnQCGUA2PBmYOQWBESxbsM6IBbP+zOaIajGpMDs0Tc0J W8S9gaTMEVz1xbfyxhHOEQTD0sKSW8oxI8IYXnDiwoNL3RFlrlaSrhKiBDTZptFrZK2QjK9MSXjm S5lxRPmo2zvJesUMMR1lftb3yRI/tqKGQfMJzDhs/fCrazsXb9sr6IuTpMFb8dkIOhGqCwPX+Pqo 5VOkkl8CGlzaNmo/GEpSVVt5Elf7S1sf5+sNEALGq7myumJl5ob/94ZB7UfMauddBZ81fBDrnJAs 5bywOeXFRlyX/evrOK9/DZOqGltSAtHrciT8staGRSUK6xS3EJllg/5gtSYaHslwXnJq1GU4e7J6 KROgMrlpFKtx17YmYq13DYuDWvsyIIDQmZaeeF5s7E1t6tapOtyt/ecXd5c9jK5+Ytp/XPvI11v3 BWoqxRbEvojqA8ExOF4sCgaNEmuA87vMIACdqz5WVt3o+q4R/T9oGbWyZbTwO+WGYnMmMW0KkzWc l6iM7MonrJkpCReCYmoTV0IT4WuZrVyZ8F+RG/2JYvs1PBQ2jeeDl+XAiQwBsFrWtYnLFuMCPg6e pyMxwnnJz31wXv0QDGuWxbk6hwu2C+dFq1XZVZRcI3+KoCjCrSTl5mIIspOMIJbVa01Q5DuyJ8hN vT5bllxeViER142roCj9isMgtNreRcx0OO9FRGNxnrHkHzqiqqyU6ETOz4FAPQgYDDl6ouTVaXP/ z58HswlvOx+WLqEMJMN51Q6GFyikgGRkeGG7RmIXouSPR1OQsBX+LIx4f4xOauJPaO1dQ6QgDNdw z8aeJCLgyV5+/jS4p9nRAMUWyibETVykJOoyxsBmxIePEWfOtqi90Wuv8iah51IyangE/H1MWosY 0ZepEkqxcn9LElCS9QPncN7rRs/5f9r3+HJxYk1FeUCnYwznVbYLZGC1DuethyGX2wX7bFWt+27X vza/9ZoRX+CZD+dt5k0I1XkN51W+KdaVJpESyVlMNGJayWwxJrVJTKrwRE82GC4CoazxMVqq4jyB wWUgMDoUdeHFRLpgsY9LRFMS2EtRcGH2ZcDaYxYKGZMRbyEDwGSlTEpQUww39alktqTZEBu1xXZ1 etogOeIrIxRhtYN70VX3Dnsy5sXDh0pkn09LegSBdfeTUzivILaj814MdNb9eWtOniwVgCPhn2kK 4GLUw/lGw4YAA3TfkSO9Ro3/n3s9bDHQyhUXHi1kAZpzJs6LBG5mr4T5CinAEOePhxoQ1ZkQ9DJ9 Fp3Y1J8Ar2zrwbUpiaW1EbFphMOCQLHbEXuPCufF1wXVIyojIiorzJ0h+x2IxrG2EVNyYzJaR61t MSoRAth4TAZKLh9Cwm/uiWd9cXM0DrZOk5B6lh3vx/Bck6eVN75j5Fe/vf0p1/g3jh4+Iloum7eq 2n8650XhdXTeho25Z6gdzkUl5VVTv1z8+z8/0nHEbGFzsWsbe+LFQhu0NodyXuYsQHIJ9+1OxdIi 878xa5lLFanSmw33BFct3qdcVe+LAQdeCeelTGP7xX8P5ktROmTkRN71SVgMsulISTfnuCWgFIO9 jCOVaRlNov828+aSKJbLUJQ+nfMazFfOu6Tto+Ovub/fnv0lBplBWbHViFetxYbhx6rzyv1g5LYz wM25dQEhILAP0XmtnriAH3CKuvwhAJIwNncePNLhnt5t+7za0b08LGo1c0mG80IEVCwXHVMJAlRI jGAqcotrE0ke+ZJlPyNfGrurNHPJjmatomHH6czJ4mMMcUM/RSmGR2PWo2R2N0DDbeXJaM3mg650 4vZEeLNg06jJ6LkURaAeHDgbIwCMy2rmFsIVHpPaIjYJ/RrOi7eMOMyo7iBUKERBOPc5FsI2oxeE 9Xiu08OD9+47ZKjTyapK0Rb4KdWydd4g6TLPnOPlAQF6bd/RsiH+55vd9eQ1o+azA2/EuAziRsKn jEEYXApyXrHiYk5p7c+CJzZ34X/FJEgyQmNzdr9SPVRGgS7+NSqz8lkxLGtRlhFYH4kGSgqOCJEJ uYTvC+uXsSPWGF6Xlbm6PtdovoK9smhX6gaLbyxcvh7bPQc+80p797Lrh7792+s6f/e9IDNtD3Je tdsIPstN0Fsx3OG8FwmHFfDIgHhamSW9F+m7zmcuIwiYfcM37Tr4P9fc9+dh0zp64sI9Cay5OBvn tQRyFdfr6Iz6q4TFZreKyULVvdq9orVrGdO1jd2iTfAKKq3s7eteEeZZTuAgpoDDo5JbRa1pHRXf Kio+3LUm3JXAK63cS9rgfzJqZVvP2nYxmRioWfchVmhXSgv36rDohDC/eL+Eo0q42EyNZRdiGD8H dTrlEeSurWfl1YPea/ynv+/cd4RuYl8bdN76nBcCJR1oSNZl1JVOVU2XfX/w+F09hoX93XWdZwUL iDQqheGM1hSqWoOFFYo6KVGtMpq7MtnoSnbCda9u6V6Gs5M+lYgWzMzCGQXVxYZs2K7hlRJUmQQH 5L7OwiCLSuKcyVzEPImUZbwTLQ1XXhSnBZLKjeSkDsp54fgpiJoi1v44SZLvMtBujPzk3zt2Scnd VKHu+obzgtaCviFoLBgul47fwsUYJUDabLmqdgbZJvBifNX5xmUFAYYq4W0z1m/+Tcf7bhj1xdW4 jviScHMK5bxGMleea81MMeolmSgWKre3+P/b++7wKspt7z++7/nu89xzz70ej8dKSUjvhSoc4SCC gCCCSBGkl/Tds3cCIhYEQZCiNOnSIQmk995IAggogvQaKaEmkEKY77fWO7MTOODBewxk4wzvs5nM nj3lnTXrt/rS56DUFSDSMTTFQ7Mdwyk0wSkszTksFXFWrdFkUJ/nGrrDPWiza0iUa2isS2gcPt1C t7uFbnUNw9jiqtmA4RK82d+Q5BmW6qHJxk9aalErvsgd/mJtgocu0VGLDBGYBIHmRa5IejJSqNWj D6ghaM/qH7b+Gfceh06UQ+oQkRAyX5JZk/ya4C8ZkW3qgf6RLxaPDJbVoxduOHcd4jdypq8h1S2y FDEG0HlBJKBYQcMASgxQNdl7LRwBpSdTMDl89al+4UkuITEgFbwCgF2BvIS5HI1ADlmKRqbfoq6F wErsLCwwwFN8JTAUK9guzoizY3/ANKAc23nQkQn6CWopzgG/wsCf8sv1CITtbkrpoN/8Px3f3xCb e/VaFciVkRckABq2DisIy1j8R6aQx3PvxDruIl+RHgg9ExV5H8+8285ZQCEYV2/dSczf/WLHd9uG bfZgDxTDLvl5mScQj6LB/IHZAsn54k9wIaFTuEcUA3nbhGYifXLgnIwJywrGLt0z6ps973yW0VEf 7RAY0yEiY/w3JcY1+z74Kvd1c9TYxWVjF5eMW1wwbkneuCU545ZkjV2aOXZpThfturHf7O0ZnuwX tNPblGenodgYL0PKsPm7+s/I9DVmOGkpNxMM0MVcRqr0vU6xf4HCuAtDZqfwnf/l3qto3xGOSaHX g+pqiLmQ+RU9QnmD7TxN9UrxyIC8h85ff8G/f6dJS9y1ya0RMBBRCBeGIAy25VJgs0BeUDUQEyEE cHygdZG9NqPzp8XvzS97zRIPYY8wkXOIiOYF7JIpmK3BAnktpKXiIKTJslWZDMsc0ixHNeM14TrM BMHh2di5ZQSpw4y5pO0KeUBALem/qNUsZFpZTqAdfmW4haf76bf+pevEeat3nr9wTSAvp/RaYRcr jSgZE6QuTT8DwqzPk00PAnUkm/6c6hlsaQYEuFy4Vr0yOrlltxGI+yWhnU3HAnwb8xkFakl6tw7A LphJywiI6xz5DM03aNP8tCM7vz+b9uOV2LJzy+N2hcxe39+82rgsL2lPxa5j1ZuzT4cvSogtvZCw uzxh34XE/ReT9l1M/v6X1O/LtxWe6qNdtnFv/YzVe3sHr/UO2gHbXeuQ1O4zChdnnJ0Xf8Q3OMpD T/lKhPim0tam315Ty5znZ4h5rsOg6NTC29y/C28FRVKJuVCR15bo9/5rxTME8u49efE/PXt30az1 RLy9sRg5sGQ0ZtVSgJ1AXoGG6GHkoEvztBQ6aDLgB3lz9p61ZdKgjxK9dMkOelRvS4HlGfQGdzCV REPCLyKpdFnwjyCkEN4QYLo7kFeLDN8CRDggpY6qdrCR2VGbCZcK5QXDsavLRmI7yk+1iixqiXQk ICz12y30QBZSSAYOCLeLO6RKXTpbntEXrADjVzBXfIWIQR/Djmd7hEV+uebU+ctMyTwnpPoK8MV8 0B8Y6vLYZkBMODrREOzeqVVLij22mbehE4FIzldUfb0xtkW3D9pqycgG7iRgVygIeMexBVArkJf/ JOQlLZjF+5YRhS0iihBehQAVN32Wx/hVuy9Jx6/dyT98peDnqyev1R84c+2bTRnnqqSfT1QVlp3d d05an3kieX9F1uFrJWfrDl2XztyScvafz/3pxvZdFwaaV5xExNcNafqitF6mbR4hZLV+a1bOgetS wveX/IO+cwpNobAupBpZSlsifOuRI1LEjUAZ8dbHPNfxvY2xmVXV9KDI5Kwirw2R7MMvFcQMYaro 0Ok/eb/dSbMBQhpihn8deREw72hM8zDnIdLAPTzng2WHdl+WNHPS/EO2u4bFIW3HJXirW1icuz6V ANqY/saUzE6hMV6h8c5hic6GpDbBMT7BO73xpyYNoOkQkuypT3YN2eatifHVJnmGxHsEx7kH7exo SPHUJCK9zg5nsWQ7auLcw5I8ghNcgxK9wxJ7fZLT2bSznS7WS5voqsuED0VowQJe8Uk5vA9SfuFE 9tTFPttTr/n4mxOnyxuQV9A1ga+KvA8nlyb7BlALUuTcItJ4UdGqyU6lHthWZwAkcubijS++3fJK t9H++lhI2sAyHgS4Que1Ii9sbiIyU3AGNsEVIXUCw8VS4hKW6RWc6DNyyY8XpbVxpZ3Hzu4WsGhF 0g8Xa6T9P56/fKk+0vx174GWwC9S3/8iq33QCrfRcwd/GrWu9FL6oSuvjZ7iPvobt0mr201YeLRe ulojnamQdF/t7DBxgVfAundnJh24Wp944Ix3wHJXPcVfweAM5x0SQPgif80i15hlYWdkE3sZdr7Q edjyjbE3b9UJ0JWzh/C2yJqC9Wmqr4x1KmxgBQ+wpv5OWtnBP/m/20m7BXKgIzoDynIjEbOgFhnX hPRoyXG2IBofamwGwHTUwj2nrkm6j9Z3DVzRPXJnN8OGf+i/62XZ1i5wtXfg2kEzUudFHQn6PKG7 fiuShTsZN3Y3bxwUGf26ZrOfNs5dE9s1MhmelNf1a94wrP578FqIjr0tm7trV72hX/+adpNv0Fbf 0B2+Yds666N6m2PeNMZ0DNzcNXTDrJhD2sVpA6Zs7xS23V2Tiqh++f1SbM6/grwe+vgX+kaMMXx2 5MRpot+GpUHnhcZ771cNO6lrTTEDMPizPE+wi+OLz6Y4kXpM250BQM/J8oqPF619pdtYf0Mc3vFG sHsf8sI7JpC3Ic4K3Izr9uxqo831MuZ7BiX5jVp2oFzamrqvR+D8IR9v25B78sR1Ka/05PUq6fDx OwHhK7uNnu83YaV7WJRL6JYhCwtXlVZmHa/rNvFL77AE17DELro10HljMn6uqJRwnLGfru44Yd6Q 6Rt/uFiVsP+k0/iFzgZCXhgMkWGE4pOsjP9m5H35tRGL1myprCJzM2BX5kv3syfBu2z32f4Rrxwm vvjc3f/dblhH/XY3fY4TalmQu1bO6xFeEhAtC43sN4ngHvSGDMQhu2sTR88tPntZMk9ZGjo3PvOS FHtYOlQnxR2oGfvp5onzUrfurrpaK525IW09IHUJ+/bDjYXf35CO3pSWJ53oY9k+Yn7hwsxLa4uv Ru+/cbBWmr5hX+YpKee0hH3KKiTLqoIeYd/9PXDN+HkphZeln2qk+B/qewUsnRdz6Pwd6USVlH9W Ct9wzEubhKx2YW0G/v56DCF8QwhvfmXAR0ODphw5elw8b1G2gWkZCi/pvCryPv43QSAvzkt9G8Uj efwXoZ6xGc8AxLPT5RXTF655pdt46uqCLgNyvKUcvQydsZHWgHWqbUWKJKkMVApP+HldIkvQksBZ k+k+bmX+8auVknRZki5KUoUkpf1UMXFm1KqsX87dla5I0oaEg/1Cl3qGRtkHRQ+en7+6pCr3sPTm +G/8A2K9QxI6hiz9WZLGmdct3bj72FUp44fzmrmbRkYu/OnSrfgfLjhPXkmF+wzU1tzFnIk8I7qM BxniHrgRNwLbI6zNr7w2fOHqzTcrqeDAfcjbCH5V5G3GhPuQS6utrY7PLf3vdsMR1wfkpQQ0JlQr Gd/rNwHs5rcOz0P1ZtSV8tanTFpQfO6i9OnHSz5ZHn9MIjTcknf2bKWUUHB0e/75/MPVN29KRXvP r911efz8mGuSVLjnUFLO7oq70lebds3Zsjvxh8tnJILa729KK7POnpak07elren79/1Su+ei9OGq og8+XH8CIuW560tjsn6RpKj8Mzn7r1TelQ6euRlbelO/4qC3LhkeYQrZ4iTfhyCvCPSi1CRG3mlD Ai0/Hz1CUwJ6BtmykosexVbkxRZe8J26NPkMgKlivsWU82qTn1E9ge3NwF3pbPnlWUs3vaQgL/Ut JTMXTF5k9bKyLIFlVGSe68NTCcdwxIqgZyiBL2opU+U9ba7jmFUl5TW7j55Ym1SwKDovdO76t/SL 2k34uu34RcOmfVd6TkIN00Wbi1417XTW7By6IA/Im3FQ6j1pebugeF9NIpAXHC9kVuqbo+Z/E7P/ eLWUe6hibVzOoXMVO8pOuQWtp7bmBoQ3o0ZWJmrX/ybkFfcC5H2x85BvN8RU3kSeO/7BJMRvicyv rM8QbAq8S11saAbQpOh2RsmB//Qf0kEXhWgoZOkyGVPIsVB4GyEvGZ8hScIB0SaiuJU21SMsfuL8 ouNnpWkfLZq+eBsw9I1Jc7oMizzyS11c5vfBH63RfLTm0MHLQdpZnUZP37Dn4m1JKikpyyvZX1Er ZZRdWBe3N2Xv0YzD5e2GGzuM+uT1iXPOS9LqHWX9R2q+3pqUefji4viDHy9PqbwjHTx+ckduWXm9 dOyaNHTctFPnrsz+es07IV+3m7hGIC/1GeFWI+IFFK9eo88G5PXUJ5G1WT/92LFjRMU88CHHDSo6 ryBwdqbY0NO01UuFnis/ClXbtdVn+Biuu7784tWF63YCef30ieQL4yTZhyCvXJkWTADyNkIrqWML FYGnsrfOunyH4CyPiRv2XZVWJpf2Miz3D/q2Y8g6eLiGfJ7UL3Kb/5gF3cbOvFwllR27+rplo0vI hnfnZqzbV5dyTHotYCHl9obt7BK66qd6SbugsMekNe1HL1tTWHXshnSzDiWWq1PLfnab+J2dFuX+ diGZl9qd638z8qJBA2KbkUK1ISa5inVe8sOAMSksC/8ri4q8ykzYzP+IZrmN5PT/5z0IzS494DBF gUel1tl9yAvMJUkMHa9QbA1lW/SZCIKauLD0eIUU+cmSD5dFH5akbmHLO34wu+Bw5dbUA7p5yZqZ cQeP1EzWfoU8no17rl+uljZvi125NePrzXn6GRsXrM9N23Nsc/7h9oEL/CYt7TZxYbkkrYv9YeC4 qQuiM7NOVy2OP/T15lIgb3RCxqL1iQu3FM9Zu3/wxPlnL9bOXxn9j0nftNVEe8HdDMEStWUYeR8S 4dyAvGi/9WxPo+ajeadOHheGZVAy3CdAXuqS0Bh5ibKxRV0exwygfJU4DWRBRex5HOdVz2EbM0Bw U3/x0rVlW5JhbfbTxzIvouq1yEwkliXrvKQvYF2EVHERWrh6UdiHqvSIHEY4Xj0MBQiychq3IfeC tDT7TNfIHW6h0e6h8f/4MPPDnWeyr0phK3abl+dfvSvFFZ183bLJLWzDO19mrthbu/OY1Clwobcx 1lWzs1PoWljNJn5Z9I+QqPbBcZ1CNs+J2n/qlgSLXNyukz6BW9BEBsjroEPmBRWCxmU00gVIQ1eu mdQZ5q7EYMUQvLetYccL7QdGJ2bfui2aI4BRyVov8yt+dDKbUjmVbRCycpUII63+/ti5/3B/p6Nm K7KKEImHyjDsFiHDMim85J6geqQCeZHGC4suvkI/DuibYxaU/XhdCvpkVcTKpIPQecO3eI+cl31c itl1MfCr7JC52T+VS19vKjatKJiXePi6JCXk7NN9vnZV8uFvYn5YlXgoaW/5mrwTnpMW+4au7xqy 6pgkLY878k7QnHnxpQnHbn++eU/ozO2X6qTCH3/Rz14/Y23hdzlVg0NWHL0obc8+HLF+36B5Zb7h aDWCaudZjLxoMkJRzTBDKcRsDWkg8MUb6mdK/Et3TcQXS8+eOSWXZaZS5A/SeVXkVaikqf/HTCtR VWAsddXVsI6oizoDjWYAJHLn7o3rt3dm7nm2wxAf3TbEeYq0RFEHD2+91ckL2GXk5chnNDjjdgmE fdxdF1K6J1AvLNU5MCr2ijS3qKZTeBySL7x06V7a+Elrvs+vlHZfk+DtOnhFCv4qr4M+2lW7beCi osXfS1FHpNc06/1QpSostr1+yx5JClz8898RrBWc4BEU9dqU7ZExPx2ol9bvveMXFIWe4EiZdDDl oMqlGxmcqR2b4Et0hVzKD5cNZzQK4SqV7Wk7uC7yOpGG6afZ/jfvfgVlB1G8C9BL1ua7NZyPQnKq LKpiZohTqYstzQCRsyQdPHv1Ge9BHSavhj4I+kQTQDj30UVXVL1gAVK056NCMUQwEDKNye6GBM/g 2HFLDhfdkMZ/mWRYXfijJCECud3YpSlnpVW7bo6elz/i87SSS9LeCinvghS0IDb54I1DN6XSi9Ke 69L8+ENzdv647cDtb0tv+gUu9w1Z19W8/XtJmp1w+vWQr2fGHUo+K1m+2/22adW3WWcO1kg55dKu q9Lawhs9A+an/Fy3+4pUcFWanXmt27QcH3MOSqrSC4g22ejVBdi1FFPLJIrBIDGSboGEyULIvb76 6Oe6B3+5Mqb8l8voNQ3wramlYv28wFeCGEIKIFRoWZUkHwc9Y7Ypl+gOuhShkFVNHfVEUxd1BhrN AJEItYgv3H/ymbYDfXVbELZEMjZ3pce7ryAv65KMawxz6HRvbeoNJYKagFOPAxQEMKS3CYjqPa+s +4xcX11cW1MWolzc9ekdIqIGzokL+CoxZF7amM/zu2riPXWJruHJvpa4N2flDpyZ5zt5s68+3UOX 4ha25f2lP3Y1ZLUPyWyLuhxaFDTY5j9lx4Av897+osBjchTMcWRnhuZiyAT4NiAv9Y5RyhNR/flC 1J//J+TNdrPk+QRvet6774GfTzPcoo8XGBXeEaptjjXy7BKfkrXgRpOlrjb3GcBzwzM9dbW6Vafh viPmeWh2uEbmtdZnw5OLrHMgLywkMM6Itn3CdINKpGQ8MSS56eN9dGkdTOmDvyrtbNj8RkTU8LmF bSdt8A/YOHBWZu+PE7uEx7YP3frezNThsxLHfJnSQ7t84LTNo79MCPgma+SchL5TNvaM2Nx/RuJb MzO8Qzb56WKQ1fvOwr09p6f6Tl7ZZ3rigM/T34iI8Zu0vGfk9lEL88cvKRo5P/utaVHtA5YM+Cjq /dnJI79M7TMttn14sgcCrXUZ0HzRkEsgL67/XuSlGAxCXlNGO/22P786am1s/rXrt1jnpeRRQl7M BUgb7QIJjxV5ElStLk0/A3Xk5oVMT4IQPQWr4NP0p1bPYBszAAIhOVk6dPrKX/0H+IZudDamo5It kJcUAdnazL5d7iXK8ZYiQYPq3OLdJ9sdd8uF1Q7ZEMQu9GlOYbGehgTkaLho0hxREZeSOOKdQtZ1 0KzvrNvqM2mLd1iyAzoiUfmgFGdNvGtwLFRjGNbQz8jZmOgQtN1fl+0ZisI+efDk2hkSHAw7nIO2 eIXt8NSmIXy6DfdFwidKBhELgjIrR1zLOi82wn6IjawjEBxDRyBTsxl6RKb7+OWt2vVDRDerBOBN +J95lIq8tkG1D71KkDMe5Lmr1a8ODHR6OxLGFpg4YLRB6DIkMTIpc+8DbglNZAnysDOWtDahHgsJ kNQTISzdMWiHly7WQxPtHhzlg+RxTaJraLSbdgcqungZ0pwCot2CtrsFbPPV7vAI3uIeRCCLFZR8 IaAPi3PRJLlAJkR8MhL0tJnAUBSx9DbSYXEolMZyDt6Bg/joEz01cR4h0X76eHzimK4Bm3HBEDVR 0wPVtNiZQg0dQOeCvJmeKacA5C2QF/2mOxq2/IfPoPSyI9U19ULnZTlSTBEmA7StIu9DCaaJvlAq ZwB2SedVkbeJ5tmmD4vmtLBGnSi/7tTtfbdxy1zAGbhhini72bwsdwPHFtF4hb6iMrbEu6AUM/jm orsB6kqRW8qQSV0CTWlo+Qf+Y2/YhXYJqBTkbEpy1+301MWDfaHaHpr5olEvmc4MOe7UroU7iVsK kSiEen2ISqV2vQiWtqBWFQxuKd4WpFsme1LwSa6DZZe9uQSH5WamdBArzgq1l/gSx7IKNgXkxQAH BndFR6Q2Q79o12fUuYvXamR3GExDAnlVHmXTtEwXD/A9W3FjpGa6/ZshPtp4kvoiClrD5szNCGTk lf0mIAlQ3W70rwcuk0Vak4PIPXdLnpM+FQTsDELlYCcHQyooh8hMmwVCohJqmnTH0FRPUw6VfAxL RZFnKsShz3REYUmK2qI+mK30xWhwiXW7MMQiUidfpN2hyCRWYB2yD8ULQoWz2oThOLko+iGOg6B9 8eoBcxH9RaNRZRuWEIi26cUxFqKeeafQ1X/y7rfvxGWq2QAmz423FOOmirxPhp5BhJRYZNV51Qjn J/McmvlZyQ1UfqmyzwfhLQd8htp3aKELHUFgFt5uRIeiQjKMXXCZUS4tdz0jTxOBL6EeO4Lzncy7 7A0FJJ8b0YoXVfLS3aYQNJM1L6KUNlJz3mwnUyZsaHDUAqbBUqhpuL7AFT3E9YWtLSUtSDHJdUIL GB12Rt2/0leMhQ6Ru+yhCwNMtZmAXeQuoecvynegaDOMyQL9wVfR5wVKAXFacvVCKcBPyAcNzR2s kpG3EH966aJffNPwQdj0C5evQzugdwSDkBfjPuQFL1Otc82ceu+/PKgZ16qqP1u0HCnb3sHRoBZr rTNBGIIYsM6kC3orISkOEGwqAF0J+kHFZsRloR+lnS7XOWKXSyRJiWiCSW8ByE+f7xlRCgsPlbxg 0iJAN+W5cZshCtkyFLhGlFIQFyrPhCMgEH4QhFhjO/4spm8JiAvhoCEzkXDTmPJwYTgIoaqZwq3b EHzDplRMXYNZvhVGG/pUkBeObJ/Rcx26jzj+C6K9QK2ybVmxb8oELIicCF2l5/vppUn+ppmmhXVe 1dosJkP9vHcGYA0BncBJNGX26mc6B7UzxgMZWzGeyvBq3HUf8gor9L3IWwg9FEpoa2OBU2SJk6VQ cI/W0E91eW106IZGnA3Ndu0tpIAQe0HleXORk67A3VKKpEtgqD204HB8m+sYWQC0bWnMAxa/gkwl yy5nSwkVhbYA/Sl9CfwQ2q69uawNepqz6i0jL+k1QHNhXhawS6ICAzF800WISGmr3fLnTiO+Wh19 9eYt3LhsF8IaeWTIHYbBi+BaKvLeSy7N/i8UywXupBUU/Y9Hd/+Qbc4Goqg2ESQlQvriYbXWshkE /eh1OYBXUI6LZRfVcDPmuUYUo2MgAJf8GtBVI0paGfJbGPKwQuKlAe4YYGsJIFiYerCFfmVGE2oc nApPoccWQJZcMMZCQC32tH7ijcCfBMFUiq0QVO2oQ5MFKsuGn0OOFV4SsueEl6AGF2RXHBw+HQzO 4KN9MLA/0gBb9dUNCv7ofMVN5vPkNwEB/xryKqjQ7J+kDV+gMscUQ3O3FoHNygYbvif10n/PGQBB oC88lL3q23d2pJf92ee9jprNbuYcqAB4tWXkBcaFI54KfABYxkDG/l98S6I4YTT5y4C50AjamCkI E8yqlSEPAxzMM7LACa4usD5zUQtDrl1kMVAS1TA8jDle0EzDsiHzg33RQVAo3pKPSFRH+OamFLQw ZrpMLUNpLHA5e00uPsHEoPkS7qPQX0QxNAKwQVYoSFOmNuWN1V7S0BH6lQE9ly+VbOawDSLu9L98 +hfsO1ZTSxgLOxBFgmIiVOT9PSnriR0LkeoImSuvqHjRp7vfxNXoEE36o5lkNoG8RNWyn5QcJRTF pEv3sBRD/WyjQ9g8+hORi5a8tADTSNAtYrSghxY5RxTZGajPL6i6lYZa62IFn5Az8YmBr5AXgJ94 Td3laKAwCdad87BR/ErAugsESGA0XhxkD0EWNWR5RBbBHw3HLuIryCVtIgszABcSKVUCgcpM1wzk pSZH1OSX3zjIk+10O/766gdfrY25VnmbXbrQeesIfe8RIBW+T+yfxEt1aeoZEBFWqs7b1PNsu8fH WwjYAfjCJ/HT8V+e9ejzauByF2M61E9wBgYsuXQGWAEjL2XvCsbF3zYgLyCyBXQHC7QDglHwOgZN OecXOUfosEb1ChT3rrsuB61kKBHJRNzGEcwHHA8+XzPqY2S1QgeZqfl2yAehKOtiV2MJrHbQLMhS bUjzMGWiuQwxNKgVBjLcwf5mZ5GZErRgUnvZ1MyRz6RxA3YREga/mN+4uc96v3GxklMtmAspyEv4 i9kgPKZF1XnFPNjWJx5rfU1dNRI5OvYe5jh4ho8hFa5SiI4gV2H6UAibsTIc5JThhm71OhRszPeI yIM3BIonG3hJFLQ3ZDhAfjOTFRpAyYon+1gZhYG53CiwoJUxB/KkgGCUammlTXeNJKwkWAe8RsCO ndtalyFWsI59SMg0UsaTE8IqKHWIEohgKYK7WThN6BqQt24oBjFDm2YxMoskTHKsENa7G7I76Lb9 rd3A9F37a9GGHVbN+mr4Fq3Iy9QtG5zpKdLfqg3ncdAzZhoclWab4lcVC8TjOLN6DtuYARCHSLoH kZy/dLX/KG2rniHu2gQyzFIoCGUuEOaym4lMxPcNWe0l7yrvCSAmnkDyPH9if/AfYZ3GcVqZd7W0 wO9GGrS7vtBdT7CLys+tUHyS4k6xhTbivNwNAfWpyFDsri9y1ZOzjHgmtiD+yoiWqVS9CsfEr8hM hwrSlixZHZBNfJmojQCFhVlZEWJdgMiIjm7ZO3ikfnpFJQeh0Bti1XnpkWGDiry2QbsPvkpC3jt3 66B0fLVi+3NdJ6AxEMjDwVQKeoapBMHzojgq6BMDmqYsSRJ1kWwJpZLlNAreoxXuYi/ImwVOMvky 4ZGzFWhLA54ULqmKFRocykWuWB5Y4UGnsw6xzwM/xUZWchFKQQ5iYepBAp1LRG5rc05Lc4FccUuf 6jj0S4cu715CKTZSZvGJ3lso0C/rvCBmhloFbelvZf3Bs6du/X1mgGcevRI4n1dF3t9nUp+qowig Afii7M31qspVm3dSbpE2Gr4nrqShIC8DKOEvjUZA3LBF2ShvoT3BqRh55VBMgbwAX7QUhAbqCjyF d4x1VSr7zMjroSvy0KE+AH5CFaEJZxXkJfmf9G4yICPulKpWMvKSekvIi/1JI2B9gZgV5fyasqBN tzSCPZaAkSLjqa1m2wuvvheTXXyb8RU9qwlrrUNZ5WcslAWVU9kYwcvIW1d/9PyNZ/zfRjNKd32m g6EEwUuQAAkNYVSBTcZE0YBEz9iCT1AXUtQZJeEuYfcK0du9yMtFY7hujKz80v6gYQZc+pVYIeGT hwy+8imUV0P5tgGI/3kLyB6DMJc8LPQqAXkR+tjSmPOKKQ9Vpl0tOUhr+lv3MM0niyqroVWBUIWy W68UsCK6VpH3iZAvzzxN/t1aRJtDHFLZyBN5Ds36pCASjjKCllB34mz5c149XEcvQR9wDwMqQ8qV NPDKUwk+aLLIcRC6APEWZlms7QqcbWyIBq9gVVfuzkbMrVFdKTA6YSVmhTerZSQZioHFHrpd0HCF 9RhMD/wNqIrtLoZSRHlRTSoYBrlwB84F7QC8jpFXIDWQV4Q3E/LClQwFBz9pYSpCjDQcau6aeI8P 5rV5bdD1Wlmxra+TyzVbVQEBws36gakX96szAOSlh1hPJTX+MTTQZaDZMyQODgsCMlM2lFwgL8gG vlQgL0UuiUAFuTKM0GHlwAaW9IgIFQQk5BUVU/EJ8uZjUkgVhtCLZblUgKySeMvKMnb7l0Mch73P KGBF8fz01mAw8pKjB5fdylQAs7aHMcV74sr/69ove88RNEaUEZYcJwixIkMnhgK7Ktv/VYppgi95 8kWuIuXzqjWsmmCObf6Q4FPKS1pXeavqvcmmFr1NPpooZN0S8rIWAOZDLItAVrHCPRR5yQsMuKRB HmEZeQXbEVyO/bAAU4obsSIvINXVUAidVxiWrSoD9uG6BxRfDRilGCoCXxpCxcBV0cGphiQFvYBb CgMdQlywDzAX2ZqI+4Jr2Cvouxa9QgKnfCH8LuSIERwKnEm8KvfovDb/ZP+YN4AnCUMGPm9W3122 accrnYf4Tt6ENHCqhEw6L4ikgXIgSco0Keu8Qg+l2AYZQ7lKDIiQB8XsKchLyMiaKZG6DM2sohJB UsIdW4HkH4qfP+CTfsuhX/In/xDr4iwgbJA0gW84ybEIhKDganhYwnO8wqLd3vvE680xv1yr5Q6w olwhIa8g6kawqyLv434V6BGwn7e+hirjoY7k474C9Xw2MgMoJUEeoju1qfl7Xuwyol3gSi99gitU Tq42T7EfyJWgvEJGXopzZvgjgZzgmLiNiGgS8VeyiYyQlzEX7EV4e+U/wXCoXhB1t6cOv3ZocI/q UshnNIBryXUpSadmtZo9vKSGMPKSH414EWvQ4EKsmJA6wzvTxYDv4cioSICAFpQnwkDMDEoG+Y+b 37LLewX7fxasiSoPAHsRAQGdH5voL/ISYsgPTWFhNvIM1cukGcBDE88TK6fPX/DrMdRzxFdupPbK yIu8ciIhRABy4i1gDrQkY6VCcrSFBtEV67ayJMnCJDaKbxsAl18BejswGLXl10RBcAHED/gU5230 KQ5C8YFAecgJuFQBvkgWRpgiktwhLbgZUv3D1r/SddS8VVFV1fVEwKzqKlK0oARsFPZnoRHTzGCo y2OYAQp4w2yDudTB1YvcEXXiH8Os29gp5Bg8iMjcK+/abcm71yj3odPdtdEOqHrBMj/Z5ZD7z4N4 C/lbH4q8+IqxUuwDqG1gYgzEBMdWZQEsjnQQhICaZVAWvAunkJGXwRfILjRcRc8V4Euwy4OUAvBJ EgBQsoCQFzGrhLwtDfghLNtZqNXs8W5418HjKmsgf1IkKLMrZkZgWPS/DLsq8toYBd97uQJfuEcb IktrJ2qm2PUxOU9aj4QypO2glguFBICozAWEvBTjx8PqTr3fJiyTpQBilu5Aew/AUAG7MvUqAire GoVErbQqrzzsIBSETy8aWbbxUig5RPnwUyPvCalGuBLUPPcZv6hlh35Hz1wQAiTmQMCuoGri+Q2w S8iLacEmDBUD7qWXJvmLZvvOHa6MV3+nGg3J1Vlvknm26YNyOi+VbmYfkYSCihFzlrXoMc4heENr QxqaAcGqRpmzwC+ok6QgkIbLyCssyaRm8hYy5WE7ieikt4LnEKoyh+Ed8FvCa9pNVoTJtkasifBU jgjFTxrAlPckpOYfimgW1lCsuZl0YawFE/LKsaCkUMNHpgenzbEzFUNNcNOlwXnt8uaYL79dw06x Onze+zLIsMv8StV5bZiiqQwZssNI0aiR6qrj4zOd+oQ6jFqMcsqw1iIwydFMHaUR9E7Rzpwk3ggE hUR3/6egSY68InpjwpZVUUU7BnyT7EfiHxG5LJda9xQr2Pm+wYCuoD99C0M3xR/SoUg3F2H/ROHY AsJ2MSHDLtczNMauv3lEcGQdknc5Dx3kK4BVkSc5mYWiasVQkfexkrSSz4uHgweER3Avs3ms16Ke rHnOAFCG9D9cHL3BCAeQpB+Pldv9fZDrhMWOmh0I5ED5ZYG8YAuMvCzwK7zFCqwAWR5UKorCRB+E vDIW828ZKAVqk2lOACg4jJWzyRitxFMJtmblVMSFKGaGGCB+JTNATsFg5M1F1XooDlQAATnCwTEu Qz7zf3PYqXL0KidehDdBvAzEu2ixIi9PCG+iPdQ3RkyFDX1ChiTvAZ4jWmFU3bld3324zmHQVNeA jY66JGrFZcmGwRm0CuQl74ZiOhaYaMXKxhCpIO99IqKQJGXAZfoUIqUsKDZAsHg1SN1WQBkrjMLK 2RXUJh8KeVvE0YTOS70eyLdbAMxFPXNPTaJfwJrnO4/ckZxLrYggaiAdX9FnCWJpEWQM2hYrKvKK aXl8n3gksjlR7Zjw+Gbdhs7EcKtk3+OthYcCn9PmfNvq9QmuYxb4GHY4Im3QjJqQpa21MOEiIoVk fplvyJEkpKUSdNJoiAsV3IP3BMLeL+0rWxjH+ZiC6dFBKIyKgq9IN+EkjkYGavLhgl8xE8O32VQO iEv2wVkGFxjKBIFHYR9RFBc2Og9d4osDZnq+rVuybrMkVd+j1drQg1Iv9dFmwGq6QXIN1TGuq0vL Len8bmDrd6a4h21zMqWjZosDOgaitQHHAwDLqD1HIylOkB+ZaxqCk4XhheiNCO9hxCy+aryDfATx Q/LbWo+As/MFgJ4F+uN0RPAooIoAZhjG0ZwXBbVQYYPCsM3FKCODsm++hhTvyate7hkwMHjqbYrM 54xRnhkZcu+ZJcBuw4IdHrRPww7q2u84A+QFwEJyIKLs1UWdgftmABlnKCtKJjqkuOJTyMwXrlV3 HjDBfVC4Z8Aq74h0VNrhUpAokkxA2YC8Cgti0CT8ZVWXVog7yb7Xh2Hug7ezykwqMB+T2BEGQFxx DRPy4uBgjATNiF5m2KUaueEFKH6rKBFUFxcdFjz1qV6BG+z6GAcHfXwbFW3r4HO5hx3dNx3qnzY/ A4wuUPZAzLU1oqaipJs203ugxmX0PE9TSmt9JrCMqp+hSrMeQX3Ue4jFOeHOEPUxhAHHCr6PhrzK 63A/NDOIA1VZkpSxW0ZeRPgz8gpJkpDXlO02tbiNLpNs4zAyo4kSQvrRmiG8wMeU4Tl5rdvgaZ69 R5UcOkU3SpZMlZ6bKc2Sq5eraN+VYbiZXqd6WU9iBvDa0suLtxgeIjArrMAHik3LN8e1HTD5hV7G toadKP6Dpn6i+I8CvsSamF2QyRcDvIvAkYKZCSsJN8nsrHh4H8aU7t1OWoABAVGliHCWk4PEDg3a h4zXOL6sGgOIzTgLytRT8UmZi0IRDs91C0/318e26DtlUNhnqUV7UVKQ2BRz5icx1eo5H8sMsNIL ggY9C6rG5/4jp4OnL2r5xkS3SSvdzRmoK45Camh5AFGNIg2sVEokzciouE4USw7Zc9jm/GBx8X6o VaiabUFkBZJ9xEqgMvaXRUQBu+w0wQvF71Q2KsCgMqrb1DL8HCWj4euBJcdJl+5viPN4f5Zrz/ER ny+u5reVA8key6yqJ/ntMyBiVsFg60mzURd1BhrPgIy8xKTuStU1xLawCvUQjXw00+e3GxLhNGyu hzYO4OtsARNQKmPIXIIsbwJ2AXmIa+IKA5y+QR4r8BwOhFYY0cMYlHU7kBd1M9x1qHBFpTbwJwO9 Es2i2PGsKrY4BZQCaL5AXvT5xWXAsQv0d9AntY1I+EtPU/shpg0JudVM+3UU2KwuT/UM3BXdipBD KVcwvllNkmR28f4+o43PdgtoZ4pB6B0aYNnpsoFoVioFUTExk8uVREpCQwJcqt/ClEzEbMXoRyNp PgJgVww5ztlK7dYVEiP5XFihPD5DJvw7sDKhcQkSeKGeI1zQPzzBecTcNj0nDg+aduUGicq4KfG2 PtWP0yZvrpa7sdCl84NSdV6bfIpNfdEEtvUcg0eYa43Kw2nLr9wyf7m2ZY/JTqMW+YUnoZMC2AJA jbRa4jwNBQfIGkxtcMUQtjuyNpMM/2g8SuwGEBd+N5HtK5CX2Ne9kc8Mx1xP3rQL3EkgL3oOouMM 5Tyi+a8hBZzqlYEf2fcc8cni1SiqQFwYt0cvgro83TMAYRLqLtk3oBhSLWOYce5KNTU167fFdRgY 8mIfo5c+DjSM+qKQJJHRplCX8JLAfiIMNULJVbRdVo1/K/LKVM0uXUWMlIVJfMVKLptuGN9FPXMY wGE7Qug1umQ6TP2+hR6hC0V+4Wn+AUtadh+LWpE/HDkHdR55oqTXM1E/3Y/Tdu9ORFjV1lSpOq/t PsQmvHLEAFAqAqiDmwiATdXWknsCGHVX2n/0/HD9rL91m+gdsNxTF4s+BdQzpRHyMi+SXbrsjRVm Z2FMI7OzUB8eEX8ZwbP4LOTbJXBnK59s9Gsw1lF0ilJho8jBggamBXDs4hO81DMy38cU5zZ63rMd B89eteHI2VNk9kG9AVGluQmnUj10c5gBRl4ElHLvgCqAlICnO9VXr15dHZXaossw+yGzvI2xEM/Q UQiuVREwAEojzCU3x/2eDqZe/vY36ryNJFISRymYis04TNUiVoHdykLh5UxeV5xClwPl12lqqV1E 6Uthmf5TC9wmrHix25i3xugyCncDcBG8jXcTSj3JGOrS/GZAVM5QSiXUqTpv83tEzeCKZOSlKqO1 dbdIReCsjLu1WJFq6qXYrOIxU+Y/23mUf/AaFLai0jqyW4rMcdbBemhDjgZ4jhiPiLnybkBqMxqq piDpkp3FHLIl1A2OuSIcZ5+vEnBFFkLyQRsLMVrq0UA81zc8zXHU/Oc6Dfrk61UHjxyn2EJu44Lb Uf0tzYDgmvYSwO7qahHBTvjLEQts08Gzv1t3q+rmlauVi9bsePHVYT7jFviZ4tFxkhttUKgeCJjK sFCYgSjGAumRzDs8iJgpCktxyz4iVeNXqODhYUhzN2RxBLUoliXMztB2qYAMh12J41Ocs7t5FzII ULsGOu8r2myfDwv8w7a+1CN4wATzhu2xt27XQIyEUEzCMl7VOxQe2bQTqh79fzsDVM+EBrqwqs/o fzuJT/XvQBf8IuMmOe8buRgMvmBXYGIV1yt3Zha9Mcr0/OuBbTUbkOEr4E/Yygh57zPEMTgya2ow rD0ip8Ix7S0Z9pY0tPzj4+Pg1FeXTiEjL+nRgh/Cvk12Oe6mSj44aL7h+Z7mNI9Jq/7UYfi7geay Hw5WVd6gzAskE91FeVuw36f6Qao3p8wA7DaAJC7lhKaBBFWy6e9W1ekzv0wwfobSi+5jl3ibEiDp QedlcY56c6BhB3WlNAAEgYZEaSKvjSU9xY3yyA4UIC8MOABfrsOMnwud14q8gF2kGlHzBXhq0B+T +mYaCpyQZWwpQUCjuznLO2zbnzuPb9t/wurNMadOncId4V5gPCdChkWdaFvl6spTbzb/C52XSvKi kgYxVZXvNJtn02wuhJgSD7oiAlwGX1CLvFBV2OuVNYm5ewC+/9NlnGfIFmdDGhqIcwZELvAOqIcg EHij4KVFBiIG6jwDKOG3IteVyDB6NGYF6ES5PGubXWCusP7BDIj0ChzWns5LzAqVLVHkx82Sh3q2 bXTZuAxqxatJ8Axc99Ibk94YpSnef7SyCtoupAoqWg4GBeRVXwDlsT61/1vpmZ81UImASWzkWNPa +uqqQ0dOhk6b/3/cB9qP+tolPNkuPAsNQaDSehgKXEJzvY1omEWB+oBdUkgtOdQuJJxC+DAeUYa0 7sYCpIh2aLBXkzHZQobuNkZqQo3UXWd9pps219NYiFgFu7BsIC9KwXgGbXIZPK11p7fRvvNaZRXE CdyI4tvlV5WE5Kf2UdrujSmMRsTPQDpSH5LtPswmuXLxIuNdpgV/0CBmxUWMUYIPsAUgpvSMm7fq 1sUkP+fbu8WAab7aKF9zCjrUg6s4TilBbeRWBuqngPRDN3MuBjgVABetCloZSby3cqF/uQKOBBxH NKlQdeFxI9MfBzmjoRsO6xxRgEFcy2p2pkyibDdzjrshyS9sQ6u39O0GjNuRUVB5mxWDO6JFJt0a VHv1BRCP+in+FFSswBNuVEZeEdxOSuLd6jvVt/cePNmm8+DnugU6T17taU51N6a5aNNdgX3mEicN 2m0gkafIOaIIlAZctkcgFvftQiz0v6ThxjuQJGlGdDRVmBHRWVZ7dUtNmnNkHlJ3nS0wayMDrtDd VOysI8RHyXE3fSYS4lyHzrDvNnzmguVVVVXs1SXYxRAZRfS/StDNkpSBvLCxCJML2yXU59Qsn9OT uygQBFtDmEGRtkvvMjbi7ZaVXmwhYzS+kmpq7yzbGPNyp0Fe73/qNWG5j3aHR0TeS9osuyll9pEl rU2Uc4TeBNSOzUCqAcKiEHUM5tOYF/2rdTIvo3StwFwY/ajQAXc1Quol4zI6qxa2NhZhYDeUsUW/ ew9dCirZ+kxa4T3U7Npj8PbkfLk6JDt2cQd0S4S8pPk+uclWz/yYZkAQsBV8+eETCdCCvvEoHQPH 211p14Fjnd4JaNPP6BvwrVfwxvaRCO0raKUtdLDst7Pse9lQhE64duE5KDWJ/tSQ95DpY8eE/a9o uIHgIXa2MhdhkDCJ/pWU9g6bMw3XyEJ7Y24LXQ6kVhAzmmC2CS+DbcfJkOEfkeYbstVj6KyWnd6L nPXN7erautpb4gbo1ugdhRpFL6iiW/GtqR/NZgaU50JaDJwDzICazcWpF9IMZgAvMl5g8Cg2Mgur rIzFxLjoPWfj81103CB+hbc+ufCA15ujnN7StgtY7qePdTNnoeoO2uaCL8EiZ80tghgPBvUbYZcy lYR5maNcKDmXM5WIU1ExH1NBayMSMHc5mUtdw0sRDAMlxVuf0k67ve24xSiM/+o7Y7J3H8CV19bc ReouS550FwBicvXRW6CCbzMgu6a/BDzt+wbRuAi2khBKiBAsZK/XHT51qdt7Ia3+Md5vzDzvwO/Q VQHlNVqayl4BDk7Z2yYCvpJc1LUQIfqAzt9kwBH0D8xtZaHUpMZvB+gZkqQ9ellGlrpM3dvKAGGy gCzMaLxrjPUKXOnwdoT7GxOXbkigynKUdECir1iEw1pQtBKeIX+l/td8ZkCJPIecVMOZ5c3n0tQr efIzgLdZRl4SzBDYjE8RE8CMC/ov/cUvPmAL/X1qCMF2/3iy14iwF7sMdR/xub9mo7cxBQHPwgsG /6+LKYM6HKG3L7GX3+wXE6Wr8FsKoDIh+ES0Vc1FAT0qKWApc0CYii7fQ5/rq8/2D0tsG7zRYcDU Fp0H9x0RfKL8usKfZEOcgF00YCLpAvcKv5iq9j55untMVwBiwCAZkk9IES93oe7SQhvYwnPxatVk 4wyX10fb9wv3CVrnFZ7cRpeOsAG7cCAjYDeHc9hzHfSwOVMU/aMrvGJPCJ/CM8JCaRaHWiFwC2Uh i0HPdvp8HBZuGtfwTBd9oqduu8f4hSjL7N93XHL+/mrgLQMtXSzJkXwnDf/zXakfzW8GKJhTQgo5 RZ7fra+uqSZJT13UGWg8A+JtZgSWERacCoMKjor3nYiHVUXlxUduzrUaSffpAjSaR6qv34Rlfprt PqZUhGK6oM1ueJajMQNxVkBPKjz7aLFVjRiaSE2i4ziHU/wJpxflgxmi3x/qxqMas48h9dXwpLbB mz3en/dclwmdh+lnLttQiZ4tdOlk4eEq5cRdISjQvdDA1dNXMhduPAXq+tM3AwpZKzQLXwOjbSMK ILMzpf1KyPPeGJ/TZ3zkf3cY/vLbH3YKj/HQxyJI3tmYSV2e0STIjFb1RcgWx2hEqA1W5V/fCPsP grUE8uKT3wiKtrLXIyIxz8OU6WtK9Ddscxu/6KW++r91HvpO4Ienr5JfmlPs6bJl3RY3wwQMEAZh 01/q0lxngOmt/k4dSrkgtEB9Vs31OT2x68J7zbgkLkDwKdYKxSpK5dAbDoNtzR1gMbgBmhlh37q6 +htVtSk5ZRPDZz3n0691Hx3crB6aaKi6iEuBbQ2lcZEWQUGhvx156ScUQEWRpcj4QIkhDlOhuvGI Am0fmdFev8Vl5KyXek1+ofM7E6fMKv7pKGRKXBtfKpIckUNHeg2nk4BF4YIR2Fxr5b1PbLLVEzf9 DMg8jvRZMYgoCMUUqCKbMwL2qQwFfYWibVjDO3D4dPmH8xZ7vTns+Vff8xr5OWjM15TsZsprYyiw NxQ5mUpQquW3i5GipIz4BP4SWHMW3i47faH3lN3umlR/TXSXULQfmvxCx379J+o2xKZVVBHs1tRR VjKxbn4B5ZnDupAmqTYMfaMuzXMGGqzN9eA8RGzqos5AoxkAKpGq2/By08tMcIz/EVKFd1uOUGL2 hXJ82M49bfHmE88C/kanFr5v+OLPfu/+tZfBYfS3nrp4T0qUyIbKwLZikVJhVRAoyZf9ZffEPLNe QFUy2DpHBjoaVGeAdF5WGVCLIMlfv8N1zKJn/j72+c6DAmcsKjl25kr1bWAtrOBgRHTl4FcUxIxc TqEZ4EZkXR5f0y7q8lTPgPyICXZh5yChC1vA+OgTDhNR94nAljqDYCNtJ9qprYcrpb7u59NnZy5Z /3KHt5/pPMZ+yGxf7Q5f2IE5aBAhB6heDkuOoFWKZIB8KMCUTMr3DwJZ2kgET2U6qMI5/VYov2g8 5B26wz9wXYve5v/y6td/cnh8YcmF69frCGqJYnE9RM/iEnEfuFShOmEL/mTYZZp/qh+nbd4cPSIE 8RGZgeZq6kiBURd1Bu6bAeJO92160BaZBzAnED+hT7CG67dvn624kVF6cLRx5kud3vtr5/FOQ2fB /QquhfAnOLaIR8kMCnEmxZD5EZ+MklPWeBW4g4mnmbJcUdWH2v+BXyFSOtPBkO5qSvEJT/Yz7EAR D7t3P3n+tQkvtBuEvjPFPx6/ePXGnbsy88RVKYvCrOS/rZeqfK/+/0eYASIIpgS+2Ubkcf/NM3sU Zh8iFYDbpWu3fjxVMWXuWmT0/OXVkfaDP3ab+G278DhPfRKSjzyUAH4AKHU3YBGRqlFFIIE9D9GG bSx5DhHIRcqhXCRzfgtTEdLrQOpouQvDso8xCUpu+5D13iPnvtB18jN+7wwMmr4lrejoxYrKepSN A4u2UixWHrL8yv085Bfq5sc5A3g+Qsa7Wws5CtEFD3+Uj/Oy1HPZ9gxA0Gatkr0XwpZbW1t9+/bt n0+ciU0v1n+21Kdf0F87j325d4TzB4t8Qrd66+PAcLwMye7aZBddKkoEkNgfnkO8i1ay3VC+HpqF MdVJnwzm5mZI9TAmo0eDnyHGZcK3Ld6Z/sIbYc+/NspvQKBl7pqUoh+OnrnEbmjWcB8gNtj2/KpX /xhnACxRgV2ia9YkKYHubvnla5mlBz5dtqnbB6bnu43+6xuhLw+a4Tx+hY9mu68xDsTpaUhw1ya4 GZNFPCF10oSQScEJWbD2OBvTETSFyH9kmqPViLsh2Vu/0yvoO8fhc1v0Nr38jwmOr48aa/5yU1Lh jyd+uVx5q4byBlAoQyDvY5wA9VRNMAOi7wyZL2BnJtuLKio1wSz/UQ8JmhKMiiaAhDxSMaqq64v3 HVqwNjpsxjdvBU3zeTe0dc/ANm+Fu7473WP4bK/RC/0nr2wbtrGdPspXH+Oli4Vp2kOXCDMyjwQ0 ZXAet8ptzFLnYXMcBk1zfEvv0jeg6zDN8LCPzLMWrtm2c/cPP4tAZT4bn/ePOv/qff8uM6CkGvHB gMOgZLJUUwMRrB48cmJ9dNL0+atHm2b3HB3p3j+0ZX9dy8FT2oz43GXsAq9JK32CN/mFRflpE9oZ Uv21Kb5hSb6axLb6lLb6JJ+QGLfx67zHfes2fLbTwOmO/S2OfcO8BgT3nTQ14MN589dEpRXsuVJF IiQFf+Fk5A1s0NN/l7tTD/JEZoCIiNCWCKnudiU/3SdyIepJn6YZYObA/l/AH4EvNjDPgMOM/oCD WJIu3rqVu++HZdvjZi7fFj573UjjvF6jP2w/SO/RX4tcYERktX7L0nrAh/bvfmY3+LMWgz5+8e0P n+s35YW+ZteBUzsOn9ZzwqcjTPMtc9d9tTo6Kil79/6DlyuuEm9SAqWIrFUu9TSR1RO7F/LHyS5U XAPoF2RNMc8iKhUacT3KkB44dDwxvXjhup3GBd+9P+3rHgGfdBwxxXOQ2aGvqdWbJru+U1v3ntam /yfOA2Y49v/Uvu80bLF/a4pLP0vbgaYeIyOH6+ZoZqyYvmj9N4igKt538sIVHBddsEHGWKhZGDFr ZfBG9cN2Z0B5sIBdlEDBoxbP2XZvSL3yJz4DYBEiAoQQVrAK+g9/YaADOfKPKD6Exp27MNpRAu2p X65l5O9Zsnqr+dMFY8OmDRit6TF4Uq9hIT2HhvZ4L7j7u5NfHxzQa3jQW6M0b4/VjtJOi5j59fKN sXm7f7p0g9rqgi01MCWFhEUZ/Do1aPCJU4TNXwDRLsXDWKmMaQyJafW1VejxS8QMKmb7Dkjx2m2p 7ODJ1duSps1eOlH/6cAxhj7vh4kBku41NLDnkIAegyf0HDqx/+jQoZON5s/mLlyxIS2/9GR5RRUK aLFJu2HOxLmQNcAtLJFw3PCVumazMyCeIplTSC1RkddmH2QzunAQElW+5ZIUDXjI4EudjYjMiE3B wcEqAznRwNnkPaEZ429gMSrzXL5++9wvV4+fOn/i5Nnz5Zdu3KikvsCy75j2h9worNniE5tqavBr WhCDKhf2UY4vtquf6gz8xhkQ9AySJJIj+lTazTPzJGmS9V8OkwYhQhsGdQuGyj/B/pU19RU3qs5d rDh6+vThEydOlZ+ruH6tsvp2LeXEwzCDsgp1oFgMfhdwRuV94GQ9ccFkcFaXp2UG6AnTckdmifTI 1UWdgX9nBsAgAK+MsKQGEPKBXymEhW95EOVR4UkEa6LDL/gadsPAClQIQLL4kz7Jzid+jR+yvgzg JimR0oIEUmN/1ILBwFZsobPSAAdjrsjI/u/ckvrbP/AMwJ9LHSQxA6ApUBfWxKCyjUxygtxAezW8 hWmP9sZ2kKLYh209QFZ5AHABuyxGYheAMwZWQOGNFhxBds7QRlhvkOUEYbPRHuqqrc6AKHpAzBAP FCHralaRrT7J5nTdVomfmRXAEsyHg62ItxD74vLOWIEGK/gS7yDjpsKp6CvswwvoE1oEAy7AVAxm UyLWE8grBrgfXGPyT8DboH4wRsuHUf9TZ+A3zwDLe0BGlNbgSm1W+hRiHuRGbMEAKWILEBQLCYsc PwOCx/eQ/zDwCvAg8RF7Cdrm/ei9YBRu/NuGC0V2vDiaohQ3fKWu2egMiKdPdjlWEOqoW7S6qDPw 782AYCss8yur4DMCdkm2F5yKdARWGYgH3YOn4HViiMuw/qmsCKpl3qUclg7OByPmR8N6QCLsf+92 1F//0WdApkYrMfN8KNTYiFYVQgMXheWG/b9Eiry79cf43T+tWzcoRwYNW3VrrAiqtp7xj/48noL7 xxOXa7aQUAZGiA3qos7AvzUDRFSNuAsfSzANYiCMlbKagL+xJ5tcIPuJwaBJrMbKZ+5baeBbyj6C LymcipTcxj//t+5F/bE6A2IGBDgyySn01iDdgWgFlWJfrAjkZcQUgh9+fB8Viz/F9kYyKp8L3+EU 4iACvvlQDVStPhObnwE8eSzV1QhshmqAxy022Px9qTfwpGYABAQwBSUJ8OXLAGk1GvfqCDLB4T8x GjjUg+6A91b2VXiZfHBFz+UjiH1wDY0u40EHVLepM/CvZkAmTHk3BRZFDCHFCrJHA0RIhKcs1t8o xKqQN++AjTKd40VhmwxtabyIo+Fb67j3+I33VddtcAasWUWihpWKvDb4DJvXJYOFiDAS4diVOQz4 EhxZYhAvEmwEn8x5/ukOaBdl4MvG69Y/lR/xoWTwZSbG+wv0F2wLP1cXdQZ+pxkQRAsltJGJhshP plIQXgO9CsK958SC8q14yvT/gN3oGNYjCelRfKrEfM902uwfeI5ycXu1kobNPsRmdeHsxkWQkxxv ImMrsyaZI4H3EKsRWrCwLQv0xH0IvkRRWGJYeQ5WxMB2+btGt614e+V9sKeVtYkjNNpXXVVn4DfO gKBF+UcyiTboqvwtPqwk15hEmTLhYaFIwEYDW8jtolyHOCb9JU6FT6JbjosWxGz9VOlZmTTb/v// AyB3kb4KZW5kc3RyZWFtCmVuZG9iago5IDAgb2JqCjExNTczMQplbmRvYmoKMTkgMCBvYmoKPDwg L0xlbmd0aCAyMCAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA2Mzgg L0hlaWdodCAyOTQgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0ludGVycG9sYXRlIHRydWUgL0Jp dHNQZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHt0AENAAAA wqD+qe/sAREoDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAgQ8MgKgCEwplbmRzdHJlYW0KZW5kb2JqCjIwIDAg b2JqCjg0MQplbmRvYmoKMjEgMCBvYmoKPDwgL0xlbmd0aCAyMiAwIFIgL04gMyAvQWx0ZXJuYXRl IC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBnZZ3VFPZFofPvTe9 0BIiICX0GnoJINI7SBUEUYlJgFAChoQmdkQFRhQRKVZkVMABR4ciY0UUC4OCYtcJ8hBQxsFRREXl 3YxrCe+tNfPemv3HWd/Z57fX2Wfvfde6AFD8ggTCdFgBgDShWBTu68FcEhPLxPcCGBABDlgBwOFm ZgRH+EQC1Py9PZmZqEjGs/buLoBku9ssv1Amc9b/f5EiN0MkBgAKRdU2PH4mF+UClFOzxRky/wTK 9JUpMoYxMhahCaKsIuPEr2z2p+Yru8mYlybkoRpZzhm8NJ6Mu1DemiXho4wEoVyYJeBno3wHZb1U SZoA5fco09P4nEwAMBSZX8znJqFsiTJFFBnuifICAAiUxDm8cg6L+TlongB4pmfkigSJSWKmEdeY aeXoyGb68bNT+WIxK5TDTeGIeEzP9LQMjjAXgK9vlkUBJVltmWiR7a0c7e1Z1uZo+b/Z3x5+U/09 yHr7VfEm7M+eQYyeWd9s7KwvvRYA9iRamx2zvpVVALRtBkDl4axP7yAA8gUAtN6c8x6GbF6SxOIM JwuL7OxscwGfay4r6Df7n4Jvyr+GOfeZy+77VjumFz+BI0kVM2VF5aanpktEzMwMDpfPZP33EP/j wDlpzcnDLJyfwBfxhehVUeiUCYSJaLuFPIFYkC5kCoR/1eF/GDYnBxl+nWsUaHVfAH2FOVC4SQfI bz0AQyMDJG4/egJ961sQMQrIvrxorZGvc48yev7n+h8LXIpu4UxBIlPm9gyPZHIloiwZo9+EbMEC EpAHdKAKNIEuMAIsYA0cgDNwA94gAISASBADlgMuSAJpQASyQT7YAApBMdgBdoNqcADUgXrQBE6C NnAGXARXwA1wCwyAR0AKhsFLMAHegWkIgvAQFaJBqpAWpA+ZQtYQG1oIeUNBUDgUA8VDiZAQkkD5 0CaoGCqDqqFDUD30I3Qaughdg/qgB9AgNAb9AX2EEZgC02EN2AC2gNmwOxwIR8LL4ER4FZwHF8Db 4Uq4Fj4Ot8IX4RvwACyFX8KTCEDICAPRRlgIG/FEQpBYJAERIWuRIqQCqUWakA6kG7mNSJFx5AMG h6FhmBgWxhnjh1mM4WJWYdZiSjDVmGOYVkwX5jZmEDOB+YKlYtWxplgnrD92CTYRm40txFZgj2Bb sJexA9hh7DscDsfAGeIccH64GFwybjWuBLcP14y7gOvDDeEm8Xi8Kt4U74IPwXPwYnwhvgp/HH8e 348fxr8nkAlaBGuCDyGWICRsJFQQGgjnCP2EEcI0UYGoT3QihhB5xFxiKbGO2EG8SRwmTpMUSYYk F1IkKZm0gVRJaiJdJj0mvSGTyTpkR3IYWUBeT64knyBfJQ+SP1CUKCYUT0ocRULZTjlKuUB5QHlD pVINqG7UWKqYup1aT71EfUp9L0eTM5fzl+PJrZOrkWuV65d7JU+U15d3l18unydfIX9K/qb8uAJR wUDBU4GjsFahRuG0wj2FSUWaopViiGKaYolig+I1xVElvJKBkrcST6lA6bDSJaUhGkLTpXnSuLRN tDraZdowHUc3pPvTk+nF9B/ovfQJZSVlW+Uo5RzlGuWzylIGwjBg+DNSGaWMk4y7jI/zNOa5z+PP 2zavaV7/vCmV+SpuKnyVIpVmlQGVj6pMVW/VFNWdqm2qT9QwaiZqYWrZavvVLquNz6fPd57PnV80 /+T8h+qwuol6uPpq9cPqPeqTGpoavhoZGlUalzTGNRmabprJmuWa5zTHtGhaC7UEWuVa57VeMJWZ 7sxUZiWzizmhra7tpy3RPqTdqz2tY6izWGejTrPOE12SLls3Qbdct1N3Qk9LL1gvX69R76E+UZ+t n6S/R79bf8rA0CDaYItBm8GooYqhv2GeYaPhYyOqkavRKqNaozvGOGO2cYrxPuNbJrCJnUmSSY3J TVPY1N5UYLrPtM8Ma+ZoJjSrNbvHorDcWVmsRtagOcM8yHyjeZv5Kws9i1iLnRbdFl8s7SxTLess H1kpWQVYbbTqsPrD2sSaa11jfceGauNjs86m3ea1rakt33a/7X07ml2w3Ra7TrvP9g72Ivsm+zEH PYd4h70O99h0dii7hH3VEevo4bjO8YzjByd7J7HTSaffnVnOKc4NzqMLDBfwF9QtGHLRceG4HHKR LmQujF94cKHUVduV41rr+sxN143ndsRtxN3YPdn9uPsrD0sPkUeLx5Snk+cazwteiJevV5FXr7eS 92Lvau+nPjo+iT6NPhO+dr6rfS/4Yf0C/Xb63fPX8Of61/tPBDgErAnoCqQERgRWBz4LMgkSBXUE w8EBwbuCHy/SXyRc1BYCQvxDdoU8CTUMXRX6cxguLDSsJux5uFV4fnh3BC1iRURDxLtIj8jSyEeL jRZLFndGyUfFRdVHTUV7RZdFS5dYLFmz5EaMWowgpj0WHxsVeyR2cqn30t1Lh+Ps4grj7i4zXJaz 7NpyteWpy8+ukF/BWXEqHhsfHd8Q/4kTwqnlTK70X7l35QTXk7uH+5LnxivnjfFd+GX8kQSXhLKE 0USXxF2JY0muSRVJ4wJPQbXgdbJf8oHkqZSQlKMpM6nRqc1phLT4tNNCJWGKsCtdMz0nvS/DNKMw Q7rKadXuVROiQNGRTChzWWa7mI7+TPVIjCSbJYNZC7Nqst5nR2WfylHMEeb05JrkbssdyfPJ+341 ZjV3dWe+dv6G/ME17msOrYXWrlzbuU53XcG64fW+649tIG1I2fDLRsuNZRvfbore1FGgUbC+YGiz 7+bGQrlCUeG9Lc5bDmzFbBVs7d1ms61q25ciXtH1YsviiuJPJdyS699ZfVf53cz2hO29pfal+3fg dgh33N3puvNYmWJZXtnQruBdreXM8qLyt7tX7L5WYVtxYA9pj2SPtDKosr1Kr2pH1afqpOqBGo+a 5r3qe7ftndrH29e/321/0wGNA8UHPh4UHLx/yPdQa61BbcVh3OGsw8/rouq6v2d/X39E7Ujxkc9H hUelx8KPddU71Nc3qDeUNsKNksax43HHb/3g9UN7E6vpUDOjufgEOCE58eLH+B/vngw82XmKfarp J/2f9rbQWopaodbc1om2pDZpe0x73+mA050dzh0tP5v/fPSM9pmas8pnS8+RzhWcmzmfd37yQsaF 8YuJF4c6V3Q+urTk0p2usK7ey4GXr17xuXKp2737/FWXq2euOV07fZ19ve2G/Y3WHruell/sfmnp te9tvelws/2W462OvgV95/pd+y/e9rp95Y7/nRsDiwb67i6+e/9e3D3pfd790QepD14/zHo4/Wj9 Y+zjoicKTyqeqj+t/dX412apvfTsoNdgz7OIZ4+GuEMv/5X5r0/DBc+pzytGtEbqR61Hz4z5jN16 sfTF8MuMl9Pjhb8p/rb3ldGrn353+71nYsnE8GvR65k/St6ovjn61vZt52To5NN3ae+mp4req74/ 9oH9oftj9MeR6exP+E+Vn40/d3wJ/PJ4Jm1m5t/3hPP7CmVuZHN0cmVhbQplbmRvYmoKMjIgMCBv YmoKMjYxMgplbmRvYmoKMTAgMCBvYmoKWyAvSUNDQmFzZWQgMjEgMCBSIF0KZW5kb2JqCjIzIDAg b2JqCjw8IC9MZW5ndGggMjQgMCBSIC9OIDMgL0FsdGVybmF0ZSAvRGV2aWNlUkdCIC9GaWx0ZXIg L0ZsYXRlRGVjb2RlID4+CnN0cmVhbQp4AYVV32/bVBQ+iW9SpBY/IFhHh4rFr1VTW7kbGq3GBkmT pe1KFqXp2Cok5Do3iakbB9vptqpPe4E3BvwBQNkDD0g8IQ0GYnvZ9sC0SVOHKqpJSHvoxA8hJu0F VeG7dmInU8Rc9frLOd855zvnXttEPV9ptZoZVYiWq66dzySVk6cWlJ5NitKz1EsD1KvpTi2Ry80S LsEV987r4R2KCMvtke7+TvYjv3qL3NGJIk/AbhUdfRn4DFHM1Gu2SxS/B/v4abcG3PMc8NM2BAKr Apd9nBJ40ccnPU4hPwmO0CrrFa0IvAY8vNhmL7dhXwMYyJPhVW4buiJmkbOtkmFyz+Evj3G3Mf8P Lpt19Oxdg1j7nKW5Y7gPid4r9lS+iT/XtfQc8EuwX6+5SWF/BfiP+tJ8AngfUfSpkn103udHX1+t FN4G3gV70XCnC037anUxexwYsdH1JeuYyCM413VnErOkF4DvVvi02GPokajIU2ngYeDBSn2qmV+a cVbmhN3Ls1qZzAIjj2S/p83kgAeAP7StvKgFzdI6NzOiFvJLV2turqlB2q6aWVEL/TKZO16PyClt u5XClB/LDrp2oRnLFkrG0ekmf61memcR2tgFu54X2pCf3dLsdAYYedg/vDov5gYc213UUmK2o8BH 6EREI04WLWLVqUo7pFCeMpTEvUY2PCUyyISFw8thMSJP0hJs3Xk5j+PHhIyyF70tolGlO8evcL/J sVg/U9kB/B9is+wwG2cTpLA32JvsCEvBOsEOBQpybToVKtN9KPXzvE91VBY6TlDy/EB9KIhRztnv GvrNj/6GmrBLK/QjT9AxNFvtEyAHE2h1N9I+p2trP+wOPMoGu/jO7b5ra3T8cfON3Yttxzawbsa2 wvjYr7Et/G1SAjtgeoqWocrwdsIJeCMdPVwB0yUN62/gWdDaUtqxo6Xq+YHQIybBP8g+zNK54dCq /qL+qW6oX6gX1N87aoQZO6YkfSp9K/0ofSd9L/1MinRZuiL9JF2VvpEuBTm7772fJdh7r19hE92K XWjVa581J1NOynvkF+WU/Lz8sjwbsBS5Xx6Tp+S98OwJ9s0M/R29GHQKs2pNtXst8QQYNA8lBp0G 18ZUxYSrdBZZ25+TplI2yMbY9COndlyc5ZaKeDqeiidIie+LT8TH4jMCt568+F74JrCmA/X+kxMw OjrgbSxMJcgz4p06cVZF9Ap0m9DNXX4G3w6iSat21jbKFVfZr6qvKQl8yrgyXdVHhxXNNBXP5Sg2 d7i9woujJL6DIo7oQd77vkV23Qxt7ltEh//CO+tWaFuoE33tEPW/GtqG8E585jOiiwf1ur3i56NI 5AaRUzqw3/sd6Uvi3XS30XiA91XPJ0Q7Hzca/643GjtfIv8W0WXzP1kAcXgKZW5kc3RyZWFtCmVu ZG9iagoyNCAwIG9iagoxMDQ3CmVuZG9iagoxOCAwIG9iagpbIC9JQ0NCYXNlZCAyMyAwIFIgXQpl bmRvYmoKMjUgMCBvYmoKPDwgL0xlbmd0aCAyNiAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VS R0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngBhVXfb9tUFD6Jb1KkFj8gWEeHisWv VVNbuRsarcYGSZOl7UoWpenYKiTkOjeJqRsH2+m2qk97gTcG/AFA2QMPSDwhDQZie9n2wLRJU4cq qklIe+jEDyEm7QVV4bt2YidTxFz1+ss53znnO+de20Q9X2m1mhlViJarrp3PJJWTpxaUnk2K0rPU SwPUq+lOLZHLzRIuwRX3zuvhHYoIy+2R7v5O9iO/eovc0YkiT8BuFR19GfgMUczUa7ZLFL8H+/hp twbc8xzw0zYEAqsCl32cEnjRxyc9TiE/CY7QKusVrQi8Bjy82GYvt2FfAxjIk+FVbhu6ImaRs62S YXLP4S+Pcbcx/w8um3X07F2DWPucpbljuA+J3iv2VL6JP9e19BzwS7Bfr7lJYX8F+I/60nwCeB9R 9KmSfXTe50dfX60U3gbeBXvRcKcLTftqdTF7HBix0fUl65jIIzjXdWcSs6QXgO9W+LTYY+iRqMhT aeBh4MFKfaqZX5pxVuaE3cuzWpnMAiOPZL+nzeSAB4A/tK28qAXN0jo3M6IW8ktXa26uqUHarppZ UQv9Mpk7Xo/IKW27lcKUH8sOunahGcsWSsbR6SZ/rWZ6ZxHa2AW7nhfakJ/d0ux0Bhh52D+8Oi/m BhzbXdRSYrajwEfoREQjThYtYtWpSjukUJ4ylMS9RjY8JTLIhIXDy2ExIk/SEmzdeTmP48eEjLIX vS2iUaU7x69wv8mxWD9T2QH8H2Kz7DAbZxOksDfYm+wIS8E6wQ4FCnJtOhUq030o9fO8T3VUFjpO UPL8QH0oiFHO2e8a+s2P/oaasEsr9CNP0DE0W+0TIAcTaHU30j6na2s/7A48yga7+M7tvmtrdPxx 843di23HNrBuxrbC+NivsS38bVICO2B6ipahyvB2wgl4Ix09XAHTJQ3rb+BZ0NpS2rGjper5gdAj JsE/yD7M0rnh0Kr+ov6pbqhfqBfU3ztqhBk7piR9Kn0r/Sh9J30v/UyKdFm6Iv0kXZW+kS4FObvv vZ8l2HuvX2ET3YpdaNVrnzUnU07Ke+QX5ZT8vPyyPBuwFLlfHpOn5L3w7An2zQz9Hb0YdAqzak21 ey3xBBg0DyUGnQbXxlTFhKt0Flnbn5OmUjbIxtj0I6d2XJzllop4Op6KJ0iJ74tPxMfiMwK3nrz4 XvgmsKYD9f6TEzA6OuBtLEwlyDPinTpxVkX0CnSb0M1dfgbfDqJJq3bWNsoVV9mvqq8pCXzKuDJd 1UeHFc00Fc/lKDZ3uL3Ci6MkvoMijuhB3vu+RXbdDG3uW0SH/8I761ZoW6gTfe0Q9b8a2obwTnzm M6KLB/W6veLno0jkBpFTOrDf+x3pS+LddLfReID3Vc8nRDsfNxr/rjcaO18i/xbRZfM/WQBxeApl bmRzdHJlYW0KZW5kb2JqCjI2IDAgb2JqCjEwNDcKZW5kb2JqCjcgMCBvYmoKWyAvSUNDQmFzZWQg MjUgMCBSIF0KZW5kb2JqCjI4IDAgb2JqCjw8IC9MZW5ndGggMjkgMCBSIC9GaWx0ZXIgL0ZsYXRl RGVjb2RlID4+CnN0cmVhbQp4AcVW224TMRB991cMUMpu1Dj2Ol5nJQSoaYGWi6i0Eg+0DyhqVVAC tIVP4j8Ze+3jTdOmF1UirbRer+d25sx4zuiAzsjU/C8V/ypyupEN/8iOFZ0f02f6QaPphabZBenw dzHzAtbZ7tyCnO2WAntz7CXFhuY9M/7tlE4Gwbo2msZWJW113S0F9uaU9kjXmkW9RLc6Df6ld1tF 36sm+/7p+Hx2/Ov3n69zcf6Ng8UhRYr8wSQ9W9Bob1HRzk926wZYRISl8rB4RYoYljPGxy811U7W zuqGAxvLybghVr7dstPdd/8Y8kvLJttWC03tCRV/S2q/027LxhPi91FtZa20rStvQXQWDLvkLTxa snA354XyDGE9s14Y2kgbaJOjsZ2tL1TsTg+Lkt+KrRcvXUlH1O6H6MQdcHKVdHriXA+ubGCjFEMl 2cBhWVJYbJbEO4aKJixsbzGYhq0xFaOw8GLsnpJ5RxQb6dPzqJD9ZoWsp34dVhUVb/wnfqYjkBno qI7dYbTYgA0ybEAmNQo24bMy6RTkk1+s+khE1HrsmqjELmNvZFeGSwa4OJatZFABrxwEVoAJzkNu 6OPro4yoIA20kYnB22CWxWC1C1gUzyKkPt7Ekl68uZp0vTZe4aspcv2u1XSN6gespr4FkVvB2hp6 nFIFhF95rBhEbGifDObYYHj5CzKIrFzm7nZkbHqioiCqBsj6TvIFRMcOju9FhdGiyMV2O0UsdxUD wHjTOM8Asa6fZsaj/q4IIrosMpAKUUTvqdgPIXMlY2e1GFJJiwL1u9KOgCEWSF/uAzl24a+flbvE uMla9oe75BL7WdNt7pLrVD8c+5cs/Cf2o++gOSELMS+9GwBkuB1xcTxXQLycUMKr1EHnf5d49t7X D7do8C1eQKL44L8wE6Gud3R9ydg1tIkDQi6ZKhYw4kn0JtAbceDMxyAUwLvKldpI3c2UppHWYRwy VRiH+KErPsKjJw35pV34Pu46JvMcwVML38F843LoofU9ATpPc810s2Q3X9GKxdgwwgxj/AyTbVfa SVVXNtr2VZRt2zpMMIZ7K2PPydCi2GQ/7hemMZO+qeUwEdSIr8Nu6FBpkTrLIGYnZIkvARBIpbs9 fRnHk9CFo0uQHfwD6mBRbwplbmRzdHJlYW0KZW5kb2JqCjI5IDAgb2JqCjg1NAplbmRvYmoKMjcg MCBvYmoKPDwgL1R5cGUgL1BhZ2UgL1BhcmVudCAzIDAgUiAvUmVzb3VyY2VzIDMwIDAgUiAvQ29u dGVudHMgMjggMCBSIC9NZWRpYUJveApbMCAwIDc5MiA2MTJdID4+CmVuZG9iagozMCAwIG9iago8 PCAvUHJvY1NldCBbIC9QREYgL1RleHQgL0ltYWdlQiAvSW1hZ2VDIC9JbWFnZUkgXSAvQ29sb3JT cGFjZSA8PCAvQ3MyIDEwIDAgUgovQ3MxIDcgMCBSID4+IC9Gb250IDw8IC9UVDUgMTUgMCBSIC9U VDEgMTEgMCBSIC9UVDcgMTcgMCBSIC9UVDMgMTMgMCBSID4+Ci9YT2JqZWN0IDw8IC9JbTIgMzEg MCBSID4+ID4+CmVuZG9iagozMSAwIG9iago8PCAvTGVuZ3RoIDMyIDAgUiAvVHlwZSAvWE9iamVj dCAvU3VidHlwZSAvSW1hZ2UgL1dpZHRoIDUzMCAvSGVpZ2h0IDI5MCAvSW50ZXJwb2xhdGUKdHJ1 ZSAvQ29sb3JTcGFjZSAzMyAwIFIgL0ludGVudCAvUGVyY2VwdHVhbCAvU01hc2sgMzQgMCBSIC9C aXRzUGVyQ29tcG9uZW50CjggL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4Kc3RyZWFtCngB7H0HgBTV /f+C2EtM+6UYlXKVjoqCJTHxZ4wmsURjLGBBBZVyfa9xFRELqEiHuwOkqURUkF6u9957215vd+/2 tpf/5/ve7nJiC/lp/kBmeMzNvHnz5s13dr6f+dbn9QqLQAGBAgIFBAoIFBAoIFBAoIBAAYECAgUE CggUECggUECggEABgQICBQQKCBQQKCBQQKCAQAGBAgIFBAoIFBAoIFBAoIBAAYECAgUECggUECgg UECggEABgQICBQQKCBQQKCBQQKCAQAGBAgIFBAoIFBAoIFBAoIBAAYECAgUECggUECggUECggEAB gQICBQQKCBQQKCBQQKCAQAGBAgIFBAoIFBAoIFBAoIBAAYECAgUECggUECggUECggEABgQICBQQK CBQQKCBQQKCAQAGBAgIFBAoIFBAoIFBAoIBAAYECAgUECggUECggUECggEABgQICBQQKCBQQKCBQ QKCAQAGBAgIFBAoIFBAoIFBAoIBAAYECAgUECggUECggUECggEABgQICBQQKCBQQKCBQQKCAQAGB AgIFBAoIFBAo4PV8Cw2+7di3nCYcukApQL8Ht7/QLydQTt/wOf6b+dIt4F7OuIXTd3f6joQtgQL/ zRT48kvO91xnvjgj9gPt6V0bsXylfmTFWW7739NvOo2xKY/XjTJiBF/dZP2c0clXW317DU4fwRW/ rS2/EG9BZ33L4r/B7xj/t/RwbhyiW3Z7PU6v1+Hx2vE48MvBDgr/Cfn4L27XRxw09m//QBv8YY3s /OtI5WELHfG1dHg9Nq8XxYkKjN/O1timvx4cddCmsAgUECgACgTeL0aNwF5gw0ekwH5g4wzqBeqx wZaRFWe57Weq33Qa4wzfhRr+TtB4ZD9nDPu7d0f08+2N+VW+vY3v6L/c57/U2//PRm6ny+sBRICp Olxet9XttLm/jBr8Xn3EYc8C48XuD7H+hgfNr+Zyex0Oh9uNAY1YfKcEoAH3cxo12AeDw+sGagBJ hEWggECBs6fAV95K/j5SR1936PTRs7/U//mMf50z85bfdMFvP/pNZ/231PPH7nS7nG6IG5A1SNzg lUSCL/8q+O/hh1uPJPrIKxOqYYhfHg4auDwQVxmCBVozKYnLSgQZEDEAGW5gysi+hW2BAgIF/BQI vDtnbPiPn/GXt/JVjjyFVX3p6Bln/id2vy/UONuxjrzuhY84+IAPcGO2CQ2P3eW0nsYLoh/R4Ywf CHax/KDrkVfkAIG1w+V0uSAZ+YYEgCApItCUbeKOGGQ4GWQANdBYWAQKCBTwUWDE6zLi3UEtXpQR xwKb37TxzQSl1/MsCr/AiO5GXnFEtX94X6r66s4Zl/5qg0DNGS35buDoiI2RA8L2mQvnQyPX39zV meeel/ugAdgsxw6mqjJ7vRZS6XjoF8QPQQZhRqivJfJ/qNIDTRqZJ/BooHGyUyEpgkwYX/MYUcVN NqSbIsgTFoECAgU4Bfh7Ta9IYJ/vBNZ+9hzgDIEjIze+mZ5nyRN4pyO6+8arfKXliJNGbp4xgJGH ztg+oyXfPaPNt+/ilJF4wbf/jX6+/Srn1lGPh0zIPtQgw/EwoYYLQEH1ZPAgCCGhBHzbX2CNxvYP tGYdf2mF0WFhD4JGyAYFCz5ZZeiBsZ8S4Ro2aMEftKVaOgV/+fn8oLAWKPBfTgF6M/zFR4rAPjbY MrICrw8Kr/Ed/kobX/1XG4084Zu2R17s23s+y/6/y3o+ckCcz/P1SBQYWf/Vo4GWZzQb2fOFt42b pR8EUAHwwbit0+0mTyTOkEEU/oNhh+iXw39C/+G13eVDB2AAG+cZDwIDJgTxDRWjxG2x22HGGqoX FoECAgUCFMDL8W+UwOl8Y2QPvkO86ox237n7lY6+UvHl4X5nh/4GZ4MaOGck5/8qHKAGDQL1gY3A WbwH/7Uv4L/kQAW/JPogBxWURuuOz089G5l+35yoP86Jwfq+ORH3z1l8/5yFbL0Yu6wS9T9keTrm Pl78V3ng2dh7n1r8p6eW/OXZyAeeXjxncUrWJydlRkhE/EnRE8Q2L7gXhhq+p8krL+BnKNyaQIGz osBpOZ5eFGIBKFBJ8w2sOdN2uVzcZRFtUOgS+Gaj70u2DjRjG74B8DP9h/jeGeszhorBUN/0srIN DIauizd6JDf294g6IAHWX1po3+ddeeYA0Ja0Il9qjh1W8dXqM5uxfd8IiVS+E89oNnI8Lhhf/cML XNfpxO1cSIvb6bCA5LirXQfy/mfqH//nzhf+54+xv34o49d/W3bdI+nXPZR2/SMZ1//t9f9h5bqH M3/zcPoPWdD/V0v69Q/5y8NpNz6U9usHEq6645XLJj+Y88+D+BExnZVPEwXPYfzs6ScHRZbTxpRU /DdyIT014V4ECvwfKMD5M5i0x2N3wuXea3HYwQGY8tcDzS/jj6x/xid93A/bONFFL1yAf6KOww02 aHGjLW3iPy/oipdADY4CF7BQe74EOvQBB/YBAvCbZH4vONM/YN4p5/b0rct05hxi6MK4I3YxNPNf Dmf6mbj/aqeb+Wv4X9YDzvOPmI8KuziBBsCtu6xrdgLpv/ll6I7oRKfzS9f60j3ya1wQa5gG8Ejw /8NDuaLf3DL9yddmLv5wWvShSeKjYeIjYVEHp8YenRR1OCzyyKTE/KCYI5Nij06JPTQl5sgPska3 X1tiD02NOTI1BmuUL6bHHpwee2Dy4k+mvrBu1GXXr9qYQ48CnrnsN4Pf4pDVQb837nNLPy2v1Yaf n7AIFBAowCjg9rgcTpIaGNuzu4mDAyywRvEzQi+1ccARkVk94ZjPD4NZEMDg44ywBY39Z6E3KuDk vFvez8j111IfPDkgJjBBBqdznGEGVQIl1nNgWLx3aoOWbDRk6KR7ocV/PYIG/GdDOn2Ut/nOtb+T QG8MSPwjoUuzLkY0sxPq0oKL2u3w0PEtNpuNY4fTSd47KMwF1H/4fP1LP5Xilh7RT8NuX7D61qi9 02NPhsUWhCcUBonzgmNzQ2MLJiWUoWZCxLGpyYWhcbms5P0wa3T7tSU3BCOJyw2j8ZxACRefmhR3 anr0pzPmvXXNxLtzS2qYxd7mddpJImW/HXqy+AqxQpLyPeTz9REJ4xYo8P1SgLM79gHPeZpOp9u7 d+/bb7+9fPny9PT0tLS0zPSMZRmZKK9nLnszc8WK1GVvpCxbkZTxZlLaG0vTX09OW5GxLD01DY3T MzNSMzPSM9NQMjOoUA8ZVM8LtlEyMjIyMzNT2YINvp2Wksq3sabLZaa/lp6WmZq8LDV5eXrK6+g4 JSkzNYUq09EjLegnIz01I31pWmrissyUZcuSsZGesTQ9HV29lpnxOkpGOu4iEzUZmSkZmUvZOiWD Bpbq64F6WUZDxF1Soc6pjg2S98Aa4E6S09MTMtPEr2Uk8LIsPTEjPRljYKfQ6SDXsmXLli5NWrYs Y9Wqtw8c+NxkMoD32GyM+RB4YWHY51t/v4/zP9+be8jpeWxJ2q/vXXBLxB6IFaGxJRNiS26Iyh8X WxCSWBoUVxIUXTQxvnQKmHbkEeLbX8/Yv5bb/98qMYC4AlwuBIVdN0ycHxJ7CiU05hRGMjnm4G2x e8c/GHPPo/PoK8Ux7HVDJUV+X+T9ReBPTwohHvyx/eeJK1xRoMA5SAH6tqdvKiYqeLzvrVx19+13 xi6JXPfu6qz1G7dlZW/dkpXNyuaNm9a/v+a15HTgxarU5W8lZ76VmLEyedmK5LTXU9I3rVu/CcuW jRuyNm7cvAFly+aNKJtZ2bRpA9/wrTf5jmZt2ZSTvSU7azNtbN6EjS1btmzashnNUJO9aePGNe+t fnPF28vSVy3PfCszbfXKN7M3rUcz1iEab9q8ad2m9e+ueW8FyurVy1evXrFhw7uoxJEtm9AuZ8uW bPS5JWvDlqz1W7LWsjU2sOsbErrCwHHJwELtcT4bOQ0na0NW1trNm9/ZsO71Ne+nrlm9dN0aKmvW JL+/eun7azLWb3hz8+b3Nm9Zt2nzWqxztm5Cyc7ZuOqdNxcuWnDnXbPWrV9NfAiMielzuABisRCO nO8LNDlI3nT1lD/OfHnd9Lgj46PyJsSVhyZWB8UVTU4umxCdGyouDBcXBS85Ni326PSYw1BYTY47 9h8qsScmxZ2YzNYTo49BOYbr8jWGgQIt2fS4Qze9mn1l6O+GGTDgEVmdFMFhZxIHiw2kZwbpQ1gE CggU4BTAu0IiBkONzWvX33fn3fp+uU09MChVDSo0Nr3JA40ujnIjhcfb39LVXlHfXlbXW9nUW97Y WVrXVd2g6u73MrUM2qEvvHDMguD7osZXG7ilmwVVMT0S6rkBBF78TvvwoM085HEgmpgUTdDqsNeX KZ3g5m+3GhWyroa6nsb6nqYGg1JO2mb2Behr5rW5HaZBo8yg79MP9BlNUqfTxNLQ+XVHdJ+4AYfL Pex0D6K4PENuDzg2+qGPSv+QaLQjFFm8nq/RDKxxyOVUms1dJkOL0VBvMjYYDY0GQ7N5qMfu0OAo a4NmFrvTaLZoDSaF0aS22owSaefV11wWnxCNMfCRX2C/vSG395Lg//1dzK7wiIPhSZVjxZU3xpaG xZdAJUUsOuZg+JLPx8/f89PH1v700TW0/k+VH/99LSvr+frax9bw4hvA399H/Y8e3/irx1eJxv/x 7e2H9h6vOFraMODxIuCEkIL9giiog+1eYE9NuB2BAv8eBcB48VIQ+/V4ARkTfvkb98CQoUvSXVbb U17XVV7b39BqUmgoLx3BgAfJ35wDw6qm7p6yBpS+8kYAh6a912u2sdx1YPjg6U6XBxI9sX1ggs06 ZBk2DpuNVouJJZqwMyMj9ABIXDRs0qnlfV3Snk69Sua0DOEQTvTDAXqAJcXpMOjVPV3K9jZlV4dZ p/G6ENXLgsXwXhMSQatgtJjlg6ZeFGy43UAN/t4zqIOtBHZ+l8VqHxgaVqEMWzVg7MAOGDk5cDBM sdkdw1brsM1udrltqEHBiYRiPpuI1eMy2KzS4aGuIVMbyqCxddDUZbXInE4DAo1JlPDYHS7DkEXe J2lSabpkina1tmfAKLdYDfc/8L/btmfZ7bgi4IkhNbZo8zxe8KTAUQ1u79Whf7p7UfZNUV9ArLg+ pgzAERJbMinq6MyoT35yX/KoG/4qCntadGu06JaoUbdGiG5d/AOWmYtFgcIuRFe8bfGo2yKxFt26 iMrM02XUzCWiGfNHz5h79S1P/2jmUz+77e9XhN39gvg1sw0/LQd+bHhGSOaL2xQWgQICBUABvPU8 P4/DZr/n9rvUHb3GTkl/aZ2iqrmnsr67qqH00Ims99ZmJi6F0QF6/tSlKcuT0jOiE1MXxyUviExZ ELV8ScKb0UmrEtLeiMeh1IyUpVDpp6Qkp6anYJ2QII6MWLhk8SuLFr8cGbUwIT46ZWl8akpC+tJE GCwS46J9RxcuWPzqS7FRi1KTxUtTEpamJvOSvjQ5Izk5MyExUyxOi41GeT05cQU6T4xDD7BQpKQm pKaKMzLi0lKiUpdGpC5dnJayJCMzOjUtKjU1NiUlLmVpQmpaUlp68tKU+ITEqFjxQhRxwuKkpREp adGp6XGpafEpqYkYs1gcGx0dGRm1KDpmSXxCDIaB8eNmYO9ITU3H7XOjRgbOSlmYkrQgJfnFpUkv pCTPT0t9NTM9KjM9Nj1FvHRpbKz4laiYl6Jj52MdFYP1/Ji4VxOTomPjIm6+ZZpKpeCoASQ63yGD /37AUZFA5Iqge+9emHNr3JEJUSdCkqvGxhVPjD5xc+wh0aSXRDNenLFg/c2Ltt8Wf3BK1P6boj+9 KeaTW6I/+SHW6PaMgqsEyozof2L75th9KIGrY3tmzD9vWrxrVuRHs6M/uj1y6+z5715704NjfhGs NpnpDfG7fggcQ6CAQIEABVwOd2le8fOPPe3VmDU1HerK1t6yhtaaxtiImLtvmRX9wsvr3373ww92 btmwcee27R/kbEXZkb116/pNq1KXvZuQvjHptQ3ijE0Jy9YlLVuVlP5W2rK1a1Znb81CycrZkp2d nZODP5tztm1ZD53/ti3ZOZuysjajMntrzvrNm7I+2LZlGwwbG3Z8kJ2zZe3WnE3ZWzdv2rplTRZM A9u25WzP2ZC1J2vbzs2btm14f83r6e+mJ65fkf7+8rTVb2XiWE72RnS4NWczTtyWvTZ7yzubNr62 fl36+nUZGzcs37Lx3eysDTk5WdmwnuTA3EDXxdW35KzJ3v4+Sta297dkb8RYs3NwW9txcOu2LegN 1pbtW3fmZG3HPWDZunUrbgTLtq1btm7dsDX7vS2b39i4Pm392uRN65I2r09G2bRu6Ya1GevWvZmd sx4lZ+uGrJw127bjLrC96b3VK595Zs4tt9y0bt06UJ7JL4EncB5vgK1Crrs0+L67InZOjT4aElc0 QVwUFncSUoZoyvxRd6bAFXZy1KGJMUfgtkReTHEnUSbCz+oHWKPbMwq/3NeuWcvjE2N5OTkp5iSG Oi3mi1ui9gNBxtw2b+wf5ppJNHRCR0Wys7AIFBAowChAX7we7ycf/nNphNglN8hKGvoLa6F9euKR x++9549DMvWwTAMbh7ZX6jYNI5sptL3QxMAU4rY7FJ29HaXV/YXVurImdXG9pKC6r7JB1y932aww bUBVhTWs7ViYiyk3bTA3eHj2sqgGKKqgCGBmFdRbPVaTzaR22QehEvApk8GVMEJyhYQRxGJW9sua a2T1lVgbFL04xW+VwM1Ao2V32vXmod6BgRYUbGCXJ6nj94o2LNcFejS7vVqnV+XxDkARAYELSmzE BjOfWGbvoGxF7NJ0eb9+AjW0oAYuUephcx/0VGZj47CxgRezod3lwuCh3cJtQc0FS4oROjHTkMI0 qBm2DCiUkksvuygxMZ53fUFghxuocXHI/XdEfDgl5jhQA3bwSbFHgp5cNSpsTuji/TCIT0oogS/T jZG5zKWKGpwrRUxOVkHigglx8PUqhbcVHKsmRefhRsIWf3jNb+dv2PpP/JA9TguzyvGnL6wFCvxX U4DxRdLa5+RsW5aUZmiXSksbUVaK0yf88gbnoFXd3NNTWg/7BXCkv7LZIteTSyL+MUvhsMEkae2E EURSVt9bXANTiKazzzkMTk5sHlyefaGBxzILBUIGh41Oo841oPUMmbwwf5OFw2VxkRHB67AMK6TG 7nZde6NB0uEYhKUA8EQfesS9cTmY2WFXgSGkp03eUq/parcMaAlKfHYQ/hyRBNtsHVaYjF0oNovS 7YaR2sfzAWE0EpfT6xx22OVDQ62GwUaztcvpGnDTPG60sAATjGfIYtPADmJzGGD+gBmdMw0y25C5 Bg1xU1anXWcZ6jMZ2gYHmocMLZbBdqu53+2yojHr0GyxqwZMXXJ1g1RZI5HXKdQtpiH50LAGNo4d O7deEJBBpPha1LjidzEoNyeeCo7ND4srJObMxJBzBS84co1ADQAHd9NFaAnkjpsTD4/7W8of/vwU foL4CfHII/qJCItAgf9uChA/xjexywnlTIo4WV7bLitraj9Zfu+02QO9Cm2XtLe4TlfTAekDMoii rKm/osmqNYBlslyhxLDtwxaDTAWDyECvDD5XLgu5u4OzsjhBsFiarIf4tt1i06sJFJrqUIydbYQd dng7wnROZkcAiralUVNfPdBYpWmsNPV2eq0wc+NKGCMtzGcVQGRzmU12g95jHiR/egr6I1Qh5KMF u5ARBt1OHYrfr4m1YeBDI/HYXBbVkKHJZKo1maqNpnqbVc4yexMYwGhusWn1xm6psg7cXqVtMQ5J 7E7II4AVhj50Mbpx7Ho8FgCH3SK3DUvsFqnXrva6jJSGgoZhc3mMemOnQlMrVZXJteUKbaVUWSVT 1Vsd6q6extvvuHVkACAb/Hm6+nrUEE2dB3EDskZ4QnFQVC6wY2JyxdiY/HMLNeKKfHAWVw6HYYyN gCO2KCw2L2jxp7MXZ/069Davkx6ooKE6T3+dwrC/dwqA94FXomTlZKcmJMlq2noLa/dv3DHvL4+7 1YMQLmTFTfLCRl1pm7akVVnc3F9cTx5TOIG+uum7Gz1gGx/X5FUKtsohAxPfsE04U7EDAIUBY2+b tqF6oLZisLbS1FCrb64flKMr5gEL716DVtlQa2yoMzdWDdZXDDTU2BUS6IEgYiCZiO+CwBdSHEFA gW8VdGWENuz6zGkXm3i5iWlDikG3+AQmVg+xiA+UmmKUTr3N2D6kr7YOVVvMNQZD9fBgL+ELAy9A htbYpdDV9atKpZoymbYC8GEyS93eQZyLjnjmEJJ7cOt0LVwC1mAUCDVY23iGDXhnQVoBRkiU5TJN iVxbLNMUATtkqmrtQDta/v3xh2tqamhE5/3y9ahB6qk5700RH+PxGkExeSHwxRWfM7qpgJZMzISg uPJx4vIJ4hKKSSShA2GJx2dHfXDN9dPpI4F+zMIiUECggI8CnPPDzhu/JEpa1dJXVLch/a0VUcke pQkYoShqUhc16wqbNYXN8rx6RWmLpL4V7BP8GbYAfLiDiTOWTviBLa51ITMBpQZBoj4OJ1aLXiFr rNTVllvqK+11VebqsoHaKm1LvcOgJtuExwZZQ9fRpmusNdWVmxvKjfVVgBW7VgMlFqQVDkfsew+f 8QHxg33U8zeav9W0RgM0Bz/nMHZaWsFBSAdWY7fV2Gg1VVsGq4aM1UOGBggLHDUQxKEz9PQpqqSa crm+RKIv7leVSBSVED0cLi5uMAAi2YXuNGC/AE6hZxZWjIvSglgxs0UF1JBrqhS6Cqm6EMCh0JXJ 1JWagVb0Fhn1yj//+TEDXX7G+bv+BtQInwvUmBx3dEJc/sT4YqAGvuSDE8CTzzHgGIkacaXQUzGh o2RiUv5NC7f9aNxM+hDCb/v8fT7CyAUKfO8UIGbq3bF1W/T8V6Vl9cryxveSXns9Mknf2CcvbvKh RkGLMq9RVdIqK2shWcPpgoYK54E7+xg0Xivsc47O3zGsYYygFw5NbMMDCmlz1UBjBRDBUVturSyz NdTr62scKhmlcQD4gM3qlZrOJkNDhaGm1NRQraqtNPT3EGpw0QIxIEAqBhnAKfRLl8M+tGCwgPAB MGbO0AtNcF2K1yABAY2x73bZ7SYYIKymWpRBffXgQKPd3O91GpnIAJu4Sa1r7ZWXy3UVQA2ZrlSi LpOpagdMPQw1LLgXXI0uyO6LAjpIroG44Uco/9OB6g7iEwwZcnWdQlsNJZVEVQIlFWQNaL2sdu3S lLhdu3b4m5/Xf78BNSY+M+m5tcFL9gM1QmLyoaE6N2UNv4aqFLLGODHWtAGhY2z0iRlLdv4oaDb/ ObNf0Hn9mITBCxT4niiAl4Gx322bs5KWRHPUeDMmZWVChq6uR5JXR7qpohZFboOhrFNZ3NJb3GCS KMGpkcyQm4URs8dlDeLhFueQSgczByLKkTkXqn0EszE7ssNm1io76vUtNQN1JcM15daaClNNFVDD qYOsgfyi4L0kHViNKmNXo6q6xNRcD4WVtq8L9m6gBvRKDCRwDcIIXBGFRs5eZrYaQRC6I/Z1yI/6 P+jJ2uIi1Bg21plNDWZjMxkj3IO4BCU4hf+Ve1Cjb5OoquS6SomaIAOqKlixYdoAoMAhChgBpHB5 LRb7gGFIbhpWWhw6pxdBhYQaX0IueGO5zApVR7+sFqZwSBxyTYVSVwXJBSoviCFx4iUffbSHRJfz fvkG1AibE/zUOzOSTo2PzYM1HHoqSBnnoIYKqEHewnGEF3zNgKMkOKHopsiPrhh7G35E+PGd+Rs7 75+acAMCBf5dCuBlIPck7+5tHyQujlJWAxdq3k7KzIhMUFS0yAvrNcUt0E2p8qGnagFqSMqaXfC/ xTc/0IBUNP63yeV1GIb7alv7KijNCIqyscutg8Ea3Btf5uDJ1kF1n6q1VttcAdMGFFDq6goYx8mu 7abQWzhROYn32rzWAbO8R9vWZOjrJk8qcGPgCgwZ/GLs7f0O1DiTGODMVNAP+rdZJcPmtmFzr9Oh 8roRxgUxhwlK1MBqHJTJlA2QL1DA3rGtG+hDuDdLMmFxeoaAEUi2Ite0yNSN/Yo6pa5FZ+x1e5lZ H/2AIGyEuBw8r/SGfrmqEeIGFFOAjH5FCWQNGNkHjBKgxs6dH5w50vNy/xtQg2mo4IILWQOoAVnj HEYNmDZKABmwaPiBAyaYAqDGleNmccjwPdXz8gEJgxYo8H1TAO+D04UshcuSUuwymKTbkZwwZUlc X0m9srgRgoa6gCBDUdQsK2zSNvZ5rQ5KnRH4SObM2OpGmhFpeRNcreTFDcryZjhfqRo7MFEBOCkz EDvctkGLTjrY365pqYVFQ9/Zah9gZgv4RbEk7JTAijxgka16yGsd9CJJrIvSdPheWPzhhQkaVOnf pW2GC2x9Bn18kOFHDQCTye3RkbctGa/BEnz9MAzE/CImgwnRKW1yVbNa1wlHWeQeYUmrMDCLyzs4 aJErtM0yTZ1cVy1RV8g0NQAOs03tQjosJt9Qf4QchEE4HbgD+UKmLod1Q6YpA3YARGA9EcdH7N69 84yxnp+7340aEDTOUdQQw2OKQjZYmAk3hQMvyGrvR41bBUHj/PxZCqP+ASkABgedD8Kfl6WlIwTB MTC45q13xQujukvqVGXN6sIGZX6dvqxdVtTYn19n6pCBPZNun6MGWCNEFbxXRivCydFeU9SoK2nW lbVQqGBpvVVlgC6JBXeQAsoLk7HD5DIhXsMAX1ykpYL2CX63LCLOwSMB0YxC5MjMTgyfL3T/HCMY QjCzQgAOOHGwi3GgYIM15tW0y+v5IeySRINLMIMLbsDXMeP51BiaJZgk4EzlcMACDl+swOk2h8eo 0rf7zeVlUm0J/Kyk6mqtoQdqK3RF3bFBk3gFucapUema+xVlSn05N4gr9ZX98gqlpj0mdtGuXbv4 /E2+kZ6vf74GNSbGHRk1cW7w3Pe4rHHOowZSqZMnFXJnoSDojxcmawiocb7+LoVx/0AUAJPjEzDl bNuKrEvEYt3erM3ZcUtieioa5eXN2uImAIG6ol1S0gRTuEOB4DswROjwiT8SHDA2jOg/SRnM5U2a /Hp9QaOqoB4IguAOTafEz8jhQQvjBbMdEyJALwS+iv8eK1uz7tAbGZrtHswmaGMBGv77Zjw9IFyw WuLwNFzfwnf9NYx7j2iGa/kOkVmEUkD51GvY4NvMxs0Bghi+v9AgeT9wi7I69QptKwwfMm25VFsk 0xXCYi7TVqHS5TVj5KAHXzhquL0mvakDzrdybSnzoSqBxAHRQ6Pvgobqww8/9LU+v/8Qaozxx4Zz F6mvogb0VOe0hoohBWYGQbAGJuPAfFIADgE1zu8fpjD6H4YCYK7cRoApLpCpj9iy27Nx86akhMTO 2sae0lpFcZ2ssKazqKa7vEHfLvEOQ3Ig1ODDYUIEfbzrumWQNZSlTdqChgBqwMZBqAGgYDwcsRs8 oI8CumHihjmdMXKfIYCGAs5N+ig+JHYSjefLYBEgBIcJP5sm3s55PqvByf7zWT1HDd+5viuyJiQ3 kdwB6QPCggUWCmakgNUbBSHePOctTsQ4MEefEWKCVF2r0FdKNICMYrm+TKqphPECmUNwIQ6m7DIY DISmocFhCVRSEDe4G5VUVaHUNsB6EieO3LNnT+Bmzt8NYOV5jRoEc37hIoAaIeJchhp7Lx9/K346 +EH6fk3n73MSRi5Q4HuiAGeuWCNeA/ls0SvciTBhEmamg9uoorEdjriKsobummZFt8Q+YKb3h/in j1eTngonO72aXnlHUQ2CxyGbDBSThkpSVIckJMPQUDFVE85jPB3uT+zr3u6yqI2GXrW+T+0wWNkx hAMidg/iBvxo/UBBl2IpR9l1TqMJH/eIkWBUvivwsfka0GhZ/ZdQg4iHBmyBnoqBxaDNrR6yyQzm PqNZCvUUUAMnchTg2jjsQnml1nb3K2ph1IB6igka5f2qcqWmGRZzdiGfUYNRCRd1wFCCIEG4ZsEI Dgu7QtNoHOqzOfTi+Kjdu3f7e/YN5nz8cyGghj+EBOopkjXEuQJqnI8/RWHM/zEKIBIPLBQ5bNOS l+Ki4MzI94rZUFEJG4dLorX1q01aPWbW4Kyc8fERqIFz8EmtM/VUkwVcWVgP9RTM6IgWVDR3e4bg mUvnceXUsNcBwzfmbxqSaXuK6vsLGiSFjbKqdn2XDM66bjvs4OwqOIXLAzgTl8KYGHTA/AHoIX6P //QHiOLfZrvsOLseb3C6Euf562mDxZWjZ5I0bFa7bsjSrxpogNTQpyzrV1ar9V12F2bf8FlvqBmF p5OxftCs9EdhVMK6DX9a5AkxDfaxST3oKmS+p8BHWthd4Cy7zW4yW9RwuB22quHEC/VXYlLchaGh Ot9Rw2/7ptjDL6FGHDxvP7l8/Cz+weF7ovy5CmuBAv/dFOBapu1bsgk1wAK8pKFKSUsljgklEji1 FSyTMU1wW/rLmCGTB8hUjT3wSqdnQKruKqun5IfF9fC/Ujd2uwwW4vJMEcXtBBAq6Ao2t6KhW1lK Pr3aolZsAG66Kut1Eim+zXHcBwokl6C5zzOJG80JB/yIwI758IuDiO9J+huwStShDRsHPxfdkimD 9QMYsA7qB3oouyAC+nSlioFyYIdE02y06KgJvz1cyXcdjN8KJysAh1LbhLMgO0DQgEcW2c15whO6 R85pWF5fBn8MfmgYzEkMmitHXFzM7t0fBnRlvpGfl3/8GqrI3UgVy+0amMLvy9bw4uDYQuh8YHRG iifklWW2A/J3RYH/EhyZ/PVkiea2ad4VmaepGemRmLMTWRzYIVbPlUuUP4qnkKJZwtlE4dSGIULg XGrAC++BjrIwjXHMaQrtcS3WD5tnHKgRse/ycbMF1Dgvf5XCoH9QCjD+ieklyBrOtjFndmpmBuAB 2ipm70aWKUxpRhYN4uEIDKfABbsX2dBRQzMsUzQF4v5shkGTXG3ok9u0g3BT9VjpFDQBy0aB2Z0Y OPqxeTRNfeTWW9Cgym80VHRK8+uh3ZLXtHkH7eifmDUyUDHpBsOgkZBxmhLk0g7kFtJjwfULedsR c4cAbUgofHh0KqEEClqimg0ALZkmijF/ugs058DhGhxUyRQ18IyV6Cr6tXCLKkI6kT51y6DdBKM5 nY6u+Bp/SXggvZPdMThoVqNAgmAevDZEZ5DrFzOjI1oQFhAW4gG0RHuGrLguIxfb9cTHJ+7e9XGg hiQ+tnBcJjiGjOIHFX4UNbxNYOOru7wl7wRHectAP3wjcHTk6SMr0SwwDN7mqyfyBryect6G/WlW 5I4pYoYaMQXT4o6LQp6a9Nz7YTGHg5BOJK6EJoSNPBUSeXRa9JHwRZ8FRx+aEHcqSFw2LqY0JKYw NOL45IX7Z0QfCo4+RgoigpWC4HgKDAyLLRu7JD84oSwkoQDTZExKODU29gQyrofEVIbGVYxDJwl5 xO2jikIjT4ZGHJ0eezI84nB4fC7C9G6IKcFctIhJD0b+84SS8ZHHJ8UXoGAXvrXjEyqviy27XlwR nFxzA/IrxheOj6NC8AEgiym9eclnl42/C48Qz4a+doRFoIBAAU4Bxsqyt+b4rOEeL1ADGiq8Kexl IcYGUKBWDpdVZ5S19vTVt0mqWjQtvRbNANg3Z88+CEH0nwMJAxmHZD1zWYFkEjBqwBDBgccqUUuL q1XltfKKxq6CanlFe3tBQ09NJ2OxuBKzUbOpOfBdjs4wEqAG1r4dVFEjggynF/OaI9EuOmd509lF 6Qy49DrhwQsUonTqNEh+CMPA5J4MTRzOYZNJLpNSTF+vtlGqb1JoylXqCpWuG1N90Cl0ycACHgzI JC7icJJHLhCEyw4MGhCvQTOG6w0SuEixcI92w2A/TBhoSdwbV/eNjdAnPj4esga6DrBobNvgq+uH D35VHMWC06kH1phvYBt8G2pDHOUtA2teg/VIIMDRQA/YJn0jhuVkA/OfSdegmVAYcVn7kZ3jkL+h 12xGqItvwWMFjI8O/d9bI7dh6qVgcTFsytNijo0Kmzvx2dVADYp9iC1mfDj3D8uKxTvbXlpXMiXm 0/FIUSUuGRddGBp54s9vVSd80HVP9MeT4w6PjT4eHk9hFBNiC8fH4Pu/NExcHhJfdmPUyVCgUsyR kKTCcbFFwTFlwVHFoYkQYXKBO2ERJ3+fWbLoQ8X9abkzI/eHxR29MeZEUHJlcFL1uAgKMxwfdSos viAk+mRQ9InQ+LzxcfnIHBKytBGwFSwuCxOXIaJkclplUHzhuOj88Phy3MXNEfsuG38Hnrfv5+a/ ZeGvQIH/dgowroPp65JTlnLO5kcNP+8H12JMFqYHdUsX/GmRCFdR1KAoaVQ3dNnURgIO5s4a4F/c mxe7xILAtzHjBk3ThMwgYOYoDq/FvGfdmvvvmDX++l+MG3fjnbff+/7a7WqTC1Ml4XudNDgABMYk aUjYRCfgcpBrfCwNiizwbTIiIKKcDmKFM/28Gd//+/duevSB2U88+vBjjz65YGHsyaIaC4OA9LiI B++569FHH33wsccefeKRR//+wN8ffuCvD95/5wMP1Pe0Ntcc/8cDt00MuX7mbbcmL18Bb1o7Mqt7 hmDURp8ozErOJQg+Ip/SCSwfCdUR9K1QN5HTlJw8bKG/MiHPFQV9gEtzros1wQ0mmWVRfj5WDP5s tVqXL1/+xBNPgKWDRQcQIcCuscG3+Trwu8Uu6Iwe+EagPsD/UXMGGPE2gQYcRHglRwp+Cb6NZrwl OuFXOXHixL333ltbW0unMIqIgn7/24QPoZgaH1MQElM8JerIqPBnQue8Ex7rQ40g1EefemZ9LYw6 9f2Oqa/mhMQjsSHEihPjXtm5pdYDF7T1+5rCFn0UtLRobMSxKUkVYyOLQ8SVgKFxMbnB4lL0HJRU OD4B3J4iuAFDAJewOErDPjGhMPjVT17Mqu70ejeeNN3xyq7QyC/GxeeNFUN2KA6NKwP0hCaU3xhd MDGlEjIIxBzAzfjIwgkRhVOiClBCIwqDowuCYk6NjTwKiEGBFmt61EeXBt1Cqf/ZbdJaWAQKCBQA Bdg7sXlbTiJQg+1iflRMEU76GUYfMAoSE5xuU58C+UaQ0hBZcI2lrQgAlBbWYdommlODdYP2YNso pLBi5w4ZjKr2LlVzJ2buAOKou3uBGuqerpDrfjFGJBKNEl034Zc/u+F/RKNHiy66/JY//Fk2TB+u 9DXPsANjoC6xQnd+oQN6M+LDLgsNzAcUPq6M5lAVkTnEM7jxveTL6ApYxohGXSwafXnOroPAluef egz1l1wkEo0Widj6ItHoUaLRV//ilyeKC3561ZjLRaLpYSFXXXXNJdf+pEXSpzVJtQOdiBZH5tvB YZndCdkBM7vR5G6gC67PE22hctCskCmZsUNbjUSFMJQDOJCrkIkbuCd2L747s8cnRO/eg4wixPAx 0cbrr7/+4x//+KKLLsrNzQXlent7m5ubscY2GHhHR0dlZaVKpeK7SLFeVVU1OIjk7V69Xt/S0tLQ 0IBtLFqtFodwLrbB5Ht6esDb5XIk9aV+0Az9GAwGwAQuWl9f39jYODw8jEOorKurq66u5i1xIvrB Grsgc1dXFy4qk8mwiwGjnylTpoCy999/f211HZc1ZkZsDY08SOqdmOLpscdF4U+HPL1qkvgovt7B +ZHzdvySows218K1urFVMu3F9RNijgXH5wfFHApbvHNziR42tA/3V095+QNoqGi62MWHpuGbPxLa p9wgTBcbfXxy/PHg2ENoH7zk5PTEsonifKizwqNzw6OOT4n5fPqinCWbT2J82Qelv3tx09Toz0PF R4OXfDYl5ujEqPzQ6GIIGuOijo2POBwWeSQk4kB49OHw6PypUbk3Lfrn1Jd2TV+0f3rMsbCoQ1Pi T01OKAqOppCN6VF7Lg26ifwz+KPDzQuLQAGBAqAA09Vs3J4jTlsKJoxdjho+2qAKBQBidxna+voK qjDLhjIPQRnNmvxGaX6ttLrVbhziDJxODyz4BB0wyRoRVF6ryKvWlNRpK+oV5dXa5tZpE4LBsv/0 yOPNUhm4P2Ileloq75w5Bbx99r2P6GEwYZCBd5V9zYMzA4XglEsDpdmgCJQoSBByBxr4hofEghYo d3AKvuRRbdm8OvOnV4t6ZBJUnjq6GyB155/m6SHo0CkDXo+8uvSw6Ipr9x4poxoKOdRuy35LNGr0 Z1+cRJ9Wizlj+Wv5ZXnIN4UwvT55KaWr1cFvtsfpNrAcI4HoDPAUwNEQYEWiqOX5QzCVBs9ViIwi sH0wVAuQBncSkDUQBGK/6667Ro0ifLv44ovBwMGW7777buzefvvt/CP/2muvRYMlS5agi7a2ttGj R48ZMwah5SA7XKbREgvwAjDxzDPPoOV1113HENUbHh6O3fvuu4/vXnLJJTgxJSUF/QCe0A9OzMvL w25aWhq2r7jiClwRjR955BEcDQkJ4YP+1a9+haNz587FLvCFn4jRovKqK67ed6Tokkl/uiNu1+S4 Y5h6aXxE/uTIw6Kwp0LmvA3UgC4IqAH9z40LD72wsQISYUObbPILWeMjoYMqHg8e/vIHG/KVdqf3 gz3Hb1+wbdqSg5OfzZnx7Oabn8+atWRf+JLjk2NPTV20K3je6qmLtkxasGXyvA+mvLB3WsTRqdEn J0UdDn1l17T5786Ym/RiZg4QffPeljuefHvmkl1hC7JnPP/+zHmbpr/y2dTIYyHR+8Ijd894efvU ZzfNemXnlBd3Tok8FDJ/xwPxOTXD3tuef/OOhVkzFn04KfJgWFQeNFSw198UtfvK8bfQxxOeMP1K hEWggEABRgE/asSlM9TwEmpkpmfQMY4XfG11DjR1AwI0ZW2QNQYKWzDpBsL6EMoHdACfgYjBRAMG MXjTrA59j7SnqNpQ0jJQ0KgvatIUVKoK8rcvzxwjGnPnPX8dcNK0SQAIN3xw3AbvsPqu2beKRl16 orgFle3dfT19nQ1tTTKNiqABC/TqyEzlcbbUV588tK+ztQmf72a8y25PT0uTzeLs6u4/mnekW9aF OqfDtnFl+s+uEqmHBgdhg7D2Xf+LKyfOehRcBcF7SEXl9fQ3VBwUXXTl7qMVTFICM1PszFoO4eT1 Veuoider1Cnkui5kmkJANxXkOVdXIkMI8oQweQgMnrWjFWVZ1xk6YB9R6mrgkStVFyN5iFxdAw8r zGLIhKdAY3y9u+Lj4xCvwavAqHfs2DF27Fhw44MHD6IS3/8mxHkw8wEuYzQaLRYLBAQOIgMDA0ND Q/zyQAq0xC7vCmoutEQNjmLh2wEzBOohoaAfrmvil0Cf2MWCXVyI94Nm6ArD4LvoH4dgdsEunjVa Tpgw4fLLL3/xxRdlEjme16iQe2DX4NbwCZEFN8efgqwROnclgsTHxeYBNWDdHrfk0HPrSo0Ob11r //Sn3pr40h6UqfO3T3xyxc7cbnDmTz/PmzVn5cubm3OV3vpB78FG60NxH9y08LPJC/bubfPuqlJn F6vKBrwFUu/f4vfOnP/R9Ff2hc7LStnfU2n2Vqg9PYOUfXj3oY575yxP3VVVNuQt13o/rBz+W9qx 6fM/CH95zbys/DyFt1LlPdzmfTztk2nzNv0pYXcvPhe83hNtxo+qzPcmHpgeeSQspgiIBtS4JWLP VeNu5fIuAYewCBQQKMApwFgkZI0zUQP1ABTma0Rrm0vX0CkvrpMUIj9hE5xmkdUQjk/wtjUPEKtB c7Ap+gNxAN/7Vpe+rVde2qjMa9YWdurKe5WF1YbSk/FPPywafWVVu5rsF7AJ0NvILNcuS+nRfZeP FsUvzcyvahBdMoY0SPgAv+iSu/74d4UaoRzQklmem/sEvsovZbqll2MzBz3e1sYK7OI7HYgzarTo sisuPZpfA6DJWZNx1ShRzo7deWWVjz34h4tHi1blfAYHWfpmdCFtr6q67KBozKV7jheBMyKGBLm0 NP21v7hGdNkY0ZNPPo0Mhv16ab++FY64mE2JlQqEeGOiJcRcMCMKBZfgftlNY/KpQYYapJuSqkv7 lYWEHcoqmDmGrTpfdhRGaqLVCGs4BwLUoH7r1q3z5s0DGfkujRSGIbZwjo1NsHeseQOseQNeSfSH lGWBGYUWXsm3A7vchMFPR4PAhdAA23zhpwQmqOWn8AZYY/fo0aMvv/xyf38/f+Iw9ogm3HN77G6o feCwNCmhLHzxF0CNsGdWhcceHM/irMltKfLIM+vLoVYzme25DdKj9dpT9Ya8Gm1JvVwNCdPm3bPn wKJV/+zyeqFoAjDjYbUMeu98KfueRTuxjVT1AAUkpoclXmr1/nXJ9tnPbfikdlgJvPd4Md0veja4 ves/Khev2IFnisYSr7fX6113Qn77i2+lflyIXeoHnaAHr/fJmLWYo3Fkzdz3GiYuPD5RXBFC1vAC Qo2xs0jWEBaBAgIFRlKAvRSwa4zUUJGsgbcFh9iaUMPl1TR3yUrq5CXNqrJWoAb0VKqKFmQaGdIj LJraUj5zbFCIN0EB2ktKGjRF7erCDklem66sQV944PHbJ1927fWtagIBOocWmMChWLI15n16tUgk TogrqqkTXTRm6fL0Tz79eMHLr44a87Mpk+/0Woa3rFx+8SWjlr2eNqTvTk8Rjxr90y/yaurKjl85 WvSjn/26sKKp4ORh4Mx9jy2AF2z2u5nXAExGwahx6RgGQDsPFYFjEHsGu3dqG2uOiy65bPuxXHAh ilgHdLjNzRVHfvPT0WPQyyjRul1b2tStUh3m46ugpLVaJDmvwbRN3C0K46avUN8t4MbNmNqVjOBK pJyixFMQTyh/iKbZagdnIsr4G38JNaieLZzn87W/jgFxYGfEBtj7iD3aDOALtkcy/0CHgQY4ispA D7yeN+OV2Oa7/BJ8e2Qz1AcgCaE6kDUum/yX26J2ADXIVzaueFrsUS5rADWCE8mHdgKcl6KOzl1b Ad4OrzbQHBs4cRhTypMTNT2DPXsPRb6/r87pnZP0/qy//KPfRJ8jL7524PfPrkYmG4hT8xa9e/dD ka0yDZ7jvMy9z6fvwwY+KKLe+PD2v4mXbzyE9pv2VWe+vxdYW9PYetMDj7/+UW7EmsO/fW4Zh4zI pNd/d9/ftn92EI/kcHHvHx6Zr7JYZBbb3xa++efIXbOijkxckgvvKajOEPRxc+QeHuXHaI2HLSwC BQQKMAqQpcCbvX1bfHIS7bs9WzZtXpaRSZvs29X3qel0KZo7ZRWNqvI2RX4DjBrG0nakKKS0IQZ8 BkKzT1ZqFGIA+EJGYpBBi6S6SVpQTXbz/AZdea0m77Mlj9036orr6mTMGwq4xBkvuIbD3FP+Bfh8 ojiquLpOdPHVn53KJ2buscdFRP340kvUvc2PPXyvaPSYzJWrtm3bmJmZPmrUzxdGZzZVHoN1++Mv ToIFeR2ax/56z4QZf9bbvNtXr75WJPrwo32Hc/Ozs96YOmOsaMxPtuwtIgZlR+SHpq7yiOiyq7ef LKMTKRaEiQ2YTcqseD3p1YsBHBeP3nPicL+mlaZVUtdRShBlw4CpD3lFCOnQDy84HUzUPWgY7KW4 PyZrMNTAfK/lCAaEbELk8TkI4IZP+1AFWDf1cZ4uECu93otC75sVvRM+VEANJOWYGnOErOFz3p4Y d4gcZeEEFZtLGqqNlZACtAND85I3L1x5NOKdE9HvnJyTuOtUAyYu8e7cd2z2c29Pn7PqgZeWbfv8 OMRLhg4f3fPM2yBZRV3fnU+8NfPJt3fm10O+mLvs4/i1J2DbOnyy+o7nVt08b/2S1YdRv+nTlgVx GzEks8M7YPFGZqz77bMr752/BkGb0K9p9B6lxol6YBay/v/h4cWdap3M6b3z+XdufWXv5MjjCCqZ lFiE0cIoD2v4xUGz0BWeM31WCItAAYECnAKM9SHnrc/z1u3NgQ8VsqazT1asAQH01niQbEraVlzZ W1irLm0dKG5F5hCkQ5fXd8CxFg04ZCDVui+4A6fAu2hgcLCzX1HZAO2Wpq7eK6nfuTJdNOrqFyNf Bx/A9zKQhgQZGLHtQ08/dM8Vo0T79+0or64SjfnRnoN5TASwrMxM//kVY1T99Q8//L9wtfrrUy/8 /R+PPfnUnH/Mi9174FRj2aGrxog+PpxL0OXRP/7g78dNux/cZv0bb9x41SUKtZFAwatr7SgXXfyT lxNWW8kHFqKNsqn6uOjSq7KPF5NohBTuLpvLbGKhiBA6dJ/u3iC69LL5iSmaQSUyFirUbdqBbnhJ sSyFbIYRjBznoRB1wPOQbEQhVdRDK4VEhSRuINmICqEfzUANWM+Bi0QRwo7/AtSIPi1rBCXkYzq/ UHE+/JeeXVsC1Kht6pg1d8XMhXumLdgJi8P0F7K2FmjA0nfvO3rTPzL21JN6Smsnsxd4+7zUHQ/O X2lzemvblDc/s+bmBds3nmyFCmtOxt74944g7mTXRwdnPvPmrQuzX113BPUbPm3+01OpL0WuxIPH ZJLoJHVL4V9eWY2u9Abn0WM1Jwva9ufWHiztXru76vePxDRItVKn977Fm6e+sGtSxCG4ZoXGnAqJ RQSiDzWYLUdADXqLhEWggI8CYHpucsWh7IUIMjOa177zXlpKKo7SlzCxYp/QAftFX30LzaNR0aIu bpQV1Cmr22zqAWgcwDu5py5f4yT4x0IRgU6gysD8qh6H1Wsxep16l6r7hp//z0WjL0tJXyHFCytR Kvr6miuKXn5urujiK68PDnPaNeXlJ0UXXfPZqUqE1HkcpiWvLL72qit18uYXnn3sih+Pa+kZstMM SKTf7tPqmyqPwq7x8dE88AevVfX0I/eF3PSnAYc3+723fnaJSD1ghsUCyuyDB/aIxvz4yUUpxAQQ 6+GQ1pcdFl1+bfaRfJ1ZrVPU2bU1y1IWZK561wB/KIdO3d900RXXRiQuIy7vMiNeA1EbzHUKHRD/ p17ZwoGAxWsYebIRnqgQcgcEDeS8ZUHi/BScRbIGSkJiLKzhF46sEXbvrOgP/LJGyVSgxsQ5sIaH xRzC9EaI14M1HHaNeRvKkVMYXhXT5r0bHHkgODE/OO7YjfNzsisNSDf8yb4Dse9+DFXS4Zq+2fc/ vv3zU3AjeDpq/V+fSTLb7HW9ipsXbh43b/P2ch08iZ9L/zT27S/wcJv7FLPmiG+am/LC8m0Q6tbu r3khadPihLW/u++Zjw+V4PuhtM/y5+fFsJwArRe8kvq/D7006+8L7l+8fOEbn/328aS2AWe/y3vb E/GzXlwz7dWdk6O+mBSTGybOh6wBHyrkvMVZ9NDwOxAWgQICBfwUwNd+TlZ2RnKKBW5DrV2vp6Sn s/y3dNxv3SBtFQKhEe3c0A5vW1lZk76xx67QEQskFk7gQoXeL2AIqyAXWHzEY14NCuImvyPMuGod KDm8/wqyXl/0oyuufeqxx+c++tgvr7j8UridXnVDaX0HPgkbak/Au+mPjz3/wQfbnpvzpEh06UMP P4ZcisX5h0SiKy+65OepqenihHjRmCt3f36guTb3EpFo3/FCkilshqcevm/s5DuNkJjWvn2lSDT7 rrufmPvC3XfdCoWT6KKr9xwsgOnWA7W6W1VXekh0+RVZhw53yxr0qrJBdV5m2jOI7bj9nj8lxC4c 9+ufiC65JnvP57g/zuexppg/FoYI4BgRFc4jDJFr3Yq8IgaTQq3tgWyCEA+osxD6h2ExQYPThNPI zXyoLoj5NbiG6quowTRUQA1E1cGHakJ07oSIY89vpii/ik59+EtbkAzkF/FF1ycXXr/wo/dLTajf vvdwwvr9fWggta7a9rne4wVqFHR5Y97egy+E4j5tyPz1Qa/u2lQ0AGR5LuPQ7CdWtBpIMGl1eA93 DtXqvdBQrTlYv7dCiRMrO4fLOgZg+C6TOW77++K9hd2wesDVrLJ7uGrQ2+b15qm9s55aUaHyAmvy +x21w94Vx/UzlnwaHnkKphmgxs2Ru68adwspUXmhBygsAgUECnAG7/0gZ2tqTDzC8brKazPjkzNS UllkBHFHwgXYK0nzxMMlwAXhyGJnVkw6RIYPAAc8p3SmIYnG2KscUug9w5Q1CvUI27bRtNpI4uF0 2OG8hBnCHU15+fP++jfYvn8kuggI8tNRV0e/GFdV3Oqi3Fa6qtIDsFOLLr4G0ROI0Xt5ydIhYA6p pU2ffbT9R1cwY/XFl02/8y+NnarK8pMwdn92pIDYu3P4Hw/ed9efHxtwedeveu0q5mrF3KtGz7rr 7uO5ZWR4xZAJNQyN1bmiS0Sb9++Sa2tV6nyp4nhj6xdPz3kAkX8wr19+8Zg31mwCs8IpuA3KJYKQ dqKFDRHiw1YNxAqkQIf2iems4LZE0MB8pdDUCvGETzXOhk2uSiS3UWGA6vWKxeKReajO4x/iN6FG 2FOIDYfnLaL8YOxAlB9Q48GVpQiV/7TeMuXVvYj1Hpda9YuYU+OW7H+n3AuweP9A0x8WZVWYyYcK nLzbRIiA9v9I+gBHv+i2B72aExa5d13xcC9Q462SW1/cNvOVjZ90k68UToFbVIfH++anLQk5xdhQ wHfa6+10eJ97++CsRTlTnt+8vZa6RcHp1V7vq1n1t83PeXHVUeyiMTrJ/Fw+Y9FnoUuQX7EM1vBb IndfM/YW9lEkwMZ5/AsVhv79UgAsDJp8rJEpPfHViL7y+t6yuhXJaZA76GXBu4JsTGCTxGoZQLjg +oQt39cXmST44vEOSlWK2lY4TaEgiEPV2mvVDKEHJIkiQQOpP+xAIJzrdhpMqqaW/rKqvtLKupO5 9XllHWVtzaVtyk41JX5yqpDWQ3TRxbsOnDDb3cMWJ6brhuEEggsivr00jcWQXqccxgwdPMqP0ATp FIknU+IpF5CJPimZlIMB0DWhx0CByyozQ6ApIMyM3kw0PfmwUl2vUBbL4fKkKZdJS/WKps6mGr1W h36AGgHNBNNE4RbMmFOJ57xFdAaUUQjusznwSYthwGxBVGLIQPjCpQ8maPgJ5ftsvfBljVGhc8Lm vjs5/tg4yihVPDGxbELE8ekxh2+en33bqzvCFx1AFtzfiIvGxhch00jo/I+mvrBu9uLsyfN3hc3b /ofoHbc+v3L23FUPxX4447mNt726/eYX1ty8MCs0al9w5OeTF2yf9nzW9AUfT4/4IuiVj4Pn50yZ +/aMp5dNfHL5ra9snLkg66aXNk974f1Zr7z/18RtM198b9qru0Ne+SRs0cHgF/fMXrDp/pgtsxev DXvuXaSZmr7w0xkLdtz04oY/x++8OyJ7+ss7pkYcmJZQGhxNaXh5vAaTpPH46MNFWAQKCBQAk8ME GFgjU3rSKxGS0jppecNbyekZCcmodpjMTtWAS22w6YyUS4p9qIMbotC3M7ILcgYJ/0l8edc0S4pq VMhPVdTQV9TQVdKgbOnDzHjoHIzXzvNKcZ7p9g4ptV1lFaqG5pbC0p7qRnW71K6HHgtNLV63rL3x JGwcHxwtpQsxfRc6YeiGlxesH9X4+Cc4YJ/ulDYQjJoiydEDiwzHJqzb8Ixy2DAfHwlMGAMNBQV9 EDeHyyfG5Ha6bW77wPAgbCwtXbIqw2CzTFahUvXgDHRCXbqAVgiXhpHGAQWUaUgByKD5lZivVJ+8 WKKohiYKVg/6OfFL0BZOBdwioATzdED0sFhtg8MWo8VqYNlxrZRRZPdONhpqfR4v3yBrIHshMoog DQglko0pAmoAHYKWHAb3nrjk8GTYxzHRKksVODmmeNLi49Mj9k9c8gmy2iJafHr84cnR+8IW7Q19 dV/Ywv1TI0+ELzwatvhIcNwJ2EEmRx+bHHl0clw+GHt4Qim6nbj4ixmRBycv/nzSkv1hi/fPiD8R tHDvtLgDkyMOhC06MDEmNxyNI3OnIP3IogM3xx6aGrNvUtSnk6KOhkWeQMqRkEX7kSx3UtypG5d8 HppwDGMIjjqJPFfTIz+5eMId0HzSlwOerLAIFBAowF4FvBF4IYAaqRGxcKztL617Iz5leWIKkKKv trm7pA7pChGUIW/rtZnA0imdB3Fg9hbhRIoHR4xVvxzTxcoROV7USKWivb+4sbe82aw04pXjl0Bj FtBBX92I6RhWqxVtbQap3GMeBlslZo4Fdmq3pjj3U9GVP9l2IJ8MkdQ/5bjAJgAAa1rwhzAAh4AT vLARATvIjxhogj8seJC19TUH6mH0kDoIWWBtwRZugDXzkFxgtKgwzbfR3G12QMVFjsToFOfSXyoI AB/SGXr65VVyTZVMU6LUl/N5wNW6dsy7RO34rdIphBqADEwdPjSslCnapPJWiaxFrmqFqAJjhzg+ Yvee7axbav0fWfhdnHEpqiSK8WrfnzPafMcu+OqY0HtnR/k8b5EXHRNtjJr47Ph/vDkp7kRQYjml NGTzXyBfOrJUhYvLgqJPhonz4OAaFl8UHlUM4JgSlx8uPgWImZBYMjb2JDLfhiTkI3lUuLgkKLJo orgmTFw5NiYXfryURB2zdcSXIhvhhLjy0PgqZDWfsCR3cmI58keFiguRvQQ9w2vrxsh8xOuhJYQd mComIQViBGENElhNjEdchm9USI04NrZirLh8fFLBuISTACYkWocRf0rUvtFBd0H5SFT5tyjzHYQT DgsUOD8pQLEVHu92zK8RLZbWtsFF6s241Deil8JRCuEY0qJGeXmrtLS5v7QJUynRxNqcXYNBkp6f MSKXB8lDADeq0gZdSaM8t0pT0oRzMZ2foVNGX9zsncN53E4OnyqSFMBXSWqgAu0VLAJg+SwToE2j ln2w5+P2fhlLVMjECkbbr7y4nOOhY7rElxc6xPCNqnEiL7TDxg/cgH6LzBDAHQzDaYNqiyEKhmul PLd+XooTWap1jNPicuul8lq5qlKmQihfKYADSi1MI67SdlhtRroGLuvTUOEy4KZmzPcK51vksEKE IFvXYZJxrb43Vrzww492Erqd9cJujVN+xJoLRBgBnotPQGP6Q9+NM49fkBoyFIdCgkMqhKPAbCuJ akzAQuVZLjDhXBL0xzsjdiIP1Y1xBUGJFUg2CFkj7On3JoL/Iy0tnG/F4MM0CxKfhgmcH4XPjkRJ 1GNJI0Q1NJXS6Ym80YDgBtNnjJibiawkpwvNzeSfTYnmxfAd8s/WhKO8hsEWNWCFrsUb85mbKJ07 fL3ikbSQIjUmxOfekJg3KfajMcGzoHlkny6gj7AIFBAowCgALuH2wIcqJT4R/lGdpXWrEjPTX4lR FVLaEHlhI+baUxa3yAqbZGWtdjm8Z+kEFMb56VzIEsMyHebvkxc3wCNXnl/LUQNTh+tb+3EULcGj EPbhi/zADv4BJtx2Nl0FfJDgpQslFizP6Jna+0OPOYf8tidFnM9f/O1G8lVfHW/DdtA5XQsyBrgk GR0gzgDFcFWY/N2kSiMkg2jBYA4bTIBwwvnWZlerNA0qLYL+EJFBwAHUkKhqEMrhC/0jSOLyCaGG y2NEmhEIJsgxAohBjhFkskJOErWuE6ix58Md3yNqcLJhTfcI8jKE5rE2NCY8J8JlAL3T7oQQRIOk jCgkHTmGnRD2UMVDUKj12Sw0l9/Vkx66M2J3eOT+kMTiG+nD/uSo8GeBGpNijsPtNjg+D8nJA6gx guf7mXyA2/+nNwjIMDBkuEXhWMbgLI+jBqL8GGXY18XZEEVoK1DgQqYA2JvHC9SABVzfI28vq3s7 KTN1QRTwgtKGIMNtaQvSFSqKmqRFTdrmfuKnOANZKeg89jkPXDDa+yvbJCXN2soOqKdwCjRUUG3B pQqNmJMV42dgUXbEjNsQFeK1WMkU4XY4HdABoDMU6hALBxdwPLsdn+sEAb74dBzjjXg71vhLq8DR ERtMuXW6FY5wXGAmckwTBYbAugVbxawWHkrVPuhyGuw2s1/GQHv2iQ6sMSCjCOb+U1JyKvh3VmLe WKAGosJhwiCcoS92Ig6YM1DD6lBD0ECsH1AD+Qx5jhGgBmSTuPhFLFP66YF9L1u+mwU1SXTzERQi G4CRBuZGdndQm8G0Dw1RjWPICEYzVfkewFkMBYIL5DTv6KD774j+kPKTxx6Dny1EDKBG6Jz3pkUf Co85AT1VKCbgiwNb/v8OE2cOgMkaTLqhsZViJg5kLwyDBV9cAg0VZmWiryRSk9KTFRaBAgIFiAKM VyDPbVryUova2FnVuCp1ecqCKEVJM8ACYeAADsgdDDia5dUd0NPgJGaLplO59h/KGFWLpBu2jEL4 UDX1FNV3FNUpmrsBEGgEbkycyeLEFE4DHVJFXUd/ZTO8fO0aPX3vk7aKIAOsDewMHeIdRWggsV5a SPLAmu/Qmg3Ytz5dy7ZGHhq57W+GOuieBh3kFwt0AHBA0qCGPDUTKaFccoOxTSZrkkh71HqZHili wWo5VBIQwOwvUyDdXh1iwCFESFRVCuQMsSlhwmCuWfh8D6DG8JBFjpY8MxXPggsE4bIG2TXIGv69 LSRW0EIdEmTw2wddnfB2poyHuFl2EJEmFKgOhMOD9LWC5wCjMAeXsxkTHh88q72i8X+cHfcRDNDB 0UcmxpdOiiHUCJ77DkcNpDoHdgSm8z6XZA1SiJFOjCCjJCi2PCS2fFJ00STM0BRXOj3ys8vH3UU/ TyKTgBpn87sQ2l7QFOCqjJ07dyaJ4+E01VHTsEyc8kZsCuL45IX1kBogZWB2b0pyW9QsK2txGCgI m1gU+1j1SQjICKIbljf1wHWqu7Sxt6ZN1SYZ1sBRlpg+8TKn1yRRy6ra+/LrJAW1sqL67oJKeV2r d9BKn/4wsvs7hPOsQmZoauzsaO+xWmHvYJhCavkRwDHyiXDG99U1RnZGJU1O61YZhzrk6nalSomk 4gARdhdMnUPqG9mAoaGvv7qrt7K7H8HIdd3SXpUeDsDs8hCvoFKDG5VcqWmFeUKuaVJomw1DEqRJ B6DgS94/SAwVfluDA6YeeFshwQhJGZQ7vZxrqHQDffEJkd8vavhIgpt2e1ua2v/20OMw1JA059Ts 27buzXW7kIgJFSx4H5MF8gwnBJkAaH4uJ9hI0n73NlGYpDNRyAO3RO9CTF9IAs3KNC3mxKiJc4Ea iBaH5ZpcmGDIZmaLcwoyMBiYM7AmY0cspgisBGpMic5Dga3kpojPrhx7ByEpbpM+HIRFoIBAAUYB vBFuz8mTJxe8NB+z8ql7JK8lpq0Qp6pq2pFmChIHZA1AhraAzByY+9Uo1YB/g5fjPN/HKlgP2CoA wjSM6PIhmXpYZfBg6gt2GA1hn8XMTZKaVpwOsWWgrHWgog3mcklZvUWuRcwgtwmjQ0wr19Yiq67o rK3uaGrolvQjTouW05b3L2EH3mc2Dpx5RsE5AdTwb1D0nc3R3Cer6ZZU90ob5cp+zDfhoY9IsnDA dG13tcsUdb2SevB6iapepm2UYK5CuVxvhBBEchBdBlKQBcnPBy1K07DCbNM4yecW4IO7YMdpvIQa TJ3Vjp4oX66uAnYNMqCrMelGAzJWATV27dpFbb+nxYbp07EwOpQUVvzmV2NJcwQMdkrfS4984uUE hEujgnkigyIo1Jb++7giboylgDnb8XhoWtyrp/9lyktrJ8cfIft1TCFlFAl/GqgRFnd8fGxJGDQ/ MYj1KyELwjmmpOKoAXM8Rw2IGMgoAlkJ45weue+qsbPp84hoJKDG2f4yhPYXMgXwPY8J2m6fNRsT tpq0+neWvbksNtnQLoUTFCbIUJU06YpbgRr6oha4VCna+/xMHlABVQgKvmFhpEDkB+LB8XFL3kkc MtgMGoAY55BK11lcC8lFW9SCruS5mEm2Af5ag1KNG/N5Mxam1RiBFI118oYaeX1Nf31td2tzHw75 X1v+5uLlPaMEePXpZ0T9sdNQFdgAaiA2EOIDQwRVdb+krq+vXw9RAl5HNF7ECnYqVDV9khqporxH WtWnrOlVNvVKO6UK6LU4RDILAY0EMAJvKwYmGA9q/ByYtnAUAKWXq+A9RZEdsIOT6VxdCk8qCCmY RhYaqu8XNeiyUEPBBczjratu+uXPf0NwSGGPsnczo+ZFJu7La1q3cXtSXOK+T/YfOHTyyWcXVtZ3 c/ULzDEuJ+4FYgeAhd0L7+5fWIPUkFvmilf+5k+Lp0Z+DA0VJIupUYdF4U8y1IAPVVmwuGxCbMk4 cTnKuQYcXD3FnLiKMCP5uHhkej+K2WPHxRdMi/oEGUWY6Q6IzED5XyCI0ESgwAVPgQBTXbFixbNz nwHP2bx6/YqkDKtUB66OQG9FSaO2pBVKKjB8aXF9b0M7fZqTtAE1FVT+4LhADXAbmAiAGhRbh6Po lkEBWYjBlCxaQ1dpjbqcDOuk7Cpt7UdXlU3DGiP/1jUP2dpau+tru2orJU116oZaWW1Vt8mAPv8F 1BjxkPhFweHBPfl24AbRldXp6VIbavqV1X2yBoWyvr+/oadHqTOgPYeibpWmqqevWiKvlijrZNqa XgVkky6ZAg2oTzBW9j1O3q0Ejb41nLJoCBgqGtH9kO3AatdJFY2wa9DsfkzcgIFDoanFPE0wgrAo P99cfiOG/+9v8udB53u8+blFkDUINfAs7LJ1b8S9FBGV9m7WJdf86sCh3F/+/IYX5y1e+W7OuNCZ iN0k7RtRiz9KPwL+ywPBbwE3X9ejvTL0d6FPLJsV98+pEZ/OjPlMFP4EUGNiLMkaQeKy8bFl0P8g vCLgCnuOCB0cNWD+huvvOHHJ2ISCoPjjExKO3pBYMCV675Xjb+L+2AJq/Mu/CKHhhU8BZjig28Rs cQ8++GDwhKAtazctT0r3Gq3g6v2lDbKSBpghtOWtcKmF6KHo6IIqG0AAVskVRxAlUJh+BswHYALZ AREZlOuWOC1jtza9SdHY3lNAIgYkjt7C+u7Sel2vwoOMJeCyHq/RYG6ob22s7W5pVNVU9DdAHlAM oSccwsI8VIFEmKsULIowC4V7WAVAAQ2JqzP2bsXl2Qat6eubFdaL3uZpVuireiQNMkWTTNbY2ytR aiAT8XMHHI42laqip7eqV1ovoSnDm3v7VUbSUOFeTqug6FKoo+AOpwdZtqDaB1bijgk9WWJDG0L5 kMNQqqxT0bxOVdBNATKwC2MHUlTFxkXu3buX7u3fWXwUCJCC9wFSUIZht7e+tuH668ZiVlykD/M6 FZtWRD03b27yyrXPid9GBr8/3/+4XqobNthvvfm3yBsPuYhhJtxxYTQ/ayUVlF1ctXW8sGbUmF+F PvAyUnPcFbVDFPr3kGdWzxAfD4rKDU4oGY98gLGlQdHF5xpqIAaQnL5i8kJj8oEaNyYWj0vM/038 qeuTSqfE7Ltqws14oJS4jKJDhUWggECBMykA/hoVFTX7lllPPfI4+K+ksaOjqEZd26HAnH25lbqq 9t7iGptugL5g8VXN+DlkBJVSr5DrlTK9XmNCanPUM04OvkpfumQNQHG4rSq9sr4TYR19Zc2YlQP+ Wk6kQGQxEehp2GxvaeyormiuLG+tq+7p79VZofhgl+CQwTgkDdhisRkMJguyI7Kj/B4wcu4UBJiw 4SV3OGimbYpg9GmWeFs6ilR1Q/YmqaKmp6eqo6Ohq1Op1WGsWNAY3F9js/UMDDQpVA298vquPoXR NGTH5D8M/HwjQnPcF5zJBm0uPQwcyCiCYqHZl8jG4XJD24M8jGZyuFI2ASn4vE4SRS3mdXJiknSv 7YknHysrqwhYovld/Gvrr0IG1QTQE50MGoeuv+6Gj/Z8DA2VuqVs4q8ux6wlGSvfeSJqOaSmv/zl CWWXzD3kvO2WOyzQYAFSyY5PaVdo+18bhL8VbCEMx3Ga21tV2zRx1r0/m/aXX/72hVHj/gLP20mR BxH9jcwhCPpGdHZ4bGmouBhc+twpY2OQ8KQgPDoX4gag7XpxyfWJVK4TY0bCTy+9YTo+D9ivRtBQ +Z+58Pe/ngI8ng4BEXjvwTTw3VhRUnrr9Ju0ciUEhP66tq6SOmAHEhIi/sIq03gdMLBCDUVoMGh0 drQpwOSrK7rrKnvrq3skPXobfKwYcDAFDrolhRX+kRgwaLerjHaNyTPEuRXxKDgoYQ0ZRa3Qd7X3 QU8llaiG4FvFFkCGrwe2i/rOjr7Gho72VonFzMQauhb1wBk7pIx+pbKlp6etr0+q1QI4cFkIP0zg wGc48ThYb5WD5i6Vql0qk6rVyGBLfUN+Yu6VgBUkLdTaHTqLbcBGESPogbNTjob08YkEW95Bk0UC t1vEhvcpKnrl5RAlkI0EsOZPog4DtQFh4MgiAuyQyBuQeGRwGMlZzRJp9+9//7vhYfJGO/vl61ED N8AELF9seFlJ6U+u/TGmv0Ua+TfTkVVscOWqFc8sikNUyZ8feLi/o1enNd3x23sgjgDkcN8eOxzK zhYycAZ+B2TioeeL+EgPJB03hI64t7ZeHP7X8Gfen5ZY8JuYwnEJFB4eFnVqEibaiClE3N+5U0KT ymiu89j8cCQziSsfK668Pr56bGL1hISymTH7fhx8F3tAJD6f/ZMSzhAocMFSgMfQ2RH9zNgjeMfr 6ZkvPPscsYJBOyL1tF3SIZnWpR2iFLjMyIo2Dqunt1sDs3VjraK+WtZQpWiqUTTWSOT9Bs597E7u 3gmmC9RgMge/AGfB8LZlKiwyfDDSQptiHXaYzRa7HcFoqMPliSNx1OBWCnD5+rq2hrrOqopWudTk s8sz1AD64ErDTmd7f39TVxdKp1RqslLUM73zwASo8PFVzXg6WKTJ6TDabEgsSNci3CK2i4sBVgAc yIdIKic/ZICxovAhseMwoWs1hvY+RZVEXQGNl0xLc4vDimG2qFkf1BOsG3bH4NAw0qrLkPYQDrp2 pxG+uzffMnXlyrdw03C0+rd+VXQvZxQukSFdI9XjXtjEvsNDQFY8VDw1s+f/sXcVgFUcXfcluDul QIsGpxSKe/FShVKnX40CCVKcUmrQUlq8WA0vUMPjCSTB3SUhIYFAPCEuT/P+c+/sbl6C5QUL/DMs m9nRO+ft3jM+pnQqF55QKkYcPrASa6u9eASSfQaRkYaKDeyY78v7wnQY5NLg9RlNJnjXRRfQ9AP1 J+1CLxCUM4YPCsmIhhADrR6c/dFwnF+j8XuwXqPe5KN1Jh/DgvEWU/wbv/vzU636Eib8etgHjAwt EXisEVDUJrQhJslCk9Cx2pZXXnq5SaPGplTeWhBaBxM7Sf8IpUNaIjUl69SJEIxZY9YTLgxGBJ6L xSNGtJMSUVuHAR1AebJWwQOdUGEhPU8DFKSesH0H1BsuWkQgPkzSZvBCFHEpmpsiWKzolTp/Lliw xsnjQdfCE8XnLNoagjXQNxV8NSLoytULYVdwxSQmggU01kDiEJ3KqF6UIf7DiQXADV40ro9FcFgs zkPqsLCE8GTZaOA4IzY+FFOkMGYeGX86KgEj5zj49Qg6o+KvX+VtUnDAIXrrhPwoJh3YBBJJz0ga 9ukHrw95lZNC3vfEQKqcS7Q4UEqDPpO4jnwsWOmOEQywBi5eem/hJfk01w2lEmWnDUbsNIhLvyfi o6cR5MMpgQvx+MPyDVU7/6/1ZLfG03Bu+M6Gk3Zhx0LU57VdOwqJBbsdQhLcsbNikymHMPiC9SYt xu9sN26T00uT3x3xOV5VmpkmjURAIqAioIyGc58SFCY+fFLkXPGeOHHigF59fvpu1ub/Nnl5ee3Y tt0Nczbd3D08PFxd3Tf9t33J4t+XL1275OfVy5asXbp4zbIldC1ftnLtmo07drghyvbtW908tru6 b3PzcHXzcHd393QTfzxh3F1dt7u57fDwcIPZsWMH0oSB1d3d1d1juxtiuW+DBY8Uws3jr43/LV3y 26+/rES+vyxf9dfGLW6u3vB0d9uBvNw9PVw9vf7bvv2X1WuXrVz965p1S1esWr1hwxZKmOO7u3p6 IHtKbZub63ZEw4O7m7urhyek4KLBmxw9PTwoPSUwhXGnUnPwHW6uW11d/1v756/r1i9fu2Hp2o2L ca3ZsHDdhkXrNiz9+5+1rm5bkaJSEOTg7urt7fnvfxu/nfFlz+e7fvnlF4AYQy7KCgv1h7i7v8QN mCogWhzEF6TLWaNTQwP/BBvyIVPE02AI7OWCcXxu6MGbfnG7RUA8MCK9M5ickIXDunivSm7mRMSn lW/avenQuS3GbW4y3rXFNP+mn6NWv7uQkEWOGBN3N5m8l1oc2Ed3vD+60VpO2NVh4vauzkt0T7TZ c+wCfw08bdBueGQEicBjiwANGlNdEaqEFA1X/5W6/6Wgi78sWTph0sThLs6jxowe89lYl1FjcI0a PRbX8BGjXEZ99in8XOjx0+EjR450GTVqzMjhzs4jXEa7jHFxoeDOo4aPcB4+YvRIl9GjnEe5IBCF cxkJq/PIYaNchsMZjwjMZrSLy2hnZ2cOhRSRlvOoUaPg+OmnI0YMHzV61DjEpgRcRo8YMWLMaBdK B+FdnEeMGj189OhPRo0ZNnosro+cRw1DuqPHUL4UYvioEcNHjxwBy0iXEZAE7vgPQcaMHI3TyUc5 U77whrTIlwN/SqnCA8Vydhk90nkMJHUeMXLEpy6jhju7DBvh8gmukaOGOY/+FNdIl09HOg8bNZqi iMJAzhHIatSYCRMm/PLLL2FhYdQPhtr43RhW8nkSUNifmxYKZaBhZ6bthRFcNJqIF3DhmX5kmqhA h26JugJtOoL+QNztMII1KL1sbB2DthXFxyuEFwrDJX9u2VGmQZf2H/7Y9rN/sB1u3fEB2DUd/UI5 Gpt3vn2Ij+guw6J1sAbvK4Jd2f1aT/FuM25z2xFLSzbpMXXOzxgXI46l1pQ0EgGJgIIAjyDwAa/c xU2sgS+Ee4xEzwMe4UCqADoBHxBXT0k/8B4gZOGOJu7roL4nbZiAGQg1WOgiioQub6G7KAcaSkB6 rMU0Cz0jPeoVItKyMUJI4SDmHcFF1Ks5kth6nSKT7uMLelnRYJSrSA42vjhfOCk+sPEDZy5u8MGU YJApW1gudJJp/f8ciAsrKJaTEpVSstKlZZpTDO4aokd1R9+CVO+V5ESBctImGxcTLIHNhFF0SM6O hAOVn+DiYqJFwoGpb0pAZKW90mkIiY5eZOEpZj4MUqAXBgasYUa3pAXLIZU0kaLFuNndv2Tttk/2 GE773zqvb+q8sYXLhpYufxaS6xnnP+n8Puc/m7qsb+qy5lnnVS0+WFCj79gSzfqN+34+Rr5QGu5p FFiKosq7REAikIMAlAAplJuZ23jdLHheN9Lx0CncCaLWivOGuSfPQk7be65kb1MMeNkYkhcuXF2H sya5pvBtwhZ2a07Jbii+4kAhBNkR39ll1MQREXRBmClpwsK8fjb46viv5jbv+kqNlj2rNO1etZBd VZp0g0iVGnet2rxbtWbdGrTtM2LqD3tPXcRwGAgRtR1Gxi5IZGCJgETgrhAgvlCq+qRGYmJikNzd dtHclUS3jKxRA0JAVHTvpKTQCX3CaKVQHeTfOyBgy7AaehqtFBKLaCFCGGFBexh7weAxlxGy5nKS DxIBicB9RAAaQyiQrKysli1bYvndfczsLpKm8R02EBgG1latWl25cgXuMMIFjve1rSQEeGzuAA01 BIGeAFAo4MJzF2SBO05P0RiEfntbI8S1dZF2iYBE4H4ioKnZ6dOn63S6OXNoqUJhM7YNDcFxmzZt grTvv/8+RIXewx16TytLYZO/sMmjNSc1ti2crIHGhTZCB3LAIy7QRy4jWSMXHPJBIvCAEEhMTKxW rZqDg0PNmjWxju8B5WpPNoIRNNmcnJwcHR1LliwZHh4uWEMkJokjn6AKktVYA7FsYcxnIvc7GAgB HCGYQiOHAu30cr8llelLBP6/ICAUBe4zZ86EBkbtvXjx4t9//31hK79QcUIq2P/9918QXNGiRcuW LTt06FDhrnXUF0LtV9jwhDwaXwAuDbrCJif4QpAF7jdpZRQ2caU8EoH/NwigAo+1FVjaB9bw9/cf O3ZsYSu6UHHQbzCQDSscAwICypUrh1MOITkaSkJgdLzItkZ+fjugBCQ14shPlIcSRrQ1tFYGZvnJ 3/eh/BAyU4mALQJCD+NjDA0NBWtgGlWhVSaaxhASlipVCkwn7LhrFWYtmG0xpf1GBACa+PXhBdAE kjcGe4guWltDbEgmJCmEcj5EiGTWEoGHhQC+xJCQELBGVFTUw5Ihn/lqSqN06dJgDdtYwksLYOsl 7RIBiYBEQCJwDxGQrHEPwZRJSQQkAhKBxx4ByRqP/U8sCygRkAhIBO4hApI17iGYMimJgERAIvDY IyBZ47H/iR/JAmrzbmGRRiIgEShMCEjWKEy/hpRFRUCyhoqE/CsRKGwISNYobL+IlIcQsGUNYZe4 SAQkArdHQPtqbh5M7BSds1/0TT4s1UlNCTs0cPg87o/zzFsNpVxKiBHN8bo5wNL14SKgvrU5v9zD lUfmLhEo5AjgkzHj0B51VwWWlg7BwOESuGNhFk7bwXHiFtxNWLBFO/bg8CZaPI39IrD0F458/hsO 81HOCLcY6Iwf7DVtwnFNCI0oOHeBns3Zly6FYb1GXEyscmxQQc90YDHv440KxeZm6zW4dsoQmY2A jk9TzcaRU9hZi440QmGpvHRHKgCQzy0nNwLUVkVxDuQojURAIiAReGQQEFoMe2jgPD4j7ShohKpn R2IDYgeoNdJ4RtKKZAELwB8UAE+cGAu7FZTCrIEQfIE4MsgVZ8dl0fF3mcw1CH/xYoijY9GYqOjH gTWYOJhwcWYdymvEeaoABhilgjDBxrjAqgQJcwi/EwJvcWdsJWswLvImEZAIPEIIKNov868/fy9d vly9BnUvnNq3fs0vPy76PT7V+kq/N9o2a9eu4/P++w6CCM6c2PvNF1P//fu/ps+0adGh07IN6+NS Uzu3btupZeu+z/dq36FLqYo1vHbtnjhxVPtWTh1btVn56yooT+hNHAwKS0gIdhRxjLwWQcST09Ao dJozd1vDnUVVflHygvDMnWhrjB8z+vD+PcGBZ9q2btG2dbPXXnvl3MXL1DyjZpYIaDCZs7jFQSlI 1lBwlH8kAhKBRxYBHI4NXZYcFfx0jdInz5//Z/Om/Tv/nTtr8nsjx19OsDat3zb0zLU/N7qXqlg9 +XrUsvkzt/35x5xZM3q+8MrOkxd0lWps89sddOZMyPFjPTp18fLcefx0cFR0/Bsv9fd323JgV0Cl 8tV8/faKijfuQUHBYI3Y6BjSno86a4A4rJZO7dq4bdt8YK/foFdeCA8LnDZtapv2PTK4rYFmBtpZ CIODvLmw9IrYsAb84J7jRd7SSAQkAhKBQo8A6TFTpiX5cp1qpXZ47oIWs1quL547/cPPpoSnWtu3 7ZWdZb0WnVa+cq2woODX+/XUR15Y8tNXI6d+gc2kqrXovm7bLsS3mjJe6z8wJioeqZmMma/37ZWJ zaZM1mdattuy3UNUvMFOwcGXHByKYFzDQp1fUJvaxTAJlVoIELtZW0MRFaM5JDbfzSZDn57d3Ldv OX5k//ixI9Af5+e3s0KVp1OymA+4UYLSaKmRPeeSrFEIfmkpgkRAImA/AtBjVgx2W657blldpEiR gS+9mJEYNnf29A/GTo4xWKvVaKrTldcVqeA8enJSVPyQXt2tqSG/L/xKV6yUQ4knm/d4O42G07Os 5tSX+70YfTWGx80zh770Uhmco6Er0eqZ9okpmWANjIYjI8EaURGRN29rPGqsAeB6dOmItsaJoweK 6HS4YDb+s4MGM0CkIGAaDqfGhrbvq2QN+99QGUMiIBEoZAhgzNqAem+61XrdlBb2cr/npkx1/mHu 7GGjp1yLz36m7SvhkdmxCTRZyHeH+/wvJ1mN4SsWfjlkxJjfPY4VqdT8fAjaFxaDIeXlF1+7EhJu tWZas9Ne79P/7IGTqfFpiIWqOdQn7lCY588HOuh0tj1UuYgi18PDRElrHfAcKjGuIdoaSsOBA1iM hqzu3bp4e7kdPLDnow/fS7weYzTqMcFMlNfIMwREMfKwhlo2JU31Uf6VCEgEJAKPAgKsuhLiwhYv mm7NjvtlwZcffvzW93N+/MRlQlSStWXb19JZDaLO/PmY8ef2+FkN15b8MPn9sVOuW62Tpi/o3Lmf kWZEGQe++FrkNQxY6K2ZyYP7DYy9HC0mVoEvcGFqFsYBroRdBmtgDhUfzEwZ5yKKXA8PE7p8sQYN iJuf79l9+7YtRw4fHDH8Y9AjhjBQWD1xLF3CaJSBR1t31V/+lQhIBCQCjxICoiPFaozp1r5BCUdd xbLljhwMmDN31sSvvrmapG/Xc3CakdR+elpSj3bdspPSrfrrv8yZMWbqtymYHGXMbuTUYPmKFZg1 1P/FV65di7QaaKrp4AGvRYVHWsyobdNgOy5oS2jZS8EhYI3oyChNpebSorkeHiaGuVkjz/kaJJgI oNfrez/fK8DPf0/A7rFjRqGIYA0UQpQXFjaiQYHSi0sruqQQBSD5RyIgEXi0EGDlZrEaYq3ZKfoU A63qwyoDiz7Tasbyg/RssdrCAhcL1l3AyZxpNWVCMfK4OXhBj4m1CEa9+LSsjT2w6A0r4NC1b9Hn aFFb1lAxgq+qXQuRFs0HaygFMGTpqQDaxVaVNRS+AJswZ0rWUH91+VciIBF4lBEwmzFSTcvQLAY9 qX4M4xqMWPWHv1CItNTCas0SU56UuVAGmjSFSGZc8DRx8wJJIDKvEBRKk6rWqHhT3VvwAlSxaGto Z/nZ6FpGUAv6sPHMzRretuLwskbwIzGicEffHey0jAN4YLk8F5xwzH3JtoYtjNIuEZAIPLIIKG0D qHhS7sQeVBRaK04bh+BOfU7gATIIwCsQyEJDGQZ0yeAobdHugB7FWjZKhjUq99VYsszU1sBFsXOz hnDXfDmEGpTDP8RbflgD4tHWKzcYJso8lCHbGjfAJB0kAhKBRxUBi4F2w+A2AuaIomVAKh4zRYk/ UD3O4jXdcNRnookBfuBxCtq3CpN1saEIEQr1vKDhgX1EmHIERyAVWOCr8cIjyxp5xjWofCgLxjCE BXa0MASDwC7aFARpzkWQqm0NRgsOMBo04lHeJQISAYnAo4AAaTNsFoUWA6lDvjE7QCuyDmTdJrQ/ qz5Uo4204SG6r4xojWRS2wQaEiwDEsGAiElMGcJGVQgm9CIn/Oi2NW7OGoSVyh0EHCiT+6xyUYHN A1sV7hDhJWsoOMg/EgGJwCOFALRZFkY0BHegY17b/5bVHPGJkXxxIRjcQCA07oGWBtYm8B5TxBfG dFoqiLjMLwaedgU+4v2XuNaNmJZs23ENTj634hROhQA9ajGwuWG9BjEslSTbLCzooLOVN6fPyrZ4 nJjqINoaKiZKPrZpSLtEQCIgESjUCAhtht1ZeQE3tBnNH4U2Z+2I+jRcaBkC9UHxsAZGNmChlggW 92GsPFu0MqihQYGhRDkAdCu2guU+K1VDPl6sIbgDcFGLTDE2P7SAVbtzI46fJGvYoCStEgGJwKON AFFGXgNNRw2NmxuhFDmASg2qE8UjkxMXmjUkJAR7bmhzqESIQniHqEKqm52vQV5agEIovBRJIiAR kAg8HghI1ng8fkdZComAREAi8GAQkKzxYHCWuUgEJAISgccDAckaj8fvKEshEZAISAQeDAKSNR4M zjIXiYBEQCLweCAgWePx+B1lKSQCEgGJwINBQLLGg8FZ5iIRkAhIBB4PBCRrPB6/oyyFRKAwICA2 r9AkoVVmhdVANk08qEEhprZAWLNoXoW1HLnkQomEwFw4Al/sCoL7jYXNFTMfD0hZJI57YGCgg4ND TEyMcMlH7PwGEXJqBbnL9LXocr1Gfn8AGU4i8GAR0D55I52aSQbqF19uoTKQSuhSFlBZ5wUJb9Sr Ihi8RMg894dVqDxi3PgIsYXMBgPWfFu13yJPAe2VX0RHLPymly9fdnR0vHLlCtK3N51bhddE1eTU uPvGMubTBXmJkJI18omYDCYRePAIQGUlJiZ+8sknddnUL3wGcjVo0KBevXp16tR5mg0scHn22We7 dOnSqVOn5557Dpb27ds3bdoUXjCIgvBaUWC3fdTcH4xF5H7jHUWBI0rRrl27559/HkXo0KED7E2a NIFX7dq1hcx5ypJ/mQERAotEatasqWGY/xTuGLJWrVoIA+H9/Pzw6tqSe8HeZMkaBcNNxpIIPBgE RJ0W9U98+H369HF1dU1LS9PqjQ9GhnzmIqTCXViwM8Zff/0F1bp69WqRAiR/6623PvroowMHDkB3 IZimfxBA1JbzmdcDCxYRETFv3jyww6lTpyAhKur4LXr37j1z5ky4CDFEKUSp7RVM/L4aFAVL5PaZ Qubjx48PGzasVKlSS5YsQWDRXLp9rNv4ar+abGvcBiXpJRF4iAhcvXq1RIkSgwcP1r7WhyjM7bO+ UcLU1NTOnTuvXLkyIyOjUaNG7777rlCMN4a8fcoP0Reinj9/Hs2N/fv3x8XFYauoX3/9VZMHvjDa Y8EsWn+XSOruE8wjBjgaZv369ah7/Pzzz3l87X3UxJOsYS90MrxE4AEggC904MCB6BLBV4/shHrR PtsHIEA+s4B4Woe5Xq8X0gqX8PDwnj17fv3112hlQHKwhiCOfKb8YIJBsJsa5C7K4uPj8+KLL6KT cO7cuQgpigaLKAssWVk4NfyujGgCIKm7SiV35DypoYnUsGHDu9wgUUtTskZusOWTRKBQIIAP3MnJ 6b///oM02tdaKCS7mRBQsHkYQWjX6dOnt2nTBn07mq9WFlg0c7MkH74bxIMQ4Gs091q1aqUVQUiG ImsthQLICnxE8UVcAZfgqQKkdpsoQki0+Jo3b7506dLbhLyjlwAEwSRr3BErGUAi8OARwEBG48aN ExIStDqt9s3eL2GgI8WV81fLSpv0q1i0arEiHgckCdlDE3XdunXQt/CECwwC464lenuLKosIhXyV S7jbpKJ62TjdPmU1KQrFcmk3m0cBAks7Y8YMNJqUwDeAw5HpTCJcEAG2HEFgowchIWV3o9EIVxDH jQEK5nIjzm+88carr75asNRELC1NyRp3A6OMKxG4TwisWbMGXQoicfG1at/sLXLMq5pydJeqb3Or Lz4liNNSQuIP0qDzhkj14RwhNQW40KlCOMaUzhjCGdkWa+z1xJOnT+3Zt/vQkcOnz5yLjE3I0uME IpyXqiSLuLjWr9/Yo0cPJV+RPk4uouTJ4MwjSo2mtlJgJEt6Fzb+yzLwYUeULLI2Wi2ZScnxR09d yDBQEqSjITGff2TISA08e27v7n1HDp+4FhGDg1bhictkoumyCoBko+zRgMBFB8/BygYWcVofZBEH Lxn57G9yNxuXLF70Qv8BLCbyxaFK1GkIL4YKieOJErSYswx0dJ9aPIRAXigBcOPTxikOXLiIFF3N nV2p8JpTLt9cDzlx7LW5uLh0797d3li24bU3ULKGLSzSLhEoJAgUlDVIJ8LYaCQ8sUbKuashOFCO ThKhhCa3ZQ1ygUrkE+gsOPU668TJ056+O3e4uXp6e+z02+Xp5bPd3Wv3/kOkRs0ms5FkQLJQgn+u 39ixY0c+8JTdKUc+HY81p96IEQFFYAQmT5aGD82zGiw4h1tYoXhxmmqm1ZoWdvmir/+RpAyiMSh2 FtNoNqR6uW719fQ6fPCIl+cuD09fvdmC6PAAS5iNCEuG/lIUsuIS53eL5g+cwRpEW2RAZMbjp88d OHKcec00f96c53v0RFzwlGANpASqIEKgKPhPpJZtoSNjUSTyNVnpYFj45GENLiDfVFk4R04EoSk5 GBFA2HM/KG4F+CNZowCgySgSgUcIgbthjVw6Rymz0EiKUiI3BKIbFCFXceGjRIPOgw5UnygQXKBm EcJkNRtOnjiyfYfbvkOHU9PThJbTG0xXo2JPnw+ymtDcoNRAAIIFVq5aw20Nk8mYSVVyMiaQiGhS IExyciKcoLqhqFFpp6o+HlWxDNlgIERjCUmM9PCrwZ6++1L1rJmRljkLNfzoiNDdft7JCdeF0OFX ozIMRihxJEPHrXJJjQZmJcrLhLxAB0pxqVzc3mEFDyqBAKhUBwWGnjl9ATlkWw0LFswb0K+/hgjI CDIRTEJak5moATcjNTQEa1Ai+A9DyTMm5MJos5Oae04gEVQ85/YVbnd7l6xxtwjK+BKBwo2A/ayB 8pCGwh9V59CjorvgTlrXxrBHNik/VvUIqzAF9CSxhpaKSJb7YSzXY6P8fb0OHjqCaAhiMND0IeQB LUrpEWVY9JlZKSkpicnXDSb9qjWru3Xrlm3MQg8S/BMTk5OT4sEaov/nwoULJ06c0OuNmZloRxj1 WWlIKsuUnZiUgtT0+kyo95S05LiEeAuEgpMlPSoqzNNnr+ihYqVN8sfHhLvv2Bx9LYJKD2GYZFgk S1pGKoRJSUmDO3GZGQIb0ZmmN1szjSYIaTZl6tNTqH3ExUasTH0W1LwZnWDkSGeAL5g/t1fP3mkp mclJ6ZCCWiXUXZWdkZ6anHQdVEmy6SmFpKysyKTExNQ0o8mCpCCJ+pvAk34L3BU8OZL6e2jhYCHD IYX1nt0la9wzKGVCEoFCiUCBWAMlIbWj6hzSRYodlJGbNaBCufINlacXEUin8sVUwuHVhOgvxrLN xuhrVzx2bL2emAy1D0dKHwb0YbESE2RbstJS9wTs9vLycnPb4e3rtWTZ0h49uoUFB/p4uLq5e3r7 7PTx9jx4YB9U7NFTZz09vT09Pbdt27Fnz55sQ5qfr8fBQ8d8/Pd6+OzCZIC42EhPjx2e3m7evj6H j5xEYwEaPSbmiqenf2o68ZTGGsas1F3eHl4enhcDgw16KjL3Plkioq7t8t+JLNzdPf399mVh2MGa eeLEge1u3qfOhW738Pbw9QwLu+DrsePcybNoCqH4Fy4FeXh6x8clHTp43G+nv9WM9lTmjGlT2z3b 1sPdx9XDd8/BI8han562x8dzt5ert9v2He4+iSnEepGRIe4+Hu6+3ui+Oxd0URCrIDJAaqZmC4Om /CH4HqSRrPEg0ZZ5SQQePAL2soatKlK1E1gDqktR78LOBWFmUdU+uXMEaDa+iGuISqgNojAQ/oqI Z04c9fPxFGPNPCIADSo6YIQ+tBw/fMjT3SMpKQkdQQcP7Z329Rfde3aLvnrZ233HhcCLaVn6sOCL 3l4eEbEJcanpu3b5BwddRAU+IS7eqk/eH+Dj5uUbcjXmSkT02bNnI6+EHj20NzE5PjT8yna3XXHx yZDq2pWLvj57jGYapGCpqK2BFkFqYnyAn/+Oba7ubt4xMXFoDmRkpYMyDh89lJaWcT0hZdfOPRcD gzAycvz43p0Bh/cduRCVmLz/yL6MjOtnTxza4xuQmZKltxh2H9yL4QykfOZ04LEjR62mlMTIS1PG jO34XKfryRmR15POBAVhLuvZo4f3eLqnxkbo05JPnQ3a4elrMqefO3fEz98nPikxJuH65Yho8HEm N2EgqGANgEUy4z+LzpA+uJtkjQeHtcxJIvAwELgb1lDlFfpffeJmCD8Id9xJeymqjPgFF3fuqKyh qDdScZgWioq65drlS+ihSklNF136Ijw1WxAClemsTH9fNCd8Y2NjoyLDjx47+NmkcZ26dIy5dsXf xxNjDcgLI8ZobkTGXUdyx4+fvHDuPKtQjCun+3ttO3cxFLV2tERg9MkYp8AAhCEqIWGHx+6YePRx GcEa3l5+6NAiySmYxWiiej5JaDBGXI308fbz8vLBcElsXOR21y2BFy/ExSXExlz39th1YN9+qynp 9OmD29z8MzFcQWVHkfUpCVG73Dyjr0bFXI/d6uWKMRokfujw8aNHDlkN188f3T1l/NSePQeCRzOp YWUwZSbv9/UJ8PS6Hp8YExtP7SPfXQZ9ZnjopW1btp44cSoDnV9of1HDTeEIkpYeufeP4NUuKil8 tYueyWgBqJD3xEjWuCcwykQkAoUWgbtiDeggTe2QnYz6F1YoImg10rRwhGZj4mDthGf8paCKL9tF YBCKOT46wtfT7dz5QCU1jF/zDCUxlAC9uHvXTh8vb2zEce7sycCgs7Pn/ditR9fI0BBmDZqGZdZn Bez0vRgWDiUMBRsWHEI9XMhVn7Tfzyvw8lVtNNlq0l8OOuPl67bDy2ub5+6468QOsRFXdvruzsig rjfEYy4j8Sxm7mezWKOj4r29fS9dCo6MCvfwcj14+MCFC0GnT124cDaYBz5Szp8/uufAacEaRqIO PZhs/05/bzcvz51e7n6+6GlD4mfOBqInzWpOvnBi75dffNOrz2sZRASMjDlzv6+3j5vb+QtBp84F 4h4UFJyemgEcQ0PCfHx2url6RURGgyYwmk+FY7C4AxCPwEBcEFthBPhrF+VABl7aJVzu9i5Z424R lPElAoUbAVvWEJLyAMIthRZalPUT9A0tcFCX1JHygS9TgxId3UeK7qLBDnogX0QWiooUstFsyaJH Gr7FlCGaRYpxDYxrB+z0dvfwCg2jbb2FsqPh7CxT2OVrYASwxoljx0lUWg1hXLF2ZeeunRIiru7y ck/Xm5ARxj52eXtdCo/IsFhPnTh59vhJSgQjypasPf4+Z0PCwA0czBoeeH6Pr/v15NjkzExXn32J KUQN0RGXPd18KTgkJpkpl8tXQq5cCaNncECmAY2dS6FBySnxrm5bY2OjUXZkgYJaDFDX6WfPgjVO Inc8cI+cAX4J1yK83NzBG5ciIgRrnDxx9sD+vVZLSuDZQ599Nr5Hr/6QChehZDbt8nI7feIwHDC/ Fw5iTm9GGjFXVqZ5l2/ALt+dmfo0bl9wFOIMYMhtDYyw48JwO+FL+5ZQkkgEYWBTDFbHiADkJlqA wgfYErxsEBe/ch53zVfzEgFGjhyJmQnCXrC7lrJcr1EwAGUsicB9RcBe1iDdAgWKxRAwJsxMRV1e 6BO6Q91hwBotAm0BMq+hwHo19PUo80jp+AiEBeGQQmYdCcVqsWaZM01QjyLBbFNWWjLGi728d6FK H3IxOOhC4MmTp7FEAo5Qpxj49vb02rt3b8S18PPnz46fPAnjGldDg9FtlJZFPVToxdrr73c6MBAZ nD5+Ypen55VLoedPn8pMSfT18Qq6GgHWoPwt1svnzwZ4u6alJ4ZFXN3mtiswODwpMSEmIjzAb296 Go1qQGeyxCY0K3bu9MH+rpcuhe323+O6fUfC9ZgsfeqevX4YlD93/uLlK5Enjp9B+yDbmHLi+KH9 R04AHVbSWLXBxbZY9mDhie/OVDhASLP19KnzxBoYf4+8NGHc+LbtOpy/GBR2Nfz0mUAQVvDFc15e W/YfCLgaEX7q9FkUPzU1fd++A8eOno6KvL4/4ICvpwfma4GaxFgR8wGjSRCDBHiyAfgavXY8tzjD QIWhrIkOOQykoMYZsYZCEoCFDegAW35ppEAsovKICGD7CDtCwjg7O2PXdCWJAv3RkpWsUSD8ZCSJ wP1FwF7WgKKDbqGKq1jBjb4RXkNHjwoHkFIiciEaYRutTTAauEpM80YV9QRH6FRUm1FTptVqpMpY odE2fXjGRCm9OTDokp9fgLurG8a+t293RaMBgx3wMmWlY9cpTFty3bHNx8frp7lzunbvlhQbCy2K SVZICmHQQ3X5WoQec15TUwK8PDANyc/HG6sofHcGXLwWiR4qPfJDpT0pwcd1M5Lfe/CAl2+Ah+fO jLT0qMhr6EjC3FgEyKaBDVyYO5tx4tTxgIAADw8vNDSioyKow8pqzMhMOX786PYdHl7efug1SqQF HcYjh/cfPn6KVoygtcGMiVm4SO1SUODp8xegprFCEH7HT585ceok46D/adb3bdo8i/6ubW6uR45f 4NOZTCEhp3193Ldt3+Tr6xsUjC470+XwMIzF+3j6uW33iqRpwDTLF2lzLxXkRAMJHXEkOS8KEWvt 8aQgzFnTIwplplEkbFSF2FhyQo0RqH1mSbJQEDZCjQsXYRdhYBfVA03PIzjaGl27dlViFuiPlppk jQLhJyNJBO4vAnaxBrQKFC2PUHM9FvVn7pHBWDEpENZLmM8jLAhM+pYvdK3AkbfIIFVJyyKsmGua YjbTwgTqheeuLUFJVGCsyDCRFuTRDFK20PbkLC7wFOUGNYcZueSOVX7YwSnbCHmUOjO6ubivhirc 2RjIpn4w5G/SG3hpBLInD04OrZtsvcGYgYSQJdYSktjshRsseOSuNgiNxC202NtkMWQx33GxzBZ0 ClHDgaYyQdciCjEpFRJCWrMp93QD9QSRgS8DhTvFQusMawwNaIuZ5v80Z8CAfgZzBqiBgtENEpmy wKsUB82jTCwnhNrHEy0JF0lkp1tNqUiH2zWcNVBTVgRSUEwMQLbshrwoR5QUUSEbcz0hSXbFkTxg xG6EWptROIq7LaEIF/z6MMKOtobcUcQWLmmXCDxmCNjLGqRa0T1FGo26NaiHypJpzkj6euas+k1b NW3W4tPhI4MuR0JDYgyCwugTfTb9V6tB5xNhGWhCYNEb9DncM5ODv/t6ZMumjZo+2/GNkdOOhfKC ayRMJAA+oMSFHqP+eNLW3AHCmpJ1Lek6sIbQYBs2/NW+fUehRWmwBUlgJIL1NNFKtt5qTo+/Gtqo fr11f7tRK4OTUDppqE8MlwWdY8gGFrpBuyrpEGEhEVzQ2CSH0I50N5kN6cADFlTUMzJN6IMj1iBD i9DFsI4lJXLwCz39Dp6gYW4uHaLqeVkIuq30mL5FOULPWxYuWNqzT39AZrVmZCcnzZ4+vWnzRvVa PDPk06mBlxOsxgSPjcu7d+t1+GQowQt0WVjMv1q++IcOPfv6HTpDkKGNYDYe3hfwxrtv1nGqV7fO Uz26dJ4/f+H1lHQIioi4QwoqEzcxuLlECSEqlQl3Vf9TMdR9IIWjQFvcRUhBLloseIE1xB6McCyY 0QSQbY2CAShjSQTuKwIFYA1qa0APZ6PPm5StNStx8IAeOocST9RrVq9+Q8eiRd75aBSaEKQgUcM3 xDxbr6aDw5Njv/odGtaEWaUmrJ3LGDq4XwmdDue01mrYXFesypDhk0gHop7Pmgt1YLpUPSboAMoE LqTdoPNMWFjNATjC2jUbenTrCT904Kt6G7QCu4mq/dmYC5W+5Kdvi+h0tZ3ax+hpOw4WjwTiZgsV hLUo9SaRNlUr8gQ+i8Q5E3tRsWCo7UNZWCxgA2PgxSBdkZJTpn2rhKVorNNNGdakKzUrFt/k4Y8Z vVDaoh0jfJEaBs+NSAeupuxFC5f27tPPjASz04YOHFhap3uq/tNPNmnuUOKpoZ9MtJoT/lwwzUFX tHSV+iHxejTVSDB9ptvfvxd11OlKlP3Xa7dRT0vNx7m4ODrodMUcdMV0rZ9tgVLrdI4ly1T0DTig sQbLCbYCzxH/ouwkAhdNU9oaO1B5bTqsKGeKQBDaGhERrCF7qGxhkXaJwGOGgL2sgZoqKRwLel0w q5RGvY1xoY2erNjzhddoLw+r1dvb85e1/4EgSKeY047v2VSpmM5BV7Z0+cYx6VZoWHQOpcWF1ypX 85XeQ9D7nma1uAfs+2XNBnAAEkRtXlFo3CkFO7U1yAmajRiCfcEpvGGg8mhd8cea53v0Eb1YCAEN h74d2taDtofClWnJiHOqUaGYg6NDkeqb/c5AjEwTmj4sJU0Dg6LmkRoreoH0V8LCDx0+AU/0thE1 8YA426hJwB10nDESx6QvdEBZjdGxMVWq11q19m+Ih0YW0oLA2BQLWZvigupUK7XJe3ccRhtAHGgK UEsKyNEqdBIBgSGwwbJ00cIBfbtjrYchOfapik++NuB1A5b/WS3bdh769dd11qzY9Yu/Lg4OKFKm Qc/B8QSv8eqJvWWIE3S64uU3ePlZLWlzvxjnqCtTsnxtD18/4rhsU2pCwrRp08EiJctVCbocDeIA O4AjIKFgDR7doBYV/WTwAuLMxTftnuJdWTgcMOBg2nFRIrzsoVLQkX8kAo8pAvayBjQd6W0oTGOW UODmhNC6lYs917Er2hcYXyZlCwvpJdTo0955dyAU3aB+A4vqyv68aivWXcM/I/5qw6r1urbulW4i HkFg0AdUGVQw7mJ6j9bWEFTBfVaUNSttqDxocyIHqv1brOih6t69JxQ7Uqe+H5IMdkEZ6ENL9N68 uqRO16/vwGIVnmzX+xVkSkFJZVtCLwb5BfifPMNrQ7LT4qMv1Xii9uLlqy+ERsYlpoi+OBzh7ee/ +8SZ0xQDlzn7SnBwVmpiWlqs326vqIQYqOKrUSnx8WjUUO398JFje/YeunYtkoBKCn2qUpFN3v7Y PxElvXw1NjD4MpiF0aO9fWFhu3Xpwnn9e3YEaKnx1+pXe7rbc13TsWkW8IKoCGFOWDV/Ogi4QZsO aJ0NdZlsSktuUqMMmiRwdChZfc2OnYlXz1QvpStW5smzV2lbExAUFZSmb1l//GmBTlfqgw9GgBQS EuMvhFwGQRNLmzCv4Cq2zELzDYEjoiL99+7bs3e/mG2FkZqoyDgsDyG0zOaU5ISLQecEgQJ2rLLc 6ed7+OgRLHfHzySaUcNHfordXRC+wEaQEaLLHqoCYygjSgTuHwJ2soa6oAw6V1RWrelWffSgPm2L U3dTY9+D50khw4s0VdTl0APoUOk18A1TYlStiqWrN2kfA3ZARduY/krP58oU1T1Zt8nOQ0GCZThJ akHkr7BqMKi+bOuadau79eiMnEnhsAtxiUVstKG3Zoa+0qNFxSo1r8Skvvf+YNTM954O45ZS/JaV c4vi2bGiQ5EqzhOmXQ0+WaM8Ku7FdEUr6opUeveDj62muBFDB1IfT5FSOgdHl7GfobGQmpJZs2Kl Lm1aVnuiNMLqKlc6FhZXrkpz508nWY1xbw3s5OBQCq46h4r+Pn7GuJA61Ytt9fZC++vvza46XZn6 TbteT6dWFal0Lq9Y3718/qIXn+9F3GJOG9yzKxoRTg0a7jp4GJBC+6Ovb/WCr0tVfuJUWGynDh1B guiFQstj1eIf1q741aFIjb88D54+uqt0Ud2or2ajJUIcQIoc5A72tCbFpdSq2rBd87ZWfdyCuV/q SlQMjU4BQ5kyoouVrfzXFg8MqW/+8xdKtChKWqJmg2bh12nXyO6dBzxVrW4WxlGslgWzv8Gvdi3i kslqXL/hH2rkUNunSJ367SKiqM8OfYLOY0d06tJe/AiidMovQr+r+quR/ZZGssYtoZEeEoFCgIBd rIGvHqPEpO2gkqFQoJay0S+VpE+68u6rL5RwgAYpO/TTSclUOUY74Oqsbz7VFS3vsfcsxj5mfj7W oXi11W6Hqe2ALpqMa28P6uFYpJjOscIHI77GQrUME9SOokXtAIbV05p1K7v17ERKCx1NiExZgD6o PZJtTr580qOsTvfJqClQv6ePeRVz1L363ngWP2b8+32rlqu8a8/5lZt2z1r4W1JU4A9fuEBnfv7j LzsCjp+5ELh+2bfldLpZs2Zdi0v+Zsa3UJOeOwOSkjMa1qoLovxx7swFvy/qOWRwWIq+Uo22n0+c bYwNdKqqe+mFwZcjjOMm/+ju5mNNu1aros47wHvP8dO64hUrVmkYHk2NDi4q6XMYMbts2byFA7r3 wF4i2dnp2Ukxnwx6GYwEqnpv5Di0xaz6iHWLZxatWDss3pQYHlK3Ajr+irz51jtWc+Jvi35ycHhi k/exP1cvKeKo27LnKFgDhcWICRZO6k2p1E1ntr75yqftm3eyZlz5fenXRavVOReVnm1Oyky+UrV2 I2x+khh+Gij1GTjw2MVw910BxStUfefTyalG6+uvftj+mS5iEGPpnBl1qxa/En429EqgzqF4r74D L14L2bHTt2jJBu9/9DVKhGGaT10+6dGnG/8sKBnkxpsgWlOwI8idjWSNO2MkQ0gEHh4CdrIG2hFo KvDXj5ol9SehPo9mBVWPd27eWKdyWUeH4iO/WIBaLKikZd1yumLFm7bt+PpL/aqUoep3xz7vglKo DwqD1KZUH7f1VaqUQa1+9KSfhCJlJWo3HGvXru5ObQ2FNYiYoKKovYMKfsrID17DyLuuWIWBr77R u2uzUkV0juUbnQ7BhNW0+V+OBtV16NL/THAKTZ+1RIUFBehKVd7sdyqNKEf/Tr92lR108xbM/2X1 2pnfTXd01I2b/HlCmqlStbrvvz8C7SacoGG2pl/PSipdrfln43+wZiQ883QFtF9Gj52ONYIEUGKY U41i07+aUL1ufYey9U8HpVIDgIbASccSinSRRl02f+6Ant0ITKIRyG/x3Lq+Vo1KYN4xk75ED9Wv c6c7lHnyynWE1R/292jYpDmtXjHHr1r6o4Nj1b/dDxza71GymG7eb2tpB0ZOmVdZZmLHEktaSu3a 7Z9p8bzVGLNs0ZcO5WsGxYNZ9VkZsRWq1PF0D9iy8ie0bt58/5M//tmBtfZodLR8tkd6pvWVF4c+ 06IT+hIxd27NzwtqFNclRJ7ZvGUNBuDffH/Eqr/WARkHXY2Wz7yEfeIxH2y488edu7VXf0KUS7KG Cob8KxF4LBCwlzVQaG05A+wGE5YPQDmjzqy3GlPNURfrPlG5afdBMdnWv/9cgy73IqVKPNmgoVPD +k716lO/jUOpAyfPIQLpSgxDZCfEx1564qmmbbsOyjDRsAicC2DWrV3dozuxBg01I21WxERqmdHJ 0RdqPlERfSl1GrR4ur5TE6fqT9es5KCr9vkXP9MqOEOSy5jhkNJBV/23XzZYrdEnjrmii2a95wFo XajeD17qXl6nG/T64JffevPNt18cPvLdjZv+Tci0VqrZfMpXCzkji8UYnZh8rUrtlmMnz8ZawKTw c51at9LpShap8NTxc8HW9IhGNYtSz49jiTc+nII2Do3HEGVY08y0+QgEpudsy+IFc/v36UHjQlhg Am8qSRLGWSo+2aR99xethtgVi2YWL1cnLA6LKWjCsxgasVrils//0qF41fVuu4ODDhd30D3l1AQD LEgZqdJYD5qFlqRN69diJtvA14ZbMyJ/X/KtQ+XaF2LBk8aM5ISKlet5efr/8uNEdM4926HboPed X3/z1Q/+9853sxZjVcqgV99v3boLVrMgtZXzF1UvorsefXruvC9Aw6079nrzg3dfGjLkg4++mPnd asibYdB/NmEUt/sIPqKMXKyBxzsb2da4M0YyhETg4SFgH2tAcfCqbciLPSpIq0HHJUW+99aLmUYD KShDwms92jVq2y3GZO3SqX+Vck9cuhYrGhFQk4f3uhd31L31/nsR8Wlvvz0sC/VXcI3V1Knn4HpN u5PytN9AAJj1a1Y/3w2sgREVkgoXutKoW8YS9/OsyejkWf3XdjAKtLU+G9XwzKa1Gz1ZqnpGHPaS vQb9ejo05Okaz9YqXz8x8typMzt1JUps3XuCBvtNpglDB9UsqcPmV1yKtAxzXFxyQnyapewTLUdN nIM0+QTvpKy0GPTzjJrwpdWQlhJ5EQT69z+bHRyqDXOZYkgIqV9Ft93dbdjYqWjkjJ3wFRoakBDL xoWoogigErRo+vTtiWlTGYkxH7zziQELLLKTsEVVj4FDG7Xqac2IXrFgRsly9c5doUXtaOIp4+iW mFXLvsPEqk279lutyaNHDAE/Pd/n5euJOLOJJw9kmzw3r0dnF3qxDp4Kt5qv/zr3C13ZyuejkjH0 kxwVWbrc01tdd54+4AaW/3npb+B0Xl1ojI4zoB312sAhzz3Tho81sS6dvahGqbLRUecC9u5wLFJi 6S+rMMsLwiCjmBhRKDPaGl17dFR+SfoVbC4ikTsbyRp3xkiGkAg8PATsZg2aI0S7TwiNh4VthqRr NSsXK1au3BdfzxjQqQ16OV57+22v/SccdFXGjPoWKgVLm2mOKfXHRPft2axcpcqHTgRXqvRUxQrV pn0+pV//FzAS/dpbzggiJkrZBQYlTKyxshexhrJ9osIaWOWXHNb86fIVn3gqHtVtCooptplYabhm wbwqOt3vPy9/tm27tn06L12zom6NllWK1zCmxZ69sF9X1LFV994zZi95+42hRzy3oYeqiGOJcV98 OfmbKboSuo2b/o5LyapSq82YyfNQOu5NStKnRFes9uTYidPSr0c+WaHIuDHDfpq/yKFo9dETvs1O vla3iuM2bKtusQ554x2o9JFjJkIzQx6oR14kQqKh22ruwkX9+vVBvxlYo3qF6hXLVPrm87H9+vZ0 KFJ1wKAPQR9/zJ9ZrGSt0JhsNFhE7xZpalPUsvmfo7n0j5c/mi+WrOiBfXthWUexoqXfevO9iRMn tn2uNXrh8Pj7Rg+iQktKgNtGnaPjgFffWDZv/hPlKzkUreLqsycxJriFU7UiDsWHvPW/73+Y8Wy7 1hVrOGUarINfeqVCsSI403zBvIXFdSWqlqsWHhGSnBZTr05dB53jG+8OmTF79nNtB1R/okV6FvHg 6LHOnbt2IGBgkJ3tJVlDwCLvEoFHGQH7WAMlhRLgyjyOsSAdAT2dGb/6t/kVK1fQORQtWbzU0Lff SUlN+NR5ZJGStQ6fuGowQLOixooTV3FLcvfYiPmfP8xa9suyXyuWRb8QTNFBb3wYk0D6rABGxFq/ dgW3NUgVIxuSC4JmG8/tofrzDwuXY02c6E2ihdiYwhV/qUmtyt3ad/lu5o+6okWo+0hX6vff1iKe yZgx+7tvodt1DmX7v/I2Bu63rP+jQvnSuiJFcbXu0hWbHGKddY1azSZOmQXlj00XMXRiSI2pW89p +hffmFJjhw55wbEo+uaK16jb8sTp4MzY8DrVymz19qXxd3PW+28P0TkWm/7DPNKmNFeVhAVG+LNw 0eJ+/fqhWwwHDq5cuqxqmfJYqIeG0svvjIhLwbhCyh8LfihX4enQSH2KCbnS3lOskxP+XrsQ2W3x 9qe4xkR0Sa34ZWmFchWLFSkOQZBGhWr1zlyMpSYKGTSbMseNGgEvDKh/9MEwlB0HBWIh5JVLp7t1 6FTUsQQyLV21+rLV/2UarQlXrzSvXQ0DQxVKlWnW8Nny5WuGxyYgpfBLQd07PUepOziWK1v7l+V/ A2EUaqTzsB49u7BgQjybu2QN8QvIu0TgUUbAbtaAfuPlYKSu8Z/GJtKtFszSMaekZqam0hJj1ku0 TwePX0AxGsEY0DNYnEErOciB45qzkpOTM7MMtPANKUHn5KsDIxfcJAbaGmtX0LgGBpWJLegvWY0Z GHBHD1K6hSYUQWw0ZqDZeA8NmnRKOoxnAmNMmc5yErnTmjsjtsxNzqLJq9QWoIXwBhzAlJxBm/3R Gj5yJ5nxiE4giwWp0QFOzAAgkUx078ckYzAcAxDYEAodZRiHYDSw8BBoIBEGgMsM8QlEYo2FP/em mbcUj2IZTanJaclptAKfOqOwshK7oANBXg6DrKnsQBa5m5IQh9CmuBgTwTITzE+wYK/5WlXLo6GB hfsvDP5k3Lgv1q/fiOm4OIIKu1plp6ca0lE0SoOSQlxyN2MTeCzWSDOKubsATo8TpdLjYgguZM3j WMjGimXv2emZWUkpGenADJdIZ/jwYbRegzBCIOX3yHmkjO5gZA/VHQCS3hKBh4qAvayhKAPILGwY caaxCZ5BChfWHlBkPARLKowmMtHqbKFjMfiLRwqGu1hKjBg8mxf7rwo9UxA41q1d2b17V0qYq7us PJEcqWuMicPGGpXTZ6ZgCWicQ0iCiGSjcRCiL0RkVUryYyUFeIZGc0g+6kcSBUcUXDy11UR7gNBK BZEq5YtU8IepEgTJmlOJR7HyGLggJHJcPG9e/969EJFyArBMgSIjTkRxURNHfgiGxEFYNP8LvUmc OIKBxdJpKxWkYEjZ+tf6Ps8PwAqU5m37JoJMSBLaa4Vi069ActMj5aj+jvx7IQQlSASEpPgB8MJL ARlFA0XSuhM44hLZu7iMxG9BdorMZVe98JwfI1kjPyjJMBKBh4WA/awhlKOiQ1T9zCO77IMtOKBt 0mlrVmgX1kXYI9YE3SuUCrcrWHPBBTqFGgV8HhMQYMVsLxKUK2beduvRnRLEfzIQQVzwVRWYsAnx hTR8J41HYaADiWKgh6HDDRhrRgOB99rAjleUJPQzKVVSg2gYoMEByfV6LBYkhZ/FZ/yRJqYAJAUX kZoFsCvRWRXDnfNDUAUTzh2PxsXz5wjWYI6jdIRkhBMVhx9FbMFl5A5Hkpm2J+GCYFYbK3P0yeEX AJHQjmEIBe5EAycVAiE4R4MkvAwfAvGW6SwH+QkJ+S8HBJkyIaleKDkHg0hUYaAnZK04WvksPxvW EGKLuEqad/gjWeMOAElvicBDRcBO1oCaUvpLSEuQUfU0fKCGqJZN9XVUW6GlTNnokqLZVhQQSpYO zqCBBahDaBxanU0qVxzhpy7rpqD5N4o6XbP2zy49eiE9Ujj0h3UpdZmQUKz6bNKkAOIirQsrwpBG pjYRa1ouAo7PgztOwYCodKFYYDWoaNpZnXqMqKcKf8iXiJI7rjgvJKbkQITCQSgDBFbkgXjMRPBS LyrIwgXz+vbppYZhP0peGBKVLyGOZifB6QIbgy5YIgz3G0yJTBZcIjA4T3gTMdHFxFlg5Xwm7YgF ES101AcuVZgcsQhJ4lMqBS4yOYHISylgjqN1lLNLj27dlWCKzCJmfu+SNfKLlAwnEXgYCBSINUjV QD0L/YY7GfyB+oeKxaAAd+xwjRfnQfBsKygYKBDU1SkAhUW9F8Fo7yMz7SKCij2rP07KjptgB8uq dRs6K6zBffSkxEivotKu1NuhpVWtSMnDU9WHEIYkEa6onFP9nMQVOlaQI+lNRCJVD52LY6GoBUGD y/ij0gpSwBMnTdFhSArFUdigmIlHKH0OyreckPMXLujdt4+SQk5MTotuSBZZQhbgDzs9AjpKSvgA YG4EYQklgU89SzjsRKV3CkRTZMF1NGGYbnS4CbEm/aekMSNBlIlSFMmyD5xROoYIAbVSKblSEBsj WcMGDGmVCDyGCNjPGtAr0PykVaCQ0fAgpSE0DLQINsI1YYSV3Elr6bHfCKkkOniCwEs1GxMRH5Nf +RH1duIeJAaNxM0T1l8UMt+GNbDKGohOjEYKkjOAGMwa3Bpg1lC0IjUr4EkbLnLWpGexgIJquZAG 48/YMZcaGkgHcamxBJojDsL6O6w3N+uhc+HIFEM8iHjoyMIEJu7pQhQSgG+KJCwTMkGmuJPWFhKq gSi1OYsWPU+swdIKvc0wKOlQLIit+hKwJCQVFP/xBCzpJFgEwt04fdLYbh06NG3ZMTQiAfn+NOsL DIuvWLEKUWiXXWPa78sWLluzEUMymzf8id1R6jVvt/dcGMpITCRyV2Ck1PArUUQtO0V+LggLqd1c XEarpzJxOiI1jkii5sPItkY+QJJBJAIPDQE7WYN1FPQA1bqp64Z0MqksuoyZWRfPHOnRo8NTTVp8 88M8zB+KDzrTqlnD9p27hEXQYXNgjX37PUeMnUKqCe0AY7o5w/Lx0JHYGQ/qCAGwxWs+FUsOXoiQ bV21Dj1U3aHZeMqTpt1Yz1NQ1rQQUm0fse6FAgd9ETNoF+Vuyd7+57oOLVs8Xa+Z356joAzXf/+s Vqn8iFEuIAzEgVb+edGC31f9w7vKmhfNnolZqUsXLoEXmAUycHaUF4tGFhiuxUPns9pnN3bOseEx F2so3hRXNYyywJrjATFGVUmEDwQE9Rl46/Xs1wf23e3lfeLcVWwLtumfdU9XL3Vsr8+T1St5BQQg 1qrlSyqUKrX3dDBYI+zcmcDjR7/86efm3fqjFCxqrrYGGi8ol8gOWJGBeOISj6pUeGLW6MnOtgJT feAmZVKi5/ojWSMXHPJBIlDIECgAa9h8+6whuakg9k0/cMDvpUEDT4WFB12KtCZldHi65pKfZ074 clKnHm+kZVhPntyPRQ8r1m4gzWOhmTlvvvlh3YbPYms+zOmB+rZJOd8wQQTe87ZLz87QbKTs4IIM cGelCobiHht0jimOlAvnxMqQBnNhjGbqniH2yrbO+nLyH0vnnb8QHBmbEBp0vlwR3W639d07tpjy /ex4i3XpynUlylY8eCoQWnTLX5uerlD2rL9HnWplPfYexQZRRKNkWOuqxMEyITjYlmVQ3UVQEoav +Qvn9e6LmbdkhBunozQu4EK44Q/fkBzywl080+m31IpJT02N+3H2PH2aYVC/Xj7btuDwcYT5+suv /lv/u9UQNee78T8uXXQx5jp2kTp58qLgwWycP2s1rvprE9Y2YmYwerkU+RlGCI82IZz4QrsD8uTI x9mjVMKfnlycx2LXetWdCowU+BKys89tb5I1bguP9JQIPGQECsAa0CWsXCE5dIXoM7H+ue7vAwcP 79u/68XXXgiNSUCPTcaV6LZ1ahuMMXEZ0bXrtY2JzW7SpNHy3xaTriMNaJo389suXXp36/sqXLAO gd3sR4M1GPa8BWvAqtRooavwwHJCRLCDoutUd44EdwSHvwis1xvSfvxxTmxs/LzZM2bNnJ6K7UOs 1l2+Oz95d5DVHHH2gGuv/i8HRqTripTdeyYQuyJC7BlTv92+erVVH/XzrKnfLvhNnKBBCQp64GxY YSIXtfaeWwYOLASwLFgwr08fHtPP0cqIBS0NOmDMEFpJk34CLhrnRcMceEKwtNDQ859+MhwLL76d PLFy6ZIVylc/HxTeomVrT9d/reao3+ZPfevj/81ZuR57m+Bq0qrTNfxYVtOs2TN1DsUWLPsDPyc3 lzgjpMpS2zQ0bFhDEZ0FoNxxkbmxraFRBv8mItTt7pI1boeO9JMIPGwECsAaQuWy4EJZQV1Y5v60 wNd317lzx9q2a4U9tMeMnnQ04ECdJ6riMIqE1Ignn6y1Y7s31iBjwbVD2ad37jnj67azaqlyx44c b9O+U3j8dVR2oQaVdXb2Y8Izb7sinqJwVPUkRIXWYjXOmpATV93VBwqA/XIzRwz/OCLyyob16+rX r68rUnr939tnfD93tPMwa3Z48JFttSpXW7R4ra54OV2JUnXbtQ+Jiuv4TKeAzdut5ph5sye94zwF +5ODSm5mkD4bG+xuDLZgwYI+fTCukccI4SkFKtZNUuAAUPbQ22ALuqN5gJabCfcPP3T5eubckWPH um77y5p5bcVPX3z33Xffzl/+v9HTko3WIW+/NXvOdziXER1Ta9b826hBCzoBnTiIjZqX+Mt3IYzi b/Mnx51n3na38bLbKlnDbshkBInAA0SgYKzB+ktIKSqZSq8FH6KtDw+LLF+matDZwFbPNMs0J6dm xDWsV3Pblq11G7WJSbPO+21T2y4v9+jav1vbTs0aNsLeHV/N/gkjAuingl4qmFm7dq0YgdUUzq3T If0m1KAShnIV+ha6EwMrpPgRYt2GLZ27v/DfFncXsIY16sLBbX06dZj9/fz3XD5Dm+LlD4dNnzX7 87FTvf/515oVPW/+N5NnLcbiOqXCfevsb+NzC9bIHUOIbntXOFHobUtGeuqlkIvRURHHjx2Ji0to 1Kzdrys2LFq8sHvnVpb40PZOtTxd3XBSYY8X38K+WP8b9uGsOd9t3PpvTGLi3xu3N27YiiYXU7Ov 4EayRsGxkzElAo8CAvayhlKmHL2isEbYpfDEhKT9+3dlZab889emGtWejouMrV6tCg5I3fD36mZN Gx46dAhnUkQmWlb87fVc54G0wgFD0anpvXv3TTVasOkHHHJStRM6e1kjV/KUq8IaF4POJqckBAQE YIbqhMlfDx787rlz5yqVLxF3NXD0sHemTHBeunxJ/8Fvx2Za3/549Kw5CxbN//H5zm0ykuOcnJy2 +eyjfUtyJW3fw12xRrZZHP99YP/eWjVrHDt6uGgRBwfH4p17vZqYajKnxQ0Z0BkTpZw//RiDP9io pHO3XrriZeq3bh+RnDhq1Ee0b1aRcjvcdqO5Z8satvZ8FkayRj6BksEkAo8oAnfNGqjiQt9bOrTr uHXztrffGozd7EqVKPvPxs1wDvDfhd3tylUsdeb0cawPHzthus6xXNHyNXcfPEsVZJM1NTGpa9fu 6I5H/R76FkvqCgbjPWGNtORYRwfdxeDz9erVw56KFavUPnX6AiYmLZ4/G0q19TNNExKvpWYlt+/W W1e8cvOWna4nYtet1JcHPo8ijxg5BkXAVWDiQ8HvijXUFoeJtryidgfWi6em4XwMGtTBzoQ4mAkb M9J8YXRAETdYk/UmjM6gb9CQkWBOS0QLAxuC2coPypCsUbAXUsaSCDzGCBSQNXIQUVjDgEMjoHGy DUYDFsHRej56pK4grEzW44IN7JKUKXrerQbukMIqNEx7QihQBpRbgSvq94A1aFjfgJlcLKZVb7Bk wEolQjNEb8hI5TP7MF3YgrUnGThEm8YORJlMOOQONrFTRw4w9tvyxRq3SBZTjrOy0NYhvqAV3wCV D8PFEkoSky44ijlTJC2gxs/B7TuKQsW5C/xthZJtDVs0pF0i8PghcC9YQ1U72FODVmObcOgGqyla dCbsQk1hX1mazATthBhQY6jdKgqNVBYm30KVwaEAxk7WyJ0DZYkOMqqV4+IdcUkMWkCNP2IrJxJQ U7MUnQafOSIq7ll6qs4XUHRKTDF3wxpUBPQ9YZE9ravgdSvkQkKR5CgZPWZaLHSwLSY541dAkRCY ludzIPx4uZsaqlh2/pWsYSdgMrhE4BFD4F6xhpk2DoERu6fSVhaKwiJlRtYsE62wJg1Gc/9p7yPY YRAyGz0j1HUC1iDlXABjB2sgAzUPGyukNAnKE5vB0s4bVBgEhrRGE53USmQnNnUXs4xoHEEkoSaU M/uoAGXIZw/VLVIWqJLIxGdEH9z0sOJ8E0HGej2ae9jflvZvgbyKYckFA/IvQkRzl0ayxl0CKKNL BAo5AnfNGigfEwO6x7GizEaLKseLM1VgxbLoDDFTFxCFR0Dq5YFWRgC64AL1Rr0pBTD3gjWIOLgb Bz08xGgQCDTBApu0o9LhLk5uVarlmHJEglOZ4FUw4bXy3l1bg5LJ3dCAWIpMGMqAbHSyBq3Xo2Jp DT0LCBFtPmr28XJNinNXRrLGXcEnI0sECj0Cq1evxvwftaWgzJ8pwBgo6c0bDVQVnLnDnFmD6u1c e6cOEnAFGSUMlC/WGNjNGkJylKJHjx6UGM8avZ38yA4XGxsr632h/bkgwosZj73EM0UkscVFadCo BzdLlM62m4HAed3qBlE1aRcuXNirl7I2/Fbh7XHPkRwCM/5EDaJNRz+MGBZnkbl8sCGU3UUQIomC 4OcYM2aMug+VPcLahNUAKV26tKenp41PPn5f29DSLhGQCNwHBNatW4cpQ0hYfKq4awxiZ26so5Q4 qh3KCNY8rEHDBwprkBqmMKzBlFq7ndmy5CgFWCNfkrN+FHnYWOEgZFYlZ7lU1uAHkhVKlXhNsAY5 wIWIQ9G17EKu+TcCdvQowbJ48eLnn38ecdXupvwnc9OQXBbIBD7m+V1cHAivtY6oW5DYg0vEZSgI a2AfdlEKIcTo0aM7d+58U4Hy6ailJlkjn4jJYBKBB4mAaGvY5pgv3avoWNt4tgoH+gqPrGxhZdaA fmK9BMqgS2gqRc1SBwqpOOWRQubXQMNA5f75558dO3ZEHCE8XG4ZH3mo2QirjQN73dJXFIpStoki HLnsasRbZn0zD6EhhcCLFi3q27fvzUIV1A0iQUCVtSElE4cqMzBnXzRAmFjwgKuABkWAAd+NGjWq Z0+xD1UBk5KsUUDgZDSJwANBAKzRpEkTfO925najhoFO4lo3KU+2ixRZl+Kmsga8RFtDaDAORKwB d02di5j5ugvJV61aJWrpIo6mdm6SBERhkeAlrDYOqhNHu8EXRVbLlRNHc+QqO9ztN5q083ACbP/+ 96ihocoBAYk1MLOKJlfxrwAvpmm1FAprqI9qzHz9FcLjrr1Czs7O3bp1y1fkWwTSAJFtjVsgJJ0l Ag8TAfTtNGjQAN/pnWvpucSEMsJla1ijKpoHdlCDMBTMRiEJgqBmBdd74YkA3M+jhLf7D/QVxvRR v8VwvNBdmtq5SVo2ogirjUMuQVmX5mEWbihp0Sg4OqzQbmIociV0k5xv5aTRBEbDMa6hqd9bhbfP naWChDycQcXJUyT8CkqfFfxQDgphnwHaWhFgB2vYMrh9aXFo7eeTrFEA9GQUicD9RgB9O2AN5CI+ 1TtrXUUg6BdWlRRTON2KNeDOXU8IplwUF9ZcrJHTTlEyyOcfiA2DOVQdOnQQUWgq122MkIED5Eik hc/lCyFJThs3Zg214OwO1qCRDjY2mGgJ5sOi0cTcuXPzvZtWPtIVQVhKLgj/CnAUYuKe0wZhL+Gu FibfGeQExAAHHj7++ON+/frluNpvww8qIknWsB88GUMicN8R2LdvH+ZQYbcl5KR9rZrl1tnbaEjl E785a3BVHF6q8qXA1JmDv+qFpIhZ6BlW+w1aSb/++mvTpk0R9Q6UgRAiV85F06VwU8wNvlwVV0Kr PVQ5VIIUbIS2tasJ5vsvSoERga5du2okku+otw2olAgy00VBcUOp2IpuK5y/wbOH2QWOOVjcNlkb T9u3BcSB5tKIESNs/O22aglK1rAbOxlBInD/EUDfQsOGDX/44QdNWYmuqjvlzEonVyBV85PaYQZh X66K52YNoZdyiANJ2cbNlegdH4S077zzDsaR3dzcEB46R1M7N4muaFHysZ81ICpdHDGvfs1RyzfJ 9c5OmZmZmAaGFtPVq1fvHDr/IZTyKmJTPFhzswb3UDFfwEv8OvlPn0Pi5YEB7Kh+1K1bN890WTsT y6m9SNawFzoZXiLwABCA1p0zZw4GxD08PJCdUMK307q3lAkaRzOko9QHW7vqlvevFjivx43PkA0K SnOHfenSpYMHD965cyeGkq9cuQIvLQACC6OFt9diQzL2RrUjPGBv3br15MmTly1b9sEHH4hhgruU XMte6HM8IkFyRMeUWLnPFCEYUAlcIMrQUk5PT69atWqnTp3u3OJT8rv5H0VOq1Wyxs0Bkq4SgUKA wOuvv160aNGVK1dCFu2bLQRy5RIBgglSE65QrXCZPXt2ly5doK/guGHDBkdHx5MnT8KOkIW2ILal gpwQ/uuvvx4wYIBwHzlyZI0aNRISErQhZq3UmsU2hdvbNcpAMDHuUIBEbp8FfCFqREREo0aNWrRo ga1L7hj+9gG0H06yxu2Bkr4SgYeCAHSIqJlPmzYNfQuoKH755ZezZs3CyGyhMj/99NP8+fOxehoW GLSPMAqA1WS9e/f+8ccfMX/4999/X7FiBRYmY4Dj1VdfRRHgjiJgOivuCC/MwyqUmn/ev5hxhFbG Sy+9tHz5crA2BmhQiqFDh7Zp0+bdd9+dMWMGBEZ5UQrMsCqA8IiFLAGFQAN38ViApG4aBal99dVX qHVgrSimscXH4zxDpcVa4PdZskaBoZMRJQIPBgHtI8UnDyUwaNAgKDFMgylUBlVxdEBhpBVnpA5k 88Ybb4AjZs6cCU2IO6rrYIpvv/0WYzTvvfcehEd4YWDHqIdwwf2hGFWWvH9fe+010DSERxHAEd9/ /z1OaMXjxIkTwRoo9QsvvIDighxRdtjtFR6xkKVIBOMmqL0DQIGGvUndNDwkBEePHTv26NGj4nXV mkgFfnu1F1K2NQqMoYwoEbh/CGhfqGZBP8b96MS4+yJoUkFCoZrgArHFHenDEXZtUEPkiAAwd5/7 /UsB4om+I9zzCI9M4aIVvMAFEYiFhoaiBy88PPzelgWJC8Huni+EYFoxJWvc219KpiYRuCcICI2k 9UXfqLXuSS53n8iNGknTLTcmLgIjgDAigK39xij320WVJe9f5KthLn4LWyWs8QXCaMHsFRVZiihB QUFgjcjISHtTyGd4ATvk1HLMZ8Q8wbTokjXyICMfJQKFBAFNNYmvXnssJOJpYmjqCBIKFapZNNYT CqfAClbL64FZhKhgCg12TWfeKEMByqUli9QCAwMdHByio6NvTPluXJAFjBAb9wIImSd3DQHJGnmQ kY8SgcKAgFY/hDDa9659toVBwjvKYCutKA6i2DqiXDC2LndM80EGgGzITtxhgQbGXZMWFs2rwFIh BSQbFham0+liY2MLnM6NETU5kQXMjQEK4KKlKVmjAOjJKBIBiYBE4J4gAFUcEhIC1oiKironCd6/ RCRr3D9sZcoSAYmARCCfCEjWyCdQMphEQCIgEZAIAAHJGvI1kAhIBCQCEoH8IyBZI/9YyZASAYmA REAiIFlDvgMSAYmAREAikH8EJGvkHysZUiIgEZAISAQka8h34P8tAljmKi4VAUwRV06cye0u/G82 gVyslBV3NZVb/xUpUC7qRWFFXtr91tFtfERoGwdplQjcbwS0l05jjejIO8y8RRQ7zM2+Ac3tRouW sq2X5igsEFVY5HqNPMjIxwIggJdJnK2GO7914As6gtOsXHQ4Ms4LUNU7LHzcj+Zi+6Zm5wSzdVY5 SfMVKeCuXZQFBBDPQh6kwEaLRU8iWfqjPSBTNSi7yptE4D4igHdNez+hii8FhzhglV9khM0HYps7 vb0iijhhStxtAvPbixB5L7hrb76Sgsj3xrsW1dYLjopRvOFJCZYpXTLPAU+CUDRaUaPJvxKB2yGA 1wqvFL9c4kUl5c1qnDS56oUUcl5jsitvo/rCwx8uHAZxxZMIwu5wgMlJnygiGxkJFwoi8rp1jkoY JU2RGlEG0uG05U0icP8R0F5Ueg/BGiEXi+RijZtLIF5aW+JQ3lnVI9c7nNtRPN34dXBqiEdfkBYj 9+ejfpvkDR/6KmVb4+a/kHS1GwFW3aSBLdiFgV7g3Jf2pCQsnvkBVvGiggDUF5saDuSpRoM7fPHE jkLPQ9UrGamhhG9OLJVQOBg7i3Q4F9ECMuJUHL44O5G+vEsE7jMC4o1FJoI10NagHirN1eYVVt55 /rzEByDeYaqWqfUx9cNAeqiq6XEoPImvfhXqX3JTDb4IceFwclhE7Qvpia+Y4yp2NSQeiVgo1VKl y8q2hoqk/Hs3CIj3jSlDvOGsmsWrR3d647QXOScj8UqLsOLO9R/xTeCNVSPifEzFKv6Il9kmRRES d8pd/RDwaeAZjmpAm4zAGtSHhk8MnWkcLUcqaZMIPBgEcrEGZ6m9yJqFnMWLi9eZ32TtNRZhxBvO 7zBe5kwzEUfOt6aEoai5XfGZ4DKLap744viuEYpgE7rTdwRRkRSyLlGmvIent0hP3NknZ5MuWy9p lwjcAQHtZWVtnfOqKy+ucKV2BEY68PrBmYwSS1P1Rmu2qP+r3EGaX1SH6LNBcBGXoou4eIYP3n9x UWBOARbyUHPIbUEk7aKkpJEIPFAE6HPAOSTqPlQx2rusvZawKG+m8KMHisXtDJuvw8ZFDCneoRxa apqFIoiU1W9NfHHKXYgqWeMOuEpvuxAQb58SRXsVlUoL3kP1heQ3U2UN0Q3FvqLaY0F72UhXDmtw qxix4JKNg4+JBfApiQ8m55tSkhctHZGd9k0plKEWh4OyhLiJpHLSUQPJvxKB+4yA8soqrOGgi4wi 1sCrqF3aZ8SS5PqCVA0vXnLtTh+UiKVGwd88EW2KpWag/hUMpYbP+/GiKUEBIB7aGp6yrWEDpLQW DAHbF0+14wXW3mdYxNtIyasB1KxynkUYCgw37fOBBY/sKL6LHOIQGYiQIhlO9GbRhTfRk4lb5ZQo PgQzX5y+Ko/8KxG47wgonwP6doJDQnUOjteiY8R7Lt7T3C8kvfZiIqLizgocdttvRItOLza93eKj E59InjtyF2HobpsIR7x54amlwaa0HNe4OULS1U4ExNvG7xVu/B6K95ym4N6OMnLno8alOAa+0MDA Jexw5E8jhzvwaPs9qPnm+hA4ivqRUC8uWCOHODgKfTvSSAQeIAIKa6BhHHQpF2uoMogAyp37nagu dJtLvMm2n4P6vSBJpGPrQ8lq35qIKD6T26SvsEa2Vc68VX8j+fcuEMCrhtfQRv9qLzAsBguq8/SO 4q430LgZ6vvi5RSOeICLMBTGbAmPjd9z9NQmD/91W3x+2+jx86otazf7/ue122fvkeDL1+h1h+o3 ZooOKzyI1IzZlgwjhgLBCvSC4z8O0sHdiM4tDmQ2qjNGRCcYj3qIuCJ3eZcIPCAE8Nrxe4y/54JC dI7F0NagtxQfEnXGolZjwD3bmKWM6KEKlm3B4Vao9eS8sehEoioQOnVpwBpeV2OT9pwM2rTr4Hq3 3cs27Fi6ZtPa/9y2uPvu2rM/5FIYjibE7FkkQ7lw9vhkMHwu+EJxzMaBjCZ8pUJAwTu4U6YiY4ux TImi3l4eCKKdFUgpUwCEkEYikD8E8LKIYWi8jPxqCdYQbyM58MFnOI4SvqjmcxCavWTAxU2J8+Ep C1ZteXPEtKbdB1Vp0bN0wy7VWr9Qu/OQJ9q/XqPDm3V7/K9K69drdnr7ybaDKjXtXblx14bt+g/6 aOzspSuPnAulFDAMrrIWrGaiA/4IbLIzGBFEuMIXlxhwx108sqe8SQQeDAJUU6KqEl7KwJAwXdES MQnXTdTzCkej1awn7jAxZdBIn5kqQOLLoWqY8rbjC7pyLeGfrb7DRk1v1fXlqk27V2jas1LrgZXb Darc7o0aXd6r3W1ozU5vPtFuUPXWL1Vq3qtcg84N2r3Qe8iwbxf8AXJJMiqteNL4yNgMDhHfgoUt 9J1CIDjpkTl/xeSebSpfuoSnhxtHops45VAQh+YoLRKBOyGACpDQw/QhiJeNXjMlmsVq0lstVHfC SLda1aGX//DpS59M+qF6q5eLN321fGfnJ1+a4fThry1cNrSZuLk1rgn/tpn4X9uJ/7QZ90/7iTva TNjx7LhtbT7b0mbMX43eX1Jj4PQneo0u3eLVco17vu38lbvf8bQsmkpLBsuRsg300WFWrQXUhPoU fZC5L1T1hMzoAMN3Q5JLIxF4MAhYlDeV3snzFy/pHIpGxcWb6OswWC1MGWhKgzgsRgpJHxJpcoM+ E9V5RDl98dqUH5Y37Dy4RJMXyrT9oPqAaU7/W9Jq9IY24/7Dt/PcxG1tJ2xtP2n7cxO3txi3vcV4 t1ZTvFpN8nzms61OH/9RZ8gPVXq6lGz2cqXmffq9NWL9Fp/kLG72IBNkZAJbQQCel8LtEfHVoAeA kbFkpCSCNXy8PUkmPsEWFhDHvTpnlnORt/8PCOCNIg0M5ZyHMrKNTBbU6DbQF8HaOzYl/Zv5vzbu 9HK5xr0a9hv13AcLOo37u/UEt8bjveqN820wZU+DaQfqTtlbb7Kf09SAplP9G03yc5q012nifqcp h5pMOdR4yv4mk/ybT/JuPWFHlwn/tvtkab0+o6u3frVGiz4uU3+8eC0J2UASkicbvViYuw6CMuBj gIi44CsufA5CbMka/x/e0cJVRnwn4AHubgoOC8doeFRMNJyUF1JQBtdkEBDflXhv0y3WxWs2N+0y qGLzF57oNqz5O3M6jv/72Qlbm07waDRpZ8OJfg0nBjSavK/plH3NpuxpNAGPe5w+P9Rg2omnpx6t PeloncmH6k8KaDrRp+0kfDh/d/hkUaMXPqv+3KDKTXq+PfLzYxeupqO7i2FSq3bEFAYT8ic+gbBM DZayZUp5eXkJPEU3grCLRoewy7tE4PYI4I3i0QQ0X6mJixcPLjmfAOpO1B1lzbBYQ+OSR381u2zj rhU6feT09nzo/NZj/mmFFsTnuxqM9248bW/Tb47Un3bg6cn76k050AAvPO6T9jeadKDx5ENOEw/A ggv00WjqgcafH3SatNtp/M42n/u1Hr+9/di/QB9VOn9SuvlLL4/4en/QZbQ0UGfKMKajrcFfnhF1 uTyskSMn225fTOkrEbhXCGD0gGtYqM2Ygy5dBmtcjbhmpj4i1GhEFYs+mUwTdSKlW62R6VlTFyyt +tyAks8OwYfTeuzWFhN8mk3Z3Xza3saTdzlN9AVrNJ26p9nUg40nHmw4DsRxANzReNIeEEf9ifuc phxsNPUw7qhxNZrk32SCb8uJ3q2neLed7N7qs83PjlhZu9/Y4k69+r4/1f1AMD4ctM+RuzJygZpe NtUG9agBkrEUL17U1dUVNr0e0ikGYy6qVf6VCNwZAbxRYAq8NDehDIzoZZsx7hCdbpn00+/lmveu 2f1/7T/9udNUt2bjPJ79PKDl1ID643waT9ntNHVv3Yn+NcftQiuj4RcHQRn1Jx3A1XDSYafJR8Aa xB1T9jecvK/BpL1gE9DK0xP31Z18oCG+lCl70U5pP9W73YT/2jivrtJrdMkW/d6aOCMwPh2fgE2b gl7svKJCeqpG3bmYMoRE4N4ggJcNavn/2DsP+KqqrG8z7zS7r844o6N00isJTSyMozA6tlFnxvJi oxNSbr83CVURsSuiICDVgtJ7IL0nJCEJRUBAQUREEEJNQsr9nrX3uTdBdIb4TQAx57dzcto9Ze+1 9n+1vXZtXWVl9f4DBz/ZvK1Vq/85ePDg11+TVATIEF8bl0CsUC+Q8cL0RVdH9rms6wMhT7/Qwz4/ 1LYm0LW2jaWgjaPkenNOB3u2ryvL35UJRvhas31t+f6OQsDC157l78yBNdA+KAIf5gx0dn9nHqWD NaudOQNWgqH8bCkYtW4yzb62d9ylIX+/7VHz+i8OgwfoGLwG+oWslTN8954vgbYrrrgsOTn5yJEj lZW8oFygl/9O5bTc5edTA4oRPH2vR9EWId99os49L3lt+5sfvrz7k50HvNPFvDjYkoSJqYM5xceW DlWL9UkRM6AQlJAPtWtFWwEEMJHvH7+WCzgOsnTCfmXPxIrl48rxS8hjl8IpcKd93OqQRAxZyaH2 FRFR7/7+z4Ov7Hzv+HeXonfLi1Wd8ESbKJ5Vx6R9ONWCGlIRLcvZqgFIzhMU8ufbbn/iyadBjYcf fviuu/6qdA3E9hqMqvTbKWs3h/R66Mrw+0P7v4UlKsSyLMi8KsCSBjr42fM7onrHF2KDglNAgfa2 rI6OHF06uLLb2jPa2zKEUxTXsA6Mz1NoksP1FB9Hro8LoSsX3KH42dNDLUu6R89s3XvoZb69XOMn Hak27AbabcFb9xvQ/58P/+tXv/n1Qw89FBISoo+3aBlni27O9+dAIdKbshj/5H+jI+CCLvoidU5f IWu6aZGXkOr3V7kfMz3324B7fP/5bA/rgqC4lUGOfICgvY0+HwOUKA6+TtEjEIdADR8Lhtksf8Qn O1ggRzrZRS5SIlMGVtmO9nTwopMrU28HuHI7WtIBDs0CbW057Zz57Ibbk7qZ5wU9/voVkY93v2fo Z3uOy9tLOIoOvvV8jPedPd/R8v+nXQM06KmLbuFTj53rPS/V1btXrEwCMn7169+2atUqLzdbtAwC WjHnut3Rz7xzSUCfgHvjbo2dFmpdqVhAWIOCWuFnEw0C6xMmXNRtVXI7wA6OrHaOTFCD0t6Z1cGe SRFfIRu2DLQMfqVVDLhP4UVue0d+u+EbrkNJcWVGxq9C4rppyBvXdHu4441/L9m6F2ZG2dCvvHnr losvvaQVyRZ/0Wry5MneToGzKgBMs5VHc+doy/KzqQGhAW3YEVoRdOA/lExRdAJVGLig3d/6LGs5 L92y1rLdBZs+a33zI5fdMiQsZm5kfJpPXFKgM7eTJQcTK1igBZ7vrCFpjuj1d06JWsHZ09fqJ/pi JWiJAhLkzAowrw60pUZYV/zuL44rgu9bml6g3hY4I/mP/iz5HBnE8d1FfzJffRo4fvfKn8a+NOOp 5afx3v/mLb/zPd5dWkxvy2+lBVXGMyHg82jhbdRIC16JzcguPVq1+tWfb71dwteF3dybv/i6y/0D fhX5ZETM+2HmeejOKAKawmENb/kugwAHDmEfxQXG+vRrTj/SESnOWdwav6ErKzA+zd+6Kty5Oizm 4/Z/H3ux751vv5+E4sN7nqwVu9mjjz4KwLXp2FaO8bIqwoueQZuz5P3pHFSn4W0IftWyXPA1QCvT k0pnypYHNdg1UEMiP9iTyA6V5UCu4hRB3cIMnKojdrv2vcUpVwTc0eb+hHDzPMI22ppT/eMLUCuQ jn4IMk6n5x99pL0pPSihsI05M3R4PtFZHf857rLg3vEvTsCfJ9/kbUK6E3a+26kIWKjRuHymbHsv /4lu6E9uvP6JfkjDa3s/hkPebd1WrPWR8xY1ICkoq959/DgRIrXLV6z6RatfZ6bncATcyCza+IfO fa7/a2xE7Mf+piTkf4IJDWGpkYD0o1nj9B9KzImrCC8hp8S9aElDr0HuCh62MOyJCZcG389AKu0f pF4///zziy666PW33hDUYF+NO4T11QfpmpcxHcI1RivI/5blgq8BoQUvRnhQA8IQWGARIhD+VFKc OqJOydgjqOVkJecnvbf8t/53Q3LBQ+f2HJXjb17pa00Ojs9vZ5ZQwPZOoc9mLWjihJF0Mqfj6fO3 ruzmWt5lyOSLg+8Z7HpGCBpJr84rHfHaDRSuvsfb+7Dx01iUGgXSSdGtc/r6TK45/Vfn6xGjXU7p kdhpXIw9XSfnVzuqYdSauqS9nhkzijevqnEvTM25KvyOdg890922opsjNcRCfBTx5+Kzbt7iFKMx 8CHRidb0AGtKsCM91JnS2b4yYtjsyyIe7v1Y3FHJvy7vPHr0aNzfukKxpym6UvZoXflyjUINruBI y/LzqAGaGoCQBhcyEKqGMBpQQ1WCvkbhiFxQV19NATU47ho/+eLAu4OffDsCVdeV5RO7xs+8JiSB AI9MwjZ841GHm5kFYDEi1S0ZoQl5uN194/G5rw4xL+0RPf3q8HsG2UZB07pUyhAqpR/Jl3pbV77I U7wHz/MN7wv/TDYUbWoK9ayNFtJN+d3WPL+aTxiqnvwglbUyFhViFC1j5sLky0P+4v/omHDzkgBL um9MagiBstZMfHbNCxlKxcDZAXAQnRvkzA6ypsKzRPO2s6SExqd0jZ1zeeQjt97/NOZdrFWyUL01 J6tqCbelcxCMkJG1HuHLI580Yin1o5bVhV0DBs9pBmyEGvqARhBoBfIQ/ULCBYn4EPf3tIUprdr1 CR84NTBuub8jExtsR0smYj9BUO2t6b44sh1ZeOWalQvE8GvNDHLiW8+CF9q5sijEa4WaV3QfNKVV 614j3piCt1ECvBTxq3Hrp3e2P9TC+sofOnuOjuuG+dms+VBNhI3X+usbGsBbGw2HzpcteX8x48A1 VaTy4CsyS7a2ui4y4MlXgy2LQxIyBCks+b62QvyA8E6z8gss6e+UgvW4vSXH354boEKqfJx41XPb 2VKD7Wu6x81t1f6ufo5XiQSWRcabiJlNhpfUnJDQL1XbfAgHGzeKQg6NNPqXLesLuAZU32jwoWwr +UFIQJMEtEExUAP3d42or5M+WtWq3Z87D5nuH7ssOFGGVLSzZktkoEMNvrAT7JGLyZTA2mblAlAD yOhoSiNkt60t93pbDsVveDGjZSMtq3pGz7g4pPfgEeMR8vgqFQMJ6mksaLz+ocbV1/zQ2XN0XLfU D60bf9YFsK0M6tChtN6pRVeA0QaNa+McNcsPPVZeTYKl6IMFMlZmlV0e1DvosXFh1uW+9oy2ZjIk 5OBr6Ggv8nUUEWTbrPwCaiBTgRo6mrejlVDePMxiOMcJx5IsDdb0LgkZXaPfu7rHk3c+btKh7LUn TlTWyQhe0cpFdCSKSr4FHPE2Cp8pZ6W0LD+HGlBt3cCEsqv3NEloiUKgA8gg62ZNXVJGCRG2fk+9 FWhPChyZ/6eY1TpWnDDyNnZiAovaOwrbWSSYVgXWNqORSusarFvbcjoklnSML25nL0CICnDlByfk +kQt6B43+zch9z0zcaYMduWrxL+vaVuDYaNv19/MumHRVzbsnw9b3tf83o3T3/B7L/vJHeS71DuL SKNjpU6JmGr8PadXwbk9ot9NGXzWbdn1h/C72v/jhRDLKtx/9NXBw3MxDREWyyBWuKa9VeLPmxc4 JBVJFul6SNrT3l7SzlHUDp61ZQQnACXpODvIwxBgWdUl7sPLIv7VzzmeTgC2wR59UnMDGXrrkMJO Rw0Y6nzkl3Pb+Bfu0z09p/GF7GoCaBDwIHw5iJhR596+88Afg+8K+L9XQ+2rOjozrrdn+o8s7OBI R2IBOzrEFwhwONciOLWPy1SjMJoRNeAvLFSkHGnryLvBnt/OtraTYy1DQrBWtbZmBA7PCzKtiBg4 5YrQ3kszC4T+6XXkYzR5e+i8cZ+jPlU+t+EatXferHhBPkSvNaw3Xn/nU/Su9/rGv/1JbPOSpy6C Go2BQ3+gXKO3GvZP/d252uN95H3l7b455u7Q88GO97mCYpdCsTIcCbuQJdnPmSHhTI5slOWOrkL8 1M2KGkSP4AqUAr/ApM7iDk4ZPNjJkqKDfrEYACvB1hU3mt/7bdC9b8xaqBNN8w24NEXuYr7yuuMQ FfwjpMW3CbNIoLt8Z8vys6gBWtzDdLIFLUAArEWqw6jJIrlklT2TGNyu9w7941/iIkwL8HrfYElt 78IYxTjujEYlS4by2WSIH/HhzS47qah1TGSMYCInCfZhUUDsDJ6VIbR+trzOtjW+D48msc/ubyXo S9E18xegfPBtUoxco55z8sGy6LNSD+dqaZySWoXiGC+CgUASO6A1KQwk65Z+d/Vp3/Oy+vhPcc3H yIfz6upTdUuJvadeQsF1aJ/x1XJNYzL+nno4C4d0xBFrnd8PS44y6cg8kg8MHH35zVERtiUdTSvJ w6b4JZ0QDoniIEkC5OrMoeiBGM0HHIo7RJDTuXrgGs2kuFSQ8XgTCkAW4Ejxj1sS3P+diwL7bPzi kCgaBkjQEpJc2qh8ql0agB4DCxYXtSw/kxqQtjYaX764ATVkT06IWCG2Wbc7/sXpvw59rJtlYYg1 CeHEP7GwjRUVQxzfGGkpfrqQJweyZEiRDA9vXtmJRwMQ6ikaNfIlS48dFMtiTDqqRwdTcue4j6/r Hd3n8Tgo+0glHKDkIxltokidb9T9r9B/44WaOS8YgV5IowbrKvKlGIgmr8orAyLSSqo0fnvjkHyU /oqf4lp9kPq22irSXmhpVtrFo3EYmpdc9z1VoH5+dlfetBsK2Olcq2tq6t5bknNJ8IPhMfM7mpMD E3AfpPg6AIsMNfQb2Ub6aihWSjNH3iqJLk8PD9SP4wgCHpziI2kPc4Ez3i3AmQkvoxZd+1erT69/ ibzlSY1C4D0Zc/kwoSxd5xIho8ny7NZ1y9POUQ0YzW70OfCjgRqQuiIJNWWG5OJ3523Y/WvfvwYN mRWWkOZrXhHkklzNkiHHtZZcB/62jECMQtYMNqA6aE8LM83LBcJo8ixRbYhCUc5EBV7pWK4w0pKi h5wkEQl54UPevzjk3okfJ4lNVs1cwIfr/lZoXwu03row2kJ6p3PULPJY5FWvuqGFWKUi0UAyAdzJ anHy6yKx9I2KAkHF1hIlSUHi/Umu1UcpowhNo761ngH+tTW1NYi7XuBQ3Rf1pZvv3DWYRnbdUmyr DV666ov9FVdF3h/w9IRAa5J/Qk57c5KfIznQmu4vo+1E1KffJm2Iv6jGIm41H8twc52fRKGGCFcK uXJgH6y7WKvauwpwi3eypWKtwpYVbMvoaV9yeeRj9mdflQZQNY2PQwxTUs+6SbBdM0UIwKEPnrsG aHny2aqBU3tKyEBQQwVmKyJQE1NyDfGr3R+Iuu5OW3h8chtLMnNhBDjSOsSlB8UXd7Dkk6gWmm9A DXsGLg9UgOZWtxGWfB2pQvwKNZSujXkKlScdSQm/Hqjhk1jgY8kJt64OeuKlqyLv231UvtA7JyCf po0JRp+jq8OofMUUZ6shvvMc463gTExoDbmpFYjL1FdEJmgjG1+j37PRmq/goF6ffvandEQaiz4K 6VY+h28CNTzf5VE3pC+TY8a/71TkWdrVkOF9mMYOed/6uietI3/b46kQ68JOtmSf+Kyg+Ex/e2qQ JcvfmkfoVHt7EdhBZx5ohYPOBmrwLGWhEtQQ4wBQZctray3EzdEW1HDyVpnwjmCZNTPEtCq038Sr g3pt3b1HV3IlETHaPaj6CsELKXQaXjTxVkPLxoVZAwarCUGw0PMIZBjqJwfwgNdU0cfOWp59Udi/ yJbTwbySrpikmmTvl+5aMmoyI0YBgpMIS4RhABkkLqA4MRNJvsHmlJ3kiVC+ltl4KI8TrZ8X0/qO S+JSxFRrWtHNtujibk/FjZ1Eb0vRzhu+W0Wjqy5X14VRFao+zvVKdz76LUTvkDcEOOg56ZAMXKC/ 8r643jjXb/1fez6fQ0shsQAa1RAm+7V1AhwCFPwZ8VTGVxv//mtPb9KNvC1Fa2jEZwPGydu445Lg 3hGxs0MSU/0SM9sSOhWXHGzNBDL8rIWdbIIabRiv7cgLtOQAJbpLb1aW0c4LYUyVRBoWVgpOHm5x dA0pODscov6AGsGunJCYeX+49en7B1rFCEUjUO+a9KS7ULYpUWalSTw6SJNqruXin14N0NbGIkwH d2rUEAKoImRCCbTH693Xd7/Xv+/LIbaVIaMKCE+CqknpL8OFzGl+rsIOKmJQkZ9yi9sVaqBrCHA0 I2p4yF4njuahwgjaStzBloabXscAB8bnBDpTma2gy5BZvwvqvfnzfRo4qmBwSF2+2iOon9Oex9MS 8t/b+TTe5m1fmjD5lUkzn584bdxb08a+OeX5yTOeeWvq2EnvPvv2KWXsW+9eEGXauMnTXp02g76J RhKCVA1Uw4SNCjU0cBg0fK7bTqG36IbeDV672wODbrjLFGlfSnr/GyzJvvG5IfG5fibMU8hdBmq0 duUj4SttvdlRQ+ORBg4PXojqoYelY2ruYM9FZ9d2My4gw1vnhPSbTbMvCfrbmoINwioKGzyVrfzg SoARVoJuGxNxy/YFWwN0mKqxhQ40ashQUE+4nZydvSgJw2xwzIckWGsdm0pcK/kJyVsuGq4js60l g5mVyFtO0Z5xEfUliknimkT+b05TrVC4qDYaocROy6PliYw3dBYQzUgwfHtrKt49uDIiel7rbv9w PfPy0VoRYvlMIXX5am9R8OFhifOhzb2ujRMnTrwyedpv/Lr1GOjqOTTx5piR3YfEdx0S32VofPe4 kV2iRzSUYaO6RV0I5aahrj4Doy5t2+716bPw4tBYEvhJ63h0jfMKNbzqhvCTCrhgGPivgu7pFjsr 0pZEzpAOtoJOCSXwi0hcViR5Ouci7ELoGu3IvYN7zku9zcMysCfwhF4DHIhKrtwoHJTMPyqgRTJT wdeEuNhk/EgbZ2E7QkpsqWGxS27o4/pbX5PgAt2D5KTSAMG2shkqZ0cLapwPPcZZeYdG/aQQADZL kSak4P7C8eh2B932L58HE0mqjBxCMlvG0LU1Sc4QmZjVlolITzoCKF8r2iLtK6uRklgkU7oSaRrH h4gm4o2tgmh18YCLPqt8gqdo0F4voVzQUOwS4q60DOUWV7EowgiMNLQXyESBGGmdmYxSZzws+bJu GfDKlZ1u3F8ps6dp1OB7lc6hgaNRlcMY53TBneGVWvXGmAnv3BQ1/MXir54t3P1sydeUMSV7R5fs HVX8FevRJft+qIwp3qdLo8v2jy6hNP7J6UcaznrvoJ8oPyw+MKZ4P8fVTeS3avd77ul59Cl341f6 t/9mPX7tF+/kb+w9YOj4KdOR26FJFl0VsuFRN9Rh1Ys1f5N5nqC4xniw/JMgWyEk7QSXHpVYvb/3 t11zp51kU6GW5CArMnxRa4ZjxxfiOBDUYGCRDJoolJ5c9dsAB+zjLYqwpT+XoiLMjR5eY4rnuIdx vAzyQxvCNSpGXaOG1zPOcQlWR9gLslEySTPC5Mv4x5mFvDVTHpCuypLRLfrji/zuKN2+h89k5Aaf 7KkK2WJbl0ZV0rJ5wdYArCdkwGI0vNpmT4w3cmxJ5rpfhz8UafqIwHKI3NvbN6ZV1e3rnlwoVuu/ 6sq8Bn+HhBqKs6+jvZAunTUXKC7IQtASrpEYXeEjHa+rsEZ76zR5a94xLuAadRMdba7Y5FQm8sCK 55RiNKbh6Bw3/8qeA56d+J62dsAAldV0SCxSD3wvn81aLRpHjAoxjp3Tf6DGjdGjninem1B60Fl2 xFl6VNZlFc6yg46yIxS1e8RRXiFFHbGur7CVV8SXViSsU5eVH3CUy8W28qOqVNjWH5Qj5RXW8qMU Lm78c30TfWduEl920Cl3OCDHS6udpZU8nZ9by4/byirj1x2PX3eUn6t7yguoG+qX5IlHrOvlJfXd zmQ9Yt2B8Wt33jjYgSHO0yge+tTNxFE5IW13FlqGRxnkoeQrntjwVpJnQ5Lt6ALpbPni4CX+d0Sa PiQ3oNK+xQOICgyRa1HfUIo9aoUieI0ReOVSQRBF5Ljq0tVuFh1+G1de63jhGgUlYg3WPKWiZxX7 qHk3OKt50DgLS+rwWhWvxYMU62mGxVBmRHApv6RHVecl9ZArh8yVFmDLJbfbVb1j7o99RvoFmVin kXjZ0BaGw+MstEXLI85hDSiBzUP8XqLnhcRuI6aqe/u7rrnLxZR5xLL+EGo0RpDG29CnoAZilXJP Kzah29eQIQCkUaPR4CYxainUUNCjYto93KQ9JkLwWl7iZYCGxo/7j9tYAHBwdHp8QqeeD8iwDU+9 qyAl6Xk4cipqiADpuerc/wc1esSMQkqnyzWtrzSXV5vLK+mZzespx9U2u8fZNm04yq5p/fGYjcfj Nhx1lB2n0GmbNhzhYo6b1ldL2XBUHeGg3FDuyX3U3dQ1cgd1W0DhOCjDHcwbKuI2HonbcNxcVm8t q1VYUBG3vjpufY2trBrs4FZco96KR1dSeCWKuqG825kXAAhNpMvQxOcnz1S1b6BDA51yQFrRON7c LdRAHuL/hTm8JAQxsVuDkar6pFhvkMXjX5z2h5ufZq5VNcWeKNSkmaVoevb06oZVSg5Kx67omT5f RQYiF1GI6/CzEyiI+pyPB4TSSDE5BTUM3QRQOA011J0J8ZVgLQxTwnfkjtPWKpuIdoRvgRq8lQ59 5AKFJpKMVDI8WHJC7KnBwxiu9TeZaFwUK2EN+WbFMlIR4t1g7zzil+amh5/x/aWr1MXDgKoyFFMc OFZ/qV+vzoMmhzuSFUU1rZdW3bgIM1IMmUpYQxGkUK8SmQy5CGRhF0qmiMeESc0c6YqGBSa050IZ fnVML78SjpM7eKS1/7jBJzANR1fLR7/16VWyeRdfXl0turZaBEUaqkIOaZ44j7ig6aghnTZY4CiV ogBFQ4aBOHTgAAGFzh9c4BrUB3Wl/EohSyVYID8HdMoFgKI3HYnedBQwMpfXoG6ggKDpgD7gCBco /UWUHVE6yuRZcuV6BTrgjrrJhYAa9JlqsgAIRi11ah5wGRKuSYi4r3Y9/h722FhmABfz6Wkk6kEN IX7PWY0aIk0p2s4ivIoiRAupizlLHA0U0MHDTUrpkJuLDs5xLYB97xPVaCbUCrkbF3CloeOLSVmU eh7KcQ5qNAE4eDEehEUa7GDCtVDz3Eu7PzZ3aZpbwvmELxCxWlDDIIGf1z+j9UXxlIVdVeoYTOWe uyL36sgHu1nmBtlTcOHh1/BQuFDUmRShZJW1QOkpHgOXyEKNpCzDqCXahOgRTnSTdGLaFRnL/OB6 inD9E64RpjC8J2L1OpPX0NcoBkzvbJnfvvfg6BGvQPDKFI012sP9HgBV+z951FDqBgBh9PzWctkW hUI0FA4aWgB6AQVccJZSBDisZWgxNaCG+q3oKUqJADWOAxkAR8xG0WXkJ8pChcICoKCkcB+AA1VI owbXgxpgB4DCxRSFXGeqbpxvugb0okFBB257toWMjPhtnMIMuHS7s8u3Xxb0t56x04NsSaf34cST QIre4iFgUAOLqwxWNfzUdnLhkiFH9epoIjZRPeAmLXSx5oecVYKTNjdpF6E+IlAi4CLMooUrJbAZ 6CDQIOjg9YN7jnt1EEENfosOItGSyHgp4Y7l19/jvOvRIXywkjAFNRrp5rrrkJMty4VeAw2ooXwc uqvELS7qZ+9Hzf73u8Jj5wXYJfADavdQ+BlChijCeMlbu0RGUgoydtqM9q50CnG56MsQP9TbxgXB G9QOqTNyNojBs2r8keRYcxSqsedghE5Ugo2LoYWMQ28aaggX2FLDbcvC+o67vus9kidBQWRj1OCQ pzc477igqboGHbsUEfU1RjSgBkfQIAQLFI4AJaIpKDOUrEtrbKW18ivl6RDDlFyGUes45inTxgPm DQcU1tD/Y+NC0ZCibV/KKmXgAuBC4QJt9TpzLUNfeR6ihqc3wD6DYV/3nQYVySnUV6YtqnNbn3vj ml4Du1nnB9qSVa9+Cr/8AB8JaqhcavlQviJ+AQgoX9JVKe859A9MqCMSo6sABa+HhwsMgGAXkUzU BIU+4iVRJi9DvkKQExc82W6Fs9BQuFLrGlxgODs0HikFhOTqmfCsnzONQU894+Zc0enGiuPGLBu6 BoSNWpafTw1Iq4tlxqNpQvTaYinRdNhurgy8s0u/N0NMywNckk65SZDBxRCkUoTzVEQ6EpQMZcLu BGS0AzjI8y/jTwm+KsTHx65wgUqtoLlGYYryejvyABEK9wRBoHavDCay1plpPXKZTBSVRrZeiP83 fndu3f2tRg0a3OgBhAEERs9PRmgyahhOBFEBAAX0C5QI0TXWeyR/dstrYjZUU/Rx8UqgMpRVW8tq 5CdivzqIS52fcIEUIGDDQesGfOL42Y/i0eC36BQKGuQadqM34uYQiEHR0Kihz15gqOEhGqEZoR+U DJUpC24Kuf0B30fHY55C3DodNX6AYkUX0Cq52JGUyCQ9v0hHFDnCthaWOKJRQyCDAa2aBRRqKBAR i5YUwY6MTvjyKGgc6jIegeGrnaOETOlKtdHoYwwSV4Yscb5otAoQrsxgQnNyZzH3X1fT/D92e3Bp eoEoVAaTaOFK1QA10bJc8DUgTf99qIFTo66+/NN9l4Y81CNubgguBmcuM7Y0eV5jlVpQj/Wje1c5 E8Rh0dEJamSIJcqKNCUogD6iZB6Ro+AOEYdkwKxo63AB1iqV4Uq8eMroKnq6RoEfYMBTRLvG1wQk 5vtYkno4ll3W9alZC5Lh99q6KswLHiYwPHp612CL84YMfhRqiG/atPEgcHA6amCGillfG7WxZugm unqcIGKDUoqD3tBYoEEHfUEOAgSsQRaJ3So9ai6rNZXXo4koVDouqFReG7e+luM46wEO8EI73JXa IuB15thxPuoaiibInyCKuYdo2AYp8IOLxHGyngyZl/re2NX8oa8FK6uSarQerdbQsCqGVA+pAxaq cNyIBuECsIZdvWHgjrbrinMcVULOwkHtnfBRFkBA/++9Xu4vMSciXMk26X2c2kWo+UKMXQxLlwJ/ KWASPBKcEo+5dppr1Ah0Zbc3JXOHwNFF7U3p4eZlf7j5KdcL7/C9ns/nm8VAwRHK+cYy5w3vXkAv ImTfGDXgBXQNgiRE13h71rIrujzdjUnHbOltmWiYGTSAjzMX7LVgo8I5oEBCvil0/hAnXCCeOLIW WAv9rDKRmVhrPWIVHAFkiFELcYjjKoZESFqUF5VQWjtKhPuaomio9yGghUTQQeaV19zpfDJulMIL hsN7JCWpDViAXc+R86m1fwRqiHFpw0FsSiaJa5KAKPp8enJc1XgZQA1in2I2VmosAC88/bxhd2KX Tp4f0uez1qoEegT3IcoX5wUqCTcRT7qE1B5lQxwi5UAJpUYBBHCjY27l7IWGGqKYwisy8k2Yqeok wLEmJ+/qiLvCLQuJmDL45T+jhvTn9PDi11NgIdue3OnQubbfiulJBRbCQVwmvgmX5giJSwQ15HFy MaiBJx32Qb4CXHReOLm/GKNEbREdX9aEVIn+oo1acJNhIkNP0cdJ0huUkEsSoRss6X7xRYGxK4L+ Nabr3f2MARsCEoKUlBbUOJ+6iuZ8l+9HDbHZwgl9h42+/q5E8v4JKcavbWdJYyS4wQWqB/6P2yIO 0e07C/xiUyLsMlbIF+yIL4bCGbVN7LqfOS/AupaZKAllD7BkgiloxJjCwBTmcu2UUEoeTsYZtWVu SouKAFTz13Ry5gcmFt8Qu8Y/QbHJmb2M8baMWsKTbk3ze2JiSK+HAAlYnswp1MRJEqmCGuQGVJIk R2rkcPMu3gQUPMY7uNjrZ+GIPqhTG41+Y3KTIm9Vb098lOgacRsNKxMmI3wTrk0nzEUH7Ruq5RoZ /SHFseGIpfywhdEc6w5LBNS6ClP5EYp9Q6WrrMqx7oS9/GRU8dHY8ir75npL0VH85goXjtjL9seX 7Xeu+8a5/rC5VJutaqLXV5nKj2EckwAt1rhL1p84c0WDK7Wu0TVq+LhJM1Qz0EFJNy1kq0pdFbl8 peb0cXVNM6+QJsSiK7naRLaW1+G/OAGrOaWk7XFvTr3htr5hjiTGmWphHpLzFunSicIlnYI128+1 tp2ZvjqP/MzwFxlxGQDoF5+rYCKnnZUhtDKZMqIO9iXp8HEFOjOY/s/HJZjC6NoOLhljK7oGHhAS D9K3O7IJeYKn2lsLfZxFvvEyaRqGWdgK/iWI19+eHOLIYjQfspyPmbEkqfgsdLwi3ArQaABSOCXm L34r+EXEr6Mw2JbGxMqX+/eGSaBMGdQl9c9eFbKXsdfMLdBy+3NcA8J7DbqGSnWrIAOKqHffcv/g tg++ECgzVOZ2YEAriURkLF4TiqjMrqK2sanhlpSQ6CWBMcvCSUIbm+pjEWMpk2B2tqaHmdM7xaxh UGq4aVV43PLAuOVMQBniSvGzrWkzbDWJcTomFDJFoH9CcUdzdkeL5HBG9+kQlxqUgFbeVBQjDCyb gpsmcPDM60Jvh85VCk/RLIT+pTOA/BtpH83fQl6M4FEaI9gAJhqlupWXYHfsW9OaiBoERKEFoDjI IAs0BVzVEje76Yip9JBr/TGKtWDvyIJdzxZ+MTxvlz3rM0f2joS8nYmZX4zK/SohZxe7zvyd9tyd ifn7EnL2OTO/cmR9acvdbc750rW2IqH4sLNorz13+/CcT+NTN47M3ZaQs2PU+gpLaQUPQoWh5wcv UENAorjyEyoMuGkWqmdKvgkf6Hxx6hxVS4IO0llJb11fTf5+DuBKcNepaUeklpp9gTgkyYvKIAlU iMwhSRTZhJYEP2rdA+3PXPeXfj6xyzollBuoAdd4gEOjBqwBavg6C0njBk8JJTsymNqPmVjbxSaJ KdgJdhjkSpIo5vvuaE1hXmPJ5BOfDw2L0diWJUnh2LBkB7rWBrnyfCwZnSzgQjZpqH3sSHoglKT0 ZLZZssZ1QlgCIGzJSE2CF9a00OF53LaTmIt1zK2MVQc7hHPRWWSewQxBHFeuympYSJhKj+j3Lwm6 b9fBEzIQWDoQPltQg89vQY1mJ7/z5AHS6NLyQvPKPgkP6t0bIv4W3H8q8RughiIkRflNQ42ctjJJ cVrI0Pc7D5rWeejssJi5wTFLIhyrAmI/DIqaGfrU1MiBs9HlQ00fh/SbHNnv7W6DZ3QeMLXL4GkQ Z5e4JSGmle2iliE+kSARrTnYsiYgemlQ7IrOaD3mzAYLwJm9lWLYPD4HVmWQ+BWdbvrm0BFCz4Xa ESH5pzsk1I6TRNxrjpD/zbd8L0x4D/Jctr3wMer1SU1CDYZaxJfUONdV03uLw0J5rqM+kdBZNAg6 87ic3WMKv5i54avXU8tezNgytXzf1MItMwo3v5mxaVLm5pn5W2bkb5hZvGlK0VbH4hzHwvx3i75Y vuPQ+6U7xicXO1M3O9I2TyrdOTXvk1l5W94v2D4rb+uYxVmJSSWJBV+IgqOGaeD7kAetPzJk04nB m6oAjjNXN7y6BpkYvaghdeIZWSPwrlCDY9SSGImaeVGJE4VZRBsXvBI091qo2K2udd9439NBj4wK caa1ta9tjBrKv6BHG4mugcrcwSpD/0gBihAVMoLpjFcHxC0PdaShLNDh+yWs5Zr2BJDY8wJc2f6K 5kmMg2bBPOMIVJLeJ7GEWylYyexkSguwk6U2TyaXkYSE+W1JopuwlsHdKDLgDroMU80ihgE0KCaw Fc5K9Ig2ZClUNmEvZIhwKDAn6gmIBohIRlxHPs59HOKXdn4ktWij1tBVfQtqUPeNR842czu03P7c 1wAtrhgOiUn8wjDFiRr3ZZ1u7mb+SMgGuQiHHZqyTDfcBF0DwmtrXd3r+ax3C6tmFxyanHtg1NId EYMmBz352hOvr1i4rXbJxlrzpJyn3s6dWFwzteDQu9l7p6Xtnp2zb3butzFvZz0yLumltOO9CF8c 8r7kVbNnhkXNfymzrt/kT0inxi5M16T3ATVQ2EX6sud3sy79XUif/NL1UDyfLQudgEiSVbV1MncT ByQJV/Mv4IJX3WCDXb3wZDY0ZOgLfhRq1DpLcEyLltEYNeyfVNoxQGV+9sHeut1ud8qWL5ftrNzu dpNmaB+TXLvd+91uIszY/srt5oLR85I/d7u/ZrdeTn3mdo/P22FdksdBfRlrjnPl9OJto1LXu0q+ wTalx2iAGnjPcbhTmooaIwr2dI8eqceGMxmTaiShVXQNUZJVk7GnpmVUroXmbi/FJ2RLPqFn+lC7 vMfJWmEc3giS+VOXu8OeeinAvNoI51ADK+CFRqjB9MSKFG25MvKaucxQNMwr/UzLQ+MWhZmWEzFF hn+5xlnQwSR6RCdTCj22rzU3wLn2T7E5vonr8Ep0MmeTEfFPcVkB6OOmZCxOoRJhgkCVLqaqeEnd Ce7IpGnxBaCGsv3mt3aIcUzNHp4B3OD4aOta29pFRAqBVRLTDk/hW1SeRDGLCWroPD9OQY1ulsVX 9eg/bcEq7cqRVhBdA/xWMldz13/L/c+PGlCEr17FcAQLauz+puJSn5u72j7uaE/TIjqiyw/Emf9w 1+1Ib2eZP2BOKb3QgSrpf3a63ZlfuJ0TFtDD7OUg/U+N+92cb7e63Vvr5UiF6oW48rVlm94vqvjC 7U4u239T31EBMR/7m1f0Mr+3w+1+M+XrbsNm+ZmTRGBrCoop1JBgLZKzdbUsub7bAwtXp6JUGK49 5EYUD2F9DpyUuKqGqmmupgIXtM+CBwAQGiP0wzjV+KmcemHKrCbpGkQ0OUvqHes0aogvm04b8xTW KnPpcVtxRdTqzR/sOnrQ7V5VuGFi2sa52499vOnrBSXbaS8Orvnki4Ubd83dvPe99V/k7T0Bgmza V7Ewv3jZtj1bQI2C3faFWcAETba4dOPCsq3lJ2o/d7tpsrGrCoYX7rGXMt6cISEEVh3GtQFy6WGD TdI1niv7tvMgF6hBLekMgdSDaiN8UaTXpNagVrBV2vAsLMA3yg2PpCidRxBeQYY0FkP8jiJuBfy1 Z/S7gaaVdNfIJzo+6ruoYcmGoXRwLEoEM2O2i1ny0OStr+TWR8R8xCR6ghe2DEyp6NQAAYbisPgs HxP6dYHfiPU3mPHNpQfbczrY1vrEl3JzHBDBrmw/UyquQwxZ7GpXRTsMBejpaAqmZOxUuFoAmiAX bsR0f3MqwbS8HgcJxDUC2sVF7h0SIsHwisVEweGFiWaEca6+ZfC4yR+IiCnYTU3wX6Sss8Av8pSW 5VzXgGZA9RbwoEhwHIEeNm7bfXXoHRHWjzrYUpGRUDQU8TfR++xMbWua239aPjN0mOPG9nzg6TeW ZCCUppd9cbC6pvdD/7jtwX4TFhTdNnjijQMnBP/TvOGYO3/rnr/8c1DXR+O7PPnMzOxdgAtZzRek buwyYEJk9Ky/xEz53O1+a9WOG4e8HWbD69HkUYdABgKYvz2/i2nRdd0feH9pUoUCCZXhV6geHqg8 efT58c8cPlRxNrnAix1kRP/kk0+mTp2qScOLHfRXI159q6mowWA9wpwwFun4KBlttwG3+BHLukq8 20OTPpn16f7DQHPxhmeWF41K3zZ8eYnp3cWbD9XsrXe/vDhtzNLs4Ullw+asoWlAhxffmT5+1gfD P179UsGOsflfxn6QCr5/VX088Z1Zoz9YZJo0bUu9CAZvZ5aPyP8Sl7qt/CRgYS07hK3JXl4lw0DU qMMzBA5+Nbro68ghCc+9PV2TaI1M9a6aqb5u776v33j59cYWqlNhVtfff38NkYhhzO1etmhh6uqV WsQGTHQLIoT8otMd3aNnRrpSMTSBCwZwnKpr4P6GoZBeSEuO1szMmD6m5a+UuDe53X0ss0Ki5vnH Lg9xrPGNXhLpSA2NW8ac44FRcwOilwVa0uj/uT4kdrH4AbFfmTN9rasCbct8ohZE4Ok2rcLM5Wta FOhYHuBY08GUhOYSjO5gWoHchWMiwJyKh9F/yNxujpUMxfKJXRNAlhKVU5RXEi1DjRDRUYseqUy8 7Zz1tyRHWBb97s9R8S9PpZdgRkkCA6gBmkQMvC3Lz6MGYAGK/InUIMIbm8htheu3/jHyLkENRwoe MYQZZQ5qImo40ttalzz2dsHxOrd52PM33zdoelIpQuzqtZ9hA1qemf+3J+JvffLl0Kdnh0Z9FDLo jcwKd+auk7c+ObJr1LSQgW+/V/D17mp34ZZDR9zuCR9m9Xp8VJ/oqdvc7pcXfHJHzNTwuKW+FgzC P6zpnHZKQwZYQw7PbqbF13Z7cMpHi49qXUNcmu7jJ2pGPPPcNdde9Y9/3l9rTDZ69uhAxGlPxxcU FNSmTZspU6bweN0dgRpN9YZr8d6jXwhY4G6QhLRlR1xl9baiqsFrtkzf9i1wkLx+y8i0zY7CvQn5 e6Lmppceq0OzeCW56NnMLcML98auKE//5iRw/+m+gy/PmTduRWFi8uaE3D3mRQWAy6GqujFTP06c vsT85oxttWLUeiulZHjebsu6o5b1tSg4lvJDPFQCqJoCGSALqDFq7d6ecWOenThN2eiQ5+tIHfbl nr0DBg38zUW/BTVkaj9aDi80HdhZWbSugff36y93/e/lF918043JyckqlQJjf9zHQA2fu7pGz46w rxb6/C5qSEoECU8S4sSzkBvgYDxduq9p1fUD5r5R4t5Z57534JibBr0ZNmBK+JCpQf0nRgx4p+vA t/u+sMz+Xhkuv/Ah7wdHf+Tbf0rEU2/0GDSlc9Qi4kzCY94LGfwOrsPQflMjBs0OGzQ9oP+bwVHv +A+eFjjs/e62Vf793w8ePCN4IPecEzF0dpdBk97KPdplwMTQgVPBjgAzWebEb67ipmB2mXSAXe0W R8UA+ATgiI03J0VYF1zTOyZm9Bv0EtUSFUBMgpgKz45uflZauOUh/6EGDNTgKrboshRqwIfZa9df 0/muzpaP25MPyiVxg9pz55E9zqyvdmT8KW7pU9PW43KGuOh2vuTOn7tv+aez4LOjmKd2VruHvrS6 e9S80KHzAgdMzK10p+6s7zXw5bBhHwYNmTUza8+Xte6e/7Cv3ycGk8RX5tzy2Nhdbvc7K3bc0n9C F/PyIMnnc2Zv4r1MlKYcZhLvbll+Q89/vTRlFsLhcVGy3C+Oe/4Pf7yh1S9+1eoXrQL8O4aFhYWE hIWGhoc28xISEsITeJxeh4eHcwTI+OUvf9mqVat27drNnz9fW66aGnlrmKQYoC1WqQojSyFJ0dE1 Sk8SOjssbfuM7QdBjaTyLYnZ2+zrD8cVfBO3ojS3ohLT0ysZ5aOydljz91ty94zL3PCZMh6i/c0r 2zliSaF19afmBYX7gdpad+aWr9dsO7C9TtoX38fzy4sS8r6ylJ0wb6wDs0ANNbr8KGFUZ6hl6MtA jbGlB8IGOMa/MwsKRdGoPHFswIABF19yGW100SUXR4R07hLeOcDft3PnMOotMDC4cVuFhQZTOEIz 6iI1LJVNm35vs55+nJ+fes+wsOCQMP/gsPAuXUNDgv70h9/RRr/4RaubenYrKiqEhw653b8O+vst to9D1cBwD2oYzuUG14byZYsygufakhrkWNNu6Lw3Ck/uqXH//fGYCUvKVu1yZx50l5x0j5iZN2js BzQHlJ9/0P3I2GW3m6Zk7hdL4OKyE7cMebdL/3fmba5/bc2OzAPujG/c0RNz0QDnb3V/4nbPKjnS K2pil34TbbM3rq9xb65zvzR/U6+nn8/+Sn6OS++15G/gtUBTEpqFsDZgwXhAp+RtADLwy3RQKgYA x9kAmaY2JdK+5I93mvs5x6sZahC2alQYSQtq/Iee9gI73Qg4FGagbNa7S9dv+31wH7RRCbqzZSFv aGGjiaiR1dq08v/eXocAlpq15ZUlG6KmFPQcML3r41M6930jfva67fVCvf8csbjn4OnhA17OOezO 2eW+6fFnu0TN7Tx4zpycPTtq3D0GvNH5qZc314iLNm74tG9Puqcu2njbwEldbckdTTL0r2mvRDY2 R4Gvqzg0bknbng9PnbOATk+k1Tr3jh07HvrHo7+96LJftGr12KP/TEwcMXLUmBEjRo1ozmXkyJHD hw9nPWrUKDYSEhJ4Gru33XYb3dHll18eExOzbx/yuyxN9YYLapDDXNLeymhuPcgOU5WkhyIDYek3 Q9I2z9p+EFUudeN2a9oG+nZH0ZHoRcUFh49ienopY93I7J3MmmFZWxGX/ql9VT4dEa9Ca26uqHTN z7F8kAaaM500B7meng1NcGLGtlFrtiesk1EbpBZR8beSYp13UK/RtMhbnSn9pWnvif9AzXyUlJR0 Y8+bQY3LrrjcGmsZEZ8wSqowQVfj8JGJFFpt5PARzybGjxkeT33GjxpFSRg5auSIxNHDE0cMHzN8 BGXU8JGc5GK9jFIHdYsbp0aOiKdwDVd6rh8xcvQo18iRCSOlmTp2aMeb/OmG615/7cXqqmOwEpX5 C7+7e5jmMCEF7mlFn9LlYvkRH4FHy6A3JuwWxweBTCEJOCyWtRk4582ik7tr3ff1HbowZyt8Mb2g IvVLCT9YlFKCYe7TvZXzSyoedEzZdty9/ZB78kfJ++rcc3P29fxX4rZDEoqw/FOp/2dn5dIcmbvc c3P3YnucNHfNgGdngubLC79akrqZaWXenLp42xHxIS4tPfT6yt0RcQsxWzHoTwaMKzOaHm8O3nHQ h5lqnXg9MhkhIoOtTKkR1hW/v8MS88ybcA3fK4vuQVD4jH19tGV9gdeAbnaj9dXO5s2fXxPYu7N5 YQfiA215Et2nBPum9dIQoTXl0TfW0s9EmV/q0v8Vom3Dhn70wNi8bv2nRz4ydsDot6DefuNW9ug/ Jfzpl/OPurN31v+53/huMQsC+707M+czjORYq8KGzOjjmLaD2J5qN6rBO/NLevV/MyxupcSWNAU1 eHnkJeCvrS0fUfD6bg/NXUQoSEPEIJ++bftnfR95uHNIMNucau5FGV7kId4Nto8ePXrddddZLBbw wnucXrOpFipQAwe0Rg1G8+l0hYTgSt7aTypiy78elr519taD2Ogy1n/GmAvbhsOx2d8MW1hUfOwE 7fJ8SvHwzJ2JJcy1dNxV+FV81qao2Uvmrd9Kx0h3NH/TvvgZy/efdFfU109YvuL1jJyxSXmuxYWj Uz5LzGYGEDwplWQpATVkICFjxn8Uajy7bj/zazDKz2uhkrrCpJaa0rV7t6iBQ9kxrEOSbRZ5R5lL 9EWgjIy+kXbEnCKtSbyHFPFKcJyCvKCKses5KCfUwo/U7xquZxYNMYqdrK/LzMxEJXz51Zcqq49V V1GLNVioDte7W3W8vadlTohlBdYn6FPF7Bmo4XEu5/k4DTGe3IC4HgJsq/xi57+Se2JXrfvex6NX 5G4s2lMb8K/RT45fjiZosozcv+/gjPeX9Oo78qmRM+Gm7bv3LVid/22d+/NKd5/H7HsO1C/N/CTi sZERT463v74Qs+FtT7/Y9X5LxQn3hwtXfpD5iej4pXvyC7bXHHMvWpKxILN4x0l3n6fG3D50Smjs Qh/GcVgLfa0kGMlDG1LZfhhCjhcjP5AJMQkDdmV1TMzuGJcabs0ENS6/ZVjiq9OkDhEzDUmzUQV5 6q7l/4VbA3CNl4PUltrf+/W3vwu4LdI8H18AsXnE79HlKnmpCbI917eNXj546qbDJ9zO0bO6m+f4 2hd3iHr/ve3uT466E16YllxQhtmq7wsZkdGL/J+cnHfcnfKZ+8b+L4WbFvtFzZqxdtunoMaQSV2i PwodNOOxl1bSlXH91GWld0RNCoxbKoGFTUENLpZwd0YOymywy66NuHdJUobuF0SUVcPHVMdzcuum 9YcOVwhfNP+iSQsblLbMV1ZW7tmz59tvv9VWKX1W3srdZF1D/AgSuUTolMj5oIZkQScxyIaj1i3H Ykq+Gpb0yQdbDmNqSC/9fFTmNkvJAXSNofOKSo+K+vBC8sZns796tuiwNeXzcdmfj1hVNDK5zPJx 8pvpBfRCxd/WJ7wxg7Fe35ysjJ+/wJVRbC3YYSva5yj4dsR6kuUyA5RMusHTjfy6Kh97Uy1UIwu/ 6jZsBN5wWkf38Pg1AAbdvRfmFKiuvyGGSndjUltcRGBVrczZiH0UWV31/gpHNLSIMZ56BWukyA8N yGlocly8nOJWHjSSVuAqNZjPXV5efvw4gR68mVhgT1azLVLNr/1u7z5sSrBllSJOyTclGyq1jhc1 yM5xQ2wGo/OCEwuY7A9do0P0vNeL3Zuq3A/0c6TklJfsqo4cPOnx17LAaKf9mW+/PT5ncUbPx561 v5XCI5Ykpb0zN/m199LHTFvd5/8cuw/UzFlR2GXI692ip9jeWk7r3DR48o1PvfTFwdoPlqz6uGT3 5+iAc5Jmv580Y1ZSjOvV97PKtrndt/d/8aYBU8JMS32sqTojHP4LXBuSWdTFWFpBjQCbTK7RmmxC CfkE9DJKF9688taoF6d8KDWjqlk3h2oSOdKyXOg1ACfCTDS7SF+NF9JrXO13M/NXkntKMt4wY7hC jSb10sIj5tWPTCjHuGR6MTkgZn4b5gR0rHjsneLPVf+Pa+PDtd8ED/ogjMGqAz5ccdC94kt316Hv BJpW+MV9/NbafWVu9y2OBaExS4PRLAbNts/JB0eeX7jpxmEzAywr0Zqb9D5crL0zqE6R1sV/CL8r t3g9I1PUt0unRL8tHQTiqB63Ioja7Is88dSl0VxRdEkMRqBTEp94Uy1UQIaOWdJppoCMeEKnJBnU 0djSQ871h2zpn7+/+Yh4w0t2jcn6zFZyyJT7TdSi4uKKWnqeVzM2j8n6IiH7K/uabcX17oXbKkwz l8dMX/RqSiH2k/z9NaMmzTlaXf11TbV94Spn8U7bpuOmT2ot6447SSSyvkIGpCvUIHRKpvlTU2+A WWcOHDqGCl3jhSmzqQF0CmWkkv5JOnwOSaOpPdWzS+t5BB91EYHUghXSnAaF818qs+EydQt1F7mR KnJTrpHFc8i7J8fqa0XdUFqMuoSLa07WqLHSBOC53Tf0+HtE/1fD7MkyNFv6YVBDDdAWC5WRApcR ExAhxh94RDpt25oOwxa8mF+/1e2+7f8cSfnb1+52+z/99lOTShCTHMMnbNtfs+Fbt+mNtOhXkvbW ujftPT5k9JRxc7KxWfV82Lmzwj1lxfrQIZPDYudEv52yze2OGDorsO9rm791z1iRHT87Y4fb/UHa luiEiYtTd0yaXzS74HOODHwpaeT8vWGWlYz1ACNU3kJxiKt81GTNzQc1fM0yvwZZfSiEAQeRzyF2 we97DZ0+b7l3xltBXCpKFk+96b2W9YVZA7QyTGSM7DNa3vOl1wbeGjxkmo89BdcGo0cZEOSRlM64 r8aK68ogPiSg34fBgxbRad8gga/Jfog3/WcGDpwRNGBqYNSHAQQTxqZwmU/0QpDFL3oRuQ46xqwM jPo4aNi8NkOWkCeB4s9ApyELwoctCIxa4hezIjAhu53Knd4k4BAWFptbRoTpoyv9en1dcVSyT0Hu tYY0qgT+mtqaSs0KDXJn82xR2QZUqWpXErXRABosPK0hYvG4SdObFnkrUy9JwkB6b4oXNThoI5dI 8YHopE9nb61ErVi24evEjM8Ty4+5ig8OW1hQfLSK4X4vZq9LyNriKtofs3JrSY1oHwfq3Z/uP4oJ HS8GIztGzV5BJ4mRavTytbacPXHFVZaNbmtxlbP8BPnVSX4lpjDJmk4+Q5V3XSarbRpqjCs/SEYR b+St7pe0cCvkCv0qC5V3vAan5CznREeoFguVSlArVM71MnNrtdYsOK6aVLQJlUMGu5MUEaFRPfRN kCfYU9u6/VVz8FR5jlyjQIS0yer2SB31bN14/wDfBxKD7WvaO9d6kgoKaqgiqIH+DhFKUWFUGIg6 mpICrUkvFLrX1bv/EvXqzLz96QfcPv0mP/pW0edu95MjZj27sGyLGu70+opdlumZ29U29tvJ2RVd n3h54zHi1vYSWxUQt2DQuxvWud2R1mUBA2aWHndPTPo0bMCr08rrdqhWo+Ec72T3cc4oYWZzt7vI 7Q6zriEDiU51KwzOGCuGdUjuIElvSBgYqMHI8RvIjhuP6pHEpCGXhP8zvaDUXXdCqV0Kt6VeUMm+ I3uq2mpZXWg1QNcIP0m+Si2MCSdq6aveHXnHv9o/+qKfLYkMaW0Zwdp0XQO55QbTar/4bNyC/nYy ZxZ0GLGujVkSbJItp/Wwlb62NFJLIf/7ufKDE3LaxqxgdBKDWFXEeJZvbIavmVOStxPfigySRfiJ zfaxFtD5Sza2+GzhxDM2UvErIkMYe4JNIGLYzEs79dRfTS1QDyCFspAbNSAdwtltbuBDrGTwnieI lG2NI5iteJeRr739Y1FDctiiZQAcGkfsdOxFh8zpu2d9Ib3Hh9sqrFm7GGFhKdgfs3pDRrV7Mxaq kk9dhZ8NZ96ltC9ezPy87JiYB3F/AygrdlbELylIWJhDpOinNe7RGdudRRWm0rqYkrrhm9zch0S7 cZsOkr0kivHgJE4X1DAefebAoSNvsVCha0inXYdLQvolumu0DmkdaT/pw1UBfxVcGK2maFvpGlzJ z1SPxg+0mMRPvAvbHGe4IOKTbOi7SfPrGzfQgR6qz+TgxxXWyCVqWHqNoXooj8njMSNuuGNIiHU1 uTclGaBH19CoAVNQIEKGfmMsbW/JxCEeOjxfMudELwofNici6t2wQdMIpmXuvKDo+RGDZnQdPC00 anoX03s9Br9LCRo8tVO/N282zyHxTkj/GV2Hvt9j8IzIwXOwifnErfQdusB/6DyfoYsZ5dF54PTI IVNCY+YEDpnVdciM2+LmhD8xoWf0rOAhUwIGT+lp/div/6xO0ctlxIckSJc8tzCgykmFfiRHGEtC 9qoOrqIbnAVt7LnM6XmTZe4vOtz25QGCxcgiAirTGnqBVKm6luWCrwE4C+Hoe1ADaau/9dk/3OUI tK6AyMl4+SOcCPTngcMLoLr2phV01NwH33p7ojXs+YHiKBHpS42hkFwlHWOWd06UBGvAAWjC+FZ8 ECThQceRa5wFJEIELzpZJCDQN7GonSU5IN7Q988QOAzUsOcwfsrv/14Kvu0fUDmdiaAGkecniQaS 4QC61Y0cEc1MAtIZSlcny3c2vG+izwIlz7w55cehhgzuWy+ogYsBB4eoHiWHh288CUYMS9nqytzo zNliLt5v+6SGLLjRefuikrcMS94Yl7MzvuwgqXGdxYddOV9FLVpnWVRkWVxoWlpsT9kyYu3XlvRt 5hXFljXrTWv3xJUdJmjKuqnWVHyYiCkCfWM2VaBr4BNnmKGjVNJhKa9Kk/NQMcqP8RqqEqQTF9VM AXrVSVQJDe0N/ZU+pS6mbQ0LlT6oalkd1LjQ6Ci3VRqJoIbSO8RjfgpqyI81uPAC3Bbokd5S9Zjy VmwLfPH7Wvcrk2Zdf2vfzo7Vra16liXDQiV4YSQtF7InpS0SkTJSMVJPEuYE2lJ9Y1cCN/yW5IfM ZyH9duxq8k77MS4vdnlQzKrQ2JWRrmRc7SGWVf7Ry8IZ7mdO4XiwKZmB3pKxzZyG8sLocp+hSyMd KZIO1LbKN255kGlFSOxS4tXDohcEWxYExH0cbl4iGa1jVmN6EgsVXj+Zj4BMhsacHUBJIGqRNYPk pWQducFeGOxIZZTHNWF38v0Kf/HpaKRWtSFV1rJc8DXAAA1hAXpO3X+qVocQpB99Zercq3sNCbcs YtbUjiqxMx34GfbP3stwpUGTHRnlGi9jzCWdWnxpR+ta0t6SFJ0UN+3BCJ1QFxXDyqi9LPQOVGZo lUxroAy3IooDOQd931dllu6I9iFzGWf52Mnw3DRdg98CTJ0tS6+709Y3ZhT51vh29dUSXSNOUboA leWDgwi0Z4ECvGDBc1l4Ikf0hnettY8f5dcQL4ZGDaVlyFQaFCR/nOOkw7WXfWsq+sy2YS9pRoaR rqq8ylRWFbvuGLASV1Th3HiCYl5XYSk+JHmr8vba1u6nsG0u+pa86PayQ9FF+2LXq5nENx6LLa1w bDpOunXuJoNEDG94taNUCt6Npo4N15G3eryGjpWSBkLG1TSqOmrxdygpV0xJRmtyAoqmCCXrov5/ H2pwQi7hJ9xYUEN+6PlVw4a6oUCGBz70qTqV0oRfatTg4Kq0vN9H3NPZuljZoMQMpdnhVNQQdQNd g0zpwYlryQoV6MzFDBvgyofy8XRA3mQLaWcr9o9f29GSKR07o8gdmIwyGKAdQKJaczoZCOnqyQUd 6FjrzxyX5iwyc3ZCoMILaUkLdWaLXVdmBpe8tdwBUAgBF0yrg+NTA11ryJTF+AvymcB0ymspqEGB T/VMT6CGnjFQ0pI417aPLwu2pQQ8OKLbXY8J12AAVHBJ1WlVS1WkVGbLckHXADwl8hjN3Qg1+GLh tdKte34ddH8P6zwGhPolFGBHgsi9cHDGG/jXcojlo8A1AgF25hErhDhlNmRy+8uMMIheYjsSJULS 4IhjjiNt4nHMEQEIMXO2kKmauBWykFZSuNLLj2f4MvIm9lwe2s0878puj8+YnwrxS5CNtDH/VF+h 2vv8pP8mz8ok3vAG1BBPdDmZ0om8ZUP34cRTVcRt2h/zyQEOqnlgmXGJUqNc2PJbDToYuPSUfAww NzDImKdJJnsVdNjA1EvMCUuROZgaj84QpCiXEFxKk4ZsYKHSqKGzF6ruWqGqgQPqgDSVdPiq3bwJ JwF+lGj8U54ZrlUr07+peCeFMvpHrLkDZwW8ySiFJdC4m0A2x6EPWQSD6uoNPVTtGnfk52JTVIdk u9Z9vKrut+26RcR9AG0z+lsGOjHzBXNeiGFKnHF+zAvDtkfgETlfifq661anZHS2omooX+bs46Cm fDVZUqqfg9HccoHMfMGYbnzuKsGgzNMkcznJzTWb8FDtp+BKw1YGD0q2B7EDw4YKMozrv4Ma2ARI NiLAxMu7Ctrai0Mtq1vf+nTCuAlKnFI1INq6BJWdnyyjqaJl/V+tAdqdrlJaHDKgGE3Pv3o3vq4r Q+8O7/dmhHMNUeWkzWxqL607c4UaQrqaTSBvcbTZM9DHg6xM7SrUKxghKTeLlHgjw4s40jo+C+CA aAEO4Q4PLwi/CMfJfZr8Ss7cEEdyz9iZl/j/bcsuclDJV6vZl6gKgwvU1/9Xq/m/dLMfhxp08qrP F080cbAyxG+joAa4IEc2oBRgSjoiqMGMGAI0rAU7MGfpkCd+bugOG2WeDqVByBAMsXep2QC5LU8B MujnQQ098Z+6lVzGTQALjVbNjRrUND4G5f4gcrladDTUyUqRB06e1H27oIOyMil8IAtZJYKTtBDp EKXpRW3R/guhDE4BCtwDNUT9QLel2taEon7LsBByJct9lL4T0ftfnR4ZL6GAVtLPknIQtYL0s9ng BVMsqVmWTkMNrxSkHB907BomkKaUvMT1MmZQ+nmZK9yYW1bxBZ5rie/lMpkfmWHdoizoDCGs9cQZ wkFcI9KXEsDUrgYjiagXVmW2MjU1OT+BZzV/tTOTZZGsvGmS+dZa0MW68g/hd69KyzH6CvW9Daih qkJXUMv6gq0BaXQhdf43QIb+WiVX3fGYpcPdjrCYjwPJ7S9p0g1dW8PBmawVBTZIMpC9yE7M/ary aqrZwJXuYBwXFOAa8q1Bw61d+TfE50PeyEUdXUmdnKtF77ByBL7QhN3E91ECGOP7Oj8xvnXX+0XB VozusS0YXE9VUKRSROw8j5YfjRoKKZjdVUBBawoaNbQmYmgTMiTQ43RQ2oEYlNQErxwXP8UnB+I2 HWADrJGZO9YRx2sggnZwKxxhEigpxrYYwdSuWMkYwaH1lDMNo/oRuoYOgBKq9radELluTaUwGJvS 1ierauQqaWQJb/ZcJXnX2VbGwjrsMGxrkjBc8EIRonoYt/Wwj9AMsAN8nKyOG/XydbcPJdwoxC45 DDVqSI4Fl5pxwDPOCFKnePhI684Na6UF5KCYt5cpkkVnh/gpIjIJJctvQRbRaERlkChfuUy5TrTm zp25CTwoiKCmeRUMEuDghmLmlVPqBQAUNpQigwojGKSYHRUpDxMZEwgGOJlqM4uMDdf43XTseCUf S7XoGiCKQOpRqkyqpmW58GuAtlZkLzTQeIH4a9yzlmReHfmP7nFzI1wEB6bhufNQuJfU/8OGQbFi ZRIiF73DKUXIWIBDiiHqCCSJqs6VKhVDlp4pRlDDmdrJtdzXmRRoYeQRQSk/EjV4EPNddrEsaPOX QcOGvypdwUmxzsm3G//kv+4i1BHFC42r5Zxu/1jUQImQLCIaNQyjk9ImQA01154MAFQIIiigtAMx TImuUYapipS51aJibJJgWlLmooyAGsotQv8vWCAaRINdS2KlPIVttSuDNch/BeKIynOG5UeghrKU iLeOkR0CHdKsGKUq0alxQOCTEKdFrYpS0y0uyfEFOZSFSn5dfVJFZ6mGxl0iRi2lZug8t0Zv6UUN 1U9qmgFI9NMBl9wN2y8NuevGYdPIzEymKZlEwy7ubzXhhUzqqvlI9/x6m47a01drJVqPq83xtUlC WlEikLWshRQ2YArFKYaZFybCiot2IHeQISEZAgp2xnobg3NFtbemYxPmApl6SWBI3RPmMlBDeFNQ QxJSed9EbF+S0d2RHmBd09mc1PbeUb0f7Md3fgc1JCsPtdCCGue0fzh7D9e8w1oWxT66F1Xrb47U XR3cWyYLiCXxctOmW/XwhUhBMlwIkclRKEAQn4PpSXIUKMkfKhVAgeZtODVginx/a54/sbjMGy44 IkHjIko5xAMSZM4LMudroMGWRVHX/Afk0m/CGsGMuWW7xb13WWCfok2fSzAO/YcXGVQlsIL9YQqp DYnbPI844UehhqgP5J5SmdJF1xC/A5J/eTVYoDFCaQ1GV0+kE7vOsiOO8oPqSmbHkCuV50K86h5Y kUAs7FoxmyTClm0GZRBhSwGbABFtEyOAiqJUGEENAY6mDNn4MaiBn47REzScDLnQgGCEfNDWNOdR wxyljFjSuLg/qozhHpCDCp0VgBCEqanGlKWIgR/q4kENfoh8bZAOD+K4Z8i6/ITh22263NXjyXGM pCaiCQMvrg0UDQ0N4rNWmoIQtookRIii06ZoWlWaAhcrnUJZrtq4cihwBzTfxpVH4UoV0J4q/kGr AArsI3ykfkVv3xHUsGHyxYcoyrvW6wURlF1X4IOARslnK/qI1t/5ub6DPFrQRMGHk2RZmVjbbjIv uKLzox8sS2F8ilEPBstQYR7NSxinZbnAa0A4y/hEGEE4RbOADkqBNu590vqnv5rDTQuYOKbJc/kp 1gA1tIMbIQejk+gaMoxI5CUNHIpWhR0oooN7PINC7VaK+MchYC4DMgAOmAWhSOFF01AD3Am1r/J7 /OX23e/jUwUR1Ahf6V9Y1JoV/QMfrv5z1U8eNejntVVK9eeVuKqVt1q82HTvnJWY2HUgiOgXOuuI uCfWH+QyQzVQBivt8kCJIPKK4/gpGI4hqLGRyV5Jk6hRo0YQRLnOxRuiJhBUDzKea9zwzNSNJqMG jScO66rStfkh/sG/+tVl8+ctOXH4YN9/3ntk/+7Zs94NiujpG9ojxuQ8XHEcvWDI4P5bPyn5x4N9 unQO7Pt/j27fsWv6jPfat/O5+eZb77r3nsCwoPsfuKdgbX5w565h3W7929+f+PSzb2AP1WEq1BBs Ekrhz6AZRUIQDTHczucmXN/z0e7WJYEuiWXCLyBThEtERx6BJULz2knhyWpooIbqrtmGO0TLVio5 vbpCDdWl2/MRvUANDoIX2u4keGEtUryTo7we6cIdZCO0aeAQ/V2JZ4Y9it/ydIVNhjLyHdTguVwA cCikI14xJ9Kxpku/N68I6HOgUnQvqWnhERZ2G6GG56g+17K+8GqAFobghe5lgfCNsRvqCHKU/F+S Xnxx+KNdzB8H2pgL7EyleiWoyMUi86BZS+ATLm9xaijdQUhanRLg0IgAJaNZ62t0HAi/Uqo398EY q33lIjjBF3g6hK2Usdf7rP+4AYsxePayXtHDX5upqBu5s5KNxpTOtgc1OEuF/LRRQ7uk6efp7aVv R/LHoLSBibyriZhSCgjGpRqKcnnLIAuMUeoahnVL+kFQgK4eQxOA4jE3ia1Jx0RxCqzxeECAIX1/ uaBBVeHmglBNC6BCRWoyaijdobbycK+e3Rd+tGDdui1vTJhUeeTgH//3Nwf37hj//LNjX3ozv/TT W/5813PjXiRFZM+buh44uOuP1/wma/XcRIepa6+7t+46uGP9uvenTbr7safzNn362aelJXkpfe57 ZN22A/aEVwKDb2JacMhDEQzSNeqGSB/wiaaZqhMyGFNwi3kPd+y9KuD24MGzguKzoWRm7obORdfQ Nh9lidW6hqJ8Ub21hO/dpVfneg0NnBJqV7FSoiMw06v2XJNsEEawF6FZgETCMvbVfo7VsJsHODSj aTVH1Ap+qNlKYxPoIAii7cZsKwkNVuJKCs9tC+TZsiNtK6+/bcgjUSP5NKx2fCaL4h1BDTU0xtjX p1rWF2oN0OgQvMIIWhwuoJ+U6HMp7MIKdVX0qu169fV59CVJ9OGQ+Sy0EALJNSqaJkUjEHoTwlOQ ITAhlK/lH80UYoBSBitlhtVaufqVREZhdxWvB5IV+ojy9ImvnDuoGSpL4Bp5OpepKQC4UthQ6/VK MTfUc3k3QxNX9G+8M8AXNuTd3wbdu+eo4nsJs0RM+i5q8PnqtOIFD4OcDzTw7IRJvaISXli785ni vSNL9o8uPjCadck+iuyW7B9TLEV213FQjuiDY4v2UbhmxLr9I0r3Sll3IHHdgRHr9lFGlhyksJFY tieh/MuE8j2yXbo/vuxAQqlcww2fKdo/du1+1oTCjin5cvQ6rjnAr3jcM8WcPTCGl5H34dF7Rq/7 ckzJnmeKKfvUcX1/brVfvad+t/+8Hlu859WC7bcOtL046V1V/3RW0l/pJpM2MhrPOC5yb80JsL73 LT3Hjh6DHoDF6XjFt+3/dPVXX2x+btzoj5esotNzJjz75FMDU9OyLDbz4cN7O7W54uhXm1JWLLj0 +kAJqqs+uCEv9bFoF+m53DUHS7NXDI5LYCD0yvSyP17vh7PPY9JUBkxhE4OJZHSP2LhkBCDAwVCg ux83//HuxADTUvR0iaFyMPsq/uVcnOOaj9RaOmfoFu7QDKK6a4kS1BgBECDtqAsM1NDCkkYcdASJ tsVV4SgU6YuLHV7UEHFLuEx5yZVmIfYr7g9qoMXDGvCOfhOta2hWgne4lb4/2YR4K5ArctgHlwfe WbDpM8FH9dWe6qfyG6EGR1uWC7oGYBGNEfKV+AS1nVbp4EBInUjax0jLNnXemqu7PdY5Zp7MZW9h qJGE4LaxZncgB4gzUybgYKgF/jXtfUPgEesrnbkaCdu4S1dQIlRqyDMGuGiIgZ6lKEqGeoWAFYXr s5qDNCrpK7kA9mnEC5IMAUARVyC4Yytsg1HXVUy0fIAl09+MeS2ns33ln255PHb4Czr3FB9NTL5U gnRFpy/evuj0U81+hM5HD/HjSTKSQC3jJ0y8xCf09sH2PjHDbxuWeEfsyFsGO/9qHnXbsHh2KbdH SVG7xhHPwfjbo7xH2JDtP8tPjG318/g/R1OcrDnOWV30NfrOah1/+zCnvkOjm+vnem/o5HGeIi92 apGne+7w77Z7D7U/OMxyyXVtJr4zjSrQRQcyGTUitXNqoT3ra3ZuXufT5tqrrrpu27a9xw4db/OH 3+/ZteXNiS+3+tVvWv3PxZde+rvysi2OEc+tXJN64tC+gOv/99JWrX7zy1azl6eRYNZd/XV5fvIj US6ywbvrjm7OX9Oq1aW/+OXvWv3PFTM/Wgy/NFoMCtGvQHvpJtOwgledzLK/Dvl755hZTL2KX6Ot qdDXtU4lfWI0q8IFxR0KJjRqSE8uRTGConaxRFGM4ypiRPft8BEHNaco2Ulxk7CM6PWN78B91GUi 2hlSnNI4PGwoj+vgSPNLzG5rz2hD5nZlRmO+S6K/GBJOjtBI06Lr7zD1eXiYiJLiCZda9whXLajR iCJ+Bpu66Q1GYEczgUKNSh05Ug8bnThaU39t+N8C+r4Ral7lZ0pn4A8Znhn3x1wtbRwZpKgi4QCi DpEehm9C2WwhRS07eQjewxGaL/4ba80FMAKPECmLaQdFWxHpq+PwsuvNiHYFgc5CokfCnJkMPA+L mv37gFs/3fY5XYv0LgovWFNOWfSh7zlxylXNvSNRPWrhQTprOnrRqJcnMMtG/ItvJL78JlP7DX9l IsmpmE+c9YVXxrw68bkXX5kw8U16KiR7crwQ1EqzGE5obwN420sfQRKuPequOjJ27KvtOoQdrzjR /ro/7v/ys+fGjnp75uy9eDSg8JN1kTf1OVBRXX3wQMC1/1uen9ajR7e40c8zSQY5GotyVz0RNwb9 wl13aGPO8r5PDdtV4f6mUuxOp6KGfl7DmubSO3qDKe/D736q49+dXRxkI09DhmlvLZTx2irMCUJF vKE/9+KChoPm5JeGHLxaeNPQI6zqTAc40DjIiC7CmBpaC6zA3f7OFMY3XRV63+rsUhkLo5K6UA/f gxoNNdGydSHXQEPXKFvCjvyHHhAqJHKxDreexEtMX5T5y8CHIk0foWuT+pIoXJRcSA4HH0oHZKb6 be31ltg/GXyqIqAM7eC/gRHfx03K5afMVsoJInkRAZE2zsLWtpyAxBISHvpZM/3tyf6WJZH2RZf2 HGAa84b+ZL3WYqHoG42Xxlc0Pn4Wt739j1eCBTh4L9qCflNEPmUX0Bv/Zo2p5Kdb+C7dNRmNpYej ooR9B+e97aWuZ56Lt8aOOHlgf0Hxlv+9tuO3X+/pcO2V+3duHz/u+VkLVxHd5K4/vnfnlj73PCLZ 9w4f7vC7y/Z9vXvvt9/+6tJr0rKyQY38gjV9o58VvaNu7+aCJU8OcqB3YM2skuy4/27xTokioz8Y HMiceus2XxZ4R5ehM4LMq9pbU4m5JbsavjktUynUMDTuBn2huZhFHqrtTspRLoO+vYoJXm+0jPbx 2R3jc3RaRaa8xAnOMI1wy8Jr7xh2e18LhCQVTxchprhGqCH9BmjSsvwMa0A1vUINby/krpEgRgbY wjLhdw9qfV88MUhtTGsC7BnBxIRYSLAsYomSlySuSVzVaM2MMxIVG3ZoWozT9+HCv9dQiCpRwVcq HMWw9KpxTACZzvDjY04le1ukY4Ff33G/7/bg3mN1lVWGL8Pb2XzXQuU9wcY5WgALL3B40xiywUHd NXGB97g2jPzQm+qP+Imu0S+gS51Jkk9A6dAWqlM+lhO6SFcmBpNnbOaLmEC31aVTZs2rrT7W+veX 7vt8x/PPjf9oWQpiEHbX6VPeeHXiTJKFHPtmn+/11+zdy3zd7rnzljKF4oljewrWpj8eNUIc2/UH SnMW9x9qRwfRioauxlOernZ0E0hmRY+6wWGdg7dv9PBrbh7Y3baA1E8+iXky6YYKcNVyvrIdwUEw iy7/nuD/v86i1CgmzYJr4E21K5kZQBOsUmI0cOUybl3ljhPO9cWd4VwZ+MSrl4TcVfzZASIBvGjh qW9lnlA7niOn103LkQu1BlTrKxMVra9R44S2/iPgnWT6NHd2+fb/8bktLHpOsDM5yLEmwCH503yt uWSvpbuWIjYiPdBbe6L/vyj8TBBElB01flDQSnGi91c+jgJGJ7UxpwYlZnV2rLrRPPvikL++Mms+ 8pImb4Z66Q01BPj7mvWcsoHufLyyayNckJby5PHTPAszNzTfBbZNI4AarDVYsE1T6VyO320zOQPW 0sIM2aiDiKur5PLKo0dUpAdVKBZ5CjerrDwuRM5PJAKkCoMVkgPKtSTHYJQGiAy0iGIhfl7+cSXc QLcpD/m+pTFYNGzLDeq//Pro74NuiXjqmRDmU7ZntsYtOKKUflsNShJfnnLP6UBcEbq8NNwcG5pl NHzIcA8JYhdXe1uS9rgK8NcDGYGuLH9XZmsSjdpSusXO+n2Px+LGTRYMZWGCMFUFrNR/TYGyw65G FX1hy/pCrgHV9o27Gt368IjwF8aQSjVmSoUYWsa/fUn3p5kWNsy2wseSRNLawPgCemw1qkJCAZXC i5YhkowSorxevObiBQOw9DhBkdZURCJvgsMd8YlAROeaLua5V9309J1PRCMuYm7jAzFJaduUykD1 A83LdUbl/MAFZ+WwFzjoKlmqqhCWa5Txg26Pvq5KjayRIxI2f4GtlUWIrt8LGUKcaojE99S9NBad GB08CadkkebzFnWKs2q4t9A22aeUjqlHBcqVOp+S/gnbVZIdQWGWmtdDHv09T2045AULmsxoNQ3m 9e5pHy64MvQv3c2z4JoOI4qvMSPkCGow8g5BS6MGlEwf3syoYaj/PFTGBqoCz4Ia7fCYu4qYmAB2 DnQyx81q7MyIWx3usfnd8uC+E5LkU4GvSgjpqVdd4dqyTeVQpBFalp9NDagYbE3l0vS6X9UcBLUQ 0FhTe4J41aC/Ps6gv8i4BcwFGZSIcy0T30GAnWEUIixpmtdrrXo3h7x0yj115JVai1lMWW6hfHL+ kICdYYmh1pWBD4+5NuKuXfuPaw/48RNVeoO2VXM1SCTVedjO0u+pRXWBMmETe6oXZIuOVNvZ+BSJ hNTHL7i1hwCluxfjD8u/byzVXVNRWl1G8yAWVxvdyVh7oq4Ot4aqMU//pnQT9AvZp551b68tSwBH ZZ0enyE6C6kQ/z2R8HNe7zvXcGcNX/c/FXXVzX27OD5uTSbAERsQq/AM6vHayqMh2TzoxtECTiHv /6rqIdEjMrIDj4YE0+qM07CMNiaTa72DSZyVGKaYkTbEudLnydcu8r21dLuY76TapSpRwiQmwQMQ 6qBoZKfU6ncqoWX3wqsB1dUIexqLZ0uzEnyg7CEQBgp/7fqd+64M+WvoE69FxC0mzz8zkQUllnWw iHJhULunGz8L3j2tzkjgh47XUpG6Grw4JfNo2FMih0y/xK83YxU1zwvtG32vARmqK/J8s6cOzvl/ 3Tc2XvNK0i/p/lN9gsY+jvBN3o+68Da8igY1oLvl0zvnxu2l3D2CGpKqVlWH6ss5gq4p/Rt2KKVl cJIqVN0dlA3UiJ/XgGaOghonRd0QX5JoKt6abfwwz7b3lbwburGgOgH/eveBo9XX9/hb+4dcYY6V jN2ASkVJV+l0VKcNauiB3s2OGoQ7ytMxJqswdeEUFA1zDqhBmHpgfJ6/OTXcvrJzzIyLIh96cdpc tAyDvGrF+lej0ok0oIYy4kltqxry1EfL/wu5BryMQ6PLYrAGhCIc14hRYDo4jlxv7g9WZV4a0Lvr 0xO6WJI7mXLa2daS5Bz1tp0128eZ2dGe1s6WKrk9MVKZhSCbU3bKwYV3PZNUDscpn0GaOCxmDGWV GQNtOZ2dqZED374i5J4Rr7wLuXvoXH/nT3ytW+vnsG5iQ2mKhVC19KtrSHBVaR/Gruci9d9wdsgp CRpsTPZAB2FWkv9WOMEQtpvwQvxI2EYhDuSXv+mzy4Nv83nkuTDzQh9rsg9+BDsTHxPpJxK+jzO7 A934f1W5OO1ueT6EzVsZZpjP05n1jKJew4gq4X0wlDH9X3fT+1f2eORfMSMAWqk9vkRqga9hFHCj GpOKpUuQnoEL5JKW5UKvAVpZ0YCIW8bClhToRCgETIHaddGsxxF64DfnLL7Yt0+XftMj8KYRfOtU UybFS5bm9swy5sok9whyC8F7zY0anRLXMjrjBmsW40dw5HUwZzB9DAzIJBrdYt7/Vce/9LOMEcgQ 76h8yE9+MRpIN9PPYN3EBtNSkP6RrioPZNC/eRe2ZZcLNG2z4SH7U1AD9UQlWVJnNWqoH3pv9O83 uC0sJI9QVjJ2V+WWXeR/W1i/Vzo7l3W0pOJHQE8nFlfG09llIgwl+TeXExAQ4UHMlcmIV8SqTszr 6si9wZwJlOAHl0FYyFr2lJut81r53HXLPwYdNrz/sI6uMTqK/9fetUBHVZxh2nqA8hBMoYq1gYS8 NvtmISQkYIAYYg2WKCpCD4SQgmAeu3t3N5tQrdbC6aGxWm0pogKHisEQCIEIeS0h5EGIUNt6qkdO PXraU2pPtVqBmEdN+n0zd2+i0gJijiTcyWTuvXNn58789/vnn7nzzz9sECQrkWiI52crthX/nxT6 3SFDAbx3yTWSiVgvRNEDDOg/oKPBroXEhAAJk0BzFTG+jb/++pSUmWu3xeRg3St2oucOSlARiS5s jC1sinAHsH8xelCf6+18yTHfxcqR9TTCE+rGxuKtsEQNq9RmV1VC7vbRlvRluYUQGRxii5p2DQFs qy9Ie1ND/YSIu3SHxg3YZC9IwFVesvMTzIIxQrIwAmmQGiwgAM804lfiIM5gdAr4V5OqXSktK0Zf 1KEoyKmrE6ba8RWMvZed+6uHTbLEZv4Cc83Y9ZUT0P42fM4Nhcp6EXVIBo5lwI/YRpaL02Fxmpsv N4UXtGKJbqiHm27gu5nJXZPg3D3OvnjytPkfQAtGrR6JJjxjPis1KDgk4ZDs8ohzUerpCa5CCkgM kGv4uvu/cSE1aFGELCYRI5IFGUosNPvJr3ZeF5lizd5qdr8c468P9+PzVD23IXbTerOxqDncg7V+ A8gFyBwdJxj2wYw8P4j5WmBf1JhXmZi3a5zt++lCaQrFZgcJs8dUoURVBruTb+raCS/rfalkUZsx QpofT9RLHATOg3fZ2gWlBjvM8pKpkIwHdaAtI9jsXz5+mCd2ocUPMUmCIQdWnvT2ljec+tqNMw3L nzTn7cPkoNHfgq03sOJvsg+7xA4gv0BqQGRglTo2Jee+5K4jnGGB1FD4XJMvEJdXEhK/wp5yz9kO KqZ3dwo9W5KCbQCO8GAo6YUsDooMppH0Qai7oUwBiQG+cPWNa3gAPsBHNGYIoARBIkhBKUK8oBMF ZtiwZduI2ORpq4ptrgqDUhel1EIxgyfuAOc4MOgYYKkR4Wb3yeRvtOKbWF6tzXk4Kef5UYbULOdD /26HcjlaDaxkRWFFdRj2Cb7B+WpRFzDmNREKWF7J+yKh1Ewu9LL78C/QjktViJAhOMchE6iYCfLI hXL6X3HYiFyIDMgKSA10w3pocQFrH16sPTnCkGJYuiGpcD/MG2IqHM14mDLQ8xpNMEAKP9WNlVYN sPMQ6a4Jd9aai47ZC+psOTtvmrsy+Z7VH8GckCYvQAI6kBG0oUOE8ESggGIwlgngkVJ3Q5wCKij4 ZRJdcQ4rOMBgpdGLANTVvoSajNFECrasEdqJ7EVt3Xvwm4bkyLt/al27e7q/OlapwspxfKTC9DTm 2ga07yTGGifAAnioJb8izl1hWFI8xrDA+cgTkBdwUt51dGFLgE70FbFcUQM9TwahCzIsis827RJD VJSvbbCFfD+ikmrI60t0gHBwiNHvFzIzLTf1EgnYQRKr+QT4Ec9vSWJfJ0AomB4ER7aX1SrKdlUw Eec2OoRJXmpVgcsONr82Yfod45NWzlJ2272VUc5q6C8NdC8LH6Yw58jVTMoxmMOy+OutXmzSt8+8 8unhloyF2Z5zsn5gFlCgj0CgAm6Ie6QOL4PYYyrhcPdy6aP+Uj8MMgpIYIhZDDAFwAyNdoREAv7B M8CCCgsBG3TB5Eo5aLN3tkMdHoKj4dXTEyy3fWfe2hl5u2y+2smuwFT/CVrO9LcOqNRA5pjOw+OA /FsL9k9JzQ2JnldW1YIiyVWKnd1c+Mbyw0tEy/P+4SB7YV+ouKgv3KAL+78m7fyiBGBKVWqwzacT DaCAM2kgs9KOvBQDAZEA4OGvmAF/qUkNNJKY5pDClzcuzSFvaXGRz4XDQTAUmmQ86NW3zlhvXzJ6 WkZ83vMWpSrSTWWqARUckBrsaxW+Iqe/zd5624MlERnrsWXnpi27UCRUGkzNYqLmOEjNKLX0Ui7w ox/uIw5JZCpRN9E+qClFhB4MVQoIYJBrqC7CsQOGz31SQwAhKDjEBcCCPxpmw6XqgCHMnd2e6R5p vTds6S+N7koYJcDn0wjlqDT0wb6Nxg59CzrIIFKsXEC4BJMFf4gcNC9MSWNBH/aE9R22+yqiM38z yrHceOt977x7FoqOKKOKZ1FObA7Oa5QXBVXr2+8kWIuhefx8fQd7zEXfEyuIN82xBl67cKrUkFUn BgR6eVSjxLdMkV6VGhJAMgeR5otJDWm4BplhpAFJ0Qc/cYp46Cmtebh4uGFB6KLHZrgrzEo1vvFi WpDrKdQVfxL2F5Em4KALei7i6+e5sRoWN7kD+CBg89VFZ227eX7+JEd608nXJaGwdl5WXZZWJQ8p BSdZSKUV4mRKcfMzAxOZXg+HNgWAB3oNCWptcS29eo00/Rxuyd/hW60YdGyrOBpiXzh2VrZj3Y44 T4XFXW1wNRsLTmFZB8UHZAQHyMegmgsdXZj7wOq8cH8jNK9wjhAeG9Zg7IxkmBaBTQMRHoNOICa7 o3yvTHW1GAraYgpawl110QVHLe7y5PxnJiUtud6U+tDTuz8Sm4qhUH1OK7920ndPPxvCFJC4FPLh kmrZl14iRYN9fzhd7kBDe7Kap3YtTrAeEPEQb9j47FDjSWNS+nhrujV7s13Zb1UqIT4MYBboyoq9 nLDVOPQDIReo0y55xNXISb0CKrdz0bePVs2hiHWLj9vFYu8bGLDFXgZh3iPgI0yagF8iPAGwHhRX Yl0V8Z7SSWme4dFpOQ8/9f45UUuIWkrbvkYAQqF/9UWpJaEQ0l2wXvKWHuoU0CgAxlGhIg8IgaAg 3tALeb+7d91jzwybOv/bc3NsP3x2ulJldgeMSiDaWWcubIaxAmyFCelAk9FF/H4F7ZGIgsbowmZ0 gTBPF+lpwAgFCy6gwcvVHx7uCRtd1BaJHQAhOPKOxubXWd2HZhRUWnNfnLDAPc44/66s/Lf/+THM M30MzUYUB2t/uRxXwFuHtfbm9JOriQJyCblc+49yAbE4L968Y5Qp7frZayxZTyUqZdNclbHOqkhX fez6NvALlKzAOFOUeqgmQr0cVkPhITjgoUbIHcn9rWH+4/Dhha00e17A7hkWgGNFISyEGJSaWOWw WSm3O1+clF44yrbYsTD7d3/+B1hFKB4LkSGkBiOC44iriWZ6WQYrBaTUANKkB7rUDgfw1t0B2yMY kmNC7fS75zPdG8ea0sbMWRW2fNMMT4nDWxGTe8BedDzSDaP9J8PdJ8JcLVOVVrndAEwrGD2NBsxr C0NSEByQF1j3BF1E9KCmeJsNviaInjjlUHzOrpmrnrx5TiYMm6RmugKnTsuJGHSSUCQwo+DET/WI Biut9XIPXQpgAw5ZOdXOIQYdYJ3e3jMfduY/8iRmGW5wLDEvK05U9jl8NWF5h8I9R7CnXkQR92PF SBz9Ky67UBoinQ2x3hZsrznV1QhTDBiPR3rbpjixwBam4ZqwuYxRqbd4ajBpYnYdgGJtaFreyKjk OYsf3FPbhm9xlA4dWEsiRYY+ghi6gPsqa6a2xrIrwm/Hsq1Gzx5qVcSeDIW5pJ7et947++DPt3xr TsYwY9rEBTn2NZsdebsTfNVm52G755jJVW/2HLP5m0yuIzG5QHWNzRNA58rkqTN662K91bDHbiqo MXoOmZzl05x7rauem5K+fpz93huMKStcPz755tuYf4EH+DGXQflFxxKyMOq3MxmphzoFrkYKdHQA vxxoyMKhw4N+F5D8r/beDZtLJ89aMsK8OCTZZV39nMNVavPut3oPmj2VscrLBk8Vxg7wFt8RLM0z uGpNniNmbwNYCd7uPepQam35ldPz9iW4ymY8sD100aPD41YPi7rjzkxP6+9Pw7oWbQPhSaq8AOey CAjY9ZKl0TlIpYN+uEIKoHWmjiLEhQRYn+BgLx+Tzp09ndhhs+uTLowAmKy9pwdnB5tP3O/0T7TP HmNODkm4N/xOJXbpz2bl/3Zmfqll3e445UC8/5DNXQ4/TTlod5Xb80ri8l9IzN/uyCqOTFdCk1dN sGeExKamLXWWHD7+QSeFRTsXTVFVGCXheJ8HqEuhhEK0BaHPaOGvsOb6z3UKfIkUAGLlHlsyT23E IfRM2HQD2O09vcdf++u6wuKbTCkhltQQx123pDxg/sHGhLwdCb69GLxjXs/iLLV79jg8ZXZ36Qz3 nnhlzyxXSWLujumZj5vu/tHkudnjLd8bb7g1KSPrmT2H3+uUBs/BD2CT7u72swihjo7CyCdKdhas wwT0lB260ylwJRSQUkPuuEEtRIBNerWRFmjk1gQUGUiGcQCRiJRo4SFOjr/xxhM7X1qwPGdyYsZ1 UfNGmhaFJGWNjsscOXPl+Lk5Y+esHZWw5obZ68bPyhptzRgRNW+i+bbUJTkPbdp6tO31Dz/mkhI8 Ds/q6DrPbRQoPSgjxEIMzMhzpNN5/pwGdSkvZHgl1dZ/q1NggCggpzZkKGQHTtlWcw9ZsWICjTow /9rpvzz30oH7HvCHJ2YMj0kZFn3HNxzLxsxePSYpO2Te6onz14ybvWJs/LLr4+4fY1s0PGb+jfa0 uIUrlA1P17b+4b1zmPEDn3AHliCzdPd0tgu5gMdxphKPBK9KdsWl4CAkZvoBqrie7TVDAbTMWicE QKONDjHTQWh1wVoCNjEQrTruYSwAzPEStjzQnSFeVRGDeDFY6P3j238vq2nceTCwtaym+Pm9m57d s6WkZntZYG9N26k3//YhDFWLlMgNXsoLWGoWPSPmge0SPvmPEGEwGCK5gIIDCelkSRCqjmc6CwSp oR+/UgqwsVbVNtRySJEhkI7142i/2R2iGiwV3YldyBAgG4xwHvOGZz6qav3TC5WNW0urH99aunHz LhgU3bE/UB5oPfHGO2fOc8tmqUIvGQdMSyeYSGMl8CM8IhHT3/NhfLqM01lGfUH64YtTAJCSnrhC 0w0v0SWyDIJQAy0RSPjj25U44ZoQaUkTDIFUKjLBQbJIPJJN+LFXPkd0uPhMKpALB14Ser7i6fxc Blkm+IkhE5FHgsVkAegQL7281EOdAl8xBbTpjH4n5KYeDtWJVQ43pLyQOoHofqFTxH4RAC7AzHY/ CHQcecUf0JA1zWrhNp3MhCcYTQhDQOA6sAouNcEhfsVIGS9+qPOLIJ8eXBkFJLRkQy/QBVzJK4QA rACiGFDgWo52GQ9JIAEoEgRTMTnvSk9GUH8eLCNufdZpSbQTNQXzEjmIa3m3H/7lXf07rUot/XAV U4ANuWy9NUaTSGaZiWzgXPMiRmOuYK3IDZqTzBAMcezLjSwjmULwLzmxjws/lYmWm35yrVLgv+PM +ooKZW5kc3RyZWFtCmVuZG9iagozMiAwIG9iago3NzI0NQplbmRvYmoKMzQgMCBvYmoKPDwgL0xl bmd0aCAzNSAwIFIgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCA1MzAgL0hl aWdodCAyOTAgL0NvbG9yU3BhY2UKL0RldmljZUdyYXkgL0ludGVycG9sYXRlIHRydWUgL0JpdHNQ ZXJDb21wb25lbnQgOCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHt0AENAAAAwqD+ qW8ON4hAYcCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCA AQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMG DBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgw YMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMCAAQMGDBgwYMDA88AASPoupwpl bmRzdHJlYW0KZW5kb2JqCjM1IDAgb2JqCjY5NAplbmRvYmoKMzYgMCBvYmoKPDwgL0xlbmd0aCAz NyAwIFIgL04gMyAvQWx0ZXJuYXRlIC9EZXZpY2VSR0IgL0ZpbHRlciAvRmxhdGVEZWNvZGUgPj4K c3RyZWFtCngBhVXfb9tUFD6Jb1KkFj8gWEeHisWvVVNbuRsarcYGSZOl7UoWpenYKiTkOjeJqRsH 2+m2qk97gTcG/AFA2QMPSDwhDQZie9n2wLRJU4cqqklIe+jEDyEm7QVV4bt2YidTxFz1+ss53znn O+de20Q9X2m1mhlViJarrp3PJJWTpxaUnk2K0rPUSwPUq+lOLZHLzRIuwRX3zuvhHYoIy+2R7v5O 9iO/eovc0YkiT8BuFR19GfgMUczUa7ZLFL8H+/hptwbc8xzw0zYEAqsCl32cEnjRxyc9TiE/CY7Q KusVrQi8Bjy82GYvt2FfAxjIk+FVbhu6ImaRs62SYXLP4S+Pcbcx/w8um3X07F2DWPucpbljuA+J 3iv2VL6JP9e19BzwS7Bfr7lJYX8F+I/60nwCeB9R9KmSfXTe50dfX60U3gbeBXvRcKcLTftqdTF7 HBix0fUl65jIIzjXdWcSs6QXgO9W+LTYY+iRqMhTaeBh4MFKfaqZX5pxVuaE3cuzWpnMAiOPZL+n zeSAB4A/tK28qAXN0jo3M6IW8ktXa26uqUHarppZUQv9Mpk7Xo/IKW27lcKUH8sOunahGcsWSsbR 6SZ/rWZ6ZxHa2AW7nhfakJ/d0ux0Bhh52D+8Oi/mBhzbXdRSYrajwEfoREQjThYtYtWpSjukUJ4y lMS9RjY8JTLIhIXDy2ExIk/SEmzdeTmP48eEjLIXvS2iUaU7x69wv8mxWD9T2QH8H2Kz7DAbZxOk sDfYm+wIS8E6wQ4FCnJtOhUq030o9fO8T3VUFjpOUPL8QH0oiFHO2e8a+s2P/oaasEsr9CNP0DE0 W+0TIAcTaHU30j6na2s/7A48yga7+M7tvmtrdPxx843di23HNrBuxrbC+NivsS38bVICO2B6ipah yvB2wgl4Ix09XAHTJQ3rb+BZ0NpS2rGjper5gdAjJsE/yD7M0rnh0Kr+ov6pbqhfqBfU3ztqhBk7 piR9Kn0r/Sh9J30v/UyKdFm6Iv0kXZW+kS4FObvvvZ8l2HuvX2ET3YpdaNVrnzUnU07Ke+QX5ZT8 vPyyPBuwFLlfHpOn5L3w7An2zQz9Hb0YdAqzak21ey3xBBg0DyUGnQbXxlTFhKt0Flnbn5OmUjbI xtj0I6d2XJzllop4Op6KJ0iJ74tPxMfiMwK3nrz4XvgmsKYD9f6TEzA6OuBtLEwlyDPinTpxVkX0 CnSb0M1dfgbfDqJJq3bWNsoVV9mvqq8pCXzKuDJd1UeHFc00Fc/lKDZ3uL3Ci6MkvoMijuhB3vu+ RXbdDG3uW0SH/8I761ZoW6gTfe0Q9b8a2obwTnzmM6KLB/W6veLno0jkBpFTOrDf+x3pS+LddLfR eID3Vc8nRDsfNxr/rjcaO18i/xbRZfM/WQBxeAplbmRzdHJlYW0KZW5kb2JqCjM3IDAgb2JqCjEw NDcKZW5kb2JqCjMzIDAgb2JqClsgL0lDQ0Jhc2VkIDM2IDAgUiBdCmVuZG9iagozIDAgb2JqCjw8 IC9UeXBlIC9QYWdlcyAvTWVkaWFCb3ggWzAgMCA3OTIgNjEyXSAvQ291bnQgMiAvS2lkcyBbIDIg MCBSIDI3IDAgUiBdID4+CmVuZG9iagozOCAwIG9iago8PCAvVHlwZSAvQ2F0YWxvZyAvUGFnZXMg MyAwIFIgL1ZlcnNpb24gLzEuNCA+PgplbmRvYmoKMTcgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1 YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAvTk5MTVRWK0NhbGlicmktQm9sZCAvRm9udERlc2Ny aXB0b3IKMzkgMCBSIC9Ub1VuaWNvZGUgNDAgMCBSIC9GaXJzdENoYXIgMzMgL0xhc3RDaGFyIDU1 IC9XaWR0aHMgWyA2MzcgNDczIDg3NAoyMjYgNDk4IDQ5NSAzNTUgNDk0IDUzNyAyNDYgNTg1IDUz OCA1MzcgMjQ2IDYwNiA0MTggNTM3IDM0NyA1MDMgNTM3IDY3NiA1MzcKNTYxIF0gPj4KZW5kb2Jq CjQwIDAgb2JqCjw8IC9MZW5ndGggNDEgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0cmVh bQp4AV2Sy2rDMBAA7/4KHdtDsWwnTQPGUFoCOfRB036AI61TQyMbxTnk7zurhBR6GJPRaje7kvKn 9fM69JPJ3+PgNjKZrg8+ymE4RidmK7s+ZEVpfO+mi6U1t2/HLCd5czpMsl+HbjB1nRmTf5BymOLJ 3Dz6YSu3uvYWvcQ+7MzN19MmrWyO4/gjewmTsVnTGC8d5V7a8bXdi8lT6t3aE++n0x1Zfzs+T6MY OiKjOLfkBi+HsXUS27CTrLa2qVerJpPg/4UuCdvOfbcxq8tZw2a7NHw8n9LyaW3KvOwprymX4mXR 1Iq1s0VDiRIFa+eVaoUCUa86RxVbpOg9P4HNM40uULB2Uao+oGDtfaG6RAFNm1sU0KVGHQpop+pR QEVVUECdaocCXWnlivNRiGpXFdMo6IMq0yh0pf9bMY1CdK7KkSlEkzJcBVTWNiqGU4hyinXFcApR BuQ6tt35FPVm9AVdb9wdY+Sy0zNL70Dvtw9yfYnjMGqBxC/Is73pCmVuZHN0cmVhbQplbmRvYmoK NDEgMCBvYmoKMzc5CmVuZG9iagozOSAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0Zv bnROYW1lIC9OTkxNVFYrQ2FsaWJyaS1Cb2xkIC9GbGFncyA0IC9Gb250QkJveApbLTUxOSAtMzA2 IDEyNDAgOTcxXSAvSXRhbGljQW5nbGUgMCAvQXNjZW50IDk1MiAvRGVzY2VudCAtMjY5IC9DYXBI ZWlnaHQgNjMyCi9TdGVtViAwIC9YSGVpZ2h0IDQ2OSAvQXZnV2lkdGggNTM2IC9NYXhXaWR0aCAx MzI4IC9Gb250RmlsZTIgNDIgMCBSID4+CmVuZG9iago0MiAwIG9iago8PCAvTGVuZ3RoIDQzIDAg UiAvTGVuZ3RoMSAxNjY2OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAHlnHlgVNX1 +O99781MZp9JMpnJOjN5yWSZZCb7AiGZrGQhQEgGEyCQEJagYDAQNgVjW8FGUSvuG9alaqMyGUAH oYKK2lZRa6n7gq22oqbSKlqBZL7nvjMTAtW23/b7+37/+A0583l3ffeec+65971E1/YPLCVqMkh4 ktOzqns1kT6ODYC6nnVrbZiO+YoQecSy1ctXYTrhDCHKqOUrNy7DtONvhMSe6l3avQTTBMpJUS9k YJoWAFN6V61l/cLHYYCv3pV9PaFyxyFIF63q3hC6P3kX0raLu1ctBcLHA/cn6av7l4bKaTshpjsX QOZ9HIwMqADRgLCOS24tGhwe1RFCIRFHbZD5C6jAAd2kC+r10EoiQCkrl90dyPvqItUifdlJEhsB GYTs/+yylxhf2PbQ1affHtuu/FzxHNRVQg/4gXaKu8feJkR1z+m3T21Vfi71FCqUEDei5APct/6k RGuA+5s/yQn4xp+UBfgacRLxFZZ9iam/Iv6COIH4AvFnrDmK+BwzP0N8ijiO+ATxJ8QfER8jPvIn KWEQf8DU7xEf+hMjIfOYPzEW8IE/0Q14H/Ee4l3EO1jlbUy9hXgT8QbidcTvEEcRv0W8hvgN4lXE K4iXcRBHEC8hXkT8Gm/7K6z5S8QLiOcRzyEOI55FPIN4GnEIcRD7fArxC8w8gNiPeBKxDxFAPIF4 HLEXsQexG+FHjPgT8kCDPsQuf0I+pB5DPIp4BDGM+Lk/IReqPIx4CNs9iPgZ4gHE/Yj7EPdi858i 7kHsRNyNuAtxJ3Z9B+J2bH4b4lbELYibETdhuxsROxA3IH6CuB5xHeJa7Ho7Nr8GcTViCPFjxFXY YBtiK+JKxI8QP0T8wB9fAHq5AjGIuByxBbEZcRniUsQmxEbEBsR6xDrEAGItYg2iH3EJYjWizx9X CIO4GLEKsRJxEeJCxApEL2I5YhliKWIJogexGNGN6EIsQixEdCIWIOYj5iE6/LHFMLJ2xAWIuQgv og3RipiDaEHMRsxCzEQ0I2YgmhCNiAZEPWI6og5Ri6hBVCOqEJUID6ICUY6YhihDTEVMQZT6LaUw vxJEMaIIUYgoQOQj8hC5iBwJPPVbXNCLGzNdiGxEFsKJyERkINIRaQgHItVvngqdpSBEv5kt9GS/ eQrAjpk2hBWRhEhEJCDiEXGIWIQFYUbEIEx4h2i8QxRmRiKMCANCj9AhtAgNQo1QIZTYZwRCgZly hAwhIHgEh6AIIoEGEeOIMcQZxGnEKcS3iL8hvpFuS7+WZkRPYuZXiC8Rf0X8BXEC8QXiz4hRxOeI zxCfIo4jPkH8Ce/3R3+MaA3QjxEf+WNg5dA/IH7vjymB1IeIY/6Yakh94I+pAbyPeA/xrj+mFjLf 8cfUAd5GvIV4E7t+A/E6dvY77Owo4reI17Cz32C7VxGvIF5GHEG8hHgR2/0au/4V4pc4+BcQz+P9 nvPHVMHIDmODZ/FGz+Con8bODiEOIp5C/AJxALEf8SR2vQ+7DmDXT2DXjyP2IvbgjXYj/IgRvK0P sQvxGHb9KOIRxDDi54iH/SaI+vQhv6kS8CDiZ35TM6Qe8JtmAu73m2YB7vOb5gDu9Zs8gJ9ilXuw yk6scjdWuQvL7sSad2Dqdqx5G+JWbHAL4ma/aTb0eRM2vxGxA3EDDuknWPN6rHkd4lq/qQXabcea 1yCuRgz5o9uh7Mf+6A7AVf7oBYBt/uhOwFZ/dCPgSn/0fMCPsOyHWPMHWOUKzy6oekJfa/1CV289 pplpfQbkaZBDIAfVc61+kBEQH8gukMdAHgV5BGQY5OcgD4M8BPIgyM9AHgC5H+Q+kHtBfgpyD8hO kLtVvdbbQW4DuRXkFpCbQW4CuRFkB8gNID8BuV7Za70O5FqQ7SDXgFQquTPcKTKXWLnTwF5ipZf7 oyBk0i3+SLYA1yLW+I3Ma/sRlyBWI/oQFyNWIVYiLkJciChDTPUbWGdTEKWIEkQxoghRiChA5CPy /KDgAM1F5CAiEUaEAaFH6BBaPxglQDUINUKFUCIiEAq/lpla7pkP/DPIKMjnIJ+BfApyHMz5Acj7 IO+BvAvyDsjbIG+BWd4EeQPkKZBfgBwA2Q/yJMhdYIo7QQJ0EDW9yW9ki2MjKmcDYj1iHWIAUY2o Qj1UIjyICkQ5YhpO2YSIRkQx7ON5nvN7rPc/xXNkD8hhEJ4nOJZLEa1o9Tk4shbEbMQsxExEM2IG ognRiGhA1COmI+oQtYgaRDLCjoO3IayIJEQiIgERj4hDxCIsOE0zIsZzB0x3DOQMyGmQUyDfgg/8 DeQbkK9BToJ8BfIlWPWvIH8B+RPIH0E+BvkI5A8gvwf5EKx7BOQlkBdBfg3yK5BfgrwA8jzIcyCH QZ4FCYA8ARZ/HGQvyB6Q3SB3MOtzY6jjzYjLECv8RjgK0V7EclTLMsRSxBJED2IxohvRhViEWIjo RCxAzEfMQ3Qg2hEXIOYivIg2hBvhQlVnI7IQTkQmIgORjkhDOBCpaJsUhIiQIQQEj+AQFFck8dwL RgqCjIN8Aop9HeR3IEdBfgvyGshvQF4FeQXkZVD0PpAr+VTrj3iX9YfUZf1B/aD3iuFB7+X1m71b hjd71Zunbm7azKs3xwMu3Ty8+Z3N8svqN3kvHd7kFTZFb+JUG+vXezcMr/eq11PNuvoBb9vARwNf DfDRA20DSwbWDtw4cBQyFPcP7Bk4PMAHgoc8kQMlU+sGB64f4KKhnCMDVM+y7QNqXd3a+n7vmuF+ r9Bf0M9N/aqfHuunXE4/nd3f1c9Brd39Kel1rHZhf0xcnaE/p9/Tz19S3+ddPdznndXX13d5386+ g32yy/uu6+N2wRXn6VNq6y6uX+X9YBUlB7ggMYAc4oJ+XtW3nxuHtx5fcOOeIL0IFHAhKGKFa7m3 d3i5d5lriXfp8BJvj2uxt9vV5V3k6vQuHO70LnDN884fnuftcLV7L4D6c11tXu9wm7fV1eKdM9zi neWa6Z0J+c2uJu+M4SZvo6ve2zBc751dT6e76ry1fJEVdhCSBD+rkwaTTiQJ6q7E1Ync6sRjiScS +dUJJxK4y+OpPu7yuOvieD18cfgVa429LnZn7K5YmV664DWrIwcjudXGQSOXY/QYXzUeMwrEeI+R 01+n36nfpedn6Rfpv9AH9cIuPd2lO6h7RcfP0i3S9el4vY6leYNH58qt02utWs90t5Yvc2srtLO0 /HVa6tG68uo82pS0ugrNLM0iDb9TQz0aR0bdF6qgivOooOALZVDJBZWU8NRG4T2UAcBHMBtRk7Uu QMnuGCqjAXr9SFur09kUUATnNPkiZs/30at8qa3s29Myzye/yke88+a3j1B6bccI5arbfNFNLfMw feX27aQqscmX2Nruuyexo8k3CBcedhGEC5I4EkOqOpwL1wysWbPWucYJXyAL10DO2gH4kUDhG64H 4ItdEaji/J4PqwGFUFuqtGZg0QD0AZUhm/U+ABcswap8Txf/u9lsbP9nH/p/duf/729sWbSQvb0l ZHzHpBe2V5AryJ1kmOwlT5Knya/Jb8mXVAXviq8kB8kfyKfkr+Q0LFMFNdEEmjGp3X94Of5D2Sqi 5Q/BK2wzIcFTwePjDwePw0tp3aScHZAyC46zOcHI4Oj5eeM7xgPjL8vVxCC1NXAvQm8n6GjwFFcB LQ3BIpbmtrFr6U4nFHeP7xrfec4EVpN+MkA2kI1kE7mUbCZbyOXkh2Qr2UauIj8GXVwO11eTa8h2 ci25jlxPfkJuIDvIjeQmcjO5hdxKbiO3kztAj3eRu8nOUBlL3w3/bpZKWcm95GfkYfII8D5yP3mA PEgegvTPQfuPkMcgD3Mw/Sjk3EN+Crk/g3qs1iPkUbIL/vnICPGT3WQP2AzT4VSAHCKPkydIgOwD a+4nB+Dt/1Ngx0Ng2WekPJYTTn9/Taz/LDlMniPPkxfIL8mvwDNeJC+RI+Rl8gr5d0qem+iF9fAq +Q15DXztKPkdeZ28Qd4i75D3yQfkGPk9eN3nf1f+JtR4G+q8F6r1IdT6mByHmqPQE/aDdd6FPj4k n0g9HIW+j5GPaAQ5STlymgThilnvZslCt0l2ZNa7Hex2v6RnZo9dkGYWQq0z2zwKOn8U7Mssw65v D1njMag7AnoNa5pp+e9183LIVqjvA1CH6YLpE7X5KmgYbcb6eWpC4y9KevJLFn1mwhZnrcB0yPT3 Bglr591JOvyY/FHSDNPum5Lu3p2kPablj0CDzAqsj3N1+3toi9ZhbZnOmU7DbVjZ25A+DtHhc9A0 42eSJT4jf5q4/lOofJT8mXxBTkrfJ8hfIJ58Sb6C9NeQcwJSX8D3ubnn53xDviF/I9+SU2DBM2Rs UmryNSsZI+NgY0Ip5ShPxs9enc1lJVSAI4YcYloEVVIV1VAt1VE9HEUU55WoJ0qMf1dyttXZMqXU TySNotEQL83UQuNoPMTNRJpErdROk+nZstiJEhuUiDSFpobaxUgtYyfaWuGIZA71wupm0By6Hr6d 1EXdcJ1LC2ghLaalkJMN6TxIT4GyHIlVZDZZTFaSU7JPuJdgXNEQVUY8dYsWdi6YP6+j3dvWOqdl 9qyZzTOaGhvqp9fV1lRXVXoqyqeVTZ1SWlJcVOh2ZWelO1JTxGSrJdpo0GvVKmWEQi4TeI6SrFqx rsvmc3T5BIdYX5/N0mI3ZHRPyujy2SCr7tw6Phtr1w1F59T0QM1l59X0YE3PRE1qsJWRsuwsW61o 8x2pEW0BOq+lHa6314gdNt+odN0sXQsOKaGFhN0OLWy1lt4am4922Wp9det6h2q7arKz6IhaVS1W L1VlZ5ERlRou1XDlSxdXj9D0cipdcOm1U0Y4EqFlt/XxqbXdS3yzW9pra+Lt9g4pj1RLffnk1T6F 1JdthQ/GTK62jWQdGromYCCLu5yaJeKS7gXtPr4bGg3xtUND23xGpy9DrPFlbPrIAgpc6ssSa2p9 ThEG1jRn4gbUJ0s1iLahkwQGL45+DqOelNMdypGnGk4SVsimOKEmH+0OXxMYG4wQ5me3s7FcHfCQ xZDwDba0Y9pGFsf7icft7PBxXazkULjE5GUlg+GSieZdImi2VqztCv2s67X4BhfbsrPAstJPqk9I hXKbj3d0Le7pZexeOiTWwAxBl6QNTuc1cOHpDimzdiTHDfW7u2ASK5gaWtp9bnG1L1qsQm1DBnSS WruitV1qgrm1vuhqH+nqCbXyuWuhLbhI7RAzDBsg60tsad9H8oPHRgps8bvzSQHpYOPwxVSDURy1 Q+1LlvmsXfFLwD+X2drj7T5PB6ivQ2xf2sGsJBp8GcfgdvABA0qtYG7n1Q5Xhmn7FKkRtnYunu9g 1oIMWx18iVVlUGDwyTHJLFpVZmun8SRcDe4SqsGuzukHEnxqdT00BkLT6vp4Ozi39PkHQ4rHCcAw fBETYxJgELKzY8L7fO/QsDYbUIatdmnNpAGe0ykkpAGGevvucXJMFyFlwBAimDnr2Ryyszi4tkFx hI+DeUpZzIoWm4/MtrWLS8UOEXzIM7udGYfpWrJvU6vIngAla4e8pO2cFJaXYJmP2Jva2sMJeH5s 99U5Jbsys0rp6VJ6Ill/XnFDuNg2FCE2tQ6xm4uhDokNVhAYR+5o6L66JLIAFmsdBEqxrlu0GWx1 Q92B4ODioRGPZ2h1bVfvFFgGQ2LDkiGxtb0MbCmt+83xm9itI0kTbWqrys6C2FM1ItKrWkY89KrW ee374Cxru6qt3c/B029XVcdICpS177PBX4xIuRzLZZmsio0lWE9zIBEh1Y/f5yFkUCoVpAwp3QMP 4FIeVoI8SnoCHOYZwvU4yBMwzyPldcAHVpilF0wAcbjWtoSZ57KO3qGuDra4SAyYEn6oj4rlxMeJ 5fDMLtf4VOLSKp9arGL5FSy/AvPlLF8hVvloDAXlBCAmDXWJEKfA5dpJPO0A7zAw7+dSbYFgsK3d fiR+tMMOS2IByLx2n9IJ+4AstRHqTWfSBdnTfYM93WwcxAtLna3Mhp4OWAvhDqFKg08JPShDPUCN OqkNc0do1AO2AQNK7Qch4Rvs8HU42U3bV7AR2WwGH6kXp4DZsU+Zg93I3TEUKeYxx4aqPlXqNgYl jI3A2wgpJx6ScDMIuGxGCg2MvEeEop4uG1hAID2t4OoYS1XMbpCzFEKi4FgqiSo+VEjYtPhUtVbl U7qgQ/hh12oXdAg/ig5QCpu8lNoWqgD3NvjUMCLHJFWGGoB2oKiBjQV+tsHgWdWnWTctATJH3ACh kQ1aupUCin3a1IZuCP7YXg05Ykm4MfQVkcqyWB+HMVfBZq4BvfOpbYHgg+JGFgHCn+wskW0OzDFJ /D5wbNIxdH6Gb74zOyvi/FytlD00FKH97gaorwjtBKEXIrA/m3qFEOEteOa8jGyXxZIG+ThwBZnN /5JU8F8TDf8lmc53kHqhiTQJCtII3EK/IReBbGHXQrNUtoV7k2zhnod+doWkiWyEOoQ/EzwJs4GD KXyzP9uSkxKgHZ6BBfg7LRnkx5IIEgV/caUmOmIiRnhm1ROOqIiWREN9M7SIhL9Yww88XdJm+gXn 59fxx4UHZILshHyrIlnx54iVEU8reeWQcky1U52k3qt+WlOi2aN5UzMGDWXwBmAN/w48LfNwz1LS TGaStgNES++C7qfQF/fU1ERkK56CJEds9EUYD6V3eaIEThsfXyEWyq/hW4wNFYpruDZSMfb+e8/D 15HIUvcR6n5v9PVRw9jzxlL36NHR3BxqtBslidZxCoVcLia7uMI0R1F+fl45V1jgEJN1nJRXUFRc zufnJXE81MScco6lKf/OmVl87VgKt9E+tTVXRp2pZmtURARvTdKm5tv0Tc1iUXqcTIiQ87IIRVpR lehd35j8ssqSlpCYZlEBExOAY8/IdKf+KtOdvkCoOX2A+6S0vTxFvlGr5mTKiLvSk0wpuQnTmrR6 rUwXb45LUEQYdarM+u6x2+JSzSqVOTUuIZX1lTo2FTRiDp4SnpVFk2TiIB+yV49eOE+kBD/Zo9bT GWIg+IkniV2larSiRUtiqC7GoVaJySpiE0RqFB2pAZrpSfKoiYZG8hpNWmKKKCaptDFETLYoIhPn RHplXmKpqKiINJeWGPONoFk4q+fHNY/m0Vj3ws44y5G8/M3bDh+mlsMLO/EyNwdeUMISmTyMvWwU /8ndcnOczo7UmBi0WxpvV+h4MdnhKCqmaCyzQuTtwohGHlOSm1+apBEuGI+bI2gTC52ugmi5hl4n N4jl+VPr0ozyZ+gTtG9xSqZJxisNWiqM6aLUgtycKQqXGU1qnlfHRD0Pf1XIw/sVIhSBZyYRJ6yM nWH9Wrkde+PUJpOaBLg7/VmO/AC30a+OSwtQfnduriIF1C7pPyVAUz1KQ0uBhc2+IEAz/B5FG6gT 1OesGHWCMkdLqXs0zz0KThpZCk4aP/JvdpOb00GjdYJoT3YUGguK8u3grybm6Uk8LXBxomhkbh51 9lIoclR3rr585vhD9uxsO61d/8AlZRZXtbO4szZ9/BFLTsO0K3eU1mTHVCdNmVd/51PFTcVW+qPa 1XPL06PSsoTerLT0lsva3K01BQZV3qwL6Qdp5Rkx4754d8XYt9nTc+LGrzdnV7PY0hD8VLhDlkIq yDuov90JCXpLgLvBT9L0+7nb4MxrCX6yW0+bLaC33VqJJ3ZrGGnanuTkUnf5fuqGOKEKqVUVoPM9 ytLWaEmt0QG6yO9xzw2rdcx5dJS56Si8YQXdHj08CglQ7L7/d7dB3UuhggURU3QShIuiYiP4Z2EB hA7JFkZmHRZyWE5ekgBKUWqV2ildV7YvvHXllKkX3jQva27qychomUqnpHsNsVEqU2XX8hWFd5z8 +bwu37e3tQ0tr4nXCLWJmbGqlMyUyvUPLu17uH9KdDTNyi5KcJjV6hhr9NhYUnZcQrSq4+Evb985 NrLQbHck5IMVtgdPyS8BTy4jb6EVPGptTo7Z7Va5LJa4ALdkT0quRqOCiydISlFLrEZt2U+zYZNz BU/sMYjcjNxA8ITHxq7MBvatxW+zOyfXJbemt1i9E6GCxQr2epsFiby8Cuo+OppnzDewL2PpNHd+ vjEf7LH3f/YuYIPUcLg2ipQFBxeXRkVQO8ZwtihYEDfTfBYx2KVJfok6MSc1JSdBw43/WIi05iQn 51gj+fGbOXWSG/IT1UXZj7iqcmwaahFostaaUZI6Ep8Wq01RGVRyOXwJiac/0hpVvExtUAsJp/8w kX9FfpFeLM08M8bTzCkpeh20IhCvZwePy2JlqbCnppFL0BIHSTT3DGyESfCtIrEhJ48N0AUepb5V lJxcDNBOv0c24eSjkmuzeLHvX24xyUtDPsjJWDiY8NhyThY7++7jt93y4c1NwNt3fHhL8/jntubB ru4fzLbbZgx2M3I3/3R8pHPWvaeG7zrtWzjz3m8eX/bg+sqGTffNv/DhDRX1lz0A3lYRPM5fA7Ns IPtxjvtIJXfL3pS8lDxNPIuZRONi7lVMVDT7cWMx/IspC0fNsgDN9mgq42UZrTHS5GMCtH3y5CNL S0edxtJSt9swahhl7gU5bjfTxgHi+h/q9qy2hLC28JzgkofSchZemZeFNCjnr5nxg8d6qte0T41T C0q9Spc/u68hZ0ZhQk7z4t7FzTm1Azs7XAtml0crZByv0KrVOXULip0ep8k9a0nvkpk59EfLbl9e EGNNjst1WTPj1PZ0uzmz3JFVkevMmeZd29K5vdOlsyRF68xiXGJ6nCbBHm9KLUh0Yvka0LsmeIr/ FFZ5MvGi3keIPMDduNtilEeG1RsJ0XOPJ7FFI+3rbCfKo+7DY0dAeyP/sFZYI/azS8oejmcswsGd VXrl+AFtUr7DkZ+kHT+g0qlkEM1U/PWgDZlwb2JGrOb06MQSidLEZiQmZcaq1bGZbG1MB69Zx79B 8omHZuD4/UpzQYCbv4ekpZEpAa7WYzDyZvqlmZoDmgJ6poAWsN+jKzVa2F4LXJWZAWrxxB9Lpvzm 5O3JnCd5dnJXMq9PtiZzGiE5WUgMBI95dBrYjBMtBtqceMrVOA30Ans0bZ72kUfTLBCLO7w7s+0Z zjqdnYs6pQ3F2XnJaOclsKUcLgXHyysFhXn0/8ejkaIeOxI5HIWFoSMt21/yC0MrO7TjCFK4U6Cn xrDNiV8X7czMzjAWb587ff0FOdM27ll/gTGtMqeiZ0a+QW1Uy1UJdQv7pq64qSvrm65pc4tip1cU drisOoNCYdBNn1qV2rCyfuaappSizIrM6ITkBF2cw2xNSRSTojK8Wxe8HZmSby/xFMF/bkJJffBT 3s6/TgrJXSGrJpC0p7i18EhhofCHBBMHRTgvWf1RjcKTtJ7kgl3VatqcmyXFgKwArfN7lM3SLg9b vHO0gm30zBp50rr/T3uSNKnDhwLcoWF9S0kxGa7Yji7t2xxMRaawTGm8wLV858ri6g33L05vri6M Ucr4aIPRUVCft7g3Lr85v6CpxKFVahSCL0606M32OINn8561W58dLIclHKO3iLFT3KC2W26ov7gx 1eqwquKlNdAEa+Al+F2kA56EbgppSx1fup+DX5YSN9fvUUXZ69SlafGCLjO8osHrGzxKS+PEMbNh j0fXLJvBzu3hk6a5FPZheAxCt1X+u32glnBDnexveTFmI2qNM/EO6VEqrLNi/iWVJSPJlh6rrr1l wbLtHen5i29Y1LSpjG29qbD1nirqKcqd7jRFZtQUxOXmF9mS1XqVIKj06p7GObO27u5Z/9TW+mlT KeytarlcbVCNFdTU585ZWlhyYWuePrk4ncWORtDb4xA7nKSAylBvu6Oi7FkBrtrvLBACTHN2Pisq i4vPelZgQcMMJ00iGARuxmyhS+DuEXwCJwgJbtAqO4wyemxQx/2Ro9HyNdEZdJyR1yktcDBVWqCC 8ltPQtgdnUchUIzCiZ7FjM5LFnY6Rxd2gr7z3gsdPj3K/917S7FaLton+S3sVpO9mzOlFUl2UvCP Z6SMfRg/tbOyaklDjl6pieA5IUI7Zd7aqvW7N0wtX/fwhat3Lsv5ip+/KGe6O5ajp1xZpZ2VyVHm KEWkPTbGGqPXWczGsk1Pbl5/8Mq6qoF7Ftou3JgyrdUNa38L7EivyVaTPLIKrbKPqLlF/rzM6ADX tRuCvyHsxYYAbfYoPdmNKXWxM9B50X0jpUck9gQf7//X6k/2UqMUCOWKs5tW2E+NRUVSVORf0yTk pqTmJmiiUkodOYsLNZJjJmrCrNzWMH9zc3KyCjYx2OJUdKyysTCxrnpsVzhHJoZ9czzKU1HWe3UP 88mLgqfodtlMeG9iJ7U4+4MkhjtIEoiJ64KznpVeutcTa2jA2b4Oa1VaozDRfd9Rdu6sMBiZoliM gqcMmEoM3RQecZhR5W3eqdO8bWUTY+c3wbqCVQSzyJkxpaRhxtRStBLdBFYyEfbKE94hePRaE4Xw q1ZRLaFqAR50u/Z6VIY6HCp1w1hzc6TdsTN+dzj7O0f496OaGMxZtYU9BVZwHrkCxzCSGbUf1JQk OQxJAkc5sRs2BMlh2BYuOYwaHCYzNqVhwmUiS6WYB+fjo3A4ZJv0Pviji/9Oy3NnwY533+U9pn/m Paq4DKst06xqvK31n3gPf1nYj5bPnl22fKgbfKc+eFwQQBvnPScMSM8JA+c+J8TBc0LjxHNCAhyV MS5J7xjOetSkJ4t/2ALmD28SMMaH1sr5zwmCULYpcOl639qSaZueuHSDb03J+Jgpr7WipK0oPia3 rby0rSiOHu8/cFVj1ZbAuv5fbGus3BK4oqpvjitjVt90YHbGzD6Y5ZbxmwQCs8wk08jNaHW/vUjF zG4iTu5Kj5KYVEWFdkGWEw4TOQHa5NE6GuMbDLNKpaNBaYA2Tp5zBXuzYoagwRxA2u8e/3f7mKSK tL8PICZ88RRWjsIYAyerck4gsMEtTKucVmYLr0NVbIY1KSNWldY0s9W9eOiC9PFTxozqvFjY7ZIK uwpya7NMdHT9wa31eqvLOr4gHEyE98OOsSJ9WkZ081b/+tIVc3L1yUXp429XN+S1LMN1w+0HHeYT +P0wW7sjDj2sVo+GxOlVVpVbxWt5FdvUYO3Am5NWj8rjbHToTbYGk3RCgGcnacXAYobngNCKgVct /6z+JN2wY+V3BFjUj5zbD7uJKiI6NinSlJkNYTYUXsMLRCwvKUnQJtksapnA8U0prjiVIkJhTCnL Gjsanv/ZJdKXV+nQ8wqlSmPKhNmbg59z1wojZArZgbN/wmjUTs0gYnYAthmzNjvsN9lwttwt1idq wxladtg01+cG6HR4KxdaMeA6R0CoO38s73Aee40kBZDs0EP5f6sTjCP4zmfiVRAczEOR2yRtPhC+ 4RWF5DcszV2rjhTdxQlNF9cnXxQFr4L0qgvVibg7PcOUER31rGtqtC3WqJCr5bJNWe4oCOeOWRvm 0F+5ixPTzaoXwHlk8DYCLszpicXu8c6GBoVSoTClBINMW0KNbCbnIDEQSBTEwj0BlLQo5IAWK0mF 311pANXtcSYlOcGPFj3OFzor6w1Opr6phfXwtm367tRm5QwCy6ziyCh7vYOnHFhroCyaF2M6u1Lg UXFianD++H5d8B9n2sO78HjfpBmqIlO+Rx38oZTkMw+FHYR77exEE7KyTd+rFZjtRnbG5p+Hneai 0IpRp+EB28ot8uijshvS1LLYhhQpusAzSfN5x2m2YqSwKj0C6v6V6ugL556bJw7MxvD7wrBrwIkZ AoY9wwKbx5wFm5vtkgvkJGoiU+GA0l0cPjlPbKRs3+j98TJuImM8ok46onAtYQVBtCX8Iek8Ai/7 STT8Bos7uEeu5DX1pOJ9+G0J7Od08mGCbg8fHsbXCC+Fzgrjw4QGT9LXBIHbCb8JMvqJQr2P2uDX RW44u8A7BNYFewUdegMtCKbYMzPjTKY43q+JVMm5kmK3u7jErYpNA8eDD4XfH+Fvn+Sw15GZM2c0 t811VnevXLG4f0V2Vd9K9j8y+C/nHo9WCmVuZHN0cmVhbQplbmRvYmoKNDMgMCBvYmoKODk4Mgpl bmRvYmoKMTEgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9u dCAvTlhSQ0FJK0FyaWFsTVQgL0ZvbnREZXNjcmlwdG9yCjQ0IDAgUiAvRW5jb2RpbmcgL01hY1Jv bWFuRW5jb2RpbmcgL0ZpcnN0Q2hhciAxNjUgL0xhc3RDaGFyIDE2NSAvV2lkdGhzIFsKMzUwIF0g Pj4KZW5kb2JqCjQ0IDAgb2JqCjw8IC9UeXBlIC9Gb250RGVzY3JpcHRvciAvRm9udE5hbWUgL05Y UkNBSStBcmlhbE1UIC9GbGFncyAzMiAvRm9udEJCb3ggWy02NjUgLTMyNSAyMDAwIDEwMDZdCi9J dGFsaWNBbmdsZSAwIC9Bc2NlbnQgOTA1IC9EZXNjZW50IC0yMTIgL0NhcEhlaWdodCA3MTYgL1N0 ZW1WIDk1IC9MZWFkaW5nCjMzIC9YSGVpZ2h0IDUxOSAvU3RlbUggODQgL0F2Z1dpZHRoIDQ0MSAv TWF4V2lkdGggMjAwMCAvRm9udEZpbGUyIDQ1IDAgUiA+PgplbmRvYmoKNDUgMCBvYmoKPDwgL0xl bmd0aCA0NiAwIFIgL0xlbmd0aDEgNjg1NiAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0K eAGFWQl4FFW2Pvfe6iUb6QTI2klX06SRdGIggAGCSWfpABPZg3YzQTqESIIgkQDu0Iwi0GwOA4zg gssoKKNUOsh0AIco6owoy1NHxxVE56nzDYJ+nzpuqfff6gbB8ZtXN/85555z7nbq1K1b6cWLlrRQ MoVIkLd5QVM7GVf2x2A5zUsXq7F6ShaRueG69rkLYvW+81G/Ye78W66L1XOs4EtbW5rmxOr0A/gV rVDE6mw4+MDWBYtvjtWz3wO3zl/YHLfnSLV5QdPN8fFJ2tUbmha0SAOmsgtEbV/YsdioUk4I/LL2 RS1xf+YnSvpzMpQ2YOS9V4R2n+lDxFDh9CWNoQfIAslGJXQ1kfJHJY9MqEu7KbXxd/t3jpyVOuYr a65cBtEjHw0qlPzF+2Zf892eH+fayCq7TjD8pQHtLBW9E6nGRt/t+e5WjCl7uvji3dQgLutyZzlO HBSD6RTAxeCIJ8/RLQaJvEi5wxsVrq70/qWpVcVCRfsSg6qgC4E9wCFAoVkiH1Yb6HIgBOwBDgEn ADMRqLSqwEJgB3AKMIs8YY+oDlvVIJGNttlYb6rIpLOADghygJYAk4BZwEZgB2A2/KRmIbAcOASc A8zkFZmRTcMw98zIWoN1zZtfalSbYtXGmUa165pAjE+YEuO142Nuo2NuQ4fH1JdXx/igohhPLygN ofOuxJTSnqoMkYFFZmDi7aCMv0CpjJGDHhL9SQO4wFQNjVekdw10l+44JBRiggtGc8ih9wgWSUkr rUrkOj9L6eTgn/MzMQs/09UnrXRH1a/4adoDHAIEP43yIf+QlvNTMuaglcAO4BBwHDgLmPkplJMo H/APKJW/TyVAJTAL2AEcAs4CFv4+qI2/J/PDoFKuBDh/D9TG38Wy3gVN5e9Aeoe/o/fw1yNlo0q7 DcFTEhccBXEhMzcupGeURvlrkW8HI6PcuNPIqANiAFXQMDEgUjDUERVZkTFtjij/qEv1OB6qGsLf IA3gmMkbGPkNUoHJQBBoB8yQ3oT0JoWAe4CHAA1AloHaAJUfAV4F3qQhgBeYDFj5iQiGifLjEXe1 oyqDH+N/oUxE/Cj/q8Ff5S8Z/BX+osFfBs+H/Qh/KZLvoKok2AltbOA28BLYTfy5roHpDr0qjR9C BB2gJUAlMAmYBWwEzPwQHxCZ40hHJwfoCJ5hB4/QZwZ/nB6xkneew+uuQQKqkrhHXwkJZIe6w829 7q3bUJXEvWETJEncd62DJIn71hWQJHHPXwpJEveceZAkcc+YBUkS96QGSCBR/uCfBg5ylE26nqlV qfwmROkmROkmROkmUvhNstC3ipzjfZHCQkRsu9czuNAR2s9CB1loKgs9wkItLLSMhVaw0BgWupaF PCxkZ6F8FvKy0AE2EqEIMe/eS6qjvFksdISFnmKhDhZys1ABCw1kIZWVeaPcGRmPpw7MZ7CuKvnQ cWfXlRXYfVK5ExF1Iued2BMOgR4HdKPmhZM6IOacnS/5gK7Cylj98tGlC6vG8cNoeBi34TCdBBTc oMNIo8Po5DC6SwWtBGYBPcBZQAfM8B6AdWw0aCpoCVAJzAKWA2cBszGds5gKp4Wgcop7jImVgFYC k2SNH0YZgOLkTm+ezW7z2MaJjXaWms8m5ev5vIwyMrA3p6dZ06IsZd83Kf/+JoUSqhL4Br6R8nAj 7onzjZFv8xxRdm/EfcBR1Z/9nvIVZB0bRW5WAD6SOoz6CLJbpX442flu8NKI/Wo0S424ixz7WR/Z ap/jW/vHjs/sUQ7xU/sBx1tqVGERx9+g2b3P8YZ9jePlkqgVmoPuKAPbrxqu3faRjqeOGK4rYNge cSyTbJ/jDvtYx/V2w9ASM1zbgZo31THVPcMxDv3V2mc7vB3oc5+j0n6tY0zMa4Rss88xBFPwxMRC THaw3RjUlW90OL0sylq9RZatFr9lkuUKS6mlyOK0OCx5llxLP2u61WbtY022JlqtVrNVsXIrWftF 9VNej3zr9TMbLz8zEpqRYsg27DBMbjOgxJmV069I6yvqef20alav9TRT/WxV+3qaK8oSp8zQTK5q pqXXU31DtTbSUx+16FO1Mk+9Zpn8a38nYxsC0Gp8dZRRgz/KdKlamaul1/i7ibG0letzJb9s5fpA gLIyllZmVaZXpI2qq/0FEjSUwVrPT1fWT6Iny5Onba2f5teezAtopVLQ8wL12u+mqY3+bvYlO+er 7WZfSBbwd4sK9qVvqtSLitpAoD7Krjb8SGVfwA8ZAwY/K17M0o9Ua37Mb3vMrwDt4TdQMvglJFCB 4VeQkGD4KUz6dXYM9NV2DgSBT6ZKHYZPR6Z6sc+RAvgUgMAnI0RHDJ8jGSHpo1UY3djtcMkHgQvL IbvhYmc5hosx807DpSTusuaCyxpjJBGbjeEjCbpJOXXeJ+UUfC4K5H8XW6o9HtZVHmhu9LW4fEGX rwUIamuXtmZpodmq2tkckAZVE+7g7OZWyZtatICrpVZrdtWqneVGu5+ZG6W53FXbSY2+Bn9no7el NlLuLfe5mmoDXWMnDy+7ZKw1F8YaPvkXxposOxsuxxprtPvZWGXSPFaOVSbHKpNjjfWONcYiI8cn +zutVB2owf2TvIsnJSJfg7nOQHWGrb3CSN5yZ9ay3P04reyiJE9AS3ZVaymAzOviquIqacIzJU19 oE6Nm7KWlTtz97NdcZMN6jRXNXkWL+lYQlm+ttrYXwcuqBYvkbciRj1S94sXXHyat6lWnq3rtcJp 9VrllBn+TosF2mBtALrR53VJSb6o3hNTXg7laOkoxAVHqRsjdQkJccf/zAVjTlAjOt04aBzoYt58 tpg6AkLLr2/g2AoaZiAMjTP8+3GWki+JjgAW2ME8rON8b3IdhkwxDWHZHeexeElcisdicZwbrh0e 8nScD8n57jwyWAYxYrXYg63NtJ+ygRzTTspW3ITvH/0T4FPJe9v0T6Vdcv5PbHTROIh20VOsjZ6i Q/Q8O4dWe6ib9pI8AtXS/XQ7baZVeK3NgGYNTUUxQb+ZZet78WXyMF6YD9NR+F5Dy2g/ZbAs/TNa TivF62i1klJoAFXRZFpI69lV+hJqpJPKnVRGV9EN1M5Cul/foG/S/0CPUbf4q/4jJVEONaMc1T83 /V1/j4rRYgtto5NsU8Iz5MUoIXg+QItou5ipMH2u/h1m4KSbMAeFJtBR1sM96L2FPmFZ7HZRg14e 1TX9BXjZaSa10nbaz0awsdxpatQn6EcpA2PcjF63UYT2oUTpWXqHJZvO6X/Qz1E2FdF4rGcvHWM9 ovfHFb2ViJsJURpMo2BZSH+mv9AJ5mLP8YWmZFOpyWu6VX+D+tFQmo7Z7kTL/2Xf8GUoy8VLSp1e TX0Ql9/KaNOL9CHLYSVsEruaD+YL+YNiEVkx4lCUOdSGeN+L3j9AGu3jyfy4eFTZrXxvzus9pffB HXHTffQAPcdSsFKVdbDfsDfZR7yGz+L38dNis/KE8pqlCau+lhbQetpN37B0NpJNYb9mrex2tor9 lm1jR9kJ9imv4g38en5WtIobxbNKNco0pUO503S3aa35015/7wu9/9P7jV6q301TkA8rMPst9CBW 1k3H6W2Uk3SamVgS64OiMiebzm5DWcbWs0fYLvYE24tRTrDT7DO8kr5i33O8abmZ5+LwI49ALr4I J8zN/H5+HOUE/xf/VmSKAcIjRogxIiAWYlarxD0oz4gPlRzluKIjzqWmraYdpl2m3abnTefMyZbf 4B3/6g+P/lj44we91Lu6d2tvpHev/iH1xz3E2wOfYGMw+yaUebjfW5Fxe+h1lozY5bBCVsGuQmRm sXnsRnYzInkX284eM+b+NDuIKL3FzmLOKdxuzPlyPoJX80ko1/IWfiMOY5v4Xv4m/05YRJJIFf1F oRgrZooWsVjcIrYKTbwq3henxdfiBxRdSVQcygDFrXiUscosZYnyoPKJ8omp0fSK6R/mRPMC893m qPkLnGoqLJMtUywzLRst+yxvWIPIzsP0DP0JGXjhYqfECuETz9AGPkzJxifMMeTzLJojJnBkKt/F VvM72F4+0HSzuZyXs4l0TnEj1i/xHfxrXi4msHo2jebxobEOzf2UJyGNUQ7TGeUg1nYMPd9sTmbL +FlzMkVwRhqFM9KLYojiEa/QO+IksygP07tKIstkZ/hOMRlZ8KxSYfKTU9xPT4sb2R30DPcRJX5v XYc8nsiexL7QwErZv4WOY/BEZFGZ+IjupOv53+kMnuPV9Hs2R5lLG2gYu50+ocfxVAw23WAuNPdn L/M2Jcz7sr3ElSewulFsIBOmfnQXmym2m8/yt2kJHVcS6QPxR8z+OH9aTFDOmaayVjwBd9DddKO+ gm4x+ZXX2FwS7GoqUE5hd7tdlCpO8OXYVRqxp+3D070f+0CVmABNFjLnKuTFdOwQ21HuxT6hIIPa 8Ixfg13sGO01N/AozTX1Ydh18J+aV3qn0gz9cdqmz6Ub9E1UjP1glX47etxF/6CNtIut7L2N2vEp +Tae7atMdfy4qU4v5mH+Np/Gt156fxHtApZF/0R5GnemwnSAwspbNI0q9XX635Ddl2GH3UazcWD9 GKv8HCOMEz00rHci79TrRDvWe5Km6Dt1B0ukVn0+TaKD9JjFRE0WD+6xxl7Dem+jFj5VXyxaetsQ h42IghfRWoL9Z423ZnpDlbey4sox5aNHjSwbMXxY6dAhJZcXF3kKB182yF0w0DXAqTry8+y5OdlZ mRn9+/VNT7Ol9klJTkpMsFrMJkVwRkU+V11Q1dxBTXG7xo0rlnVXExRNFymCmgpV3aU+mirbNcF0 iacXntf9zNMb8/Re8GQ2dQyNKS5SfS5VO1rrUqNsxhQ/5PW1roCqnTHkCYZ8jyGnQHY60UD1ZbXW qhoLqj6tbmlr2BesLS5inUmJNa6alsTiIupMTIKYBEnLdLV3sswKZgg80ze6k5M1BUvUcly1Pi3b haboRhT4muZok6f4fbW5TmeguEhjNc2u2RrJk5LHcKEaYxjNXKNZjGHUNpxxNFqrdhb1hNdFbTQ7 6Eme45rT1OjXRBP68GlpHoxbq2Xe+nHWT1V0jjPZqoutuSLsy2pTpXM4vErVHpriv6htrlP2EAig D7TlBXXBcB2GXoc7VS/P4hpfGfBrbCWGxMGywFhVbH2xU29BcJ6qJbiqXa3heUHcmpywRlNvcUZy crzd+inK8anhBr/LqVXmugJNtfbOfhSeektXtlfNvtRSXNRpS4sFtrNPalxITrlYaEHQYzZDMtyl VD/1QmSZnKNrPE6CmtqsYiZ+F9Y0UpKWkRRuHokbgCvA0EqbgzvSpiXUBMO20VKPJTLNVGBzqeGv CBngOvOvSzVNcY25wPYVSaPMkwupprGm87Lm8WiFhTJFLDW4p5hjhVEfUVy0NMpdrnYbvp/lRwNN RmybAqNLEH6nU97gtVEvzUZFC03xx+oqzc6NkLcEZ2selJae85b+06UldN5yoXnQhUzeK79nqb9m dV/4S7Vl9PW1jtZYxn8xt8Ts9dNc9Tgaq75wMJ619Q2X1GJ2GVDEDba4pPWt8YtcDp2UeK4wrLET 8nkXHJf9yZpSgD+zkdRzohYrstLQMLVOswXHxWgg0emMPzP/X6Oofk62MthPzeLL0EZ74hONTVsr v6R+yfSSw6K+AVsOx8k+HE68xIZUi81yfJwh4/Gh71RrNJqOJ7MAf/jkGCkRyNW8CBksDXiKDHUg N169xDE33iiAS2ZncVEd9sxwuM6l1oWD4aaoHprtUm2ucDd/nj8fbvdht4slTlTfvzZXq1sXQMRa 2Wg8HpyqO11s9ZROL1s9bYa/G//iUFc3+COc8ZpgdaBzIGz+bpXIa2i51EqldFFlheoZFhnhVsM/ t9tLFDKsiqEw6s3474ahizlBx6g5ymM623k/Dp0S03kNnVyf3GNqGvzx22IkhHz0kEP4QQXd8KN4 kxGE2C8UyVDK3zIeu6BBSlM5NHi1yMO4CT8o4LcScqY50wpA8F8d+kEVPT94TfQ9qUqP7GsBO8Fb cWZJIkc3Xv7TvH0SzK+qNARn0SXJ1+zM8ti+nnmGSs4MHdJ3+BXDSvEmM7sGuBdsaW3bsqWtdQs/ 1rZ5cxtkjIgmxqUPwjnyly5pX2UYGKXHV2HGuZ8m+qfWVI33VC1qa5o/oeH/AFKWDSoKZW5kc3Ry ZWFtCmVuZG9iago0NiAwIG9iago0NjEwCmVuZG9iagoxMyAwIG9iago8PCAvVHlwZSAvRm9udCAv U3VidHlwZSAvVHJ1ZVR5cGUgL0Jhc2VGb250IC9OUE1TR1QrSGVsdmV0aWNhIC9Gb250RGVzY3Jp cHRvcgo0NyAwIFIgL1RvVW5pY29kZSA0OCAwIFIgL0ZpcnN0Q2hhciAzMyAvTGFzdENoYXIgMzMg L1dpZHRocyBbIDEzOSBdID4+CmVuZG9iago0OCAwIG9iago8PCAvTGVuZ3RoIDQ5IDAgUiAvRmls dGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAFdkMFuwyAQRO98xR6TQ4TtM0KqUkXyoW1UJx+A YbGQakBrfPDfF4iTSj3sgZl5MCw/9++9dwn4lYIeMIF13hAuYSWNMOLkPGs7ME6n/VQ1PavIeIaH bUk4994GEIIB8O+MLIk2OLyZMOKxaF9kkJyf4HA/D1UZ1hh/cEafoGFSgkGbr/tQ8VPNCLyip95k 36XtlKm/xG2LCLlRJtpHJR0MLlFpJOUnZKJppLhcJENv/lk7MNo92bVS1Gk6W/NPp6Dli69KeiXK beoeatFSwHl8rSqGWB6s8wt+2nBKCmVuZHN0cmVhbQplbmRvYmoKNDkgMCBvYmoKMjIyCmVuZG9i ago0NyAwIG9iago8PCAvVHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9OUE1TR1QrSGVs dmV0aWNhIC9GbGFncyA0IC9Gb250QkJveCBbLTk1MSAtNDgxIDE0NDUgMTEyMl0KL0l0YWxpY0Fu Z2xlIDAgL0FzY2VudCA3NzAgL0Rlc2NlbnQgLTIzMCAvQ2FwSGVpZ2h0IDcxNyAvU3RlbVYgOTgg L1hIZWlnaHQKNTIzIC9TdGVtSCA4NSAvQXZnV2lkdGggLTQ0MSAvTWF4V2lkdGggMTUwMCAvRm9u dEZpbGUyIDUwIDAgUiA+PgplbmRvYmoKNTAgMCBvYmoKPDwgL0xlbmd0aCA1MSAwIFIgL0xlbmd0 aDEgNTA2OCAvRmlsdGVyIC9GbGF0ZURlY29kZSA+PgpzdHJlYW0KeAG9WHtwVNUd/p372N2QUJMA sklY7t1elrwliUqBUFg2uyEhAQMBuosgu0k2JjGRDIZUsNAdC1YWpCpCFRyVPqxAkcuGwRuoGBkd dVoVdbS+ZpT66nRk7IuOiub2O3eTlTDK5A/Ge+bc3/Oc853vnD333u1Zuy5KYylGIjWsiHS3knWN ewSipLkr0p20s/8Emdvc26MmbbmASOxs7b6xK2k77iMa47qxc/1Q++z34e9si0ZaknH6CnJ6GxxJ m10DOaWtq+fWpJ19FNLRuaZ5KJ79JmxbV+TWofHpXdjqzZGuaDJ/3M8gp3SvuaVnyK6HLOteGx3K Z0Hge5kYvALdS2l0E9mhZaKsIrL/fYyLJER5HFfZS+88tfqK2ecoy2HZqxf+ypIv9h9/4vPoV/np 9zi+gCNtOJ9LW+FgIVEGQ/xs+j2piNUON8GgxmKDalHnol6LWlw8z0kx9ijdjfoIqkjtbButR92K +gCqlNL2w+pn2xKSw3ucradctsCbLilLx+cozjHpyqsGsx19SHnL+cEJloPVO8NyEmMpbd4Y9gh7 mFpIYb8nD9tANVTA9vQVdiphhPZTN2oMVbTujO1PTK5QTrIS8kgMbabSZIkdUz4pL1U+KjcEllBO 5RsSxNOTYXmvUAZcDylPuW5UTqIeTIYOFCLjmLLf1ansnGywPQnlXpfB0OaepFjnQtNjSlfhbqWl 3IrX7zaEgwllJuLLvenK9Blu5VrXh8q0fMPBYJe66pWi8heVKWiINBWderxZyiTXTmUWQpNdgfxZ qCfYAbaXitjehGeBchwqpttXWzhjt8Fu66spKPcYbIN3ek3B7sKafE9hveIprM7Ph778eftm+/X2 efYKe7G9wD7V7rbn2cc7sh2Zjh84MhxjHA6H3WB/TMxVbCfYQZoLWg72OWwO2WCPwymdYIcs56En HJJDcJBjvGG+j83LaLzBDh7N5BqUYzZLsxnsUF/SdcirSFyTrECmwHXccCeBOQRaQDq7y7DRlit7 5zrnZs/Jmlnt/65b2IoM34u/+3Iyl767rjGoH3CF9AqumK7QcLpzWPlO2bMOoaivuLhuyfq+3u6O 1kBUC4S1QBQ1rG/rbXPqsSZVPdLRzQOqLk4NNzW3cRmJ6t1a1K93aH71SK/V7qJwKw/3av4j1BpY GjzS6o36E73e3oAW8Yf6mnxrV40Ya2tqrLW+bxnLxztby8dqstpdNNYqHm7iY63iY63iYzV5m6yx +OQD7Y2+W3qwO9VAe52qFzTqtYtXBHU1EvIb7FE4/etIHqBM+UkqkGOUK00jhch8C/VtLgeXmR/L z1HmYJf5L7ESi9rPqzA4dzYN0F20lw6TjR6DXkA30P30AuvAb3slHaU32GS6CmevRAbV01+Yab5C rfQ75PfQKdpFRygDbbpoAqI7mMfcANsLvYk2m7+hKTSD7qAnaSZ63UFnzf1mH6JLaBkdoINo/2em CUekcebj5ofkoMXoczMir5j15mHKphLyUQO8m+kk84hvm23kpEqge5Aepn30NH3KbmdHzTaz1zxt nsFWddIkakTZyI6yM+Jh6Q7zQfMf5iCYKKAijBqmnfRb9H8YZQBHa4DdxHrYTrZL8Aq3C0elLfLE wa/BQyHNR6mhNXQnGOinZ+jf9AX7THCKmWKP+Kx5rfkfSqc6zJLPJEq9KL9E2YE5nWA2VsaqWAPb yO5ju9hrQpGwTAgKPxVuFT4WF4krxfXia9ItUkLeLt9vSx88Z54wnzNfp4nkoutpLW3C7E7Rafov fclE9DWJeVgl87EbUGJsr9DP9rF+oYENsNPCAfYe+4B9xs4LspAhTBCKhR5hp3BQOCW8JLaLu8QH xPfEc9IcWZD3yR/ZPPZ3BpsGtw6+ZFaaZ8zPccQ6yI2V8dEiWk0RzLabrqGfYxaHUA5j1Z6hZ+kF q3zAJtFZ+hwsEMtmuayCLURZxK5jraydPcSOo5y0sPxPwEIIaUKWMFGYJDQKTUKXEBNeF2Jinlgk LhBXiIdRnhffEM+L5yVZGidNkOZLtbRd6pL2oDwqPSYlpJflmfIceZG8XI7JW+XtYrP8ivyGbZNt hy1h+8z2TxyL9fY19u1YnRewZ5/GXv7mktgUoK+gm6mZ+VkT7cZq7GMRimN3tbA7wVc3FZirxE3i fKEMu+Ek3Ybduoc20lZxJe0z3xQP0F+xUzrRZYz+IPnIJf8aq3M7lWEXDRVvYVFhQf5UzxTth24V R/6kvNwc58QrJ4wfl52VOTYjfUyaw26TJVFgVBLQqsOqPjWsS1O1mppSbmsROCIXOML4Kat69cgc XeXtIgiNyPQis/WiTG8y05vKZJnqbJpdWqIGNFV/0a+pBluxOAj9Lr8WUvWzlr7Q0u+29LHQ3W40 UAPONr+qs7Aa0Kt72+KBsL+0hPV7QceY0hJ+cHgpnXesU1VkIw5YquIZAT1X8wf0HA06YqInEGnR GxYHA/48tzsEH1xLghijtKRdB07altGitWwzvNQU5lpkZVAXIyFdCPO+sor1iZpfn7jhI+c35rAW 2H5BUBc81ZFovFr3hreBXG6GuRXZDquuUUW3wpZQUGdbhkBwjB1AyuEmnwmecIeqp2k+rS3eEQa5 tCSYyPXmWoevTg3BRI43xzJKS/qdmyrdmH1/6bzSeVxWup2bkvKTXyT9rw5w6dz0zPuQdUtSBDDO gFYLnLrabA2iAewMfovOoHjzDPCEK8QwzXbgqdIF7BnRo8ue2ogeaxyG0eZPggt3+BNpObnWQ8gX Qn44njkLK4X8TE2Nn8PTOqyd/XSkJzLksXkyzxEP8oVO7RWdRYb1Xv6w9GDWbU6tja9vr7WmsDVn 4AIHbE4Nx6yPxwO8IejW1RAceJssqTMorSF4hLEdIYOZWwzyu/rxjiquvgHhEr7V2v0YH0ZpCRxF bmhXlajVGLma7xU1rsZrW+JqtdqGzSR5LIlANB6aBgYbg+CJlmJEbygvpUZDoVnoZxrvB02QHg+h h46hHiAt17SvkVRWgoepOLUhuDiox/x5utcfwipg+w40BPUB7NxQCFnlKaRAvLHdOYS5ApjLixC/ OtkL3l1i6CIUj/M+G4OaWx+Ix/Pi/PeWtA1GFzu8Qw6DeAqn3GCxBrSF0Nx51hq4NTdghTin12BL D+8ovLNfmuHpKdxo+SOgnW4xPOMyMTxzNAzPGhXDlSmkIxieDcyVnOEff38MzxnB8NxLM+xN4QbI eUDrtRj2XSaGq0bDsH9UDAdSSEcwXA3MAc7w/O+P4ZoRDNdemuEFKdwAWQe0CyyG6y8TwwtHw/Ci UTF8XQrpCIYbgPk6zvDi74/hJSMYbrw0w0tTuAFyGdAutRhefpkY/sloGA6OiuFQCukIhlcAc4gz fH2KYW+eTheew7GLjl267Afzygsox5uSnE0+5oLCP5/xAY0rA18WGZDulAf/N6Hw/398RNJpfLuJ +A+oKvm/jGOaQRKqI9MgOo3Kbejiu9Ah7ZAiZNq7dBytiJYXH0dPMmRZ+dVZ7qx8VJ+0w/jqb/KT X1YZ0sLz+M5HhnWZUXy3fNuFOBPs625uryirqLYSGL7EkjOw4b8pWtSwsHH+0uKaaGdvtKe9OYKc ZJQnI06TzKGLO1I6U6dx+/+jVmaXCmVuZHN0cmVhbQplbmRvYmoKNTEgMCBvYmoKMjcxOAplbmRv YmoKMTUgMCBvYmoKPDwgL1R5cGUgL0ZvbnQgL1N1YnR5cGUgL1RydWVUeXBlIC9CYXNlRm9udCAv Wk9EUlNZK0NhbGlicmkgL0ZvbnREZXNjcmlwdG9yCjUyIDAgUiAvVG9Vbmljb2RlIDUzIDAgUiAv Rmlyc3RDaGFyIDMzIC9MYXN0Q2hhciA3OCAvV2lkdGhzIFsgNjIzIDQyMCA1NDMKMjI2IDMwNiA1 MjcgNzk5IDQ5OCA0MjMgNDc5IDU1NyA1MjUgNDcxIDIyOSAzOTEgMzM1IDM0OSA1NzkgNTI1IDUz MyA1MjUgODU1CjQ1OSA1MjUgMjI5IDcxNSA1NjcgNjMxIDQ1MyA1NDQgNDg3IDQ1MiA2NDYgNTE3 IDUyNSA1MjUgNjYyIDM4NiA1MDcgNjEyIDI2OAo2ODIgNDMzIDI1MCA2NzMgNDU1IF0gPj4KZW5k b2JqCjUzIDAgb2JqCjw8IC9MZW5ndGggNTQgMCBSIC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+CnN0 cmVhbQp4AV2Ty46bQBBF93xFLyeLkds0tscSQoomGsmLPBQnH4DpxoMUA8J44b/PuWXLUWZxkQ71 oG7RvXjdfdn13ewWP6ah2afZtV0fp3QeLlOT3CEduz5b5i52zXwne9ec6jFbULy/nud02vXt4Moy c27xk5LzPF3d0+c4HNInvfs+xTR1/dE9/X7d25v9ZRz/pFPqZ+ezqnIxtbT7Wo/f6lNyCyt93kXi 3Xx9pupfxq/rmBwTUbG8jdQMMZ3HuklT3R9TVnpflW9vVZb6+CF0Lzi0zXs9ZWVeVCT7reMReeSe R+2t8p7zsWKlilzJdXS5X/6XXDyy75Pky6qUvC9eKr6XgwhshAFE3q9y4RpE3q9b4QZEYBS+gAhc CbcgAoOwBhG4FDYgApMwggjcCBOIwK2wrcrAyrzfqFVgXgnUVIF5JWZW58C8ElGNEdigRNRqWU+w Fa3lN+BGIioLATcSfi0ZN+HmyD6Em3BzpOUE3Eh8SDOHA4ioXQsxJ9HZopgLZnAjRwFzElHrLIOI 2oJogVeJzmqFLRPJ2hUVJpL5tyW2TCQb4rUwv2trhdfC/Bb6ZQVeJU6IIV4ZD2RjRDEngbUQcxLJ NgbmCjO40eo4ICai2gb7MzGV/gKTmviDh/tpvZ04HXldzcdVai7TxC2y+2sXTBen69Pjio/DqIti +gvXeQ1+CmVuZHN0cmVhbQplbmRvYmoKNTQgMCBvYmoKNTE0CmVuZG9iago1MiAwIG9iago8PCAv VHlwZSAvRm9udERlc2NyaXB0b3IgL0ZvbnROYW1lIC9aT0RSU1krQ2FsaWJyaSAvRmxhZ3MgNCAv Rm9udEJCb3ggWy01MDMgLTMwNyAxMjQwIDk2NF0KL0l0YWxpY0FuZ2xlIDAgL0FzY2VudCA5NTIg L0Rlc2NlbnQgLTI2OSAvQ2FwSGVpZ2h0IDYzMiAvU3RlbVYgMCAvWEhlaWdodAo0NjQgL0F2Z1dp ZHRoIDUyMSAvTWF4V2lkdGggMTMyOCAvRm9udEZpbGUyIDU1IDAgUiA+PgplbmRvYmoKNTUgMCBv YmoKPDwgL0xlbmd0aCA1NiAwIFIgL0xlbmd0aDEgMjcwNDggL0ZpbHRlciAvRmxhdGVEZWNvZGUg Pj4Kc3RyZWFtCngB1Xx3fFvV3f6592oPa1uSZVuSZUu25b1XbDkeseMVx3ZiJ3Fix84CsidZhCSs QMpKaUOZHYyGISsJcQiFtE1LV4C2jE4KbweUkhZaWqbt33Pu0XEcCu/7/j6/f/ozefQ8Z9yre77n nO9ZV2zZtHUF0ZN9RCIFI2uHNxD5r2QUtGVk2xYfC2esJkSZvHLDqrUsnH2QEG3SqiuuXMnCpTWE lLSvXjFMr6N/nwBlqxEhh4hQAk5fvXbLDhYuvg987or1I/H0kl8gPLp2eEf8+8lvEPatG167Aoy/ Ndfjw7dh04p4utCP25k3rN+8RU4mtnZwwaXpCYQIiC0UfMRMvkvURATnE9zRcouwnyiQStOV94wf fv/HlmWmmn8StwYRhJz5y+6fUH72uodu/PijiRu1b6ufQFCLO7A/XKe+Z+JXhOju+/ijj+7Tvi3f KZ4oU2FMK/nGxYMntC5hLsQBLvZzcTUX+7i4iou9XOzhYjcXu7jYycWVXOzgYjsX27jYysUWLjZz sZGLDVys52IdF2u5uIKLy7m4jIs1XKzmYhUXK7lYwcUoFyNcLOdimIshLpZxsZSLQS6WcLGYi0Vc DHDRz8VCLhZw0cdFLxc9XMznopuLeVx0cdHJRQcX7Vy0cTGXi1YuWriYw0UzF01cNHLRwMVsLuq5 iHBRx0UtF7O4qOGimosqLiq5qOCinIsyLkq5KOGimIsiLgq5KOAin4s8LnK5yOEizEU2F1lcZHIR 4iLIRQYX6VwEuEjjws+FjwsvF6lcpHCRzIWHiyQu3Fy4uHBykciFgws7FzYurFxYuDBzYeIigQsj FwYu9FzouNByoeFCzYWKCyUXCi4kLkQuBC5IXAhTXExyMcHFJ1x8zMVHXHzIxQdcvM/Fv7j4Jxfv cfEPLv7OxbtcvMPF37j4KxcXuHibi79w8RYXf+biTS7e4OJPXPyRiz9w8Xsu/ouL17l4jYvfcfEq F7/l4jdc/JqLX3HxSy5+wcUrXLzMxUtcvMjFz7n4GRc/5eIFLp7n4jkuznPxEy5+zMWPuPghFz/g 4lkuvs/F97g4x8V3ufgOF9/m4iwXz3DxNBff4uIpLs5w8SQXp7kY5+IUF09wcZKLE1wc5yLGxRgX US4e5+IxLh7l4hEujnHxTS4e5uIhLh7k4gEuvsHF17n4Ghdf5eJ+Lu7j4l4u7uHibi7u4uIrXNzJ xVEuvszFl7i4g4svcnGEi9u5uI2LW7m4hYubufgCF4e5uImLG7k4xMUNXFzPxXVcXMvFNVwc5OIA F/u5uJqLfVxcxcVeLvZwsZuLXVzs5OJKLnZwsZ2LbVxs5WILF5u52MTFRi42cLGei3VcrOXiCi4u 5+IyLtZwsZqLVVys5GIFF6NcjHCxnIthLoa4WMbFUi4GuVjCxWIuFnExwEU/Fwu5WMBFHxe9XPRw MZ+LeVx0cdHJRTsXbVzM5aKVixYu5nDRzEUTF41cNByns2XMmmOptV7MmWOpDtB+Fro6llqF0D4W uorR3liqAZF7WGg3o12MdjK6MpZSjyw7YikNoO2MtjHaytK2sNBmRptY5MZYymxcsIHRekbrWJa1 jK5gdHksuQk5L2O0htFqRqsYrYwlNyLLChYaZTTCaDmjYUZDjJYxWsquG2ShJYwWM1rEaIBRP6OF jBYw6mPUy6iH0XxG3YzmMepi1Mmog1E7ozZGc2OeVpShlVFLzDMXoTmMmmOeNoSaYp52UCOjBkaz WVo9uy7CqI5dV8toFqMalrOaURW7vJJRBaNyRmWMStnNShgVs7sUMSpkVMBuls8oj12XyyiHUZhR NqMsRpmMQuzWQUYZ7J7pjAKM0tit/Yx87Dovo1RGKYySGXkYJcWSOmEsNyNXLKkLISejRBbpYGRn kTZGVkYWlmZmZGKRCYyMjAwsTc9Ix0jL0jSM1IxUMfc8fLsy5u4GKRhJLFJkIYERkUmYYjQpZxEm WOgTRh8z+oilfchCHzB6n9G/GP0z5ur1jgvvxVw9oH+w0N8ZvcvoHZb2Nxb6K6MLjN5maX9h9BaL /DOjNxm9wehPLMsfWegPLPR7FvovRq8zeo2l/Y7Rqyzyt4x+w+jXjH7FsvyShX7B6JWYcyGK8nLM uQD0EqMXWeTPGf2M0U8ZvcCyPM/oORZ5ntFPGP2Y0Y9Ylh8y+gGLfJbR9xl9j9E5Rt9lOb/DQt9m dJbRMyztaUbfYpFPMTrD6ElGpxmNs5ynWOgJRicZnWB0PJZYh0LHYomLQWOMooweZ/QYo0cZPcLo GKNvxhLh9YWH2V0eYvQgS3uA0TcYfZ3R1xh9ldH9jO5jdC+72T3sLnczuoulfYXRnYyOMvoyu+BL LHQHoy8yOsLSbmd3uY3RrSztFkY3M/oCo8OMbmI5b2ShQ4xuYHQ9o+sYXRtzDKPs18Qcy0EHGR2I OVYitJ/R1TFHH0L7Yg4MNsJVMUcZaC+jPezy3ey6XYx2xhyjyHIlu3wHo+2MtjHaymgLo83s1pvY 5RsZbYg5RnCX9exm61jOtYyuYHQ5o8sYrWHXrWa0ij3ZSnb5CkajLOcIo+WMhhkNMVrGaCkr9CB7 siWMFrNCL2K3HmBf1M9oIXvcBeyL+thdehn1MJrPqDtmj6Bg82J2ataumJ122M6Y/QCoI2bPBbWz LG2M5sbsmEgIrSzUwmgOi2yO2fcirSlmvw7UGLNfBWqI2feBZseszaB6RhFGdYxqY1bMC4RZLFQT swwgVM2oKmah/aiSUUXMMgeh8pilH1QWsywClbK0EkbFMUsOIotYzsKYhRasIGahDimfUR67PJd9 Qw6jMLtZNqMsdrNMRiFGQUYZMQu1UjqjALtnGrunn93Mx+7iZZTKrkthlMzIwyiJkTtmHsQ9XTHz UpAzZl4GSmTkYGRnZGNkZRdY2AVmFmlilMDIyMjAcupZTh2L1DLSMFIzUrGcSpZTwSIlRiIjgRGJ TJmWeykmTSPeCdOo9xPoj4GPgA8R9wHi3gf+BfwTeA/x/wD+jrR3EX4H+BvwV+AC4t8G/oK0txD+ M/Am8Abwp4RV3j8mrPb+Afg98F/A64h7Dfw74FXgtwj/Bvxr4FfAL4FfGC/3vmIs9L4Mfsl4hfdF Y9D7c+Bn0D81hr0vAM8DzyH9POJ+Ylzr/TH0j6B/CP0D42XeZ41rvN83rvZ+z7jKew7Xfhf3+w7w bSAydRafzwBPA98ybPQ+ZdjkPWPY7H3SsMV7GhgHTiH+CeAk0k4g7TjiYsAYEAUe11/pfUy/0/uo frf3Ef0e7zH9Xu83gYeBh4AHgQeAb+hzvV8Hfw34Kq65H3yf/nLvvdD3QN8N3AX9FdzrTtzrKO71 ZcR9CbgD+CJwBLgduA3X3Yr73aLr9N6s6/J+QbfKe1j3De9Nuge910gZ3oNShfeAUOHd37ev7+pj +/qu6tvTt/fYnj79HkG/x7Onbc+uPcf2/HpPxKrS7e7b2bfr2M6+K/u29+04tr3vSfFaslK8JlLT t+3Y1j7FVvvWLVul97YKx7YKjVuFgq2CSLaat/q2SoYtfZv6Nh/b1Ec2zdu0b1N0k6I6uum1TSLZ JOjGp84e3+RJbQZHdm8ymps39q3v23Bsfd+6lWv7LsMDrqlY1bf62Kq+lRWjfSuOjfaNVCzvG64Y 6ltWMdi39Nhg35KKRX2Ljy3qG6jo71uI/Asqevv6jvX29VR0980/1t3XVdHZ14n4joq2vvZjbX1z K1r6Wo+19M2paO5rQuFJsjnZlyyZ6QN0JuNJiEeYXeCJeF7zvONREE/Uc9YjWU1J3iQxy+QWGrrc wnr3Ve6b3ZLJ9bxLjLiycppNzuedv3P+zamwRZxZec0k0ZzoS5QctGyJHb20bMcT6xoZF5bKZe1I DASbTQ7B5PA6xCavQyCW1yzvWCTHM+bnzaLJJJhMUyYxYkJ2U4I3QaQfUwlSJKGwvNlk9BpF+jFl lBIjRsTQhw8Z5vU2m/RevdhXp+/SixF9XUNzRJ9b0EwkwSfg5McMkjT0aQSHt3lcIMcTBaUwLtwy 1tsTDreNa8j8tqhm3uKocH00o4d+RroXRVXXR0nfosX9Y4LwhYExQWzojdrbuhex8DWHD5PZKW3R lJ7+6H0pA23RfRARKqYgSMpYIpk9EF66eevmcHjLUnws3bwlLP9DSNhKQ/hDAv5t3oIw/Q+EMKEp n//HsiHfss34k2/D7v75l/x/kCL8f/CM/+GPOEbQRPvrp8SDZFQ8AOwHrgb2AVcBe4E9wG5gF7AT uBLYAWwHtgFbgS3AZmAjsAFYD6wD1gJXAJcDlwFrgNXAKmAlsAIYBUaA5cAwMAQsA5YCg8ASYDGw CBgA+oGFwAKgD+gFeoD5QDcwD+gCOoEOoB1oA+YCrUALMAdoBpqARqABmA3UAxGgDqgFZgE1QDVQ BVQCFUA5UAaUAiVAMVAEFAIFQD6QB+QCOUAYyAaygEwgBASBDCAdCABpgB/wAV4gFUgBkgEPkAS4 ARfgBBIBB2AHbIAVsABmwAQkAEbAAOgBHaAFNIAaUAFKQFE/hU8JEAEBIGRUQJwwCUwAnwAfAx8B HwIfAO8D/wL+CbwH/AP4O/Au8A7wN+CvwAXgbeAvwFvAn4E3gTeAPwF/BP4A/B74L+B14DXgd8Cr wG+B3wC/Bn4F/BL4BfAK8DLwEvAi8HPgZ8BPgReA54HngPPAT4AfAz8Cfgj8AHgW+D7wPeAc8F3g O8C3gbPAM8DTwLeAp4AzwJPAaWAcOAU8AZwETgDHgRgwBkSBx4HHgEeBR4BjwDeBh4GHgAeBB4Bv AF8HvgZ8FbgfuA+4F7gHuBu4C/gKcCdwFPgy8CXgDuCLwBHgduA24FbgFuBm4AvAYeAm4EbgEHAD cD1wHXAtcA0Zrd8nHIQ6AOwHrgb2AVcBe4E9wG5gF7ATuBLYAWwHtgFbgS3AZmATsBHYAKwH1gFr gSuAy4HLgDXAamAVsBJYAYwCI8ByYBgYApYBS4FBYAmwGFgEDAD9wEJgAdAH9AI9wHxgHtAFdALt QBswF2gFWoA5QDPQBDQCDWT0P9xN/6c/3sB/+gP+hz+fa9lS+sYQIZO3z3xJiMwjl5HNZB/+u5Yc JreTZ8ivyXJyAOoouY88QB4mUfJt8kPyyiVX/T8GJq9UriUG6RRRERshUx9NXZh8ABhXJsyIuR0h m8J3MWbKPPXXT8X9dfL2KfPkuMpKdPK1RvFnuNs/hImpjzC+qohxqoyGxeugTfI3vau+Z/LxyQcv KcA80k0WkcVkCRkkQ2QY5R8lq8kaWOZycgVZS9bJoXVIWwW9EqFlyAVfIuuLudaTDWQ92US2kK1k G/7bAL05HqJpG+XwVrId/+0gV5KdZBfZTfbEP7fLMbuRslOO3YGUveQq1MzVZL+sOLOYA+QguQa1 dh25ntyAGvv80A3TuQ6RG8lNqOcvkJvJ5+nDl6TcQm4ht5Lb0B6OkC+SO8iX0S6+Qu76VOyX5Pg7 yT3kXrQZesUXEXOvrO4gXyJPke+Tk+Qx8jh5QrblCGzLLMLtslK29AbYYDfKfGDGEzNrbp+21l5Y g5b7ULzcO2C//TOu2Ba3I7XeAeSk1jkUrwd6lz3xGG6JW1Aypi+Wk9qIluHmS8rJr/ifYmmJqZ3u gr24ZajN7kDcnf8WOzPHTH0HuRs98H58UqtS9VVopu6V9cz4e6bz3ienfY18nXwDdfEgoYozi3kA cQ+Sh9C3v0mOkUfw30U9U7HUx8ijcs1FyRiJkePkBGryCXKKjMvx/13a4/Adn77mePxesem7nCZP kjNoIU+Ts/A038F/POZbiHsmHntOzsXC38G7lOfkXDT1O2hbz8JD/Yj8mPyEPE++h9Bz8ucPEHqB /Iz8nLwiGKF+Sv6MzwnygvIPJIHU48XLJ1Ebd5GlZGlkzuiypYNLFi8a6O/r7ZnfPa+rs6O9bW5r y5zmpsaG2fWRutpZNdVVlRXlZaX5ebk5mcGM9ECa12W3mE1GvU6rUauUCgkz25ymQPOQLxociiqC gZaWXBoODCNieEbEUNSHqOZL80R99LphJF2SM4KcKz+VM8JyRqZzCmZfDanJzfE1BXzR840B37iw qLsf+nBjYMAXvSDrDlkrgnLAiIDfjyt8Ta7Vjb6oMORrijZvW32oaagxN0cY0+saAg0rdLk5ZEyn h9RDRTMDG8aEzFpBFmJmU9WYSDRG+rVRKaNpeDQ6r7u/qdHj9w/IcaRBvldU1RBVy/fyrYnimcmN vrGcs4duGjeT5UNhw2hgdHhJf1QaxkWHpKZDh66LWsLRrEBjNGvnH1ww4IpoTqCxKRoO4MHa5k9/ gRBVZpgDvkP/JHj4wIW38dQzYobjMaoM8z8JTaRFnDZTVBjmmuDZ8IQon99Pn+XG8QhZjkB0X3c/ C/vIck+MRPLDA1FxiKac5SmOPpqyj6dMXz4UgGWbAk1D8X/bVrui+5b7cnNQs/K/jKgiA+m+qBQc Wj6ymvLwikOBRpQQtiS92LRphIgMx43ZNFaQj/zDQyjEGmqG7v5ofmBD1B6YzayNCNwko2lNT798 CYttitobomRoJH5VNL8J16KJNB2iFUMfkN4r0N1/mhRPvTZW4vMcLyYlZIA+RzSxAZUSbDrUP7oy 6h3yjKJ9rvT1e/zRyADMNxDoXzFAaylgjma9hq/DHypQvgpl+1RunhnFjqozNL5+0SMN0NpChK8Z H4HZNUgwR1UsSGt0do2vX/AQng3fEs9B1SX3QUDKaGjBxWBc2tDi8aNxy3//zSN5WAHwGFHN9DMp 8BDKi8/EvudzH43lpg+U5Wta0TjjAS+5KQLyA8bv9tnPKVJbxI2BR9DQ6myhZcjNEaF9SNZERZRT jqK16PJFyTxff2BFYCCANhSZ108rh9part+2ngDdGJRrO95Kei8JsfQKlhYl/rbefh6gezbR5rBc r7Ra5fAcOTwdbPlUcitP9h3SBNp6DtEvD8RvSHzoQagcVbB1+MYKawk6azMcZaB5OOAz+5oPDY9P 7Vt+aCwSObShaWh1FbrBoUDr6KFAT38N6lLu93s8O+lXW0mb0NY7OzcHvmf2WEC4vnssIlzfs6j/ tJkQ3/W9/TERm6JDswfG0pHWf9pHSESOFWksjaRZfDRA7zQfAY2c33M6Qsg+OVUhR8jhEezLynEs E+IEMjIusjgzzyciTsHiInLcAP7Qw1yrUQXww02+UVo9uwdWHxoaoJ2LJKIq8U+ICoFaEhUDtdjK VRmiusCK2VF9YDaNr6PxdSxeRePVgdlRIVGAccbhkw4NBeCn0OT6sUU+gNZhpq1fzPCNT0319vvP ey4M+NEllgCL+qPaMMYBZcZc5JtDMYToOdF9I8P0OUgfujrtma0jA+gL/IbI0hrV4g7a+B2Qo1m+ hjZHXDSCukEFytfvQyC6byA6EKZf2r+GPpHPZ46SlkAVqp3dUxmkX5Q/cMgaKKING1mjuozrKGnx bASb1HKMB0F8GRwuLZHagCcfCSBpZMiHGlCQkR40deZLdbTeELMCLlERXCFD54knElosKUNv1EW1 ebgh/lGtz8MN8U89AKPQwsuh6+IZ8N3mqB5PFJxhyvgFsA6SWumz4N91eHia9dv0Nt3jZH5gB1wj fWj5q9RIjhozWofh/Nn1esQEKvjFuJcmg0bRe5xjsWpacgPsLmX0jk89GLiSegD+l5sToIMDbZjE cxoNmwwc+nREdHE4N0fz6VijHH3okMb42Rcwe2mM00zv4mvCWEOIgv6M5Xnw/SSgWEQeUTSSYaWB LFZ8Qh6RBskjqlfII8psoJ2MKNLAy8H9SHuUzJH+REyKQyRNeoksUZSQo9Jysgg8JH1MBqVzpJTG YY/tGulrMh9VjZKjNE5RIec7Kv4I1/hJt/gY8Sv+BGyNo4Qcke4macpxUiptJ1nSvSQN9yHYU8wW 08kZyUkE7BY3KbfKz78KBmO/tSHEgLXgSoT9JA9KTYxIySMpxEMcWI1aSIAkk0TiIj7k8BKRZKB1 OYkGM0YrSSIh/IJHSbLwWyUTCeL3OHqSSuxER3JJAUkjOfh1TyYJ4zvc+AaCOfv9Qr7wR3G5pJUe lt5XfF1ZpzylKlD9WL1N06J5XOvXvqBbo/un/iZDrjHJeE+CM2Es4T3TS+aV5vcsN1oV1h/Zmm3/ sE3ZtzqUjqcSjzjTnTc4H3W+6gq6Ol0b3UVJQTwLmdws/QyrXwllqSQdpJMsfooYsU2VSKqEkycd jY2aXPXT2IISiQ+bWBoiCA0Rk0I0nkpKqgucKlUdliyt40LuiTr1YWzP1k28OvFc/sSrF6yV+ReE /N++/urr5nefs1TmF7/+4uuFBYLFb5FhTxDVarsqkJYnloaCZcXFRbViaUkwkJYgynElZeW1UnFR qighJ4upFWlYkH72ySKpa0Il7g3ULShWpiaZ7EaVUkx2WXNrMsw9izNq8lLUklolKTXqzPLZaW1X NKX9Sm1JcSSmWDUaa0qiI8Winvi1MuGjvysTPm5QXPHxEUlVvaQuXfqyTiMqVKrxVJc7u9rfusBk Myv0NrMlUaO2WgyZjUsmrnUk03skOxzsXhMdMEtg6iPFXqUd9Rckd58m6VNvnjCYhfbAeFwEx6fe OaFHjJ4LnJO+E0miURlm+mmUPw3yZyRTyKDJOXqhIz0QzHjPoDe40lICOqOQqDAQg9kgPh54JvB8 QAoYAgZrynxrn7KP1NXVWSsr8/MHBy3OSgukpdh8ochSDIuHB9neEk7gMhITVbLJQ5JfSpACacFg WbnA7OxUByT0D41gzvB6M2xaxfqJP10m6WyB5JQMk6ARYgqjO5Tqy05KUOwSfid8Z1aiJ0EhqQ1a oXryh1qjVqFM8CQqYvoEjSRpTPrDE7sI2tQj6D8CWlcqWnUF+UEkyesyCx1es4l+GPHhMuDDh7Li rb28SGaSI4J0RwTpDoc+h2bOoZlzaOYcmjmHZs55UizCfszZk9AkWAxLH0dO8DvHkVlm5Af/6zgu kdORs3hcNEeM9+nP6kV9Uui9wkJ1+riAtym6S8YF/Zi6l9RdqJPbbaWQP/i6bLWiF8NMoDmHw5VM w6j2BEXAnxYstZSUFfvRKh20PadKQkmeGAhYaGO2XZQKwVvRNbKxdfIxZ1aWUwhuOTJSlBiuzy5d 0pQ5OZFUsWhu7FzD/DJ3Z8acy7uf+6i6vyEobJ61an5ttsMbUuwPeXN6d3bk9c6psOpK568Thfz2 0uTJwUB118Rvq/prvJMVyeXz4YWGp95RGJSp6MXLjyeT6nDcKmDZKuC3j8Mq4L9Sq8jpsEr4abEY 3skl5MNjBYWcmK1HcUbIJqWkQMgb0y5Al37xAoWQz4pvfvlcYUGGPYF13hK5W6qoAWg3pR3YYU9F V2XdVWEQlRp7ZNmu1r0/vrmj546fXlVx2aJmj0YpKTR6TUJR18auBYdHy0tHblncsbm7xKTWqaRT Zpc1wZ4V8vR+/d277//k8SUOX7YnwZZktSfbtKH8UNO1396961tX1QfzgypLKkq+eOqvih1KH6kj X42kJCebXLTduGi7cdF249KhuC4zyuoaFy0RI3kmJPhCkdBQSAqZ4lYCy1YCy1YCy1aS03GlaVws OpFfIpS4xgXdibS0yvzaM4IO/lMnZMUqe+zjQs5YPmwlWwodkDq/eBt6cXDw3HQjktvOpyxVVm6h bYlaUm5LFtq6qGNktlUodig0BrWhYumBRZd/c1td086HV9TsKp180WJRaNH/vqJPtOqsVUuWjxbe 8fbXFgw+fOGWuftXNCXpFEttKTZNMC/Yeejp9bvPHmxMSRGuTEu3eSwajTnZOmlLCqakuQyDj7xz 5M6PosNJgaykNFjzEfizefBn+WT8RF2hEDDETQSWTSQzzAqWu5ecDhMZqHGTnel6an09tb6eWl9P ra93IYOe9j8niTjQaSM2+mG24PwjgnTipC8yIIHyE0hzZs9H58yJmM4ahBcMguFST5c/uPFCnYAe +SLtpcy4ReY4FxYMonWyQQPDzbRk1hQdiONSMU9j97uSfHbNxHEotyvNrtHY01xuv10jdmjsviQX VBKsr1SqDRqxduI7XCt+xdXER6KKazpPgM+T2mC/JNJymjiYa8LbI7LtZIZRwLLtwG8eh2kcsN0J ojXNd4wL4TGV7IqE/POsRHJvE+P+hnUrFIKOjW0KeN6Jc84s/tDCC9QVt9k9Ni1cx2P8sT6+X2tJ lp9t6iNVGP64hjwSMQ/VbqgVjQUFzvx8XZ7LlRSvZ7D8rDLjWcHys8rpeNYkWs+p6YUGg47WtI7W tI7WtI7WtI7WtO5JnPPCP0fcCJD0sm69y2nMdxXmqbyZ3d4+PmTVWTFYFaMiuZfFiMVr0VJsqZyV X1xMx7AZ9RkQ6LiVJ4aEwIyapfOHVNEpFNPBjEqHKqyxe91Ov00jThZLekeK3ZFq14uTcwTUqtvl s6lzPKt9BekurbBdKVyrT/IG3WtNHpthurIVqz4+otapJQVcEiYJR7ktFQ9kpxuSMj2fLJQeSM12 67W2FEe81+xVWsgscs3xkMlkjxtTZhhIZtgI/A71vnIYxrHLxkzV5eUVUWMWuZC3yIWMRWbkKqLG LKJZzCS1Yr4uzxRSuNO63X20hWDId1ZS48Xb/UXb5cNmchdglgoGQ4HERMdn2CtVchYH6SgWb1WK vUZHkrE8KRQIOCZX++qTRVHU2Lwul9eqyUmanxLypliEqpSyokKXIApIcSf6rJo5dsyK9ClFIfG1 yj3VLXfM/eQfaiPtMUa14puZaTpnlnfiByUjQ4P5Xce6xKcxZ1DAcakJ5k4jUxcUbyr9mDmHyO5I kp3awE4blN1OjWWllqI2gJmKI1ofZsn7MKtIjRsXLLdUsOy0wbLTltNxVeoZDG064oaLNvUEaM9S yi56eih7Me6iL3rluM8V1XT4njGWKd6ce/urR2576cbGuUdePXLzi4ebToYWf3nDhi8vywou+tKm jXcuzRTvuPuTsWULH/jXfUc/enzZgm/84+F137qxs/emM6s2nb2xo/fmp1Be+FbpWfS/ZKwBdoyl q+IFAcsFkRkFB8tdTk5HQVS0CTgtKdQ8KdQ8KWaDUWhPoXOhFIxMMWLJwLh0XKUyoJj6445uA50T xifhrIHwjhUv66XdB95EIReZTV6kZyPbH91xu9bmd1NXmJ0kOLI71qxtzzpZvXAw596vdK5qTpdu H75rXc1k3nS/QFWrnXVLrlzYdVlJwsSHmXNGWA3XK69DDYdINflCJEXnt2bSUmTSUmTSSs6klZxJ KzkTJYnoiC+5IHlfspRcFDcOWDYOWK5lsFzLcjouQ/8oPmH164y540LWCWdPhqKcVrWRVvWL56kR MJ9jfeTFiyNxZWGBMj40hNikmFc9m8sp5bncjBaAUugMKvvAloO1hXeM8JZw489vbrFl1Wa3rmvJ tGsmH/l0o9jk9FpU/rpFNak5Cx54/747P6Qt4+93dx85uCG3piHNZAuIr6176sbOnsNPrt70zE1o Jt+iVqNjsB7tpIw0klsjqeY8S7kGRS2nViuX676cWrGcmq0c5T+VRefNWXUWaisomZFXZhgZLDco sDzeWNCgYsl55nFB88SGiBCJOGeh3Zz0dzvjqwnadAYvTBtuxjwYhuPDa0jKkzDdvTjC0slwojNV ik+HnbbERKEkGAoG45NihV5lT09N8tv1iu2O3Nre6s28iWFebCusT2rb3BkKzF5S6SvJzbRvSdBM TjTOc9cV3/pQ48hsL1yzBp4DjrGwZGFdYOKX003vsZBXKRkrFqxvqF/VVWVPCNd0Fk7+Pj1FuqZ9 jVOtmmz3V8+Dj54zdUEaQVtsJW+cJvVYnpmw+KqnJoOJZIbpZEaTBMumqh8XcyLhoojNLrQXRSxY lRWlFxk8Lnqthw57HjOu8lB37aHV4XkS71hh7DvuwdBHZzXuONsZP2Gikx5D3hkhRMoxfQxG9BZf uVAe0RuEdtTP2YiOqnJLuSWxZlwwnKz3KLN6EtG2494L7fmChS72wuFB8wUznNmMWZC8CuRTomm3 puBtmy2z81Tx8Ken7SpppGH7/YP16xdWO/WYdGoSiudtnFsx2JBeNH/NutXzi6vX3NobXthRY1Mp REmlV+vzGweryuaVJBX1XLbusp5i4fLFX8DixpfmyvBiva1Oywykls8rLu+sLiyu7d3Y1X3VglyT 22vTW1w2K2bzyYGUlILZGWWdNUXFs3o2oo5M8JCvoOWnkRWnXBGY12WhVjwBRWR3CGPLbhKtW2Yk gC91l3T6YcHyEGkWlXVcyDyeEveIRZg1visv7b4XNp8Lxy00Y5bo5xNveYL1CiZYmskjfG4IZdQo lfiQDmow0VKcsyVbNB/fM90Ql2ssyTYb2xyg86009OPVmAumk3WRlHTahTPThSTKwSQhE2tBo5Dj FnJcghutTW6OsqDO3cVjqIhYaZTb5XYFM7zzXUrrfHnRb62ss1gF1hbCKAwZHBQGBwex5M+Qp0mK kIAlftmMyVERtgDU4ilFgjuUkuh3WQxqaXJAI1gz05L9Vq1C2CwIayQNOqk33ShpUulyXlAosVRT xOQFv8ao+/gZRR2Npwt+6quWoFfVST8ixdhQjEZ8ptne2fmzJb3WWWJAnyihXaSEdowSM+0yWGu/ H0kgoZCJCAZC/Rmpoj0QWcFv0p4oMy6gLNukalzUROwW5/dIiblErD5bIhCsxEry6rPHBU/E9EKa kJamSHkrb+6s3xg6FCQ/vo4fvEAXYoMblw7yAf9ceOlgZT4bCYvgyJZiZkmdP+ZApTMGgeLS+Ogf X4Up5Cmlms0HEouLysqlOnOyJ8mbUH1r95zN3bm1Wx5aszuxsLNy1nBroUGDCY7aM3vBypLh63uD Xz/cODrbOzCvfv0sl8GAEdqwqK45o3llffuGuRnNJfNKPSmBFI3ZbXKnJAVSbDl9e3vPOXPrspp7 ZjfCukdh3ZeUG0k2nVmerKsTdP6yeHMHy54LLHsqGpbtVTYufBDxOMJ0ZA37YNEwtX+YjhhhavHw uKiLaIlDV1bqVygLxgXlE8G5nmZzeyXkmLKDLmPp7MEJ/x+fXV602SA2P+TFVYiv+S/OHy1sL4lP ntSWRFirVpReKh65ZTDc2twc0lg9DkwXVWqbz+XG3DGzraUlc/mNCzMfc5QsiPhqI02hxt0Ntf3l buGNrWcONluCVVnr0L0UCqy/lBXyCICPiT9mVQTMnQeiW5v2j86yZs8umjzas7BmZBf63CJYzCf9 EBsYN4wlyx4Y5Qa/RtsW+M0TMAYJUaMhASzPLsDyrEKORwbwW/SC0LiojxjzE4QE9xveiM7Y4sW6 VDxhmyv9pZD6Ja2xpTBnXFCNaWG2iRfDdAMgfHHxfw6+puiztkvk3ZNAGjxw6vRmieQTlWp3TVt/ /vAdK0rrNx4dCHc3lrq0KtFqNIVq+qq2X+WPDNZULqgLG+jS5KsWt8XozkixRnYd33rNMzurzUlp rgSbyxry+jP9px5beKA/nB4OaGwptJ8OwS534c2pIHaIbox466oFvaeS9s5Kum6rpKNYJW0dlbSx VJ7Be7SE5DOr5ceNBZaNJTMukuORO582KJ3N36yvDHkUCeiWyphrLrq64nhCBzb20Zjk5oTVSnwi Fl+zoA9eXNzN7IKYRkyvSiTMH2ZMxMqlu9SWZDvdip1zdPHITQszi5bfuqzrQERt99I2pX2gYU9j HVoQWlS9f1akOeTmDWh7x4KOA2PLt5w5OKepQdTzVcpEE9rO8t2Rxv0r0JYaMHyLZBDWOgqvFsaJ 9mOR7PyyurL1ZZKN9iabD1ay2fw5dMzPodZi25Oyf0Nb+PBkY/jrYZFuvJ2kva1EEW98YLmNyWFc BmYOTkHt5/fnPLtPcYtCPKsQXlAICkVy/m+Cc11vDSVsSBATtG8lyw1skO1RDm7cxJ1a0W/DbBkj 71HCoAL21f0zmhX66cy9OtERKpMNqpaOhtwTsdTmDd2R0dZ8g1qvkkRJrS9bsDGy/sFNVTUb7xu5 7ItDuQ9IV26ftaQ2DYvBkL9tx4I8R5JDneC2Gm0mg97tstXuHN+55fTVTY2bv9Jv238kr31FOd37 LZ28XbpB+gGpxZnCMvJCxGHNnUPb1xwNzDbHZ7YJ7XOK68anPqC+Hyy3LPBrT9CkOnUXZMRosgrt XR6FqUAqVqupHdFMPXSWZITILVZ7POriXAXt3pESmJT006/o95lxWX92RkQPzjAVqKWKub8y9Lzp cAxVSH+uacn2zf5lxdzFv/R1xTd96+Sx4sLLzOmFi8+Hw+fCTkyy6DTLAk9oPh/GvzD/oBMHVYAu q2VvGMQawmFPdMbnvnz3rhwDC04y6CddYSc6MT3GhHh6IKHbxMFQKAETZuYob7CZrg4kFw3u6ywf 8Vid9WV/adgwP6/k8gc2rj26PMfsL/QV5hdleNNLllzdnjXHK5gtlsnJFYMFc/KdKxYXtuQ7e5Z1 /9mX5dIe3Na2otYjbQl40xfmd+7oyUlJtOalBvJEneifNVBdu6GvMCMyUOKvrSh2u9tzZg0FMwZn d+zszdVq/JPvLlnlq2jNHFjpLW+ZWFpVJ2rcuVmZjvqGlIJaOqs5ijnafRiTisiVJ+pKhGwbdQ8w PpgNQBDyhIxGUCdqowOSM5VtBVKXw/YD5Q6jp2k6tguI/RQsSVSncuemN7vbZcchr2IF1ILsMdgw dInXsMhjtUo9YxnC98jYzMch3aexstHGlddaULu7EUF5C4gPQnNuaV20q93vptMcui0tmjqWNqb3 903cyGNmjjxtrbNW3jBMfcQ1Ux8J3cp8nPz5yU2n6gJdgfUBKZEaA0UEyzaQw9jRBMuNFyy3dDke Rks8I27EfoCDWerfNwbjJsXG4AdP6Lz0ZAQ/L6094Ta3yvZ5+UI47lTjIzWmgRdd6rQPtdGzNtoY 0QqF2k8bwJZTXRWmmDaBdBDjLYxhUAsFVdlZlQCv+d2o+RLyxYihrkzIKhQKI1ahA0PhC/LUA0Ie Z8Fv0X4th1HKwjP4RUkaMcRL8/l7yGgMSYm5uYQWlDWKxDS9MrM1udnCG4S8oMfAipmcPJUvek2e 0KPc0wUPCZ/RHOInXQ67Si0IiYnSbo0tLckTcJlUkwc/bRGhV2N1YyM4zaE1miafFNYZ9fLyU1Ib tcLfJ43/3jA++ZmwTWfUSnCgWoPLPPnkZIbFEbeZUAubOUjkVJ2zy7neKcFdyf0CLLcROiuhHYjG y2YkqO0TOnOzXMXx+v3Mev33upyuwottNv4Uyhcwns0jb0U8VnoYYqMjV9BMF5shF/3cMF9ontFz p7s0dblyT0aVgOVpkdyjU1MT0dBTU4vYzi/t2Gz7V+7YOoyEp+bRFfO8Wsym5ILOmF3J+xQI89mX bJDQGfx0p4iYBVWsbS4mWqqIsX5ubXNuRWtu+7RDQP3T+QSfS1TGd49xyBw/CqD+Qf7BId+owAyV budd4iT+LSLuNRzx9RKbyjqULzDnYdPYcxrzKjc3aTBzxb6yOjGnIa9yy7QvUVmTnYkpZnX7za0V A40F5tzutjnpC7e1eqfrQwxUfsqr/HsMlpV6NCGtXrO9ryspvz6zsDHbBnfTzr0uarCIHImYWA3S aow7YNmcM2op7nen/XC8NunCIFVP53rscIaOljNPaIQPTsVdMXXEEV3u3Gx3eis3PdabMDs3c3xH MW7t/87Wl5r28x3ytBG/1PE/OORLDAUDDVF/TGf+r8JCdDf5oUhyXZaQaRWyLHSVHTQIQY0QVAvZ kpAlCvIOMYwAltsfWHZb4Et3kOnELDVfJ+hmbE3TOeCMrekn8bs17PecMpGODagm97ggxExzsQ8r xpdSdDUQb5n8TJD6qvgfX07xLRq+eOILA+nVqs2Pblr/jXVllZsf2Qwuf8xTe1lX65pGv6fusq6W yxp9wh/Xnb62bfbeE5vAc8G7W/cvryxZtr9j7v7hypKl+2Gbo5NHpJdgG7qO3EfXkf4y+hoCHanA cuekYdn7QMjNBT0Yw7aDLSHlxaS868VWk5+5hmw1d33uGvKzlpD/7qUdn7+EvG1pZmN9JJ27ajQW u8NjVWe1d3TnLj9El5DF8hKyOdS4s6F2oDxJ+PO2pw7MMaeVBCZr+cpR8Wd0LryioNdemV2b5Wg/ +PjWpqtHa2xZDYWTd+J9wdHdcW8pPghrFZORExtKhaApbiKwbBkwMxUV1IYmaipr/FgTLo/QRkKS YMGMiDY8N2hy+FoddCEkOy8hn64L5RkN7T28CdB54WfMY5hJVOKDokqr0ThT0h3ugtKqwAw7yJ4n o76qMsXoT08xKCRBWp6YatFqtRp7Xnv5RJQPVxe7zYGyxpBJ0uh02gQPLXH31AXxOZS4lTwXMeS3 1bV1tV3V9nibcsb2qNxI5DCcBvjscUxr5DB6ksxwR/Xjwm8iXrZHSgcED11cxrdIkeyhDsfzJH6Y SY8HdQgQQwTxmBCcjQRxvzrD4wbRkPfbct1fLPMsQ5YNFolthf6a7oPOTXyTbU/AjGwTNL4Fipdc +CEikvLjy0w6F4ob93+9BSo+V7x0f2fBwqaCRJ2CbnGG6xZUZDcWeUKReX3dkVDW/F3z01uqshxq CWO9TqVNK2vNz45kOTIj8/t6IiEhoekK1LfTbU/32pLMao/PYw2UZQRLMr1p4doFNaXDrTkGq8Ns MCWaLW6zOtGdaAsUJIdKM31p2TW9tC78U38T1yoeJVVkyYksYgnk0kYGU8kMm4LlugDLexgyw4g4 APkgYnAacy8EWlKMF5wthViBj6nl/ZwLOAkR8BaWPFUqOn+ObUqw9wws8tQQThobX9xVy1tedIlj YUsTGhbXasy+rDxn82gkZa/JSvdB9/A59Bt018tqeqN8jjM92a5RapWKxSlp5gStKgOb+mKCL92W ZFG/zA//XlZbkmzpvknd4DKtTqtMcMXLrfhYiV9ukoGT8+vri0aLaYHcncnBIlKUhv+M/Z2jLUuX qoqDnRf6W3DMo4joWjpy2pNbEi+o5sS3reouFBVhKYy9huJztCngXPQ8Xg4owvwgH8u2eBEV8YUb W4w5ZhSX7W6V0lcH5EUZS4q/kvFZppKqAi1rW9Ma0g1wLCqNUhMu8GSU+Ew/pJvFVtOPeEedDM8w zudbUjo1uPS6BVlGk8HmsdmcCUqr3lXcXbWcWeyTv0z3ZcdF61lT/JbPNfXUFG1R0t+U+WIQO9H4 IR/ecsRv+VhLk36DllZPZsXy6zHkf3AinJoahjf7MGKQSsP1LebwherSFrzfojie0aFlWznnLxTB ukW/fR1mhmGpVYtmni//7y33UGoi5lNOt8+mmcz/X1rHk/TJl/6vbYCyHqH7X9JTmD/dht2vEkEf ov4pRP1TiO7Ih+RZa4jOqUIo/xOETl2JN+7gwXKfA38gD5JU0Dk7zcAj3mERMJ7Wltsa0ivdrZjE Ki9uglHvz+et0w7rkuUs3wSbXrlZ5J0cvCPEuya2v6wpDmeKRdVxhzxNUtt9LrzRoHHmtxTU7mrC NhhWt1bt9MRze19nzaoblotpfG458V7XsoaM/j5xK4+hbQFnFdIu2CeH/P40XmrEyE8XBV4N/czw CqlMpAryAhYFl99lAfNXGTD5lMdGa5wtMEykHBnKMQOzCCGzkKkU0jIRMStNSE8T/FTW+YV0v+CT Y31Cuk8ImYRtfsGP9WREa3G0+H0YExB6M6LFIOOnO280RJeW4HciBtzDn9nq1ye16tnwCvvKPo6E B+VZVpiehwyG6blI/E1Iej4SpsOCevplkumXrUSnzVluY3MQaZcgSuLkeYUxKTM1NdOdoJh8TqGk rz04UwJ4Q3JSIX0sYtfT40y1qKV7FVqdQf3Jw/RoRKFJ0EkLDVathAW0iA/tRJLBIP5JCw8havTU 2qVTHykPwtpN5NXTOJg8G5mFomF/G6e4FUI55Yw8IegXgj4h6BWCqUIwRQglC5kKIUsSqqqF6iqh OleoycEPkfDaFP6HN/LmAmVsUiPChzuYMTuRoylHcILUYaLRpvpWOR81Zp25y7zefJVZYY5YE1vM xa0ZrVW35Ag5NC2HjslmW2LLqpztOWITYp3tsgd4iVpy8Fxd3XlYktlbtrl8AMWOoNjklhkay+34 SztSSC2/d0rf3+GbYnhv56LJZ0jlQYVy8n3J6MxM9Wa7DdK3RPFxyZiUleoNITT5oVJBPUdymlUj /VIUnxW1VjR7vKciviIKL4s4V05y4UVf6V613XSxUsTDWu3E5otVZLKrtXrUEFb1E0laLWrIiGEd Wx8TLh4SNZjeCyQLvaMN9ZVPrj1NCmEYC1pePvUbedRjVOcJOKd75wnIEpeAt9hk30C7ihyVKGhp a81GMqHX1BChIiCU6QW9jy7FaK3o9YUFWa0BvSWlle90UG9Bz/dg3PjZHsxO/9GGnJEoH13BlNLF d3kvHvfZ5EZMT/sEqUFjC3lTAw694hevKPSONLzSaxG0gmvyfY1gC/lSAnad4vwLCp3F60nJsIra yQ9zEmwGJXYy1MKKya+AJKXBliCcEh5MsBkVkkqnnhwTukCSQm83TS6l3gPri92wTzqZf5p4UNZS FLPcI2R5BJe80eASggllCWJIKyTRCV9VkuCuAFe7BW+rW2dr1bUpukgbfa0Jc+Q6dF2Ukh1mDob9 EjudK7fhXSYhWDJ9pGmj05XERLtaLN6hKixK8llE1W6tWZp8RmNOT01Ns2uVgiB9oLKk+ZLTLarJ k2aL0mBPECoVVp20xOFKUOJlZeNEnviyTa/ELMSKlRKRTsm7enq8h2/HzyTEjSdUWsnQQupePQ/f zXZ+p/fShG6+dzb5uOJ8fKtscgwWyZ58VdhMXsMvA3QxvTOZmF88z16dUKtZdyi38emWsFmV4LTc oDTa3DaLUycortG70pPc6U79zd6SvFz3c2odphZoloJtn8dnVqnMPrrePTP1vnBY+qK83vWMEbwk teuULjWA1boJT3u+Do9b/Domenx9wb9uetUVH1KEw1p3pteXiTbvyvR5M93aT4clny/Ho9d7cnxp uZRzJzL9LAK/w4FrS8IPPQQiTL4h6ZRPY6dLM2ZWEjrdcsaLGt97Uz+kMNpTHG6/VaESBxVGW6oD JzYK5btGk0ahNtqMql1GkxYltdPfVTQJJ8Q8cRZ+K5Fwgqj1F3C0izksrCifcLAqoMf0Yp7VMrnU ij/hqziWVwofhlK9wWCqypKEX18Q/O7fq5xLevHbcfp7+fyIrnVzSeoO9yK1ad24IJ3s7MjKMmHZ qjrZ2DH6tqk5fiSAY2Ts+xcW2GCl8jyJG4/OG/Gqt7NWKp2OisfhZFg+EGBvKLITeAHDN80bP1GW 4ucyuCG2/YUrUiOrWjMrM8zZg7et7r+6LxzsPTCYNm/h4hyM6Qa1GS/Yee3wZYWpuQ35Xp3OqleJ SoMvyV4Q6avMHlyzuaFu41B7KYYGkzfX2zpS43HkNReWtuYnbgk0rmzI6pwT8ZSsGhrIKGrIsk6+ LvSVjwwuzCnrb28K1G5cWBxsHplVvXzJ4qKsgUULMz1NHfOy0rGHqRDVJqO74opVSzPTC1INosbl dqeadJqEQE1eWlWWMzGrtmu5JHoqZjWHs5oikfSU0iyXJ7dmIrNkQV3AkpLlzB1ePpznq6uLSNeg Hldh5nUb3rvpF5SnsUlzNpJsEjuGFgmFGji/QroiLJTfaSqk77MVjoulEV1nT7Cz04WxP0LH/iCy BOmQFEFsMCIleOiVbC0pX+mhV+JYSPa6nnEx96TsZum+6gl8F0mgAyGuB8srKfDZiA1eN6E6guhq Oji251cLmLOcpfkoR3Q0stpSbUnEgboeraYn5x8+n7KVvoyjn34ZJ/9CpXn6fRzMK+hIiBdy2EIL DUg+QcIRUiXb/6COLd4f8RYOtuNT5eNfuX3wYyO8wkp/DUN3KOOLkZJaVXwZIqodqZJ0W+2Wb15e v7G/yqRRSQlGbWnP+sbZo41p4Z4rO3bh5xdqlT5Bu3H2mtZQUkl3adVwe5GOenG8qGyr6lsfWXT9 4lxf7aLqhvXzcoVNAzevLHekeBMS0DPTk30ZvrTavqLy/kia2pzksLlN6rTIQHlma5k3kBlQmjyJ JqclwZYecOX1bp0za013pV5Ul867XF5PWFHb9E9F8KuvRV2N83sGwg3DV6xZvmnN/wFUEaB6CmVu ZHN0cmVhbQplbmRvYmoKNTYgMCBvYmoKMTUwOTIKZW5kb2JqCjU3IDAgb2JqCihPcGVuQlRTIERp YWdyYW0gZm9yIERJU1BBVENILnBwdHgpCmVuZG9iago1OCAwIG9iagooTWFjIE9TIFggMTAuOS4x IFF1YXJ0eiBQREZDb250ZXh0KQplbmRvYmoKNTkgMCBvYmoKKEppbSBGb3JzdGVyKQplbmRvYmoK NjAgMCBvYmoKKCkKZW5kb2JqCjYxIDAgb2JqCihQb3dlclBvaW50KQplbmRvYmoKNjIgMCBvYmoK KEQ6MjAxNDAyMTAwNDI0MTFaMDAnMDAnKQplbmRvYmoKNjMgMCBvYmoKKCkKZW5kb2JqCjY0IDAg b2JqClsgKCkgXQplbmRvYmoKMSAwIG9iago8PCAvVGl0bGUgNTcgMCBSIC9BdXRob3IgNTkgMCBS IC9TdWJqZWN0IDYwIDAgUiAvUHJvZHVjZXIgNTggMCBSIC9DcmVhdG9yCjYxIDAgUiAvQ3JlYXRp b25EYXRlIDYyIDAgUiAvTW9kRGF0ZSA2MiAwIFIgL0tleXdvcmRzIDYzIDAgUiAvQUFQTDpLZXl3 b3Jkcwo2NCAwIFIgPj4KZW5kb2JqCnhyZWYKMCA2NQowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAy NDA2NzIgMDAwMDAgbiAKMDAwMDAwMTcwNiAwMDAwMCBuIAowMDAwMjA1MDc2IDAwMDAwIG4gCjAw MDAwMDAwMjIgMDAwMDAgbiAKMDAwMDAwMTY4NiAwMDAwMCBuIAowMDAwMDAxODEwIDAwMDAwIG4g CjAwMDAxMjQxODMgMDAwMDAgbiAKMDAwMDAwMjAwNiAwMDAwMCBuIAowMDAwMTE3OTU2IDAwMDAw IG4gCjAwMDAxMjE3NjcgMDAwMDAgbiAKMDAwMDIxNTI5NSAwMDAwMCBuIAowMDAwMDAwMDAwIDAw MDAwIG4gCjAwMDAyMjA0NTEgMDAwMDAgbiAKMDAwMDAwMDAwMCAwMDAwMCBuIAowMDAwMjI0MDEz IDAwMDAwIG4gCjAwMDAwMDAwMDAgMDAwMDAgbiAKMDAwMDIwNTIzMCAwMDAwMCBuIAowMDAwMTIy OTc1IDAwMDAwIG4gCjAwMDAxMTc5NzggMDAwMDAgbiAKMDAwMDExOTAxMSAwMDAwMCBuIAowMDAw MTE5MDMxIDAwMDAwIG4gCjAwMDAxMjE3NDYgMDAwMDAgbiAKMDAwMDEyMTgwNCAwMDAwMCBuIAow MDAwMTIyOTU0IDAwMDAwIG4gCjAwMDAxMjMwMTIgMDAwMDAgbiAKMDAwMDEyNDE2MiAwMDAwMCBu IAowMDAwMTI1MTY5IDAwMDAwIG4gCjAwMDAxMjQyMTkgMDAwMDAgbiAKMDAwMDEyNTE0OSAwMDAw MCBuIAowMDAwMTI1Mjc2IDAwMDAwIG4gCjAwMDAxMjU0NzQgMDAwMDAgbiAKMDAwMDIwMjk0MCAw MDAwMCBuIAowMDAwMjA1MDM5IDAwMDAwIG4gCjAwMDAyMDI5NjIgMDAwMDAgbiAKMDAwMDIwMzg0 OCAwMDAwMCBuIAowMDAwMjAzODY4IDAwMDAwIG4gCjAwMDAyMDUwMTggMDAwMDAgbiAKMDAwMDIw NTE2NiAwMDAwMCBuIAowMDAwMjA1OTYxIDAwMDAwIG4gCjAwMDAyMDU0ODYgMDAwMDAgbiAKMDAw MDIwNTk0MSAwMDAwMCBuIAowMDAwMjA2MjAxIDAwMDAwIG4gCjAwMDAyMTUyNzQgMDAwMDAgbiAK MDAwMDIxNTQ3MCAwMDAwMCBuIAowMDAwMjE1NzMwIDAwMDAwIG4gCjAwMDAyMjA0MzAgMDAwMDAg biAKMDAwMDIyMDkzNCAwMDAwMCBuIAowMDAwMjIwNjE2IDAwMDAwIG4gCjAwMDAyMjA5MTQgMDAw MDAgbiAKMDAwMDIyMTE4NCAwMDAwMCBuIAowMDAwMjIzOTkyIDAwMDAwIG4gCjAwMDAyMjQ5NjYg MDAwMDAgbiAKMDAwMDIyNDM1NiAwMDAwMCBuIAowMDAwMjI0OTQ2IDAwMDAwIG4gCjAwMDAyMjUy MDEgMDAwMDAgbiAKMDAwMDI0MDM4NCAwMDAwMCBuIAowMDAwMjQwNDA2IDAwMDAwIG4gCjAwMDAy NDA0NTggMDAwMDAgbiAKMDAwMDI0MDUxMCAwMDAwMCBuIAowMDAwMjQwNTQwIDAwMDAwIG4gCjAw MDAyNDA1NTkgMDAwMDAgbiAKMDAwMDI0MDU4OCAwMDAwMCBuIAowMDAwMjQwNjMwIDAwMDAwIG4g CjAwMDAyNDA2NDkgMDAwMDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSA2NSAvUm9vdCAzOCAwIFIgL0lu Zm8gMSAwIFIgL0lEIFsgPDgyN2IzZGZmYzI1NjhjNzkwMjgwNjcwNjNhNzA3MDBkPgo8ODI3YjNk ZmZjMjU2OGM3OTAyODA2NzA2M2E3MDcwMGQ+IF0gPj4Kc3RhcnR4cmVmCjI0MDg0NwolJUVPRgo= --Apple-Mail=_87E19733-3E4F-474A-A8B1-169B0B6F1F71 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-8859-1 --Apple-Mail=_87E19733-3E4F-474A-A8B1-169B0B6F1F71-- --Apple-Mail=_D1597216-296C-4A84-9595-AFA16499F0A3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJS+FbZAAoJECAtT58A/2SKYJcH/jl1zlw0bEgz6qZCey5JQIc5 gJupXWo9etevUQX6nxodx6CvkVWPuvLstetkQNnBoXvEfEM2+ElSxQDnZQXqRmA5 7KmYqXU3L/AEwDxVBrkhC4xL7G6fnVW+tlLccDOGQBoUkXdLgnJY+L84KuF50f/x RNLm8USTKiglvhhbJsyZIfTmGSaymH7PzI7iv5vY1qDzfdoDyGvxw0IEmLM38XHp ZneNneZRywDqNu8SOC4a1eiOk7a58Cfl5PmUd90BnQvfLajD96ZyepK3IptSHWv7 HqueIv+QooiB7nQCOTxjHEky6mc79avyTXhyMnGidieSw1yEjO/oZf37G8JqMW8= =HHr8 -----END PGP SIGNATURE----- --Apple-Mail=_D1597216-296C-4A84-9595-AFA16499F0A3-- From andrew.hutton@unify.com Mon Feb 10 06:19:45 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005861A05FC for ; Mon, 10 Feb 2014 06:19:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgJxJ6MEQIA6 for ; Mon, 10 Feb 2014 06:19:42 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8E61A0865 for ; Mon, 10 Feb 2014 06:05:38 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 18B8D23F0682; Mon, 10 Feb 2014 15:05:37 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.100]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0174.001; Mon, 10 Feb 2014 15:05:36 +0100 From: "Hutton, Andrew" To: "Ram Mohan R (rmohanr)" , Gerben Stam Thread-Topic: [dispatch] Lossless Recording in SIPREC Thread-Index: AQHPI1dDJyXBrcc2c0ma7EaQoC0IX5quiwsg Date: Mon, 10 Feb 2014 14:05:36 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17CEDF53@MCHP04MSX.global-ad.net> References: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:19:45 -0000 SGkgR2VyYmVuLCANCg0KTG9va2luZyBiYWNrIGF0IG91ciBvZmYtbGlzdCBkaXNjdXNzaW9uIEkg ZGlkIGFjdHVhbGx5IHNheSB0aGF0IHlvdSAic2hvdWxkIHN0YXJ0IGEgZGlzY3Vzc2lvbiBvbiB0 aGUgU0lQUkVDIGxpc3QiLg0KDQpTb3JyeSBpZiB0aGVyZSB3YXMgY29uZnVzaW9uLg0KDQpBbmR5 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogZGlzcGF0Y2ggW21haWx0 bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUmFtDQo+IE1vaGFuIFIg KHJtb2hhbnIpDQo+IFNlbnQ6IDA2IEZlYnJ1YXJ5IDIwMTQgMTY6MjANCj4gVG86IEdlcmJlbiBT dGFtDQo+IENjOiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBM b3NzbGVzcyBSZWNvcmRpbmcgaW4gU0lQUkVDDQo+IA0KPiBIaSwNCj4gDQo+IFBsZWFzZSBzZWUg aW5saW5lDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBHZXJiZW4g U3RhbSA8R2VyYmVuLlN0YW1AbmljZS5jb20+DQo+IERhdGU6IFRodXJzZGF5LCA2IEZlYnJ1YXJ5 IDIwMTQgODo0MCBwbQ0KPiBUbzogQ2lzY28gRW1wbG95ZWUgPHJtb2hhbnJAY2lzY28uY29tPg0K PiBDYzogImRpc3BhdGNoQGlldGYub3JnIiA8ZGlzcGF0Y2hAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6 IFJFOiBbZGlzcGF0Y2hdIExvc3NsZXNzIFJlY29yZGluZyBpbiBTSVBSRUMNCj4gDQo+ID5IZXkg UmFtLA0KPiA+DQo+ID5JIGhhdmUgaGFkIGFuIG9mZi1saW5lIGRpc2N1c3Npb24gd2l0aCBBbmRy ZXcgSHV0dG9uLCBjaGFpcm1hbiBvZiB0aGUNCj4gPlNJUFJFQyBncm91cC4NCj4gPkhlIHN1Z2dl c3RlZCB0byBwb3N0IHRoaXMgb24gdGhlIElFVEYgZGlzcGF0Y2ggZ3JvdXAgYXMgaXQgaXMgYSBn b29kDQo+ID50b3BpYyB0byBkaXNjdXNzIGluIHRoZSB0ZWFtLg0KPiANCj4gT2suIEkgd2FzIG5v dCBhd2FyZSBvZiB0aGlzLg0KPiANCj4gPg0KPiA+V2hhdCB3b3VsZCBJIG5lZWQgdG8gZG8gdG8g YmVuZCB0aGlzIHRvIFNJUFJFQyBXRyBpbnN0ZWFkIG9mIERpc3BhdGNoPw0KPiA+DQo+ID5SZWdh cmRzLA0KPiA+DQo+ID5HZXJiZW4NCj4gPg0KPiA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPkZyb206IFJhbSBNb2hhbiBSIChybW9oYW5yKSBbbWFpbHRvOnJtb2hhbnJAY2lzY28uY29t XQ0KPiA+U2VudDogZG9uZGVyZGFnIDYgZmVicnVhcmkgMjAxNCAxNTo0NQ0KPiA+VG86IEdlcmJl biBTdGFtDQo+ID5DYzogZGlzcGF0Y2hAaWV0Zi5vcmcNCj4gPlN1YmplY3Q6IFJlOiBbZGlzcGF0 Y2hdIExvc3NsZXNzIFJlY29yZGluZyBpbiBTSVBSRUMNCj4gPg0KPiA+SGksDQo+ID4NCj4gPklz IHRoZXJlIGEgcmVhc29uIHdoeSB5b3Ugd2FudCB0byBoYXZlIHRoaXMgZGlzY3Vzc2lvbiBpbiBk aXNwYXRjaCBhbmQNCj4gPm5vdCBpbiBTSVBSRUMgV0cgd2hpY2ggaXMgbWVhbnQgdG8gZGlzY3Vz cyB0aGUgaXNzdWVzIGFyb3VuZCBTSVANCj4gPnJlY29yZGluZyA/DQo+ID5JZiB5b3UgZG9uwrl0 IGhhdmUgYW55IHNwZWNpZmljIHJlYXNvbiB0byBkbyBpdCBoZXJlIHlvdSBtYXkgd2FudCB0bw0K PiBzdGFydA0KPiA+dGhpcyBkaXNjdXNzaW9uIGluIFNJUFJFQyBXRy4NCj4gPg0KPiA+SSBkbyBo YXZlIHNvbWUgY29tbWVudHMgb24gdGhpcyB0b3BpYyBidXQgSSB0aGluayBTSVBSRUMgV0cgaXMg dGhlDQo+IHJpZ2h0DQo+ID5wbGFjZSB0byBoYXZlIHRob3NlIGRpc2N1c3Npb25zLg0KPiA+DQo+ ID4NCj4gPlJlZ2FyZHMsDQo+ID5SYW0NCj4gPg0KPiA+RnJvbTogIEdlcmJlbiBTdGFtIDxHZXJi ZW4uU3RhbUBuaWNlLmNvbT4NCj4gPkRhdGU6ICBUaHVyc2RheSwgNiBGZWJydWFyeSAyMDE0IDM6 NTggcG0NCj4gPlRvOiAgR2VyYmVuIFN0YW0gPEdlcmJlbi5TdGFtQG5pY2UuY29tPg0KPiA+Q2M6 ICAiZGlzcGF0Y2hAaWV0Zi5vcmciIDxkaXNwYXRjaEBpZXRmLm9yZz4NCj4gPlN1YmplY3Q6ICBb ZGlzcGF0Y2hdIExvc3NsZXNzIFJlY29yZGluZyBpbiBTSVBSRUMNCj4gPg0KPiA+DQo+ID5EZWFy IERJU1BBVENIIGdyb3VwLA0KPiA+DQo+ID5TSVBSRUMgaXMgYSBncmVhdCBpbml0aWF0aXZlIHRv IHN0YW5kYXJkaXplIHRoZSBpbnRlcmZhY2UgZm9yDQo+IGNhcHR1cmluZw0KPiA+Q29tbXVuaWNh dGlvbiBTZXNzaW9ucy4NCj4gPlNlc3Npb24gUmVjb3JkaW5nIGlzIGJlY29taW5nIG1vcmUgYW5k IG1vcmUgY3JpdGljYWwgZHVlIHRvIENvbXBsaWFuY2UNCj4gPmFuZCByZWd1bGF0b3J5IGNoYW5n ZXMgb3ZlciB0aGUgbGFzdCB5ZWFycy4NCj4gPg0KPiA+VGhlIGNvbXBsaWFuY2UgbWFya2V0IGlz IHJlcXVlc3RpbmcgbW9yZSB0aGFuIGNhcHR1cmUgb25seSB0aGVzZSBkYXlzDQo+ID5Db25maXJt YXRpb24gaXMgbmVlZGVkIHRvIGFja25vd2xlZGdlIHRoZSBlbnRpcmUgQ29tbXVuaWNhdGlvbiBT ZXNzaW9uDQo+ID53YXMgY2FwdHVyZWQgY29ycmVjdGx5Lg0KPiA+UlRDUCBSZXBvcnRzIChyZmMz NjExKSB3aWxsIGhlbHAgdG8gY29uZmlybSBjb21wbGV0ZSBoYW5kb3ZlciBvZiBSVFANCj4gPmNv bnRlbnQuDQo+ID4NCj4gPg0KPiA+DQo+ID5OZXcgcmVxdWlyZW1lbnQgaXMgxZJsb3NzbGVzc8K5 IFNlc3Npb24gQ2FwdHVyaW5nLg0KPiANCj4gV2h5IGlzIHRoaXMgYSBuZXcgcmVxdWlyZW1lbnQg PyBSRkMgNjM0MSAoU0lQUkVDIHJlcXVpcmVtZW50cykgYWxyZWFkeQ0KPiBoYXMNCj4gYSByZXF1 aXJlbWVudCBmb3IgTG9zc2xlc3MgcmVjb3JkaW5nLiBTZWUgUkVRIDAwNS4NCj4gDQo+IA0KPiA+ TG9zc2xlc3MgaW5kaWNhdGluZyBoYW5kb3ZlciBvZiBjb250ZW50IChSVFApIGlzIGFja25vd2xl ZGdlZCBieSB0aGUNCj4gPnJlY2VpdmVyIEFORCBpbiBjYXNlIG9mIHJlY2VpdmluZyBpc3N1ZXMs IHRoZSBzZW5kZXIgd2lsbCByZXNlbmQuDQo+ID5SZWFzb25zIGZvciBsb3NzIG1heSBiZSBVRFAg cGFja2V0IGxvc3Mgb3IgcmVjZWl2ZXIgZmFpbGluZyhvdmVyKSBhbmQNCj4gPnRlbXBvcmFyeSBu b3QgYWJsZSB0byBhY2NlcHQgY29udGVudC4NCj4gPkN1cnJlbnQgYXBwcm9hY2ggdG8gYWRkcmVz cyB0aGlzIMWSbG9zc2xlc3PCuSByZXF1aXJlbWVudCBpcyB1c2luZyAyDQo+ID5pbmRlcGVuZGVu dCBwYXJhbGxlbCByZWNlaXZlcnMuDQo+IA0KPiBUaGVyZSBtYXkgYmUgb3RoZXIgYXBwcm9hY2hl cyB3ZWxsLiBGb3IgZXhhbXBsZSBhbiBTUkMgbWF5IGJ1ZmZlciBmb3IgYQ0KPiBzbWFsbCBkdXJh dGlvbiB0byB0YWtlIGNhcmUgb2YgdGhlIGxvc3MuIFR3byBwYXJhbGxlbCByZWNlaXZlcnMgc3Rp bGwNCj4gZG9lcw0KPiBub3QgZ3VhcmFudGVlIHRoYXQgcmVjb3JkaW5nIGlzIGxvc2VsZXNzIGFz IHlvdSBjYW4gaGF2ZSBVRFAgcGFja2V0DQo+IGxvc3MNCj4gb24gYm90aCBwYXRocy4NCj4gDQo+ ID4NCj4gPlRoaXMgcmVxdWlyZXMgdGhlIHNlbmRlciB0byBzZW5kIDIgaW5kaXZpZHVhbCBzdHJl YW1zLCBpbiBmYWN0IDINCj4gPmluZGVwZW5kZW50IFNJUFJFQyBzZXNzaW9ucy4NCj4gPg0KPiA+ Tm90IHN1cmUgaWYgdGhpcyBpcyBjb3ZlcmVkIGN1cnJlbnRseSBhcyBzdXBwb3J0ZWQgU0lQUkVD IGRlcGxveW1lbnQuDQo+IA0KPiANCj4gQ3VycmVudCBTSVBSRUMgZG9lcyBub3QgaGF2ZSBhbnkg c3VjaCBjb25zdHJhaW50cy4gRGVwZW5kaW5nIG9uIHlvdXINCj4gaW1wbGVtZW50YXRpb24gbW9k ZWwgeW91IGNhbiBoYXZlIHRoZSBzYW1lIENTIHJlY29yZGVkIGJ5IG11bHRpcGxlIFNSQw0KPiBv cg0KPiBoYXZlIHNhbWUgU1JDIGRvIG11bHRpcGxlIHJlY29yZGluZ3Mgb2Ygc2FtZSBDUy4NCj4g DQo+IFJlZ2FyZHMsDQo+IFJhbQ0KPiANCj4gPiBXZSBkbyBzZWUgaW1wbGVtZW50YXRpb25zIGJh c2VkIG9uIFNJUFJFQyBzdXBwb3J0aW5nIGl0Lg0KPiA+QWx0ZXJuYXRpdmUgaXMgcXVpY2sgZmFp bG92ZXIgYXQgcmVjZWl2ZXIgaW4gY2FzZSBvZiBmYWlsdXJlIGJ1dCBhcw0KPiA+c2VuZGVyIHdp bGwgc2VuZCBvbmx5IG9uY2UsIHRoaXMgbWF5IGxlYWQgdG8gbG9zcyBkdXJpbmcgZmFpbG92ZXIu DQo+ID4NCj4gPkkgYW0gbm90IGF3YXJlIG9mIGFueSByZmMgY292ZXJpbmcgbG9zc2xlc3MgY29u dGVudCBoYW5kb3ZlciwgYnV0DQo+IHRoZXJlDQo+ID5tYXkgYmUgc3RhbmRhcmRzIGNvdmVyaW5n IHRoaXMgYWxyZWFkeS4NCj4gPg0KPiA+DQo+ID5Mb29raW5nIGZvcndhcmQgdG8gZGlzY3Vzc2lv biBvbiB0aGUgbWFpbGluZyBsaXN0LiBJIG1heSBiZSBhdCB0aGUNCj4gTG9uZG9uDQo+ID5ldmVu dC4NCj4gPg0KPiA+UmVnYXJkcywNCj4gPg0KPiA+R2VyYmVuIFN0YW0sDQo+ID5OSUNFIFN5c3Rl bXMNCj4gPg0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4gZGlzcGF0Y2hAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0K From thomas.belling@nsn.com Mon Feb 10 06:26:07 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A821A02FA for ; Mon, 10 Feb 2014 06:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.6 X-Spam-Level: X-Spam-Status: No, score=-6.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MbvCemelDkP for ; Mon, 10 Feb 2014 06:26:04 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1C41A07DF for ; Mon, 10 Feb 2014 06:25:58 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1AEPrVS031664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2014 15:25:53 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1AEPqd0008557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 15:25:52 +0100 Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 10 Feb 2014 15:25:52 +0100 Received: from DEMUMBX001.nsn-intra.net ([169.254.1.157]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 15:25:52 +0100 From: "Belling, Thomas (NSN - DE/Munich)" To: ext Jim Forster , =?iso-8859-1?Q?Gullik_Webj=F6rn?= Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAAmPICAAALFAIAAAFCAgAAAZICAAAdQgIAALnMAgAAO2QCAAjuygIAAGAsAgABPfwCABHrqgA== Date: Mon, 10 Feb 2014 14:25:51 +0000 Message-ID: References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <00C069FD01E0324C9FFCADF539701DB3BBF241C5@sc9-ex2k10mb1.corp.yaanatech.com> <52F4E9A4.5000203@corevalue.se> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.102] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2261 X-purgate-ID: 151667::1392042354-00001A6F-81F2BD2D/0-0/0-0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 14:26:07 -0000 I suspect one problems with your ideas is that GSM operates in licensed spe= ctrum. Is your idea that some individuals, rather than an operator owning t= he spectrum, should set up the network? If so, I expect you will face regul= atory issues in less remote places than the Antarctic. Regards, Thomas ---------------------------------- Dr. Thomas Belling=20 3GPP Standardisation NSN -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Jim Fors= ter Sent: Friday, February 07, 2014 7:56 PM To: Gullik Webj=F6rn Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS >>> Interesting. But, the 4G/LTE network is an IP internet of sorts. >>> The SIP/IMS components do not need to be in the radio network, and=20 >>> thus not at the locations where the power is constrained. >> One of the nice properties of an openBTS install in a remote location=20 >> is that it can still function as a local 'pbx' at times when the=20 >> internet link is down. This turns out to be fabulously useful in a crisi= s. If you delegate all the logic out to a cloud service that stops being tr= ue. >>=20 >> Tim. > I agree violently, the challenge here is to design the distributed=20 > protocol(s) add-ons that would enable building a sip/GSM network out of h= undreds or more autonomous BTS's. >=20 > Gullik I agree mostly with both of you: * Standalone/disconnected OpenBTS's have good value in emergency response = or remote work environments. Turn it on phones in the footprint can call e= ach other; no backhaul or Core Network. In some cases that are connected, = over a thin link, there is a great bandwidth savings, and reliability impro= vement, by having a local switch. I believe the Antarctic research station= paid for its OpenBTS in a few months of operation, due to savings in satel= lite bandwidth over the GSM standard approach with the BSC/MSC on the other= side of the satellite link. Plus, solar storms would knock out the link an= d and disable even local calls. * There are indeed challenges (and value) in large networks I still owe the list a diagram which would facilitate understanding and dis= cussion. -- JIm From jim.forster@rangenetworks.com Mon Feb 10 07:07:39 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CD11A0886 for ; Mon, 10 Feb 2014 07:07:39 -0800 (PST) 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=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUZdSd6-mLYj for ; Mon, 10 Feb 2014 07:07:36 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 13A601A0880 for ; Mon, 10 Feb 2014 07:07:35 -0800 (PST) Received: from BL2PR03MB404.namprd03.prod.outlook.com (10.141.91.149) by BL2PR03MB402.namprd03.prod.outlook.com (10.141.91.146) with Microsoft SMTP Server (TLS) id 15.0.873.15; Mon, 10 Feb 2014 15:07:27 +0000 Received: from BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) by BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) with mapi id 15.00.0873.009; Mon, 10 Feb 2014 15:07:26 +0000 From: Jim Forster To: "Belling, Thomas (NSN - DE/Munich)" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAAO2QCAAjuzgIAAGAoAgABPewCABGtxgIAAC5qA Date: Mon, 10 Feb 2014 15:07:25 +0000 Message-ID: <9A8FBE69-A06E-4BB6-8083-8608E098B14D@rangenetworks.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <00C069FD01E0324C9FFCADF539701DB3BBF241C5@sc9-ex2k10mb1.corp.yaanatech.com> <52F4E9A4.5000203@corevalue.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [202.145.4.186] x-forefront-prvs: 0118CD8765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(24454002)(189002)(199002)(377454003)(81686001)(81816001)(87266001)(65816001)(83716003)(63696002)(86362001)(2656002)(87936001)(92726001)(92566001)(56816005)(85852003)(36756003)(83072002)(47446002)(80022001)(82746002)(66066001)(85306002)(74662001)(31966008)(74502001)(93136001)(76786001)(95416001)(76796001)(90146001)(94946001)(94316002)(93516002)(81542001)(74706001)(53806001)(46102001)(51856001)(56776001)(54316002)(54356001)(76482001)(4396001)(49866001)(74876001)(47976001)(47736001)(50986001)(81342001)(33656001)(74366001)(79102001)(69226001)(59766001)(77982001)(80976001)(19580405001)(83322001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB402; H:BL2PR03MB404.namprd03.prod.outlook.com; CLIP:202.145.4.186; FPR:BCEBFC29.88359D15.F6E7138C.44A4F923.201B5; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_98204C44-2187-415F-BB40-6583B2C33111"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: rangenetworks.com Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:07:39 -0000 --Apple-Mail=_98204C44-2187-415F-BB40-6583B2C33111 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 10, 2014, at 9:25 PM, Belling, Thomas (NSN - DE/Munich) = wrote: > I suspect one problems with your ideas is that GSM operates in = licensed spectrum. Is your idea that some individuals, rather than an = operator owning the spectrum, should set up the network? If so, I expect = you will face regulatory issues in less remote places than the = Antarctic. I suspect one problem with standard 3GPP IMS equipment is that it's too = expensive and power hungry for smaller locations. :-)=20 By all means conformance with laws is required. In some cases (Sweden, = UK? Netherlands?) there are unlicensed bands, which used to be DECT = guard bands. But more typically carriers with spectrum licenses are = looking for an economical way to get into rural areas. -- Jim --Apple-Mail=_98204C44-2187-415F-BB40-6583B2C33111 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJS+OsrAAoJECAtT58A/2SKAEwH/iVSG/7I96T8INAUIXP1jQav dcMGogZHPKsyyZVOPO/SOHtRPVBw8uvldaydzEP+zS5P6x5U5R9KU0xif/WUgALV GHObLEmDJCtRg2gzF735WFUMOk5qQYq131jjCIfnP6ypv60NU5gDWB2Dx802fW7E HVKUcrPY5w1ijpos7yTKzdFkK4yKix6tlvkg0a4IGGAS7G44NVtdK99vmJEnNcFm OwmP7Ob5VgWTClTGJvmBeiDQ7NDoUy/qoRjQRdpIcmpDE9fdTZw6XFYupVFCszVf my/7VTHOod33phNeOfBW82TH3ElHp5sanNCkj6fy74z9K6wNCSqArm5xuxPCWhQ= =tYNH -----END PGP SIGNATURE----- --Apple-Mail=_98204C44-2187-415F-BB40-6583B2C33111-- From fluffy@iii.ca Mon Feb 10 07:20:20 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4611A030F for ; Mon, 10 Feb 2014 07:20:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JmtENhkxjzv for ; Mon, 10 Feb 2014 07:20:13 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 5692D1A0310 for ; Mon, 10 Feb 2014 07:20:13 -0800 (PST) Received: from [10.1.4.101] (unknown [75.159.25.213]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 221B250A85; Mon, 10 Feb 2014 10:20:11 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Cullen Jennings In-Reply-To: <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> Date: Mon, 10 Feb 2014 08:20:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <187D918B-AEF3-4BC0-821E-C1487632AFF0@iii.ca> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> To: Jim Forster X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:20:20 -0000 One quick question on the figure, I understand that SMQueue forward SMS = as SIP Messages messages, and I understand Asterisk but can you give me = the one line version of what SAS does? On Feb 9, 2014, at 9:34 PM, Jim Forster = wrote: > On Feb 6, 2014, at 8:46 AM, Jim Forster = wrote: >=20 >>>=20 >>> I think it would really help if there were some diagrams showing = what IMS protocols are being used. >>=20 >> Well, I can certainly provide some diagrams that show how the system = works. >=20 > Much delayed; apologies. It's a bit simplified, and where it calls = out Asterix, one should read "any SIP switching module". >=20 > For those of you that are inclined to read code, it's all available, = as well as web site, mailing list, and wiki. OpenBTS.org, = openbts-discuss@lists.sourceforge.net, = https://wush.net/trac/rangepublic. We plan on bringing a Dev Kit and = can demo somewhere. >=20 >=20 > -- Jim >=20 > >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jim.forster@rangenetworks.com Mon Feb 10 07:35:45 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4221A06B3 for ; Mon, 10 Feb 2014 07:35:45 -0800 (PST) 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=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CTvn1rG3w3Hv for ; Mon, 10 Feb 2014 07:35:43 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 13E101A0320 for ; Mon, 10 Feb 2014 07:35:42 -0800 (PST) Received: from BL2PR03MB404.namprd03.prod.outlook.com (10.141.91.149) by BL2PR03MB401.namprd03.prod.outlook.com (10.141.91.145) with Microsoft SMTP Server (TLS) id 15.0.873.15; Mon, 10 Feb 2014 15:35:40 +0000 Received: from BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) by BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) with mapi id 15.00.0873.009; Mon, 10 Feb 2014 15:35:40 +0000 From: Jim Forster To: Cullen Jennings Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAALRjgIAABFKA Date: Mon, 10 Feb 2014 15:35:39 +0000 Message-ID: <954FD67A-17B7-4000-9E13-19D7B9C860E6@rangenetworks.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <187D918B-AEF3-4BC0-821E-C1487632AFF0@iii.ca> In-Reply-To: <187D918B-AEF3-4BC0-821E-C1487632AFF0@iii.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [202.145.4.186] x-forefront-prvs: 0118CD8765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(24454002)(189002)(199002)(377454003)(81686001)(81816001)(87266001)(83716003)(65816001)(63696002)(2656002)(87936001)(92566001)(92726001)(56816005)(83072002)(85852003)(36756003)(82746002)(80022001)(47446002)(66066001)(85306002)(74662001)(31966008)(74502001)(93136001)(86362001)(76786001)(95416001)(90146001)(93516002)(94316002)(69226001)(94946001)(81542001)(74706001)(74876001)(46102001)(51856001)(56776001)(54316002)(53806001)(54356001)(76482001)(4396001)(558084003)(50986001)(47976001)(49866001)(47736001)(81342001)(33656001)(74366001)(79102001)(76796001)(59766001)(77982001)(80976001)(19580405001)(19580395003)(83322001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB401; H:BL2PR03MB404.namprd03.prod.outlook.com; CLIP:202.145.4.186; FPR:8CFA6DE5.8F3AAF35.B6FA3EBB.74F93F73.200AF; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_755DCF9B-262C-4766-9A3F-D52D13F06BC9"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: rangenetworks.com Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 15:35:45 -0000 --Apple-Mail=_755DCF9B-262C-4766-9A3F-D52D13F06BC9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Feb 10, 2014, at 10:20 PM, Cullen Jennings wrote: > One quick question on the figure, I understand that SMQueue forward = SMS as SIP Messages messages, and I understand Asterisk but can you give = me the one line version of what SAS does? SIP Authentication Services. -- Jim --Apple-Mail=_755DCF9B-262C-4766-9A3F-D52D13F06BC9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJS+PHKAAoJECAtT58A/2SKAXsIAJ4qz5WqXwxJUBtvgSD9Qu85 upBRnZITfJdiFllDHg6RbIWti6GVZm/3UNvrymI1nWeW4DNH5GHih6bQ42VgauYd sYjusgisLbie5DIYkbfu1cXPPF/kmudvVgDarFiQHQW8BDnlkw0blOIwrezw53Eq leriscm0qNC2H51TKfTGziRWb4DRkMpYhrmHxktY5xLnnStRX2V2pR0fItgTAKYW Nq4TfpCKjKEp9cLhelWgqQpVqMWJbLwKGHkPXDs9mOYGje0nkQ5bbInnrWEU1gLX 8rYpxv+MlncJlX12yEjmuOjgNokp/2nvUIFbA8F7ozERSu++Aq/RhQNf8BJNIjc= =f4b6 -----END PGP SIGNATURE----- --Apple-Mail=_755DCF9B-262C-4766-9A3F-D52D13F06BC9-- From mary.ietf.barnes@gmail.com Mon Feb 10 08:38:39 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8071A0885 for ; Mon, 10 Feb 2014 08:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJftEKxlyRHb for ; Mon, 10 Feb 2014 08:38:36 -0800 (PST) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6671A06DC for ; Mon, 10 Feb 2014 08:38:36 -0800 (PST) Received: by mail-yh0-f42.google.com with SMTP id a41so5373811yho.15 for ; Mon, 10 Feb 2014 08:38:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mnux94pK8lg7Q/JKnUGCqujdmNUDgNer8AwTsHS3fmI=; b=MNLoQPIJnCry0lmfnBcBThQlKuSjNm3895+AUTGS0wuQxKBiUFwkSmr1B2r7D/fSv0 A3lno18QZ4m+yjBvnWSOQiyDEUGjA5J8E2pOESSLri3Waki+3BOlByEWEhyRgmjOoVIY JhxC0SCtG/e4AG/zkxZ64cd1WgbTLcvyIw2jNKLVpFNeFSycgQ9OqLJymxWzmaddoPny D0bUHEP088HbXTlKlQZiIhWLoemzOMIzGmicZIY+XPrjX+HnhUk+DKuL3rfpu4vcbGo4 5yJys0X2+UOigZ1KIkuELDDVlvOG2ZlJ9WkP5+8K23C0ZJGzr4ODzckN9+MtBtoArPfO 8bEQ== MIME-Version: 1.0 X-Received: by 10.236.90.65 with SMTP id d41mr29359574yhf.28.1392050315851; Mon, 10 Feb 2014 08:38:35 -0800 (PST) Received: by 10.170.150.2 with HTTP; Mon, 10 Feb 2014 08:38:35 -0800 (PST) In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF17CEDF53@MCHP04MSX.global-ad.net> References: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <9F33F40F6F2CD847824537F3C4E37DDF17CEDF53@MCHP04MSX.global-ad.net> Date: Mon, 10 Feb 2014 10:38:35 -0600 Message-ID: From: Mary Barnes To: "Hutton, Andrew" Content-Type: multipart/alternative; boundary=20cf3010e53595fdec04f20ff8e8 Cc: Gerben Stam , "dispatch@ietf.org" Subject: Re: [dispatch] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:38:40 -0000 --20cf3010e53595fdec04f20ff8e8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes, that is the appropriate action. The ADs just met with the DISPATCH WG chairs in preparation for IETF-89. We discussed this topic and agree that discussion should move to SIPREC WG mailing list. But, it's important to note that this dispatchment in no way implies that the community agrees that work is needed. It's up to the SIPREC WG to make that decision. Regards, Mary DISPATCH WG co-chair. On Mon, Feb 10, 2014 at 8:05 AM, Hutton, Andrew wr= ote: > Hi Gerben, > > Looking back at our off-list discussion I did actually say that you > "should start a discussion on the SIPREC list". > > Sorry if there was confusion. > > Andy > > > -----Original Message----- > > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ram > > Mohan R (rmohanr) > > Sent: 06 February 2014 16:20 > > To: Gerben Stam > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] Lossless Recording in SIPREC > > > > Hi, > > > > Please see inline > > > > -----Original Message----- > > From: Gerben Stam > > Date: Thursday, 6 February 2014 8:40 pm > > To: Cisco Employee > > Cc: "dispatch@ietf.org" > > Subject: RE: [dispatch] Lossless Recording in SIPREC > > > > >Hey Ram, > > > > > >I have had an off-line discussion with Andrew Hutton, chairman of the > > >SIPREC group. > > >He suggested to post this on the IETF dispatch group as it is a good > > >topic to discuss in the team. > > > > Ok. I was not aware of this. > > > > > > > >What would I need to do to bend this to SIPREC WG instead of Dispatch? > > > > > >Regards, > > > > > >Gerben > > > > > >-----Original Message----- > > >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > > >Sent: donderdag 6 februari 2014 15:45 > > >To: Gerben Stam > > >Cc: dispatch@ietf.org > > >Subject: Re: [dispatch] Lossless Recording in SIPREC > > > > > >Hi, > > > > > >Is there a reason why you want to have this discussion in dispatch and > > >not in SIPREC WG which is meant to discuss the issues around SIP > > >recording ? > > >If you don=B9t have any specific reason to do it here you may want to > > start > > >this discussion in SIPREC WG. > > > > > >I do have some comments on this topic but I think SIPREC WG is the > > right > > >place to have those discussions. > > > > > > > > >Regards, > > >Ram > > > > > >From: Gerben Stam > > >Date: Thursday, 6 February 2014 3:58 pm > > >To: Gerben Stam > > >Cc: "dispatch@ietf.org" > > >Subject: [dispatch] Lossless Recording in SIPREC > > > > > > > > >Dear DISPATCH group, > > > > > >SIPREC is a great initiative to standardize the interface for > > capturing > > >Communication Sessions. > > >Session Recording is becoming more and more critical due to Compliance > > >and regulatory changes over the last years. > > > > > >The compliance market is requesting more than capture only these days > > >Confirmation is needed to acknowledge the entire Communication Session > > >was captured correctly. > > >RTCP Reports (rfc3611) will help to confirm complete handover of RTP > > >content. > > > > > > > > > > > >New requirement is OElossless=B9 Session Capturing. > > > > Why is this a new requirement ? RFC 6341 (SIPREC requirements) already > > has > > a requirement for Lossless recording. See REQ 005. > > > > > > >Lossless indicating handover of content (RTP) is acknowledged by the > > >receiver AND in case of receiving issues, the sender will resend. > > >Reasons for loss may be UDP packet loss or receiver failing(over) and > > >temporary not able to accept content. > > >Current approach to address this OElossless=B9 requirement is using 2 > > >independent parallel receivers. > > > > There may be other approaches well. For example an SRC may buffer for a > > small duration to take care of the loss. Two parallel receivers still > > does > > not guarantee that recording is loseless as you can have UDP packet > > loss > > on both paths. > > > > > > > >This requires the sender to send 2 individual streams, in fact 2 > > >independent SIPREC sessions. > > > > > >Not sure if this is covered currently as supported SIPREC deployment. > > > > > > Current SIPREC does not have any such constraints. Depending on your > > implementation model you can have the same CS recorded by multiple SRC > > or > > have same SRC do multiple recordings of same CS. > > > > Regards, > > Ram > > > > > We do see implementations based on SIPREC supporting it. > > >Alternative is quick failover at receiver in case of failure but as > > >sender will send only once, this may lead to loss during failover. > > > > > >I am not aware of any rfc covering lossless content handover, but > > there > > >may be standards covering this already. > > > > > > > > >Looking forward to discussion on the mailing list. I may be at the > > London > > >event. > > > > > >Regards, > > > > > >Gerben Stam, > > >NICE Systems > > > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --20cf3010e53595fdec04f20ff8e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yes, that is the appropriate action.  The ADs just me= t with the DISPATCH WG chairs in preparation for IETF-89. We discussed this= topic and agree that discussion should move to SIPREC WG mailing list. But= , it's important to note that this dispatchment in no way implies that = the community agrees that work is needed. It's up to the SIPREC WG to m= ake that decision.

Regards,
Mary 
DISPATCH WG co-chair= . 


On Mon, Feb 10, 2014 at 8:05 AM, Hutton, Andrew <= ;andrew.hutton= @unify.com> wrote:
Hi Gerben,

Looking back at our off-list discussion I did actually say that you "s= hould start a discussion on the SIPREC list".

Sorry if there was confusion.

Andy

> -----Original Message-----
> From: dispatch [mailto:di= spatch-bounces@ietf.org] On Behalf Of Ram
> Mohan R (rmohanr)
> Sent: 06 February 2014 1= 6:20
> To: Gerben Stam
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] Lossless Recording in SIPREC
>
> Hi,
>
> Please see inline
>
> -----Original Message-----
> From: Gerben Stam <Gerben.S= tam@nice.com>
> Date: Thursday, 6 February 2014 8:40 pm
> To: Cisco Employee <rmohanr@ci= sco.com>
> Cc: "dispatch@ietf.org&q= uot; <dispatch@ietf.org>
> Subject: RE: [dispatch] Lossless Recording in SIPREC
>
> >Hey Ram,
> >
> >I have had an off-line discussion with Andrew Hutton, chairman of = the
> >SIPREC group.
> >He suggested to post this on the IETF dispatch group as it is a go= od
> >topic to discuss in the team.
>
> Ok. I was not aware of this.
>
> >
> >What would I need to do to bend this to SIPREC WG instead of Dispa= tch?
> >
> >Regards,
> >
> >Gerben
> >
> >-----Original Message-----
> >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]
> >Sent: donderdag 6 februari 2014 15:45
> >To: Gerben Stam
> >Cc: dispatch@ietf.org
> >Subject: Re: [dispatch] Lossless Recording in SIPREC
> >
> >Hi,
> >
> >Is there a reason why you want to have this discussion in dispatch= and
> >not in SIPREC WG which is meant to discuss the issues around SIP > >recording ?
> >If you don=B9t have any specific reason to do it here you may want= to
> start
> >this discussion in SIPREC WG.
> >
> >I do have some comments on this topic but I think SIPREC WG is the=
> right
> >place to have those discussions.
> >
> >
> >Regards,
> >Ram
> >
> >From:  Gerben Stam <Gerben.Stam@nice.com>
> >Date:  Thursday, 6 February 2014 3:58 pm
> >To:  Gerben Stam <= Gerben.Stam@nice.com>
> >Cc:  "dispatch@ietf= .org" <dispatch@ietf.org>
> >Subject:  [dispatch] Lossless Recording in SIPREC
> >
> >
> >Dear DISPATCH group,
> >
> >SIPREC is a great initiative to standardize the interface for
> capturing
> >Communication Sessions.
> >Session Recording is becoming more and more critical due to Compli= ance
> >and regulatory changes over the last years.
> >
> >The compliance market is requesting more than capture only these d= ays
> >Confirmation is needed to acknowledge the entire Communication Ses= sion
> >was captured correctly.
> >RTCP Reports (rfc3611) will help to confirm complete handover of R= TP
> >content.
> >
> >
> >
> >New requirement is Œlossless=B9 Session Capturing.
>
> Why is this a new requirement ? RFC 6341 (SIPREC requirements) already=
> has
> a requirement for Lossless recording. See REQ 005.
>
>
> >Lossless indicating handover of content (RTP) is acknowledged by t= he
> >receiver AND in case of receiving issues, the sender will resend.<= br> > >Reasons for loss may be UDP packet loss or receiver failing(over) = and
> >temporary not able to accept content.
> >Current approach to address this Œlossless=B9 requirement is= using 2
> >independent parallel receivers.
>
> There may be other approaches well. For example an SRC may buffer for = a
> small duration to take care of the loss. Two parallel receivers still<= br> > does
> not guarantee that recording is loseless as you can have UDP packet > loss
> on both paths.
>
> >
> >This requires the sender to send 2 individual streams, in fact 2 > >independent SIPREC sessions.
> >
> >Not sure if this is covered currently as supported SIPREC deployme= nt.
>
>
> Current SIPREC does not have any such constraints. Depending on your > implementation model you can have the same CS recorded by multiple SRC=
> or
> have same SRC do multiple recordings of same CS.
>
> Regards,
> Ram
>
> > We do see implementations based on SIPREC supporting it.
> >Alternative is quick failover at receiver in case of failure but a= s
> >sender will send only once, this may lead to loss during failover.=
> >
> >I am not aware of any rfc covering lossless content handover, but<= br> > there
> >may be standards covering this already.
> >
> >
> >Looking forward to discussion on the mailing list. I may be at the=
> London
> >event.
> >
> >Regards,
> >
> >Gerben Stam,
> >NICE Systems
> >
> >
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--20cf3010e53595fdec04f20ff8e8-- From mary.ietf.barnes@gmail.com Mon Feb 10 08:49:29 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4919F1A06E5 for ; Mon, 10 Feb 2014 08:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mwrwrSO-AIn for ; Mon, 10 Feb 2014 08:49:27 -0800 (PST) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id D721D1A0565 for ; Mon, 10 Feb 2014 08:49:26 -0800 (PST) Received: by mail-yh0-f41.google.com with SMTP id f73so5447796yha.28 for ; Mon, 10 Feb 2014 08:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=AmODZyY7n8f2htCwolIcL/LlRn13BfWYBfcjgEKkzcw=; b=TvY+G9j8grkVpjA2LCFHB3ft+D0VE33ucMFhLa3nu3lrk7nwGYJ4lsIYsFryBP1Y7x HzeOHyLmRPJvI9GWfucXtsNhmzPHHzOabb8Y8ISG3OSeS5ErBpxJp2j5Yu84HDMoWBv1 CwG6I/zC/yeHB7ttTEA8dSMI1xViyApqCrBUCtVwu1rlmAbzo4ryrO0vOMeeM2nKgYbK CDXsXBJfkEvKpcetut8l8lhlq6rL0cD/vlgnH0ayh4oeky7gdZIMXgmgKUoURcaHlJ6U jLAgpWkFhllAX0KiMP9EG7bTcVdKOznxt/YoNnGeET3YmK5w8+/BB6WNajp/Pdk6uMU+ VNtg== MIME-Version: 1.0 X-Received: by 10.236.92.138 with SMTP id j10mr3020748yhf.70.1392050966545; Mon, 10 Feb 2014 08:49:26 -0800 (PST) Received: by 10.170.150.2 with HTTP; Mon, 10 Feb 2014 08:49:26 -0800 (PST) Date: Mon, 10 Feb 2014 10:49:26 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=20cf301afb275ecae704f2101f0f Cc: Cullen Jennings , "rai-ads@tools.ietf.org" , SIPCORE Chairs , siprec-chairs@tools.ietf.org Subject: [dispatch] DISPATCH Topics - IETF-89 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:49:29 -0000 --20cf301afb275ecae704f2101f0f Content-Type: text/plain; charset=ISO-8859-1 Hi all, Based on WG discussions and consultation with the ADs, the following topic is proposed for discussion at the DISPATCH WG session at the IETF-89 meeting: 1) OpenBTS. Discussion thread: http://www.ietf.org/mail-archive/web/dispatch/current/msg05233.html We will post the preliminary agenda shortly, but the plan is to allocate 45-50 minutes for this discussion. Since we have been allocated 2 1-hour slots, the ADs are considering options for using the other 1.0 slot. The following topic is being dispatched to the SIPCORE WG: 2) TLS sessions in SIP using DANE. Draft: http://datatracker.ietf.org/doc/draft-johansson-dispatch-dane-sip/ Discussion Threads: http://www.ietf.org/mail-archive/web/dispatch/current/msg05160.html http://www.ietf.org/mail-archive/web/dispatch/current The following topic is being dispatched to the SIPREC WG: 3) Lossless Recording. Discussion thread: http://www.ietf.org/mail-archive/web/dispatch/current/msg05258.html Please note that while this document is being dispatched, this does not imply that there is yet community consensus that there is work to be done. That decision will be made in the SIPREC WG. Thanks, Mary DISPATCH WG co-chair --20cf301afb275ecae704f2101f0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Based on =A0WG discussions and consultation with the ADs, the followi= ng topic is proposed for discussion at the=A0DISPATCH=A0WG session at the IE= TF-89=A0meeting:
1) OpenBTS.
Discussion thread: =A0http://www.ietf.org/mail-archive/web/dispatch/current/msg05233.html

We will post the prel= iminary agenda shortly, but the plan is to allocate 45-50 minutes for this = discussion. =A0Since we have been allocated 2 1-hour slots, the ADs are con= sidering options for using the other 1.0 slot. =A0

The following topic is being dispatched to the SIPCORE= WG:
2) TLS sessions in SIP using DANE= .
Discussion Threads:
http://www.ietf.org/mail-archive/web/dispatch/current/msg05160.html=

The following topic is being dispatc= hed to the SIPREC WG:
3) Lossless Recording.
Please note that while this document is being dispatched, this do= es not imply that there is yet community consensus that there is work to be= done. =A0That decision will be made in the SIPREC WG. =A0

Thanks,
Mary=A0
DISPATCH=A0WG co-chair

--20cf301afb275ecae704f2101f0f-- From pkyzivat@alum.mit.edu Mon Feb 10 08:56:30 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC511A03A5 for ; Mon, 10 Feb 2014 08:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8QgojN1Uz4j0 for ; Mon, 10 Feb 2014 08:56:28 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 882701A0565 for ; Mon, 10 Feb 2014 08:56:28 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id QdpP1n0041vXlb853gwUso; Mon, 10 Feb 2014 16:56:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id QgwU1n0083ZTu2S3dgwUpa; Mon, 10 Feb 2014 16:56:28 +0000 Message-ID: <52F904BB.9050004@alum.mit.edu> Date: Mon, 10 Feb 2014 11:56:27 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <9F33F40F6F2CD847824537F3C4E37DDF17CEDF53@MCHP04MSX.global-ad.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392051388; bh=PZgeWPySVBrwl8lNRtHQhmXVe/pq+VYqeKel5meK6zY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rEaOVD8wmtnMm5H5i9sJ6f1fY+CL0WwMYGxTUUKDneTg8Wmy4UwAnUJMqd56v74Ut 8jxbw+nkhGAx4nBUD/M+TfBeX1XTfU7RpdBp/9qZMP9RiY5LWxpB97NQKDqqUDHL0a E/eI2X3AAt4dJ3GN7Vt2DbctfGe2hQ1R6g7f5PDRfV30/GCVqRQeENm8XPBA+W9s+9 nzIlf9QwRFakfcd5GlA+15GXmGr2+0rAaLjUWPC9xfNI6kBo3ZYnFJ44jRgIKWayyj k4cY2NPU7wc/bQTSgB03D8zqIQFwRIBNIpvUJtuOiJQq6MuzuhZhOUAZtPcL2whEG9 N2TLaIIFcBynA== Subject: Re: [dispatch] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 16:56:31 -0000 On 2/10/14 11:38 AM, Mary Barnes wrote: > Yes, that is the appropriate action. The ADs just met with the DISPATCH > WG chairs in preparation for IETF-89. We discussed this topic and agree > that discussion should move to SIPREC WG mailing list. That's good. It will put the discussion with the people who care, and not bother others. > But, it's > important to note that this dispatchment in no way implies that the > community agrees that work is needed. It's up to the SIPREC WG to make > that decision. Certainly! Thanks, Paul > Regards, > Mary > DISPATCH WG co-chair. > > > On Mon, Feb 10, 2014 at 8:05 AM, Hutton, Andrew > wrote: > > Hi Gerben, > > Looking back at our off-list discussion I did actually say that you > "should start a discussion on the SIPREC list". > > Sorry if there was confusion. > > Andy > > > -----Original Message----- > > From: dispatch [mailto:dispatch-bounces@ietf.org > ] On Behalf Of Ram > > Mohan R (rmohanr) > > Sent: 06 February 2014 16:20 > > To: Gerben Stam > > Cc: dispatch@ietf.org > > Subject: Re: [dispatch] Lossless Recording in SIPREC > > > > Hi, > > > > Please see inline > > > > -----Original Message----- > > From: Gerben Stam > > > Date: Thursday, 6 February 2014 8:40 pm > > To: Cisco Employee > > > Cc: "dispatch@ietf.org " > > > > Subject: RE: [dispatch] Lossless Recording in SIPREC > > > > >Hey Ram, > > > > > >I have had an off-line discussion with Andrew Hutton, chairman > of the > > >SIPREC group. > > >He suggested to post this on the IETF dispatch group as it is a good > > >topic to discuss in the team. > > > > Ok. I was not aware of this. > > > > > > > >What would I need to do to bend this to SIPREC WG instead of > Dispatch? > > > > > >Regards, > > > > > >Gerben > > > > > >-----Original Message----- > > >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com > ] > > >Sent: donderdag 6 februari 2014 15:45 > > >To: Gerben Stam > > >Cc: dispatch@ietf.org > > >Subject: Re: [dispatch] Lossless Recording in SIPREC > > > > > >Hi, > > > > > >Is there a reason why you want to have this discussion in > dispatch and > > >not in SIPREC WG which is meant to discuss the issues around SIP > > >recording ? > > >If you donıt have any specific reason to do it here you may want to > > start > > >this discussion in SIPREC WG. > > > > > >I do have some comments on this topic but I think SIPREC WG is the > > right > > >place to have those discussions. > > > > > > > > >Regards, > > >Ram > > > > > >From: Gerben Stam > > > >Date: Thursday, 6 February 2014 3:58 pm > > >To: Gerben Stam > > > >Cc: "dispatch@ietf.org " > > > > >Subject: [dispatch] Lossless Recording in SIPREC > > > > > > > > >Dear DISPATCH group, > > > > > >SIPREC is a great initiative to standardize the interface for > > capturing > > >Communication Sessions. > > >Session Recording is becoming more and more critical due to > Compliance > > >and regulatory changes over the last years. > > > > > >The compliance market is requesting more than capture only these > days > > >Confirmation is needed to acknowledge the entire Communication > Session > > >was captured correctly. > > >RTCP Reports (rfc3611) will help to confirm complete handover of RTP > > >content. > > > > > > > > > > > >New requirement is Œlosslessı Session Capturing. > > > > Why is this a new requirement ? RFC 6341 (SIPREC requirements) > already > > has > > a requirement for Lossless recording. See REQ 005. > > > > > > >Lossless indicating handover of content (RTP) is acknowledged by the > > >receiver AND in case of receiving issues, the sender will resend. > > >Reasons for loss may be UDP packet loss or receiver > failing(over) and > > >temporary not able to accept content. > > >Current approach to address this Œlosslessı requirement is using 2 > > >independent parallel receivers. > > > > There may be other approaches well. For example an SRC may buffer > for a > > small duration to take care of the loss. Two parallel receivers still > > does > > not guarantee that recording is loseless as you can have UDP packet > > loss > > on both paths. > > > > > > > >This requires the sender to send 2 individual streams, in fact 2 > > >independent SIPREC sessions. > > > > > >Not sure if this is covered currently as supported SIPREC > deployment. > > > > > > Current SIPREC does not have any such constraints. Depending on your > > implementation model you can have the same CS recorded by > multiple SRC > > or > > have same SRC do multiple recordings of same CS. > > > > Regards, > > Ram > > > > > We do see implementations based on SIPREC supporting it. > > >Alternative is quick failover at receiver in case of failure but as > > >sender will send only once, this may lead to loss during failover. > > > > > >I am not aware of any rfc covering lossless content handover, but > > there > > >may be standards covering this already. > > > > > > > > >Looking forward to discussion on the mailing list. I may be at the > > London > > >event. > > > > > >Regards, > > > > > >Gerben Stam, > > >NICE Systems > > > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From keith.drage@alcatel-lucent.com Mon Feb 10 09:56:47 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A48B1A07EB for ; Mon, 10 Feb 2014 09:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atVf4SejpdDB for ; Mon, 10 Feb 2014 09:56:44 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 77BA61A0500 for ; Mon, 10 Feb 2014 09:56:43 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1AHufIb025437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2014 11:56:42 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1AHufSN024746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 18:56:41 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 18:56:41 +0100 From: "DRAGE, Keith (Keith)" To: Jim Forster , Mary Barnes Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIA== Date: Mon, 10 Feb 2014 17:56:40 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> In-Reply-To: <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 17:56:47 -0000 If I follow this diagram correctly, you claim to have collapsed the HLR int= o your BTS. Your BTS apparently have no communication shown with each other= . This means you each subscriber is limited to a single BTS with no roaming= between them. To sumamrise, this diagram tells us nothing about what you want to do with = your architecture, unless you really want no service capabilities at all. Can you please start answering some of the questions I asked earlier. Keith Drage =20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf=20 > Of Jim Forster > Sent: 10 February 2014 04:35 > To: Mary Barnes > Cc: dispatch@ietf.org > Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS >=20 > On Feb 6, 2014, at 8:46 AM, Jim Forster=20 > wrote: >=20 > >>=20 > >> I think it would really help if there were some diagrams=20 > showing what IMS protocols are being used. > >=20 > > Well, I can certainly provide some diagrams that show how=20 > the system works. >=20 > Much delayed; apologies. It's a bit simplified, and where it=20 > calls out Asterix, one should read "any SIP switching module". >=20 > For those of you that are inclined to read code, it's all=20 > available, as well as web site, mailing list, and wiki. =20 > OpenBTS.org, openbts-discuss@lists.sourceforge.net,=20 > https://wush.net/trac/rangepublic. We plan on bringing a Dev=20 > Kit and can demo somewhere. >=20 >=20 > -- Jim >=20 > = From thp@westhawk.co.uk Mon Feb 10 10:28:21 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513F11A00EE for ; Mon, 10 Feb 2014 10:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6o5NkxqSl9cv for ; Mon, 10 Feb 2014 10:28:19 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by ietfa.amsl.com (Postfix) with ESMTP id 7F89A1A01F1 for ; Mon, 10 Feb 2014 10:28:18 -0800 (PST) Received: (qmail 66311 invoked from network); 10 Feb 2014 18:28:17 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 18679 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 10 Feb 2014 18:28:17 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 4A4A018A03C9; Mon, 10 Feb 2014 18:28:17 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id DBF8C18A0153; Mon, 10 Feb 2014 18:28:16 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton new In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Mon, 10 Feb 2014 18:28:00 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 18:28:21 -0000 On 10 Feb 2014, at 17:56, DRAGE, Keith (Keith) = wrote: > If I follow this diagram correctly, you claim to have collapsed the = HLR into your BTS. Your BTS apparently have no communication shown with = each other. This means you each subscriber is limited to a single BTS = with no roaming between them. I think you are assuming a specific solution to a specific problem.=20 Many ITSPs allow SIP registrations to a DID/account to come from = dynamic IPs. So the necessary 'communication' can be=20 implemented via the ITSP's normal functions. So when a user moves from = the BTS in village A to the BTS in village B=20 their DID travels with them. Sure you wouldn't get the ability for an arbitrary GSM SIM to roam into = the network and be billed to their home network.=20 But realistically that sort of roaming isn't really a technical problem, = it is predominantly a legal/commercial one. Tim.= From keith.drage@alcatel-lucent.com Mon Feb 10 10:43:53 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E271A07FC for ; Mon, 10 Feb 2014 10:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jyolm9-wbNxD for ; Mon, 10 Feb 2014 10:43:51 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 03C5B1A055A for ; Mon, 10 Feb 2014 10:43:50 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1AIhml2004592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2014 12:43:49 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1AIhlVl013287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 19:43:47 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 19:43:47 +0100 From: "DRAGE, Keith (Keith)" To: Tim Panton new Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIIAAPqkAgAASvbA= Date: Mon, 10 Feb 2014 18:43:46 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> In-Reply-To: <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 18:43:53 -0000 I am not assuming a specific solution - what we are all trying to find out = is how much of 3GPP GERAN is actually being used, and what identities relat= e to what. So you will have a UICC - because it is a 3GPP GERAN access network, but wi= ll not have any roaming that relates to the UICC, or the identities on that= UICC. But as far as I can see from the architecture given, the service is limited= to a single BTS. That means that (for the solution you identify below) an = operator with multiple BTSs will assign their users to a single BTS and the= collation of charging/accounting will have to be from each individual BTS,= back to some central entity (not shown).=20 You will not be running the 3GPP mobility management protocols between BTS. Keith Drage =20 > -----Original Message----- > From: Tim Panton new [mailto:thp@westhawk.co.uk]=20 > Sent: 10 February 2014 18:28 > To: DRAGE, Keith (Keith) > Cc: Jim Forster; Mary Barnes; dispatch@ietf.org > Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS >=20 >=20 > On 10 Feb 2014, at 17:56, DRAGE, Keith (Keith)=20 > wrote: >=20 > > If I follow this diagram correctly, you claim to have=20 > collapsed the HLR into your BTS. Your BTS apparently have no=20 > communication shown with each other. This means you each=20 > subscriber is limited to a single BTS with no roaming between them. >=20 > I think you are assuming a specific solution to a specific problem.=20 > Many ITSPs allow SIP registrations to a DID/account to come=20 > from dynamic IPs. So the necessary 'communication' can be=20 > implemented via the ITSP's normal functions. So when a user=20 > moves from the BTS in village A to the BTS in village B=20 > their DID travels with them. >=20 > Sure you wouldn't get the ability for an arbitrary GSM SIM to=20 > roam into the network and be billed to their home network.=20 >=20 > But realistically that sort of roaming isn't really a=20 > technical problem, it is predominantly a legal/commercial one. >=20 > Tim.= From munncha@gmail.com Mon Feb 10 11:05:30 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5EB1A0412 for ; Mon, 10 Feb 2014 11:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IrWoW2QdFmmh for ; Mon, 10 Feb 2014 11:05:28 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id D01071A03C9 for ; Mon, 10 Feb 2014 11:05:27 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id n15so5002798lbi.25 for ; Mon, 10 Feb 2014 11:05:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=G4a9Du9yBKhQy/f0nm+5lHdPl3/9wuvkeIFq6O0eA4M=; b=rK3XHsQIRkNS+y4E3m771t1tNoIOeGkdOM7QR9l481kYdTU7yRlT7yp6I8GWmHVvam zvr1To47MQq4eEYUC6A+CuexEqi1IjZl4E3Qln/6jE2HYEM8ptufqMP3NbhyGeZO2PQb 6R6kA3nR9bik5vAO9BhoPyA5Y1vSOScsnKa5JJFWeehINP2UpfTOEFGfHYdrMqHngZ0C dAeaf4TudYRe4DokJ6gekM3hSzoXbK3GYym914fueOLXHtHO3h8w0KDInomASiAhEs9v TArFLbA5IGF++FXKHq8LEu0X7N4gKQnZwx/ZP1k9NHhRQbHmwLptpPpXpbNkGDdzAuE4 FGKw== X-Received: by 10.152.9.65 with SMTP id x1mr23322648laa.6.1392059126857; Mon, 10 Feb 2014 11:05:26 -0800 (PST) MIME-Version: 1.0 Sender: munncha@gmail.com Received: by 10.112.42.170 with HTTP; Mon, 10 Feb 2014 11:04:46 -0800 (PST) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Kurtis Heimerl Date: Tue, 11 Feb 2014 04:04:46 +0900 X-Google-Sender-Auth: fs0JU8kGdwaGGONF6jy-KuADnVE Message-ID: To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=089e0158b8eac3458504f21205aa Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:08:10 -0000 --089e0158b8eac3458504f21205aa Content-Type: text/plain; charset=ISO-8859-1 You're misreading the diagram. As can be seen, multiple OpenBTS instances can talk to a single instance of the SAS. This allows for centralized charging and accounting for multiple BTS instances wherever the SAS is hosted. As far as the 3GPP mobility management protocols (if I know which ones you are speaking of), those are converted to SIP (as is everything) and sent to the SAS. So I would say we are using these protocols between BTSs, especially for handover. On Tue, Feb 11, 2014 at 3:43 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > I am not assuming a specific solution - what we are all trying to find out > is how much of 3GPP GERAN is actually being used, and what identities > relate to what. > > So you will have a UICC - because it is a 3GPP GERAN access network, but > will not have any roaming that relates to the UICC, or the identities on > that UICC. > > But as far as I can see from the architecture given, the service is > limited to a single BTS. That means that (for the solution you identify > below) an operator with multiple BTSs will assign their users to a single > BTS and the collation of charging/accounting will have to be from each > individual BTS, back to some central entity (not shown). > > You will not be running the 3GPP mobility management protocols between BTS. > > Keith Drage > > > > > -----Original Message----- > > From: Tim Panton new [mailto:thp@westhawk.co.uk] > > Sent: 10 February 2014 18:28 > > To: DRAGE, Keith (Keith) > > Cc: Jim Forster; Mary Barnes; dispatch@ietf.org > > Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS > > > > > > On 10 Feb 2014, at 17:56, DRAGE, Keith (Keith) > > wrote: > > > > > If I follow this diagram correctly, you claim to have > > collapsed the HLR into your BTS. Your BTS apparently have no > > communication shown with each other. This means you each > > subscriber is limited to a single BTS with no roaming between them. > > > > I think you are assuming a specific solution to a specific problem. > > Many ITSPs allow SIP registrations to a DID/account to come > > from dynamic IPs. So the necessary 'communication' can be > > implemented via the ITSP's normal functions. So when a user > > moves from the BTS in village A to the BTS in village B > > their DID travels with them. > > > > Sure you wouldn't get the ability for an arbitrary GSM SIM to > > roam into the network and be billed to their home network. > > > > But realistically that sort of roaming isn't really a > > technical problem, it is predominantly a legal/commercial one. > > > > Tim. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --089e0158b8eac3458504f21205aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You're misreading the diagram. As can be seen, multipl= e OpenBTS instances can talk to a single instance of the SAS. This allows f= or centralized charging and accounting for multiple BTS instances wherever = the SAS is hosted.

As far as the 3GPP mobility management protocols (if I know = which ones you are speaking of), those are converted to SIP (as is everythi= ng) and sent to the SAS. So I would say we are using these protocols betwee= n BTSs, especially for handover.=A0


On Tue,= Feb 11, 2014 at 3:43 AM, DRAGE, Keith (Keith) <keith.drage@a= lcatel-lucent.com> wrote:
I am not assuming a specific solution - what= we are all trying to find out is how much of 3GPP GERAN is actually being = used, and what identities relate to what.

So you will have a UICC - because it is a 3GPP GERAN access network, but wi= ll not have any roaming that relates to the UICC, or the identities on that= UICC.

But as far as I can see from the architecture given, the service is limited= to a single BTS. That means that (for the solution you identify below) an = operator with multiple BTSs will assign their users to a single BTS and the= collation of charging/accounting will have to be from each individual BTS,= back to some central entity (not shown).

You will not be running the 3GPP mobility management protocols between BTS.=

Keith Drage



> -----Original Message-----
> From: Tim Panton new [mailto:thp= @westhawk.co.uk]
> Sent: 10 February 2014 18:28
> To: DRAGE, Keith (Keith)
> Cc: Jim Forster; Mary Barnes; dispatch@ietf.org
> Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS
>
>
> On 10 Feb 2014, at 17:56= , DRAGE, Keith (Keith)
> <keith.drage@alca= tel-lucent.com> wrote:
>
> > If I follow this diagram correctly, you claim to have
> collapsed the HLR into your BTS. Your BTS apparently have no
> communication shown with each other. This means you each
> subscriber is limited to a single BTS with no roaming between them. >
> I think you are assuming a specific solution to a specific problem. > Many ITSPs allow SIP =A0registrations to a DID/account to come
> from dynamic IPs. So the necessary 'communication' can be
> implemented via the ITSP's normal functions. So when a user
> moves from the BTS in village A to the BTS =A0in village B
> their DID travels with them.
>
> Sure you wouldn't get the ability for an arbitrary GSM SIM to
> roam into the network and be billed to their home network.
>
> But realistically that sort of roaming isn't really a
> technical problem, it is predominantly a legal/commercial one.
>
> Tim.
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--089e0158b8eac3458504f21205aa-- From gsalguei@cisco.com Mon Feb 10 11:15:33 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537C61A046A for ; Mon, 10 Feb 2014 11:15:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bl68Z3bB_0JQ for ; Mon, 10 Feb 2014 11:15:29 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 557481A0128 for ; Mon, 10 Feb 2014 11:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2242; q=dns/txt; s=iport; t=1392059729; x=1393269329; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=V1YvD3YvSYnxY0En61JGWNvm6pP3iFOzmXtLTAx9q/g=; b=XF4xss2RxRMKlVJNS6F2Hfsph9FZPrDXYGLRQaS0f/5iaxTojtY8p/YW 42k+8Rv+yt2MNbgALBejMeEK1kuehmn2VDjiYcsWsb7Ansgh2/Bz9Rf0U +yqevzZBJR1LmrPP8a8Qom8ouB2WJoRfO+95p1CgljL+7B1Q/0UB4xeys Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAD8k+VKtJXG9/2dsb2JhbABZgww4V79hgRUWdIIlAQEBAwEBAQE3NAsQAgEINhAnCyUCBA4FCYd0CA3JKxeOSjMCBYMkgRQEmCuBMosuhUCDLYIq X-IronPort-AV: E=Sophos;i="4.95,819,1384300800"; d="scan'208";a="19339119" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-1.cisco.com with ESMTP; 10 Feb 2014 19:15:28 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1AJFSVO015643 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 19:15:28 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Mon, 10 Feb 2014 13:15:28 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: DISPATCH Thread-Topic: I-D Action: draft-salgueiro-dispatch-websocket-sipclf-00.txt Thread-Index: AQHPJpR1rIplQhY9+Uqk7RA3bDrnxA== Date: Mon, 10 Feb 2014 19:15:28 +0000 Message-ID: <92EF8F31-C0DD-4035-A09F-C8BB178A9512@cisco.com> References: <20140209192704.25520.1461.idtracker@ietfa.amsl.com> In-Reply-To: <20140209192704.25520.1461.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.57] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch-chairs@tools.ietf.org" Subject: Re: [dispatch] I-D Action: draft-salgueiro-dispatch-websocket-sipclf-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:15:33 -0000 Folks -=20 We have submitted a new draft to add WebSocket as a transport in the SIP CL= F. The authors would gratefully welcome any feedback. Noting that this draft is nothing more than an IANA registration, it does n= ot need to be dispatched to an WG, nor does it require time at a meeting. = If the WG agrees, I think this is an ideal candidate for AD sponsorship. Thanks, Gonzalo On Feb 9, 2014, at 2:27 PM, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 >=20 > Title : Indicating WebSocket Protocol as a Transport in = the Session Initiation Protocol (SIP) Common Log Format (CLF) > Authors : Gonzalo Salgueiro > Victor Pascual > Anton Roman > Sergio Garcia > Filename : draft-salgueiro-dispatch-websocket-sipclf-00.txt > Pages : 8 > Date : 2014-02-09 >=20 > Abstract: > RFC 7118 [RFC7118] specifies a WebSocket sub-protocol as a reliable > real-time transport mechanism between SIP (Session Initiation > Protocol) entities to enable usage of SIP in web-oriented > deployments. This document updates the SIP Common Log Format (CLF), > defined in RFC 6873 [RFC6873], with a new "Transport Flag" for such > SIP WebSocket transport. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-salgueiro-dispatch-websocket-sipcl= f/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-salgueiro-dispatch-websocket-sipclf-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From keith.drage@alcatel-lucent.com Mon Feb 10 11:42:09 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC6FA1A01A8 for ; Mon, 10 Feb 2014 11:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMhRW6zUsEAq for ; Mon, 10 Feb 2014 11:42:06 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 46BD51A03C9 for ; Mon, 10 Feb 2014 11:42:06 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1AJg3Uh018593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2014 13:42:05 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1AJg25F004558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 20:42:02 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 20:42:02 +0100 From: "DRAGE, Keith (Keith)" To: Mary Barnes , "Hutton, Andrew" Thread-Topic: [dispatch] Lossless Recording in SIPREC Thread-Index: AQHPJoOSx59IE/b4SkKjD7FE2seEVZqu4vvw Date: Mon, 10 Feb 2014 19:42:02 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B12F844@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <9F33F40F6F2CD847824537F3C4E37DDF17CEDF53@MCHP04MSX.global-ad.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B12F844FR712WXCHMBA11zeu_" MIME-Version: 1.0 Cc: Gerben Stam , "dispatch@ietf.org" Subject: Re: [dispatch] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 19:42:10 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B12F844FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable According to the charter: The Dispatch working group is chartered to consider proposals for new work in the RAI area and identify, or help create, an appropriate venue for the work. I would read this as a working group decision rather than a WG chairs decis= ion. Keith ________________________________ From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 10 February 2014 16:39 To: Hutton, Andrew Cc: Gerben Stam; dispatch@ietf.org Subject: Re: [dispatch] Lossless Recording in SIPREC Yes, that is the appropriate action. The ADs just met with the DISPATCH WG= chairs in preparation for IETF-89. We discussed this topic and agree that = discussion should move to SIPREC WG mailing list. But, it's important to no= te that this dispatchment in no way implies that the community agrees that = work is needed. It's up to the SIPREC WG to make that decision. Regards, Mary DISPATCH WG co-chair. On Mon, Feb 10, 2014 at 8:05 AM, Hutton, Andrew > wrote: Hi Gerben, Looking back at our off-list discussion I did actually say that you "should= start a discussion on the SIPREC list". Sorry if there was confusion. Andy > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ram > Mohan R (rmohanr) > Sent: 06 February 2014 16:20 > To: Gerben Stam > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Lossless Recording in SIPREC > > Hi, > > Please see inline > > -----Original Message----- > From: Gerben Stam > > Date: Thursday, 6 February 2014 8:40 pm > To: Cisco Employee > > Cc: "dispatch@ietf.org" > > Subject: RE: [dispatch] Lossless Recording in SIPREC > > >Hey Ram, > > > >I have had an off-line discussion with Andrew Hutton, chairman of the > >SIPREC group. > >He suggested to post this on the IETF dispatch group as it is a good > >topic to discuss in the team. > > Ok. I was not aware of this. > > > > >What would I need to do to bend this to SIPREC WG instead of Dispatch? > > > >Regards, > > > >Gerben > > > >-----Original Message----- > >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >Sent: donderdag 6 februari 2014 15:45 > >To: Gerben Stam > >Cc: dispatch@ietf.org > >Subject: Re: [dispatch] Lossless Recording in SIPREC > > > >Hi, > > > >Is there a reason why you want to have this discussion in dispatch and > >not in SIPREC WG which is meant to discuss the issues around SIP > >recording ? > >If you don=B9t have any specific reason to do it here you may want to > start > >this discussion in SIPREC WG. > > > >I do have some comments on this topic but I think SIPREC WG is the > right > >place to have those discussions. > > > > > >Regards, > >Ram > > > >From: Gerben Stam > > >Date: Thursday, 6 February 2014 3:58 pm > >To: Gerben Stam > > >Cc: "dispatch@ietf.org" > > >Subject: [dispatch] Lossless Recording in SIPREC > > > > > >Dear DISPATCH group, > > > >SIPREC is a great initiative to standardize the interface for > capturing > >Communication Sessions. > >Session Recording is becoming more and more critical due to Compliance > >and regulatory changes over the last years. > > > >The compliance market is requesting more than capture only these days > >Confirmation is needed to acknowledge the entire Communication Session > >was captured correctly. > >RTCP Reports (rfc3611) will help to confirm complete handover of RTP > >content. > > > > > > > >New requirement is =8Clossless=B9 Session Capturing. > > Why is this a new requirement ? RFC 6341 (SIPREC requirements) already > has > a requirement for Lossless recording. See REQ 005. > > > >Lossless indicating handover of content (RTP) is acknowledged by the > >receiver AND in case of receiving issues, the sender will resend. > >Reasons for loss may be UDP packet loss or receiver failing(over) and > >temporary not able to accept content. > >Current approach to address this =8Clossless=B9 requirement is using 2 > >independent parallel receivers. > > There may be other approaches well. For example an SRC may buffer for a > small duration to take care of the loss. Two parallel receivers still > does > not guarantee that recording is loseless as you can have UDP packet > loss > on both paths. > > > > >This requires the sender to send 2 individual streams, in fact 2 > >independent SIPREC sessions. > > > >Not sure if this is covered currently as supported SIPREC deployment. > > > Current SIPREC does not have any such constraints. Depending on your > implementation model you can have the same CS recorded by multiple SRC > or > have same SRC do multiple recordings of same CS. > > Regards, > Ram > > > We do see implementations based on SIPREC supporting it. > >Alternative is quick failover at receiver in case of failure but as > >sender will send only once, this may lead to loss during failover. > > > >I am not aware of any rfc covering lossless content handover, but > there > >may be standards covering this already. > > > > > >Looking forward to discussion on the mailing list. I may be at the > London > >event. > > > >Regards, > > > >Gerben Stam, > >NICE Systems > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_949EF20990823C4C85C18D59AA11AD8B12F844FR712WXCHMBA11zeu_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
According to the charter:<= /span>
 
The Disp= atch working group is chartered to consider proposals for
new work in the RAI area and identify, or help create, an appropriate
venue for the work.
&= nbsp;
I would read this as a working group decision rather than a = WG chairs decision.
 
Keith
 
 

From: dispatch [mailto:dispatch-bou= nces@ietf.org] On Behalf Of Mary Barnes
Sent: 10 February 2014 16:39
To: Hutton, Andrew
Cc: Gerben Stam; dispatch@ietf.org
Subject: Re: [dispatch] Lossless Recording in SIPREC

Yes, that is the appropriate action.  The ADs just me= t with the DISPATCH WG chairs in preparation for IETF-89. We discussed this= topic and agree that discussion should move to SIPREC WG mailing list. But= , it's important to note that this dispatchment in no way implies that the community agrees that work is needed. It's up t= o the SIPREC WG to make that decision.

Regards,
Mary 
DISPATCH WG co-chair. 


On Mon, Feb 10, 2014 at 8:05 AM, Hutton, Andrew = <andrew.hut= ton@unify.com> wrote:
Hi Gerben,

Looking back at our off-list discussion I did actually say that you "s= hould start a discussion on the SIPREC list".

Sorry if there was confusion.

Andy

> -----Original Message-----
> From: dispatch [mailto:di= spatch-bounces@ietf.org] On Behalf Of Ram
> Mohan R (rmohanr)
> Sent: 06 February 2014 16:20
> To: Gerben Stam
> Cc: dispatch@ietf.org
> Subject: Re: [dispatch] Lossless Recording in SIPREC
>
> Hi,
>
> Please see inline
>
> -----Original Message-----
> From: Gerben Stam <Gerben.S= tam@nice.com>
> Date: Thursday, 6 February 2014 8:40 pm
> To: Cisco Employee <rmohanr@ci= sco.com>
> Cc: "dispatch@ietf.org&q= uot; <dispatch@ietf.org>
> Subject: RE: [dispatch] Lossless Recording in SIPREC
>
> >Hey Ram,
> >
> >I have had an off-line discussion with Andrew Hutton, chairman of = the
> >SIPREC group.
> >He suggested to post this on the IETF dispatch group as it is a go= od
> >topic to discuss in the team.
>
> Ok. I was not aware of this.
>
> >
> >What would I need to do to bend this to SIPREC WG instead of Dispa= tch?
> >
> >Regards,
> >
> >Gerben
> >
> >-----Original Message-----
> >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]
> >Sent: donderdag 6 februari 2014 15:45
> >To: Gerben Stam
> >Cc: dispatch@ietf.org
> >Subject: Re: [dispatch] Lossless Recording in SIPREC
> >
> >Hi,
> >
> >Is there a reason why you want to have this discussion in dispatch= and
> >not in SIPREC WG which is meant to discuss the issues around SIP > >recording ?
> >If you don=B9t have any specific reason to do it here you may want= to
> start
> >this discussion in SIPREC WG.
> >
> >I do have some comments on this topic but I think SIPREC WG is the=
> right
> >place to have those discussions.
> >
> >
> >Regards,
> >Ram
> >
> >From:  Gerben Stam <Gerben.Stam@nice.com>
> >Date:  Thursday, 6 February 2014 3:58 pm
> >To:  Gerben Stam <= Gerben.Stam@nice.com>
> >Cc:  "dispatch@ietf= .org" <dispatch@ietf.org>
> >Subject:  [dispatch] Lossless Recording in SIPREC
> >
> >
> >Dear DISPATCH group,
> >
> >SIPREC is a great initiative to standardize the interface for
> capturing
> >Communication Sessions.
> >Session Recording is becoming more and more critical due to Compli= ance
> >and regulatory changes over the last years.
> >
> >The compliance market is requesting more than capture only these d= ays
> >Confirmation is needed to acknowledge the entire Communication Ses= sion
> >was captured correctly.
> >RTCP Reports (rfc3611) will help to confirm complete handover of R= TP
> >content.
> >
> >
> >
> >New requirement is =8Clossless=B9 Session Capturing.
>
> Why is this a new requirement ? RFC 6341 (SIPREC requirements) already=
> has
> a requirement for Lossless recording. See REQ 005.
>
>
> >Lossless indicating handover of content (RTP) is acknowledged by t= he
> >receiver AND in case of receiving issues, the sender will resend.<= br> > >Reasons for loss may be UDP packet loss or receiver failing(over) = and
> >temporary not able to accept content.
> >Current approach to address this =8Clossless=B9 requirement is usi= ng 2
> >independent parallel receivers.
>
> There may be other approaches well. For example an SRC may buffer for = a
> small duration to take care of the loss. Two parallel receivers still<= br> > does
> not guarantee that recording is loseless as you can have UDP packet > loss
> on both paths.
>
> >
> >This requires the sender to send 2 individual streams, in fact 2 > >independent SIPREC sessions.
> >
> >Not sure if this is covered currently as supported SIPREC deployme= nt.
>
>
> Current SIPREC does not have any such constraints. Depending on your > implementation model you can have the same CS recorded by multiple SRC=
> or
> have same SRC do multiple recordings of same CS.
>
> Regards,
> Ram
>
> > We do see implementations based on SIPREC supporting it.
> >Alternative is quick failover at receiver in case of failure but a= s
> >sender will send only once, this may lead to loss during failover.=
> >
> >I am not aware of any rfc covering lossless content handover, but<= br> > there
> >may be standards covering this already.
> >
> >
> >Looking forward to discussion on the mailing list. I may be at the=
> London
> >event.
> >
> >Regards,
> >
> >Gerben Stam,
> >NICE Systems
> >
> >
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--_000_949EF20990823C4C85C18D59AA11AD8B12F844FR712WXCHMBA11zeu_-- From mary.ietf.barnes@gmail.com Mon Feb 10 12:04:07 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922961A0870 for ; Mon, 10 Feb 2014 12:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8aEimBV2H57 for ; Mon, 10 Feb 2014 12:04:01 -0800 (PST) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 8FE671A06D6 for ; Mon, 10 Feb 2014 12:04:01 -0800 (PST) Received: by mail-yk0-f174.google.com with SMTP id 20so8483318yks.5 for ; Mon, 10 Feb 2014 12:04:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6YeqIzlxNgWq0u78GWqtwbbSsRbGS63MYDSlyidncts=; b=RT0ujxvKx1wkkPtvARXIjnR6nF6WF/AFG7TIMXKOZbc91gJeL2y4q2RzAesTEjLDbf 9E6WzFHlZI4xpRwf6m3DHkjrrtO4K9aavqlWjehp+W8SFYc8fOCf+VhwQ12k5kirIzhQ pBf+RV1VEEmyvUgzIndTq21Ek+C8IYwGzKYj61gEgpn/jQwBacjisc3yEs9KxVF61rR2 Qe0EKUYdoFjqOR3GrlR1ZGM+66zd95Thtxkc9/FUkZ5jzIk4sn2sXFjpnVNvWtRDJOTK aI7UTUx0h7cr9VTQgaVuZYrc2TyTpgpAYs9hdcaGNetok++sIFbCe8l3nLEbgXa2skCH 3N3Q== MIME-Version: 1.0 X-Received: by 10.236.130.116 with SMTP id j80mr2283722yhi.140.1392062641213; Mon, 10 Feb 2014 12:04:01 -0800 (PST) Received: by 10.170.150.2 with HTTP; Mon, 10 Feb 2014 12:04:01 -0800 (PST) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B12F844@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <9F33F40F6F2CD847824537F3C4E37DDF17CEDF53@MCHP04MSX.global-ad.net> <949EF20990823C4C85C18D59AA11AD8B12F844@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Mon, 10 Feb 2014 14:04:01 -0600 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=20cf3010e62b3c14ca04f212d72a Cc: Gerben Stam , "dispatch@ietf.org" Subject: Re: [dispatch] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 20:04:07 -0000 --20cf3010e62b3c14ca04f212d72a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Keith, I'm not sure what your point is. The DISPATCH WG chairs make recommendations to the ADs based upon what they perceive as interest on the DISPATCH WG mailing list. If you concerns about an explicit action noted below, please be specific. It's not clear to me whether your concerned about the decision for the discussion to move to SIPREC or the general DISPATCH approach. Mary. On Mon, Feb 10, 2014 at 1:42 PM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > According to the charter: > > The Dispatch working group is chartered to consider proposals for > new work in the RAI area and identify, or help create, an appropriate > venue for the work. > > I would read this as a working group decision rather than a WG chairs > decision. > > Keith > > > > ------------------------------ > *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Mary > Barnes > *Sent:* 10 February 2014 16:39 > *To:* Hutton, Andrew > *Cc:* Gerben Stam; dispatch@ietf.org > > *Subject:* Re: [dispatch] Lossless Recording in SIPREC > > Yes, that is the appropriate action. The ADs just met with the DISPATCH > WG chairs in preparation for IETF-89. We discussed this topic and agree > that discussion should move to SIPREC WG mailing list. But, it's importan= t > to note that this dispatchment in no way implies that the community agree= s > that work is needed. It's up to the SIPREC WG to make that decision. > > Regards, > Mary > DISPATCH WG co-chair. > > > On Mon, Feb 10, 2014 at 8:05 AM, Hutton, Andrew = wrote: > >> Hi Gerben, >> >> Looking back at our off-list discussion I did actually say that you >> "should start a discussion on the SIPREC list". >> >> Sorry if there was confusion. >> >> Andy >> >> > -----Original Message----- >> > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ram >> > Mohan R (rmohanr) >> > Sent: 06 February 2014 16:20 >> > To: Gerben Stam >> > Cc: dispatch@ietf.org >> > Subject: Re: [dispatch] Lossless Recording in SIPREC >> > >> > Hi, >> > >> > Please see inline >> > >> > -----Original Message----- >> > From: Gerben Stam >> > Date: Thursday, 6 February 2014 8:40 pm >> > To: Cisco Employee >> > Cc: "dispatch@ietf.org" >> > Subject: RE: [dispatch] Lossless Recording in SIPREC >> > >> > >Hey Ram, >> > > >> > >I have had an off-line discussion with Andrew Hutton, chairman of the >> > >SIPREC group. >> > >He suggested to post this on the IETF dispatch group as it is a good >> > >topic to discuss in the team. >> > >> > Ok. I was not aware of this. >> > >> > > >> > >What would I need to do to bend this to SIPREC WG instead of Dispatch= ? >> > > >> > >Regards, >> > > >> > >Gerben >> > > >> > >-----Original Message----- >> > >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >> > >Sent: donderdag 6 februari 2014 15:45 >> > >To: Gerben Stam >> > >Cc: dispatch@ietf.org >> > >Subject: Re: [dispatch] Lossless Recording in SIPREC >> > > >> > >Hi, >> > > >> > >Is there a reason why you want to have this discussion in dispatch an= d >> > >not in SIPREC WG which is meant to discuss the issues around SIP >> > >recording ? >> > >If you don=B9t have any specific reason to do it here you may want to >> > start >> > >this discussion in SIPREC WG. >> > > >> > >I do have some comments on this topic but I think SIPREC WG is the >> > right >> > >place to have those discussions. >> > > >> > > >> > >Regards, >> > >Ram >> > > >> > >From: Gerben Stam >> > >Date: Thursday, 6 February 2014 3:58 pm >> > >To: Gerben Stam >> > >Cc: "dispatch@ietf.org" >> > >Subject: [dispatch] Lossless Recording in SIPREC >> > > >> > > >> > >Dear DISPATCH group, >> > > >> > >SIPREC is a great initiative to standardize the interface for >> > capturing >> > >Communication Sessions. >> > >Session Recording is becoming more and more critical due to Complianc= e >> > >and regulatory changes over the last years. >> > > >> > >The compliance market is requesting more than capture only these days >> > >Confirmation is needed to acknowledge the entire Communication Sessio= n >> > >was captured correctly. >> > >RTCP Reports (rfc3611) will help to confirm complete handover of RTP >> > >content. >> > > >> > > >> > > >> > >New requirement is OElossless=B9 Session Capturing. >> > >> > Why is this a new requirement ? RFC 6341 (SIPREC requirements) already >> > has >> > a requirement for Lossless recording. See REQ 005. >> > >> > >> > >Lossless indicating handover of content (RTP) is acknowledged by the >> > >receiver AND in case of receiving issues, the sender will resend. >> > >Reasons for loss may be UDP packet loss or receiver failing(over) and >> > >temporary not able to accept content. >> > >Current approach to address this OElossless=B9 requirement is using 2 >> > >independent parallel receivers. >> > >> > There may be other approaches well. For example an SRC may buffer for = a >> > small duration to take care of the loss. Two parallel receivers still >> > does >> > not guarantee that recording is loseless as you can have UDP packet >> > loss >> > on both paths. >> > >> > > >> > >This requires the sender to send 2 individual streams, in fact 2 >> > >independent SIPREC sessions. >> > > >> > >Not sure if this is covered currently as supported SIPREC deployment. >> > >> > >> > Current SIPREC does not have any such constraints. Depending on your >> > implementation model you can have the same CS recorded by multiple SRC >> > or >> > have same SRC do multiple recordings of same CS. >> > >> > Regards, >> > Ram >> > >> > > We do see implementations based on SIPREC supporting it. >> > >Alternative is quick failover at receiver in case of failure but as >> > >sender will send only once, this may lead to loss during failover. >> > > >> > >I am not aware of any rfc covering lossless content handover, but >> > there >> > >may be standards covering this already. >> > > >> > > >> > >Looking forward to discussion on the mailing list. I may be at the >> > London >> > >event. >> > > >> > >Regards, >> > > >> > >Gerben Stam, >> > >NICE Systems >> > > >> > > >> > >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > --20cf3010e62b3c14ca04f212d72a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Keith,

I'm not sure what your point= is.  The DISPATCH WG chairs make recommendations to the ADs based upo= n what they perceive as interest on the DISPATCH WG mailing list.   If= you concerns about an explicit action noted below, please be specific. &nb= sp;It's not clear to me whether your concerned about the decision for t= he discussion to move to SIPREC or the general DISPATCH approach.  

Mary.


On Mon, Feb 10, 2014 at 1:42 PM, DRAGE, Keith (Keit= h) <keith.drage@alcatel-lucent.com> wrote:
According to the charter:
 
The Dispatch working group is charter= ed to consider proposals for
new work in the RAI area and identify, or help create, an appropriate
venue for the work.
 
I would read this as a wo= rking group decision rather than a WG chairs decision.
 
Keith
 
 

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 10 February 2014 16:39
To: Hutton, Andrew
Cc: Gerben Stam; dispatch@ietf.org

Subject: Re: [dispatch] Lossless Recording in SIPREC

Yes, that is the appropriate action.  The ADs just me= t with the DISPATCH WG chairs in preparation for IETF-89. We discussed this= topic and agree that discussion should move to SIPREC WG mailing list. But= , it's important to note that this dispatchment in no way implies that the community agrees that work is needed. It's = up to the SIPREC WG to make that decision.

Regards,
Mary 
DISPATCH WG co-chair. 


On Mon, Feb 10, 2014 at 8:05 AM, Hutton, Andrew = <andrew.hut= ton@unify.com> wrote:
Hi Gerben,

Looking back at our off-list discussion I did actually say that you "s= hould start a discussion on the SIPREC list".

Sorry if there was confusion.

Andy

> -----Original Message-----
> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ram
> Mohan R (rmohanr)
> Sent: 06 February 2014 16:20
> To: Gerben Stam
> Cc: dispatch@ie= tf.org
> Subject: Re: [dispatch] Lossless Recording in SIPREC
>
> Hi,
>
> Please see inline
>
> -----Original Message-----
> From: Gerben Stam <Gerben.Stam@nice.com>
> Date: Thursday, 6 February 2014 8:40 pm
> To: Cisco Employee <rmohanr@cisco.com>
> Cc: "dispa= tch@ietf.org" <dispatch@ietf.org>
> Subject: RE: [dispatch] Lossless Recording in SIPREC
>
> >Hey Ram,
> >
> >I have had an off-line discussion with Andrew Hutton, chairman of = the
> >SIPREC group.
> >He suggested to post this on the IETF dispatch group as it is a go= od
> >topic to discuss in the team.
>
> Ok. I was not aware of this.
>
> >
> >What would I need to do to bend this to SIPREC WG instead of Dispa= tch?
> >
> >Regards,
> >
> >Gerben
> >
> >-----Original Message-----
> >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]
> >Sent: donderdag 6 februari 2014 15:45
> >To: Gerben Stam
> >Cc: dispatc= h@ietf.org
> >Subject: Re: [dispatch] Lossless Recording in SIPREC
> >
> >Hi,
> >
> >Is there a reason why you want to have this discussion in dispatch= and
> >not in SIPREC WG which is meant to discuss the issues around SIP > >recording ?
> >If you don=B9t have any specific reason to do it here you may want= to
> start
> >this discussion in SIPREC WG.
> >
> >I do have some comments on this topic but I think SIPREC WG is the=
> right
> >place to have those discussions.
> >
> >
> >Regards,
> >Ram
> >
> >From:  Gerben Stam <Gerben.Stam@nice.com>
> >Date:  Thursday, 6 February 2014 3:58 pm
> >To:  Gerben Stam <Gerben.Stam@nice.com>
> >Cc:  "dispatch@ietf.org" <dispatch@ietf.org>
> >Subject:  [dispatch] Lossless Recording in SIPREC
> >
> >
> >Dear DISPATCH group,
> >
> >SIPREC is a great initiative to standardize the interface for
> capturing
> >Communication Sessions.
> >Session Recording is becoming more and more critical due to Compli= ance
> >and regulatory changes over the last years.
> >
> >The compliance market is requesting more than capture only these d= ays
> >Confirmation is needed to acknowledge the entire Communication Ses= sion
> >was captured correctly.
> >RTCP Reports (rfc3611) will help to confirm complete handover of R= TP
> >content.
> >
> >
> >
> >New requirement is Œlossless=B9 Session Capturing.
>
> Why is this a new requirement ? RFC 6341 (SIPREC requirements) already=
> has
> a requirement for Lossless recording. See REQ 005.
>
>
> >Lossless indicating handover of content (RTP) is acknowledged by t= he
> >receiver AND in case of receiving issues, the sender will resend.<= br> > >Reasons for loss may be UDP packet loss or receiver failing(over) = and
> >temporary not able to accept content.
> >Current approach to address this Œlossless=B9 requirement is= using 2
> >independent parallel receivers.
>
> There may be other approaches well. For example an SRC may buffer for = a
> small duration to take care of the loss. Two parallel receivers still<= br> > does
> not guarantee that recording is loseless as you can have UDP packet > loss
> on both paths.
>
> >
> >This requires the sender to send 2 individual streams, in fact 2 > >independent SIPREC sessions.
> >
> >Not sure if this is covered currently as supported SIPREC deployme= nt.
>
>
> Current SIPREC does not have any such constraints. Depending on your > implementation model you can have the same CS recorded by multiple SRC=
> or
> have same SRC do multiple recordings of same CS.
>
> Regards,
> Ram
>
> > We do see implementations based on SIPREC supporting it.
> >Alternative is quick failover at receiver in case of failure but a= s
> >sender will send only once, this may lead to loss during failover.=
> >
> >I am not aware of any rfc covering lossless content handover, but<= br> > there
> >may be standards covering this already.
> >
> >
> >Looking forward to discussion on the mailing list. I may be at the=
> London
> >event.
> >
> >Regards,
> >
> >Gerben Stam,
> >NICE Systems
> >
> >
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--20cf3010e62b3c14ca04f212d72a-- From keith.drage@alcatel-lucent.com Mon Feb 10 13:19:12 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB4CD1A0549 for ; Mon, 10 Feb 2014 13:19:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sixSgQoOEQIi for ; Mon, 10 Feb 2014 13:19:08 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id BA1681A0407 for ; Mon, 10 Feb 2014 13:19:08 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1ALJ5AG021496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2014 15:19:06 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1ALJ5Cc007988 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 22:19:05 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 22:19:05 +0100 From: "DRAGE, Keith (Keith)" To: Mary Barnes Thread-Topic: [dispatch] Lossless Recording in SIPREC Thread-Index: AQHPJps9x59IE/b4SkKjD7FE2seEVZqu9tOA Date: Mon, 10 Feb 2014 21:19:04 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B12FA03@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <9F33F40F6F2CD847824537F3C4E37DDF17CEDF53@MCHP04MSX.global-ad.net> <949EF20990823C4C85C18D59AA11AD8B12F844@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B12FA03FR712WXCHMBA11zeu_" MIME-Version: 1.0 Cc: Gerben Stam , "dispatch@ietf.org" Subject: Re: [dispatch] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 21:19:13 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B12FA03FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable The ADs make decisions. The DISPATCH WG chairs are there to represent the consensus of the WG. The = charter does not create a special role for the DISPATCH WG chairs that goes= beyond the role of any other WG chair. While I do not necessarily regard this as contentious, the only discussion = we have had on the list is whether it should go to dispatch first. The WG h= as had no mails that say: "Let's dispatch this to SIPREC." So my concern is that the WG itself has been effectively ignored. Let us see the question put to the WG. regards Keith ________________________________ From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 10 February 2014 20:04 To: DRAGE, Keith (Keith) Cc: Hutton, Andrew; Gerben Stam; dispatch@ietf.org Subject: Re: [dispatch] Lossless Recording in SIPREC Keith, I'm not sure what your point is. The DISPATCH WG chairs make recommendatio= ns to the ADs based upon what they perceive as interest on the DISPATCH WG = mailing list. If you concerns about an explicit action noted below, pleas= e be specific. It's not clear to me whether your concerned about the decis= ion for the discussion to move to SIPREC or the general DISPATCH approach. Mary. On Mon, Feb 10, 2014 at 1:42 PM, DRAGE, Keith (Keith) > wrote: According to the charter: The Dispatch working group is chartered to consider proposals for new work in the RAI area and identify, or help create, an appropriate venue for the work. I would read this as a working group decision rather than a WG chairs decis= ion. Keith ________________________________ From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 10 February 2014 16:39 To: Hutton, Andrew Cc: Gerben Stam; dispatch@ietf.org Subject: Re: [dispatch] Lossless Recording in SIPREC Yes, that is the appropriate action. The ADs just met with the DISPATCH WG= chairs in preparation for IETF-89. We discussed this topic and agree that = discussion should move to SIPREC WG mailing list. But, it's important to no= te that this dispatchment in no way implies that the community agrees that = work is needed. It's up to the SIPREC WG to make that decision. Regards, Mary DISPATCH WG co-chair. On Mon, Feb 10, 2014 at 8:05 AM, Hutton, Andrew > wrote: Hi Gerben, Looking back at our off-list discussion I did actually say that you "should= start a discussion on the SIPREC list". Sorry if there was confusion. Andy > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ram > Mohan R (rmohanr) > Sent: 06 February 2014 16:20 > To: Gerben Stam > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Lossless Recording in SIPREC > > Hi, > > Please see inline > > -----Original Message----- > From: Gerben Stam > > Date: Thursday, 6 February 2014 8:40 pm > To: Cisco Employee > > Cc: "dispatch@ietf.org" > > Subject: RE: [dispatch] Lossless Recording in SIPREC > > >Hey Ram, > > > >I have had an off-line discussion with Andrew Hutton, chairman of the > >SIPREC group. > >He suggested to post this on the IETF dispatch group as it is a good > >topic to discuss in the team. > > Ok. I was not aware of this. > > > > >What would I need to do to bend this to SIPREC WG instead of Dispatch? > > > >Regards, > > > >Gerben > > > >-----Original Message----- > >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] > >Sent: donderdag 6 februari 2014 15:45 > >To: Gerben Stam > >Cc: dispatch@ietf.org > >Subject: Re: [dispatch] Lossless Recording in SIPREC > > > >Hi, > > > >Is there a reason why you want to have this discussion in dispatch and > >not in SIPREC WG which is meant to discuss the issues around SIP > >recording ? > >If you don=B9t have any specific reason to do it here you may want to > start > >this discussion in SIPREC WG. > > > >I do have some comments on this topic but I think SIPREC WG is the > right > >place to have those discussions. > > > > > >Regards, > >Ram > > > >From: Gerben Stam > > >Date: Thursday, 6 February 2014 3:58 pm > >To: Gerben Stam > > >Cc: "dispatch@ietf.org" > > >Subject: [dispatch] Lossless Recording in SIPREC > > > > > >Dear DISPATCH group, > > > >SIPREC is a great initiative to standardize the interface for > capturing > >Communication Sessions. > >Session Recording is becoming more and more critical due to Compliance > >and regulatory changes over the last years. > > > >The compliance market is requesting more than capture only these days > >Confirmation is needed to acknowledge the entire Communication Session > >was captured correctly. > >RTCP Reports (rfc3611) will help to confirm complete handover of RTP > >content. > > > > > > > >New requirement is =8Clossless=B9 Session Capturing. > > Why is this a new requirement ? RFC 6341 (SIPREC requirements) already > has > a requirement for Lossless recording. See REQ 005. > > > >Lossless indicating handover of content (RTP) is acknowledged by the > >receiver AND in case of receiving issues, the sender will resend. > >Reasons for loss may be UDP packet loss or receiver failing(over) and > >temporary not able to accept content. > >Current approach to address this =8Clossless=B9 requirement is using 2 > >independent parallel receivers. > > There may be other approaches well. For example an SRC may buffer for a > small duration to take care of the loss. Two parallel receivers still > does > not guarantee that recording is loseless as you can have UDP packet > loss > on both paths. > > > > >This requires the sender to send 2 individual streams, in fact 2 > >independent SIPREC sessions. > > > >Not sure if this is covered currently as supported SIPREC deployment. > > > Current SIPREC does not have any such constraints. Depending on your > implementation model you can have the same CS recorded by multiple SRC > or > have same SRC do multiple recordings of same CS. > > Regards, > Ram > > > We do see implementations based on SIPREC supporting it. > >Alternative is quick failover at receiver in case of failure but as > >sender will send only once, this may lead to loss during failover. > > > >I am not aware of any rfc covering lossless content handover, but > there > >may be standards covering this already. > > > > > >Looking forward to discussion on the mailing list. I may be at the > London > >event. > > > >Regards, > > > >Gerben Stam, > >NICE Systems > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_949EF20990823C4C85C18D59AA11AD8B12FA03FR712WXCHMBA11zeu_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
The ADs make decisions.
 
The DISPATCH WG chairs are there = to represent the consensus of the WG. The charter does not create a special= role for the DISPATCH WG chairs that goes beyond the role of any other WG chair.
 
While I do not necessarily regard= this as contentious, the only discussion we have had on the list is whethe= r it should go to dispatch first. The WG has had no mails that say: "Let's dispatch this to SIPREC."
 
So my concern is that the WG itse= lf has been effectively ignored.
 
Let us see the question put to th= e WG.
 
regards
 
Keith

From: Mary Barnes [mailto:mary.ietf= .barnes@gmail.com]
Sent: 10 February 2014 20:04
To: DRAGE, Keith (Keith)
Cc: Hutton, Andrew; Gerben Stam; dispatch@ietf.org
Subject: Re: [dispatch] Lossless Recording in SIPREC

Keith,

I'm not sure what your point is.  The DISPATCH WG chairs make rec= ommendations to the ADs based upon what they perceive as interest on the DI= SPATCH WG mailing list.   If you concerns about an explicit action not= ed below, please be specific.  It's not clear to me whether your concerned about the decision for the discussion to move= to SIPREC or the general DISPATCH approach.  

Mary.


On Mon, Feb 10, 2014 at 1:42 PM, DRAGE, Keith (K= eith) <kei= th.drage@alcatel-lucent.com> wrote:
According to the charter:
 
The Dispatch working group is charter= ed to consider proposals for
new work in the RAI area and identify, or help create, an appropriate
venue for the work.
 
I would read this as a wo= rking group decision rather than a WG chairs decision.
 
Keith
 
 

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 10 February 2014 16:39
To: Hutton, Andrew
Cc: Gerben Stam; dispatch@ietf.org

Subject: Re: [dispatch] Lossless Recording in SIPREC

Yes, that is the appropriate action.  The ADs just me= t with the DISPATCH WG chairs in preparation for IETF-89. We discussed this= topic and agree that discussion should move to SIPREC WG mailing list. But= , it's important to note that this dispatchment in no way implies that the community agrees that work is needed. It's up t= o the SIPREC WG to make that decision.

Regards,
Mary 
DISPATCH WG co-chair. 


On Mon, Feb 10, 2014 at 8:05 AM, Hutton, Andrew = <andrew.hut= ton@unify.com> wrote:
Hi Gerben,

Looking back at our off-list discussion I did actually say that you "s= hould start a discussion on the SIPREC list".

Sorry if there was confusion.

Andy

> -----Original Message-----
> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ram
> Mohan R (rmohanr)
> Sent: 06 February 2014 16:20
> To: Gerben Stam
> Cc: dispatch@ie= tf.org
> Subject: Re: [dispatch] Lossless Recording in SIPREC
>
> Hi,
>
> Please see inline
>
> -----Original Message-----
> From: Gerben Stam <Gerben.Stam@nice.com>
> Date: Thursday, 6 February 2014 8:40 pm
> To: Cisco Employee <rmohanr@cisco.com>
> Cc: "dispa= tch@ietf.org" <dispatch@ietf.org>
> Subject: RE: [dispatch] Lossless Recording in SIPREC
>
> >Hey Ram,
> >
> >I have had an off-line discussion with Andrew Hutton, chairman of = the
> >SIPREC group.
> >He suggested to post this on the IETF dispatch group as it is a go= od
> >topic to discuss in the team.
>
> Ok. I was not aware of this.
>
> >
> >What would I need to do to bend this to SIPREC WG instead of Dispa= tch?
> >
> >Regards,
> >
> >Gerben
> >
> >-----Original Message-----
> >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]
> >Sent: donderdag 6 februari 2014 15:45
> >To: Gerben Stam
> >Cc: dispatc= h@ietf.org
> >Subject: Re: [dispatch] Lossless Recording in SIPREC
> >
> >Hi,
> >
> >Is there a reason why you want to have this discussion in dispatch= and
> >not in SIPREC WG which is meant to discuss the issues around SIP > >recording ?
> >If you don=B9t have any specific reason to do it here you may want= to
> start
> >this discussion in SIPREC WG.
> >
> >I do have some comments on this topic but I think SIPREC WG is the=
> right
> >place to have those discussions.
> >
> >
> >Regards,
> >Ram
> >
> >From:  Gerben Stam <Gerben.Stam@nice.com>
> >Date:  Thursday, 6 February 2014 3:58 pm
> >To:  Gerben Stam <Gerben.Stam@nice.com>
> >Cc:  "dispatch@ietf.org" <dispatch@ietf.org>
> >Subject:  [dispatch] Lossless Recording in SIPREC
> >
> >
> >Dear DISPATCH group,
> >
> >SIPREC is a great initiative to standardize the interface for
> capturing
> >Communication Sessions.
> >Session Recording is becoming more and more critical due to Compli= ance
> >and regulatory changes over the last years.
> >
> >The compliance market is requesting more than capture only these d= ays
> >Confirmation is needed to acknowledge the entire Communication Ses= sion
> >was captured correctly.
> >RTCP Reports (rfc3611) will help to confirm complete handover of R= TP
> >content.
> >
> >
> >
> >New requirement is =8Clossless=B9 Session Capturing.
>
> Why is this a new requirement ? RFC 6341 (SIPREC requirements) already=
> has
> a requirement for Lossless recording. See REQ 005.
>
>
> >Lossless indicating handover of content (RTP) is acknowledged by t= he
> >receiver AND in case of receiving issues, the sender will resend.<= br> > >Reasons for loss may be UDP packet loss or receiver failing(over) = and
> >temporary not able to accept content.
> >Current approach to address this =8Clossless=B9 requirement is usi= ng 2
> >independent parallel receivers.
>
> There may be other approaches well. For example an SRC may buffer for = a
> small duration to take care of the loss. Two parallel receivers still<= br> > does
> not guarantee that recording is loseless as you can have UDP packet > loss
> on both paths.
>
> >
> >This requires the sender to send 2 individual streams, in fact 2 > >independent SIPREC sessions.
> >
> >Not sure if this is covered currently as supported SIPREC deployme= nt.
>
>
> Current SIPREC does not have any such constraints. Depending on your > implementation model you can have the same CS recorded by multiple SRC=
> or
> have same SRC do multiple recordings of same CS.
>
> Regards,
> Ram
>
> > We do see implementations based on SIPREC supporting it.
> >Alternative is quick failover at receiver in case of failure but a= s
> >sender will send only once, this may lead to loss during failover.=
> >
> >I am not aware of any rfc covering lossless content handover, but<= br> > there
> >may be standards covering this already.
> >
> >
> >Looking forward to discussion on the mailing list. I may be at the=
> London
> >event.
> >
> >Regards,
> >
> >Gerben Stam,
> >NICE Systems
> >
> >
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--_000_949EF20990823C4C85C18D59AA11AD8B12FA03FR712WXCHMBA11zeu_-- From keith.drage@alcatel-lucent.com Mon Feb 10 13:19:16 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9331A0823 for ; Mon, 10 Feb 2014 13:19:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QucKQ523kB7Y for ; Mon, 10 Feb 2014 13:19:13 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id E3CF61A0407 for ; Mon, 10 Feb 2014 13:19:12 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1ALJ7e7003129 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Feb 2014 15:19:08 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1ALJ6pb009840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 10 Feb 2014 22:19:06 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 10 Feb 2014 22:19:06 +0100 From: "DRAGE, Keith (Keith)" To: Kurtis Heimerl Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIIAAPqkAgAASvbD///eJAIAAMB4g Date: Mon, 10 Feb 2014 21:19:05 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B12FA06FR712WXCHMBA11zeu_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 21:19:16 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B12FA06FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd contend that there is not enough information in the diagram to identify= either point of view. What I am beginning to understand is that the SIP registrar is not colocate= d with the BTS, and therefore the subscriber records for the GERAN usage ar= e physically seaparate and distinct from those of the SIP usage. Therefore = to add a subscriber to the system, tou have to update the HLR records in th= e BTS (and every BTS that is serving that user) and the records at the SIP = registrar / location server. Is there a requirement to correlate accounting records between the two usag= es? Mobility management is not I assume converted to SIP. The original descript= ion said they would use REFER to do such functions. It has not been clear w= hether that is supported by a centralised function (at or distinct from the= registrar / location server) or whether this is performed UE to UE. This n= eeds to be clarified. I would very much suspect this is going to need the d= efinition of some new protocol to indicate support of various capabilities = (This is a special REFER because it comes from my other registration over a= different proxy, and not any old REFER). regards Keith ________________________________ From: munncha@gmail.com [mailto:munncha@gmail.com] On Behalf Of Kurtis Heim= erl Sent: 10 February 2014 19:05 To: DRAGE, Keith (Keith) Cc: Tim Panton new; dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS You're misreading the diagram. As can be seen, multiple OpenBTS instances c= an talk to a single instance of the SAS. This allows for centralized chargi= ng and accounting for multiple BTS instances wherever the SAS is hosted. As far as the 3GPP mobility management protocols (if I know which ones you = are speaking of), those are converted to SIP (as is everything) and sent to= the SAS. So I would say we are using these protocols between BTSs, especia= lly for handover. On Tue, Feb 11, 2014 at 3:43 AM, DRAGE, Keith (Keith) > wrote: I am not assuming a specific solution - what we are all trying to find out = is how much of 3GPP GERAN is actually being used, and what identities relat= e to what. So you will have a UICC - because it is a 3GPP GERAN access network, but wi= ll not have any roaming that relates to the UICC, or the identities on that= UICC. But as far as I can see from the architecture given, the service is limited= to a single BTS. That means that (for the solution you identify below) an = operator with multiple BTSs will assign their users to a single BTS and the= collation of charging/accounting will have to be from each individual BTS,= back to some central entity (not shown). You will not be running the 3GPP mobility management protocols between BTS. Keith Drage > -----Original Message----- > From: Tim Panton new [mailto:thp@westhawk.co.uk] > Sent: 10 February 2014 18:28 > To: DRAGE, Keith (Keith) > Cc: Jim Forster; Mary Barnes; dispatch@ietf.org > Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS > > > On 10 Feb 2014, at 17:56, DRAGE, Keith (Keith) > > w= rote: > > > If I follow this diagram correctly, you claim to have > collapsed the HLR into your BTS. Your BTS apparently have no > communication shown with each other. This means you each > subscriber is limited to a single BTS with no roaming between them. > > I think you are assuming a specific solution to a specific problem. > Many ITSPs allow SIP registrations to a DID/account to come > from dynamic IPs. So the necessary 'communication' can be > implemented via the ITSP's normal functions. So when a user > moves from the BTS in village A to the BTS in village B > their DID travels with them. > > Sure you wouldn't get the ability for an arbitrary GSM SIM to > roam into the network and be billed to their home network. > > But realistically that sort of roaming isn't really a > technical problem, it is predominantly a legal/commercial one. > > Tim. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_949EF20990823C4C85C18D59AA11AD8B12FA06FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I'd contend that there is not eno= ugh information in the diagram to identify either point of view.
 
What I am beginning to understand= is that the SIP registrar is not colocated with the BTS, and therefore the= subscriber records for the GERAN usage are physically seaparate and distinct from those of the SIP usage. Therefore t= o add a subscriber to the system, tou have to update the HLR records in the= BTS (and every BTS that is serving that user) and the records at the SIP r= egistrar / location server.
 
Is there a requirement to correla= te accounting records between the two usages?
 
Mobility management is not I assu= me converted to SIP. The original description said they would use REFER to = do such functions. It has not been clear whether that is supported by a centralised function (at or distinct from the regis= trar / location server) or whether this is performed UE to UE. This needs t= o be clarified. I would very much suspect this is going to need the definit= ion of some new protocol to indicate support of various capabilities (This is a special REFER because it comes = from my other registration over a different proxy, and not any old REFER).<= /font>
 
regards
 
Keith

From: munncha@gmail.com [mailto:mun= ncha@gmail.com] On Behalf Of Kurtis Heimerl
Sent: 10 February 2014 19:05
To: DRAGE, Keith (Keith)
Cc: Tim Panton new; dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

You're misreading the diagram. As can be seen, multiple Op= enBTS instances can talk to a single instance of the SAS. This allows for c= entralized charging and accounting for multiple BTS instances wherever the = SAS is hosted.

As far as the 3GPP mobility management protocols (if I know which ones= you are speaking of), those are converted to SIP (as is everything) and se= nt to the SAS. So I would say we are using these protocols between BTSs, es= pecially for handover. 


On Tue, Feb 11, 2014 at 3:43 AM, DRAGE, Keith (K= eith) <kei= th.drage@alcatel-lucent.com> wrote:
I am not assuming a specific solution - what we are all trying to find out = is how much of 3GPP GERAN is actually being used, and what identities relat= e to what.

So you will have a UICC - because it is a 3GPP GERAN access network, but wi= ll not have any roaming that relates to the UICC, or the identities on that= UICC.

But as far as I can see from the architecture given, the service is limited= to a single BTS. That means that (for the solution you identify below) an = operator with multiple BTSs will assign their users to a single BTS and the= collation of charging/accounting will have to be from each individual BTS, back to some central entity (not= shown).

You will not be running the 3GPP mobility management protocols between BTS.=

Keith Drage



> -----Original Message-----
> From: Tim Panton new [mailto:thp= @westhawk.co.uk]
> Sent: 10 February 2014 18:28
> To: DRAGE, Keith (Keith)
> Cc: Jim Forster; Mary Barnes; dispatch@ietf.org
> Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS
>
>
> On 10 Feb 2014, at 17:56, DRAGE, Keith (Keith)
> <keith.drage@alca= tel-lucent.com> wrote:
>
> > If I follow this diagram correctly, you claim to have
> collapsed the HLR into your BTS. Your BTS apparently have no
> communication shown with each other. This means you each
> subscriber is limited to a single BTS with no roaming between them. >
> I think you are assuming a specific solution to a specific problem. > Many ITSPs allow SIP  registrations to a DID/account to come
> from dynamic IPs. So the necessary 'communication' can be
> implemented via the ITSP's normal functions. So when a user
> moves from the BTS in village A to the BTS  in village B
> their DID travels with them.
>
> Sure you wouldn't get the ability for an arbitrary GSM SIM to
> roam into the network and be billed to their home network.
>
> But realistically that sort of roaming isn't really a
> technical problem, it is predominantly a legal/commercial one.
>
> Tim.
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--_000_949EF20990823C4C85C18D59AA11AD8B12FA06FR712WXCHMBA11zeu_-- From worley@shell01.TheWorld.com Mon Feb 10 13:31:26 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6A01A06FD for ; Mon, 10 Feb 2014 13:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWZGGb1QDvlP for ; Mon, 10 Feb 2014 13:31:24 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4CA1A05D5 for ; Mon, 10 Feb 2014 13:31:23 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s1ALV7s9012264; Mon, 10 Feb 2014 16:31:09 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s1ALV47w4688672; Mon, 10 Feb 2014 16:31:04 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s1ALV1we4694874; Mon, 10 Feb 2014 16:31:01 -0500 (EST) Date: Mon, 10 Feb 2014 16:31:01 -0500 (EST) Message-Id: <201402102131.s1ALV1we4694874@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "DRAGE, Keith (Keith)" In-reply-to: <949EF20990823C4C85C18D59AA11AD8B12F844@FR712WXCHMBA11.zeu.alcatel-lucent.com> (keith.drage@alcatel-lucent.com) References: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <9F33F40F6F2CD847824537F3C4E37DDF17CEDF53@MCHP04MSX.global-ad.net> <949EF20990823C4C85C18D59AA11AD8B12F844@FR712WXCHMBA11.zeu.alcatel-lucent.com> Cc: Gerben.Stam@nice.com, dispatch@ietf.org Subject: Re: [dispatch] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 21:31:26 -0000 > From: "DRAGE, Keith (Keith)" > According to the [Dispatch] charter: > > The Dispatch working group is chartered to consider proposals for > new work in the RAI area and identify, or help create, an appropriate > venue for the work. > > I would read this as a working group decision rather than a WG chairs decision. It seems to me that "lossless recording" is well within the defined responsibilities (charter) of Siprec. Siprec may decide that they ultimately need mechanisms that can only be defined by another WG, though... Dale From mary.ietf.barnes@gmail.com Mon Feb 10 13:36:36 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612DE1A088C for ; Mon, 10 Feb 2014 13:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhzOBli3qMOT for ; Mon, 10 Feb 2014 13:36:31 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) by ietfa.amsl.com (Postfix) with ESMTP id 014F11A088B for ; Mon, 10 Feb 2014 13:36:30 -0800 (PST) Received: by mail-yk0-f178.google.com with SMTP id 79so8783424ykr.9 for ; Mon, 10 Feb 2014 13:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fo0qTfoJW7W4VuXT0wcveR8nemSVneHLKO3p4oX/+Os=; b=bgSybRzAd3hnY2y/JDPMNkSGgFC3+QZyU/Lw9PERO0CRqtu2JBl7OALKWsf9GULgJM C47Szp0Gd/pJ4ntmKenGDibDxoyL29/rk1bTVWPQHmEdCSnXiDxcDt2OxFnHQHsV/v8e HWpz6g3+FnDoJk7U7c1jVQUtyG7GGxHPSegZfpZnSX91IjZA7v6XojEF4QW6CZ+0f9q/ GW43pgLHrCDFGPHbREPNt9aM8MyLa1xHeEzgKZ5UzY6kl6MQVtIXCS+iuDO5vitAKW2Z J9/G8/8ti90PZWyO1UDPs8moe3JSt6hFzlUAMnqyEFpRgjYdZTKODtmItOivpp/nLp0n YJMQ== MIME-Version: 1.0 X-Received: by 10.236.150.164 with SMTP id z24mr3769947yhj.75.1392068190550; Mon, 10 Feb 2014 13:36:30 -0800 (PST) Received: by 10.170.150.2 with HTTP; Mon, 10 Feb 2014 13:36:30 -0800 (PST) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B12FA03@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <9F33F40F6F2CD847824537F3C4E37DDF17CEDF53@MCHP04MSX.global-ad.net> <949EF20990823C4C85C18D59AA11AD8B12F844@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA03@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Mon, 10 Feb 2014 15:36:30 -0600 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=20cf303b3c930042ae04f21422e4 Cc: Gerben Stam , "dispatch@ietf.org" Subject: Re: [dispatch] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Feb 2014 21:36:36 -0000 --20cf303b3c930042ae04f21422e4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Feb 10, 2014 at 3:19 PM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > The ADs make decisions. > > The DISPATCH WG chairs are there to represent the consensus of the WG. Th= e > charter does not create a special role for the DISPATCH WG chairs that go= es > beyond the role of any other WG chair. > > While I do not necessarily regard this as contentious, the only discussio= n > we have had on the list is whether it should go to dispatch first. The WG > has had no mails that say: "Let's dispatch this to SIPREC." > [MB] That was the point of the email that I sent earlier. This is the proposal. If you have a compelling reason why we shouldn't do that, then post it. There clearly were suggestions that this topic should just be discussed in SIPREC and Partha had added them to the thread. Another participant actually responded to the thread only in SIPREC (one of the reasons I discourage cross-posting). [/MB] So my concern is that the WG itself has been effectively ignored. > [MB] Read my comment above. There is some common sense to be applied to the process. [/MB] > > Let us see the question put to the WG. > [MB] The whole point of the DISPATCH process is that topics must be posted to allow time for discussion and the WG to raise concerns. The DISPATCH chairs then meet with the ADs (reviewing the relevant threads) and determine whether there is enough interest in a topic and then propose the best way to dispatch the topic. There is nothing in IETF procedures that require chairs to ask explicit questions. Chairs make proposals and if you disagree you can reply, in particular in cases that are clearly non-controversial. Certainly, if there had been the slightest hint of controversy, we would have kept the topic in DISPATCH until there was what the chairs deemed clear consensus. If you read the recording thread carefully, you can see that one of the SIPREC chairs had previously told the individual that the topic should be on SIPREC, so we are actually just clearly stating that with this proposal/decision. If you have concerns about the DISPATCH process, please post a note to the RAI area mailing list. [/MB] > > regards > > Keith > > ------------------------------ > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* 10 February 2014 20:04 > *To:* DRAGE, Keith (Keith) > *Cc:* Hutton, Andrew; Gerben Stam; dispatch@ietf.org > > *Subject:* Re: [dispatch] Lossless Recording in SIPREC > > Keith, > > I'm not sure what your point is. The DISPATCH WG chairs make > recommendations to the ADs based upon what they perceive as interest on t= he > DISPATCH WG mailing list. If you concerns about an explicit action note= d > below, please be specific. It's not clear to me whether your concerned > about the decision for the discussion to move to SIPREC or the general > DISPATCH approach. > > Mary. > > > On Mon, Feb 10, 2014 at 1:42 PM, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote: > >> According to the charter: >> >> The Dispatch working group is chartered to consider proposals for >> new work in the RAI area and identify, or help create, an appropriate >> venue for the work. >> >> I would read this as a working group decision rather than a WG chairs >> decision. >> >> Keith >> >> >> >> ------------------------------ >> *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Mary >> Barnes >> *Sent:* 10 February 2014 16:39 >> *To:* Hutton, Andrew >> *Cc:* Gerben Stam; dispatch@ietf.org >> >> *Subject:* Re: [dispatch] Lossless Recording in SIPREC >> >> Yes, that is the appropriate action. The ADs just met with the >> DISPATCH WG chairs in preparation for IETF-89. We discussed this topic a= nd >> agree that discussion should move to SIPREC WG mailing list. But, it's >> important to note that this dispatchment in no way implies that the >> community agrees that work is needed. It's up to the SIPREC WG to make t= hat >> decision. >> >> Regards, >> Mary >> DISPATCH WG co-chair. >> >> >> On Mon, Feb 10, 2014 at 8:05 AM, Hutton, Andrew wrote: >> >>> Hi Gerben, >>> >>> Looking back at our off-list discussion I did actually say that you >>> "should start a discussion on the SIPREC list". >>> >>> Sorry if there was confusion. >>> >>> Andy >>> >>> > -----Original Message----- >>> > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ram >>> > Mohan R (rmohanr) >>> > Sent: 06 February 2014 16:20 >>> > To: Gerben Stam >>> > Cc: dispatch@ietf.org >>> > Subject: Re: [dispatch] Lossless Recording in SIPREC >>> > >>> > Hi, >>> > >>> > Please see inline >>> > >>> > -----Original Message----- >>> > From: Gerben Stam >>> > Date: Thursday, 6 February 2014 8:40 pm >>> > To: Cisco Employee >>> > Cc: "dispatch@ietf.org" >>> > Subject: RE: [dispatch] Lossless Recording in SIPREC >>> > >>> > >Hey Ram, >>> > > >>> > >I have had an off-line discussion with Andrew Hutton, chairman of th= e >>> > >SIPREC group. >>> > >He suggested to post this on the IETF dispatch group as it is a good >>> > >topic to discuss in the team. >>> > >>> > Ok. I was not aware of this. >>> > >>> > > >>> > >What would I need to do to bend this to SIPREC WG instead of Dispatc= h? >>> > > >>> > >Regards, >>> > > >>> > >Gerben >>> > > >>> > >-----Original Message----- >>> > >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >>> > >Sent: donderdag 6 februari 2014 15:45 >>> > >To: Gerben Stam >>> > >Cc: dispatch@ietf.org >>> > >Subject: Re: [dispatch] Lossless Recording in SIPREC >>> > > >>> > >Hi, >>> > > >>> > >Is there a reason why you want to have this discussion in dispatch a= nd >>> > >not in SIPREC WG which is meant to discuss the issues around SIP >>> > >recording ? >>> > >If you don=B9t have any specific reason to do it here you may want t= o >>> > start >>> > >this discussion in SIPREC WG. >>> > > >>> > >I do have some comments on this topic but I think SIPREC WG is the >>> > right >>> > >place to have those discussions. >>> > > >>> > > >>> > >Regards, >>> > >Ram >>> > > >>> > >From: Gerben Stam >>> > >Date: Thursday, 6 February 2014 3:58 pm >>> > >To: Gerben Stam >>> > >Cc: "dispatch@ietf.org" >>> > >Subject: [dispatch] Lossless Recording in SIPREC >>> > > >>> > > >>> > >Dear DISPATCH group, >>> > > >>> > >SIPREC is a great initiative to standardize the interface for >>> > capturing >>> > >Communication Sessions. >>> > >Session Recording is becoming more and more critical due to Complian= ce >>> > >and regulatory changes over the last years. >>> > > >>> > >The compliance market is requesting more than capture only these day= s >>> > >Confirmation is needed to acknowledge the entire Communication Sessi= on >>> > >was captured correctly. >>> > >RTCP Reports (rfc3611) will help to confirm complete handover of RTP >>> > >content. >>> > > >>> > > >>> > > >>> > >New requirement is OElossless=B9 Session Capturing. >>> > >>> > Why is this a new requirement ? RFC 6341 (SIPREC requirements) alread= y >>> > has >>> > a requirement for Lossless recording. See REQ 005. >>> > >>> > >>> > >Lossless indicating handover of content (RTP) is acknowledged by the >>> > >receiver AND in case of receiving issues, the sender will resend. >>> > >Reasons for loss may be UDP packet loss or receiver failing(over) an= d >>> > >temporary not able to accept content. >>> > >Current approach to address this OElossless=B9 requirement is using = 2 >>> > >independent parallel receivers. >>> > >>> > There may be other approaches well. For example an SRC may buffer for= a >>> > small duration to take care of the loss. Two parallel receivers still >>> > does >>> > not guarantee that recording is loseless as you can have UDP packet >>> > loss >>> > on both paths. >>> > >>> > > >>> > >This requires the sender to send 2 individual streams, in fact 2 >>> > >independent SIPREC sessions. >>> > > >>> > >Not sure if this is covered currently as supported SIPREC deployment= . >>> > >>> > >>> > Current SIPREC does not have any such constraints. Depending on your >>> > implementation model you can have the same CS recorded by multiple SR= C >>> > or >>> > have same SRC do multiple recordings of same CS. >>> > >>> > Regards, >>> > Ram >>> > >>> > > We do see implementations based on SIPREC supporting it. >>> > >Alternative is quick failover at receiver in case of failure but as >>> > >sender will send only once, this may lead to loss during failover. >>> > > >>> > >I am not aware of any rfc covering lossless content handover, but >>> > there >>> > >may be standards covering this already. >>> > > >>> > > >>> > >Looking forward to discussion on the mailing list. I may be at the >>> > London >>> > >event. >>> > > >>> > >Regards, >>> > > >>> > >Gerben Stam, >>> > >NICE Systems >>> > > >>> > > >>> > >>> > _______________________________________________ >>> > dispatch mailing list >>> > dispatch@ietf.org >>> > https://www.ietf.org/mailman/listinfo/dispatch >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> > --20cf303b3c930042ae04f21422e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Feb 10, 2014 at 3:19 PM= , DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com>= ; wrote:
The ADs make decisions.
 
The DISPATCH WG chairs are there to represent the consensus of the WG. Th= e charter does not create a special role for the DISPATCH WG chairs that go= es beyond the role of any other WG chair.
 
While I do not necessarily regard this as contentious, the only discussio= n we have had on the list is whether it should go to dispatch first. The WG= has had no mails that say: "Let's dispatch this to SIPREC."
[MB] 
That was the po= int of the email that I sent earlier.  This is the proposal.  If = you have a compelling reason why we shouldn't do that, then post it.&nb= sp;

There clearly were suggestions that this topic should j= ust be discussed in SIPREC and Partha had added them to the thread.  A= nother participant actually responded to the thread only in SIPREC (one of = the reasons I discourage cross-posting).  
[/MB]

So my concern is that the WG itself has been effectively ignored.<= /span>
[MB] Read my comment above. There is so= me common sense to be applied to the process. [/MB] 
 
Let us see the question put to the WG. 
[MB] The whole point of the DISPATCH process is that topics = must be posted to allow time for discussion and the WG to raise concerns. T= he DISPATCH chairs then meet with the ADs (reviewing the relevant threads) = and determine whether there is enough interest in a topic and then propose = the best way to dispatch the topic.   There is nothing in IETF procedu= res that require chairs to ask explicit questions.  Chairs make propos= als and if you disagree you can reply, in particular in cases that are clea= rly non-controversial.  

  Certainly, if there had been the slightest = hint of controversy, we would have kept the topic in DISPATCH until there w= as what the chairs deemed clear consensus.   If you read the recording= thread carefully, you can see that one of the SIPREC chairs had previously= told the individual that the topic should be on SIPREC, so we are actually= just clearly stating that with this proposal/decision.  If you have c= oncerns about the DISPATCH process, please post a note to the RAI area mail= ing list. [/MB] 
 
regards
 
Keith

From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 10 February 2014 20:04
To: DRAGE, Keith (Keith)
Cc: Hutton, Andrew; Gerben Stam; dispatch@ietf.org

Subject: Re: [dispatch] Lossless Recording in SIPREC

Keith,

I'm not sure what your point is.  The DISPATCH WG chairs make= recommendations to the ADs based upon what they perceive as interest on th= e DISPATCH WG mailing list.   If you concerns about an explicit action= noted below, please be specific.  It's not clear to me whether your concerned about the decision for the discussion to move= to SIPREC or the general DISPATCH approach.  

Mary.


On Mon, Feb 10, 2014 at 1:42 PM, DRAGE, Keith (K= eith) <kei= th.drage@alcatel-lucent.com> wrote:
According to the charter:
 
The Dispatch working group is charter= ed to consider proposals for
new work in the RAI area and identify, or help create, an appropriate
venue for the work.
 
I would read this as a wo= rking group decision rather than a WG chairs decision.
 
Keith
 
 

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 10 February 2014 16:39
To: Hutton, Andrew
Cc: Gerben Stam; dispatch@ietf.org

Subject: Re: [dispatch] Lossless Recording in SIPREC

Yes, that is the appropriate action.  The ADs just me= t with the DISPATCH WG chairs in preparation for IETF-89. We discussed this= topic and agree that discussion should move to SIPREC WG mailing list. But= , it's important to note that this dispatchment in no way implies that the community agrees that work is needed. It's = up to the SIPREC WG to make that decision.

Regards,
Mary 
DISPATCH WG co-chair. 


On Mon, Feb 10, 2014 at 8:05 AM, Hutton, Andrew = <andrew.hut= ton@unify.com> wrote:
Hi Gerben,

Looking back at our off-list discussion I did actually say that you "s= hould start a discussion on the SIPREC list".

Sorry if there was confusion.

Andy

> -----Original Message-----
> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ram
> Mohan R (rmohanr)
> Sent: 06 February 2014 16:20
> To: Gerben Stam
> Cc: dispatch@ie= tf.org
> Subject: Re: [dispatch] Lossless Recording in SIPREC
>
> Hi,
>
> Please see inline
>
> -----Original Message-----
> From: Gerben Stam <Gerben.Stam@nice.com>
> Date: Thursday, 6 February 2014 8:40 pm
> To: Cisco Employee <rmohanr@cisco.com>
> Cc: "dispa= tch@ietf.org" <dispatch@ietf.org>
> Subject: RE: [dispatch] Lossless Recording in SIPREC
>
> >Hey Ram,
> >
> >I have had an off-line discussion with Andrew Hutton, chairman of = the
> >SIPREC group.
> >He suggested to post this on the IETF dispatch group as it is a go= od
> >topic to discuss in the team.
>
> Ok. I was not aware of this.
>
> >
> >What would I need to do to bend this to SIPREC WG instead of Dispa= tch?
> >
> >Regards,
> >
> >Gerben
> >
> >-----Original Message-----
> >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com]
> >Sent: donderdag 6 februari 2014 15:45
> >To: Gerben Stam
> >Cc: dispatc= h@ietf.org
> >Subject: Re: [dispatch] Lossless Recording in SIPREC
> >
> >Hi,
> >
> >Is there a reason why you want to have this discussion in dispatch= and
> >not in SIPREC WG which is meant to discuss the issues around SIP > >recording ?
> >If you don=B9t have any specific reason to do it here you may want= to
> start
> >this discussion in SIPREC WG.
> >
> >I do have some comments on this topic but I think SIPREC WG is the=
> right
> >place to have those discussions.
> >
> >
> >Regards,
> >Ram
> >
> >From:  Gerben Stam <Gerben.Stam@nice.com>
> >Date:  Thursday, 6 February 2014 3:58 pm
> >To:  Gerben Stam <Gerben.Stam@nice.com>
> >Cc:  "dispatch@ietf.org" <dispatch@ietf.org>
> >Subject:  [dispatch] Lossless Recording in SIPREC
> >
> >
> >Dear DISPATCH group,
> >
> >SIPREC is a great initiative to standardize the interface for
> capturing
> >Communication Sessions.
> >Session Recording is becoming more and more critical due to Compli= ance
> >and regulatory changes over the last years.
> >
> >The compliance market is requesting more than capture only these d= ays
> >Confirmation is needed to acknowledge the entire Communication Ses= sion
> >was captured correctly.
> >RTCP Reports (rfc3611) will help to confirm complete handover of R= TP
> >content.
> >
> >
> >
> >New requirement is Œlossless=B9 Session Capturing.
>
> Why is this a new requirement ? RFC 6341 (SIPREC requirements) already=
> has
> a requirement for Lossless recording. See REQ 005.
>
>
> >Lossless indicating handover of content (RTP) is acknowledged by t= he
> >receiver AND in case of receiving issues, the sender will resend.<= br> > >Reasons for loss may be UDP packet loss or receiver failing(over) = and
> >temporary not able to accept content.
> >Current approach to address this Œlossless=B9 requirement is= using 2
> >independent parallel receivers.
>
> There may be other approaches well. For example an SRC may buffer for = a
> small duration to take care of the loss. Two parallel receivers still<= br> > does
> not guarantee that recording is loseless as you can have UDP packet > loss
> on both paths.
>
> >
> >This requires the sender to send 2 individual streams, in fact 2 > >independent SIPREC sessions.
> >
> >Not sure if this is covered currently as supported SIPREC deployme= nt.
>
>
> Current SIPREC does not have any such constraints. Depending on your > implementation model you can have the same CS recorded by multiple SRC=
> or
> have same SRC do multiple recordings of same CS.
>
> Regards,
> Ram
>
> > We do see implementations based on SIPREC supporting it.
> >Alternative is quick failover at receiver in case of failure but a= s
> >sender will send only once, this may lead to loss during failover.=
> >
> >I am not aware of any rfc covering lossless content handover, but<= br> > there
> >may be standards covering this already.
> >
> >
> >Looking forward to discussion on the mailing list. I may be at the=
> London
> >event.
> >
> >Regards,
> >
> >Gerben Stam,
> >NICE Systems
> >
> >
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



--20cf303b3c930042ae04f21422e4-- From charles.newyork@gmail.com Mon Feb 10 18:36:17 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E32E1A074A for ; Mon, 10 Feb 2014 18:36:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HPts2wCqYUW for ; Mon, 10 Feb 2014 18:36:15 -0800 (PST) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 960821A073E for ; Mon, 10 Feb 2014 18:36:15 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id wo20so8215082obc.38 for ; Mon, 10 Feb 2014 18:36:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=ZmtHwq4TPdc5TqAWWshwXIbsTjZHaZ9cWPpWZRCJcxY=; b=gjn6DiOXQDY0s+qOI9D8ldskFGAs8OEfe+brGEC7X/IP14FzA9GjCvetNgg7BSgYxc twGr58f0esRpaAfYiNa8EMD18NO17fTqnQTYJW8wG6rhsmU5rbsz/DPfysUc3cAjX/mB /41ZhDvkYxmDTP5MP7A2x0nZo6zQSjvI0h6ePmCaHJP8oxXCRS4ydw6xvOzWibq2V6A2 zBwiq6elT7HPz5lMu6wbXju593Me1cHljaLEZEJtX2O90e+FieVK3coMX7maCDyDZIdJ dB0fecYOKnOK8ojmPQkIp2/q/6oNRQm/4fDJbwVMKqQnH0c5BQxoM54DYg/nJ8V4yPYw Cp5Q== X-Received: by 10.60.45.206 with SMTP id p14mr29949729oem.21.1392086175030; Mon, 10 Feb 2014 18:36:15 -0800 (PST) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.55.106 with HTTP; Mon, 10 Feb 2014 18:35:54 -0800 (PST) From: Charles Shen Date: Mon, 10 Feb 2014 21:35:54 -0500 X-Google-Sender-Auth: _y-TysXcTJFWxx6RP-uWMSykvXA Message-ID: To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=001a11c2019af5a24804f218510c Subject: Re: [dispatch] draft-shen-soc-avalanche-restart-overload X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 02:36:17 -0000 --001a11c2019af5a24804f218510c Content-Type: text/plain; charset=UTF-8 Dear all: As advised by Richard Barnes, I am writing to seek opinion from you about this draft: http://datatracker.ietf.org/doc/draft-shen-soc-avalanche-restart-overload/ A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart Overload Control Abstract: When a large number of clients register with a SIP registrar server at approximately the same time, the server may become overloaded. Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests may have similar effects. Such request avalanches can occur, for example, after a power failure and recovery in a metropolitan area. This document describes how to avoid such overload situations. Under this mechanism, a server estimates an avalanche restart backoff interval during its normal operation and conveys this interval to its clients through a new Restart-Timer header in normal response messages. Once an avalanche restart actually occurs, the clients perform backoff based on the previously received Restart-Timer header value before sending out the first request attempt. Thus, the mechanism spreads all the initial client requests and prevents them from overloading the server. The draft has been presented and discussed in IETF meetings since 2010, and generated interest among the community: https://encrypted.google.com/search?as_q=draft-shen-soc-avalanche-restart-overload&as_sitesearch=www.ietf.org%2Fmail-archive%2Fweb%2F I am looking for your kind opinion on what should be the appropriate next step for this document: -- Should this draft be dispatched to SOC (and their charter amended)? -- Should this draft be processed as AD-sponsored? -- Should this draft be killed (if it is harmful)? Thank you very much. Charles --001a11c2019af5a24804f218510c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all:=C2=A0

As advised by Richard Barnes, I am writ= ing to seek opinion from you about this draft:

A Mechan= ism for Session Initiation Protocol (SIP) Avalanche Restart Overload Contro= l

Abstract:
=C2=A0 =C2=A0When a large n= umber of clients register with a SIP registrar server
=C2=A0= =C2=A0at approximately the same time, the server may become overloaded.
=C2=A0 =C2=A0Near-simultaneous floods of SIP SUBSCRIBE and PUBLI= SH requests may
=C2=A0= =C2=A0have similar effects. =C2=A0Such request avalanches can occur, for
=C2=A0 =C2=A0example, after a power failure and recovery in a m= etropolitan area.
=C2=A0= =C2=A0This document describes how to avoid such overload situations. =C2= =A0Under
=C2=A0 =C2=A0this mechanism, a server estimates an av= alanche restart backoff
=C2=A0= =C2=A0interval during its normal operation and conveys this interval to it= s
=C2=A0 =C2=A0clients through a new Restart-Timer header in n= ormal response
=C2=A0= =C2=A0messages. =C2=A0Once an avalanche restart actually occurs, the clien= ts
=C2=A0 =C2=A0perform backoff based on the previously receiv= ed Restart-Timer header
=C2=A0= =C2=A0value before sending out the first request attempt. =C2=A0Thus, the<= /span>
=C2=A0 =C2=A0mechanism spreads all the initial client requests= and prevents them
=C2=A0= =C2=A0from overloading the server.

=
The dr= aft has been presented and discussed in IETF meetings since 2010, and gener= ated interest among the community:


I am looking for your kind opinion on what should= be the appropriate next step for this document:

-- Sho= uld this draft be dispatched to SOC (and their charter amended)?
-- Should this draft = be processed as AD-sponsored?
-- Should this d= raft be killed (if it is harmful)?

Thank you very much.

Charles


=

--001a11c2019af5a24804f218510c-- From andrew.hutton@unify.com Tue Feb 11 00:37:47 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF61B1A08F5 for ; Tue, 11 Feb 2014 00:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw_Cyrbi_Tn9 for ; Tue, 11 Feb 2014 00:37:46 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id E40C41A0690 for ; Tue, 11 Feb 2014 00:37:45 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id E754E23F0527; Tue, 11 Feb 2014 09:37:44 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.1.100]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0174.001; Tue, 11 Feb 2014 09:37:44 +0100 From: "Hutton, Andrew" To: "Dale R. Worley" , "DRAGE, Keith (Keith)" Thread-Topic: [dispatch] Lossless Recording in SIPREC Thread-Index: AQHPI1dDJyXBrcc2c0ma7EaQoC0IX5quiwsggAAamICAADNBAIAAL4FBgAC5HpA= Date: Tue, 11 Feb 2014 08:37:43 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF17CEF982@MCHP04MSX.global-ad.net> References: <4BEAD79F6904AC4FB1917EBA8006628905C0685D52@SOUEXC01.eu.nice.com> <9F33F40F6F2CD847824537F3C4E37DDF17CEDF53@MCHP04MSX.global-ad.net> <949EF20990823C4C85C18D59AA11AD8B12F844@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402102131.s1ALV1we4694874@shell01.TheWorld.com> In-Reply-To: <201402102131.s1ALV1we4694874@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Gerben.Stam@nice.com" , "dispatch@ietf.org" Subject: Re: [dispatch] Lossless Recording in SIPREC X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 08:37:48 -0000 Hi, As SIPREC co-chair I advised Gerben to discuss this topic on the SIPREC mai= ling list so that the SIPREC WG could assess whether it was in scope of SIP= REC and if so whether the WG would want to work on it. It was simply a mis= take that the mail went to dispatch in the first place. Of course if it turned out that it is not in the scope of SIPREC then we wo= uld ask for it to be taken to DISPATCH. I don't see there is any issue here. Regards Andy > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: 10 February 2014 21:31 > To: DRAGE, Keith (Keith) > Cc: mary.ietf.barnes@gmail.com; Hutton, Andrew; Gerben.Stam@nice.com; > dispatch@ietf.org > Subject: Re: [dispatch] Lossless Recording in SIPREC >=20 > > From: "DRAGE, Keith (Keith)" >=20 > > According to the [Dispatch] charter: > > > > The Dispatch working group is chartered to consider proposals for > > new work in the RAI area and identify, or help create, an appropriate > > venue for the work. > > > > I would read this as a working group decision rather than a WG chairs > decision. >=20 > It seems to me that "lossless recording" is well within the defined > responsibilities (charter) of Siprec. Siprec may decide that they > ultimately need mechanisms that can only be defined by another WG, > though... >=20 > Dale From thp@westhawk.co.uk Tue Feb 11 11:03:32 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740A61A06F1 for ; Tue, 11 Feb 2014 11:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIiJ-NdEn1e1 for ; Tue, 11 Feb 2014 11:03:29 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by ietfa.amsl.com (Postfix) with ESMTP id 83AF71A06F0 for ; Tue, 11 Feb 2014 11:03:27 -0800 (PST) Received: (qmail 34769 invoked from network); 11 Feb 2014 19:03:26 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 14789 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 11 Feb 2014 19:03:26 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id BD49818A03B0; Tue, 11 Feb 2014 19:03:25 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 7168518A02E5; Tue, 11 Feb 2014 19:03:25 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_C0BB1696-7784-4372-AED9-686F0B8C5E04" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton new In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Tue, 11 Feb 2014 19:03:20 +0000 Message-Id: References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 19:03:32 -0000 --Apple-Mail=_C0BB1696-7784-4372-AED9-686F0B8C5E04 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here is an interesting presentation by Kurtis that will give you some = feel for what these systems do: = https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/h= eimurl It isn't directly related to the standardisation effort but is a great = background info. Tim.= --Apple-Mail=_C0BB1696-7784-4372-AED9-686F0B8C5E04 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Here is an interesting presentation by Kurtis that will give you some feel for what these systems do:


It isn't directly related to the standardisation effort but is a great background info.

Tim.
--Apple-Mail=_C0BB1696-7784-4372-AED9-686F0B8C5E04-- From michael.hammer@yaanatech.com Tue Feb 11 11:55:28 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24EC61A0591 for ; Tue, 11 Feb 2014 11:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FET615Bz4b1Y for ; Tue, 11 Feb 2014 11:55:26 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id EF3E51A0700 for ; Tue, 11 Feb 2014 11:55:25 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Tue, 11 Feb 2014 11:55:25 -0800 From: Michael Hammer To: "thp@westhawk.co.uk" , "keith.drage@alcatel-lucent.com" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAC9HICAAALFAIAAAFCA//96B5CAAI2tgIAALnMAgAZ4WICAAOAQAIAACMEAgAAEaACAAAXeAIAAJYeAgAFsZwD//4Ij8A== Date: Tue, 11 Feb 2014 19:55:24 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF28361@sc9-ex2k10mb1.corp.yaanatech.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.92] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_036B_01CF2739.4ADE1040" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 19:55:28 -0000 ------=_NextPart_000_036B_01CF2739.4ADE1040 Content-Type: multipart/alternative; boundary="----=_NextPart_001_036C_01CF2739.4ADE1040" ------=_NextPart_001_036C_01CF2739.4ADE1040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is interesting and useful research. But, I would note that there are other power solutions for the BS. But, I have to ask the question, why is this directed toward the IETF and not 3GPP or GSMA? Looking forward to seeing the IETF protocol nexus. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Tim Panton new Sent: Tuesday, February 11, 2014 2:03 PM To: DRAGE, Keith (Keith) Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS Here is an interesting presentation by Kurtis that will give you some feel for what these systems do: https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/hei murl It isn't directly related to the standardisation effort but is a great background info. Tim. ------=_NextPart_001_036C_01CF2739.4ADE1040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is interesting and useful research.

But, I would note that there are other power solutions for the = BS.

 

But, I have to ask the question,

why is this directed toward the IETF and not 3GPP or = GSMA?

 

Looking forward to seeing the IETF protocol = nexus.

 

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com

Mobile: +1 408-202-9291

500 Yosemite Drive Suite = 120

Milpitas, CA 95035 = USA

 

From:= = dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Tim = Panton new
Sent: Tuesday, February 11, 2014 2:03 = PM
To: DRAGE, Keith (Keith)
Cc: = dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS = with OpenBTS

 

Here is an = interesting presentation by Kurtis that will give you some feel for what = these systems do:

 

 

It isn't directly related to the standardisation = effort but is a great background info.

 

Tim.

------=_NextPart_001_036C_01CF2739.4ADE1040-- ------=_NextPart_000_036B_01CF2739.4ADE1040 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIx MTE5NTUyM1owIwYJKoZIhvcNAQkEMRYEFAYbZemUYcWN9hNxDI21K8dlQht7MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAXWUpVoe5+FI/aRUnzAn5rLQJFhjBjUy6zi3o2Ah1 4K5fY4MIdUxyO93dK1XStAzvAtmMl6hQJ71TGB/XCMtoaeHXzwOTktlLLqPUaq2GqLzLqI6P//Ue Yp+XUo2kdr+kkavQI5JCl1dPY4Ad5f6kXLFuXreePo1sASgdR66MGkCIWsleh+camNEzNByuKtcm kCxfkOaXLmcQUcXXYf+W8tQT8k3Mtf+Vv2y3iksnfiKpM3kYeerz/u7cPqXl9vFxhpGtUaEL4Fl0 j3m04r5KbAXCNWWwsB2CahtWL+c8SsP+0743TXy8PhYof1y9c+woBmLwwe9Y6rLJXSiOVzEzrgAA AAAAAA== ------=_NextPart_000_036B_01CF2739.4ADE1040-- From munncha@gmail.com Tue Feb 11 13:31:57 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35841A076D for ; Tue, 11 Feb 2014 13:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6bTLGjLH86U9 for ; Tue, 11 Feb 2014 13:31:54 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 495811A075B for ; Tue, 11 Feb 2014 13:31:54 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id c11so6409419lbj.17 for ; Tue, 11 Feb 2014 13:31:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=gNktLpo8FSMm13MkohDZ7A4eeGi5U8fJNCXS6QO5cyk=; b=AKctlzIsgfw3gDJNGmTccev9+GGKetOEdrOXjFddXeLkhUjDCH0+3PIr8QfWptCD5p xOqr5WL86v/M/KJ0IO6i/AnRhEgBDH2jSsNawqfbaTZqrdaTNLrJh0qWqdJ7oUR3YAXi m4PFWYfN7calGMSt6MPQN/ERQcH2gnjkHCw0XPG6JTvEKTUDfH1Tsd2llWft7Vdgha+/ 9PttLwNmopRB9W8OXEGHPEASrcXsAp7ZXcvYwnk3OzlCZ5jvYR7VmMdBD3icB8ogRC7t NXDVQc7YLISA49X81ugyksDbB6V77C7H+o/E+qZP98sVy773O4AOpaGPzTvEQnyLsPIj SKPQ== X-Received: by 10.152.27.193 with SMTP id v1mr28470292lag.4.1392154313012; Tue, 11 Feb 2014 13:31:53 -0800 (PST) MIME-Version: 1.0 Sender: munncha@gmail.com Received: by 10.112.42.170 with HTTP; Tue, 11 Feb 2014 13:31:12 -0800 (PST) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Kurtis Heimerl Date: Wed, 12 Feb 2014 06:31:12 +0900 X-Google-Sender-Auth: 2kdUeUJNvO-yYipNBeGIQUyHdLU Message-ID: To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=089e0158c4864cbb7d04f2282fc8 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2014 21:31:57 -0000 --089e0158c4864cbb7d04f2282fc8 Content-Type: text/plain; charset=ISO-8859-1 Comments in line: On Tue, Feb 11, 2014 at 6:19 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > I'd contend that there is not enough information in the diagram to > identify either point of view. > > This is not a "point of view". This is how the system is architected, as shown in the diagram with the boxes under the OpenBTS box. > What I am beginning to understand is that the SIP registrar is not > colocated with the BTS, and therefore the subscriber records for the GERAN > usage are physically seaparate and distinct from those of the SIP usage. > Therefore to add a subscriber to the system, tou have to update the HLR > records in the BTS (and every BTS that is serving that user) and the > records at the SIP registrar / location server. > > They can be physically separate, though they need not be. In most PBX setups the subscriber records are read by the HLR (for authentication) and PBX (for routing) from the same database. Again, this database and HLR serves multiple BTSs, so each BTS does not need to be updated. > Is there a requirement to correlate accounting records between the two > usages? > For the PBX and HLR, probably. It's definitely good practice. > > Mobility management is not I assume converted to SIP. The original > description said they would use REFER to do such functions. It has not been > clear whether that is supported by a centralised function (at or distinct > from the registrar / location server) or whether this is performed UE to > UE. This needs to be clarified. I would very much suspect this is going to > need the definition of some new protocol to indicate support of various > capabilities (This is a special REFER because it comes from my other > registration over a different proxy, and not any old REFER). > In OpenBTS, the BTS itself acts as the UE within the network, as it bridges between Um and SIP. For Handover, the current solution has the UEs forward packets between BTSs when a phone is roaming. I believe it's not possible to do through the PBX, though I can't remember why. > > regards > > Keith > > ------------------------------ > *From:* munncha@gmail.com [mailto:munncha@gmail.com] *On Behalf Of *Kurtis > Heimerl > *Sent:* 10 February 2014 19:05 > *To:* DRAGE, Keith (Keith) > *Cc:* Tim Panton new; dispatch@ietf.org > > *Subject:* Re: [dispatch] SIP and GSM/UMTS with OpenBTS > > You're misreading the diagram. As can be seen, multiple OpenBTS > instances can talk to a single instance of the SAS. This allows for > centralized charging and accounting for multiple BTS instances wherever the > SAS is hosted. > > As far as the 3GPP mobility management protocols (if I know which ones > you are speaking of), those are converted to SIP (as is everything) and > sent to the SAS. So I would say we are using these protocols between BTSs, > especially for handover. > > > On Tue, Feb 11, 2014 at 3:43 AM, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote: > >> I am not assuming a specific solution - what we are all trying to find >> out is how much of 3GPP GERAN is actually being used, and what identities >> relate to what. >> >> So you will have a UICC - because it is a 3GPP GERAN access network, but >> will not have any roaming that relates to the UICC, or the identities on >> that UICC. >> >> But as far as I can see from the architecture given, the service is >> limited to a single BTS. That means that (for the solution you identify >> below) an operator with multiple BTSs will assign their users to a single >> BTS and the collation of charging/accounting will have to be from each >> individual BTS, back to some central entity (not shown). >> >> You will not be running the 3GPP mobility management protocols between >> BTS. >> >> Keith Drage >> >> >> >> > -----Original Message----- >> > From: Tim Panton new [mailto:thp@westhawk.co.uk] >> > Sent: 10 February 2014 18:28 >> > To: DRAGE, Keith (Keith) >> > Cc: Jim Forster; Mary Barnes; dispatch@ietf.org >> > Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS >> > >> > >> > On 10 Feb 2014, at 17:56, DRAGE, Keith (Keith) >> > wrote: >> > >> > > If I follow this diagram correctly, you claim to have >> > collapsed the HLR into your BTS. Your BTS apparently have no >> > communication shown with each other. This means you each >> > subscriber is limited to a single BTS with no roaming between them. >> > >> > I think you are assuming a specific solution to a specific problem. >> > Many ITSPs allow SIP registrations to a DID/account to come >> > from dynamic IPs. So the necessary 'communication' can be >> > implemented via the ITSP's normal functions. So when a user >> > moves from the BTS in village A to the BTS in village B >> > their DID travels with them. >> > >> > Sure you wouldn't get the ability for an arbitrary GSM SIM to >> > roam into the network and be billed to their home network. >> > >> > But realistically that sort of roaming isn't really a >> > technical problem, it is predominantly a legal/commercial one. >> > >> > Tim. >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > --089e0158c4864cbb7d04f2282fc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Comments in line:


On Tue, Feb 11, 2014 at 6:19 AM, DRAGE, Keith (Keith) = <keith.drage@alcatel-lucent.com> wrote:
I'd contend that there is not enough information in the diagram to id= entify either point of view.
=A0

This is not= a "point of view". This is how the system is architected, as sho= wn in the diagram with the boxes under the OpenBTS box.=A0
=A0
What I am beginning to understand is that the SIP registrar is not coloca= ted with the BTS, and therefore the subscriber records for the GERAN usage = are physically seaparate and distinct from those of the SIP usage. Therefore t= o add a subscriber to the system, tou have to update the HLR records in the= BTS (and every BTS that is serving that user) and the records at the SIP r= egistrar / location server.
=A0

They can be= physically separate, though they need not be. In most PBX setups the subsc= riber records are read by the HLR (for authentication) and PBX (for routing= ) from the same database. Again, this database and HLR serves multiple BTSs= , so each BTS does not need to be updated.=A0
=A0
Is there a requirement to correlate accounting records between the two us= ages?

For the PBX= and HLR, probably. It's definitely good practice.=A0
=A0
=A0
Mobility management is not I assume converted to SIP. The original descri= ption said they would use REFER to do such functions. It has not been clear= whether that is supported by a centralised function (at or distinct from the regis= trar / location server) or whether this is performed UE to UE. This needs t= o be clarified. I would very much suspect this is going to need the definit= ion of some new protocol to indicate support of various capabilities (This is a special REFER because it comes = from my other registration over a different proxy, and not any old REFER).<= /font>


In OpenBTS, the BTS itself acts as the UE within the network, as it bridges= between Um and SIP. For Handover, the current solution has the UEs forward= packets between BTSs when a phone is roaming. I believe it's not possi= ble to do through the PBX, though I can't remember why.=A0
=A0
=A0
regards
=A0
Keith

From: munncha@gmail.com [mailto:munncha@gmail.com] On Behalf Of Kurtis Heimerl
Sent: 10 February 2014 19:05
To: DRAGE, Keith (Keith)
Cc: Tim Panton new; dispatch@ietf.org

Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

You're misreading the diagram. As can be seen, multipl= e OpenBTS instances can talk to a single instance of the SAS. This allows f= or centralized charging and accounting for multiple BTS instances wherever = the SAS is hosted.

As far as the 3GPP mobility management protocols (if I know which ones= you are speaking of), those are converted to SIP (as is everything) and se= nt to the SAS. So I would say we are using these protocols between BTSs, es= pecially for handover.=A0


On Tue, Feb 11, 2014 at 3:43 AM, DRAGE, Keith (K= eith) <kei= th.drage@alcatel-lucent.com> wrote:
I am not assuming a specific solution - what we are all trying to find out = is how much of 3GPP GERAN is actually being used, and what identities relat= e to what.

So you will have a UICC - because it is a 3GPP GERAN access network, but wi= ll not have any roaming that relates to the UICC, or the identities on that= UICC.

But as far as I can see from the architecture given, the service is limited= to a single BTS. That means that (for the solution you identify below) an = operator with multiple BTSs will assign their users to a single BTS and the= collation of charging/accounting will have to be from each individual BTS, back to some central entity (not= shown).

You will not be running the 3GPP mobility management protocols between BTS.=

Keith Drage



> -----Original Message-----
> From: Tim Panton new [mailto:thp@westhawk.co.uk]
> Sent: 10 February 2014 18:28
> To: DRAGE, Keith (Keith)
> Cc: Jim Forster; Mary Barnes; dispatch@ietf.org
> Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS
>
>
> On 10 Feb 2014, at 17:56, DRAGE, Keith (Keith)
> <keith.drage@alcatel-lucent.com> wrote:
>
> > If I follow this diagram correctly, you claim to have
> collapsed the HLR into your BTS. Your BTS apparently have no
> communication shown with each other. This means you each
> subscriber is limited to a single BTS with no roaming between them. >
> I think you are assuming a specific solution to a specific problem. > Many ITSPs allow SIP =A0registrations to a DID/account to come
> from dynamic IPs. So the necessary 'communication' can be
> implemented via the ITSP's normal functions. So when a user
> moves from the BTS in village A to the BTS =A0in village B
> their DID travels with them.
>
> Sure you wouldn't get the ability for an arbitrary GSM SIM to
> roam into the network and be billed to their home network.
>
> But realistically that sort of roaming isn't really a
> technical problem, it is predominantly a legal/commercial one.
>
> Tim.
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--089e0158c4864cbb7d04f2282fc8-- From victor.pascual.avila@gmail.com Tue Feb 11 23:44:47 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642E61A0878 for ; Tue, 11 Feb 2014 23:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luCPgbh5m3kY for ; Tue, 11 Feb 2014 23:44:44 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 354DB1A0874 for ; Tue, 11 Feb 2014 23:44:44 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hm4so6332107wib.8 for ; Tue, 11 Feb 2014 23:44:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=loSoQZLhMUsK3sDvIsrjezEf/k3RhSwmUdQTRCctKUc=; b=rmAtG66MFDP0Q3oKYnZHCRmISESxZ+zmxFJ2gTyaGXFWA1x32hxS9lfb2ldCS2zfql GWEoI1x/TRHAYbkH0eg+VZNuLnNQziGA5l6tdaD0BX0k6/E+B+QJYIYEAvnej/xO96N0 hmuKv2gq08Ju5Nx9mVjpWP9RjtDdEmqrPywxY4dGfjyQuOEYzHro9hHp+F/fgK+h2U02 NC2IZdzoXFe7LGa2qbs5hrj8S+4nfIAoIiLqt18vRUOQOgI12HsiFCdXtQv/VVOtUcTN bnbKkeai8+ReARh0BFI87Qc4MQqU9uzGkvhdm8HBXWuOvayc0fnV9k1+e1MrF/B7fQ3z qlSw== X-Received: by 10.180.73.196 with SMTP id n4mr969092wiv.24.1392191082887; Tue, 11 Feb 2014 23:44:42 -0800 (PST) Received: from [100.68.223.196] (87.212-142-204.dynamic.clientes.euskaltel.es. [212.142.204.87]) by mx.google.com with ESMTPSA id k10sm49976277wjf.11.2014.02.11.23.44.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 23:44:40 -0800 (PST) References: From: Victor Pascual Content-Type: multipart/alternative; boundary=Apple-Mail-C7591CC1-775C-4FAF-A032-EA463D73ABC3 X-Mailer: iPad Mail (9B206) Message-Id: <98FCADC6-5874-42D5-BBCC-C03F3EE3AAF5@gmail.com> Date: Wed, 12 Feb 2014 08:44:30 +0100 To: dispatch@ietf.org Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: [dispatch] Fwd: [bfcpbis] Fwd: I-D Action: draft-pascual-bfcpbis-bfcp-websocket-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 07:44:48 -0000 --Apple-Mail-C7591CC1-775C-4FAF-A032-EA463D73ABC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii If you have comments, please provide them via bfcpbis Thanks, -Victor Begin forwarded message: > From: "Charles Eckel (eckelcu)" > Date: February 10, 2014 8:28:25 PM GMT+01:00 > To: Victor Pascual Avila , "bfcpbis@ietf.o= rg" > Subject: Re: [bfcpbis] Fwd: I-D Action: draft-pascual-bfcpbis-bfcp-websock= et-00.txt >=20 > For those of you interested in this draft, which was previously discussed > within DISPATCH, please provide your comments asap. The chairs will use > this as input when determining whether to place this draft on the agenda > and how much time to allocate to it. >=20 > Cheers, > Charles=20 >=20 > On 2/9/14 1:40 PM, "Victor Pascual Avila" = > wrote: >=20 >> Hi all, >>=20 >> We have submitted a new Internet draft to describe the WebSocket >> Protocol as a Transport for the Binary Floor Control Protocol (BFCP). >> We are looking forward to your review comments. >>=20 >> http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00 >>=20 >> Thank you, >> -Victor >>=20 >> ---------- Forwarded message ---------- >> From: >> Date: Sun, Feb 9, 2014 at 9:50 PM >> Subject: I-D Action: draft-pascual-bfcpbis-bfcp-websocket-00.txt >> To: i-d-announce@ietf.org >>=20 >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >>=20 >>=20 >> Title : The WebSocket Protocol as a Transport for >> the Binary Floor Control Protocol (BFCP) >> Authors : Victor Pascual >> Anton Roman >> Stephane Cazeaux >> Gonzalo Salgueiro >> Sergio Garcia Murillo >> Filename : draft-pascual-bfcpbis-bfcp-websocket-00.txt >> Pages : 11 >> Date : 2014-02-09 >>=20 >> Abstract: >> The WebSocket protocol enables two-way realtime communication between >> clients and servers. This document specifies a new WebSocket sub- >> protocol as a reliable transport mechanism between Binary Floor >> Control Protocol (BFCP) entities to enable usage of BFCP in new >> scenarios. This document normatively updates [I-D.draft-ietf- >> bfcpbis-rfc4582bis] and [I-D.draft-ietf-bfcpbis-rfc4583bis] >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-pascual-bfcpbis-bfcp-websocket/ >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >=20 --Apple-Mail-C7591CC1-775C-4FAF-A032-EA463D73ABC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
If you have comments, plea= se provide them via bfcpbis

Thanks,
-Vict= or

Begin forwarded message:

From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
Date: February 10, 2014 8:= 28:25 PM GMT+01:00
To: Victor Pascual Avila <victor.pascual.avila@gmail.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>
Subject: Re: [bfcpbi= s] Fwd: I-D Action: draft-pascual-bfcpbis-bfcp-websocket-00.txt

<= /div>
For those o= f you interested in this draft, which was previously discussed
within DISPATCH, please provide your comments asap. The chairs will use
this as input when determining whether to place this draft on= the agenda
and how much time to allocate to it.
<= span>
Cheers,
Charles

On 2/9/14 1:40 PM, "Victor Pascual Avila" <victor.pascual.avila@gmail.com>
wrote:

Hi all,

<= /blockquote>
We have submitted a new Internet= draft to describe the WebSocket
Protocol as a Transport for the Binary Floor Control Protocol (B= FCP).
We are looking f= orward to your review comments.

http://= tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00

Thank you,
-Victor
=
---------- Forwarded= message ----------
From:=  <internet-drafts@ietf.= org>
Date: Sun= , Feb 9, 2014 at 9:50 PM
Subject: I-D Action: draft-pascual-bfcpbis-bfcp-websocket-00.txt<= br>
To: i-d-announce@ietf.org



A New Internet-Draft is available from= the on-line Internet-Drafts
directories.
=

      Tit= le           : The WebSock= et Protocol as a Transport for
the Binary Floor Control Protocol (BFCP)
      Authors &= nbsp;       : Victor Pascual
     &n= bsp;            =       Anton Roman
        =             &nbs= p;   Stephane Cazeaux
          = ;            &nb= sp; Gonzalo Salgueiro
=            &nb= sp;            S= ergio Garcia Murillo
=       Filename      =   : draft-pascual-bfcpbis-bfcp-websocket-00.txt
      Pa= ges           : 11<= br>
    &nb= sp; Date           &n= bsp;: 2014-02-09

Abstract:
 The WebSocket protocol enabl= es two-way realtime communication between
 clients and servers.  This document specifi= es a new WebSocket sub-
 protocol as a reliable transport mechanism between Binary Floor
 Control Protocol= (BFCP) entities to enable usage of BFCP in new
 scenarios.  This document normatively= updates [I-D.draft-ietf-
<= span>  bfcpbis-rfc4582bis] and [I-D.draft-ietf-bfcpbis-rfc4583bis]

<= blockquote type=3D"cite">
The IETF datatracker status page for this draft is:
https://datatracker.ietf.or= g/doc/draft-pascual-bfcpbis-bfcp-websocket/

There's also a htmlized version available at:
=
http://tools.ietf.org/html/draft-pascual-= bfcpbis-bfcp-websocket-00


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

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

_= ______________________________________________
I-D-Announce mailing list
<= blockquote type=3D"cite">I-D-= Announce@ietf.org
https://www.= ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_____________________________________= __________
bfcpbis ma= iling list
bfcpbis@ietf.org
https://www.ietf.org/mailman/listinfo/bfcpbis

= --Apple-Mail-C7591CC1-775C-4FAF-A032-EA463D73ABC3-- From worley@shell01.TheWorld.com Wed Feb 12 08:03:59 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF541A09E5 for ; Wed, 12 Feb 2014 08:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-fS5iE2emED for ; Wed, 12 Feb 2014 08:03:57 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id C2A7D1A09CF for ; Wed, 12 Feb 2014 08:03:56 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s1CG258x024746; Wed, 12 Feb 2014 11:02:07 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s1CG1tgE4841537; Wed, 12 Feb 2014 11:01:55 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s1CG1q0W4835781; Wed, 12 Feb 2014 11:01:52 -0500 (EST) Date: Wed, 12 Feb 2014 11:01:52 -0500 (EST) Message-Id: <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Tim Panton new In-reply-to: (thp@westhawk.co.uk) References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 16:04:00 -0000 > From: Tim Panton new > Here is an interesting presentation by Kurtis that will give you > some feel for what these systems do: > > https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/heimurl Though he's incorrect that the first cellular network was in 1991, it was in 1979. 1991 is the first GSM cellular network. > It isn't directly related to the standardisation effort but is a > great background info. It's interesting work, but I don't see its connection with SIP at all. My assumption is that you're asking, "How do we mate the GSM over-the-air protocol with SIP for backhaul?", that is, how do we disconnect the cellular system from IMS and all that. But if your goal is to deploy base stations commercially, you're going to need the call accounting infrastructure of IMS. Dale From thp@westhawk.co.uk Wed Feb 12 08:45:50 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29521A0459 for ; Wed, 12 Feb 2014 08:45:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWJkW0Fa_Cgk for ; Wed, 12 Feb 2014 08:45:48 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by ietfa.amsl.com (Postfix) with ESMTP id D95A81A02A7 for ; Wed, 12 Feb 2014 08:45:47 -0800 (PST) Received: (qmail 72940 invoked from network); 12 Feb 2014 16:45:46 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 12507 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 12 Feb 2014 16:45:46 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 00D3F18A0189; Wed, 12 Feb 2014 16:45:46 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id BD97C18A00F6; Wed, 12 Feb 2014 16:45:45 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton new In-Reply-To: <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> Date: Wed, 12 Feb 2014 16:45:34 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0D0418E0-A6D0-43BC-A5DC-1D8AD1D93E75@westhawk.co.uk> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> To: "Dale R. Worley" X-Mailer: Apple Mail (2.1827) Cc: dispatch@ietf.org Subject: Re: [dispatch] [SPAM] Re: SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 16:45:51 -0000 On 12 Feb 2014, at 16:01, Dale R. Worley wrote: >> From: Tim Panton new >=20 >> Here is an interesting presentation by Kurtis that will give you >> some feel for what these systems do: >>=20 >> = https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/h= eimurl >=20 > Though he's incorrect that the first cellular network was in 1991, it > was in 1979. 1991 is the first GSM cellular network. >=20 >> It isn't directly related to the standardisation effort but is a >> great background info. >=20 > It's interesting work, but I don't see its connection with SIP at all. As I said it isn't related to the standardisation, but rather to give = some background to the usage. >=20 > My assumption is that you're asking, "How do we mate the GSM > over-the-air protocol with SIP for backhaul?", that is, how do we > disconnect the cellular system from IMS and all that. But if your > goal is to deploy base stations commercially, you're going to need the > call accounting infrastructure of IMS. That's assuming a currently popular billing model. If all your customers = were (for example) on an all-you-can-eat tariff then you might not need IMS. Likewise if you only = had 1000 customers, the standard IMS solution is overkill. If you don't need roaming, then you = may not want the full IMS stack. So to take Kurtis's example there might be significant value in a phone = service that allowed users to: 1) call within network (that's a potential 20 mile radius even for a = single cell) 2) make emergency calls 3) receive external calls 4) all bound to a specific sim 5) sms to the world - That could be associated with a small monthly fee to cover the = infrastructure costs.=20 Sure they'd like the full LTE experience - but (a - wifi probably does = that better (b - LTE is too expensive. The point is these systems don't attempt to replace existing services - = they are generally put into places and scenarios where the IMS 3gpp model doesn't work (for one = reason or another). This is evidenced by the fact that these places _aren't_ served yet. I'm hoping we'll standardise the SIP interface towards the ITSP, either = in the form of a set of recommendations and possibly a new header field or two. I'd also like see a standard (SIP? SCTP? SNMP?) interface between cells = to help with handoff etc. The point of standardisation is to allow many vendors to interoperate = and ITSPs to offer service, but not to restrict the use-case so much that it exactly replicates something we _know_ isn't practical for these = environments. Tim. >=20 > Dale From worley@shell01.TheWorld.com Wed Feb 12 13:12:06 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B51D1A0685 for ; Wed, 12 Feb 2014 13:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXhqLGcq2_YK for ; Wed, 12 Feb 2014 13:12:03 -0800 (PST) Received: from TheWorld.com (pcls6.std.com [192.74.137.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6646F1A0647 for ; Wed, 12 Feb 2014 13:12:02 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s1CLABJD017638; Wed, 12 Feb 2014 16:10:13 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s1CKtOi64867480; Wed, 12 Feb 2014 15:55:24 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s1CKtFC64823393; Wed, 12 Feb 2014 15:55:15 -0500 (EST) Date: Wed, 12 Feb 2014 15:55:15 -0500 (EST) Message-Id: <201402122055.s1CKtFC64823393@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Charles Shen In-reply-to: (charles@cs.columbia.edu) References: Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-shen-soc-avalanche-restart-overload X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2014 21:12:06 -0000 > From: Charles Shen > I am looking for your kind opinion on what should be the appropriate next > step for this document: > > -- Should this draft be dispatched to SOC (and their charter amended)? > -- Should this draft be processed as AD-sponsored? > -- Should this draft be killed (if it is harmful)? I do believe that this draft should be advanced, as this sort of registration storm causes a problem in practice, though I don't have any opinion on what would be the proper track for it. It would be interesting to know if there have been any large-scale implementations, and what the results have been in practice. In regard to the draft itself, I think a few tweaks would improve it. - Clarify that the Restart-Timer value is associated with the URI that is being registered (for REGISTER) or the URI/event that is being subscribed to (for SUBSCRIBE and PUBLISH). - You may want a more clever way of handling multiple Restart-Timer values received from different servers during a boot sequence that sends requests to several servers (which may be incompletely coordinated with each other). E.g., if the registration server has a Restart-Timer of 300 and the voicemail server also has a Restart-Timer of 300, it seems that the UA could safely wait rand(0:300) then register and subscribe. If the VM server has a zero restart timer, the UA probably wants to wait until the registration is done anyway before subscribing to VM. But if the VM server has a Restart-Timer of 600, there probably should be an additional delay between registration and subscribing. The trouble is that rand(0:300)+rand(0:300) doesn't have the same distribution as rand(0:600), so you may not want to say "Wait a random fraction of the difference between the two Restart-Timers." Perhaps a workable algorithm is "Choose a random real number uniformaly between zero and one. Each bootup operation may be executed no earlier than (the random number) * (the specified Restart-Timer for that operation) seconds after power-up." That causes each server to see the time-distribution of requests that it expects. - The text suggests that the Restart-Timer value expires when the registration expires. ("The validity duration of the Restart-Timer header is the same as that of the corresponding registration operation.") That doesn't work at all, because the power failure may exceed the length of all the registrations. The Restart-Timer value has to be saved until another value is received for that same target. - You may want to allow/require the UA to place an upper limit on the Restart-Timer value. At the least, Restart-Timer should not exceed the maximum registration/subscription duration the UA requests and the server provides. - I expect that you want to require that if a REGISTER response is received that does not contain Restart-Timer, then the saved Restart-Timer value is set to zero. That causes the expected behavior when a registrar that supports Restart-Timer is replaced with one that does not. Dale From ivo.sedlacek@ericsson.com Thu Feb 13 02:06:58 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7911A0155 for ; Thu, 13 Feb 2014 02:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YwBpTfSxMaPa for ; Thu, 13 Feb 2014 02:06:55 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5F61A016D for ; Thu, 13 Feb 2014 02:06:54 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-4e-52fc993c0d5a Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 19.ED.10875.C399CF25; Thu, 13 Feb 2014 11:06:52 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.164]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 11:06:52 +0100 From: Ivo Sedlacek To: Tim Panton new Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPKAwVozdeAICzrkKy3baFOj5a05qy64bA Date: Thu, 13 Feb 2014 10:06:51 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> In-Reply-To: <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610112662068ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvja7NzD9BBk0XDC2WTlrAarHu/TEW ByaPJUt+MnlcnLafKYApissmJTUnsyy1SN8ugSvj2eK3LAVnkirmT2tnaWB8HtLFyMkhIWAi cWnnSjYIW0ziwr31QDYXh5DAIUaJ2d/nsUM4Sxgl5vx6xw5SxSagJzFxyxFWEFtEQF1i5tKL TCA2s4C2xP/r6xhBbGEBU4mVU1ugaswkJk2bxdzFyAFkG0ns/WEPYrIIqEpMfx0HUsEr4Cux 9sVbqFXNXBLfL+8HO4hTwEHi14+LYCMZBWQlrv7pZYRYJS5x68l8JoijBSSW7DnPDGGLSrx8 /I8VwlaSWLH9ElR9vsSmuZ3sEMsEJU7OfMIygVF0FpJRs5CUzUJSBhHXkViw+xPbLKgvly18 zQxjnznwmAlZfAEj+ypG9tzEzJz0csNNjMCYOrjlt+4OxlPnRA4xSnOwKInzfnjrHCQkkJ5Y kpqdmlqQWhRfVJqTWnyIkYmDU6qBMf1azl7NgLcyBw7o7bQyqGza+SE8NWKl5J0JyZ6Cqw+f EDVfbVf3kF1X/ee/pWaLAnRFvNxNv7pF2qp+SWVt7xS4mNHprbPvit6eE7s/vXHgtpZfVLzb aXItz/dTC0z2l16YrNadXmnwvFbo83IHx4kn3hmvF0uXjJ/P71nQnHdo4YljOT/2KbEUZyQa ajEXFScCAEMOh7J3AgAA Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 10:06:59 -0000 --_000_39B5E4D390E9BD4890E2B3107900610112662068ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Tim and all, if I understood the proposal correctly, in comparison to 3GPP architecture = you propose: - UEs are unchanged - BTS - uses regular Um reference point towards UEs - has a new SIP based interface replacing ABis reference po= int - BSC, MSC, HSS, SM-SC, ... collapse into one functional entity "SAS/Asteri= sk/SMQueue". This new functional entity: - uses the new SIP based interface replacing ABis reference= point towards BTS - uses another SIP based interface towards remote networks Can you please clarify what's the intended business case where the proposed= solution is supposed to be superior over the existing 3GPP solution? E.g. can you please clarify whether you indent to specify a solution for: a) carriers with license to use the licensed GSM bands? b) individuals/corporates without license to use the licensed GSM bands? c) anyone else? The original mail suggested b) but then you referred to a) in your mail sta= ting "But more typically carriers with spectrum licenses are looking for an= economical way to get into rural areas." If a), such solution can be deployed anywhere where there are existing GSM = bands in use. However, it will likely require implementation of the full 3G= PP feature set which carriers offer today, including supporting regulator's= requirements, support of handovers, integration with other operator subsys= tems (e.g. billing, operation & maintenance subsystems, ...). Or do you bel= ieve that some existing requirements are unnecessary for deployments in car= rier networks? You seem to claim above that your proposal can be more economical than exis= ting solution. Given that new protocol would need to be defined and functio= nal entities newly developed and tested, I fail to see how this can be more= economical than deployment of existing products which are already develope= d, tested, mass produced and mass deployed. Can you provide some numbers su= pporting your view? https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/he= imurl just proposes new functionality to be added, unrelated to any potenti= al replacement of ABis reference point with SIP based interface. If b), then such solution can be deployed only in countries where there is = no license needed. You list Sweden as one with UK and Netherlands with ques= tion marks. Also Antarctica was mentioned. Can you please provide a reference to regulators' document enabling usage o= f GSM bands without license in each of those countries? How will interferences be avoided if several individuals/corporates start u= sing the same GSM band in the same location, particularly if each starts us= ing power enabling "potential 20 mile radius even for a single cell"? Furthermore, even if all of Sweden, UK, Netherlands and Antarctica enable u= sage of GSM bands without license, this is still quite limited market. If t= he solution is limited only to those countries, even if the required featur= e set is smaller, there is little economies of scale. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer --_000_39B5E4D390E9BD4890E2B3107900610112662068ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Tim and all,     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           

 

if I understood the proposal correctly, in compar= ison to 3GPP architecture you propose:

- UEs are unchanged

- BTS

        &= nbsp;       - uses regular Um reference point= towards UEs

        &= nbsp;       - has a new SIP based interface r= eplacing ABis reference point

- BSC, MSC, HSS, SM-SC, ... collapse into one fun= ctional entity "SAS/Asterisk/SMQueue". This new functional entity= :

        &= nbsp;       - uses the new SIP based interfac= e replacing ABis reference point towards BTS

        &= nbsp;       - uses another SIP based interfac= e towards remote networks

 

Can you please clarify what's the intended busine= ss case where the proposed solution is supposed to be superior over the exi= sting 3GPP solution?

 

E.g. can you please clarify whether you indent to= specify a solution for:

a) carriers with license to use the licensed GSM = bands?

b) individuals/corporates without license to use = the licensed GSM bands?

c) anyone else?

 

The original mail suggested b) but then you refer= red to a) in your mail stating "But more typically carriers with spect= rum licenses are looking for an economical way to get into rural areas.&quo= t;

 

 

If a), such solution can be deployed anywhere whe= re there are existing GSM bands in use. However, it will likely require imp= lementation of the full 3GPP feature set which carriers offer today, includ= ing supporting regulator's requirements, support of handovers, integration with other operator subsystems (e.g. bil= ling, operation & maintenance subsystems, ...). Or do you believe that = some existing requirements are unnecessary for deployments in carrier netwo= rks?

 

You seem to claim above that your proposal can be= more economical than existing solution. Given that new protocol would need= to be defined and functional entities newly developed and tested, I fail t= o see how this can be more economical than deployment of existing products which are already developed, tested, = mass produced and mass deployed. Can you provide some numbers supporting yo= ur view?

 

https://www.usenix.org/conferen= ce/nsdi13/technical-sessions/presentation/heimurl just proposes new fun= ctionality to be added, unrelated to any potential replacement of ABis reference point with SIP based interface= .

 

 

If b), then such solution can be deployed only in= countries where there is no license needed. You list Sweden as one with UK= and Netherlands with question marks. Also Antarctica was mentioned.

 

Can you please provide a reference to regulators'= document enabling usage of GSM bands without license in each of those coun= tries?

 

How will interferences be avoided if several indi= viduals/corporates start using the same GSM band in the same location, part= icularly if each starts using power enabling "potential 20 mile radius= even for a single cell"?

 

Furthermore, even if all of Sweden, UK, Netherlan= ds and Antarctica enable usage of GSM bands without license, this is still = quite limited market. If the solution is limited only to those countries, e= ven if the required feature set is smaller, there is little economies of scale.

 

Kind regards

 

Ivo Sedlacek

 

This Communication is Confidential. We only send = and receive email on the basis of the terms set out at www.ericsson.com/email= _disclaimer

 

--_000_39B5E4D390E9BD4890E2B3107900610112662068ESESSMB301erics_-- From thp@westhawk.co.uk Thu Feb 13 03:06:39 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990EE1A01DF for ; Thu, 13 Feb 2014 03:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ttKIyH7EPv0 for ; Thu, 13 Feb 2014 03:06:38 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by ietfa.amsl.com (Postfix) with ESMTP id 8220D1A01E3 for ; Thu, 13 Feb 2014 03:06:36 -0800 (PST) Received: (qmail 25778 invoked from network); 13 Feb 2014 11:06:34 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 4899 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 13 Feb 2014 11:06:34 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id A7C1118A048D for ; Thu, 13 Feb 2014 11:06:34 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 790A318A0436 for ; Thu, 13 Feb 2014 11:06:34 +0000 (GMT) From: Tim Panton new Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 13 Feb 2014 11:06:33 +0000 To: "dispatch@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [dispatch] Email ettiquette X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 11:06:39 -0000 If ( hypothetically ) an email were to be sent to this list containing a = disclaimer expressly forbidding a reply or disclosure, would it be concidered impolite to ignore it? Tim.= From emcho@sip-communicator.org Thu Feb 13 03:45:47 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DE51A01E8 for ; Thu, 13 Feb 2014 03:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKcg8utEGzHy for ; Thu, 13 Feb 2014 03:45:46 -0800 (PST) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by ietfa.amsl.com (Postfix) with ESMTP id C4FC21A01B4 for ; Thu, 13 Feb 2014 03:45:45 -0800 (PST) Received: by mail-ve0-f181.google.com with SMTP id cz12so8517084veb.12 for ; Thu, 13 Feb 2014 03:45:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VaPyRtrMoA4H9VH82pFbQn1NOgkU42XXUH31X0rdrXo=; b=B6x0pLQy+ZQushxGJbicDchY1T0nXuVIWU+i3X7uDbKUfcWwhB+hxOm9TCYjCBl/2n L4KTSnecBLLhezQOzdtkwJBw5jQqh36wvFcA5OZ/J4sWHsUNQ3td394g53rVtd2AmOE2 1K3LAkfTvdtDG2sdZO67NHdctMTLWGkJKI/agQHZFJJ159P7L2WumkV4uDPQOuZfACo4 7WCbOOIvPMsq/D9XRVZFSIqWHoXENSKkkdgKvBwoFxWgmAay5qk4rMKQteosVOL0h/mu dQGe4Sl7m0swj+OQa/oKBkr/rL4pjbRPQPQzk5Ihii3cUkJzr3O17YuOyAbCq7p0Qji+ OVqA== X-Gm-Message-State: ALoCoQmBCl3tKc50XJrffNT+xSer/BhrOXRUg4c676ejvCadWy4sIi5stog/bPtrjXfQDetKBsWW X-Received: by 10.52.251.232 with SMTP id zn8mr182755vdc.41.1392291944376; Thu, 13 Feb 2014 03:45:44 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by mx.google.com with ESMTPSA id x1sm2380749veb.5.2014.02.13.03.45.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 03:45:44 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id lf12so8189637vcb.3 for ; Thu, 13 Feb 2014 03:45:43 -0800 (PST) X-Received: by 10.58.188.78 with SMTP id fy14mr643511vec.23.1392291943928; Thu, 13 Feb 2014 03:45:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.191.130 with HTTP; Thu, 13 Feb 2014 03:45:23 -0800 (PST) In-Reply-To: References: From: Emil Ivov Date: Thu, 13 Feb 2014 12:45:23 +0100 Message-ID: To: Tim Panton new Content-Type: text/plain; charset=ISO-8859-1 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Email ettiquette X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 11:45:48 -0000 Or, instead of ignoring, responders could start their replies with a disclaimer that expressly forbids reading the rest. On Thu, Feb 13, 2014 at 12:06 PM, Tim Panton new wrote: > If ( hypothetically ) an email were to be sent to this list containing a disclaimer expressly forbidding a reply or disclosure, would > it be concidered impolite to ignore it? > > Tim. -- https://jitsi.org From jim.forster@rangenetworks.com Thu Feb 13 03:46:30 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36B01A01B4 for ; Thu, 13 Feb 2014 03:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHGCsq9O3S5x for ; Thu, 13 Feb 2014 03:46:27 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0187.outbound.protection.outlook.com [207.46.163.187]) by ietfa.amsl.com (Postfix) with ESMTP id A38251A01E8 for ; Thu, 13 Feb 2014 03:46:25 -0800 (PST) Received: from BL2PR03MB404.namprd03.prod.outlook.com (10.141.91.149) by BL2PR03MB147.namprd03.prod.outlook.com (10.255.230.19) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 11:46:22 +0000 Received: from BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) by BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 11:46:22 +0000 From: Jim Forster To: Ivo Sedlacek Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIIAAT20AgAAEZwCAAAXeAIAAJYiAgAFsZwCAAWBU1IABLnGAgAAby4A= Date: Thu, 13 Feb 2014 11:46:22 +0000 Message-ID: <676E4A52-E702-43BE-9245-5CD558D69497@rangenetworks.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [202.145.4.188] x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(71364002)(199002)(189002)(83716003)(85306002)(561944002)(79102001)(54316002)(77982001)(56776001)(19580395003)(59766001)(80976001)(93516002)(65816001)(80022001)(54356001)(53806001)(51856001)(66066001)(76482001)(63696002)(46102001)(94316002)(47446002)(86362001)(74502001)(83322001)(31966008)(74662001)(33656001)(47976001)(56816005)(94946001)(15975445006)(82746002)(50986001)(47736001)(95416001)(81816001)(81686001)(93136001)(49866001)(85852003)(92726001)(69226001)(4396001)(74366001)(90146001)(74876001)(2656002)(87266001)(16236675002)(81342001)(87936001)(81542001)(74706001)(92566001)(36756003)(95666001)(83072002)(76786001)(76796001)(15202345003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB147; H:BL2PR03MB404.namprd03.prod.outlook.com; CLIP:202.145.4.188; FPR:EFE8F16F.AFDA1FB5.F1D35DBB.4CF67178.20537; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_676E4A52E70243BE92455CD558D69497rangenetworkscom_" MIME-Version: 1.0 X-OriginatorOrg: rangenetworks.com Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 11:46:31 -0000 --_000_676E4A52E70243BE92455CD558D69497rangenetworkscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ivan, all, Sorry for the relative quiet from me after starting what seems to be a vigo= rous discussion. if I understood the proposal correctly, in comparison to 3GPP architecture= you propose: - UEs are unchanged - BTS - uses regular Um reference point towards UEs - has a new SIP based interface replacing ABis reference po= int - BSC, MSC, HSS, SM-SC, ... collapse into one functional entity "SAS/Asteri= sk/SMQueue". This new functional entity: - uses the new SIP based interface replacing ABis reference= point towards BTS - uses another SIP based interface towards remote networks Yes, that's pretty much it. Also noting that we are currently using this m= odel with 2G & 3G phones. Can you please clarify what's the intended business case where the propose= d solution is supposed to be superior over the existing 3GPP solution? Um, I thought that was pretty well covered. No? I can repeat what's been = said if that will help. E.g. can you please clarify whether you indent to specify a solution for: a) carriers with license to use the licensed GSM bands? Yes. b) individuals/corporates without license to use the licensed GSM bands? No. c) anyone else? The original mail suggested b) but then you referred to a) in your mail sta= ting "But more typically carriers with spectrum licenses are looking for an= economical way to get into rural areas." If a), such solution can be deployed anywhere where there are existing GSM = bands in use. Right. However, it will likely require implementation of the full 3GPP feature set= which carriers offer today, including supporting regulator's requirements,= support of handovers, integration with other operator subsystems (e.g. bil= ling, operation & maintenance subsystems, ...). It's not clear to me how all of that follows. Or do you believe that some existing requirements are unnecessary for deplo= yments in carrier networks? Evidence indicates entities operating legally are willing to use this appro= ach. I don't know the definition of a carrier, or if that's relevant in th= is forum. You probably see other evidence indicating a different conclusi= on. You seem to claim above that your proposal can be more economical than exi= sting solution. Given that new protocol would need to be defined and functi= onal entities newly developed and tested, This is largely done already. See working code, at previously mentioned pla= ces. We seek to document what has been done, while looking to the IETF community= for guidance on additional aspects of the Internet usage today, such as IP= v6, ICE, Security, etc. I believe many of those, which are variously recom= mended or required on the Internet, will be quite useful in this case. ...more further down... I fail to see how this can be more economical than deployment of existing p= roducts which are already developed, tested, mass produced and mass deploye= d. Can you provide some numbers supporting your view? https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/he= imurl just proposes new functionality to be added, unrelated to any potenti= al replacement of ABis reference point with SIP based interface. If b), then such solution can be deployed only in countries where there is = no license needed. You list Sweden as one with UK and Netherlands with ques= tion marks. Also Antarctica was mentioned. Can you please provide a reference to regulators' document enabling usage o= f GSM bands without license in each of those countries? How will interferences be avoided if several individuals/corporates start u= sing the same GSM band in the same location, particularly if each starts us= ing power enabling "potential 20 mile radius even for a single cell"? Furthermore, even if all of Sweden, UK, Netherlands and Antarctica enable u= sage of GSM bands without license, this is still quite limited market. If t= he solution is limited only to those countries, even if the required featur= e set is smaller, there is little economies of scale. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer Hmm?: is this policy consistent with IETF policies? I will take it on goo= d faith that it is, in which case it is unnecessary, but going forward a p= ositive affirmation would be useful. Please affirm. Yours, Jim Forster Range Networks. This email is not confidential. It is intended to used as part of the comm= unity discussion, and I recognize that all such discussion are a matter of = public record. --_000_676E4A52E70243BE92455CD558D69497rangenetworkscom_ Content-Type: text/html; charset="us-ascii" Content-ID: <9B070F639A46E74CBFB74F1D3AA6AD89@namprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Ivan, all,

Sorry for the relative quiet from me after starting what seems to be a= vigorous discussion.

 if I understood the propo= sal correctly, in comparison to 3GPP architecture you propose:
- UEs are unchanged
- BTS
            &nb= sp;   - uses regular Um reference point towards UEs
            &nb= sp;   - has a new SIP based interface replacing ABis reference po= int
- BSC, MSC, HSS, SM-SC, ... collapse into one functional entity "SAS/A= sterisk/SMQueue". This new functional entity:
            &nb= sp;   - uses the new SIP based interface replacing ABis reference= point towards BTS
            &nb= sp;   - uses another SIP based interface towards remote networks<= /div>

Yes, that's pretty much it.  Also noting that we are currently using t= his model with 2G & 3G phones.

 Can you please clarify wh= at's the intended business case where the proposed solution is supposed to = be superior over the existing 3GPP solution?

Um, I thought that was pretty well covered.  No?  I can repeat wh= at's been said if that will help.

 E.g. can you please clari= fy whether you indent to specify a solution for:
a) carriers with license to use the licensed GSM bands?

Yes.

b) individuals/corporates without license to use the licensed GSM bands?

No.

c) anyone else?
 
The original mail suggested b) but then you referred to a) in your mail sta= ting "But more typically carriers with spectrum licenses are looking f= or an economical way to get into rural areas."
 
If a), such solution can be deployed anywhere where there are existing GSM = bands in use.

Right.

However, it will likely require implementation of the full 3GPP feature set= which carriers offer today, including supporting regulator's requirements,= support of handovers, integration with other operator subsystems (e.g. bil= ling, operation & maintenance subsystems, ...).

It's not clear to me how all of that follows.

Or do you believe that some existing requirements are unnecessary for deplo= yments in carrier networks?

Evidence indicates entities operating legally are willing to use this = approach.  I don't know the definition of a carrier, or if that's rele= vant in this forum.   You probably see other evidence indicating a dif= ferent conclusion.

 You seem to claim above t= hat your proposal can be more economical than existing solution. Given that= new protocol would need to be defined and functional entities newly develo= ped and tested,

This is largely done already. See working code, at previously mentioned pla= ces. 

We seek to document what has been done, while looking to the IETF comm= unity for guidance on additional aspects of the Internet usage today, such = as IPv6, ICE, Security, etc.  I believe many of those, which are vario= usly recommended or required on the Internet, will be quite useful in this case.

...more further down...

I fail to see how this can be more economi= cal than deployment of existing products which are already developed, teste= d, mass produced and mass deployed. Can you provide some numbers supporting= your view?
 
http= s://www.usenix.org/conference/nsdi13/technical-sessions/presentation/heimur= l just proposes new functionality to be added, unrelated to any potential replace= ment of ABis reference point with SIP based interface.
 
 
If b), then such solution can be deployed only in countries where there is = no license needed. You list Sweden as one with UK and Netherlands with ques= tion marks. Also Antarctica was mentioned.
 
Can you please provide a reference to regulators' document enabling usage o= f GSM bands without license in each of those countries?
 
How will interferences be avoided if several individuals/corporates start u= sing the same GSM band in the same location, particularly if each starts us= ing power enabling "potential 20 mile radius even for a single cell&qu= ot;?
 
Furthermore, even if all of Sweden, UK, Netherlands and Antarctica enable u= sage of GSM bands without license, this is still quite limited market. If t= he solution is limited only to those countries, even if the required featur= e set is smaller, there is little economies of scale.
 
Kind regards
 
Ivo Sedlacek
 
This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer

Hmm?: is this policy consistent with IETF policies?   I will take it o= n good faith that it is, in which case it is unnecessary,  but going f= orward a positive affirmation would be useful.  Please affirm.


Yours,

Jim Forster

Range Networks.

This email is not confidential.  It is intended to used as part o= f the community discussion, and I recognize that all such discussion are a = matter of public record.

--_000_676E4A52E70243BE92455CD558D69497rangenetworkscom_-- From harvind@rangenetworks.com Thu Feb 13 04:37:21 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B171A0218 for ; Thu, 13 Feb 2014 04:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJzMwjELlBMP for ; Thu, 13 Feb 2014 04:37:19 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0153.outbound.protection.outlook.com [207.46.163.153]) by ietfa.amsl.com (Postfix) with ESMTP id 182D81A0213 for ; Thu, 13 Feb 2014 04:37:18 -0800 (PST) Received: from BN1PR03MB201.namprd03.prod.outlook.com (10.255.200.141) by BN1PR03MB204.namprd03.prod.outlook.com (10.255.200.155) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 12:37:15 +0000 Received: from BN1PR03MB201.namprd03.prod.outlook.com ([169.254.11.81]) by BN1PR03MB201.namprd03.prod.outlook.com ([169.254.11.81]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 12:37:15 +0000 From: Harvind Samra To: Ivo Sedlacek Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIIAAT20AgAAEZwCAAAXeAIAAJYiAgAFsZwCAAWBXlIABLm6AgAAqBAA= Date: Thu, 13 Feb 2014 12:37:14 +0000 Message-ID: <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [70.151.3.10] x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(377454003)(189002)(199002)(71364002)(24454002)(74876001)(87266001)(2656002)(74366001)(90146001)(81542001)(74706001)(81342001)(87936001)(16236675002)(81686001)(77096001)(93136001)(49866001)(69226001)(92726001)(4396001)(76796001)(76786001)(15202345003)(36756003)(92566001)(85852003)(83072002)(95666001)(19580405001)(79102001)(19580395003)(56776001)(93516002)(80976001)(59766001)(77982001)(54316002)(16601075003)(561944002)(83716003)(85306002)(65816001)(47976001)(74502001)(31966008)(33656001)(74662001)(83322001)(50986001)(95416001)(15975445006)(82746002)(81816001)(47736001)(94946001)(56816005)(86362001)(66066001)(76482001)(80022001)(51856001)(54356001)(53806001)(94316002)(47446002)(63696002)(46102001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR03MB204; H:BN1PR03MB201.namprd03.prod.outlook.com; CLIP:70.151.3.10; FPR:E7E8F12E.8EDA1E16.89D35F7B.40F67D78.20493; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_017BBEA0CDBE453D9E9877F470BC9181rangenetworkscom_" MIME-Version: 1.0 X-OriginatorOrg: rangenetworks.com Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 12:37:22 -0000 --_000_017BBEA0CDBE453D9E9877F470BC9181rangenetworkscom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Ivo, I have to ask=85why are the questions regarding frequency licensing and eco= nomics relevant? This is a discussion regrading augmenting SIP. On Feb 13, 2014, at 2:06 AM, Ivo Sedlacek > wrote: Hello Tim and all, if I understood the proposal correctly, in comparison to 3GPP architecture = you propose: - UEs are unchanged - BTS - uses regular Um reference point towards UEs - has a new SIP based interface replacing ABis reference po= int - BSC, MSC, HSS, SM-SC, ... collapse into one functional entity "SAS/Asteri= sk/SMQueue". This new functional entity: - uses the new SIP based interface replacing ABis reference= point towards BTS - uses another SIP based interface towards remote networks Can you please clarify what's the intended business case where the proposed= solution is supposed to be superior over the existing 3GPP solution? E.g. can you please clarify whether you indent to specify a solution for: a) carriers with license to use the licensed GSM bands? b) individuals/corporates without license to use the licensed GSM bands? c) anyone else? The original mail suggested b) but then you referred to a) in your mail sta= ting "But more typically carriers with spectrum licenses are looking for an= economical way to get into rural areas." If a), such solution can be deployed anywhere where there are existing GSM = bands in use. However, it will likely require implementation of the full 3G= PP feature set which carriers offer today, including supporting regulator's= requirements, support of handovers, integration with other operator subsys= tems (e.g. billing, operation & maintenance subsystems, ...). Or do you bel= ieve that some existing requirements are unnecessary for deployments in car= rier networks? You seem to claim above that your proposal can be more economical than exis= ting solution. Given that new protocol would need to be defined and functio= nal entities newly developed and tested, I fail to see how this can be more= economical than deployment of existing products which are already develope= d, tested, mass produced and mass deployed. Can you provide some numbers su= pporting your view? https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/he= imurl just proposes new functionality to be added, unrelated to any potenti= al replacement of ABis reference point with SIP based interface. If b), then such solution can be deployed only in countries where there is = no license needed. You list Sweden as one with UK and Netherlands with ques= tion marks. Also Antarctica was mentioned. Can you please provide a reference to regulators' document enabling usage o= f GSM bands without license in each of those countries? How will interferences be avoided if several individuals/corporates start u= sing the same GSM band in the same location, particularly if each starts us= ing power enabling "potential 20 mile radius even for a single cell"? Furthermore, even if all of Sweden, UK, Netherlands and Antarctica enable u= sage of GSM bands without license, this is still quite limited market. If t= he solution is limited only to those countries, even if the required featur= e set is smaller, there is little economies of scale. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch Harvind Samra Founder, CTO Range Networks San Francisco, CA ____________________________________________ Cellular networks made simple and affordable. http://www.rangenetworks.com ____________________________________________ --_000_017BBEA0CDBE453D9E9877F470BC9181rangenetworkscom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1284D92287D24446B2088D61DB278EC4@namprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable Hi Ivo,

I have to ask=85why are the questions regarding frequency licensing an= d economics relevant?  This is a discussion regrading augmenting SIP.<= /div>

On Feb 13, 2014, at 2:06 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:

Hello Tim and all,         &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;       
 
if I understood the proposal correctly, in comparison to 3GPP architecture = you propose:
- UEs are unchanged
- BTS
            &nb= sp;   - uses regular Um reference point towards UEs
            &nb= sp;   - has a new SIP based interface replacing ABis reference po= int
- BSC, MSC, HSS, SM-SC, ... collapse into one functional entity "SAS/A= sterisk/SMQueue". This new functional entity:
            &nb= sp;   - uses the new SIP based interface replacing ABis reference= point towards BTS
            &nb= sp;   - uses another SIP based interface towards remote networks<= o:p>
 
Can you please clarify what's the intended business case where the proposed= solution is supposed to be superior over the existing 3GPP solution?<= /o:p>
 
E.g. can you please clarify whether you indent to specify a solution for:
a) carriers with license to use the licensed GSM bands?
b) individuals/corporates without license to use the licensed GSM bands?
c) anyone else?
 
The original mail suggested b) but then you referred to a) in your mail sta= ting "But more typically carriers with spectrum licenses are looking f= or an economical way to get into rural areas."
 
 
If a), such solution can be deployed anywhere where there are existing GSM = bands in use. However, it will likely require implementation of the full 3G= PP feature set which carriers offer today, including supporting regulator's= requirements, support of handovers, integration with other operator subsystems (e.g. billing, operation & = maintenance subsystems, ...). Or do you believe that some existing requirem= ents are unnecessary for deployments in carrier networks?
 
You seem to claim above that your proposal can be more economical than exis= ting solution. Given that new protocol would need to be defined and functio= nal entities newly developed and tested, I fail to see how this can be more= economical than deployment of existing products which are already developed, tested, mass produced and mass deplo= yed. Can you provide some numbers supporting your view?
 
http= s://www.usenix.org/conference/nsdi13/technical-sessions/presentation/heimur= l just proposes new functionality to be added, unrelated to any potential replace= ment of ABis reference point with SIP based interface.
 
 
If b), then such solution can be deployed only in countries where there is = no license needed. You list Sweden as one with UK and Netherlands with ques= tion marks. Also Antarctica was mentioned.
 
Can you please provide a reference to regulators' document enabling usage o= f GSM bands without license in each of those countries?
 
How will interferences be avoided if several individuals/corporates start u= sing the same GSM band in the same location, particularly if each starts us= ing power enabling "potential 20 mile radius even for a single cell&qu= ot;?
 
Furthermore, even if all of Sweden, UK, Netherlands and Antarctica enable u= sage of GSM bands without license, this is still quite limited market. If t= he solution is limited only to those countries, even if the required featur= e set is smaller, there is little economies of scale.
 
Kind regards
 
Ivo Sedlacek
 
This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer
 
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/= dispatch

Harvind Samra
Founder, CTO
Range Networks
San Francisco, CA  
____________________________________________

Cellular networks made simple and affo= rdable.  
______________________________________= ______




--_000_017BBEA0CDBE453D9E9877F470BC9181rangenetworkscom_-- From sunilkumarsinha9@rediffmail.com Thu Feb 13 05:36:18 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24291A01F9 for ; Thu, 13 Feb 2014 05:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.732 X-Spam-Level: ** X-Spam-Status: No, score=2.732 tagged_above=-999 required=5 tests=[BAYES_60=1.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FM6U2EOY7YLa for ; Thu, 13 Feb 2014 05:36:17 -0800 (PST) Received: from rediffmail.com (f5mail-224-149.rediffmail.com [114.31.224.149]) by ietfa.amsl.com (Postfix) with SMTP id A5C371A01D5 for ; Thu, 13 Feb 2014 05:36:16 -0800 (PST) Received: (qmail 31398 invoked by uid 510); 13 Feb 2014 13:36:09 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=CIc3Eaiu7ZupP8MZtm7VRgU6EfBphDArnxHqTGQTiOpaRRk+4ml1wCf8sZ0sCdgPby0JQWh9pGfaK4PB60Fqn/4psHlelNMVCG9uW9s6qZY5ejPpMy79K8oVUkKd5zk40fdQYC21U3zkIk605mfyTZ5+5SLZ4AMahRkwBkM2RoA= ; x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd; X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: : 0 X-CTCH-RefID: str=0001.0A150207.52FCCA4B.0124, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-REDF-OSEN: sunilkumarsinha9@rediffmail.com Date: 13 Feb 2014 13:36:08 -0000 Message-ID: <20140213133608.31245.qmail@f5mail-224-149.rediffmail.com> MIME-Version: 1.0 To: Received: from unknown 122.167.104.123 by rediffmail.com via HTTP; 13 Feb 2014 13:36:08 -0000 Sender: sunilkumarsinha9@rediffmail.com From: "sunil kumar sinha" Content-Type: multipart/alternative; boundary="=_d89805d4ec1471be88e3781c5ede951f" Subject: [dispatch] =?utf-8?q?SIP_INVITE_server_transaction?= X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 13:36:19 -0000 --=_d89805d4ec1471be88e3781c5ede951f Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi, SIP INVITE client transaction can retransmit INVITE seven times in case of unreliable transport before it gets timeout. My queries as below 1.)Does SIP INVITE server transaction also retransmit INVITE? 2.)If yes, then please share some detail on it. Thanks & Regard sunil --=_d89805d4ec1471be88e3781c5ede951f Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi,

SIP INVITE client transaction can retransmit INVITE seven times in case of = unreliable transport before it gets timeout.

My queries as below
1.)Does SIP INVITE server transaction also retransmit INVITE?
2.)If yes, then please share some detail on it.

Thanks & Regard
sunil



=
<= b>Know More >
Get your own FREE website, FREE domain & FREE mobile app with Company email.  
--=_d89805d4ec1471be88e3781c5ede951f-- From keith.drage@alcatel-lucent.com Thu Feb 13 06:28:04 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126B91A0237 for ; Thu, 13 Feb 2014 06:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n_EnTxAV-gsO for ; Thu, 13 Feb 2014 06:28:02 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id DDB931A0240 for ; Thu, 13 Feb 2014 06:28:01 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1DERx7b006393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Feb 2014 08:28:00 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1DERwYQ028428 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 15:27:58 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 13 Feb 2014 15:27:58 +0100 From: "DRAGE, Keith (Keith)" To: Tim Panton new , "dispatch@ietf.org" Thread-Topic: [dispatch] Email ettiquette Thread-Index: AQHPKKuuUX/UwwpnVU6pt2w9VuIY5pqzN8Jw Date: Thu, 13 Feb 2014 14:27:57 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B1319A7@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Email ettiquette X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:28:04 -0000 While these signature lines are undesirable, and some people don't have any= choice in having them there, apart from using a non-company email address.= I personally prefer that people participating on behalf of their company u= se the company email address. In any case, please note the following: 1) If it is Ivo's mail you are referring to, then it does not forbid replyi= ng. Further it states "unauthorised" (see 2 below). You are a member of the= WG and it is addressed to the WG. 2) A long time ago I raised this issue on the WG chairs list, and the answe= r I was given was that the contract you make (the Note well) when you sign = up to the mailing list overrides all such statements. Regards Keith =20 > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf=20 > Of Tim Panton new > Sent: 13 February 2014 11:07 > To: dispatch@ietf.org > Subject: [dispatch] Email ettiquette >=20 > If ( hypothetically ) an email were to be sent to this list=20 > containing a disclaimer expressly forbidding a reply or=20 > disclosure, would it be concidered impolite to ignore it? >=20 > Tim. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From keith.drage@alcatel-lucent.com Thu Feb 13 06:34:27 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0371A029D for ; Thu, 13 Feb 2014 06:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoqIlzbPLIvT for ; Thu, 13 Feb 2014 06:34:23 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id AD9A71A029C for ; Thu, 13 Feb 2014 06:34:23 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1DEYGut009300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Feb 2014 08:34:17 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1DEYFwo000673 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 15:34:16 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 13 Feb 2014 15:34:15 +0100 From: "DRAGE, Keith (Keith)" To: Harvind Samra , Ivo Sedlacek Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIIAAPqkAgAASvbD///eJAIAAMB4ggAFh0ACAAXHr6IABHNuAgAAqBACAADBv4A== Date: Thu, 13 Feb 2014 14:34:15 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> In-Reply-To: <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B1319E6FR712WXCHMBA11zeu_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:34:28 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B1319E6FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jumping in here, they are relevant in as much as there is no point in IETF = working on this if there is no known market for it. Usually those type of projects are published only on April 1st. So all Ivo is asking is for you to justify that it is worth other people wo= rking on this as well as yourselves. Perhaps if you identified the spectrum you believe is available for use in = the the countries identified, that would be useful. regards Keith Drage ________________________________ From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Harvind Samr= a Sent: 13 February 2014 12:37 To: Ivo Sedlacek Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS Hi Ivo, I have to ask...why are the questions regarding frequency licensing and eco= nomics relevant? This is a discussion regrading augmenting SIP. On Feb 13, 2014, at 2:06 AM, Ivo Sedlacek > wrote: Hello Tim and all, if I understood the proposal correctly, in comparison to 3GPP architecture = you propose: - UEs are unchanged - BTS - uses regular Um reference point towards UEs - has a new SIP based interface replacing ABis reference po= int - BSC, MSC, HSS, SM-SC, ... collapse into one functional entity "SAS/Asteri= sk/SMQueue". This new functional entity: - uses the new SIP based interface replacing ABis reference= point towards BTS - uses another SIP based interface towards remote networks Can you please clarify what's the intended business case where the proposed= solution is supposed to be superior over the existing 3GPP solution? E.g. can you please clarify whether you indent to specify a solution for: a) carriers with license to use the licensed GSM bands? b) individuals/corporates without license to use the licensed GSM bands? c) anyone else? The original mail suggested b) but then you referred to a) in your mail sta= ting "But more typically carriers with spectrum licenses are looking for an= economical way to get into rural areas." If a), such solution can be deployed anywhere where there are existing GSM = bands in use. However, it will likely require implementation of the full 3G= PP feature set which carriers offer today, including supporting regulator's= requirements, support of handovers, integration with other operator subsys= tems (e.g. billing, operation & maintenance subsystems, ...). Or do you bel= ieve that some existing requirements are unnecessary for deployments in car= rier networks? You seem to claim above that your proposal can be more economical than exis= ting solution. Given that new protocol would need to be defined and functio= nal entities newly developed and tested, I fail to see how this can be more= economical than deployment of existing products which are already develope= d, tested, mass produced and mass deployed. Can you provide some numbers su= pporting your view? https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/he= imurl just proposes new functionality to be added, unrelated to any potenti= al replacement of ABis reference point with SIP based interface. If b), then such solution can be deployed only in countries where there is = no license needed. You list Sweden as one with UK and Netherlands with ques= tion marks. Also Antarctica was mentioned. Can you please provide a reference to regulators' document enabling usage o= f GSM bands without license in each of those countries? How will interferences be avoided if several individuals/corporates start u= sing the same GSM band in the same location, particularly if each starts us= ing power enabling "potential 20 mile radius even for a single cell"? Furthermore, even if all of Sweden, UK, Netherlands and Antarctica enable u= sage of GSM bands without license, this is still quite limited market. If t= he solution is limited only to those countries, even if the required featur= e set is smaller, there is little economies of scale. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch Harvind Samra Founder, CTO Range Networks San Francisco, CA ____________________________________________ Cellular networks made simple and affordable. http://www.rangenetworks.com ____________________________________________ --_000_949EF20990823C4C85C18D59AA11AD8B1319E6FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Jumping in here, they are relevan= t in as much as there is no point in IETF working on this if there is no kn= own market for it.
 
Usually those type of projects ar= e published only on April 1st.
 
So all Ivo is asking is for you t= o justify that it is worth other people working on this as well as yourselv= es.
 
Perhaps if you identified the spe= ctrum you believe is available for use in the the countries identified, tha= t would be useful.
 
regards
 
Keith Drage

From: dispatch [mailto:dispatch-bou= nces@ietf.org] On Behalf Of Harvind Samra
Sent: 13 February 2014 12:37
To: Ivo Sedlacek
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

Hi Ivo,

I have to ask…why are the questions regarding frequency licensin= g and economics relevant?  This is a discussion regrading augmenting S= IP.

On Feb 13, 2014, at 2:06 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote:

Hello Tim and all,         &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;       
if I understood the proposal correctly, in comparison to 3GPP architecture = you propose:
- UEs are unchanged
- BTS
            &nb= sp;   - uses regular Um reference point towards UEs
            &nb= sp;   - has a new SIP based interface replacing ABis reference po= int
- BSC, MSC, HSS, SM-SC, ... collapse into one functional entity "SAS/A= sterisk/SMQueue". This new functional entity:
            &nb= sp;   - uses the new SIP based interface replacing ABis reference= point towards BTS
            &nb= sp;   - uses another SIP based interface towards remote networks<= O:P>
Can you please clarify what's the intended business case where the proposed= solution is supposed to be superior over the existing 3GPP solution?<= /O:P>
E.g. can you please clarify whether you indent to specify a solution for:
a) carriers with license to use the licensed GSM bands?
b) individuals/corporates without license to use the licensed GSM bands?
c) anyone else?
The original mail suggested b) but then you referred to a) in your mail sta= ting "But more typically carriers with spectrum licenses are looking f= or an economical way to get into rural areas."
If a), such solution can be deployed anywhere where there are existing GSM = bands in use. However, it will likely require implementation of the full 3G= PP feature set which carriers offer today, including supporting regulator's= requirements, support of handovers, integration with other operator subsystems (e.g. billing, operation & = maintenance subsystems, ...). Or do you believe that some existing requirem= ents are unnecessary for deployments in carrier networks?
You seem to claim above that your proposal can be more economical than exis= ting solution. Given that new protocol would need to be defined and functio= nal entities newly developed and tested, I fail to see how this can be more= economical than deployment of existing products which are already developed, tested, mass produced and mass deplo= yed. Can you provide some numbers supporting your view?
https= ://www.usenix.org/conference/nsdi13/technical-sessions/presentation/heimurl=  just proposes new functionality to be added, unrelated to any potential replace= ment of ABis reference point with SIP based interface.
If b), then such solution can be deployed only in countries where there is = no license needed. You list Sweden as one with UK and Netherlands with ques= tion marks. Also Antarctica was mentioned.
Can you please provide a reference to regulators' document enabling usage o= f GSM bands without license in each of those countries?
How will interferences be avoided if several individuals/corporates start u= sing the same GSM band in the same location, particularly if each starts us= ing power enabling "potential 20 mile radius even for a single cell&qu= ot;?
Furthermore, even if all of Sweden, UK, Netherlands and Antarctica enable u= sage of GSM bands without license, this is still quite limited market. If t= he solution is limited only to those countries, even if the required featur= e set is smaller, there is little economies of scale.
Kind regards
Ivo Sedlacek
This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/d= ispatch

Harvind Samra
Founder, CTO
Range Networks
San Francisco, CA  
____________________________________________

Cellular networks made simple and afford= able.  
________________________________________= ____




--_000_949EF20990823C4C85C18D59AA11AD8B1319E6FR712WXCHMBA11zeu_-- From jim.forster@rangenetworks.com Thu Feb 13 06:40:16 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9941A02B3 for ; Thu, 13 Feb 2014 06:40:16 -0800 (PST) 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=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjJMCQJOGYip for ; Thu, 13 Feb 2014 06:40:14 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0153.outbound.protection.outlook.com [207.46.163.153]) by ietfa.amsl.com (Postfix) with ESMTP id 4871C1A0291 for ; Thu, 13 Feb 2014 06:39:51 -0800 (PST) Received: from BL2PR03MB404.namprd03.prod.outlook.com (10.141.91.149) by BL2PR03MB401.namprd03.prod.outlook.com (10.141.91.145) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 14:39:47 +0000 Received: from BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) by BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 14:39:47 +0000 From: Jim Forster To: "DRAGE, Keith (Keith)" Thread-Topic: [dispatch] Email ettiquette Thread-Index: AQHPKKuuzEvQFiVrp0+c5r0/+Awx/JqzPjyAgAADTIA= Date: Thu, 13 Feb 2014 14:39:46 +0000 Message-ID: <2B6412BF-FAB6-433E-8275-453C785248FF@rangenetworks.com> References: <949EF20990823C4C85C18D59AA11AD8B1319A7@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1319A7@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [202.145.4.186] x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(24454002)(164054003)(13464003)(51704005)(199002)(377454003)(189002)(80022001)(87266001)(65816001)(74662001)(87936001)(95666001)(83716003)(92726001)(92566001)(2656002)(82746002)(56816005)(90146001)(83072002)(31966008)(85852003)(15975445006)(36756003)(76786001)(76796001)(81686001)(66066001)(81816001)(85306002)(47446002)(74502001)(69226001)(93136001)(86362001)(95416001)(94316002)(79102001)(93516002)(74706001)(81542001)(53806001)(46102001)(54356001)(51856001)(56776001)(54316002)(76482001)(4396001)(49866001)(47736001)(50986001)(47976001)(74876001)(81342001)(74366001)(94946001)(59766001)(77982001)(33656001)(63696002)(80976001)(19580395003)(19580405001)(83322001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB401; H:BL2PR03MB404.namprd03.prod.outlook.com; CLIP:202.145.4.186; FPR:F7C6F917.AAFA97DA.F1C5BEAB.82FAE261.2035D; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rangenetworks.com Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Email ettiquette X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:40:16 -0000 Keith, I fully well understand the difficulties of large companies and their IT de= partments and policies, and I agree about the desirability of clearly ident= ifying affiliations. Still, I would ask for some positive affirmation, ideally from your corpora= te legal department (:-)), or at least from the WG chairs, that Ericksson's= policy, as referenced in your message, is conformant to the IETF policies,= or null and void somehow.=20 Personally, I can take your word in good faith, but procedurally I would th= ink some more formalism is appropriate for the WG group and IETF. Sigh...Thanks, -- Jim PS: Your recent message doesn't have the worrisome statement. Phew! I was= going ask how can you guys communicate when everything you say is supposed= to be confidential :-) On Feb 13, 2014, at 9:27 PM, DRAGE, Keith (Keith) wrote: > While these signature lines are undesirable, and some people don't have a= ny choice in having them there, apart from using a non-company email addres= s. I personally prefer that people participating on behalf of their company= use the company email address. In any case, please note the following: >=20 > 1) If it is Ivo's mail you are referring to, then it does not forbid repl= ying. Further it states "unauthorised" (see 2 below). You are a member of t= he WG and it is addressed to the WG. >=20 > 2) A long time ago I raised this issue on the WG chairs list, and the ans= wer I was given was that the contract you make (the Note well) when you sig= n up to the mailing list overrides all such statements. >=20 > Regards >=20 > Keith >=20 >=20 >=20 >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf=20 >> Of Tim Panton new >> Sent: 13 February 2014 11:07 >> To: dispatch@ietf.org >> Subject: [dispatch] Email ettiquette >>=20 >> If ( hypothetically ) an email were to be sent to this list=20 >> containing a disclaimer expressly forbidding a reply or=20 >> disclosure, would it be concidered impolite to ignore it? >>=20 >> Tim. >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From thp@westhawk.co.uk Thu Feb 13 06:49:43 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98CD61A01EB for ; Thu, 13 Feb 2014 06:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_H-aRVe7rT7 for ; Thu, 13 Feb 2014 06:49:41 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id 943421A029E for ; Thu, 13 Feb 2014 06:49:40 -0800 (PST) Received: (qmail 28691 invoked from network); 13 Feb 2014 14:49:38 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 10306 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 13 Feb 2014 14:49:38 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 60D9618A03A8; Thu, 13 Feb 2014 14:49:38 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id E40F018A0137; Thu, 13 Feb 2014 14:49:37 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_255D003C-5D9C-4F20-A4F2-4348819DC64D" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton new In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 13 Feb 2014 14:49:30 +0000 Message-Id: <00361BF0-F6B9-48DD-80A6-CECD0A7C0A3B@westhawk.co.uk> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:49:43 -0000 --Apple-Mail=_255D003C-5D9C-4F20-A4F2-4348819DC64D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) = wrote: > Jumping in here, they are relevant in as much as there is no point in = IETF working on this if there is no known market for it. > =20 > Usually those type of projects are published only on April 1st. > =20 > So all Ivo is asking is for you to justify that it is worth other = people working on this as well as yourselves. > =20 > Perhaps if you identified the spectrum you believe is available for = use in the the countries identified, that would be useful. > =20 > regards > =20 > Keith Drage Ivo's employer seems to see a market for small cells, but looks to tie = them to existing operator IMS's through=20 internet connections "owned by themselves or a partner". = http://www.telecomlead.com/enterprise-networking/mwc-2014-ericsson-announc= e-small-cell-service-20233/ Perhaps that's an April fools joke too (I can't see any avian carriers = mentioned though)? It isn't up to the IETF to crown specific solutions. That's the market's = job. T. --Apple-Mail=_255D003C-5D9C-4F20-A4F2-4348819DC64D Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:

Jumping in here, they are relevant in as much as there is no point in IETF working on this if there is no known market for it.
 
Usually those type of projects are published only on April 1st.
 
So all Ivo is asking is for you to justify that it is worth other people working on this as well as yourselves.
 
Perhaps if you identified the spectrum you believe is available for use in the the countries identified, that would be useful.
 
regards
 
Keith Drage

Ivo's employer seems to see a market for small cells, but looks to tie them to existing operator IMS's through 
internet connections "owned by themselves or a partner".
Perhaps that's an April fools joke too (I can't see any avian carriers mentioned though)?

It isn't up to the IETF to crown specific solutions. That's the market's job.

T.



--Apple-Mail=_255D003C-5D9C-4F20-A4F2-4348819DC64D-- From ivo.sedlacek@ericsson.com Thu Feb 13 06:59:45 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4F71A02A1 for ; Thu, 13 Feb 2014 06:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08mLyfDFSLAL for ; Thu, 13 Feb 2014 06:59:42 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 353731A008E for ; Thu, 13 Feb 2014 06:59:41 -0800 (PST) X-AuditID: c1b4fb2d-b7f5d8e000002a7b-f9-52fcddda2f77 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E3.1A.10875.ADDDCF25; Thu, 13 Feb 2014 15:59:38 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.164]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 15:59:37 +0100 From: Ivo Sedlacek To: Tim Panton new Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPKAwVozdeAICzrkKy3baFOj5a05qy64bA Date: Thu, 13 Feb 2014 14:59:38 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101126623B2@ESESSMB301.ericsson.se> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> In-Reply-To: <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101126623B2ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvje6tu3+CDBY1aVgsnbSA1WLd+2Ms DkweS5b8ZPK4OG0/UwBTFJdNSmpOZllqkb5dAlfGstOzmAr2JFQ8eWLXwPg5qIuRk0NCwESi r7uPBcIWk7hwbz1bFyMXh5DAIUaJjctvM0E4Sxglli2ZxgRSxSagJzFxyxFWEFtEQF1i5tKL YHFmAW2J/9fXMYLYwgKmEiuntkDVmElMmjaLuYuRA8g2ktj7wx4kzCKgKnG0/TlYCa+Ar8TF uetZIXY1c0l8v7yfDSTBKeAg8evHRbCZjAKyElf/9DJC7BKXuPVkPhPE1QISS/acZ4awRSVe Pv7HCmErSazYfgmqPl9i/8X7LBDLBCVOznzCMoFRdBaSUbOQlM1CUgYR15FYsPsT2yyoN5ct fM0MY5858JgJWXwBI/sqRvbcxMyc9HLDTYzAmDq45bfuDsZT50QOMUpzsCiJ83546xwkJJCe WJKanZpakFoUX1Sak1p8iJGJg1OqgTFd6bR+TnPFU42fn1g+y7m8WhWyeYKh394D6cuLj7yb ust+b1RcZFzck9yjO3Y6MRjaeW9+335A8qft2vTzby8uz9/5Snx2+BKDtNxJfyb0Z4S4HCte xSvwWScp1bdnm/jRn9Vba1RV7ut4Z1RcY95ctiY86J3Lr/a9d15p7dkTslbv6n/mHS1KLMUZ iYZazEXFiQDHvcDtdwIAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:59:45 -0000 --_000_39B5E4D390E9BD4890E2B31079006101126623B2ESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (the mail below is resent without the final line) Hello Tim and all, if I understood the proposal correctly, in comparison to 3GPP architecture = you propose: - UEs are unchanged - BTS - uses regular Um reference point towards UEs - has a new SIP based interface replacing ABis reference po= int - BSC, MSC, HSS, SM-SC, ... collapse into one functional entity "SAS/Asteri= sk/SMQueue". This new functional entity: - uses the new SIP based interface replacing ABis reference= point towards BTS - uses another SIP based interface towards remote networks Can you please clarify what's the intended business case where the proposed= solution is supposed to be superior over the existing 3GPP solution? E.g. can you please clarify whether you indent to specify a solution for: a) carriers with license to use the licensed GSM bands? b) individuals/corporates without license to use the licensed GSM bands? c) anyone else? The original mail suggested b) but then you referred to a) in your mail sta= ting "But more typically carriers with spectrum licenses are looking for an= economical way to get into rural areas." If a), such solution can be deployed anywhere where there are existing GSM = bands in use. However, it will likely require implementation of the full 3G= PP feature set which carriers offer today, including supporting regulator's= requirements, support of handovers, integration with other operator subsys= tems (e.g. billing, operation & maintenance subsystems, ...). Or do you bel= ieve that some existing requirements are unnecessary for deployments in car= rier networks? You seem to claim above that your proposal can be more economical than exis= ting solution. Given that new protocol would need to be defined and functio= nal entities newly developed and tested, I fail to see how this can be more= economical than deployment of existing products which are already develope= d, tested, mass produced and mass deployed. Can you provide some numbers su= pporting your view? https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/he= imurl just proposes new functionality to be added, unrelated to any potenti= al replacement of ABis reference point with SIP based interface. If b), then such solution can be deployed only in countries where there is = no license needed. You list Sweden as one with UK and Netherlands with ques= tion marks. Also Antarctica was mentioned. Can you please provide a reference to regulators' document enabling usage o= f GSM bands without license in each of those countries? How will interferences be avoided if several individuals/corporates start u= sing the same GSM band in the same location, particularly if each starts us= ing power enabling "potential 20 mile radius even for a single cell"? Furthermore, even if all of Sweden, UK, Netherlands and Antarctica enable u= sage of GSM bands without license, this is still quite limited market. If t= he solution is limited only to those countries, even if the required featur= e set is smaller, there is little economies of scale. Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B31079006101126623B2ESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(the mail below is resent without the final line)=

 

Hello Tim and all,     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           

 

if I understood the proposal correctly, in compar= ison to 3GPP architecture you propose:

- UEs are unchanged

- BTS

        &= nbsp;       - uses regular Um reference point= towards UEs

        &= nbsp;       - has a new SIP based interface r= eplacing ABis reference point

- BSC, MSC, HSS, SM-SC, ... collapse into one fun= ctional entity "SAS/Asterisk/SMQueue". This new functional entity= :

        &= nbsp;       - uses the new SIP based interfac= e replacing ABis reference point towards BTS

        &= nbsp;       - uses another SIP based interfac= e towards remote networks

 

Can you please clarify what's the intended busine= ss case where the proposed solution is supposed to be superior over the exi= sting 3GPP solution?

 

E.g. can you please clarify whether you indent to= specify a solution for:

a) carriers with license to use the licensed GSM = bands?

b) individuals/corporates without license to use = the licensed GSM bands?

c) anyone else?

 

The original mail suggested b) but then you refer= red to a) in your mail stating "But more typically carriers with spect= rum licenses are looking for an economical way to get into rural areas.&quo= t;

 

 

If a), such solution can be deployed anywhere whe= re there are existing GSM bands in use. However, it will likely require imp= lementation of the full 3GPP feature set which carriers offer today, includ= ing supporting regulator's requirements, support of handovers, integration with other operator subsystems (e.g. bil= ling, operation & maintenance subsystems, ...). Or do you believe that = some existing requirements are unnecessary for deployments in carrier netwo= rks?

 

You seem to claim above that your proposal can be= more economical than existing solution. Given that new protocol would need= to be defined and functional entities newly developed and tested, I fail t= o see how this can be more economical than deployment of existing products which are already developed, tested, = mass produced and mass deployed. Can you provide some numbers supporting yo= ur view?

 

https://www.usenix.org/conferen= ce/nsdi13/technical-sessions/presentation/heimurl just proposes new fun= ctionality to be added, unrelated to any potential replacement of ABis reference point with SIP based interface= .

 

 

If b), then such solution can be deployed only in= countries where there is no license needed. You list Sweden as one with UK= and Netherlands with question marks. Also Antarctica was mentioned.

 

Can you please provide a reference to regulators'= document enabling usage of GSM bands without license in each of those coun= tries?

 

How will interferences be avoided if several indi= viduals/corporates start using the same GSM band in the same location, part= icularly if each starts using power enabling "potential 20 mile radius= even for a single cell"?

 

Furthermore, even if all of Sweden, UK, Netherlan= ds and Antarctica enable usage of GSM bands without license, this is still = quite limited market. If the solution is limited only to those countries, e= ven if the required feature set is smaller, there is little economies of scale.

 

Kind regards

 

Ivo Sedlacek

 

 

--_000_39B5E4D390E9BD4890E2B31079006101126623B2ESESSMB301erics_-- From ivo.sedlacek@ericsson.com Thu Feb 13 07:00:10 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7C31A02B5 for ; Thu, 13 Feb 2014 07:00:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KHN_hFHh-ta for ; Thu, 13 Feb 2014 07:00:05 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id AA5D11A02B7 for ; Thu, 13 Feb 2014 07:00:04 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-44-52fcddf20ddb Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 60.8D.23809.2FDDCF25; Thu, 13 Feb 2014 16:00:02 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.164]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 16:00:02 +0100 From: Ivo Sedlacek To: Jim Forster Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIIAAT20AgAAEZwCAAAXeAIAAJYiAgAFsZwCAAWBU1IABLnGAgAAby4CAAANfkA== Date: Thu, 13 Feb 2014 15:00:02 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101126623BB@ESESSMB301.ericsson.se> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <676E4A52-E702-43BE-9245-5CD558D69497@rangenetworks.com> In-Reply-To: <676E4A52-E702-43BE-9245-5CD558D69497@rangenetworks.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101126623BBESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje6nu3+CDE5Ps7BYOmkBq8WD84fY LNa9P8biwOyxZMlPJo8zJ9M9Lk7bzxTAHMVlk5Kak1mWWqRvl8CV8envf8aCzakV9yZnNTBu iupi5OSQEDCR2Pq/jxXCFpO4cG89WxcjF4eQwCFGiS+t71khnCWMEouvv2QCqWIT0JOYuOUI UIKDQ0RAX2J1qwFImFnAR2LVrqvMILawgKnEyqktYENFBMwkJk2bxQxh72KU2PoCrJ5FQFVi 3dzP7CA2r4CvxJ6L/9khdjVxS1xvuQHWwCngKvHxSzfYXkYBWYmrf3oZIZaJS9x6Mp8J4moB iSV7zjND2KISLx//g/pGSWLF9ktQ9fkSd/d9gVomKHFy5hOWCYyis5CMmoWkbBaSMoi4jsSC 3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkT03MTMnvdxoEyMwyg5u+a26g/HOOZFDjNIcLEri vB/eOgcJCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYLT3kZ/43OLjtuz97VtFmnMvmi2qY50s FxQz4fjRhy5bFKPvHgmX+bvLpPsH95RLd8+LC/w1vfcneXpp3Cx19ditdyJ7Umwm7jlYm1y4 8Na3Td4/ky+4XE43eVQUNNFxv10Tx3e986y60yRU383j3Tehcr7envr+D/1xaV/ZJyp57zZZ ZLM/1UOJpTgj0VCLuag4EQBhJ/36gAIAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:00:10 -0000 --_000_39B5E4D390E9BD4890E2B31079006101126623BBESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Jin and Samra, @Jin: > > E.g. can you please clarify whether you indent to specify a solution fo= r: > >a) carriers with license to use the licensed GSM bands? > > Yes. > > > b) individuals/corporates without license to use the licensed GSM bands= ? > > No. OK, thanks for clarification. > > Or do you believe that some existing requirements are unnecessary for d= eployments in carrier networks? > > Evidence indicates entities operating legally are willing to use this app= roach. I don't know the definition of a carrier, > or if that's relevant in this forum. You probably see other evidence in= dicating a different conclusion. Can you please point me to such evidence indicating "entities operating leg= ally are willing to use this approach"? Can you please indicate which existing requirements defined for the existin= g 3GPP solution you believe are not necessary in your solution, when deploy= ed by an operator with a license to use the licensed GSM bands? If no such = unnecessary requirement is identified, your solution will end up with the s= ame complexity as the existing 3GPP solution. You stated "But more typically carriers with spectrum licenses are looking = for an economical way to get into rural areas.". Can you please provide an= y numbers or other justification proving that your proposal is more economi= cal than the existing 3GPP solution which is already developed, tested, mas= s produced and mass deployed and thus benefits from economies of scale? Note that there is no preclusion in the existing 3GPP solution to provide o= ne node encompassing BSC, MSC, HSS, SM-SC, ... so if that was considered us= eful, it could have been done with the existing 3GPP solution too. @Samra: > I have to ask...why are the questions regarding frequency licensing and e= conomics relevant? This is a discussion regrading augmenting SIP. The point is to identify whether there is a relevant business case for the = solution augmenting SIP. If there is none, why to spend meeting time and ef= fort to standardize the solution? Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B31079006101126623BBESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Jin and Samra,

 

@Jin:

 

> > E.g. can you please clarify whe= ther you indent to specify a solution for:

> >a) carriers with license to use = the licensed GSM bands?

>

> Yes.

>

> > b) individuals/corporates witho= ut license to use the licensed GSM bands?

>

> No.

 

OK, thanks for clarificatio= n.

 

> > Or do you believe that some e= xisting requirements are unnecessary for deployments in carrier networks?

>

> Evidence indicates entities operating legally a= re willing to use this approach.  I don't know the definition of a car= rier,

> or if that's relevant in this forum.   You= probably see other evidence indicating a different conclusion.<= /p>

 

Can you please point me to = such evidence indicating "entities operating legally are willin= g to use this approach"?

 

Can you please indicate whi= ch existing requirements defined for the existing 3GPP solution you believe= are not necessary in your solution, when deployed by an operator with a license to use the licensed GSM bands? If no such unnecess= ary requirement is identified, your solution will end up with the same comp= lexity as the existing 3GPP solution.

 

You stated "But= more typically carriers with spectrum licenses are looking for an economic= al way to get into rural areas.".  Can you please provide any numbers or other justification proving that you= r proposal is more economical than the existing 3GPP solution which is alre= ady developed, tested, mass produced and mass deployed and thus benefits fr= om economies of scale?

 

Note that there is no precl= usion in the existing 3GPP solution to provide one node encompassing BSC, M= SC, HSS, SM-SC, ... so if that was considered useful, it could have been done with the existing 3GPP solution too.

 

 

@Samra:

 

> I have to ask…why are the ques= tions regarding frequency licensing and economics relevant?  This is a= discussion regrading augmenting SIP.

 

The point is to identify wh= ether there is a relevant business case for the solution augmenting SIP. If there is= none, why to spend meeting time and effort to standardize the solution?

 

Kind regards

 

Ivo Sedlacek

 

--_000_39B5E4D390E9BD4890E2B31079006101126623BBESESSMB301erics_-- From ivo.sedlacek@ericsson.com Thu Feb 13 07:05:22 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BD91A0246 for ; Thu, 13 Feb 2014 07:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.24 X-Spam-Level: X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tzyv4VtW_ZN for ; Thu, 13 Feb 2014 07:05:20 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id C02941A01F1 for ; Thu, 13 Feb 2014 07:05:19 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-0b-52fcdf2ddd14 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 78.CD.04853.D2FDCF25; Thu, 13 Feb 2014 16:05:17 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.164]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 16:05:16 +0100 From: Ivo Sedlacek To: Jim Forster , "DRAGE, Keith (Keith)" Thread-Topic: [dispatch] Email ettiquette Thread-Index: AQHPKKuuzEvQFiVrp0+c5r0/+Awx/JqzPjyAgAADTICAAAaWoA== Date: Thu, 13 Feb 2014 15:05:16 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101126623FD@ESESSMB301.ericsson.se> References: <949EF20990823C4C85C18D59AA11AD8B1319A7@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B6412BF-FAB6-433E-8275-453C785248FF@rangenetworks.com> In-Reply-To: <2B6412BF-FAB6-433E-8275-453C785248FF@rangenetworks.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+Jvja7u/T9BBh9axCyWTlrAavHg/CE2 i6eNZxkdmD1an+1l9Viy5CeTx5mT6QHMUVw2Kak5mWWpRfp2CVwZk5fdZyv4KlaxZEJUA+M9 oS5GTg4JAROJK7d3MkPYYhIX7q1n62Lk4hASOMEoMfnkdyhnCaPEl+4dLCBVbAJ6EhO3HGEF sUUEsiSa77xgB7GZBbQl/l9fxwhiCwtoSMzdvowNokZTYsfXiYwQtpPEr1lXwOIsAqoSy079 BrI5OHgFfCUOH0+C2HWWUeL41ItMIDWcAq4S8w/3g9mMArISV//0MkLsEpe49WQ+E8TVAhJL 9pyH+kBU4uXjf6wQtpLEiu2XoOr1JG5MncIGc+eyha/B6nkFBCVOznzCMoFRbBaSsbOQtMxC 0jILScsCRpZVjJLFqcXFuelGBnq56bkleqlFmcnFxfl5esWpmxiBkXVwy2+jHYwn99gfYpTm YFES573OWhMkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVE3hdn5b0Cq+5/Jl0zfP+3lm1lz IXV2++Vunaetudb7g9akKAuVzTey1D8kY7Jzfpzm2tvZi9WTr26fdPWIzvNvC0/drDmhv/Z6 gee/BfblvTcc1p/8F/iiMtrWZc+C2sSdRw70L70klbT0WncCu8Ztpx7pxw83hn4R27wi2UD9 suAcP70FdkFKLMUZiYZazEXFiQBddhytegIAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Email ettiquette X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:05:22 -0000 Hello Jin, I resent the mail again without the final line. Feel free to work with this= version. Kind regards Ivo Sedlacek -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Jim Forster Sent: 13. =FAnora 2014 15:40 To: DRAGE, Keith (Keith) Cc: dispatch@ietf.org Subject: Re: [dispatch] Email ettiquette Keith, I fully well understand the difficulties of large companies and their IT de= partments and policies, and I agree about the desirability of clearly ident= ifying affiliations. Still, I would ask for some positive affirmation, ideally from your corpora= te legal department (:-)), or at least from the WG chairs, that Ericksson's= policy, as referenced in your message, is conformant to the IETF policies,= or null and void somehow.=20 Personally, I can take your word in good faith, but procedurally I would th= ink some more formalism is appropriate for the WG group and IETF. Sigh...Thanks, -- Jim PS: Your recent message doesn't have the worrisome statement. Phew! I was= going ask how can you guys communicate when everything you say is supposed= to be confidential :-) On Feb 13, 2014, at 9:27 PM, DRAGE, Keith (Keith) wrote: > While these signature lines are undesirable, and some people don't have a= ny choice in having them there, apart from using a non-company email addres= s. I personally prefer that people participating on behalf of their company= use the company email address. In any case, please note the following: >=20 > 1) If it is Ivo's mail you are referring to, then it does not forbid repl= ying. Further it states "unauthorised" (see 2 below). You are a member of t= he WG and it is addressed to the WG. >=20 > 2) A long time ago I raised this issue on the WG chairs list, and the ans= wer I was given was that the contract you make (the Note well) when you sig= n up to the mailing list overrides all such statements. >=20 > Regards >=20 > Keith >=20 >=20 >=20 >> -----Original Message----- >> From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Tim=20 >> Panton new >> Sent: 13 February 2014 11:07 >> To: dispatch@ietf.org >> Subject: [dispatch] Email ettiquette >>=20 >> If ( hypothetically ) an email were to be sent to this list=20 >> containing a disclaimer expressly forbidding a reply or disclosure,=20 >> would it be concidered impolite to ignore it? >>=20 >> Tim. >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From peter.dunkley@crocodilertc.net Thu Feb 13 07:12:51 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542101A0209 for ; Thu, 13 Feb 2014 07:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.922 X-Spam-Level: X-Spam-Status: No, score=0.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ip583gOYqFrR for ; Thu, 13 Feb 2014 07:12:47 -0800 (PST) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 7333D1A02AA for ; Thu, 13 Feb 2014 07:12:41 -0800 (PST) Received: by mail-vc0-f173.google.com with SMTP id ld13so8126443vcb.4 for ; Thu, 13 Feb 2014 07:12:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FztiiCIS5CnqMUBjw9NGozSCDaybmFYRzR5bS02TDac=; b=iI5L/d0ITynnhJ4JF9P887mvDZ3gqeU+EevuxAWqvZl/S7INbjhEFPW1ChDFAhy0KK XnKZIApU0uE3s7k3H5mxMkM8XpOOanh3qTzZnXMxNO9BtMHB23e8YHCZ8+mqz9PH3Ga2 +BxgZBUNM+Tv2fEIvp3B51GM7x11ckhEj3Slk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FztiiCIS5CnqMUBjw9NGozSCDaybmFYRzR5bS02TDac=; b=Wczow1NIDe6vrAS7YnewRa3ARsGy+6D1Te3QyBYlSt7YxjXExDuNA6MoODzQN3ofyF QvnJ8xOXeOG6WrXSosisBR2CheXdeBzSs1XSovHjVG27uhCy0RCNp3IHg9nUrQps2dE2 0AnjPZcBaW7OliKCn/1hwNuSCvUdrxRXlhp73A9/D4HpyJrkWvW/C0qfEze4oziv42q5 T2MOBNB9cFtNAuV3vz+qoex0KduNsh0aQiGUQ79eNQhcgSAk1oiB9ZCSiRuwj/OqbSco iYff/s57EOkERXBWs4ndvemJ+H8N92s3LPgnXz9fMFq1KsfpMa2Svi2TtO3s2lFddOVZ cLBQ== X-Gm-Message-State: ALoCoQkzIOfRmM0Q3IRmZbDhI9qfUnfmsTN9w33ApQ1SdfikspV1BSFl7MOhgTp5abWZUa0C99ht MIME-Version: 1.0 X-Received: by 10.58.172.132 with SMTP id bc4mr329728vec.45.1392304359937; Thu, 13 Feb 2014 07:12:39 -0800 (PST) Received: by 10.58.187.114 with HTTP; Thu, 13 Feb 2014 07:12:39 -0800 (PST) In-Reply-To: <5F44E887-4513-46DF-9C05-8C68F54842B8@nostrum.com> References: <5F44E887-4513-46DF-9C05-8C68F54842B8@nostrum.com> Date: Thu, 13 Feb 2014 15:12:39 +0000 Message-ID: From: Peter Dunkley To: Ben Campbell Content-Type: multipart/alternative; boundary=047d7b5db9c4cb2daf04f24b1ead Cc: DISPATCH , "draft-pd-dispatch-msrp-websocket.all@tools.ietf.org" , "rai@ietf.org" Subject: Re: [dispatch] MSRP Expert Review of draft-pd-dispatch-msrp-websocket-04 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:12:51 -0000 --047d7b5db9c4cb2daf04f24b1ead Content-Type: text/plain; charset=ISO-8859-1 Hello, Thank you for the review it was very much appreciated, and sorry it has taken so long to respond. These and other comments made on the list have been considered and a new version of the document has been published: http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-05 I have included some specific responses to each of your comments below. Thanks again, Peter On 11 January 2014 06:01, Ben Campbell wrote: > I'd like to see more detail on the expected support (and behavior) for a > WebSocket MSRP Relay when dealing with 4975/4976 clients and relays. For > example, would it be acceptable to build a WebSocket MSRP Relay that would > only talk to WebSocket clients, and not support "legacy" MSRP relays and > clients at all? Since this draft introduces some new rules on chunk sizes, > how would a WebSocket MSRP relay handle it if a "legacy" peer did not > follow them? > This document is mainly about adding support for a new MSRP transport (WebSockets) as per section 6 of RFC 4975, and updating the procedures from RFC4976 to reflect that authentication MAY happen differently with WebSockets. I don't believe the rules on chunk sizes have changed as the rules for chunking in RFC 4975 just use the term "very large" and aren't specific at all, and RFC 4976 indicates that relays are allowed to re-chunk. This document doesn't currently deal with MSRP over WebSocket servers that are not relays (the CEMA scenario). There is a TODO for Christer Hormberg to come up with some words describing this scenario, but for now this is out-of-scope. > The security considerations section needs considerably more meat. I'd like > to see a discussion of the security implications of downgrading the 4976 > MUST requirement for TLS between a client and a server, as well as the use > of the MSRPS scheme if the WebSocket connection is not protected. It would be worth a discussion of any other TLS requirements that differ > between MSRP/WebSocket and 4975/4976. For example, are the certificate > matching rules the same for WebSocket as for MSRP/TLS? Is there any > requirement that the domain names match between the WebSocket and MSRP > layers? (i.e. could I authenticate as example.com, but except traffic for > example.net?) >From higher level perspective, does the use of WebSocket introduce > potential web oriented vunerabilities that native MSRP wouldn't have? > (e.g., sidejacking of authentication cookies over non-protected > connections?) The loosing of the security requirements from RFC4976 has now been removed. Discussion on list appears to have reached the conclusion that the security provided by secure WebSockets is sufficient to meet the requirements of RFC4976. The authors of the document do not believe that any new vulnerabilities have been added by this work and the text of the document has been updated to reflect this. > specific comments: -- Abstract and Introduction: The idea that WebSocket enables communication between clients and servers > needs a bit more context. One assumes that clients and servers could talk > to each other before the advent of WebSocket. When does it make sense to > use MSRP/WebSocket rather than MSRP/TLS or MSRP/TCP? Additional context has been added to the text of the document. -- section 1, last bullet: This point needs more context. The need to apply policy to a messages is > already one of the justifications for 4976. Likewise, MSRP using SIP > already offers varying degrees of authentication. How is the need for these > things different in the WebSockets context? I don't believe there is anything different here in the WebSocket context. This text is informative and intended to provide some context for the reader of the document. > --3 I am not happy with the downgrade of of the TLS requirement between client > and relay. I recognize that WebSocket This has been removed. > -- 4.2: MSRP only allows a "binary" transfer encoding. I'm not sure it makes sense > to use text frames, even for text content. If text frames are allowed, do > you need to verify that only text-based content-types are negotiated at the > signaling layer? Does introduce a mapping requirement for WebSocket relays, > for example if a WebSocket client sends text frames towards a "legacy" > peer? Some additional text has been added to the document to clarify this point. > -- 5.1, 1st paragraph: Is it impossible to have an MSRP _client_ implemented on a WebSocket > _server_? (For example, an robot endpoint for human-to-machine or > machine-to-machine communication?) This document doesn't currently deal with MSRP over WebSocket servers that are not relays (for example, the CEMA scenario). There is no reason why you couldn't have an MSRP client on a WebSocket server but this is out-of-scope for this document. > -- 5.1, last paragraph: Can you offer guidance on a reasonable or maximum chunk size? It may be > worth suggesting a minimum size beneath which MSRP messages should not be > chunked. Can a MSRP chunk in a WebSocket frame be interrupted? (I note the > examples have interruptible chunks.) I think that this is very implementation (WebSocket client/server) and application specific. I don't think guidance is particularly helpful here. > nit: Indented paragraphs are usually considered parenthetical explanations. > It's generally not a good idea to put 2119 normative language in them. -- 5.2.1: Is there ever a need to map between MSRP URIs and HTTP URIs? Is a WebSocket > MSRP client expected to always connect to it's own server, or would it ever > connect to a WebSocket server that it learned about in the offer/answer? > (e.g a WebSocket server acting on behalf of the peer?) Is there any > requirement that the MSRP URI domain name matches the HTTP domain name in > any way? (In particular, can a server that presented a TLS cert for one or > more domains accept MSRP URIs for a domain that was not included in the > cert?) I don't believe there is any need to map between MSRP URIs and HTTP URIs. I believe that a WebSocket MSRP client will always connect to it's own server in the same way that an MSRP client will always connect to it's own relay. > -- 5.3.1: It seems ambiguous when you allow the connection to be authenticated at the > WebSocket layer whether the AUTH request is still required. I assume it is, > since all the examples use it. But it's not clear to me from the language > in this section. The AUTH request is required to establish the connection (at the MSRP layer) between the client and server. The Use-Path: header returned in the 200 OK to the AUTH is required for the SDP offer/answer. The text in the document has been updated to clarify this. > -- 5.3.2: This issue has given me heartburn for WebSocket in general. It's not as big > of an issue for protocols that do not have MUST level requirements for TLS. > But I really don't like downgrading a security related MUST from 4976. As I > mentioned above, if we are going to do so, we need a thorough discussion of > the security implications. (For example, do we introduce a requirement to > ensure MSRPS URLs are never used for unprotected links? Do we need to worry > about "legacy" endpoint users that assume that the peer's client to relay > connection is always protected? It seems like we should have some general IETF policy on this, as I'm sure > MSRP is not the first place it has come up. But in general, while I am > sensitive to "existing code" or "API" limitations preventing some > requirements from being MUSTs, I am personally less sympathetic when it > means downgrading an already existing security requirement. The downgrading of security has been removed. > -- 6, last paragraph: Seems lile they also need to be prepared to receive bodiless SEND > keep-alives from the peer, especially from legacy peers. This was implicitly allowed as nothing in the document had removed this capability from RFC4975. The text has been updated to make it explicit. > -- 7: Is there any requirent (in WebSockets or otherwise) that authentication > cookies only be tranferred over protected connections? Does this introduce > a sidejacking attack into MSRP? The downgrading of security has been removed. Only secure WebSocket (over TLS) connections are permitted. > -- 7, last paragraph: " ... authentication MAY be requested at MSRP > protocol level." Who can request it? Just the client by sending an AUTH? (Still not clear if > AUTH is expected when authenticating at the WebSocket layer.) Also, you > might consider avoiding 2119 language in a section marked as > "non-normative". The MSRP relay that is a WebSocket server can request it by sending a 401 to the AUTH. The text of the document has been updated to make this clear. > -- 8: I'd like to see an example with authentication included. It would also be > good to see an example where the peer has it's own relay. These have been added. > All the examples assume default settings for the Failure-Report and > Success-Report header fields. There's no other mention of them. Does > anything change with those as a result of using WebSocket? Use of the WebSocket transport makes no change here. > -- 8.4: Does this not still assume the offer/answer exchange from the previous > example? Why not include the "bob -> alice" message in the previous > example? (Or are we assuming Bob initiated the session negotiation this > time?) The example has been updated to make this clear. -- Peter Dunkley Technical Director Crocodile RCS Ltd --047d7b5db9c4cb2daf04f24b1ead Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

Thank you for the review= it was very much appreciated, and sorry it has taken so long to respond.

These and other comments made on the list have been con= sidered and a new version of the document has been published:=A0http://tool= s.ietf.org/html/draft-pd-dispatch-msrp-websocket-05

I have included some specific responses to each of your= comments below.

Thanks again,

Peter


On 11 January 2014 06:01, Be= n Campbell=A0<ben@nostrum.com>=A0wrote:=A0
I'd like to see more detail on the expected support (a= nd behavior) for a WebSocket MSRP Relay when dealing with 4975/4976 clients= and relays. For example, would it be acceptable to build a WebSocket MSRP = Relay that would only talk to WebSocket clients, and not support "lega= cy" MSRP relays and clients at all? Since this draft introduces some n= ew rules on chunk sizes, how would a WebSocket MSRP relay handle it if a &q= uot;legacy" peer did not follow them?

This document is mainly about adding support for a new MS= RP transport (WebSockets) as per section 6 of RFC 4975, and updating the pr= ocedures from RFC4976 to reflect that authentication MAY happen differently= with WebSockets. =A0I don't believe the rules on chunk sizes have chan= ged as the rules for chunking in RFC 4975 just use the term "very larg= e" and aren't specific at all, and RFC 4976 indicates that relays = are allowed to re-chunk.

This document doesn= 9;t currently deal with MSRP over WebSocket servers that are not relays (th= e CEMA scenario). =A0There is a TODO for Christer Hormberg to come up with = some words describing this scenario, but for now this is out-of-scope.
=A0
The security considerations section needs considerably more meat. I'd l= ike to see a discussion of the security implications of downgrading the 497= 6 MUST requirement for TLS between a client and a server, as well as the us= e of the MSRPS scheme if the WebSocket connection is not protected.=A0
=A0
It would be worth a discussion of any other TLS requirements that differ be= tween MSRP/WebSocket and 4975/4976. For example, are the certificate matchi= ng rules the same for WebSocket as for MSRP/TLS? Is there any requirement t= hat the domain names match between the WebSocket and MSRP layers? (i.e. cou= ld I authenticate as=A0ex= ample.com, but except traffic for=A0example.net?)=A0
=A0
>From higher level perspective, does the use of WebSocket introduce potentia= l web oriented vunerabilities that native MSRP wouldn't have? (e.g., si= dejacking of authentication cookies over non-protected connections?)=A0
=A0

The loosing of the security requirements from RFC4976 has now been removed.= Discussion on list appears to have reached the conclusion that the securit= y provided by secure WebSockets is sufficient to meet the requirements of R= FC4976.

The authors of the doc= ument do not believe that any new vulnerabilities have been added by this w= ork and the text of the document has been updated to reflect this.
=A0
specific comments:=A0
=A0
-- Abstract and Introduction:=A0
=A0
The idea that WebSocket enables communication between clients and servers n= eeds a bit more context. One assumes that clients and servers could talk to= each other before the advent of WebSocket. When does it make sense to use = MSRP/WebSocket rather than MSRP/TLS or MSRP/TCP?=A0
=A0
Additional context has been added to the text of the document.

<= /div>
=A0
-- section 1, last bullet:=A0
=
=A0
This point needs more context. The need to= apply policy to a messages is already one of the justifications for 4976. = Likewise, MSRP using SIP already offers varying degrees of authentication. = How is the need for these things different in the WebSockets context?=A0
=A0
I don't believe there is anything different here in the WebSocket conte= xt. =A0This text is informative and intended to provide some context for th= e reader of the document.
=A0
--3=A0
=A0
I am not happy with the downgrade of of th= e TLS requirement between client and relay. I recognize that WebSocket=A0
=A0
This has been removed.
=A0
-- 4.2:=A0
=A0
MSRP only allows a "binary" transfer encoding. I'm not sure i= t makes sense to use text frames, even for text content. If text frames are= allowed, do you need to verify that only text-based content-types are nego= tiated at the signaling layer? Does introduce a mapping requirement for Web= Socket relays, for example if a WebSocket client sends text frames towards = a "legacy" peer?=A0
=A0
Some additional text has been added to the document to clarify this point.<= /div>
=A0
=A0
-- 5.1, 1st paragraph:=A0
=A0
Is it impossible to have an MSRP _client_ = implemented on a WebSocket _server_? (For example, an robot endpoint for hu= man-to-machine or machine-to-machine communication?)=A0
=A0
This document doesn't currently deal with MSRP over WebSocket servers t= hat are not relays (for example, the CEMA scenario). =A0There is no reason = why you couldn't have an MSRP client on a WebSocket server but this is = out-of-scope for this document.
=A0
-- 5.1, last paragraph:=A0
=A0
Can you offer guidance on a reasonable or maximum chunk size? It may be wor= th suggesting a minimum size beneath which MSRP messages should not be chun= ked. Can a MSRP chunk in a WebSocket frame be interrupted? (I note the exam= ples have interruptible chunks.)=A0
=A0
I think that this is very implementation (WebSocket client/server) and appl= ication specific. I don't think guidance is particularly helpful here.<= /div>
=A0
=A0
nit: Indented paragraphs are usually considered parenthetical explanations.= It's generally not a good idea to put 2119 normative language in them.= =A0
=A0
-- 5.2.1:=A0
=A0
Is there ever a need to map between MSRP U= RIs and HTTP URIs? Is a WebSocket MSRP client expected to always connect to= it's own server, or would it ever connect to a WebSocket server that i= t learned about in the offer/answer? (e.g a WebSocket server acting on beha= lf of the peer?) Is there any requirement that the MSRP URI domain name mat= ches the HTTP domain name in any way? (In particular, can a server that pre= sented a TLS cert for one or more domains accept MSRP URIs for a domain tha= t was not included in the cert?)=A0
=A0
I don't believe there is any need to map between MSRP URIs and HTTP URI= s.

I believe that= a WebSocket MSRP client will always connect to it's own server in the = same way that an MSRP client will always connect to it's own relay.
=A0
=A0
-- 5.3.1:=A0
=A0
It seems ambiguous when you allow the conn= ection to be authenticated at the WebSocket layer whether the AUTH request = is still required. I assume it is, since all the examples use it. But it= 9;s not clear to me from the language in this section.=A0
=A0
The AUTH request is required to establish the connection (at the MSRP layer= ) between the client and server. =A0The Use-Path: header returned in the 20= 0 OK to the AUTH is required for the SDP offer/answer.

The te= xt in the document has been updated to clarify this.

= =A0
-- 5.3.2:=A0
=A0
This issue has given me heartburn for WebS= ocket in general. It's not as big of an issue for protocols that do not= have MUST level requirements for TLS. But I really don't like downgrad= ing a security related MUST from 4976. As I mentioned above, if we are goin= g to do so, we need a thorough discussion of the security implications. (Fo= r example, do we introduce a requirement to ensure MSRPS URLs are never use= d for unprotected links? Do we need to worry about "legacy" endpo= int users that assume that the peer's client to relay connection is alw= ays protected?=A0
=A0
It seems like we should have some general IETF policy on this, as I'm s= ure MSRP is not the first place it has come up. But in general, while I am = sensitive to "existing code" or "API" limitations preve= nting some requirements from being MUSTs, I am personally less sympathetic = when it means downgrading an already existing security requirement.=A0
=A0
The downgrading of security has been removed.
=A0
-- 6, last paragraph:=A0
=A0
Seems lile they also need to be prepared to receive bodiless SEND keep-aliv= es =A0from the peer, especially from legacy peers.=A0 =A0
This was implicitly allowed as nothing in the document had removed th= is capability from RFC4975. =A0The text has been updated to make it explici= t.
=A0
-- 7:=A0
=A0
Is there any requirent (in WebSockets or otherwise) that authentication coo= kies only be tranferred over protected connections? Does this introduce a s= idejacking attack into MSRP?=A0
=A0
The downgrading of security has been removed. =A0Only secure WebSocke= t (over TLS) connections are permitted.
=A0
-- 7, last paragraph: " ... authenticat= ion MAY be requested at MSRP protocol level."=A0
=A0
Who can request it? Just the client by sending an AUTH? (Still not clear if= AUTH is expected when authenticating at the WebSocket layer.) Also, you mi= ght consider avoiding 2119 language in a section marked as "non-normat= ive".=A0
=A0
The MSRP relay that is a WebSocket server can request it by sending a 401 t= o the AUTH. =A0The text of the document has been updated to make this clear= .
=A0
-- 8:=A0
=A0
I'd like to see an example with authen= tication included. It would also be good to see an example where the peer h= as it's own relay.=A0
=A0
These have been added.
=A0
=A0
All the examples assume default settings f= or the Failure-Report and Success-Report header fields. There's no othe= r mention of them. Does anything change with those as a result of using Web= Socket?=A0
=A0
Use of the WebSocket transport makes no change here.
=A0
-- 8.4:=A0
=A0
Does this not still assume the offer/answer exchange from the previous exam= ple? Why not include the "bob -> alice" message in the previou= s example? (Or are we assuming Bob initiated the session negotiation this t= ime?)=A0
=A0
The example has been updated to make this clear.


--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
--047d7b5db9c4cb2daf04f24b1ead-- From peter.dunkley@crocodilertc.net Thu Feb 13 07:14:48 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9535F1A01F1 for ; Thu, 13 Feb 2014 07:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOPuPgbOmPck for ; Thu, 13 Feb 2014 07:14:46 -0800 (PST) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 74BB51A008E for ; Thu, 13 Feb 2014 07:14:46 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id lh14so8132611vcb.24 for ; Thu, 13 Feb 2014 07:14:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZiOEAo0dRJfjTLzcyqNoJA2udPO4NVf/PlDBu9siMiM=; b=MQCIEXTsZnM6THyelSc1aBzH3720PnHzulC2toqOeIRTjgBC/SiWEGECPN6Y9MqtaO ttw42Wk/OZ2OOqZik9f/EH0f6UJCIyQjC0mkM6wrLFN3y/mG1CSlCmSWG/VsPgBhe+Q7 CsmEnPb5IRFMbU+ZrexRlHCMYQ7ao/bw7rvlM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ZiOEAo0dRJfjTLzcyqNoJA2udPO4NVf/PlDBu9siMiM=; b=jiy404tynswDZsme4EsBlCk3pmQ2QEp2K6PhV/7UveyfEp3/iuJFAPsRxqjc9Xq63I uoYdkZwk2W9+G+UD1aX3MOEzeztEjODI6/nRGeQbnbQTF3MDP1T5p7OTWXml/zq5ITfH r1CXFodd0iy+QvZUR6+kQ+KW0NfeqQsVaMKTSz5aJRygiCxfbnw3abwX/918MCZSKic0 q9rED8ThFxcuIS3lyYq9OnhBCcba7J70X81marbmtbEI4yBdTsvN2sxYz3Fxe4rXjTrP fQBD+dVH6DBubtwGc+6HDkzP97YeTMbTWYeBTLyiWX65puH2zMzH+rgjR2f9d/6tIa49 yUkA== X-Gm-Message-State: ALoCoQlrCZQY3KH66SxzHzycVTNUWzLYS8DiJvDo5SwpFmao4RFO4+q0agYvAJYqeSfb3WnTzZjg MIME-Version: 1.0 X-Received: by 10.220.192.71 with SMTP id dp7mr379521vcb.45.1392304484949; Thu, 13 Feb 2014 07:14:44 -0800 (PST) Received: by 10.58.187.114 with HTTP; Thu, 13 Feb 2014 07:14:44 -0800 (PST) In-Reply-To: <20140213150710.22467.74553.idtracker@ietfa.amsl.com> References: <20140213150710.22467.74553.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 15:14:44 +0000 Message-ID: From: Peter Dunkley To: "dispatch@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5d2aa23eb8dc04f24b26b9 Subject: [dispatch] Fwd: I-D Action: draft-pd-dispatch-msrp-websocket-05.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:14:48 -0000 --047d7b5d2aa23eb8dc04f24b26b9 Content-Type: text/plain; charset=ISO-8859-1 Hello, This document has been updated based on recent feedback on-list and various review comments. Regards, Peter ---------- Forwarded message ---------- From: Date: 13 February 2014 15:07 Subject: I-D Action: draft-pd-dispatch-msrp-websocket-05.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP) Authors : Peter Dunkley Gavin Llewellyn Victor Pascual Anton Roman Gonzalo Salgueiro Filename : draft-pd-dispatch-msrp-websocket-05.txt Pages : 30 Date : 2014-02-13 Abstract: The WebSocket protocol enables two-way real-time communication between clients and servers in situations where direct access to TCP and UDP are not available (for example, from within Javascript in a web browser). This document specifies a new WebSocket sub-protocol as a reliable transport mechanism between MSRP (Message Session Relay Protocol) clients and relays to enable usage of MSRP in new scenarios. This document normatively updates RFC 4975 and RFC 4976. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-pd-dispatch-msrp-websocket/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-pd-dispatch-msrp-websocket-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-pd-dispatch-msrp-websocket-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt -- Peter Dunkley Technical Director Crocodile RCS Ltd --047d7b5d2aa23eb8dc04f24b26b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

This document has been updated b= ased on recent feedback on-list and various review comments.

=
Regards,

Peter

---------- Forwarded message ----------
From: <= internet-drafts@ietf.org>
Date: 13 February 2014 15:07
= Subject: I-D Action: draft-pd-dispatch-msrp-websocket-05.txt
To: i-d-announce@ietf.org
<= br>

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : The WebSocket Protocol as a Tra= nsport for the Message Session Relay Protocol (MSRP)
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Peter Dunkley
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gavin Llewellyn
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Victor Pascual
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Anton Roman
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Gonzalo Salgueiro
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-pd-dispatch-msrp-websocket-= 05.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 30
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-02-13

Abstract:
=A0 =A0The WebSocket protocol enables two-way real-time communication
=A0 =A0between clients and servers in situations where direct access to TCP=
=A0 =A0and UDP are not available (for example, from within Javascript in a<= br> =A0 =A0web browser). =A0This document specifies a new WebSocket sub-protoco= l
=A0 =A0as a reliable transport mechanism between MSRP (Message Session Rela= y
=A0 =A0Protocol) clients and relays to enable usage of MSRP in new
=A0 =A0scenarios. =A0This document normatively updates RFC 4975 and RFC 497= 6.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-pd-dispatch-ms= rp-websocket/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-pd-dispatch-msrp-websock= et-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-pd-dispa= tch-msrp-websocket-05


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

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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d= -announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt



--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
--047d7b5d2aa23eb8dc04f24b26b9-- From gsalguei@cisco.com Thu Feb 13 07:17:53 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DBFA1A02BC for ; Thu, 13 Feb 2014 07:17:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.049 X-Spam-Level: X-Spam-Status: No, score=-10.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKcnExCaxD16 for ; Thu, 13 Feb 2014 07:17:49 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id B06471A01F1 for ; Thu, 13 Feb 2014 07:17:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1775; q=dns/txt; s=iport; t=1392304663; x=1393514263; h=from:to:cc:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=vR5ddpuvqbKqfarNlBQt3Lte1n7JDn+nYNLM+ACOTBA=; b=D94NpmBIR19lKbNSuFoLzf2H/TO+bz4ZdaHb9GmXV7w6OONEQtDdn15J KUmnFsQr9NNLZsjeVSdV3WuTK4Hzwi5+2DbRtriXeWaXfXzCeIjk7Eyex i+yKEfiX7tkdheR2Ie6+TM3uTc1bLKCA/QizS/WCHnsmnOV6Iso/Qo815 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FAHzh/FKtJXHB/2dsb2JhbABZgwaBD79MgRcWdIIlAQEBAwE6MQ4FCwIBCDYQIRElAgQOBYdxAwkIv0ENiDwXjF+BZzODK4EUBJZAgWyMXoVFgy2CKg X-IronPort-AV: E=Sophos;i="4.95,839,1384300800"; d="scan'208";a="20193132" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by alln-iport-8.cisco.com with ESMTP; 13 Feb 2014 15:17:43 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id s1DFHhps016558 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 15:17:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.213]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 09:17:43 -0600 From: "Gonzalo Salgueiro (gsalguei)" To: Mary Barnes Thread-Topic: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt Thread-Index: AQHPKM69Gzr1Sxm0FkKTa2Dy1OUwAA== Date: Thu, 13 Feb 2014 15:17:42 +0000 Message-ID: <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.57] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Ben Campbell , DISPATCH , "draft-pd-dispatch-msrp-websocket@tools.ietf.org" Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:17:54 -0000 Hi Mary -=20 Thanks for taking the time to review the document. We have published an -0= 5 that (hopefully) addresses all your feedback. =20 Inline, trimming to only the points requiring responses... On Jan 10, 2014, at 5:58 PM, Mary Barnes wrote= : > I have agreed to shepherd this document. I've reviewed the document in a= nticipation of doing the PROTO write-up and have the following comments and= questions. Ben Campbell has agreed to do the required expert review and t= hat should be posted within the next week or so. This is also a good tim= e for anyone in the WG that hasn't previously reviewed this document to rev= iew and provide any final comments. Note, that this document was agreed to= be AD sponsored around the IETF-86 timeframe. >=20 > Regards, > Mary.=20 >=20 > Review Summary: Almost ready. Comments & questions below. > 5) Section 10.1. Since securing the connection is just RECOMMENDED, what = are the implications and risks if the MSRP traffic isn't transported over a= secure connection?=20 Other review comments indicated that it was problematic to downgrade the 49= 76 MUST requirement for TLS between a client and a server. Thus, the docume= nt has been updated so that MSRP traffic transported over WebSockets MUST b= e protected by using a secure WebSocket connection (i.e., using TLS). I be= lieve this renders this point moot. > 8) It's typical for documents that are updating existing RFCs to have a s= ection that summarizes the updates to the existing RFCs that are made by th= is document. =20 This was the intent of Sections 5.2 and 5.3. Is this sufficient? Or did yo= u have something else in mind? Regards, Gonzalo From keith.drage@alcatel-lucent.com Thu Feb 13 07:28:46 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43BE1A02DC for ; Thu, 13 Feb 2014 07:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmA_Fqx4LyfA for ; Thu, 13 Feb 2014 07:28:44 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id E60151A02D7 for ; Thu, 13 Feb 2014 07:28:43 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1DFSdBc027731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Feb 2014 09:28:40 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1DFScGF025275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 16:28:38 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Thu, 13 Feb 2014 16:28:38 +0100 From: "DRAGE, Keith (Keith)" To: Tim Panton new Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIIAAPqkAgAASvbD///eJAIAAMB4ggAFh0ACAAXHr6IABHNuAgAAqBACAADBv4P//9IUAgAAUl7A= Date: Thu, 13 Feb 2014 15:28:37 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B131BEF@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.c! om> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00361BF0-F6B9-48DD-80A6-CECD0A7C0A3B@westhawk.co.uk> In-Reply-To: <00361BF0-F6B9-48DD-80A6-CECD0A7C0A3B@westhawk.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B131BEFFR712WXCHMBA11zeu_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:28:47 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B131BEFFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ericsson is not the only vendor that sees a market for small cells, but the= expectation is that the products are built to the completed 3GPP standards= will be deployed in licensed spectrum by owners of that spectrum, although= the boxes may well be owned by 3rd parties. These deployments already exist. I see Jim has now identified that this proposal is for licensed GSM operato= rs in licensed GSM space. Personally, I would suggest if you believe the operators should be picking = this up, you take it to 3GPP where the operators are actually present. That= is the only way you will see it taken up by GSMA, which you will need to o= btain interoperator agreements to use this (e.g. roaming, shared networks).= 3GPP them works with IETF on any SIP extensions needed. I would only see IETF having any direct part in this if the proposal was on= ly to use unlicensed spectrum by enterprises rather than licensed operators= , which Jim has negated. regards Keith ________________________________ From: Tim Panton new [mailto:thp@westhawk.co.uk] Sent: 13 February 2014 14:50 To: DRAGE, Keith (Keith) Cc: Harvind Samra; Ivo Sedlacek; dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) > wrote: Jumping in here, they are relevant in as much as there is no point in IETF = working on this if there is no known market for it. Usually those type of projects are published only on April 1st. So all Ivo is asking is for you to justify that it is worth other people wo= rking on this as well as yourselves. Perhaps if you identified the spectrum you believe is available for use in = the the countries identified, that would be useful. regards Keith Drage Ivo's employer seems to see a market for small cells, but looks to tie them= to existing operator IMS's through internet connections "owned by themselves or a partner". http://www.telecomlead.com/enterprise-networking/mwc-2014-ericsson-announce= -small-cell-service-20233/ Perhaps that's an April fools joke too (I can't see any avian carriers ment= ioned though)? It isn't up to the IETF to crown specific solutions. That's the market's jo= b. T. --_000_949EF20990823C4C85C18D59AA11AD8B131BEFFR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Ericsson is not the only vendor t= hat sees a market for small cells, but the expectation is that the products= are built to the completed 3GPP standards will be deployed in licensed spectrum by owners of that spectrum, although the = boxes may well be owned by 3rd parties.
<= span class=3D"502110315-13022014"> 
These deployments already exist.<= /font>
 
I see Jim has now identified that= this proposal is for licensed GSM operators in licensed GSM space.<= /span>
 
Personally, I would suggest if yo= u believe the operators should be picking this up, you take it to 3GPP wher= e the operators are actually present. That is the only way you will see it taken up by GSMA, which you will need to obta= in interoperator agreements to use this (e.g. roaming, shared networks). 3G= PP them works with IETF on any SIP extensions needed.
 
I would only see IETF having any = direct part in this if the proposal was only to use unlicensed spectrum by = enterprises rather than licensed operators, which Jim has negated.
 
regards
 
Keith

From: Tim Panton new [mailto:thp@we= sthawk.co.uk]
Sent: 13 February 2014 14:50
To: DRAGE, Keith (Keith)
Cc: Harvind Samra; Ivo Sedlacek; dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS


On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote= :

Jumping in here, they are relevan= t in as much as there is no point in IETF working on this if there is no kn= own market for it.
 
Usually those type of projects ar= e published only on April 1st.
 
So all Ivo is asking is for you t= o justify that it is worth other people working on this as well as yourselv= es.
 
Perhaps if you identified the spe= ctrum you believe is available for use in the the countries identified, tha= t would be useful.
 
regards
 
Keith Drage

Ivo's employer seems to see a market for small cells, but looks to tie= them to existing operator IMS's through 
internet connections "owned by themselves or a partner".
http://www.telecomlead.com/ente= rprise-networking/mwc-2014-ericsson-announce-small-cell-service-20233/<= /div>
Perhaps that's an April fools joke too (I can't see any avian carriers= mentioned though)?

It isn't up to the IETF to crown specific solutions. That's the market= 's job.

T.



--_000_949EF20990823C4C85C18D59AA11AD8B131BEFFR712WXCHMBA11zeu_-- From ralph@schmid.xxx Thu Feb 13 07:29:48 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FC51A0215 for ; Thu, 13 Feb 2014 07:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.549 X-Spam-Level: X-Spam-Status: No, score=-0.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iaf7A9Ly5cxz for ; Thu, 13 Feb 2014 07:29:42 -0800 (PST) Received: from smtp03.udag.de (smtp03.udag.de [62.146.106.29]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8BE1A020D for ; Thu, 13 Feb 2014 07:29:42 -0800 (PST) Received: from RSold (p57AF396D.dip0.t-ipconnect.de [87.175.57.109]) by smtp03.udag.de (Postfix) with ESMTPA id AE5349FB2A; Thu, 13 Feb 2014 16:29:39 +0100 (CET) From: "Ralph A. Schmid, dk5ras" To: "'DRAGE, Keith \(Keith\)'" , "'Harvind Samra'" , "'Ivo Sedlacek'" References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 13 Feb 2014 16:28:23 +0100 Message-ID: <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B9_01CF28D8.9E02E2F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQNPugcZyd0Y0xi19Wfg+5nisdnbrQGRK6jCAbpbpFsAwcWeSQNJa3XQAjv6wk0Cx63icQKQ+SrbAaUjvSQBfpHUPQGLVnIOAotbsMUCKkJVaAF79nXqAoEkzbMC6rYFkAHC1FZqATtkheYCEkpN9QI0B9+dAhh4I88CI/jTTpZcV1Ng Content-Language: de Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:29:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B9_01CF28D8.9E02E2F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I see the purpose of such systems in not-so-developed countries, and especially in very remote areas of those. Usually the commercial providers have no interest in covering those, as there is no revenue from doing so, and especially in such countries often the government is not willing to force operators to cover an area, and/or they are not willing/able to enforce such a rule. So imagine a village, a few hundred people living there, most of them owning mobile phones for communication when they travel to the town for work or for trading goods - but at home those phones are useless. Now there are two possibilities - the government does not care about licenses, or they give a license to operate a local network. This is not our problem here, we are techs, no bureaucrats. So somebody is able to spent a few thousand dollars, puts an antenna onto some tree, flips the switch, and a few hundred phones can (and do) log on. Very nice, people can call each other, can call the doctor when they are ill and injured, the system runs locally just fine. Now more and more of those low-cost networks grow up, and people want to connect them. Internet is available in some places, cheap to buy and install WiFi-links are established, the whole thing evolves, some simple structure grows. This is the time were some standards are needed. Open standards, cheap standards, not a 3GPP IMS monster. We are not talking here about a nice and clean data center with racks full of BSCs, MSCs and all that, we are talking about simple to maintain structures. It must be some technology a normal computer guy everywhere in the world can understand after reading some manuals. SIP family of procedures was chosen. As far as I understand (don't blame when I'm wrong, I'm RF engineer, not a SIP guy) at the moment the possible procedures are not standardized, some extensions or modifications need to be defined, for being able to cope with this kind of mobility (handover etc.) and distributed network control. This is the scope of this mail thread. Such systems like described above are not dreams, such systems do exist, they bring a large benefit to those people, micro economics evolve, emergency communication is established, social interaction is improved. Now imagine an earthquake or a similar catastrophe - the almost non-existent infrastructure breaks down completely. Emergency teams show up, have no oversight what is happening. But hey, they unload some boxes on top of a hill, fire up their BTS, link it to the headquarter, many phones log into the system, and people can call for assistance, can tell what kind of help is needed in what place, first responder teams can be sent to those places. No fancy and shiny business, just live saving communication somewhere out in the mud and dirt. Normal phone companies do not do this kind of work, but someone needs to. IETF may be a small gear that makes this thing move a bit smoother - it is already moving, that is for sure, with or without IETF :-) But I may be wrong...then just hit the DEL-button. Ralph. From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Thursday, February 13, 2014 3:34 PM To: Harvind Samra; Ivo Sedlacek Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS Jumping in here, they are relevant in as much as there is no point in IETF working on this if there is no known market for it. Usually those type of projects are published only on April 1st. So all Ivo is asking is for you to justify that it is worth other people working on this as well as yourselves. Perhaps if you identified the spectrum you believe is available for use in the the countries identified, that would be useful. regards Keith Drage _____ From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Harvind Samra Sent: 13 February 2014 12:37 To: Ivo Sedlacek Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS Hi Ivo, I have to ask.why are the questions regarding frequency licensing and economics relevant? This is a discussion regrading augmenting SIP. On Feb 13, 2014, at 2:06 AM, Ivo Sedlacek wrote: Hello Tim and all, if I understood the proposal correctly, in comparison to 3GPP architecture you propose: - UEs are unchanged - BTS - uses regular Um reference point towards UEs - has a new SIP based interface replacing ABis reference point - BSC, MSC, HSS, SM-SC, ... collapse into one functional entity "SAS/Asterisk/SMQueue". This new functional entity: - uses the new SIP based interface replacing ABis reference point towards BTS - uses another SIP based interface towards remote networks Can you please clarify what's the intended business case where the proposed solution is supposed to be superior over the existing 3GPP solution? E.g. can you please clarify whether you indent to specify a solution for: a) carriers with license to use the licensed GSM bands? b) individuals/corporates without license to use the licensed GSM bands? c) anyone else? The original mail suggested b) but then you referred to a) in your mail stating "But more typically carriers with spectrum licenses are looking for an economical way to get into rural areas." If a), such solution can be deployed anywhere where there are existing GSM bands in use. However, it will likely require implementation of the full 3GPP feature set which carriers offer today, including supporting regulator's requirements, support of handovers, integration with other operator subsystems (e.g. billing, operation & maintenance subsystems, ...). Or do you believe that some existing requirements are unnecessary for deployments in carrier networks? You seem to claim above that your proposal can be more economical than existing solution. Given that new protocol would need to be defined and functional entities newly developed and tested, I fail to see how this can be more economical than deployment of existing products which are already developed, tested, mass produced and mass deployed. Can you provide some numbers supporting your view? https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/hei murl just proposes new functionality to be added, unrelated to any potential replacement of ABis reference point with SIP based interface. If b), then such solution can be deployed only in countries where there is no license needed. You list Sweden as one with UK and Netherlands with question marks. Also Antarctica was mentioned. Can you please provide a reference to regulators' document enabling usage of GSM bands without license in each of those countries? How will interferences be avoided if several individuals/corporates start using the same GSM band in the same location, particularly if each starts using power enabling "potential 20 mile radius even for a single cell"? Furthermore, even if all of Sweden, UK, Netherlands and Antarctica enable usage of GSM bands without license, this is still quite limited market. If the solution is limited only to those countries, even if the required feature set is smaller, there is little economies of scale. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch Harvind Samra Founder, CTO Range Networks San Francisco, CA ____________________________________________ Cellular networks made simple and affordable. http://www.rangenetworks.com ____________________________________________ ------=_NextPart_000_00B9_01CF28D8.9E02E2F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I see the purpose of such systems in not-so-developed countries, and = especially in very remote areas of those.

 

Usually the commercial providers have no interest in covering those, = as there is no revenue from doing so, and

especially in such countries often the government is not willing to = force operators to cover an area, and/or they

are not willing/able to enforce such a rule.

 

So imagine a village, a few hundred people living there, most of them = owning mobile phones for communication

when they travel to the town for work or for trading goods – = but at home those phones are useless.

 

Now there are two possibilities – the government does not care = about licenses, or they give a license to operate =

a local network. This is not our problem here, we are techs, no = bureaucrats.

 

So somebody is able to spent a few thousand dollars, puts an antenna = onto some tree, flips the switch, and

a few hundred phones can (and do) log on.

 

Very nice, people can call each other, can call the doctor when they = are ill and injured, the system runs locally

just fine.

 

Now more and more of those low-cost networks grow up, and people want = to connect them. Internet is available

in some places, cheap to buy and install WiFi-links are established, = the whole thing evolves, some simple

structure grows.

 

This is the time were some standards are needed. Open standards, = cheap standards, not a 3GPP IMS monster. We

are not talking here about a nice and clean data center with racks = full of BSCs, MSCs and all that, we are talking

about simple to maintain structures. It must be some technology a = normal computer guy everywhere in the world

can understand after reading some manuals. SIP family of procedures = was chosen.

 

As far as I understand (don’t blame when I’m wrong, = I’m RF engineer, not a SIP guy) at the moment the possible =  

procedures are not standardized, some extensions or modifications = need to be defined, for being able to cope

with this kind of mobility (handover etc.) and distributed network = control. This is the scope of this mail thread.

 

Such systems like described above are not dreams, such systems do = exist, they bring a large benefit to those

people, micro economics evolve, emergency communication is = established, social interaction is improved.

 

Now imagine an earthquake or a similar catastrophe – the almost = non-existent infrastructure breaks down

completely. Emergency teams show up, have no oversight what is = happening. But hey, they unload some

boxes on top of a hill, fire up their BTS, link it to the = headquarter, many phones log into the system, and =

people can call for assistance, can tell what kind of help is needed = in what place, first responder teams can

be sent to those places.

 

 

No fancy and shiny business, just live saving communication somewhere = out in the mud and dirt. Normal

phone companies do not do this kind of work, but someone needs to. = IETF may be a small gear that makes

this thing move a bit smoother – it is already moving, that is = for sure, with or without IETF  :-)

 

But I may be wrong...then just hit the = DEL-button.


Ralph.

 

 

 

 

From:= dispatch = [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith = (Keith)
S= ent: Thursday, February 13, 2014 3:34 PM
To: Harvind = Samra; Ivo Sedlacek
Cc: dispatch@ietf.org
Subject: = Re: [dispatch] SIP and GSM/UMTS with = OpenBTS

 

Ju= mping in here, they are relevant in as much as there is no point in IETF = working on this if there is no known market for = it.

 

Us= ually those type of projects are published only on April = 1st.

 

So= all Ivo is asking is for you to justify that it is worth other people = working on this as well as yourselves.

 

Pe= rhaps if you identified the spectrum you believe is available for use in = the the countries identified, that would be = useful.

 

re= gards

 

Ke= ith Drage

 

From:= dispatch = [mailto:dispatch-bounces@ietf.or= g] On Behalf Of Harvind Samra
Sent: 13 February = 2014 12:37
To: Ivo Sedlacek
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

Hi Ivo, =

 

I = have to ask…why are the questions regarding frequency licensing = and economics relevant?  This is a discussion regrading augmenting = SIP.

 

On = Feb 13, 2014, at 2:06 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com&g= t; wrote:



Hello Tim = and = all,           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;        

if I = understood the proposal correctly, in comparison to 3GPP architecture = you propose:

- UEs are = unchanged

- = BTS

  = ;            =   - uses regular Um reference point towards = UEs

  = ;            =   - has a new SIP based interface replacing ABis reference = point

- BSC, = MSC, HSS, SM-SC, ... collapse into one functional entity = "SAS/Asterisk/SMQueue". This new functional = entity:

  = ;            =   - uses the new SIP based interface replacing ABis reference point = towards BTS

  = ;            =   - uses another SIP based interface towards remote = networks

Can you = please clarify what's the intended business case where the proposed = solution is supposed to be superior over the existing 3GPP = solution?

E.g. can = you please clarify whether you indent to specify a solution = for:

a) = carriers with license to use the licensed GSM = bands?

b) = individuals/corporates without license to use the licensed GSM = bands?

c) anyone = else?

The = original mail suggested b) but then you referred to a) in your mail = stating "But more typically carriers with spectrum licenses are = looking for an economical way to get into rural = areas."

If a), = such solution can be deployed anywhere where there are existing GSM = bands in use. However, it will likely require implementation of the full = 3GPP feature set which carriers offer today, including supporting = regulator's requirements, support of handovers, integration with other = operator subsystems (e.g. billing, operation & maintenance = subsystems, ...). Or do you believe that some existing requirements are = unnecessary for deployments in carrier = networks?

You seem = to claim above that your proposal can be more economical than existing = solution. Given that new protocol would need to be defined and = functional entities newly developed and tested, I fail to see how this = can be more economical than deployment of existing products which are = already developed, tested, mass produced and mass deployed. Can you = provide some numbers supporting your = view?

https://www.usenix.org/conference/nsdi13/technical= -sessions/presentation/heimurl just proposes new = functionality to be added, unrelated to any potential replacement of = ABis reference point with SIP based = interface.

If b), = then such solution can be deployed only in countries where there is no = license needed. You list Sweden as one with UK and Netherlands with = question marks. Also Antarctica was = mentioned.

Can you = please provide a reference to regulators' document enabling usage of GSM = bands without license in each of those = countries?

How will = interferences be avoided if several individuals/corporates start using = the same GSM band in the same location, particularly if each starts = using power enabling "potential 20 mile radius even for a single = cell"?

Furthermore= , even if all of Sweden, UK, Netherlands and Antarctica enable usage of = GSM bands without license, this is still quite limited market. If the = solution is limited only to those countries, even if the required = feature set is smaller, there is little economies of = scale.

Kind = regards

Ivo = Sedlacek

This = Communication is Confidential. We only send and receive email on the = basis of the terms set out at www.ericsson.com/email_disclaimer<= /o:p>

__________= _____________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 

Harvind = Samra

Founder, = CTO

Range = Networks

San = Francisco, CA  

______________= ______________________________

 

Cellular = networks made simple and affordable. =  

______________= ______________________________

 

 

 

 

------=_NextPart_000_00B9_01CF28D8.9E02E2F0-- From sergio.garcia.murillo@gmail.com Thu Feb 13 07:39:02 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BB81A02B4 for ; Thu, 13 Feb 2014 07:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yctVbzWbuu5s for ; Thu, 13 Feb 2014 07:38:59 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F2BCA1A02E5 for ; Thu, 13 Feb 2014 07:38:55 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so8812448wib.0 for ; Thu, 13 Feb 2014 07:38:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=QkJDDDkXvrNWtFiLD+JhYbeacajHM0ArcJekjrKhPMk=; b=qg7gknVsfT4OvwsC9T4Sr8c+cF5IKivML0Y/85XLp+tTz90gxxtb+MHrWtiLfYHfj6 Ykejh1jr51FduZSp/IKgrrS/c4E6gbyJUzY/q0BmIjfLF86stX6npTTfj2ODC+rRKJc8 JshTDhrfC0qsQcG1RDUkztabnJaEeWYo35LWARjFkxQZlVXd63A55XNqb8Kmb1GUCneD VoBYoogl1g1YYctag/fljrFHjKQj6wg7lPDFz2WcHshR+rDS4boJQuxgguJWSmeTw1A/ PpAxHDtxDhRR6ZQsOCa7uGSGyrCi6XOn5z8MX4ynQR7yVsPnkNNuLh55GyzMHggbY0j6 9vQQ== X-Received: by 10.180.11.233 with SMTP id t9mr4314003wib.1.1392305934364; Thu, 13 Feb 2014 07:38:54 -0800 (PST) Received: from [192.168.1.66] (66.Red-79-154-146.dynamicIP.rima-tde.net. [79.154.146.66]) by mx.google.com with ESMTPSA id cm5sm6171004wid.5.2014.02.13.07.38.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 07:38:53 -0800 (PST) Message-ID: <52FCE70C.1030608@gmail.com> Date: Thu, 13 Feb 2014 16:38:52 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> In-Reply-To: <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:39:02 -0000 Hi, We also have recently published a different draft for BFCP over websockets: http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00 I beleive that we should harmonize who the WS transport is signaled and how to signal the WS version if also the "normal" TCP version is supported. In your case you seem to be using the same transport line TCP/MSRP and use the path to signal the ws part, in our case, we choose to signal it in the transport TCP/WS/BFCP and include a new attribute ws-uri to signal the full url (I could not reuse the path attribute as it is restricted to msrp urls only). Best regards Sergio El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribió: > Hi Mary - > > Thanks for taking the time to review the document. We have published an -05 that (hopefully) addresses all your feedback. > > Inline, trimming to only the points requiring responses... > > > On Jan 10, 2014, at 5:58 PM, Mary Barnes wrote: > >> I have agreed to shepherd this document. I've reviewed the document in anticipation of doing the PROTO write-up and have the following comments and questions. Ben Campbell has agreed to do the required expert review and that should be posted within the next week or so. This is also a good time for anyone in the WG that hasn't previously reviewed this document to review and provide any final comments. Note, that this document was agreed to be AD sponsored around the IETF-86 timeframe. >> >> Regards, >> Mary. >> >> Review Summary: Almost ready. Comments & questions below. > > >> 5) Section 10.1. Since securing the connection is just RECOMMENDED, what are the implications and risks if the MSRP traffic isn't transported over a secure connection? > Other review comments indicated that it was problematic to downgrade the 4976 MUST requirement for TLS between a client and a server. Thus, the document has been updated so that MSRP traffic transported over WebSockets MUST be protected by using a secure WebSocket connection (i.e., using TLS). I believe this renders this point moot. > > > >> 8) It's typical for documents that are updating existing RFCs to have a section that summarizes the updates to the existing RFCs that are made by this document. > This was the intent of Sections 5.2 and 5.3. Is this sufficient? Or did you have something else in mind? > > Regards, > > Gonzalo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From jim.forster@rangenetworks.com Thu Feb 13 07:41:18 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBF3C1A02AC for ; Thu, 13 Feb 2014 07:41:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ceFbPxaG3TAV for ; Thu, 13 Feb 2014 07:41:16 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0183.outbound.protection.outlook.com [207.46.163.183]) by ietfa.amsl.com (Postfix) with ESMTP id 206D51A01F7 for ; Thu, 13 Feb 2014 07:41:16 -0800 (PST) Received: from BL2PR03MB404.namprd03.prod.outlook.com (10.141.91.149) by BL2PR03MB402.namprd03.prod.outlook.com (10.141.91.146) with Microsoft SMTP Server (TLS) id 15.0.873.15; Thu, 13 Feb 2014 15:41:13 +0000 Received: from BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) by BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) with mapi id 15.00.0873.009; Thu, 13 Feb 2014 15:41:14 +0000 From: Jim Forster To: "DRAGE, Keith (Keith)" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIIAAT20AgAAEZwCAAAXeAIAAJYiAgAFsZwCAAWBU1IABLnGAgAAqBACAACCygIAABEMAgAAK7oCAAAOCgA== Date: Thu, 13 Feb 2014 15:41:12 +0000 Message-ID: <253F78CD-A217-4342-BEAA-FF31BF13419F@rangenetworks.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.c! om> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00361BF0-F6B9-48DD-80A6-CECD0A7C0A3B@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B131BEF@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B131BEF@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [202.145.4.186] x-forefront-prvs: 0121F24F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(6009001)(199002)(189002)(80022001)(87266001)(65816001)(74662001)(87936001)(83716003)(95666001)(2656002)(92726001)(92566001)(82746002)(56816005)(90146001)(83072002)(31966008)(85852003)(36756003)(76786001)(76796001)(81686001)(66066001)(81816001)(85306002)(47446002)(74502001)(69226001)(93136001)(561944002)(86362001)(16236675002)(95416001)(94316002)(79102001)(93516002)(74706001)(81542001)(53806001)(46102001)(54356001)(51856001)(56776001)(54316002)(76482001)(4396001)(49866001)(47736001)(50986001)(47976001)(74876001)(81342001)(59766001)(74366001)(94946001)(77982001)(33656001)(63696002)(80976001)(83322001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB402; H:BL2PR03MB404.namprd03.prod.outlook.com; CLIP:202.145.4.186; FPR:F7E7FA1D.ABF1FCE6.7BE393B2.44A5A821.201EC; InfoNoRecordsA:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_253F78CDA2174342BEAAFF31BF13419Frangenetworkscom_" MIME-Version: 1.0 X-OriginatorOrg: rangenetworks.com Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:41:18 -0000 --_000_253F78CDA2174342BEAAFF31BF13419Frangenetworkscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Keith, Responding only one part for a clarification; it's late here and I don't wa= nt make any more mistakes. I see Jim has now identified that this proposal is for licensed GSM operato= rs in licensed GSM space. And license-free space; see below. Personally, I would suggest if you believe the operators should be picking= this up, you take it to 3GPP where the operators are actually present. Tha= t is the only way you will see it taken up by GSMA, which you will need to = obtain interoperator agreements to use this (e.g. roaming, shared networks)= . 3GPP them works with IETF on any SIP extensions needed. I would only see IETF having any direct part in this if the proposal was on= ly to use unlicensed spectrum by enterprises rather than licensed operators= , which Jim has negated. OK, probably incorrectly, i read 'unlicensed' as ignoring licensing policy.= So to clarify: Licensed Spectrum -- Yes License free (ex-DECT Guard bands in Sweden, etc.) -- Yes Illegal -- No -- Jim --_000_253F78CDA2174342BEAAFF31BF13419Frangenetworkscom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Keith,

Responding only one part for a clarification; it's late here and I don= 't want make any more mistakes.

I see Jim has now identified that this proposal is for licensed G= SM operators in licensed GSM space.

And license-free space; see below.

 Personally, I would suggest if you believe = the operators should be picking this up, you take it to 3GPP where the operators are actually present. That is the only way = you will see it taken up by GSMA, which you will need to obtain interoperat= or agreements to use this (e.g. roaming, shared networks). 3GPP them works = with IETF on any SIP extensions needed.
 
I would only see IETF having any direct part in this if the propo= sal was only to use unlicensed spectrum by enterprises rather than licensed= operators, which Jim has negated.

OK, probably incorrectly, i read 'unlicensed' as ignoring licensing policy.=  So to clarify:

Licensed Spectrum  -- Yes

License free (ex-DECT Guard bands in Sweden, etc.)  -- Yes

Illegal -- No

  -- Jim

--_000_253F78CDA2174342BEAAFF31BF13419Frangenetworkscom_-- From mary.ietf.barnes@gmail.com Thu Feb 13 07:49:30 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D181A02D5 for ; Thu, 13 Feb 2014 07:49:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aKbNdWGwH9z for ; Thu, 13 Feb 2014 07:49:27 -0800 (PST) Received: from mail-yk0-x230.google.com (mail-yk0-x230.google.com [IPv6:2607:f8b0:4002:c07::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7641E1A020D for ; Thu, 13 Feb 2014 07:49:27 -0800 (PST) Received: by mail-yk0-f176.google.com with SMTP id 19so19709713ykq.7 for ; Thu, 13 Feb 2014 07:49:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HBlr/dIVlvhe2EsczEwI6LTW0+xPWM4//70kB5gu3ec=; b=Yd35u3zO/Lu4+XxbJYQgw5o5AGb6ts7260jxZzusPh5VSdrIlN5WJXLMowE5RO4ybN Cxg6ltwV7tUjOIiRAxHhGOBYiKYRFOiNmXqneT6EoNYTU3jauSkJix3b1nZjzUOTmbWi e2gxfZaJ3aZp4K3OwOE9DHSU5ldLSzBFmRoKvIbIUVQv5ayRCZIZJrf879v5OoKKL/b1 +VpNkUKUqxKcX9fXo/ewKNV/Fbc49Ui0/0uOtBQP2hp6R3tF6qEtThacyWWlu0j9Dwz2 aSOftjY23xpBA3jJAyH1JLODEGktBC32TGRFI/oEqWx7HBt3BHPwQ8nlOxJGV0uN6s6w 6xDA== MIME-Version: 1.0 X-Received: by 10.236.29.109 with SMTP id h73mr972955yha.131.1392306566219; Thu, 13 Feb 2014 07:49:26 -0800 (PST) Received: by 10.170.150.2 with HTTP; Thu, 13 Feb 2014 07:49:26 -0800 (PST) In-Reply-To: <52FCE70C.1030608@gmail.com> References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> Date: Thu, 13 Feb 2014 09:49:26 -0600 Message-ID: From: Mary Barnes To: Sergio Garcia Murillo Content-Type: multipart/alternative; boundary=089e0158ac764c4d1504f24ba243 Cc: DISPATCH Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:49:30 -0000 --089e0158ac764c4d1504f24ba243 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sergio, The draft you mention is being discussed in the BFCPBIS WG and any comments that others might have on that document should go to that list. It's not clear to me whether your suggestion is that changes are needed to this MSRP document or whether you are just proposing to make the BFCPBIS consistent with this MSRP document? Mary. On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > Hi, > > We also have recently published a different draft for BFCP over websocket= s: > http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00 > > I beleive that we should harmonize who the WS transport is signaled and > how to signal the WS version if also the "normal" TCP version is supporte= d. > > In your case you seem to be using the same transport line TCP/MSRP and us= e > the path to signal the ws part, in our case, we choose to signal it in th= e > transport TCP/WS/BFCP and include a new attribute ws-uri to signal the fu= ll > url (I could not reuse the path attribute as it is restricted to msrp url= s > only). > > Best regards > Sergio > El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribi=F3: > >> Hi Mary - >> >> Thanks for taking the time to review the document. We have published an >> -05 that (hopefully) addresses all your feedback. >> >> Inline, trimming to only the points requiring responses... >> >> >> On Jan 10, 2014, at 5:58 PM, Mary Barnes >> wrote: >> >> I have agreed to shepherd this document. I've reviewed the document in >>> anticipation of doing the PROTO write-up and have the following comment= s >>> and questions. Ben Campbell has agreed to do the required expert revie= w >>> and that should be posted within the next week or so. This is also a >>> good time for anyone in the WG that hasn't previously reviewed this >>> document to review and provide any final comments. Note, that this >>> document was agreed to be AD sponsored around the IETF-86 timeframe. >>> >>> Regards, >>> Mary. >>> >>> Review Summary: Almost ready. Comments & questions below. >>> >> >> >> 5) Section 10.1. Since securing the connection is just RECOMMENDED, wha= t >>> are the implications and risks if the MSRP traffic isn't transported ov= er a >>> secure connection? >>> >> Other review comments indicated that it was problematic to downgrade the >> 4976 MUST requirement for TLS between a client and a server. Thus, the >> document has been updated so that MSRP traffic transported over WebSocke= ts >> MUST be protected by using a secure WebSocket connection (i.e., using TL= S). >> I believe this renders this point moot. >> >> >> >> 8) It's typical for documents that are updating existing RFCs to have a >>> section that summarizes the updates to the existing RFCs that are made = by >>> this document. >>> >> This was the intent of Sections 5.2 and 5.3. Is this sufficient? Or did >> you have something else in mind? >> >> Regards, >> >> Gonzalo >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --089e0158ac764c4d1504f24ba243 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Sergio,

The draft you mention is being = discussed in the BFCPBIS WG and any comments that others might have on that= document should go to that list.

It's not cle= ar to me whether your suggestion is that changes are needed to this MSRP do= cument or whether you are just proposing to make the BFCPBIS consistent wit= h this MSRP document?=A0

Mary.=A0


=
On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia M= urillo <sergio.garcia.murillo@gmail.com> wrote= :
Hi,

We also have recently published a different draft for BFCP over websockets:=
http://tools.ietf.org/html/draft-pascual-bfcpb= is-bfcp-websocket-00

I beleive that we should harmonize who the WS transport is signaled and how= to signal the WS version if also the "normal" TCP version is sup= ported.

In your case you seem to be using the same transport line TCP/MSRP and use = the path to signal the ws part, in our case, we choose to signal it in the = transport TCP/WS/BFCP and include a new attribute ws-uri to signal the full= url (I could not reuse the path attribute as it is restricted to msrp urls= only).

Best regards
Sergio
El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribi=F3:
Hi Mary -

Thanks for taking the time to review the document. =A0We have published an = -05 that (hopefully) addresses all your feedback.

Inline, trimming to only the points requiring responses...


On Jan 10, 2014, at 5:58 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:=

I have agreed to shepherd this document. =A0I've reviewed the document = in anticipation of doing the PROTO write-up and have the following comments= and questions. =A0Ben Campbell has agreed to do the required expert review= and that should be posted within the next week or so. =A0 =A0This is also = a good time for anyone in the WG that hasn't previously reviewed this d= ocument to review and provide any final comments. =A0Note, that this docume= nt was agreed to be AD sponsored around the IETF-86 timeframe.

Regards,
Mary.

Review Summary: Almost ready. Comments & questions below.
<snip/>

5) Section 10.1. Since securing the connection is just RECOMMENDED, what ar= e the implications and risks if the MSRP traffic isn't transported over= a secure connection?
Other review comments indicated that it was problematic to downgrade the 49= 76 MUST requirement for TLS between a client and a server. Thus, the docume= nt has been updated so that MSRP traffic transported over WebSockets MUST b= e protected by using a secure WebSocket connection (i.e., using TLS). =A0I = believe this renders this point moot.

<snip/>

8) It's typical for documents that are updating existing RFCs to have a= section that summarizes the updates to the existing RFCs that are made by = this document.
This was the intent of Sections 5.2 and 5.3. =A0Is this sufficient? Or did = you have something else in mind?

Regards,

Gonzalo

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

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

--089e0158ac764c4d1504f24ba243-- From keith.drage@alcatel-lucent.com Thu Feb 13 08:00:37 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37161A02F7 for ; Thu, 13 Feb 2014 08:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwUTXlE1wF_s for ; Thu, 13 Feb 2014 08:00:30 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 120251A02A8 for ; Thu, 13 Feb 2014 08:00:30 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1DG0O7P013693 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 13 Feb 2014 10:00:25 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1DG0Nd1024610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Feb 2014 17:00:23 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Thu, 13 Feb 2014 17:00:23 +0100 From: "DRAGE, Keith (Keith)" To: "Ralph A. Schmid, dk5ras" , "'Harvind Samra'" , "'Ivo Sedlacek'" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIIAAPqkAgAASvbD///eJAIAAMB4ggAFh0ACAAXHr6IABHNuAgAAqBACAADBv4P///2KAgAAYwpA= Date: Thu, 13 Feb 2014 16:00:22 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B131C97@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.c! om> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> In-Reply-To: <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B131C97FR712WXCHMBA11zeu_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:00:37 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B131C97FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So you propose that IETF should write standards solely for an illegal activ= ity? One separate point I would make is that telecommunications represents a sig= nificant source of government income in 3rd world countries. Therefore any = such activities would be rapidly cracked down on. Keith ________________________________ From: Ralph A. Schmid, dk5ras [mailto:ralph@schmid.xxx] Sent: 13 February 2014 15:28 To: DRAGE, Keith (Keith); 'Harvind Samra'; 'Ivo Sedlacek' Cc: dispatch@ietf.org Subject: RE: [dispatch] SIP and GSM/UMTS with OpenBTS I see the purpose of such systems in not-so-developed countries, and especi= ally in very remote areas of those. Usually the commercial providers have no interest in covering those, as the= re is no revenue from doing so, and especially in such countries often the government is not willing to force o= perators to cover an area, and/or they are not willing/able to enforce such a rule. So imagine a village, a few hundred people living there, most of them ownin= g mobile phones for communication when they travel to the town for work or for trading goods - but at home th= ose phones are useless. Now there are two possibilities - the government does not care about licens= es, or they give a license to operate a local network. This is not our problem here, we are techs, no bureaucrats= . So somebody is able to spent a few thousand dollars, puts an antenna onto s= ome tree, flips the switch, and a few hundred phones can (and do) log on. Very nice, people can call each other, can call the doctor when they are il= l and injured, the system runs locally just fine. Now more and more of those low-cost networks grow up, and people want to co= nnect them. Internet is available in some places, cheap to buy and install WiFi-links are established, the wh= ole thing evolves, some simple structure grows. This is the time were some standards are needed. Open standards, cheap stan= dards, not a 3GPP IMS monster. We are not talking here about a nice and clean data center with racks full of = BSCs, MSCs and all that, we are talking about simple to maintain structures. It must be some technology a normal co= mputer guy everywhere in the world can understand after reading some manuals. SIP family of procedures was cho= sen. As far as I understand (don't blame when I'm wrong, I'm RF engineer, not a = SIP guy) at the moment the possible procedures are not standardized, some extensions or modifications need to b= e defined, for being able to cope with this kind of mobility (handover etc.) and distributed network control.= This is the scope of this mail thread. Such systems like described above are not dreams, such systems do exist, th= ey bring a large benefit to those people, micro economics evolve, emergency communication is established, soc= ial interaction is improved. Now imagine an earthquake or a similar catastrophe - the almost non-existen= t infrastructure breaks down completely. Emergency teams show up, have no oversight what is happening. B= ut hey, they unload some boxes on top of a hill, fire up their BTS, link it to the headquarter, many= phones log into the system, and people can call for assistance, can tell what kind of help is needed in wha= t place, first responder teams can be sent to those places. No fancy and shiny business, just live saving communication somewhere out i= n the mud and dirt. Normal phone companies do not do this kind of work, but someone needs to. IETF may= be a small gear that makes this thing move a bit smoother - it is already moving, that is for sure, wi= th or without IETF :-) But I may be wrong...then just hit the DEL-button. Ralph. From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith= (Keith) Sent: Thursday, February 13, 2014 3:34 PM To: Harvind Samra; Ivo Sedlacek Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS Jumping in here, they are relevant in as much as there is no point in IETF = working on this if there is no known market for it. Usually those type of projects are published only on April 1st. So all Ivo is asking is for you to justify that it is worth other people wo= rking on this as well as yourselves. Perhaps if you identified the spectrum you believe is available for use in = the the countries identified, that would be useful. regards Keith Drage ________________________________ From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Harvind Samr= a Sent: 13 February 2014 12:37 To: Ivo Sedlacek Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS Hi Ivo, I have to ask...why are the questions regarding frequency licensing and eco= nomics relevant? This is a discussion regrading augmenting SIP. On Feb 13, 2014, at 2:06 AM, Ivo Sedlacek > wrote: Hello Tim and all, if I understood the proposal correctly, in comparison to 3GPP architecture = you propose: - UEs are unchanged - BTS - uses regular Um reference point towards UEs - has a new SIP based interface replacing ABis reference po= int - BSC, MSC, HSS, SM-SC, ... collapse into one functional entity "SAS/Asteri= sk/SMQueue". This new functional entity: - uses the new SIP based interface replacing ABis reference= point towards BTS - uses another SIP based interface towards remote networks Can you please clarify what's the intended business case where the proposed= solution is supposed to be superior over the existing 3GPP solution? E.g. can you please clarify whether you indent to specify a solution for: a) carriers with license to use the licensed GSM bands? b) individuals/corporates without license to use the licensed GSM bands? c) anyone else? The original mail suggested b) but then you referred to a) in your mail sta= ting "But more typically carriers with spectrum licenses are looking for an= economical way to get into rural areas." If a), such solution can be deployed anywhere where there are existing GSM = bands in use. However, it will likely require implementation of the full 3G= PP feature set which carriers offer today, including supporting regulator's= requirements, support of handovers, integration with other operator subsys= tems (e.g. billing, operation & maintenance subsystems, ...). Or do you bel= ieve that some existing requirements are unnecessary for deployments in car= rier networks? You seem to claim above that your proposal can be more economical than exis= ting solution. Given that new protocol would need to be defined and functio= nal entities newly developed and tested, I fail to see how this can be more= economical than deployment of existing products which are already develope= d, tested, mass produced and mass deployed. Can you provide some numbers su= pporting your view? https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/he= imurl just proposes new functionality to be added, unrelated to any potenti= al replacement of ABis reference point with SIP based interface. If b), then such solution can be deployed only in countries where there is = no license needed. You list Sweden as one with UK and Netherlands with ques= tion marks. Also Antarctica was mentioned. Can you please provide a reference to regulators' document enabling usage o= f GSM bands without license in each of those countries? How will interferences be avoided if several individuals/corporates start u= sing the same GSM band in the same location, particularly if each starts us= ing power enabling "potential 20 mile radius even for a single cell"? Furthermore, even if all of Sweden, UK, Netherlands and Antarctica enable u= sage of GSM bands without license, this is still quite limited market. If t= he solution is limited only to those countries, even if the required featur= e set is smaller, there is little economies of scale. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch Harvind Samra Founder, CTO Range Networks San Francisco, CA ____________________________________________ Cellular networks made simple and affordable. http://www.rangenetworks.com ____________________________________________ --_000_949EF20990823C4C85C18D59AA11AD8B131C97FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
So you propose that IETF should w= rite standards solely for an illegal activity?
 
One separate point I would make i= s that telecommunications represents a significant source of government inc= ome in 3rd world countries. Therefore any such activities would be rapidly cracked down on.
 
Keith

From: Ralph A. Schmid, dk5ras [mail= to:ralph@schmid.xxx]
Sent: 13 February 2014 15:28
To: DRAGE, Keith (Keith); 'Harvind Samra'; 'Ivo Sedlacek'
Cc: dispatch@ietf.org
Subject: RE: [dispatch] SIP and GSM/UMTS with OpenBTS

I see the purpose of such s= ystems in not-so-developed countries, and especially in very remote areas o= f those.

 

Usually the commercial prov= iders have no interest in covering those, as there is no revenue from doing= so, and

especially in such countrie= s often the government is not willing to force operators to cover an area, = and/or they

are not willing/able to enf= orce such a rule.

 

So imagine a village, a few= hundred people living there, most of them owning mobile phones for communi= cation

when they travel to the tow= n for work or for trading goods – but at home those phones are useles= s.

 

Now there are two possibili= ties – the government does not care about licenses, or they give a li= cense to operate

a local network. This is no= t our problem here, we are techs, no bureaucrats.

 

So somebody is able to spen= t a few thousand dollars, puts an antenna onto some tree, flips the switch,= and

a few hundred phones can (a= nd do) log on.

 

Very nice, people can call = each other, can call the doctor when they are ill and injured, the system r= uns locally

just fine.

 

Now more and more of those = low-cost networks grow up, and people want to connect them. Internet is ava= ilable

in some places, cheap to bu= y and install WiFi-links are established, the whole thing evolves, some sim= ple

structure grows.

 

This is the time were some = standards are needed. Open standards, cheap standards, not a 3GPP IMS monst= er. We

are not talking here about = a nice and clean data center with racks full of BSCs, MSCs and all that, we= are talking

about simple to maintain st= ructures. It must be some technology a normal computer guy everywhere in th= e world

can understand after readin= g some manuals. SIP family of procedures was chosen.

 

As far as I understand (don= ’t blame when I’m wrong, I’m RF engineer, not a SIP guy) = at the moment the possible  

procedures are not standard= ized, some extensions or modifications need to be defined, for being able t= o cope

with this kind of mobility = (handover etc.) and distributed network control. This is the scope of this = mail thread.

 

Such systems like described= above are not dreams, such systems do exist, they bring a large benefit to= those

people, micro economics evo= lve, emergency communication is established, social interaction is improved= .

 

Now imagine an earthquake o= r a similar catastrophe – the almost non-existent infrastructure brea= ks down

completely. Emergency teams= show up, have no oversight what is happening. But hey, they unload some

boxes on top of a hill, fir= e up their BTS, link it to the headquarter, many phones log into the system= , and

people can call for assista= nce, can tell what kind of help is needed in what place, first responder te= ams can

be sent to those places.

 

 

No fancy and shiny business= , just live saving communication somewhere out in the mud and dirt. Normal

phone companies do not do t= his kind of work, but someone needs to. IETF may be a small gear that makes

this thing move a bit smoot= her – it is already moving, that is for sure, with or without IETF &n= bsp;:-)

 

But I may be wrong...then j= ust hit the DEL-button.


Ralph.

 

 

 

 

From: dispatch [mailto= :dispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: Thursday, February 13, 2014 3:34 PM
To: Harvind Samra; Ivo Sedlacek
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

 

Jumping in here, they are relevant in as much a= s there is no point in IETF working on this if there is no known market for= it.

 

Usually those type of projects are published on= ly on April 1st.

 

So all Ivo is asking is for you to justify that= it is worth other people working on this as well as yourselves.

 

Perhaps if you identified the spectrum you beli= eve is available for use in the the countries identified, that would be use= ful.

 

regards

 

Keith Drage

 

From: dispatch [mailto= :dispatch-bounces@ietf.org] On Behalf Of Harvind Samra
Sent: 13 February 2014 12:37
To: Ivo Sedlacek
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

Hi Ivo,

 

I have to ask…why are the questions regarding = frequency licensing and economics relevant?  This is a discussion regr= ading augmenting SIP.

 

On Feb 13, 2014, at 2:06 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wr= ote:



Hello Tim and all,    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;

if I understood the proposal correctly, in = comparison to 3GPP architecture you propose:

- UEs are unchanged

- BTS

       &= nbsp;        - uses regular Um reference= point towards UEs

       &= nbsp;        - has a new SIP based inter= face replacing ABis reference point

- BSC, MSC, HSS, SM-SC, ... collapse into o= ne functional entity "SAS/Asterisk/SMQueue". This new functional = entity:

       &= nbsp;        - uses the new SIP based in= terface replacing ABis reference point towards BTS

       &= nbsp;        - uses another SIP based in= terface towards remote networks

Can you please clarify what's the intended = business case where the proposed solution is supposed to be superior over t= he existing 3GPP solution?

E.g. can you please clarify whether you ind= ent to specify a solution for:

a) carriers with license to use the license= d GSM bands?

b) individuals/corporates without license t= o use the licensed GSM bands?

c) anyone else?

The original mail suggested b) but then you= referred to a) in your mail stating "But more typically carriers with= spectrum licenses are looking for an economical way to get into rural areas."

If a), such solution can be deployed anywhe= re where there are existing GSM bands in use. However, it will likely requi= re implementation of the full 3GPP feature set which carriers offer today, including supporting regulator's requireme= nts, support of handovers, integration with other operator subsystems (e.g.= billing, operation & maintenance subsystems, ...). Or do you believe t= hat some existing requirements are unnecessary for deployments in carrier networks?

You seem to claim above that your proposal = can be more economical than existing solution. Given that new protocol woul= d need to be defined and functional entities newly developed and tested, I fail to see how this can be more economical = than deployment of existing products which are already developed, tested, m= ass produced and mass deployed. Can you provide some numbers supporting you= r view?

https://www.usenix.org/conference/nsdi13/technical-sessions/presentati= on/heimurl jus= t proposes new functionality to be added, unrelated to any potential replace= ment of ABis reference point with SIP based interface.

If b), then such solution can be deployed o= nly in countries where there is no license needed. You list Sweden as one w= ith UK and Netherlands with question marks. Also Antarctica was mentioned.

Can you please provide a reference to regul= ators' document enabling usage of GSM bands without license in each of thos= e countries?

How will interferences be avoided if severa= l individuals/corporates start using the same GSM band in the same location= , particularly if each starts using power enabling "potential 20 mile radius even for a single cell"?=

Furthermore, even if all of Sweden, UK, Net= herlands and Antarctica enable usage of GSM bands without license, this is = still quite limited market. If the solution is limited only to those countries, even if the required feature set is sm= aller, there is little economies of scale.

Kind regards

Ivo Sedlacek

This Communication is Confidential. We only= send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaim= er

__________________________________________= _____
dispatch mailing list
dispatch= @ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

 

Harvind Samra

Founder, CTO

Range Networks

San Francisco, CA  

____________________________________________

 

Cellular networks made simple and affordable.  

____________________________________________

 

 

 

 

--_000_949EF20990823C4C85C18D59AA11AD8B131C97FR712WXCHMBA11zeu_-- From ivo.sedlacek@ericsson.com Thu Feb 13 08:01:04 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2ABB1A0306 for ; Thu, 13 Feb 2014 08:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWKOmZBg60XJ for ; Thu, 13 Feb 2014 08:01:01 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 324B41A030E for ; Thu, 13 Feb 2014 08:00:55 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-a9-52fcec358c68 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D4.B6.23809.53CECF25; Thu, 13 Feb 2014 17:00:53 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.164]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 17:00:52 +0100 From: Ivo Sedlacek To: Jim Forster , "DRAGE, Keith (Keith)" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIIAAT20AgAAEZwCAAAXeAIAAJYiAgAFsZwCAAWBU1IABLnGAgAAqBACAACCygIAABEMAgAAK7oCAAAOCgIAAAocA Date: Thu, 13 Feb 2014 16:00:52 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112662583@ESESSMB301.ericsson.se> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.c! om> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00361BF0-F6B9-48DD-80A6-CECD0A7C0A3B@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B131BEF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <253F78CD-A217-4342-BEAA-FF31BF13419F@rangenetworks.com> In-Reply-To: <253F78CD-A217-4342-BEAA-FF31BF13419F@rangenetworks.com> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B3107900610112662583ESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+Jvja7pmz9BBh8fyVgsnbSA1eLB+UNs Fk8bzzI6MHu0PtvL6rFkyU8mjzMn0wOYo7hsUlJzMstSi/TtErgyHi+cxl4wvaxiU+d/9gbG gxldjJwcEgImEoumr2eCsMUkLtxbz9bFyMUhJHCIUeLrntnsEM4SRol1Sw6CVbEJ6ElM3HKE FcQWEciSaL7zgh3EZhbQlvh/fR0jiC0sYCqxcmoLVI2ZxKRps5hBBokIXGKUeNp/jwUkwSKg KnHz8k5mEJtXwFfi9L0/rBDbZvFK9O7rAZvEKeAq8bDtL9gGRgFZiat/ehkhtolL3HoyH+pu AYkle84zQ9iiEi8f/2OFsJUkVmy/BFWfL9F07Cw7xDJBiZMzn7BMYBSdhWTULCRls5CUQcT1 JG5MncI2C+rRZQtfM0PYuhIz/h1iQRZfwMi+ipE9NzEzJ73caBMjMNYObvmtuoPxzjmRQ4zS HCxK4rwf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamD0ZjofH/n42LvXjyVERSQnxB7Y d0hg9XzPpYHfvFfYq/DY7+LleDbJZ8cKWX2xdD/NP22rf5zS/n9tZsjaQ/5Pziu77RMNVpUS a93s/XsvfxUjz10t0f8SHEf2xF7yirwscL5NsiFyxa6zlYH7lK/dslx/d518aZvju3+HuqOi ZV86TZ6dp/xBiaU4I9FQi7moOBEAc7xFF4MCAAA= Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:01:04 -0000 --_000_39B5E4D390E9BD4890E2B3107900610112662583ESESSMB301erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Jim, I am confused with your responses. Previously you stated to my question: > > E.g. can you please clarify whether you indent to specify a solution fo= r: > >a) carriers with license to use the licensed GSM bands? > > Yes. > > > b) individuals/corporates without license to use the licensed GSM bands= ? > > No. > > > c) anyone else? If your intention is to provide a solution for individuals/corporates to be= used in GSM bands where no license is needed, can you please answer the qu= estions below: Can you please provide a reference to regulators' document enabling usage o= f GSM bands without license in each of those countries where license is sup= posed to be not necessary? As far as I remember, you listed Sweden, UK with= question mark, Netherlands with question mark, and Antarctica was also men= tioned. I could have missed something. How will interferences be avoided if several individuals/corporates start u= sing the same GSM band in the same location, particularly if each starts us= ing power enabling "potential 20 mile radius even for a single cell"? Furthermore, even if all of Sweden, UK, Netherlands and Antarctica enable u= sage of GSM bands without license, this is still quite limited market. If t= he solution is limited only to those countries, even if the required featur= e set is smaller, there is little economies of scale. Kind regards Ivo Sedlacek From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Jim Forster Sent: 13. =FAnora 2014 16:41 To: DRAGE, Keith (Keith) Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS Keith, Responding only one part for a clarification; it's late here and I don't wa= nt make any more mistakes. I see Jim has now identified that this proposal is for licensed GSM operato= rs in licensed GSM space. And license-free space; see below. Personally, I would suggest if you believe the operators should be picking= this up, you take it to 3GPP where the operators are actually present. Tha= t is the only way you will see it taken up by GSMA, which you will need to = obtain interoperator agreements to use this (e.g. roaming, shared networks)= . 3GPP them works with IETF on any SIP extensions needed. I would only see IETF having any direct part in this if the proposal was on= ly to use unlicensed spectrum by enterprises rather than licensed operators= , which Jim has negated. OK, probably incorrectly, i read 'unlicensed' as ignoring licensing policy.= So to clarify: Licensed Spectrum -- Yes License free (ex-DECT Guard bands in Sweden, etc.) -- Yes Illegal -- No -- Jim --_000_39B5E4D390E9BD4890E2B3107900610112662583ESESSMB301erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Jim,

 

I am confused with your res= ponses.

 

Previously you stated to my= question:

 

> > E.g. can you please clarify whe= ther you indent to specify a solution for:

> >a) carriers with license to use the l= icensed GSM bands?

>

> Yes.

>

> > b) individuals/corporates without license to u= se the licensed GSM bands?

>

> No.

> 

> > c) anyone else?

 

 

If your intention is to pro= vide a solution for individuals/corporates to be used in GSM bands where no= license is needed, can you please answer the questions below:

 

Can you please provide a re= ference to regulators' document enabling usage of GSM bands without license= in each of those countries where license is supposed to be not necessary? As far as I remember, you listed Sweden, UK with questio= n mark, Netherlands with question mark, and Antarctica was also mentioned. = I could have missed something.

 

How will interferences be a= voided if several individuals/corporates start using the same GSM band in t= he same location, particularly if each starts using power enabling "potential 20 mile radius even for a single cell"?=

 

Furthermore, even if all of= Sweden, UK, Netherlands and Antarctica enable usage of GSM bands without l= icense, this is still quite limited market. If the solution is limited only to those countries, even if the required feature set is sm= aller, there is little economies of scale.

 

Kind regards

 

Ivo Sedlacek

 

From: dispatch= [mailto:dispatch-bounces@ietf.org] On Behalf Of Jim Forster
Sent: 13. =FAnora 2014 16:41
To: DRAGE, Keith (Keith)
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

 

Keith,

 

Responding only one part for a clarification; it's l= ate here and I don't want make any more mistakes.



I see Jim has now identified t= hat this proposal is for licensed GSM operators in licensed GSM space.

 

And license-free space; see below.



 Personally, I would= suggest if you believe the operators should be picking this up, you take i= t to 3GPP where the operators are actually present. That is the only way you will se= e it taken up by GSMA, which you will need to obtain interoperator agreemen= ts to use this (e.g. roaming, shared networks). 3GPP them works with IETF o= n any SIP extensions needed.

 

I would only see IETF having a= ny direct part in this if the proposal was only to use unlicensed spectrum = by enterprises rather than licensed operators, which Jim has negated.

 

OK, probably incorrectly, i read 'unlicensed' as ign= oring licensing policy.  So to clarify:

 

Licensed Spectrum  -- Yes

 

License free (ex-DECT Guard bands in Sweden, etc.) &= nbsp;-- Yes

 

Illegal -- No

 

  -- Jim

 

--_000_39B5E4D390E9BD4890E2B3107900610112662583ESESSMB301erics_-- From thp@westhawk.co.uk Thu Feb 13 08:03:58 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B8B1A02FC for ; Thu, 13 Feb 2014 08:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeYtNnwMrrUC for ; Thu, 13 Feb 2014 08:03:56 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id F28FE1A0319 for ; Thu, 13 Feb 2014 08:03:55 -0800 (PST) Received: (qmail 22408 invoked from network); 13 Feb 2014 16:03:54 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 12128 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 13 Feb 2014 16:03:54 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id E3FE618A03C8; Thu, 13 Feb 2014 16:03:53 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 8E67A18A034C; Thu, 13 Feb 2014 16:03:53 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_36CDAF9B-FCEF-4EF5-B4C1-B17082CF43FC" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton new In-Reply-To: <253F78CD-A217-4342-BEAA-FF31BF13419F@rangenetworks.com> Date: Thu, 13 Feb 2014 16:03:43 +0000 Message-Id: <986CABB0-D494-4B9F-8BF7-FA47B4B8F8AA@westhawk.co.uk> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.c! om> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00361BF0-F6B9-48DD-80A6-CECD0A7C0A3B@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B131BEF@FR712WXCHMBA11.zeu.alcatel-lucent.com> <253F78CD-A217-4342-BEAA-FF31BF13419F@rangenetworks.com> To: Jim Forster X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:03:58 -0000 --Apple-Mail=_36CDAF9B-FCEF-4EF5-B4C1-B17082CF43FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 13 Feb 2014, at 15:41, Jim Forster = wrote: > Keith, >=20 > Responding only one part for a clarification; it's late here and I = don't want make any more mistakes. >=20 >> I see Jim has now identified that this proposal is for licensed GSM = operators in licensed GSM space. >=20 > And license-free space; see below. >=20 >> Personally, I would suggest if you believe the operators should be = picking this up, you take it to 3GPP where the operators are actually = present. That is the only way you will see it taken up by GSMA, which = you will need to obtain interoperator agreements to use this (e.g. = roaming, shared networks). 3GPP them works with IETF on any SIP = extensions needed. >> =20 >> I would only see IETF having any direct part in this if the proposal = was only to use unlicensed spectrum by enterprises rather than licensed = operators, which Jim has negated. >=20 > OK, probably incorrectly, i read 'unlicensed' as ignoring licensing = policy. So to clarify: >=20 > Licensed Spectrum -- Yes >=20 > License free (ex-DECT Guard bands in Sweden, etc.) -- Yes >=20 > Illegal -- No >=20 > -- Jim >=20 The Um radio protocol depends on having a working spectrum policy that = isn't infringed. So it isn't possible to do a pure wifi-like collision avoidance trick. Unlicensed in this context is a dirty word. See=20 = http://babyis60.wordpress.com/2010/03/10/the-benefits-of-a-managed-spectru= m/ T.= --Apple-Mail=_36CDAF9B-FCEF-4EF5-B4C1-B17082CF43FC Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 13 Feb 2014, at 15:41, Jim Forster <jim.forster@rangenetworks.com> wrote:

Keith,

Responding only one part for a clarification; it's late here and I don't want make any more mistakes.

I see Jim has now identified that this proposal is for licensed GSM operators in licensed GSM space.

And license-free space; see below.

 Personally, I would suggest if you believe the operators should be picking this up, you take it to 3GPP where the operators are actually present. That is the only way you will see it taken up by GSMA, which you will need to obtain interoperator agreements to use this (e.g. roaming, shared networks). 3GPP them works with IETF on any SIP extensions needed.
 
I would only see IETF having any direct part in this if the proposal was only to use unlicensed spectrum by enterprises rather than licensed operators, which Jim has negated.

OK, probably incorrectly, i read 'unlicensed' as ignoring licensing policy.  So to clarify:

Licensed Spectrum  -- Yes

License free (ex-DECT Guard bands in Sweden, etc.)  -- Yes

Illegal -- No

  -- Jim


The Um radio protocol depends on having a working spectrum policy that isn't infringed. So it isn't possible to do a pure wifi-like
collision avoidance trick. Unlicensed in this context is a dirty word.

See 


T.
--Apple-Mail=_36CDAF9B-FCEF-4EF5-B4C1-B17082CF43FC-- From sergio.garcia.murillo@gmail.com Thu Feb 13 08:07:30 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E6C1A0327 for ; Thu, 13 Feb 2014 08:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0ovdMIBwCZ6 for ; Thu, 13 Feb 2014 08:07:27 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id DD4541A030E for ; Thu, 13 Feb 2014 08:07:26 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id vb8so12540450obc.32 for ; Thu, 13 Feb 2014 08:07:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rDg9seb6KRarESb+61vwuPJBDMqTZr884PMQWdgGpuY=; b=CfogtcRJKqaeiBuU3gPp6ZgE1dW+6VdSdvmdNpod9VmhMkNHlXGumTJ6+zRQB8MFYl pPqlXIN8197lXemcSiBKIihbwAu+FUUHxcBi9mg3nJZL4yaHrMjFOr/yOjG+z/PdDQJd I5tDbAqlWXmDbzNN+u2UdIgVWF0vxnoXxgZRZ2xRaucvqxiqM0RkZXeTlB489hqyIVe9 If0F84kEh67eQ5QTRvqPkXyA737mC6gqu5W+CxA3y1haAy3oXYnZe39XS5PkVinR7BgZ p6lzJA8WMo5TesMEgykaiikBTmo2gaXSaodu8h6DqSLRu8v5tF43zdFNp6cE5dDJiJBY DrTA== MIME-Version: 1.0 X-Received: by 10.60.246.139 with SMTP id xw11mr1942616oec.36.1392307645573; Thu, 13 Feb 2014 08:07:25 -0800 (PST) Received: by 10.182.12.99 with HTTP; Thu, 13 Feb 2014 08:07:25 -0800 (PST) Received: by 10.182.12.99 with HTTP; Thu, 13 Feb 2014 08:07:25 -0800 (PST) In-Reply-To: References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> Date: Thu, 13 Feb 2014 17:07:25 +0100 Message-ID: From: Sergio Garcia Murillo To: Mary Barnes Content-Type: multipart/alternative; boundary=001a113696c0a1f0d104f24be20b Cc: DISPATCH Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:07:30 -0000 --001a113696c0a1f0d104f24be20b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What I mean is that I expect quite a lot of "over websocekts" drafts and we should try to use the same solution for advertising it in the SDP, and not have each one have their own way of handling it. Best regards Sergio El 13/02/2014 16:49, "Mary Barnes" escribi=F3: > Sergio, > > The draft you mention is being discussed in the BFCPBIS WG and any > comments that others might have on that document should go to that list. > > It's not clear to me whether your suggestion is that changes are needed t= o > this MSRP document or whether you are just proposing to make the BFCPBIS > consistent with this MSRP document? > > Mary. > > > On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > >> Hi, >> >> We also have recently published a different draft for BFCP over >> websockets: >> http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00 >> >> I beleive that we should harmonize who the WS transport is signaled and >> how to signal the WS version if also the "normal" TCP version is support= ed. >> >> In your case you seem to be using the same transport line TCP/MSRP and >> use the path to signal the ws part, in our case, we choose to signal it = in >> the transport TCP/WS/BFCP and include a new attribute ws-uri to signal t= he >> full url (I could not reuse the path attribute as it is restricted to ms= rp >> urls only). >> >> Best regards >> Sergio >> El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribi=F3: >> >>> Hi Mary - >>> >>> Thanks for taking the time to review the document. We have published a= n >>> -05 that (hopefully) addresses all your feedback. >>> >>> Inline, trimming to only the points requiring responses... >>> >>> >>> On Jan 10, 2014, at 5:58 PM, Mary Barnes >>> wrote: >>> >>> I have agreed to shepherd this document. I've reviewed the document i= n >>>> anticipation of doing the PROTO write-up and have the following commen= ts >>>> and questions. Ben Campbell has agreed to do the required expert revi= ew >>>> and that should be posted within the next week or so. This is also = a >>>> good time for anyone in the WG that hasn't previously reviewed this >>>> document to review and provide any final comments. Note, that this >>>> document was agreed to be AD sponsored around the IETF-86 timeframe. >>>> >>>> Regards, >>>> Mary. >>>> >>>> Review Summary: Almost ready. Comments & questions below. >>>> >>> >>> >>> 5) Section 10.1. Since securing the connection is just RECOMMENDED, >>>> what are the implications and risks if the MSRP traffic isn't transpor= ted >>>> over a secure connection? >>>> >>> Other review comments indicated that it was problematic to downgrade th= e >>> 4976 MUST requirement for TLS between a client and a server. Thus, the >>> document has been updated so that MSRP traffic transported over WebSock= ets >>> MUST be protected by using a secure WebSocket connection (i.e., using T= LS). >>> I believe this renders this point moot. >>> >>> >>> >>> 8) It's typical for documents that are updating existing RFCs to have = a >>>> section that summarizes the updates to the existing RFCs that are made= by >>>> this document. >>>> >>> This was the intent of Sections 5.2 and 5.3. Is this sufficient? Or di= d >>> you have something else in mind? >>> >>> Regards, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > --001a113696c0a1f0d104f24be20b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

What I mean is that I expect quite a lot of "over webso= cekts" drafts and we should try to use the same solution for advertisi= ng it in the SDP, and not have each one have their own way of handling it.<= /p>

Best regards
Sergio

El 13/02/2014 16:49, "Mary Barnes" <= ;mary.ietf.barnes@gmail.com> escribi=F3:
Sergio,

The draft you mention is being = discussed in the BFCPBIS WG and any comments that others might have on that= document should go to that list.

It's not cle= ar to me whether your suggestion is that changes are needed to this MSRP do= cument or whether you are just proposing to make the BFCPBIS consistent wit= h this MSRP document?=A0

Mary.=A0


=
On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia M= urillo <sergio.garcia.murillo@gmail.com> wrote= :
Hi,

We also have recently published a different draft for BFCP over websockets:=
http://tools.ietf.org/html/draft-pascual-bfcpb= is-bfcp-websocket-00

I beleive that we should harmonize who the WS transport is signaled and how= to signal the WS version if also the "normal" TCP version is sup= ported.

In your case you seem to be using the same transport line TCP/MSRP and use = the path to signal the ws part, in our case, we choose to signal it in the = transport TCP/WS/BFCP and include a new attribute ws-uri to signal the full= url (I could not reuse the path attribute as it is restricted to msrp urls= only).

Best regards
Sergio
El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribi=F3:
Hi Mary -

Thanks for taking the time to review the document. =A0We have published an = -05 that (hopefully) addresses all your feedback.

Inline, trimming to only the points requiring responses...


On Jan 10, 2014, at 5:58 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:=

I have agreed to shepherd this document. =A0I've reviewed the document = in anticipation of doing the PROTO write-up and have the following comments= and questions. =A0Ben Campbell has agreed to do the required expert review= and that should be posted within the next week or so. =A0 =A0This is also = a good time for anyone in the WG that hasn't previously reviewed this d= ocument to review and provide any final comments. =A0Note, that this docume= nt was agreed to be AD sponsored around the IETF-86 timeframe.

Regards,
Mary.

Review Summary: Almost ready. Comments & questions below.
<snip/>

5) Section 10.1. Since securing the connection is just RECOMMENDED, what ar= e the implications and risks if the MSRP traffic isn't transported over= a secure connection?
Other review comments indicated that it was problematic to downgrade the 49= 76 MUST requirement for TLS between a client and a server. Thus, the docume= nt has been updated so that MSRP traffic transported over WebSockets MUST b= e protected by using a secure WebSocket connection (i.e., using TLS). =A0I = believe this renders this point moot.

<snip/>

8) It's typical for documents that are updating existing RFCs to have a= section that summarizes the updates to the existing RFCs that are made by = this document.
This was the intent of Sections 5.2 and 5.3. =A0Is this sufficient? Or did = you have something else in mind?

Regards,

Gonzalo

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

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

--001a113696c0a1f0d104f24be20b-- From thp@westhawk.co.uk Thu Feb 13 08:16:58 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB201A030A for ; Thu, 13 Feb 2014 08:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9DW-cd27-RE for ; Thu, 13 Feb 2014 08:16:53 -0800 (PST) Received: from smtp001.apm-internet.net (smtp001-out.apm-internet.net [85.119.248.222]) by ietfa.amsl.com (Postfix) with ESMTP id 490441A0307 for ; Thu, 13 Feb 2014 08:16:53 -0800 (PST) Received: (qmail 87854 invoked from network); 13 Feb 2014 16:16:51 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 12392 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp001.apm-internet.net with SMTP; 13 Feb 2014 16:16:51 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 57EE218A0B3B; Thu, 13 Feb 2014 16:16:51 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id 05AE618A0B37; Thu, 13 Feb 2014 16:16:50 +0000 (GMT) Content-Type: multipart/alternative; boundary="Apple-Mail=_A73C7FAB-84FC-4B90-B45C-3619EA2EAA68" Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton new In-Reply-To: <39B5E4D390E9BD4890E2B31079006101126623BB@ESESSMB301.ericsson.se> Date: Thu, 13 Feb 2014 16:16:41 +0000 Message-Id: References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <676E4A52-E702-43BE-9245-5CD558D69497@rangenetworks.com> <39B5E4D390E9BD4890E2B31079006101126623BB@ESESSMB301.ericsson.se> To: Ivo Sedlacek X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:16:59 -0000 --Apple-Mail=_A73C7FAB-84FC-4B90-B45C-3619EA2EAA68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 13 Feb 2014, at 15:00, Ivo Sedlacek = wrote: >=20 > > I have to ask=85why are the questions regarding frequency licensing = and economics relevant? This is a discussion regrading augmenting SIP. > =20 > The point is to identify whether there is a relevant business case for = the solution augmenting SIP. If there is none, why to spend meeting time = and effort to standardize the solution? > =20 It is unusual for the IETF to do a market analysis and business case = before even discussing a possible standard. I didn't see one about msrp-websocket for example. Tim.= --Apple-Mail=_A73C7FAB-84FC-4B90-B45C-3619EA2EAA68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 13 Feb 2014, at 15:00, Ivo Sedlacek = <ivo.sedlacek@ericsson.com>= ; wrote:


> I have to ask=85why are the questions regarding = frequency licensing and economics relevant?  This is a discussion = regrading augmenting SIP.
 
The point is to identify whether there is a = relevant business case for the solution augmenting = SIP. If there is none, why to = spend meeting time and effort to standardize the = solution?
 

It is = unusual for the IETF to do a market analysis and business case before = even discussing a possible standard.
I didn't see one about = msrp-websocket for = example.

Tim.
= --Apple-Mail=_A73C7FAB-84FC-4B90-B45C-3619EA2EAA68-- From peter.dunkley@crocodilertc.net Thu Feb 13 08:26:06 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70381A0301 for ; Thu, 13 Feb 2014 08:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQoVXx120h0t for ; Thu, 13 Feb 2014 08:26:04 -0800 (PST) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id F396F1A01EF for ; Thu, 13 Feb 2014 08:26:03 -0800 (PST) Received: by mail-vb0-f52.google.com with SMTP id p14so8108436vbm.25 for ; Thu, 13 Feb 2014 08:26:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HQDeAokWeHMEKH2IghqUMbIF2p1XpMQFWq+kyFXR/58=; b=evoJg7THYgJTKmzA5ln7WeLtNA8Bdb0Xw9iEeD3EzzKBwU/SLgZtLlqNNDjKbIQJM1 PCoiSDlSDZM6nodh28miRbsj5ltx2vHjRYG5XHmURi7wh9aOLnuYZe1dJlneDIE0Xzox +spHqXDFXPbJK2x5oEvLY2gSDCh8XumTOqxAA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HQDeAokWeHMEKH2IghqUMbIF2p1XpMQFWq+kyFXR/58=; b=bDVGpiL2UrZkK/VltHAlZA3OeAEW/Q75+nVyf6NZIxnqkSJDccuNJUhagbsJ/ypycv QM4IeFwEdz07Hdx/4tSHNJmknk/p44kQC1HGSkR7q/Q0LVWDfnoh3JU3u/Ydt9jw32Ks X9jnrPOW3CqCi6JOGdAAo03ZrH02NpwA7gd8w3KDH7hHPSYDafZY3UEQh0JCMAPn/Lkz yJ9d4PERbNRsVJyskWO7ozI8/QKbIOif1/j4Yr1/qkkGcHvSSXf7h71Z1jXaeym+xB4K a7G7dSn8uIsPTPgOXdZt0zuwLUCipVbL3TvceWJlOzgIDJSJvqxAfRq3cHotKq9i1wQQ vMog== X-Gm-Message-State: ALoCoQl0A+lgLp4cUqmYVjpjgkLbALIkztSma9SpnTOV/taZ7OFZAJ8DJjHNvgTs9vxD+jTWGCCD MIME-Version: 1.0 X-Received: by 10.52.121.113 with SMTP id lj17mr1238742vdb.21.1392308762398; Thu, 13 Feb 2014 08:26:02 -0800 (PST) Received: by 10.58.187.114 with HTTP; Thu, 13 Feb 2014 08:26:02 -0800 (PST) In-Reply-To: References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> Date: Thu, 13 Feb 2014 16:26:02 +0000 Message-ID: From: Peter Dunkley To: Sergio Garcia Murillo Content-Type: multipart/alternative; boundary=089e0122f1ca33673004f24c256f Cc: DISPATCH Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:26:07 -0000 --089e0122f1ca33673004f24c256f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, The method chosen for advertising WebSockets in the SDP for MSRP was picked because it was would enable interoperability with existing MSRP implementations through an MSRP relay without requiring changes to those implementations. In this scenario advertising WebSockets in the SDP would mean that the existing implementation - which does not need to support WebSockets (the MSRP relay deals with this) - would need to be able to cope with seeing TCP/WSS/MSRP in the SDP. In all probability existing implementations will not cope with seeing "TCP/WSS/MSRP" in the SDP instead of "TCP/TLS/MSRP" - this would be a big problem. I have no issue with consistency between the drafts using WebSockets where possible, but in this case doing what is done in the BFCP draft (explicitly putting TCP/WSS/MSRP into the SDP) may not be practical (and in fact may be quite undesirable). Regards, Peter On 13 February 2014 16:07, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > What I mean is that I expect quite a lot of "over websocekts" drafts and > we should try to use the same solution for advertising it in the SDP, and > not have each one have their own way of handling it. > > Best regards > Sergio > El 13/02/2014 16:49, "Mary Barnes" escribi= =F3: > > Sergio, >> >> The draft you mention is being discussed in the BFCPBIS WG and any >> comments that others might have on that document should go to that list. >> >> It's not clear to me whether your suggestion is that changes are needed >> to this MSRP document or whether you are just proposing to make the BFCP= BIS >> consistent with this MSRP document? >> >> Mary. >> >> >> On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia Murillo < >> sergio.garcia.murillo@gmail.com> wrote: >> >>> Hi, >>> >>> We also have recently published a different draft for BFCP over >>> websockets: >>> http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00 >>> >>> I beleive that we should harmonize who the WS transport is signaled and >>> how to signal the WS version if also the "normal" TCP version is suppor= ted. >>> >>> In your case you seem to be using the same transport line TCP/MSRP and >>> use the path to signal the ws part, in our case, we choose to signal it= in >>> the transport TCP/WS/BFCP and include a new attribute ws-uri to signal = the >>> full url (I could not reuse the path attribute as it is restricted to m= srp >>> urls only). >>> >>> Best regards >>> Sergio >>> El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribi=F3: >>> >>>> Hi Mary - >>>> >>>> Thanks for taking the time to review the document. We have published >>>> an -05 that (hopefully) addresses all your feedback. >>>> >>>> Inline, trimming to only the points requiring responses... >>>> >>>> >>>> On Jan 10, 2014, at 5:58 PM, Mary Barnes >>>> wrote: >>>> >>>> I have agreed to shepherd this document. I've reviewed the document >>>>> in anticipation of doing the PROTO write-up and have the following co= mments >>>>> and questions. Ben Campbell has agreed to do the required expert rev= iew >>>>> and that should be posted within the next week or so. This is also= a >>>>> good time for anyone in the WG that hasn't previously reviewed this >>>>> document to review and provide any final comments. Note, that this >>>>> document was agreed to be AD sponsored around the IETF-86 timeframe. >>>>> >>>>> Regards, >>>>> Mary. >>>>> >>>>> Review Summary: Almost ready. Comments & questions below. >>>>> >>>> >>>> >>>> 5) Section 10.1. Since securing the connection is just RECOMMENDED, >>>>> what are the implications and risks if the MSRP traffic isn't transpo= rted >>>>> over a secure connection? >>>>> >>>> Other review comments indicated that it was problematic to downgrade >>>> the 4976 MUST requirement for TLS between a client and a server. Thus,= the >>>> document has been updated so that MSRP traffic transported over WebSoc= kets >>>> MUST be protected by using a secure WebSocket connection (i.e., using = TLS). >>>> I believe this renders this point moot. >>>> >>>> >>>> >>>> 8) It's typical for documents that are updating existing RFCs to have >>>>> a section that summarizes the updates to the existing RFCs that are m= ade by >>>>> this document. >>>>> >>>> This was the intent of Sections 5.2 and 5.3. Is this sufficient? Or >>>> did you have something else in mind? >>>> >>>> Regards, >>>> >>>> Gonzalo >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --=20 Peter Dunkley Technical Director Crocodile RCS Ltd --089e0122f1ca33673004f24c256f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

The method chosen for advertisin= g WebSockets in the SDP for MSRP was picked because it was would enable int= eroperability with existing MSRP implementations through an MSRP relay with= out requiring changes to those implementations. =A0In this scenario adverti= sing WebSockets in the SDP would mean that the existing implementation - wh= ich does not need to support WebSockets (the MSRP relay deals with this) - = would need to be able to cope with seeing TCP/WSS/MSRP in the SDP. =A0In al= l probability existing implementations will not cope with seeing "TCP/= WSS/MSRP" in the SDP instead of "TCP/TLS/MSRP" - this would = be a big problem.

I have no issue with consistency between the drafts usi= ng WebSockets where possible, but in this case doing what is done in the BF= CP draft (explicitly putting TCP/WSS/MSRP into the SDP) may not be practica= l (and in fact may be quite undesirable).

Regards,

Peter

<= /div>


On= 13 February 2014 16:07, Sergio Garcia Murillo <sergio.garci= a.murillo@gmail.com> wrote:

What I mean is that I expect = quite a lot of "over websocekts" drafts and we should try to use = the same solution for advertising it in the SDP, and not have each one have= their own way of handling it.

Best regards
Sergio

El 13/02/2014 16:49, "Mary Barnes" <= ;mary.ietf.= barnes@gmail.com> escribi=F3:

Sergio,

The draft you mention is being = discussed in the BFCPBIS WG and any comments that others might have on that= document should go to that list.

It's not cle= ar to me whether your suggestion is that changes are needed to this MSRP do= cument or whether you are just proposing to make the BFCPBIS consistent wit= h this MSRP document?=A0

Mary.=A0


=
On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia M= urillo <sergio.garcia.murillo@gmail.com> wrote= :
Hi,

We also have recently published a different draft for BFCP over websockets:=
http://tools.ietf.org/html/draft-pascual-bfcpb= is-bfcp-websocket-00

I beleive that we should harmonize who the WS transport is signaled and how= to signal the WS version if also the "normal" TCP version is sup= ported.

In your case you seem to be using the same transport line TCP/MSRP and use = the path to signal the ws part, in our case, we choose to signal it in the = transport TCP/WS/BFCP and include a new attribute ws-uri to signal the full= url (I could not reuse the path attribute as it is restricted to msrp urls= only).

Best regards
Sergio
El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribi=F3:
Hi Mary -

Thanks for taking the time to review the document. =A0We have published an = -05 that (hopefully) addresses all your feedback.

Inline, trimming to only the points requiring responses...


On Jan 10, 2014, at 5:58 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:=

I have agreed to shepherd this document. =A0I've reviewed the document = in anticipation of doing the PROTO write-up and have the following comments= and questions. =A0Ben Campbell has agreed to do the required expert review= and that should be posted within the next week or so. =A0 =A0This is also = a good time for anyone in the WG that hasn't previously reviewed this d= ocument to review and provide any final comments. =A0Note, that this docume= nt was agreed to be AD sponsored around the IETF-86 timeframe.

Regards,
Mary.

Review Summary: Almost ready. Comments & questions below.
<snip/>

5) Section 10.1. Since securing the connection is just RECOMMENDED, what ar= e the implications and risks if the MSRP traffic isn't transported over= a secure connection?
Other review comments indicated that it was problematic to downgrade the 49= 76 MUST requirement for TLS between a client and a server. Thus, the docume= nt has been updated so that MSRP traffic transported over WebSockets MUST b= e protected by using a secure WebSocket connection (i.e., using TLS). =A0I = believe this renders this point moot.

<snip/>

8) It's typical for documents that are updating existing RFCs to have a= section that summarizes the updates to the existing RFCs that are made by = this document.
This was the intent of Sections 5.2 and 5.3. =A0Is this sufficient? Or did = you have something else in mind?

Regards,

Gonzalo

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

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


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




--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
--089e0122f1ca33673004f24c256f-- From jiri@iptel.org Thu Feb 13 08:26:46 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B83341A0301 for ; Thu, 13 Feb 2014 08:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpcXs_FEDl1h for ; Thu, 13 Feb 2014 08:26:45 -0800 (PST) Received: from mail.iptel.org (mail.iptel.org [212.79.111.154]) by ietfa.amsl.com (Postfix) with ESMTP id 566A11A0319 for ; Thu, 13 Feb 2014 08:26:44 -0800 (PST) Received: from Jiris-MacBook-Pro.local (owli.iptel.org [212.79.111.153]) by mail.iptel.org (Postfix) with ESMTP id BA27C371D66; Thu, 13 Feb 2014 17:26:38 +0100 (CET) Message-ID: <52FCF23D.7070608@iptel.org> Date: Thu, 13 Feb 2014 17:26:37 +0100 From: Jiri Kuthan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" , Harvind Samra , Ivo Sedlacek References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:26:46 -0000 On 2/13/14 3:34 PM, DRAGE, Keith (Keith) wrote: > Jumping in here, they are relevant in as much as there is no point in IETF working on this if there is no known market for it. Hi Keith, are you suggesting that IETF processes shall only allow work on technologies for which there is a known market? I'm glad this was not the case in the past, otherwise I would not be able to send a single email. At least I don't have memory of IETF business case criteria for the SNMP protocol. If that shall change in the future, I would like to know what is the specific IETF criteria for market existence. Can you elaborate what these are supposed to be? -jiri p.s. one more question here: I understand your point that I'm eligible to read emails to this WG mailing list that carry confidentiality notice on the grounds of group memership. What I don't understand is whether I'm also permitted (in departure from the notice) to forward such an email to some other email address than that of the working group. > Usually those type of projects are published only on April 1st. > So all Ivo is asking is for you to justify that it is worth other people working on this as well as yourselves. > Perhaps if you identified the spectrum you believe is available for use in the the countries identified, that would be useful. > regards > Keith Drage From ivo.sedlacek@ericsson.com Thu Feb 13 08:58:00 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4EC1A02ED for ; Thu, 13 Feb 2014 08:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UVTC0cVVBma for ; Thu, 13 Feb 2014 08:57:56 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6B4941A029E for ; Thu, 13 Feb 2014 08:57:55 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-35-52fcf9913329 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 75.8D.23809.199FCF25; Thu, 13 Feb 2014 17:57:53 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.164]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 17:57:53 +0100 From: Ivo Sedlacek To: Jiri Kuthan , "DRAGE, Keith (Keith)" , Harvind Samra Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPKNhhkrZYui7Q4Eii0l2hGkNSOZqzZPjg Date: Thu, 13 Feb 2014 16:57:52 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112662679@ESESSMB301.ericsson.se> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52FCF23D.7070608@iptel.org> In-Reply-To: <52FCF23D.7070608@iptel.org> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvje7En3+CDNpu6losnbSA1WLr5Wls FqeWnmaxeNp4ltGBxaP12V5WjyVLfjJ57J5yjNXjzMn0AJYoLpuU1JzMstQifbsEroxzJxcw FZwWqrj3fjZ7A+Nzvi5GDg4JAROJhaeTuxg5gUwxiQv31rN1MXJxCAkcYpRoub2VBcJZwijx 4PVaZpAqNgE9iYlbjrCC2CICbYwSzcsFQGxmAW2J/9fXMYLYwgKmEiuntkDVmElMmjaLGcI2 krjX8ZoJxGYRUJV4/3kVO4jNK+ArMffwB6hl8zkk+o/sAmvgFNCUeDmnlwXEZhSQlbj6p5cR Ypm4xK0n85kgzhaQWLLnPDOELSrx8vE/VghbSWLF9ktQ9XoSN6ZOYYM5dNnC18wQiwUlTs58 wjKBUWwWkrGzkLTMQtIyC0nLAkaWVYzsuYmZOenlRpsYgbF0cMtv1R2Md86JHGKU5mBREuf9 8NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANj4eG9tfOtrcUZNGfbqpbaW7KtX3WMafq6 zWEx6U9n7eC4H5ORardOdoZlSehuHqP72yJ2/knX26507ehvbouGJmWFC5firx/Os2G4dula aMtux4L8HTO66p2sWtl+LU/OePrquJXAIZ0GYfYpD54ECBsabD8g8MD8yv+vzNuO6ype+Sq3 aKOsEktxRqKhFnNRcSIAnh3JU3MCAAA= Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:58:00 -0000 The question should be: Should IETF work on a new solution for a market where a solution exists an= d the existing solution is equal or superior to the newly proposed one? Argument for statement "the existing solution is equal or superior to the n= ewly proposed one" is: - the existing 3GPP solution is already developed, tested, mass produced an= d mass deployed and thus benefits from economies of scale. - no existing 3GPP requirement was identified as unnecessary for the new so= lution so complexity of the existing solution and new solution is the same. If you believe that statement "the existing solution is equal or superior t= o the newly proposed one" is incorrect, please prove it. Kind regards Ivo Sedlacek -----Original Message----- From: Jiri Kuthan [mailto:jiri@iptel.org]=20 Sent: 13. =FAnora 2014 17:27 To: DRAGE, Keith (Keith); Harvind Samra; Ivo Sedlacek Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS On 2/13/14 3:34 PM, DRAGE, Keith (Keith) wrote: > Jumping in here, they are relevant in as much as there is no point in IET= F working on this if there is no known market for it. Hi Keith, are you suggesting that IETF processes shall only allow work on technologie= s for which there is a known market? I'm glad this was not the case in the past, otherwise I would not be able t= o send a single email. At least I don't have memory of IETF business case c= riteria for the SNMP protocol. If that shall change in the future, I would = like to know what is the specific IETF criteria for market existence. Can y= ou elaborate what these are supposed to be? -jiri p.s. one more question here: I understand your point that I'm eligible to r= ead emails to this WG mailing list that carry confidentiality notice on the= grounds of group memership. What I don't understand is whether I'm also pe= rmitted (in departure from the notice) to forward such an email to some oth= er email address than that of the working group. > Usually those type of projects are published only on April 1st. > So all Ivo is asking is for you to justify that it is worth other people = working on this as well as yourselves. > Perhaps if you identified the spectrum you believe is available for use i= n the the countries identified, that would be useful. > regards > Keith Drage From thp@westhawk.co.uk Thu Feb 13 09:19:22 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 029991A02CF for ; Thu, 13 Feb 2014 09:19:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Frb9daphZgyV for ; Thu, 13 Feb 2014 09:19:20 -0800 (PST) Received: from smtp002.apm-internet.net (smtp002.apm-internet.net [85.119.248.221]) by ietfa.amsl.com (Postfix) with ESMTP id CAE1D1A02C5 for ; Thu, 13 Feb 2014 09:19:19 -0800 (PST) Received: (qmail 2307 invoked from network); 13 Feb 2014 17:19:17 -0000 X-AV-Scan: clean X-APM-Authkey: 83769 13576 Received: from unknown (HELO zimbra003.verygoodemail.com) (85.119.248.218) by smtp002.apm-internet.net with SMTP; 13 Feb 2014 17:19:17 -0000 Received: from zimbra003.verygoodemail.com (localhost [127.0.0.1]) by zimbra003.verygoodemail.com (Postfix) with ESMTP id 3BCCD18A057E; Thu, 13 Feb 2014 17:19:17 +0000 (GMT) Received: from limit.westhawk.co.uk (limit.westhawk.co.uk [192.67.4.33]) by zimbra003.verygoodemail.com (Postfix) with ESMTPSA id B85BB18A04FB; Thu, 13 Feb 2014 17:19:16 +0000 (GMT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Tim Panton new In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112662679@ESESSMB301.ericsson.se> Date: Thu, 13 Feb 2014 17:19:04 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <0A527A1E-0789-41D8-902B-A1B12F03E69C@westhawk.co.uk> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> < 52FCF23D.7070608@iptel.org> <39B5E4D390E9BD4890E2B3107900610112662679@ESESSMB301.ericsson.se> To: Ivo Sedlacek X-Mailer: Apple Mail (2.1827) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:19:22 -0000 On 13 Feb 2014, at 16:57, Ivo Sedlacek = wrote: > The question should be: >=20 > Should IETF work on a new solution for a market where a solution = exists and the existing solution is equal or superior to the newly = proposed one? >=20 Actually, yes, on the off-chance the person making that evaluation could = be wrong. > Argument for statement "the existing solution is equal or superior to = the newly proposed one" is: > - the existing 3GPP solution is already developed, tested, mass = produced and mass deployed and thus benefits from economies of scale. > - no existing 3GPP requirement was identified as unnecessary for the = new solution so complexity of the existing solution and new solution is = the same. >=20 > If you believe that statement "the existing solution is equal or = superior to the newly proposed one" is incorrect, please prove it. Apples and oranges - If I want a continent spanning, roaming capable = billion dollar GSM network, then I need an IMS system. If I want an Um to SIP gateway I can run off solar power and hang in a = tree, I'll go for an openBTS like solution. They aren't comparable goals. Tim.= From nobody Thu Feb 13 09:44:13 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7B41A039A for ; Thu, 13 Feb 2014 09:44:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZH0xs3cgaUy for ; Thu, 13 Feb 2014 09:44:06 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0206.outbound.protection.outlook.com [207.46.163.206]) by ietfa.amsl.com (Postfix) with ESMTP id D7E441A03A2 for ; Thu, 13 Feb 2014 09:44:00 -0800 (PST) Received: from BLUPR03CA031.namprd03.prod.outlook.com (10.141.30.24) by BLUPR03MB049.namprd03.prod.outlook.com (10.255.209.149) with Microsoft SMTP Server (TLS) id 15.0.873.10; Thu, 13 Feb 2014 17:43:51 +0000 Received: from BN1BFFO11FD038.protection.gbl (2a01:111:f400:7c10::1:156) by BLUPR03CA031.outlook.office365.com (2a01:111:e400:879::24) with Microsoft SMTP Server (TLS) id 15.0.878.16 via Frontend Transport; Thu, 13 Feb 2014 17:43:52 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD038.mail.protection.outlook.com (10.58.144.101) with Microsoft SMTP Server (TLS) id 15.0.868.13 via Frontend Transport; Thu, 13 Feb 2014 17:43:51 +0000 Received: from TK5EX14MBXC295.redmond.corp.microsoft.com ([169.254.1.97]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.03.0174.002; Thu, 13 Feb 2014 17:43:22 +0000 From: "Matthew Kaufman (SKYPE)" To: "DRAGE, Keith (Keith)" , Tim Panton new , "dispatch@ietf.org" Thread-Topic: [dispatch] Email ettiquette Thread-Index: AQHPKKvE5gFjRQKBcU2EDFDjvmvHNJqzPjyAgAA1sGA= Date: Thu, 13 Feb 2014 17:43:21 +0000 Message-ID: References: <949EF20990823C4C85C18D59AA11AD8B1319A7@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B1319A7@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(377454003)(51704005)(189002)(199002)(74366001)(66066001)(87266001)(51856001)(92726001)(76786001)(85852003)(76796001)(83072002)(6806004)(85306002)(85806002)(87936001)(79102001)(53806001)(54356001)(81542001)(59766001)(56776001)(46102001)(47446002)(20776003)(69226001)(74502001)(74662001)(31966008)(80022001)(81342001)(63696002)(77982001)(54316002)(65816001)(76482001)(2656002)(46406003)(47776003)(94946001)(83322001)(93516002)(81686001)(19580405001)(50986001)(4396001)(86362001)(94316002)(49866001)(47976001)(74876001)(77096001)(74706001)(47736001)(90146001)(56816005)(50466002)(80976001)(95666001)(81816001)(23726002)(33656001)(93136001)(95416001)(44976005)(19580395003)(92566001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR03MB049; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:F41B563D.9E2356C1.F9F1B1AC.426BE16D.201B9; MLV:sfv; InfoDomainNonexistentMX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0121F24F22 X-OriginatorOrg: skype.net Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/dA3hEXUCRu8YNwSsxvOAMiHAPyc Subject: Re: [dispatch] Email ettiquette X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:44:11 -0000 DRAGE, Keith (Keith): > Sent: Thursday, February 13, 2014 6:28 AM > To: Tim Panton new; dispatch@ietf.org > Subject: Re: [dispatch] Email ettiquette >=20 > While these signature lines are undesirable, and some people don't have a= ny > choice in having them there, apart from using a non-company email address= . > I personally prefer that people participating on behalf of their company = use > the company email address=20 They can't be "participating on behalf of their company"... from one of man= y IETF documents on the subject, I quote: " If you work for a company and t= he IETF will be part of your job, you must obviously clear this with your m= anager. However, the IETF will always view you as an individual, and never = as a company representative." What better way to view people this way than to ignore where their mail com= es from and focus on the content? Matthew Kaufman From nobody Thu Feb 13 10:00:13 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214EF1A0382 for ; Thu, 13 Feb 2014 10:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwKsEhKeRjiZ for ; Thu, 13 Feb 2014 10:00:10 -0800 (PST) Received: from mail.iptel.org (mail.iptel.org [212.79.111.154]) by ietfa.amsl.com (Postfix) with ESMTP id E47951A01A8 for ; Thu, 13 Feb 2014 10:00:09 -0800 (PST) Received: from Jiris-MacBook-Pro.local (owli.iptel.org [212.79.111.153]) by mail.iptel.org (Postfix) with ESMTP id ED937371D9F; Thu, 13 Feb 2014 19:00:07 +0100 (CET) Message-ID: <52FD0827.3050105@iptel.org> Date: Thu, 13 Feb 2014 19:00:07 +0100 From: Jiri Kuthan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ivo Sedlacek , "DRAGE, Keith (Keith)" , Harvind Samra References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <52FCF23D.7070608@iptel.org> <39B5E4D390E9BD4890E2B3107900610112662679@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112662679@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/V4M4bM_71-4i9KU8dDWpj9QgE6Y Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:00:12 -0000 On 2/13/14 5:57 PM, Ivo Sedlacek wrote: > The question should be: > > Should IETF work on a new solution for a market where a solution exists and the existing solution is equal or superior to the newly proposed one? A quick opinion of mine: I don't think the IETF should bother about this much. There is a long record of technologies developed in the IETF that either didn't have a business plan attached with them, or did crash someone else's business plan, or competed with other established or not-established technologies or even among each other. I think that's a good thing even if some of the technologies turn not to be adopted later. > Argument for statement "the existing solution is equal or superior to the newly proposed one" is: > - the existing 3GPP solution is already developed, tested, mass produced and mass deployed and thus benefits from economies of scale. > - no existing 3GPP requirement was identified as unnecessary for the new solution so complexity of the existing solution and new solution is the same. I'm afraid that business arguments are forward-looking, which in plain language doesn't mean novel or futuristic but just uncertain and subjective. I suspect that if we used such to restrict proposals when debating what to do in the IETF, we would be on analog phones today :) -jiri > > If you believe that statement "the existing solution is equal or superior to the newly proposed one" is incorrect, please prove it. > > Kind regards > > Ivo Sedlacek > > -----Original Message----- > From: Jiri Kuthan [mailto:jiri@iptel.org] > Sent: 13. února 2014 17:27 > To: DRAGE, Keith (Keith); Harvind Samra; Ivo Sedlacek > Cc: dispatch@ietf.org > Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS > > On 2/13/14 3:34 PM, DRAGE, Keith (Keith) wrote: >> Jumping in here, they are relevant in as much as there is no point in IETF working on this if there is no known market for it. > > Hi Keith, > > are you suggesting that IETF processes shall only allow work on technologies for which there is a known market? > > I'm glad this was not the case in the past, otherwise I would not be able to send a single email. At least I don't have memory of IETF business case criteria for the SNMP protocol. If that shall change in the future, I would like to know what is the specific IETF criteria for market existence. Can you elaborate what these are supposed to be? > > -jiri > > p.s. one more question here: I understand your point that I'm eligible to read emails to this WG mailing list that carry confidentiality notice on the grounds of group memership. What I don't understand is whether I'm also permitted (in departure from the notice) to forward such an email to some other email address than that of the working group. > > >> Usually those type of projects are published only on April 1st. >> So all Ivo is asking is for you to justify that it is worth other people working on this as well as yourselves. >> Perhaps if you identified the spectrum you believe is available for use in the the countries identified, that would be useful. >> regards >> Keith Drage > From nobody Thu Feb 13 10:38:46 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992141A0392 for ; Thu, 13 Feb 2014 10:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnpV9tNn-S6Y for ; Thu, 13 Feb 2014 10:38:44 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 598FF1A03EB for ; Thu, 13 Feb 2014 10:38:38 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta13.westchester.pa.mail.comcast.net with comcast id Rpdv1n0020cZkys5Dued0B; Thu, 13 Feb 2014 18:38:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id Rueb1n01c3ZTu2S3WuecGH; Thu, 13 Feb 2014 18:38:37 +0000 Message-ID: <52FD112B.5040209@alum.mit.edu> Date: Thu, 13 Feb 2014 13:38:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392316717; bh=+SUPlwdsz611G1iur5g1LEwZz3erJ1omhxPAv1o1w4Q=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=G/J6nMDtctPz8fQq4nFW2PiZhXvGqmIkxJy30AZVbiTFfl6h3bYLoX6sbEUQApaIe 4iQCWJU+jUuLmuKsD/ph6aqN44jEhcjmasZ5kc+5bKj9lq2yqMat2PIb9B3qlUQmPJ 24BJLmEC0lozAcxLW55F+3jmkeysNa4P/fOE2CkNa9vjNMGYohwRM5VJ86Aw3IwsWy YA//yuiu6r008EqJC8RzBOcsuJ5s+LjxHlG2qBsl/pM4ClYjwNjvukBqTZJgUkcmsa zIUtHTHsAZI+dyoK+rX1qU72zMtTMDbWWjXaVoaHPeGcU0jztZt1pIdL+oQLhsmQfe T32oBxu7pbOTw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/OuU-WagtecSF6dFu9z8zcxFBKKM Subject: [dispatch] X over websockets X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:38:45 -0000 On 2/13/14 11:07 AM, Sergio Garcia Murillo wrote: > What I mean is that I expect quite a lot of "over websocekts" drafts and > we should try to use the same solution for advertising it in the SDP, > and not have each one have their own way of handling it. Sigh. Yes, once we had the first of these, it was only a matter of time before the flood began. What concerns me is that for every "X over websockets" there is probably also a good argument for "X over WebRTC Data Channel". Are we going to let that happen? Or for each X are we going to have a beauty contest between websockets and data channel? Or what? Thanks, Paul From nobody Thu Feb 13 12:18:30 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CAB1A0439 for ; Thu, 13 Feb 2014 12:18:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pso5ygMR-l61 for ; Thu, 13 Feb 2014 12:18:23 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6D68A1A049B for ; Thu, 13 Feb 2014 12:18:23 -0800 (PST) Received: by mail-yk0-f178.google.com with SMTP id 79so20625101ykr.9 for ; Thu, 13 Feb 2014 12:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tMjtx9TTj+ORB+SsvqHJlKZpQRgaqVxSgsJAepRPIzQ=; b=cDGN/Hr8jOGFjy/AryW7LA7srYW1wWOCm/L2kXPwHIbn0iF+6WQrJIsx+FQ4Aok2im GJrpt8M7M7QKYk9L7U5tLeG4SkEKPAMsLtQn8I2VbLvAyo4E31RJmcCvoILwSzDP4470 4v5ww5WM3kLdFvOypSS4IRdMbocUNZTrNPn1Us3/S5tPVcnX9oKb/x2ZDQtNEOWb4GDd 9FKnufdqoXbK9RqgHQZpqoYIgdeSEPoTP0d7qtrpxguCC8vKO29FE/dH578EKiM5N1cF j/lFsN1vaGhv9APsE00EQYmx9vWdSDR35vSzEawkBi0xh1del1850Q3p3zxqrtv7u1CR cCcQ== MIME-Version: 1.0 X-Received: by 10.236.121.162 with SMTP id r22mr2977351yhh.47.1392322702095; Thu, 13 Feb 2014 12:18:22 -0800 (PST) Received: by 10.170.150.2 with HTTP; Thu, 13 Feb 2014 12:18:21 -0800 (PST) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B131BEF@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00361BF0-F6B9-48DD-80A6-CECD0A7C0A3B@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B131BEF@FR712WXCHMBA11.zeu.alcatel-lucent.com> Date: Thu, 13 Feb 2014 14:18:21 -0600 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=20cf301af34f123c2f04f24f6437 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/d8hATWod_eBt3Bdnb6o5MSLqHaE Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:18:27 -0000 --20cf301af34f123c2f04f24f6437 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > Ericsson is not the only vendor that sees a market for small cells, but > the expectation is that the products are built to the completed 3GPP > standards will be deployed in licensed spectrum by owners of that spectrum, > although the boxes may well be owned by 3rd parties. > > These deployments already exist. > > I see Jim has now identified that this proposal is for licensed GSM > operators in licensed GSM space. > > Personally, I would suggest if you believe the operators should be picking > this up, you take it to 3GPP where the operators are actually present. That > is the only way you will see it taken up by GSMA, which you will need to > obtain interoperator agreements to use this (e.g. roaming, shared > networks). 3GPP them works with IETF on any SIP extensions needed. > [MB] One big problem with this proposal is that you must be a member of 3GPP/GSMA to make contributions and to participate in meetings. And, I think having to first do the work in 3GPP and then bring it to IETF would introduce a tremendous delay for something that's already been implemented/deployed. While they are proposing to reuse elements and protocols that are part of an IMS network, the core issue they have is with interworking SIP with the radio layer protocols. Certainly, one could implement all the protocols that IMS uses and then use the 3GPP based specs and proprietary headers to interwork with SIP in the Internet, but that would be terribly inefficient. [/MB] > > I would only see IETF having any direct part in this if the proposal was > only to use unlicensed spectrum by enterprises rather than licensed > operators, which Jim has negated. > > regards > > Keith > > ------------------------------ > *From:* Tim Panton new [mailto:thp@westhawk.co.uk] > *Sent:* 13 February 2014 14:50 > *To:* DRAGE, Keith (Keith) > *Cc:* Harvind Samra; Ivo Sedlacek; dispatch@ietf.org > > *Subject:* Re: [dispatch] SIP and GSM/UMTS with OpenBTS > > > On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote: > > Jumping in here, they are relevant in as much as there is no point in > IETF working on this if there is no known market for it. > > Usually those type of projects are published only on April 1st. > > So all Ivo is asking is for you to justify that it is worth other people > working on this as well as yourselves. > > Perhaps if you identified the spectrum you believe is available for use in > the the countries identified, that would be useful. > > regards > > Keith Drage > > > Ivo's employer seems to see a market for small cells, but looks to tie > them to existing operator IMS's through > internet connections "owned by themselves or a partner". > > http://www.telecomlead.com/enterprise-networking/mwc-2014-ericsson-announce-small-cell-service-20233/ > Perhaps that's an April fools joke too (I can't see any avian carriers > mentioned though)? > > It isn't up to the IETF to crown specific solutions. That's the market's > job. > > T. > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --20cf301af34f123c2f04f24f6437 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:
Ericsson is not the only vendor that sees a market for small cells, but t= he expectation is that the products are built to the completed 3GPP standar= ds will be deployed in licensed spectrum by owners of that spectrum, although the = boxes may well be owned by 3rd parties.
=A0
These deployments already exist.
=A0
I see Jim has now identified that this proposal is for licensed GSM opera= tors in licensed GSM space.
=A0
Personally, I would suggest if you believe the operators should be pickin= g this up, you take it to 3GPP where the operators are actually present. Th= at is the only way you will see it taken up by GSMA, which you will need to obta= in interoperator agreements to use this (e.g. roaming, shared networks). 3G= PP them works with IETF on any SIP extensions needed.
[MB] One big problem with this proposal is that you= must be a member of 3GPP/GSMA to make contributions and to participate in = meetings. =A0 =A0

And, I think having to first do = the work in 3GPP and then bring it to IETF would introduce a tremendous del= ay for something that's already been implemented/deployed. =A0While the= y are proposing to reuse elements and protocols that are part of an IMS net= work, the core issue they have is with interworking SIP with the radio laye= r protocols. =A0Certainly, one could implement all the protocols that IMS u= ses and then use the 3GPP based specs and proprietary headers to interwork = with SIP in the Internet, but that would be terribly inefficient.=A0
[/MB]=A0
=A0
I would only see IETF having any direct part in this if the proposal was = only to use unlicensed spectrum by enterprises rather than licensed operato= rs, which Jim has negated.
=A0
regards
=A0
Keith

From: Tim Panton new [mailto:<= a href=3D"mailto:thp@westhawk.co.uk" target=3D"_blank">thp@westhawk.co.uk]
Sent: 13 February 2014 14:50
To: DRAGE, Keith (Keith)
Cc: Harvind Samra; Ivo Sedlacek; dispatch@ietf.org

Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS


On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent= .com> wrote:

Jumping in here, they are relevant in as much as there is no point in IET= F working on this if there is no known market for it.
=A0
Usually those type of projects are published only on April 1st.
=A0
So all Ivo is asking is for you to justify that it is worth other people = working on this as well as yourselves.
=A0
Perhaps if you identified the spectrum you believe is available for use i= n the the countries identified, that would be useful.
=A0
regards
=A0
Keith Drage

Ivo's employer seems to see a market for small cells, but looks to= tie them to existing operator IMS's through=A0
internet connections "owned by themselves or a partner".
Perhaps that's an April fools joke too (I can't see any avian = carriers mentioned though)?

It isn't up to the IETF to crown specific solutions. That's th= e market's job.

T.




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


--20cf301af34f123c2f04f24f6437-- From nobody Thu Feb 13 12:28:22 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201D71A04E0 for ; Thu, 13 Feb 2014 12:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zwwQNStKfws3 for ; Thu, 13 Feb 2014 12:28:20 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 38D491A04DD for ; Thu, 13 Feb 2014 12:28:20 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hn9so9236035wib.6 for ; Thu, 13 Feb 2014 12:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=+e9t/SFu94/Szl58Lnze6FiI/7oo3KN/CcnAHlLkGvM=; b=IpM5eRQPmplswAZH/bHhxkP+iHVhFHJw31+vX6WEyrFZh5bxzzypafTWdCLfUmCHUR GD9lS+ayxJkx2U3HdUltwfoKBFEYhcG2lgWDwL0yWZ/7dQ6sOSBrPP8ZD0xT5MVdxKVB ddY8V64Jg2ZyD5gujLqif7KYRkBznY2Ow2kIuqCwaMD63fy8gcxf4wJgEo88U7QcjaNP jBLPsTG82vFngI8JD1UDhu6rn03n3iyIUVM1SvF8LWdvl5EZM5rJIE3sMw7XfFsASVS0 p9Fp2hqmh5uivkX8/Nd5NHfPAdZZ8R3fuIr1hUipOrRyz1CY1Bt4Qbq1Fb5pw4ddhyGZ vvMQ== X-Received: by 10.180.73.173 with SMTP id m13mr8013689wiv.52.1392323298337; Thu, 13 Feb 2014 12:28:18 -0800 (PST) Received: from [192.168.0.192] ([95.61.111.78]) by mx.google.com with ESMTPSA id t6sm16495628wix.4.2014.02.13.12.28.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 12:28:17 -0800 (PST) Message-ID: <52FD2AE0.7060600@gmail.com> Date: Thu, 13 Feb 2014 21:28:16 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD112B.5040209@alum.mit.edu> In-Reply-To: <52FD112B.5040209@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/PNTgYwblUu614C1F5gonYdTa7ww Subject: Re: [dispatch] X over websockets X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:28:22 -0000 El 13/02/2014 19:38, Paul Kyzivat escribió: > On 2/13/14 11:07 AM, Sergio Garcia Murillo wrote: >> What I mean is that I expect quite a lot of "over websocekts" drafts and >> we should try to use the same solution for advertising it in the SDP, >> and not have each one have their own way of handling it. > > Sigh. Yes, once we had the first of these, it was only a matter of > time before the flood began. > > What concerns me is that for every "X over websockets" there is > probably also a good argument for "X over WebRTC Data Channel". > > Are we going to let that happen? > > Or for each X are we going to have a beauty contest between websockets > and data channel? > > Or what? Completely agree, we should try to "close" that discussion once and for all and not have the same arguments and discussions in each draft. I am not really aware of the IETF process, but could be possible to create a draft to address it? Best regards Sergio From nobody Thu Feb 13 12:40:50 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3AB1A0432 for ; Thu, 13 Feb 2014 12:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxTseu0ux2lr for ; Thu, 13 Feb 2014 12:40:45 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 72DBB1A00CD for ; Thu, 13 Feb 2014 12:40:45 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id q59so8115333wes.9 for ; Thu, 13 Feb 2014 12:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=Wuv07pe0UFDAmwlCqBs2QFAnCjwFnOB8HBFaoskJl7s=; b=SNoSN0ye/AJ3ymvFF2HRMjRo0WDGragX4RNxc+likIxdhiOXOzpCxZ4JcBrkupUoO7 RWCWPzVYfaaHLHVwV4UNdgIHmX9zP1KdDvIZQiD/gHlTkGAjrKucddrn8Muh4nZjz3Jq 1rOgkOZv1x1HgYGp6WaAwTsHRKprmySbbl2GzGy4bmv6+px4CHsPyF2NxriM0rXg5+cN cmAP5ppbF+mmEKWYQcsiGRoSaGsGEiyRTlURQBH/srgxupBrooNHWMuVpQaXuOrpShrM 8ptRKNs/oAfMwdglHxZhK9J3mXIIi7F7ItL2Ueoqzi0BQLI079ylOG0pLs6V3W09KsKH ErPQ== X-Received: by 10.194.109.134 with SMTP id hs6mr2945773wjb.65.1392324043765; Thu, 13 Feb 2014 12:40:43 -0800 (PST) Received: from [192.168.0.192] ([95.61.111.78]) by mx.google.com with ESMTPSA id f1sm16775643wik.1.2014.02.13.12.40.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 12:40:42 -0800 (PST) Message-ID: <52FD2DC9.6090105@gmail.com> Date: Thu, 13 Feb 2014 21:40:41 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Mary Barnes References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080507080503070903060405" Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/JNmcCHpb7Is76_SHH-3WKGgNT5o Cc: DISPATCH Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:40:48 -0000 This is a multi-part message in MIME format. --------------080507080503070903060405 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Mary, My point is exactly the opposite. We should not choose one or the other, it is an issue that affects both drafts, and any upcoming X over websocket draft, so I don't think it is a good idea to isolate the discussion in a single draft and ignore what is happening outside. If not we will end up with lots of different solutions for the same issue and developers (like me) will get crazy when trying to implement it. Best regards Sergio El 13/02/2014 16:49, Mary Barnes escribió: > Sergio, > > The draft you mention is being discussed in the BFCPBIS WG and any > comments that others might have on that document should go to that list. > > It's not clear to me whether your suggestion is that changes are > needed to this MSRP document or whether you are just proposing to make > the BFCPBIS consistent with this MSRP document? > > Mary. > > > On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia Murillo > > wrote: > > Hi, > > We also have recently published a different draft for BFCP over > websockets: > http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00 > > I beleive that we should harmonize who the WS transport is > signaled and how to signal the WS version if also the "normal" TCP > version is supported. > > In your case you seem to be using the same transport line TCP/MSRP > and use the path to signal the ws part, in our case, we choose to > signal it in the transport TCP/WS/BFCP and include a new attribute > ws-uri to signal the full url (I could not reuse the path > attribute as it is restricted to msrp urls only). > > Best regards > Sergio > El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribió: > > Hi Mary - > > Thanks for taking the time to review the document. We have > published an -05 that (hopefully) addresses all your feedback. > > Inline, trimming to only the points requiring responses... > > > On Jan 10, 2014, at 5:58 PM, Mary Barnes > > wrote: > > I have agreed to shepherd this document. I've reviewed > the document in anticipation of doing the PROTO write-up > and have the following comments and questions. Ben > Campbell has agreed to do the required expert review and > that should be posted within the next week or so. This > is also a good time for anyone in the WG that hasn't > previously reviewed this document to review and provide > any final comments. Note, that this document was agreed > to be AD sponsored around the IETF-86 timeframe. > > Regards, > Mary. > > Review Summary: Almost ready. Comments & questions below. > > > > 5) Section 10.1. Since securing the connection is just > RECOMMENDED, what are the implications and risks if the > MSRP traffic isn't transported over a secure connection? > > Other review comments indicated that it was problematic to > downgrade the 4976 MUST requirement for TLS between a client > and a server. Thus, the document has been updated so that MSRP > traffic transported over WebSockets MUST be protected by using > a secure WebSocket connection (i.e., using TLS). I believe > this renders this point moot. > > > > 8) It's typical for documents that are updating existing > RFCs to have a section that summarizes the updates to the > existing RFCs that are made by this document. > > This was the intent of Sections 5.2 and 5.3. Is this > sufficient? Or did you have something else in mind? > > Regards, > > Gonzalo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --------------080507080503070903060405 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Mary,

My point is exactly the opposite. We should not choose one or the other, it is an issue that affects both drafts, and any upcoming X over websocket draft, so I don't think it is a good idea to isolate the discussion in a single draft and ignore what is happening outside. If not we will end up with lots of different solutions for the same issue and developers (like me) will get crazy when trying to implement it.

Best regards
Sergio
El 13/02/2014 16:49, Mary Barnes escribió:
Sergio,

The draft you mention is being discussed in the BFCPBIS WG and any comments that others might have on that document should go to that list.

It's not clear to me whether your suggestion is that changes are needed to this MSRP document or whether you are just proposing to make the BFCPBIS consistent with this MSRP document? 

Mary. 


On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Hi,

We also have recently published a different draft for BFCP over websockets:
http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00

I beleive that we should harmonize who the WS transport is signaled and how to signal the WS version if also the "normal" TCP version is supported.

In your case you seem to be using the same transport line TCP/MSRP and use the path to signal the ws part, in our case, we choose to signal it in the transport TCP/WS/BFCP and include a new attribute ws-uri to signal the full url (I could not reuse the path attribute as it is restricted to msrp urls only).

Best regards
Sergio
El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribió:
Hi Mary -

Thanks for taking the time to review the document.  We have published an -05 that (hopefully) addresses all your feedback.

Inline, trimming to only the points requiring responses...


On Jan 10, 2014, at 5:58 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

I have agreed to shepherd this document.  I've reviewed the document in anticipation of doing the PROTO write-up and have the following comments and questions.  Ben Campbell has agreed to do the required expert review and that should be posted within the next week or so.    This is also a good time for anyone in the WG that hasn't previously reviewed this document to review and provide any final comments.  Note, that this document was agreed to be AD sponsored around the IETF-86 timeframe.

Regards,
Mary.

Review Summary: Almost ready. Comments & questions below.
<snip/>

5) Section 10.1. Since securing the connection is just RECOMMENDED, what are the implications and risks if the MSRP traffic isn't transported over a secure connection?
Other review comments indicated that it was problematic to downgrade the 4976 MUST requirement for TLS between a client and a server. Thus, the document has been updated so that MSRP traffic transported over WebSockets MUST be protected by using a secure WebSocket connection (i.e., using TLS).  I believe this renders this point moot.

<snip/>

8) It's typical for documents that are updating existing RFCs to have a section that summarizes the updates to the existing RFCs that are made by this document.
This was the intent of Sections 5.2 and 5.3.  Is this sufficient? Or did you have something else in mind?

Regards,

Gonzalo

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

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


--------------080507080503070903060405-- From nobody Thu Feb 13 12:49:26 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA661A0283 for ; Thu, 13 Feb 2014 12:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a52gy8JEOSMV for ; Thu, 13 Feb 2014 12:49:22 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 54E961A0474 for ; Thu, 13 Feb 2014 12:49:21 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Thu, 13 Feb 2014 12:49:20 -0800 From: Michael Hammer To: 'Mary Barnes' , "'DRAGE, Keith (Keith)'" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAC9HICAAALFAIAAAFCA//96B5CAAI2tgIAALnMAgAZ4WICAAOAQAIAACMEAgAAEaACAAAXeAIAAJYeAgAFsZwCAANo2FIABtI+AgAAqBQCAACCxgIAABEMAgAAK7oCAAFDzgP//goyf Date: Thu, 13 Feb 2014 20:49:19 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF2A4FF@sc9-ex2k10mb1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [172.17.88.53] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=SHA1; boundary="00_00=_MimePart_000_06574C70_CF8649C3" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/LRENOJY72VQYyYv_RkMBejP1uJg Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:49:25 -0000 --00_00=_MimePart_000_06574C70_CF8649C3 Content-Type: multipart/alternative; boundary="00_00=_MimePart_001_06574C70_CF8649C3" --00_00=_MimePart_001_06574C70_CF8649C3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mary. Interworking sip with radio protocols is like saying inter working = sip with ip. Makes no sense. So far I have not seen any case for work in = IETF. This is more analogous to ITU- T attempt to screw up MPLS as far as = I can tell.=20 I asked the question before and still do not see a connection to any IETF = work. Cut out the business case and nothing has been proposed.=20 Sent with Good (www.good.com) ---- Original Message ---- From: Mary Barnes Sent: Thu 2/13/14 3:18 PM To: DRAGE, Keith (Keith) Cc: dispatch=40ietf.org On behalf of: dispatch Subject: Re: =5Bdispatch=5D SIP and GSM/UMTS with OpenBTS --00_00=_MimePart_001_06574C70_CF8649C3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 
Mary. Interworking sip with radio protocols is like saying inter =
working sip with ip. Makes no sense.  So far I have not seen any case for =
work in IETF.  This is more analogous to ITU- T attempt to screw up MPLS =
as far as I can tell.=20

I asked the question before and still do not see a connection to any IETF =
work.  Cut out the business case and nothing has been proposed.=20



Sent with Good (www.good.com)
------ Original Message ------
From: Mary Barnes
Sent: Thursday, February 13, 2014 = at 3:19 PM
To: DRAGE, Keith (Keith)
Cc: = dispatch=40ietf.org
Subject: =5Bdispatch=5D SIP and GSM/UMTS = with OpenBTS




On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith = (Keith) <keith.drage=40alcatel-lucent.com> = wrote:
Ericsson is not the only vendor that sees a market = for small cells, but the expectation is that the products are built to the = completed 3GPP standards will be deployed in licensed spectrum by owners of that spectrum, although the = boxes may well be owned by 3rd parties.
 
These deployments already exist.
 
I see Jim has now identified that this proposal is = for licensed GSM operators in licensed GSM space.
 
Personally, I would suggest if you believe the = operators should be picking this up, you take it to 3GPP where the = operators are actually present. That is the only way you will see it taken up by GSMA, which you will need to = obtain interoperator agreements to use this (e.g. roaming, shared = networks). 3GPP them works with IETF on any SIP extensions = needed.
=5BMB=5D One big problem with this proposal is = that you must be a member of 3GPP/GSMA to make contributions and to = participate in meetings.    

And, I = think having to first do the work in 3GPP and then bring it to IETF would = introduce a tremendous delay for something that's already been = implemented/deployed.  While they are proposing to reuse elements and = protocols that are part of an IMS network, the core issue they have is = with interworking SIP with the radio layer protocols.  Certainly, one = could implement all the protocols that IMS uses and then use the 3GPP = based specs and proprietary headers to interwork with SIP in the Internet, = but that would be terribly inefficient. 
=5B/MB=5D 
 
I would only see IETF having any direct part in = this if the proposal was only to use unlicensed spectrum by enterprises = rather than licensed operators, which Jim has negated.
 
regards
 
Keith

From: Tim Panton new = =5Bmailto:thp=40westhawk.co.uk=5D
Sent: 13 February 2014 14:50
To: DRAGE, Keith (Keith)
Cc: Harvind Samra; Ivo Sedlacek; dispatch=40ietf.org

Subject: Re: =5Bdispatch=5D SIP and GSM/UMTS with OpenBTS


On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) <keith.drage=40alcatel-lucent.com> wrote:

Jumping in here, they are relevant in as much as = there is no point in IETF working on this if there is no known market for = it.
 
Usually those type of projects are published only = on April 1st.
 
So all Ivo is asking is for you to justify that it = is worth other people working on this as well as = yourselves.
 
Perhaps if you identified the spectrum you believe = is available for use in the the countries identified, that would be = useful.
 
regards
 
Keith Drage

Ivo's employer seems to see a market for small cells, but looks to = tie them to existing operator IMS's through 
internet connections "owned by themselves or a = partner".
Perhaps that's an April fools joke too (I can't see any avian = carriers mentioned though)?

It isn't up to the IETF to crown specific solutions. That's the = market's job.

T.




_______________________________________________
dispatch mailing list
dispatch=40ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


--00_00=_MimePart_001_06574C70_CF8649C3-- --00_00=_MimePart_000_06574C70_CF8649C3 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BtswggbXMIIFv6ADAgECAhAQHd1E6Q8NPRDpBgRzvi1yMA0GCSqGSIb3DQEBBQUA MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24x HzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNv bmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRp dmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xMzA0MDEwMDAwMDBaFw0xNDA0 MDIyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx MzY0ODQyNjk0NDQzMSswKQYJKoZIhvcNAQkBFhxtaWNoYWVsLmhhbW1lckB5YWFu YXRlY2guY29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90 IFZhbGlkYXRlZDEfMB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsG A1UECgwUU3ltYW50ZWMgQ29ycG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQCHYC0pA2jAjwguY291xjXqagDwIfuGNK8YM2h/BayHiq4R9npV Aa0OGE6NSZbolWrvX0wfwU0lxWvygCJVorec14lMvbA7rwumBfq1xn/PbakmjP3z AfOB9Z/el8RRisKpiDZXebqh7S2R345p5jwOY9VKkbtqzSuSgTN43AK2aliOSb3q YE7r8BDCyjBIttK6qQQbKSnWTjsqI8G3GFuna6YhF6H3i8+uvU73Ndq72gYy8AEm OKBhDZ7kCGGEN0ryo6SGCQwAk3ae8upj5UWucUixvmehD+0/Yz9y32rBFnmRRq6Z GoT9fNXesfw+hpxlb9i9zACnwavVlocIxGX7AgMBAAGjggLVMIIC0TAMBgNVHRMB Af8EAjAAMA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYI KwYBBQUHAwIwHQYDVR0OBBYEFOW9hTHg8yVTLq69x4mQMwriMENmMCcGA1UdEQQg MB6BHG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20wHwYDVR0jBBgwFoAUrfnD k3IttbkoYeSk12DVxApeGgEwggErBggrBgEFBQcBAQSCAR0wggEZMIIBFQYIKwYB BQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJpc2lnbi5jb20vQ04lMjAlM0Ql MjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwlMjBTdWJzY3JpYmVy JTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBOb3QlMjBW YWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBD JTIwJTNEJTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCg ToZMaHR0cDovL3BraS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2 OTI0N2EwZWYwNzFhYzgxYWYvTGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CG SAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v Y3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vcnBhMCoG CmCGSAGG+EUBEAMEHDAaBhFghkgBhvhFARABAgIEAYazFxYFMTA5MjIwDQYJKoZI hvcNAQEFBQADggEBABp796vil8FOmorpz+4n0Px1UnPM1fbpqSQHzP/b22i3NuSk UAiVdGHTaI1Ur4aeyBLWDC7cU6+OBPkziL5w3EO9MlVydk1eezvklQZfdSxZBu1L JKtXNDHyUy3BbqdcczkaURpjz+MpWlqZsbar04eObAxPPsjgD7IqKIYIZ2ETbd0U 6+S7q3+iLCoWdcmZvijvmRtV68oQ53fgwiPQ/tDz7WZlw1gRRNgpp2g9cXJNac7Y dMy8VwaB0sUpypvXdyVZ5bf8HlaN0GKakyNu/CLxluuEV2ntjc0soVJEfxbb2u3Q tbvNQvGKLTPfg0awGRb3D3k8vNOyqYoPhi/kCQgxggJCMIICPgIBATCBuzCBpjEL MAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYD VQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5v dCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09EOkGBHO+LXIwCQYFKw4DAhoF AKBdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwIwYJKoZIhvcNAQkEMRYEFCSZ /TaW45kKITt1Ydzg6V/dO/AtMBwGCSqGSIb3DQEJBTEPFw0xNDAyMTMyMDQ5MTNa MA0GCSqGSIb3DQEBAQUABIIBAEaG9Rlr3//ThJHeLIyjxV9E9lceIQpeeguZlC2T xB4PCqxpDfFZWjYJcarmGss6cb9RZSl78QeDl2hMgKzqXWqMl1pBFpJjAWeREELB 6E/Tnhb7W9/F1Tp7mzkYuawn7aahd9YB4zjUi4xsLJ7WJjE6Hq9Ujx8AW8jmlxhs 4gm/0uARa1n/4IlujD6ACRT+Rq78hPg+sZAooGtxeuCSZJzpZwJX6XNnkRJ6voen p5U1l33Ph0SRPInC4G0SGnp9rbeZsPHmIVgCqusRXTvD94SY3OIgfnNcTko0/eX5 zQBEjhbstjCivJX/KA3TY4ekOoG/oMIgc3JQk2AUvHEOAq4AAAAAAAA= --00_00=_MimePart_000_06574C70_CF8649C3-- From nobody Thu Feb 13 12:57:28 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B771A040C for ; Thu, 13 Feb 2014 12:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz3w_RNpzJYx for ; Thu, 13 Feb 2014 12:57:26 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id D85B01A0283 for ; Thu, 13 Feb 2014 12:57:25 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta13.westchester.pa.mail.comcast.net with comcast id Rpit1n00116LCl05DwxQYB; Thu, 13 Feb 2014 20:57:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id RwxQ1n00V3ZTu2S3SwxQ4c; Thu, 13 Feb 2014 20:57:24 +0000 Message-ID: <52FD31B4.1060204@alum.mit.edu> Date: Thu, 13 Feb 2014 15:57:24 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD112B.5040209@alum.mit.edu> <52FD2AE0.7060600@gmail.com> In-Reply-To: <52FD2AE0.7060600@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392325044; bh=2YotZqM/Al7/4F41Qy+pt7BPXTJ6SmrwbJLnpysgKgs=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VYj0CZGWqSKXpZhzmvZsiRcZp6FX+Rai1zr1eB1FzDRBEaOENdfIgzIuRkCTrRawj dHaOQTNJ5EOhM68+IGpXhXeaLcBQ5nH8Nvj7M5Ij1xI8mUvm9ddicxclJiTd/Tolyp aZir/iOk7cLIjGIXMcSRspYd+azbiEMAgEl1izIRAUOLKGCPxmVOgwrMXuf+uyOt+K wgZGyb2xMsEVZ9J6Zbl/vV951MYSjyQO+GKJBQkPEM1lBfaNXhqN2WK9m1+GfCIi8D PsCyQ2mGDupSHqrlpCQRpt5y0Kh03LtvrlxQkxQHXL5Gk09brvcVFNyYRsed2TdOUL LagZHCsP3ffxQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/0dZdM1g8lRC3OzoBu0GdYKr6uUk Subject: Re: [dispatch] X over websockets X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:57:27 -0000 On 2/13/14 3:28 PM, Sergio Garcia Murillo wrote: > El 13/02/2014 19:38, Paul Kyzivat escribió: >> On 2/13/14 11:07 AM, Sergio Garcia Murillo wrote: >>> What I mean is that I expect quite a lot of "over websocekts" drafts and >>> we should try to use the same solution for advertising it in the SDP, >>> and not have each one have their own way of handling it. >> >> Sigh. Yes, once we had the first of these, it was only a matter of >> time before the flood began. >> >> What concerns me is that for every "X over websockets" there is >> probably also a good argument for "X over WebRTC Data Channel". >> >> Are we going to let that happen? >> >> Or for each X are we going to have a beauty contest between websockets >> and data channel? >> >> Or what? > > Completely agree, we should try to "close" that discussion once and for > all and not have the same arguments and discussions in each draft. I am > not really aware of the IETF process, but could be possible to create a > draft to address it? It's kind of late to do anything about it before the draft cutoff. Continuing to discuss here on the dispatch list isn't such a bad way to start out. Then maybe some hallway discussion in London. After that, maybe a draft for dispatch or RAI Area would be helpful. If we wanted to do both for everything, then ISTM that some of the mapping can be the same for websockets and data channel. The part that is hard to unify is the SDP negotiation. Could we come up with some approach where doing these is easy and consistent? Thanks, Paul From nobody Thu Feb 13 13:01:44 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1511D1A0470 for ; Thu, 13 Feb 2014 13:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVphIXUz3B5M for ; Thu, 13 Feb 2014 13:01:38 -0800 (PST) Received: from mail-ve0-x22f.google.com (mail-ve0-x22f.google.com [IPv6:2607:f8b0:400c:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E56671A047F for ; Thu, 13 Feb 2014 13:01:37 -0800 (PST) Received: by mail-ve0-f175.google.com with SMTP id c14so8867803vea.20 for ; Thu, 13 Feb 2014 13:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=LhUPM5xSCtKbX7wACLlrIlkB9/2FdfIhToMHOwq+nE8=; b=sJd7qiVCq5ucsMsW4805742+oMyjkCEA+3YIYxiq+dl6tFm07x7AUekSpoaTQ4Ck+v J3KIHUZRUGm30/Nn7OE6VL9rXtnuJ4XCXduYE+LehK5Ty8XNJoT9VIFzHoMa0HUNYT8o SjQ9onC0fynP2ajIHDidrQS9gB6756bC5CFX4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=LhUPM5xSCtKbX7wACLlrIlkB9/2FdfIhToMHOwq+nE8=; b=QMkK3P7D2LZacJIzg6n82ag962aXls7urlry+Vy3YpIfDV/1Tvqrxo/KT8XAeLvw0L mT8ovOm9+jKQATMEJgeI+mMKITmfc4YQP7sG631Km7x80+U3tbdzCfdj+LYcSBuGRBtI UZwwhwAgOOZE8rbdGqsJ8UVYl7DeJKakaiC8vb4Xk+VLYtjlPJXOhLxZcb6/Sr8OlSFF xN92V/Uo6d9/jOMuaH5RLz+ErUATz4y/a377yGBE+4pK/QnZRkvBCq4X/iV1KOc4cdnQ c7sxCXddSovRtoN/pQ6qKJJ6mWLI2lmZrLJVrA3nuy6qLnOTDLHvDwyzgUKL4T0YpoxL Ly3A== X-Gm-Message-State: ALoCoQnrixJJhNdGwYdZ5kvHzu+PElomVXDXD/R4MFG+ZLfc+AXl0kB9emH9iDXda42R180o5pwU MIME-Version: 1.0 X-Received: by 10.52.168.39 with SMTP id zt7mr1149650vdb.42.1392325296292; Thu, 13 Feb 2014 13:01:36 -0800 (PST) Received: by 10.58.187.114 with HTTP; Thu, 13 Feb 2014 13:01:36 -0800 (PST) In-Reply-To: <52FD2AE0.7060600@gmail.com> References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD112B.5040209@alum.mit.edu> <52FD2AE0.7060600@gmail.com> Date: Thu, 13 Feb 2014 21:01:36 +0000 Message-ID: From: Peter Dunkley To: "dispatch@ietf.org" Content-Type: multipart/alternative; boundary=089e01633c18b2c3d004f24ffe72 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/0HybmzDWWbY5O2T7wE6Zzh089OA Subject: Re: [dispatch] X over websockets X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:01:40 -0000 --089e01633c18b2c3d004f24ffe72 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, Wasn't Sergio's point about what the terminology (for example, within SDP) should be rather than whether WebSockets is appropriate as a transport or not? And isn't this a totally separate issue from the WebSockets vs. WebRTC question? I honestly don't see what the problem is with having some protocols over WebSockets, some protocols over DataChannel, and some over both. I am sure it is technically possible to have all of these protocols over one, or the other, or both, but what is important is which makes sense from a use-case point-of-view. Surely the fact that someone is prepared to spend the time putting together (possibly multiple) versions of a draft is a good indication that there is interest in using a particular protocol over a particular transport? In the MSRP example, when talking about an MSRP client communicating with an MSRP relay (not two MSRP peers communicating directly), MSRP over WebSockets makes a lot of sense. The WebSocket server is much less effort to implement than the WebRTC DataChannel server. Further, to generate the SDP for an INVITE when using MSRP you have to AUTH to the relay, doing this with WebRTC DataChannel would require: - Setting up a session to establish the DataChannel (INVITE, SDP, etc) - Sending an AUTH on the DataChannel - Setting up a second session for the MSRP connection or, you could totally redesigning the MSRP relay protocol - which would miss the point. Regards, Peter On 13 February 2014 20:28, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > El 13/02/2014 19:38, Paul Kyzivat escribi=F3: > > On 2/13/14 11:07 AM, Sergio Garcia Murillo wrote: >> >>> What I mean is that I expect quite a lot of "over websocekts" drafts an= d >>> we should try to use the same solution for advertising it in the SDP, >>> and not have each one have their own way of handling it. >>> >> >> Sigh. Yes, once we had the first of these, it was only a matter of time >> before the flood began. >> >> What concerns me is that for every "X over websockets" there is probably >> also a good argument for "X over WebRTC Data Channel". >> >> Are we going to let that happen? >> >> Or for each X are we going to have a beauty contest between websockets >> and data channel? >> >> Or what? >> > > Completely agree, we should try to "close" that discussion once and for > all and not have the same arguments and discussions in each draft. I am n= ot > really aware of the IETF process, but could be possible to create a draft > to address it? > > Best regards > Sergio > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 Peter Dunkley Technical Director Crocodile RCS Ltd --089e01633c18b2c3d004f24ffe72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

Wasn't Sergio's point ab= out what the terminology (for example, within SDP) should be rather than wh= ether WebSockets is appropriate as a transport or not? =A0And isn't thi= s a totally separate issue from the WebSockets vs. WebRTC question?

I honestly don't see what the problem is with having som= e protocols over WebSockets, some protocols over DataChannel, and some over= both. =A0I am sure it is technically possible to have all of these protoco= ls over one, or the other, or both, but what is important is which makes se= nse from a use-case point-of-view. =A0Surely the fact that someone is prepa= red to spend the time putting together (possibly multiple) versions of a dr= aft is a good indication that there is interest in using a particular proto= col over a particular transport?

In the MSRP example, when talking about an MSRP client = communicating with an MSRP relay (not two MSRP peers communicating directly= ), MSRP over WebSockets makes a lot of sense. =A0The WebSocket server is mu= ch less effort to implement than the WebRTC DataChannel server. =A0Further,= to generate the SDP for an INVITE when using MSRP you have to AUTH to the = relay, doing this with WebRTC DataChannel would require:
  • Setting up a session to establish the DataChannel (INVITE, SDP, etc= )
  • Sending an AUTH on the DataChannel
  • Setting up a second se= ssion for the MSRP connection
or, you could totally red= esigning the MSRP relay protocol - which would miss the point.

Regards,

Peter

<= /div>


On= 13 February 2014 20:28, Sergio Garcia Murillo <sergio.garci= a.murillo@gmail.com> wrote:
El 13/02/2014 19:38, Paul Kyzivat escribi=F3= :

On 2/13/14 11:07 AM, Sergio Garcia Murillo wrote:
What I mean is that I expect quite a lot of "over websocekts" dra= fts and
we should try to use the same solution for advertising it in the SDP,
and not have each one have their own way of handling it.

Sigh. Yes, once we had the first of these, it was only a matter of time bef= ore the flood began.

What concerns me is that for every "X over websockets" there is p= robably also a good argument for "X over WebRTC Data Channel".
Are we going to let that happen?

Or for each X are we going to have a beauty contest between websockets and = data channel?

Or what?

Completely agree, we should try to "close" that discussion once a= nd for all and not have the same arguments and discussions in each draft. I= am not really aware of the IETF process, but could be possible to create a= draft to address it?

Best regards
Sergio


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



--
=
Peter Dunkley
Technical Director
Crocodile RCS Ltd
--089e01633c18b2c3d004f24ffe72-- From nobody Thu Feb 13 13:06:50 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE091A0376 for ; Thu, 13 Feb 2014 13:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.239 X-Spam-Level: X-Spam-Status: No, score=-1.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVRtMZ8jpvnL for ; Thu, 13 Feb 2014 13:06:45 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id B2E081A0506 for ; Thu, 13 Feb 2014 13:06:44 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-1d-52fd33e23c3b Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id F1.7A.04853.2E33DF25; Thu, 13 Feb 2014 22:06:42 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 22:06:41 +0100 From: Christer Holmberg To: Mary Barnes , "DRAGE, Keith (Keith)" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAAmPICAAALFAIAAAFCAgAAAZICAAAdQgIAALnMAgAZ4WICAAOAQAIAACMEAgAAEaACAAAXeAIAAJYeAgAFsZwCAAXEU6IABHbKAgAAqBACAACCygIAABEIAgAAK7oCAAFDzgIAAHK5g Date: Thu, 13 Feb 2014 21:06:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D171872@ESESSMB209.ericsson.se> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00361BF0-F6B9-48DD-80A6-CECD0A7C0A3B@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B131BEF@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: fi-FI X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D171872ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42KZGfG3RveR8d8gg99rZC2WTlrAavG08Syj xef9+5kdmD1an+1l9dg56y67x5IlP5kCmKO4bFJSczLLUov07RK4Mn5P28te8Gs6Y8W7rpfs DYwfWxm7GDk5JARMJGadeckGYYtJXLi3Hsjm4hASOMEo8f7zKRYIZzGjxLXXjUAOBwebgIVE 9z9tkAYRgXSJK2c+s4DYzALaEv+vrwMbKixgKnF7239WiBoziUnTZjGDzBERuMQosWbJbWaQ BIuAqsSF0y+ZQGxeAV+JrzvmMUMs6+KR+NPXAZbgFAiUeDJjCtgGRqDzvp9awwSxTVziw8Hr zBBnC0gs2XMeyhaVePn4HyuErSTRuOQJK0R9vsSPtZtZIZYJSpyc+YRlAqPoLCSjZiEpm4Wk DCKuJ3Fj6hS2WVCPLlv4GqpeV2LGv0MsyOILGNlXMUoWpxYX56YbGejlpueW6KUWZSYXF+fn 6RWnbmIExuTBLb+NdjCe3GN/iFGag0VJnPc6a02QkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6p Bsb2R1o3ZHt2J+b49kV3H33bYbvzw9uAF/PKZnfkv133S/lT1rc8nq3791w7ETTlSmV/7slp kxy5ZrBmW63L//mZ7cFCLaPaDWucvQy/JvFofp+wc13Cj6R5veGes88kb69c+Hxd23IP1fWl qU8Ob4hfZLXv/qkcnYqwZ+9NXvx55nluauGCpKIVSizFGYmGWsxFxYkACQs4EpcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/D9G2d9M6UnbuOgsOyoWy2oeNuUY Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:06:49 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D171872ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mary, I haven't followed this discussion, but: if this has "already been implemen= ted/deployed", what is IETF expected to do? Have some problems, or addition= al requirements, come up from those implementations/deployments, that IETF = is asked to help solving? Also, if I understood Keith correctly, he didn't suggest going to GSMA just= because he thinks it's a good thing to do - his claim was that one MUST go= to GSMA in order to get certain things done :) Regards, Christer L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta Mary = Barnes L=E4hetetty: 13. helmikuuta 2014 22:18 Vastaanottaja: DRAGE, Keith (Keith) Kopio: dispatch@ietf.org Aihe: Re: [dispatch] SIP and GSM/UMTS with OpenBTS On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith) > wrote: Ericsson is not the only vendor that sees a market for small cells, but the= expectation is that the products are built to the completed 3GPP standards= will be deployed in licensed spectrum by owners of that spectrum, although= the boxes may well be owned by 3rd parties. These deployments already exist. I see Jim has now identified that this proposal is for licensed GSM operato= rs in licensed GSM space. Personally, I would suggest if you believe the operators should be picking = this up, you take it to 3GPP where the operators are actually present. That= is the only way you will see it taken up by GSMA, which you will need to o= btain interoperator agreements to use this (e.g. roaming, shared networks).= 3GPP them works with IETF on any SIP extensions needed. [MB] One big problem with this proposal is that you must be a member of 3GP= P/GSMA to make contributions and to participate in meetings. And, I think having to first do the work in 3GPP and then bring it to IETF = would introduce a tremendous delay for something that's already been implem= ented/deployed. While they are proposing to reuse elements and protocols t= hat are part of an IMS network, the core issue they have is with interworki= ng SIP with the radio layer protocols. Certainly, one could implement all = the protocols that IMS uses and then use the 3GPP based specs and proprieta= ry headers to interwork with SIP in the Internet, but that would be terribl= y inefficient. [/MB] I would only see IETF having any direct part in this if the proposal was on= ly to use unlicensed spectrum by enterprises rather than licensed operators= , which Jim has negated. regards Keith ________________________________ From: Tim Panton new [mailto:thp@westhawk.co.uk] Sent: 13 February 2014 14:50 To: DRAGE, Keith (Keith) Cc: Harvind Samra; Ivo Sedlacek; dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) > wrote: Jumping in here, they are relevant in as much as there is no point in IETF = working on this if there is no known market for it. Usually those type of projects are published only on April 1st. So all Ivo is asking is for you to justify that it is worth other people wo= rking on this as well as yourselves. Perhaps if you identified the spectrum you believe is available for use in = the the countries identified, that would be useful. regards Keith Drage Ivo's employer seems to see a market for small cells, but looks to tie them= to existing operator IMS's through internet connections "owned by themselves or a partner". http://www.telecomlead.com/enterprise-networking/mwc-2014-ericsson-announce= -small-cell-service-20233/ Perhaps that's an April fools joke too (I can't see any avian carriers ment= ioned though)? It isn't up to the IETF to crown specific solutions. That's the market's jo= b. T. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_7594FB04B1934943A5C02806D1A2204B1D171872ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Mary,=

 = ;

I haven= 217;t followed this discussion, but: if this has “already been implem= ented/deployed”, what is IETF expected to do? Have some problems, or = additional requirements, come up from those implementations/deployments, that IETF is= asked to help solving?

 = ;

Also, if I= understood Keith correctly, he didn’t suggest going to GSMA just bec= ause he thinks it’s a good thing to do – his claim was that one MUST go to GSMA in order to get certain things done J

 = ;

Regards,

 = ;

Christer

 = ;

 = ;

 = ;

 = ;

 = ;

L=E4hett=E4j=E4: dispatch [mailto:dispatch-bounces@ietf.org] Puolesta Mary Barnes
L=E4hetetty: 13. helmikuuta 2014 22:18
Vastaanottaja: DRAGE, Keith (Keith)
Kopio: dispatch@ietf.org
Aihe: Re: [dispatch] SIP and GSM/UMTS with OpenBTS=

 

 

 

On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith= ) <k= eith.drage@alcatel-lucent.com> wrote:

Ericsson is not the only vendor that sees a mar= ket for small cells, but the expectation is that the products are built to = the completed 3GPP standards will be deployed in licensed spectrum by owners of that spectrum, although the boxes may well be owned = by 3rd parties.

 

These deployments already exist.

 

I see Jim has now identified that this proposal= is for licensed GSM operators in licensed GSM space.

 

Personally, I would suggest if you believe the = operators should be picking this up, you take it to 3GPP where the operator= s are actually present. That is the only way you will see it taken up by GSMA, which you will need to obtain interoperator agreement= s to use this (e.g. roaming, shared networks). 3GPP them works with IETF on= any SIP extensions needed.

[MB] One big problem with this proposal is that you = must be a member of 3GPP/GSMA to make contributions and to participate in m= eetings.    

 

And, I think having to first do the work in 3GPP and= then bring it to IETF would introduce a tremendous delay for something tha= t's already been implemented/deployed.  While they are proposing to re= use elements and protocols that are part of an IMS network, the core issue they have is with interworking SIP with = the radio layer protocols.  Certainly, one could implement all the pro= tocols that IMS uses and then use the 3GPP based specs and proprietary head= ers to interwork with SIP in the Internet, but that would be terribly inefficient. 

[/MB] 

 

I would only see IETF having any direct part in= this if the proposal was only to use unlicensed spectrum by enterprises ra= ther than licensed operators, which Jim has negated.

 

regards

 

Keith

 

From: Tim Panton n= ew [mailto:thp@west= hawk.co.uk]

Sent: 13 February = 2014 14:50
To: DRAGE, Keith (Keith)
Cc: Harvind Samra; Ivo Sedlacek; dispatch@ietf.org


Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

 

 

On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) <<= a href=3D"mailto:keith.drage@alcatel-lucent.com" target=3D"_blank">keith.dr= age@alcatel-lucent.com> wrote:



Jumping in here, they are relevant in as much a= s there is no point in IETF working on this if there is no known market for= it.

 

Usually those type of projects are published on= ly on April 1st.

 

So all Ivo is asking is for you to justify that= it is worth other people working on this as well as yourselves.

 

Perhaps if you identified the spectrum you beli= eve is available for use in the the countries identified, that would be use= ful.

 

regards

 

Keith Drage

 

Ivo's employer seems to see a market for small cells= , but looks to tie them to existing operator IMS's through =

internet connections "owned by themselves or a = partner".

Perhaps that's an April fools joke too (I can't see = any avian carriers mentioned though)?

 

It isn't up to the IETF to crown specific solutions.= That's the market's job.

 

T.

 

 

 


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

 

--_000_7594FB04B1934943A5C02806D1A2204B1D171872ESESSMB209erics_-- From nobody Thu Feb 13 13:08:36 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B30351A04EC for ; Thu, 13 Feb 2014 13:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh_cYhb7u7Sy for ; Thu, 13 Feb 2014 13:08:31 -0800 (PST) Received: from mail-ve0-x22d.google.com (mail-ve0-x22d.google.com [IPv6:2607:f8b0:400c:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F1B941A0376 for ; Thu, 13 Feb 2014 13:08:30 -0800 (PST) Received: by mail-ve0-f173.google.com with SMTP id jw12so1811503veb.32 for ; Thu, 13 Feb 2014 13:08:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=0uorWBqv2tyYJxIuRvkZyRMR4EIGIxmoKWJ+LNG6/f4=; b=GWeMmTbdgA1VuiokJEZ/keEAyMEIvK5IFly3r7MjGNT3BXyIb3Clwf4PTIkZPPqUb3 a1d+pIPzqwylR6jwNo6kDg2FESXehvM3bKgCLYXbdsIC6aIZOXPht3U2yYaMHNO+duMQ VvVNlC/VMVOvpCDHjnSWgkzL4DVfRrN2tmFkY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=0uorWBqv2tyYJxIuRvkZyRMR4EIGIxmoKWJ+LNG6/f4=; b=B3JV+KhRxhR113DIJ0q0dz8YuPAs3nIfCiaB+2qNjpy0Wvk0cmyyRryutubgQSrtDK zuu5xZoUTXUNRv6+4RuxqaL9uzFBrI2X8OyvV3NaFerc6q6BKxrE1mlWjHB34ESsoqH7 QjrMk8jBI1Odx8/tTOJp/FjiGc7uhBZiPEeHkJBjPiUiYGwxw7c/O13UXOffYiy9HDN4 qER31HO/tdIG+iUW7YLj3prSQofUIaeUhc6wfhkUUHRs4pzxH4ERlTgwAhgvJix5CTvv 3rJh46Ugkn06w1R7HPMXdcj6g26H4dEfhQjBviypjMIBT399+N+aO2wFXc278sr4Nu5/ TEZA== X-Gm-Message-State: ALoCoQljw8xivLmEnW7ikx6mrg+iBcnsFhUDOLXjiskJ9/jptoGKrRIUxsNIrIbgAXByQSwTPyXH MIME-Version: 1.0 X-Received: by 10.58.85.133 with SMTP id h5mr2306299vez.4.1392325709338; Thu, 13 Feb 2014 13:08:29 -0800 (PST) Received: by 10.58.187.114 with HTTP; Thu, 13 Feb 2014 13:08:29 -0800 (PST) In-Reply-To: <52FD2DC9.6090105@gmail.com> References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD2DC9.6090105@gmail.com> Date: Thu, 13 Feb 2014 21:08:29 +0000 Message-ID: From: Peter Dunkley To: DISPATCH Content-Type: multipart/alternative; boundary=047d7b86f0ba51304d04f25017fc Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/kCVMpV8m4SYHEaOHSFTrVbFX2-8 Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:08:33 -0000 --047d7b86f0ba51304d04f25017fc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, The problem with attempting to specify something like "TCP/WS/xxx" or "TCP/WSS/xxx" is that it will make the drafts easy to understand but might not actually help from an implementation point-of-view. Sure it'll help the implementer with respect to the specific RFC, but in the case of MSRP over WebSockets it won't help with the implementer create something that interoperates with legacy peers through the MSRP relay. This is a problem that BFCP might not suffer from, but this kind of interoperability is desirable and as a result even if this had been defined/recommended before the work on MSRP over WebSockets started "TCP/TLS/MSRP" would probably still be used in that draft (unless someone could find another way to ensure that legacy peers would accept the new SDP content without issue). Regards, Peter On 13 February 2014 20:40, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > Hi Mary, > > My point is exactly the opposite. We should not choose one or the other, > it is an issue that affects both drafts, and any upcoming X over websocke= t > draft, so I don't think it is a good idea to isolate the discussion in a > single draft and ignore what is happening outside. If not we will end up > with lots of different solutions for the same issue and developers (like > me) will get crazy when trying to implement it. > > Best regards > Sergio > El 13/02/2014 16:49, Mary Barnes escribi=F3: > > Sergio, > > The draft you mention is being discussed in the BFCPBIS WG and any > comments that others might have on that document should go to that list. > > It's not clear to me whether your suggestion is that changes are needed > to this MSRP document or whether you are just proposing to make the BFCPB= IS > consistent with this MSRP document? > > Mary. > > > On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > >> Hi, >> >> We also have recently published a different draft for BFCP over >> websockets: >> http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00 >> >> I beleive that we should harmonize who the WS transport is signaled and >> how to signal the WS version if also the "normal" TCP version is support= ed. >> >> In your case you seem to be using the same transport line TCP/MSRP and >> use the path to signal the ws part, in our case, we choose to signal it = in >> the transport TCP/WS/BFCP and include a new attribute ws-uri to signal t= he >> full url (I could not reuse the path attribute as it is restricted to ms= rp >> urls only). >> >> Best regards >> Sergio >> El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribi=F3: >> >>> Hi Mary - >>> >>> Thanks for taking the time to review the document. We have published a= n >>> -05 that (hopefully) addresses all your feedback. >>> >>> Inline, trimming to only the points requiring responses... >>> >>> >>> On Jan 10, 2014, at 5:58 PM, Mary Barnes >>> wrote: >>> >>> I have agreed to shepherd this document. I've reviewed the document i= n >>>> anticipation of doing the PROTO write-up and have the following commen= ts >>>> and questions. Ben Campbell has agreed to do the required expert revi= ew >>>> and that should be posted within the next week or so. This is also = a >>>> good time for anyone in the WG that hasn't previously reviewed this >>>> document to review and provide any final comments. Note, that this >>>> document was agreed to be AD sponsored around the IETF-86 timeframe. >>>> >>>> Regards, >>>> Mary. >>>> >>>> Review Summary: Almost ready. Comments & questions below. >>>> >>> >>> >>> 5) Section 10.1. Since securing the connection is just RECOMMENDED, >>>> what are the implications and risks if the MSRP traffic isn't transpor= ted >>>> over a secure connection? >>>> >>> Other review comments indicated that it was problematic to downgrade th= e >>> 4976 MUST requirement for TLS between a client and a server. Thus, the >>> document has been updated so that MSRP traffic transported over WebSock= ets >>> MUST be protected by using a secure WebSocket connection (i.e., using T= LS). >>> I believe this renders this point moot. >>> >>> >>> >>> 8) It's typical for documents that are updating existing RFCs to have = a >>>> section that summarizes the updates to the existing RFCs that are made= by >>>> this document. >>>> >>> This was the intent of Sections 5.2 and 5.3. Is this sufficient? Or di= d >>> you have something else in mind? >>> >>> Regards, >>> >>> Gonzalo >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --=20 Peter Dunkley Technical Director Crocodile RCS Ltd --047d7b86f0ba51304d04f25017fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

The problem with attempting to s= pecify something like "TCP/WS/xxx" or "TCP/WSS/xxx" is = that it will make the drafts easy to understand but might not actually help= from an implementation point-of-view.

Sure it'll help the implementer with respect to the= specific RFC, but in the case of MSRP over WebSockets it won't help wi= th the implementer create something that interoperates with legacy peers th= rough the MSRP relay. =A0This is a problem that BFCP might not suffer from,= but this kind of interoperability is desirable and as a result even if thi= s had been defined/recommended before the work on MSRP over WebSockets star= ted "TCP/TLS/MSRP" would probably still be used in that draft (un= less someone could find another way to ensure that legacy peers would accep= t the new SDP content without issue).

Regards,

Peter

<= /div>


On= 13 February 2014 20:40, Sergio Garcia Murillo <sergio.garci= a.murillo@gmail.com> wrote:
=20 =20 =20
Hi Mary,

My point is exactly the opposite. We should not choose one or the other, it is an issue that affects both drafts, and any upcoming X over websocket draft, so I don't think it is a good idea to isolate the discussion in a single draft and ignore what is happening outside. If not we will end up with lots of different solutions for the same issue and developers (like me) will get crazy when trying to implement it.

Best regards
Sergio
El 13/02/2014 16:49, Mary Barnes escribi=F3:
Sergio,

The draft you mention is being discussed in the BFCPBIS WG and any comments that others might have on that document should go to that list.

It's not clear to me whether your suggestion is that changes are needed to this MSRP document or whether you are just proposing to make the BFCPBIS consistent with this MSRP document?=A0

Mary.=A0


On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Hi,

We also have recently published a different draft for BFCP over websockets:
http://tools.ietf.org/html/draft-pascual-= bfcpbis-bfcp-websocket-00

I beleive that we should harmonize who the WS transport is signaled and how to signal the WS version if also the "normal" TCP version is supported.

In your case you seem to be using the same transport line TCP/MSRP and use the path to signal the ws part, in our case, we choose to signal it in the transport TCP/WS/BFCP and include a new attribute ws-uri to signal the full url (I could not reuse the path attribute as it is restricted to msrp urls only).

Best regards
Sergio
El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribi=F3:
Hi Mary -

Thanks for taking the time to review the document. =A0We have published an -05 that (hopefully) addresses all your feedback.

Inline, trimming to only the points requiring responses...


On Jan 10, 2014, at 5:58 PM, Mary Barnes <mary.ietf.barnes@gmail.= com> wrote:

I have agreed to shepherd this document. =A0I've reviewed the document in anticipation of doing the PROTO write-up and have the following comments and questions. =A0Ben Campbell has agreed to do the required expert review and that should be posted within the next week or so. =A0 =A0This is also a good time for anyone in the WG that hasn't previously reviewed this document to review and provide any final comments. =A0Note, that this document was agreed to be AD sponsored around the IETF-86 timeframe.

Regards,
Mary.

Review Summary: Almost ready. Comments & questions below.
<snip/>

5) Section 10.1. Since securing the connection is just RECOMMENDED, what are the implications and risks if the MSRP traffic isn't transported over a secure connection?
Other review comments indicated that it was problematic to downgrade the 4976 MUST requirement for TLS between a client and a server. Thus, the document has been updated so that MSRP traffic transported over WebSockets MUST be protected by using a secure WebSocket connection (i.e., using TLS). =A0I believe this renders this point moot.

<snip/>

8) It's typical for documents that are updating existing RFCs to have a section that summarizes the updates to the existing RFCs that are made by this document.
This was the intent of Sections 5.2 and 5.3. =A0Is this sufficient? Or did you have something else in mind?

Regards,

Gonzalo

_______________________________________________
dispatch mailing list
disp= atch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

_______________________________________________
dispatch mailing list
disp= atch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch



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




--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
--047d7b86f0ba51304d04f25017fc-- From nobody Thu Feb 13 13:18:37 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C78C1A04F1 for ; Thu, 13 Feb 2014 13:18:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMFLN5_IzuN8 for ; Thu, 13 Feb 2014 13:18:32 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C76091A04FE for ; Thu, 13 Feb 2014 13:18:31 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id u57so8015918wes.39 for ; Thu, 13 Feb 2014 13:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=yHScgyZPqf4ThcnnRKkwjiFnrVtw4eLDi2mO/dr2JiA=; b=lKDMxEaAt4RdVPcU16/eur2vgcDmHUQWy9Jp1fchYx+V+nI1Yb5lrSj2NtyRltEmlE 7F7pi9KCpb6YZHgf9x2gHA8s8CbfITZMpRk4aoiDmUkmcqY0yHv3xozEqtbemwWok6m0 oh39YCdkNzeMI85tsqOIz+LjRPzHwdR/ILIjdzx1bpGXAYscqgzPEVKuc7TwGd5wi50Q j4pyZX12Tn7jAaxwC6lxDfhzdem87Q36nCQq5hYbiqHRbaUvzg+w+PO1aq2AuFE7jS7Q gMQRKTrwJs9vjyPCpA3auy7mFOns9RF9i4Bsy/22D5wPHet/btFSVapkyVnaJWbfj+RP 2mww== X-Received: by 10.180.9.71 with SMTP id x7mr4187244wia.55.1392326310106; Thu, 13 Feb 2014 13:18:30 -0800 (PST) Received: from [192.168.0.192] ([95.61.111.78]) by mx.google.com with ESMTPSA id gc5sm8165049wib.0.2014.02.13.13.18.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 13:18:29 -0800 (PST) Message-ID: <52FD36A3.1020606@gmail.com> Date: Thu, 13 Feb 2014 22:18:27 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Peter Dunkley References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020501010105010100070100" Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/1_fPxKHt2SWv3DbSAcD8x0tV6Eg Cc: DISPATCH Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:18:35 -0000 This is a multi-part message in MIME format. --------------020501010105010100070100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi Peter, I think that you misunderstood me. I was not asking you to change the MSRP over websocket draft to set the transport to TCP/WSS/MSRP and do it like the BFCP over websocket draft, but to find a way that we could both use the same solution with the principles that you are mentioning, that is: -Do not break backward compatibility -Allow easy implementation for servers which wants to support both TCP/TLS and WS/WSS "flavors" In my case, I will implement both BFCP and MSRP over TCP and Websockets in my MCU, so my interest is genuine.. :) I have a doubt regarding the draft. If I understood it correctly, you are only considering P2P in he examples and using a msrp relay in the middle to be able to connect a WS to a non WS, but I am not sure how would you handle the case when you don't use a relay. Is that possible at all? Best regards Sergio El 13/02/2014 17:26, Peter Dunkley escribió: > Hello, > > The method chosen for advertising WebSockets in the SDP for MSRP was > picked because it was would enable interoperability with existing MSRP > implementations through an MSRP relay without requiring changes to > those implementations. In this scenario advertising WebSockets in the > SDP would mean that the existing implementation - which does not need > to support WebSockets (the MSRP relay deals with this) - would need to > be able to cope with seeing TCP/WSS/MSRP in the SDP. In all > probability existing implementations will not cope with seeing > "TCP/WSS/MSRP" in the SDP instead of "TCP/TLS/MSRP" - this would be a > big problem. > > I have no issue with consistency between the drafts using WebSockets > where possible, but in this case doing what is done in the BFCP draft > (explicitly putting TCP/WSS/MSRP into the SDP) may not be practical > (and in fact may be quite undesirable). > > Regards, > > Peter > > > > On 13 February 2014 16:07, Sergio Garcia Murillo > > wrote: > > What I mean is that I expect quite a lot of "over websocekts" > drafts and we should try to use the same solution for advertising > it in the SDP, and not have each one have their own way of > handling it. > > Best regards > Sergio > > El 13/02/2014 16:49, "Mary Barnes" > escribió: > > Sergio, > > The draft you mention is being discussed in the BFCPBIS WG and > any comments that others might have on that document should go > to that list. > > It's not clear to me whether your suggestion is that changes > are needed to this MSRP document or whether you are just > proposing to make the BFCPBIS consistent with this MSRP document? > > Mary. > > > On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia Murillo > > wrote: > > Hi, > > We also have recently published a different draft for BFCP > over websockets: > http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00 > > I beleive that we should harmonize who the WS transport is > signaled and how to signal the WS version if also the > "normal" TCP version is supported. > > In your case you seem to be using the same transport line > TCP/MSRP and use the path to signal the ws part, in our > case, we choose to signal it in the transport TCP/WS/BFCP > and include a new attribute ws-uri to signal the full url > (I could not reuse the path attribute as it is restricted > to msrp urls only). > > Best regards > Sergio > El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribió: > > Hi Mary - > > Thanks for taking the time to review the document. We > have published an -05 that (hopefully) addresses all > your feedback. > > Inline, trimming to only the points requiring responses... > > > On Jan 10, 2014, at 5:58 PM, Mary Barnes > > wrote: > > I have agreed to shepherd this document. I've > reviewed the document in anticipation of doing the > PROTO write-up and have the following comments and > questions. Ben Campbell has agreed to do the > required expert review and that should be posted > within the next week or so. This is also a good > time for anyone in the WG that hasn't previously > reviewed this document to review and provide any > final comments. Note, that this document was > agreed to be AD sponsored around the IETF-86 > timeframe. > > Regards, > Mary. > > Review Summary: Almost ready. Comments & questions > below. > > > > 5) Section 10.1. Since securing the connection is > just RECOMMENDED, what are the implications and > risks if the MSRP traffic isn't transported over a > secure connection? > > Other review comments indicated that it was > problematic to downgrade the 4976 MUST requirement for > TLS between a client and a server. Thus, the document > has been updated so that MSRP traffic transported over > WebSockets MUST be protected by using a secure > WebSocket connection (i.e., using TLS). I believe > this renders this point moot. > > > > 8) It's typical for documents that are updating > existing RFCs to have a section that summarizes > the updates to the existing RFCs that are made by > this document. > > This was the intent of Sections 5.2 and 5.3. Is this > sufficient? Or did you have something else in mind? > > Regards, > > Gonzalo > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > -- > Peter Dunkley > Technical Director > Crocodile RCS Ltd --------------020501010105010100070100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Peter,

I think that you misunderstood me. I was not asking you to change the MSRP over websocket draft to set the transport to TCP/WSS/MSRP and do it like the BFCP over websocket draft, but to find a way that we could both use the same solution with the principles that you are mentioning, that is:

-Do not break backward compatibility
-Allow easy implementation for servers which wants to support both TCP/TLS and WS/WSS "flavors"

In my case, I will implement both BFCP and MSRP over TCP and Websockets in my MCU, so my interest is genuine.. :)

I have a doubt regarding the draft. If I understood it correctly, you are only considering P2P in he examples and using a msrp relay in the middle to be able to connect a WS to a non WS, but I am not sure how would you handle the case when you don't use a relay. Is that possible at all?

Best regards
Sergio
El 13/02/2014 17:26, Peter Dunkley escribió:
Hello,

The method chosen for advertising WebSockets in the SDP for MSRP was picked because it was would enable interoperability with existing MSRP implementations through an MSRP relay without requiring changes to those implementations.  In this scenario advertising WebSockets in the SDP would mean that the existing implementation - which does not need to support WebSockets (the MSRP relay deals with this) - would need to be able to cope with seeing TCP/WSS/MSRP in the SDP.  In all probability existing implementations will not cope with seeing "TCP/WSS/MSRP" in the SDP instead of "TCP/TLS/MSRP" - this would be a big problem.

I have no issue with consistency between the drafts using WebSockets where possible, but in this case doing what is done in the BFCP draft (explicitly putting TCP/WSS/MSRP into the SDP) may not be practical (and in fact may be quite undesirable).

Regards,

Peter



On 13 February 2014 16:07, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

What I mean is that I expect quite a lot of "over websocekts" drafts and we should try to use the same solution for advertising it in the SDP, and not have each one have their own way of handling it.

Best regards
Sergio

El 13/02/2014 16:49, "Mary Barnes" <mary.ietf.barnes@gmail.com> escribió:

Sergio,

The draft you mention is being discussed in the BFCPBIS WG and any comments that others might have on that document should go to that list.

It's not clear to me whether your suggestion is that changes are needed to this MSRP document or whether you are just proposing to make the BFCPBIS consistent with this MSRP document? 

Mary. 


On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
Hi,

We also have recently published a different draft for BFCP over websockets:
http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00

I beleive that we should harmonize who the WS transport is signaled and how to signal the WS version if also the "normal" TCP version is supported.

In your case you seem to be using the same transport line TCP/MSRP and use the path to signal the ws part, in our case, we choose to signal it in the transport TCP/WS/BFCP and include a new attribute ws-uri to signal the full url (I could not reuse the path attribute as it is restricted to msrp urls only).

Best regards
Sergio
El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribió:
Hi Mary -

Thanks for taking the time to review the document.  We have published an -05 that (hopefully) addresses all your feedback.

Inline, trimming to only the points requiring responses...


On Jan 10, 2014, at 5:58 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

I have agreed to shepherd this document.  I've reviewed the document in anticipation of doing the PROTO write-up and have the following comments and questions.  Ben Campbell has agreed to do the required expert review and that should be posted within the next week or so.    This is also a good time for anyone in the WG that hasn't previously reviewed this document to review and provide any final comments.  Note, that this document was agreed to be AD sponsored around the IETF-86 timeframe.

Regards,
Mary.

Review Summary: Almost ready. Comments & questions below.
<snip/>

5) Section 10.1. Since securing the connection is just RECOMMENDED, what are the implications and risks if the MSRP traffic isn't transported over a secure connection?
Other review comments indicated that it was problematic to downgrade the 4976 MUST requirement for TLS between a client and a server. Thus, the document has been updated so that MSRP traffic transported over WebSockets MUST be protected by using a secure WebSocket connection (i.e., using TLS).  I believe this renders this point moot.

<snip/>

8) It's typical for documents that are updating existing RFCs to have a section that summarizes the updates to the existing RFCs that are made by this document.
This was the intent of Sections 5.2 and 5.3.  Is this sufficient? Or did you have something else in mind?

Regards,

Gonzalo

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

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


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




--
Peter Dunkley
Technical Director
Crocodile RCS Ltd

--------------020501010105010100070100-- From nobody Thu Feb 13 13:25:01 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA111A0504 for ; Thu, 13 Feb 2014 13:24:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR0K3MsAeKRR for ; Thu, 13 Feb 2014 13:24:56 -0800 (PST) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id F3DF21A0429 for ; Thu, 13 Feb 2014 13:24:55 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id db12so8750783veb.25 for ; Thu, 13 Feb 2014 13:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EGJLUxQAVoLXJWCwEN3U4bNeNWAGNaMqmRmeopsNVCo=; b=Xbjz/ulGA3HO+4t9RfjQ0pEAibkcSI4gXwgfsRIvAsws4qmF15kZb9SqDfXvWZm5T7 bL29hoU5GigYaa7COC/fc6PdKxroqcHUzSPQSt5Oz9FL316V6n0I2gZS7Q1f9//c0acm yIqh3QD4a4cK0r8A3GvwMQrxSUxiO22n2vl3Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EGJLUxQAVoLXJWCwEN3U4bNeNWAGNaMqmRmeopsNVCo=; b=IJo2YRRyG9a5WvDQUBN1JW435eqkg5BGbulqm3r7cJ/FnQU1ZD68wkryhOh4hDOzYM pyldjGiG6jeYQeW85ye7X/Qcn3H6WkIhC8D9IFtaRWcYd/Bjw2u/R9X/uD70pFsofWvP mcPJMLoHEK3H1fosN3LDTv+BbvRUWup4CyfkYBzFAs4i23hhyuU0t9iSD0wixkv54g+i 8jJeugFhz1pl7DDk3/TU+6sU86FTTIUFvVeBqZRRrKgKpe1YoIuf9WNCiqhWnt/Ksi5K TypzP6edoBb9qg6GCDE9XExjrmu6su6ZtM0S8WLqe5XUrgFOr0YxO1dWNwpZE/1qpVA2 Ky7w== X-Gm-Message-State: ALoCoQmXjHBjCGEEXSsN5IWsDAc3piw+mgn0KPAV1IQbgVVV0NJM4M5InpzX/gIyzIgQk2MaJ1sh MIME-Version: 1.0 X-Received: by 10.220.92.135 with SMTP id r7mr2326554vcm.11.1392326694526; Thu, 13 Feb 2014 13:24:54 -0800 (PST) Received: by 10.58.187.114 with HTTP; Thu, 13 Feb 2014 13:24:54 -0800 (PST) In-Reply-To: <52FD36A3.1020606@gmail.com> References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD36A3.1020606@gmail.com> Date: Thu, 13 Feb 2014 21:24:54 +0000 Message-ID: From: Peter Dunkley To: Sergio Garcia Murillo Content-Type: multipart/alternative; boundary=047d7b66f5fb09fb4a04f25052a8 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/DJfdCHWRXU3PJGYrk-gqee-zAj0 Cc: DISPATCH Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:24:59 -0000 --047d7b66f5fb09fb4a04f25052a8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, Because WebSockets is an asynchronous protocol two MSRP peers (that are clients) cannot use MSRP over WebSockets. It could be possible for a WebSocket server to be an MSRP peer (for example, in the scenario where the server is B2B'ing MSRP like an SBC will do in IMS for CEMA). Christer Holmberg has expressed an interest in this scenario and may provide language relating to it for the draft - but for now this is out of the scope of the draft which explicitly deals just with with the MSRP through relay scenario. If Christer does provide some additional language then the draft will cover this without relay scenario, but if not nothing in the draft should prevent someone from addressing it in the future with an additional document (should there be interest). >From my point-of-view I am only interested in the with relay scenario at this time. Regards, Peter On 13 February 2014 21:18, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > Hi Peter, > > I think that you misunderstood me. I was not asking you to change the MSR= P > over websocket draft to set the transport to TCP/WSS/MSRP and do it like > the BFCP over websocket draft, but to find a way that we could both use t= he > same solution with the principles that you are mentioning, that is: > > -Do not break backward compatibility > -Allow easy implementation for servers which wants to support both TCP/TL= S > and WS/WSS "flavors" > > In my case, I will implement both BFCP and MSRP over TCP and Websockets i= n > my MCU, so my interest is genuine.. :) > > I have a doubt regarding the draft. If I understood it correctly, you are > only considering P2P in he examples and using a msrp relay in the middle = to > be able to connect a WS to a non WS, but I am not sure how would you hand= le > the case when you don't use a relay. Is that possible at all? > > Best regards > Sergio > El 13/02/2014 17:26, Peter Dunkley escribi=F3: > > Hello, > > The method chosen for advertising WebSockets in the SDP for MSRP was > picked because it was would enable interoperability with existing MSRP > implementations through an MSRP relay without requiring changes to those > implementations. In this scenario advertising WebSockets in the SDP woul= d > mean that the existing implementation - which does not need to support > WebSockets (the MSRP relay deals with this) - would need to be able to co= pe > with seeing TCP/WSS/MSRP in the SDP. In all probability existing > implementations will not cope with seeing "TCP/WSS/MSRP" in the SDP inste= ad > of "TCP/TLS/MSRP" - this would be a big problem. > > I have no issue with consistency between the drafts using WebSockets > where possible, but in this case doing what is done in the BFCP draft > (explicitly putting TCP/WSS/MSRP into the SDP) may not be practical (and = in > fact may be quite undesirable). > > Regards, > > Peter > > > > On 13 February 2014 16:07, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > >> What I mean is that I expect quite a lot of "over websocekts" drafts and >> we should try to use the same solution for advertising it in the SDP, an= d >> not have each one have their own way of handling it. >> >> Best regards >> Sergio >> El 13/02/2014 16:49, "Mary Barnes" >> escribi=F3: >> >> Sergio, >>> >>> The draft you mention is being discussed in the BFCPBIS WG and any >>> comments that others might have on that document should go to that list= . >>> >>> It's not clear to me whether your suggestion is that changes are >>> needed to this MSRP document or whether you are just proposing to make = the >>> BFCPBIS consistent with this MSRP document? >>> >>> Mary. >>> >>> >>> On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia Murillo < >>> sergio.garcia.murillo@gmail.com> wrote: >>> >>>> Hi, >>>> >>>> We also have recently published a different draft for BFCP over >>>> websockets: >>>> http://tools.ietf.org/html/draft-pascual-bfcpbis-bfcp-websocket-00 >>>> >>>> I beleive that we should harmonize who the WS transport is signaled an= d >>>> how to signal the WS version if also the "normal" TCP version is suppo= rted. >>>> >>>> In your case you seem to be using the same transport line TCP/MSRP and >>>> use the path to signal the ws part, in our case, we choose to signal i= t in >>>> the transport TCP/WS/BFCP and include a new attribute ws-uri to signal= the >>>> full url (I could not reuse the path attribute as it is restricted to = msrp >>>> urls only). >>>> >>>> Best regards >>>> Sergio >>>> El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribi=F3: >>>> >>>>> Hi Mary - >>>>> >>>>> Thanks for taking the time to review the document. We have published >>>>> an -05 that (hopefully) addresses all your feedback. >>>>> >>>>> Inline, trimming to only the points requiring responses... >>>>> >>>>> >>>>> On Jan 10, 2014, at 5:58 PM, Mary Barnes >>>>> wrote: >>>>> >>>>> I have agreed to shepherd this document. I've reviewed the document >>>>>> in anticipation of doing the PROTO write-up and have the following c= omments >>>>>> and questions. Ben Campbell has agreed to do the required expert re= view >>>>>> and that should be posted within the next week or so. This is als= o a >>>>>> good time for anyone in the WG that hasn't previously reviewed this >>>>>> document to review and provide any final comments. Note, that this >>>>>> document was agreed to be AD sponsored around the IETF-86 timeframe. >>>>>> >>>>>> Regards, >>>>>> Mary. >>>>>> >>>>>> Review Summary: Almost ready. Comments & questions below. >>>>>> >>>>> >>>>> >>>>> 5) Section 10.1. Since securing the connection is just RECOMMENDED, >>>>>> what are the implications and risks if the MSRP traffic isn't transp= orted >>>>>> over a secure connection? >>>>>> >>>>> Other review comments indicated that it was problematic to downgrade >>>>> the 4976 MUST requirement for TLS between a client and a server. Thus= , the >>>>> document has been updated so that MSRP traffic transported over WebSo= ckets >>>>> MUST be protected by using a secure WebSocket connection (i.e., using= TLS). >>>>> I believe this renders this point moot. >>>>> >>>>> >>>>> >>>>> 8) It's typical for documents that are updating existing RFCs to hav= e >>>>>> a section that summarizes the updates to the existing RFCs that are = made by >>>>>> this document. >>>>>> >>>>> This was the intent of Sections 5.2 and 5.3. Is this sufficient? Or >>>>> did you have something else in mind? >>>>> >>>>> Regards, >>>>> >>>>> Gonzalo >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> > > > -- > Peter Dunkley > Technical Director > Crocodile RCS Ltd > > > --=20 Peter Dunkley Technical Director Crocodile RCS Ltd --047d7b66f5fb09fb4a04f25052a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

Because WebSockets is an asynchr= onous protocol two MSRP peers (that are clients) cannot use MSRP over WebSo= ckets.

It could be possible for a WebSocket server= to be an MSRP peer (for example, in the scenario where the server is B2B&#= 39;ing MSRP like an SBC will do in IMS for CEMA). =A0Christer Holmberg has = expressed an interest in this scenario and may provide language relating to= it for the draft - but for now this is out of the scope of the draft which= explicitly deals just with with the MSRP through relay scenario. =A0If Chr= ister does provide some additional language then the draft will cover this = without relay scenario, but if not nothing in the draft should prevent some= one from addressing it in the future with an additional document (should th= ere be interest).

From my point-of-view I am only interested in the with = relay scenario at this time.

Regards,

Peter


On 13 February 2014 21:18, Sergio Garcia Murillo <sergio.gar= cia.murillo@gmail.com> wrote:
=20 =20 =20
Hi Peter,

I think that you misunderstood me. I was not asking you to change the MSRP over websocket draft to set the transport to TCP/WSS/MSRP and do it like the BFCP over websocket draft, but to find a way that we could both use the same solution with the principles that you are mentioning, that is:

-Do not break backward compatibility
-Allow easy implementation for servers which wants to support both TCP/TLS and WS/WSS "flavors"

In my case, I will implement both BFCP and MSRP over TCP and Websockets in my MCU, so my interest is genuine.. :)

I have a doubt regarding the draft. If I understood it correctly, you are only considering P2P in he examples and using a msrp relay in the middle to be able to connect a WS to a non WS, but I am not sure how would you handle the case when you don't use a relay. Is that possible at all?

Best regards
Sergio
El 13/02/2014 17:26, Peter Dunkley escribi=F3:
Hello,

The method chosen for advertising WebSockets in the SDP for MSRP was picked because it was would enable interoperability with existing MSRP implementations through an MSRP relay without requiring changes to those implementations. =A0In this scenario advertising WebSockets in the SDP would mean that the existing implementation - which does not need to support WebSockets (the MSRP relay deals with this) - would need to be able to cope with seeing TCP/WSS/MSRP in the SDP. =A0In all probability existing implementations will not cope with seeing "TCP/WSS/MSRP" in the SDP instead of "TCP/TLS/MSRP= " - this would be a big problem.

I have no issue with consistency between the drafts using WebSockets where possible, but in this case doing what is done in the BFCP draft (explicitly putting TCP/WSS/MSRP into the SDP) may not be practical (and in fact may be quite undesirable).

Regards,

Peter



On 13 February 2014 16:07, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:

What I mean is that I expect quite a lot of "over websocekts" drafts and we should try to use t= he same solution for advertising it in the SDP, and not have each one have their own way of handling it.

Best regards
Sergio

El 13/02/2014 16:49, "Mary Barn= es" <mary.ietf.barnes@gmail.com> escribi=F3:

Sergio,

The draft you mention is being discussed in the BFCPBIS WG and any comments that others might have on that document should go to that list.

It's not clear to me whether your suggestion is that changes are needed to this MSRP document or whether you are just proposing to make the BFCPBIS consistent with this MSRP document?=A0

Mary.=A0


On Thu, Feb 13, 2014 at 9:38 AM, Sergio Garcia Murillo &l= t;serg= io.garcia.murillo@gmail.com> wrote:
Hi,

We also have recently published a different draft for BFCP over websockets:
http://tools.ietf.org/html/= draft-pascual-bfcpbis-bfcp-websocket-00

I beleive that we should harmonize who the WS transport is signaled and how to signal the WS version if also the "normal" TCP versio= n is supported.

In your case you seem to be using the same transport line TCP/MSRP and use the path to signal the ws part, in our case, we choose to signal it in the transport TCP/WS/BFCP and include a new attribute ws-uri to signal the full url (I could not reuse the path attribute as it is restricted to msrp urls only).

Best regards
Sergio
El 13/02/2014 16:17, Gonzalo Salgueiro (gsalguei) escribi=F3:
Hi Mary -

Thanks for taking the time to review the document. =A0We have published an -05 that (hopefully) addresses all your feedback.
Inline, trimming to only the points requiring responses...


On Jan 10, 2014, at 5:58 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

I have agreed to shepherd this document. =A0I've reviewed the docume= nt in anticipation of doing the PROTO write-up and have the following comments and questions. =A0Ben Campbell has agreed to do the required expert review and that should be posted within the next week or so. =A0 =A0This i= s also a good time for anyone in the WG that hasn't previously reviewed this document to review and provide any final comments. =A0Note, that this document was agreed to be AD sponsored around the IETF-86 timeframe.

Regards,
Mary.

Review Summary: Almost ready. Comments & questions below.
<snip/>

5) Section 10.1. Since securing the connection is just RECOMMENDED, what are the implications and risks if the MSRP traffic isn't transported over a secure connection?
Other review comments indicated that it was problematic to downgrade the 4976 MUST requirement for TLS between a client and a server. Thus, the document has been updated so that MSRP traffic transported over WebSockets MUST be protected by using a secure WebSocket connection (i.e., using TLS). =A0I believe this renders this point moot.

<snip/>

8) It's typical for documents that ar= e updating existing RFCs to have a section that summarizes the updates to the existing RFCs that are made by this document.
This was the intent of Sections 5.2 and 5.3. =A0Is this sufficient? Or did you have something else in mind?

Regards,

Gonzalo

_____________________________________________= __
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispa= tch

_____________________________________________= __
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispa= tch


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




--
Peter Dunkley
Technical Director
Crocodile RCS Ltd<= /div>




--
Peter Dunkley
<= div>Technical Director
Crocodile RCS Ltd
--047d7b66f5fb09fb4a04f25052a8-- From nobody Thu Feb 13 13:26:35 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238761A053D for ; Thu, 13 Feb 2014 13:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0h77OsSLaZ_l for ; Thu, 13 Feb 2014 13:26:31 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id E69621A0534 for ; Thu, 13 Feb 2014 13:26:30 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id q58so7899862wes.7 for ; Thu, 13 Feb 2014 13:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=seMW03MAplgt30Dtv2Ys/2emVAqCfPMIR93f/w/uZMY=; b=nPnvCtOlfn9vLOVvjqVEsCBNzRv1LOniQXLYrUcuCCT7go2TrMn1n9xli5Lhyf5EcP yFFHJLl3rLECls+WnZkj9/utwhM7P2fdsdlfzqEQN3xxY8pnQz4/OB8lfGhbuN5WHIO2 hLGw3msgJ0QZsJJKx+iHHd/1KM6w9zyjGryjT1rk3H7sAc2OXyiYlTmZKLE7QUuG2JPf lzIXkonHw62DxO6tPCAFHxXGkVmqbZV84GqtCJ+f7fVKN/Z1wjUirSYu/mrqxQGdP8Z1 rhKFOsgXSEvRDfSKaTQSqg9QrxLbJOwzafdh7fxYWegemSU8/HelAIww20orCiNgCKVy JaBA== X-Received: by 10.194.110.135 with SMTP id ia7mr3130831wjb.5.1392326789128; Thu, 13 Feb 2014 13:26:29 -0800 (PST) Received: from [192.168.0.192] ([95.61.111.78]) by mx.google.com with ESMTPSA id ff9sm16832727wib.11.2014.02.13.13.26.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 13:26:28 -0800 (PST) Message-ID: <52FD3883.6050402@gmail.com> Date: Thu, 13 Feb 2014 22:26:27 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD112B.5040209@alum.mit.edu> <52FD2AE0.7060600@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Y6EiVFOPVBq8HEAIiCB-oCMuSH0 Subject: Re: [dispatch] X over websockets X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:26:33 -0000 El 13/02/2014 22:01, Peter Dunkley escribió: > Hello, > > Wasn't Sergio's point about what the terminology (for example, within > SDP) should be rather than whether WebSockets is appropriate as a > transport or not? And isn't this a totally separate issue from the > WebSockets vs. WebRTC question? Yes and no. My point was that all "X over websockets" will have some common issues, so instead of having the same discussion every time, it would be better if we could address them once and for all, so when someone wants to propose a new "X", it does not have to spend time and effort on that issues. Best regards Sergio From nobody Thu Feb 13 13:32:33 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31081A0544 for ; Thu, 13 Feb 2014 13:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsPECEW8idsQ for ; Thu, 13 Feb 2014 13:32:28 -0800 (PST) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id D6E311A0547 for ; Thu, 13 Feb 2014 13:32:27 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id w20so8703481vbb.13 for ; Thu, 13 Feb 2014 13:32:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=N5LRZ1gsGaDxNHRJphc61c7apPQfBZzTFjks5GnQGi8=; b=BDTZ/yhrYAau1rhy0cRjJu1N81Ao8k7FEatd/VTsVFwwoYUORBv0q7Xg5u5Eub3WRq lQI1RPYzB7/LX7/OgQ7+bfhbAsUgqQVTDAOj9opE9dMHPvYdqnqBrSuuREgoCoUGe7kJ K0obnFTP+O3RzUO1TIyUHyFnfcHnMM/B9USHk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=N5LRZ1gsGaDxNHRJphc61c7apPQfBZzTFjks5GnQGi8=; b=hHm/UIVCaiAjJqqyX5Q1sxXDLcYibCUuFGYir7ugKHYg+BD/6VddNl9tARcnqGqg0p 3QGbdSGGf1GzFx+TcSBybAlgYoSRMvkyd1jXMJaCqt6CT72ixlcAmzJ+07ICLttVmOAv LYXiyD9a5UH+GpnvlOQrXzXs9WwNROdDjtQOGWxYDlWiRbdRVtwTaGMsMaRiKkDxhzq7 vmZr+w22whO8dzHeEC//bGMmZX0gFh10UBCXgN8WOp0y/ugBIav+ZwVOmHB0D1yrkXw3 953N9AtrNhowjtOH7h9zz3xpTFqLYUjrifNFsnKSQD5T7KP2naGKsQGeWZgZQbRi5J63 lIIA== X-Gm-Message-State: ALoCoQkddyo9nfAhVa6wbG8yOTkbANKO1FsVBS4RZGoFsIzPUwbMGeriKN4sRDUpj/MLC8XXaECo MIME-Version: 1.0 X-Received: by 10.53.0.230 with SMTP id bb6mr1268369vdd.39.1392327146380; Thu, 13 Feb 2014 13:32:26 -0800 (PST) Received: by 10.58.187.114 with HTTP; Thu, 13 Feb 2014 13:32:26 -0800 (PST) In-Reply-To: <52FD3883.6050402@gmail.com> References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD112B.5040209@alum.mit.edu> <52FD2AE0.7060600@gmail.com> <52FD3883.6050402@gmail.com> Date: Thu, 13 Feb 2014 21:32:26 +0000 Message-ID: From: Peter Dunkley To: "dispatch@ietf.org" Content-Type: multipart/alternative; boundary=001a1133f56ef8b5be04f2506c51 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Lnu2AS_psqt8k6m_b0V-2oDsHj0 Subject: Re: [dispatch] X over websockets X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:32:30 -0000 --001a1133f56ef8b5be04f2506c51 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My point was more that if we are going to have a discussion about how we refer to WebSockets (in SDP or elsewhere) then let's have it, but let's also keep it separate from a reopening of the WebSockets vs DataChannel discussion. Which is the right transport (WebSockets/DataChannel) is a use-case specific thing. I don't see the need for any sort of "beauty contest" as this is more like the difference between using TCP vs UDP - some things work on both and some are better suited to one than the other. Why would we having this "contest" at all, it just doesn't make sense to me. Some things will be on WebSockets, some things will be on DataChannel, some things will be on both, and what is wrong with that? On 13 February 2014 21:26, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > El 13/02/2014 22:01, Peter Dunkley escribi=F3: > > Hello, >> >> Wasn't Sergio's point about what the terminology (for example, within >> SDP) should be rather than whether WebSockets is appropriate as a transp= ort >> or not? And isn't this a totally separate issue from the WebSockets vs. >> WebRTC question? >> > > Yes and no. My point was that all "X over websockets" will have some > common issues, so instead of having the same discussion every time, it > would be better if we could address them once and for all, so when someon= e > wants to propose a new "X", it does not have to spend time and effort on > that issues. > > > Best regards > Sergio > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 Peter Dunkley Technical Director Crocodile RCS Ltd --001a1133f56ef8b5be04f2506c51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My point was more that if we are going to have a discussio= n about how we refer to WebSockets (in SDP or elsewhere) then let's hav= e it, but let's also keep it separate from a reopening of the WebSocket= s vs DataChannel discussion.

Which is the right transport (WebSockets/DataChannel) is a u= se-case specific thing. =A0I don't see the need for any sort of "b= eauty contest" as this is more like the difference between using TCP v= s UDP - some things work on both and some are better suited to one than the= other. =A0Why would we having this "contest" at all, it just doe= sn't make sense to me. =A0Some things will be on WebSockets, some thing= s will be on DataChannel, some things will be on both, and what is wrong wi= th that?



On 13 February 2014 21:26, Sergio Garcia Murillo = <se= rgio.garcia.murillo@gmail.com> wrote:
El 13/02/2014 22:01, Peter Dunkley escribi= =F3:

Hello,

Wasn't Sergio's point about what the terminology (for example, with= in SDP) should be rather than whether WebSockets is appropriate as a transp= ort or not? =A0And isn't this a totally separate issue from the WebSock= ets vs. WebRTC question?

Yes and no. My point was that all "X over websockets" will have s= ome common issues, so instead of having the same discussion every time, it = would be better if we could address them once and for all, so when someone = wants to propose a new "X", it does not have to spend time and ef= fort on that issues.


Best regards
Sergio

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



--
=
Peter Dunkley
Technical Director
Crocodile RCS Ltd
--001a1133f56ef8b5be04f2506c51-- From nobody Thu Feb 13 13:37:55 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3FE31A0555 for ; Thu, 13 Feb 2014 13:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ms1qvbTv_4x for ; Thu, 13 Feb 2014 13:37:52 -0800 (PST) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id ACD351A0520 for ; Thu, 13 Feb 2014 13:37:51 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id q59so7955396wes.6 for ; Thu, 13 Feb 2014 13:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=d1lW6stwq8vynuo9WgkfQOoBRGvWoZ0YBDIiGnCO3JQ=; b=nHy/IHYv7T5tlug+ls72w4QeFTSESo6e3A/czmRmSpQ43hPuOVnWkcNPG/r1NGvxJ6 JZlSodDZk58SbE3EJmWABgtXmg4VaoX8WSOLxcz1sWIMNpasx2kS8eeAE/ajXK2BwEge rjivcxRG9yKphfb36Znnw5ZBQR2PbaNdGH/9PMuBX40aBOeoEY6W3/qxwVo5D0aimnqp Ixv+A27voYP9lp0k23wCasT1Bo6xkw3tMaH5daFddgwAlnC+n/4echS5CGFsS/s99gKo +eqlUILo9Qqv8oMVjKisayZAx05INGNdE4n84YgYApIo5H9UYJhZNpFUG+I5YElT6cYf GI3w== X-Received: by 10.194.170.133 with SMTP id am5mr3153962wjc.42.1392327469835; Thu, 13 Feb 2014 13:37:49 -0800 (PST) Received: from [192.168.0.192] ([95.61.111.78]) by mx.google.com with ESMTPSA id uq2sm7513783wjc.5.2014.02.13.13.37.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 13:37:48 -0800 (PST) Message-ID: <52FD3B2B.9030905@gmail.com> Date: Thu, 13 Feb 2014 22:37:47 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD112B.5040209@alum.mit.edu> <52FD2AE0.7060600@gmail.com> <52FD3883.6050402@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040105020104060600080002" Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/CJMeWT_7uEpwUxnw8-sgDSf2wXM Subject: Re: [dispatch] X over websockets X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:37:54 -0000 This is a multi-part message in MIME format. --------------040105020104060600080002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit I completely agree, and I have argued and discussed about it in the past, but the topic keeps showing up in each draft discussion. So I would prefer to do something to prevent having the same discussion again and again in the future. Best regards Sergio El 13/02/2014 22:32, Peter Dunkley escribió: > My point was more that if we are going to have a discussion about how > we refer to WebSockets (in SDP or elsewhere) then let's have it, but > let's also keep it separate from a reopening of the WebSockets vs > DataChannel discussion. > > Which is the right transport (WebSockets/DataChannel) is a use-case > specific thing. I don't see the need for any sort of "beauty contest" > as this is more like the difference between using TCP vs UDP - some > things work on both and some are better suited to one than the other. > Why would we having this "contest" at all, it just doesn't make sense > to me. Some things will be on WebSockets, some things will be on > DataChannel, some things will be on both, and what is wrong with that? > > > > On 13 February 2014 21:26, Sergio Garcia Murillo > > wrote: > > El 13/02/2014 22:01, Peter Dunkley escribió: > > Hello, > > Wasn't Sergio's point about what the terminology (for example, > within SDP) should be rather than whether WebSockets is > appropriate as a transport or not? And isn't this a totally > separate issue from the WebSockets vs. WebRTC question? > > > Yes and no. My point was that all "X over websockets" will have > some common issues, so instead of having the same discussion every > time, it would be better if we could address them once and for > all, so when someone wants to propose a new "X", it does not have > to spend time and effort on that issues. > > > Best regards > Sergio > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > -- > Peter Dunkley > Technical Director > Crocodile RCS Ltd > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --------------040105020104060600080002 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
I completely agree, and I have argued and discussed about it in the past, but the topic keeps showing up in each draft discussion. So I would prefer to do something to prevent having the same discussion again and again in the future.

Best regards
Sergio
El 13/02/2014 22:32, Peter Dunkley escribió:
My point was more that if we are going to have a discussion about how we refer to WebSockets (in SDP or elsewhere) then let's have it, but let's also keep it separate from a reopening of the WebSockets vs DataChannel discussion.

Which is the right transport (WebSockets/DataChannel) is a use-case specific thing.  I don't see the need for any sort of "beauty contest" as this is more like the difference between using TCP vs UDP - some things work on both and some are better suited to one than the other.  Why would we having this "contest" at all, it just doesn't make sense to me.  Some things will be on WebSockets, some things will be on DataChannel, some things will be on both, and what is wrong with that?



On 13 February 2014 21:26, Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
El 13/02/2014 22:01, Peter Dunkley escribió:

Hello,

Wasn't Sergio's point about what the terminology (for example, within SDP) should be rather than whether WebSockets is appropriate as a transport or not?  And isn't this a totally separate issue from the WebSockets vs. WebRTC question?

Yes and no. My point was that all "X over websockets" will have some common issues, so instead of having the same discussion every time, it would be better if we could address them once and for all, so when someone wants to propose a new "X", it does not have to spend time and effort on that issues.


Best regards
Sergio

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



--
Peter Dunkley
Technical Director
Crocodile RCS Ltd


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

--------------040105020104060600080002-- From nobody Thu Feb 13 13:39:00 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC3B1A051C for ; Thu, 13 Feb 2014 13:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nZO9kG41mKV for ; Thu, 13 Feb 2014 13:38:56 -0800 (PST) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id A2BCB1A055C for ; Thu, 13 Feb 2014 13:38:56 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id m10so8766010vbh.32 for ; Thu, 13 Feb 2014 13:38:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=FGme3V+1tev9cF/tlRFXe4kZLNvQ3jnJ7kDwzjjbfIA=; b=ObiYBaBDkHXHZknyU7cAqJW6EMpobX257xTAUTfavzot5+XpqI57dRzy4/H1Rn+R5B l5Zcsfv8PL+MwyCYeo9nHiNmKfVMZx0XrJTbNx+0KZuzYb79C1GdwHYs3efT97jbykla Uy9KPGnED1mdR+1y/EONB4iGjyJ/qo9byVX98= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=FGme3V+1tev9cF/tlRFXe4kZLNvQ3jnJ7kDwzjjbfIA=; b=PeXCw4bbKFgSPqgZrHD8MPZPMKrrfPXm6qaj+Dc8YkI/YA77phNwuMOkoaHUhDJL5A GffkvssLFJVtGZavGwL8tSkchoTbL322j1KbOCshsKWidq0rKex0YHipVdx2Ze5fOmSQ 4DjWbi3lfO3xwOSBCAjAcZVTJTvVQMvLGh/9SRBEZWLLxHyE30Qb8DW6u+qinYedQwQd 2TC9hkQb3aNRj7ntv5y5A7u7r9Do+Jci60GQ/yVIroEz8WUiLJsA4NBim+rU6OXO2eXP AFIMDParH1UTMOCwdhiaLPcN+bOJdWUI/7sWQdFRFIn+j0SvOyMNiNCmbUY0Nf8pK9xG sT/w== X-Gm-Message-State: ALoCoQnr/146DFt+0GRN3gy/UeRkWh8cDY7QBxzdAIKxQKFAC0mEvfgatAk55shtv+PiYVRJbt6F MIME-Version: 1.0 X-Received: by 10.52.157.8 with SMTP id wi8mr252955vdb.46.1392327535122; Thu, 13 Feb 2014 13:38:55 -0800 (PST) Received: by 10.58.187.114 with HTTP; Thu, 13 Feb 2014 13:38:55 -0800 (PST) In-Reply-To: References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD112B.5040209@alum.mit.edu> <52FD2AE0.7060600@gmail.com> <52FD3883.6050402@gmail.com> Date: Thu, 13 Feb 2014 21:38:55 +0000 Message-ID: From: Peter Dunkley To: "dispatch@ietf.org" Content-Type: multipart/alternative; boundary=089e0160c5e42473b904f2508401 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/87GaQqntAZIXvH-SsQLLIPleyZ8 Subject: Re: [dispatch] X over websockets X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:38:58 -0000 --089e0160c5e42473b904f2508401 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable BTW, just looking at MSRP: MSRP through relay: - WebSockets makes sense - WebRTC DataChannel does not make sense (due to the need to establish a session for the DataChannel so you can send an AUTH to get the informati= on you need to establish (another) session for MSRP) MSRP to peer (which might be a client or might be server) - WebSockets makes sense from client to server - the CEMA scenario that Christer may provide language for - WebRTC DataChannel makes sense between clients - WebRTC DataChannel may make sense from clients to server - but WebSockets will be lighter weight Regards, Peter On 13 February 2014 21:32, Peter Dunkley wr= ote: > My point was more that if we are going to have a discussion about how we > refer to WebSockets (in SDP or elsewhere) then let's have it, but let's > also keep it separate from a reopening of the WebSockets vs DataChannel > discussion. > > Which is the right transport (WebSockets/DataChannel) is a use-case > specific thing. I don't see the need for any sort of "beauty contest" as > this is more like the difference between using TCP vs UDP - some things > work on both and some are better suited to one than the other. Why would > we having this "contest" at all, it just doesn't make sense to me. Some > things will be on WebSockets, some things will be on DataChannel, some > things will be on both, and what is wrong with that? > > > > On 13 February 2014 21:26, Sergio Garcia Murillo < > sergio.garcia.murillo@gmail.com> wrote: > >> El 13/02/2014 22:01, Peter Dunkley escribi=F3: >> >> Hello, >>> >>> Wasn't Sergio's point about what the terminology (for example, within >>> SDP) should be rather than whether WebSockets is appropriate as a trans= port >>> or not? And isn't this a totally separate issue from the WebSockets vs= . >>> WebRTC question? >>> >> >> Yes and no. My point was that all "X over websockets" will have some >> common issues, so instead of having the same discussion every time, it >> would be better if we could address them once and for all, so when someo= ne >> wants to propose a new "X", it does not have to spend time and effort on >> that issues. >> >> >> Best regards >> Sergio >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > > > -- > Peter Dunkley > Technical Director > Crocodile RCS Ltd > --=20 Peter Dunkley Technical Director Crocodile RCS Ltd --089e0160c5e42473b904f2508401 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
BTW, just looking at MSRP:

MSRP through= relay:
  • WebSockets makes sense
  • WebRTC DataChannel= does not make sense (due to the need to establish a session for the DataCh= annel so you can send an AUTH to get the information you need to establish = (another) session for MSRP)
MSRP to peer (which might be a client or might be server)
  • WebSockets makes sense from client to server - the CEMA sc= enario that Christer may provide language for
  • WebRTC DataChannel ma= kes sense between clients
  • WebRTC DataChannel may make sense from clients to server - but WebSocke= ts will be lighter weight

Regards,
=

Peter



On 13 February 2014 21:32, Peter Dunkley= <peter.dunkley@crocodilertc.net> wrote:
My point was more that if we are going to have a discussio= n about how we refer to WebSockets (in SDP or elsewhere) then let's hav= e it, but let's also keep it separate from a reopening of the WebSocket= s vs DataChannel discussion.

Which is the right transport (WebSockets/DataChannel) is a u= se-case specific thing. =A0I don't see the need for any sort of "b= eauty contest" as this is more like the difference between using TCP v= s UDP - some things work on both and some are better suited to one than the= other. =A0Why would we having this "contest" at all, it just doe= sn't make sense to me. =A0Some things will be on WebSockets, some thing= s will be on DataChannel, some things will be on both, and what is wrong wi= th that?


=
On 13 February 2014 21:26, Sergio Garcia Mur= illo <sergio.garcia.murillo@gmail.com> wrote:<= br>
El 13/02/2014 22:01, Peter Dunkley escribi= =F3:

Hello,

Wasn't Sergio's point about what the terminology (for example, with= in SDP) should be rather than whether WebSockets is appropriate as a transp= ort or not? =A0And isn't this a totally separate issue from the WebSock= ets vs. WebRTC question?

Yes and no. My point was that all "X over websockets" will have s= ome common issues, so instead of having the same discussion every time, it = would be better if we could address them once and for all, so when someone = wants to propose a new "X", it does not have to spend time and ef= fort on that issues.


Best regards
Sergio

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



<= /div>
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd



--
Peter Dunkley
<= div>Technical Director
Crocodile RCS Ltd
--089e0160c5e42473b904f2508401-- From nobody Thu Feb 13 13:46:56 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFA0A1A0051 for ; Thu, 13 Feb 2014 13:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpBXdx_0QNxa for ; Thu, 13 Feb 2014 13:46:47 -0800 (PST) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3791A0029 for ; Thu, 13 Feb 2014 13:46:46 -0800 (PST) Received: by mail-yh0-f42.google.com with SMTP id a41so10783930yho.15 for ; Thu, 13 Feb 2014 13:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lSTHU1zYTsKDgUAj6ypU6bX1iYzwNeJ9RLtaH62T8bk=; b=r2FQVhwqkQa3bOy1rkkgWD9RSsqgqtXjl7Znl8r3/1moZ476HQu7a/fmHYm3YFl+Fy gtFlSg8VVMTcKEyJqVFxA47iO4wJ+r5drs4y5xRwycPy0VSS4i6MYy1+14s4oqSKy6wR ExQh77DUcrqp4JdcDrf6qZXsZjO/GMzMBYmdRi9URXuRtHdR6KAJCgv7HikY0+LjJF7y WeccOj02kutLxM1UAbD/Q/Ghk9+2prqlyEORvnJCO4cjZHrh9XMo9tVWDlGBXwZNonX7 GUpj+kuHDJEnQDPbjzcIgfhIj2S0CGrm430drDL01LGqoqxD7FsJ5LCF65ZbaS3MH/3p usqA== MIME-Version: 1.0 X-Received: by 10.236.137.14 with SMTP id x14mr3394361yhi.4.1392328005644; Thu, 13 Feb 2014 13:46:45 -0800 (PST) Received: by 10.170.150.2 with HTTP; Thu, 13 Feb 2014 13:46:45 -0800 (PST) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF2A4FF@sc9-ex2k10mb1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBF2A4FF@sc9-ex2k10mb1.corp.yaanatech.com> Date: Thu, 13 Feb 2014 15:46:45 -0600 Message-ID: From: Mary Barnes To: Michael Hammer Content-Type: multipart/alternative; boundary=20cf303ddcfc2ff59904f250a058 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/ilFXGEulaP2TMMtqyJB6ev5JbIE Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:46:50 -0000 --20cf303ddcfc2ff59904f250a058 Content-Type: text/plain; charset=ISO-8859-1 I have stated specifics before as to the context for this and IETF: http://www.ietf.org/mail-archive/web/dispatch/current/msg05252.html One of the things they are explicitly talking about the Radio layer Call control protocol interworking with SIP. Now, if folks are saying that this interworking between these call control messages and SIP would be the same in the BTS as it would be in the MSC, then a pointer to the exact IMS spec that provides all these details would be most helpful. My guess is that this problem doesn't require the complete functionality defined by CT1. It's certainly possible that there is a subset of those specifications which could help meet their needs and I assume they would have dug through those already). But, explicit pointers to those rather than a blanket statement that IMS solves this specific problem would be really helpful. I totally agree that the proponents have a lot more detail to provide so that folks can understand the interworking and functionality that they are wanting that is relevant to IETF and SIP. Mary On Thu, Feb 13, 2014 at 2:49 PM, Michael Hammer < michael.hammer@yaanatech.com> wrote: > Mary. Interworking sip with radio protocols is like saying inter working sip with ip. Makes no sense. So far I have not seen any case for work in IETF. This is more analogous to ITU- T attempt to screw up MPLS as far as I can tell. > > I asked the question before and still do not see a connection to any IETF work. Cut out the business case and nothing has been proposed. > > > > Sent with Good (www.good.com) > > ------ Original Message ------ > *From: *Mary Barnes > *Sent: *Thursday, February 13, 2014 at 3:19 PM > *To: *DRAGE, Keith (Keith) > *Cc: *dispatch@ietf.org > *Subject: *[dispatch] SIP and GSM/UMTS with OpenBTS > > > > > On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote: > >> Ericsson is not the only vendor that sees a market for small cells, but >> the expectation is that the products are built to the completed 3GPP >> standards will be deployed in licensed spectrum by owners of that spectrum, >> although the boxes may well be owned by 3rd parties. >> >> These deployments already exist. >> >> I see Jim has now identified that this proposal is for licensed GSM >> operators in licensed GSM space. >> >> Personally, I would suggest if you believe the operators should be >> picking this up, you take it to 3GPP where the operators are actually >> present. That is the only way you will see it taken up by GSMA, which you >> will need to obtain interoperator agreements to use this (e.g. roaming, >> shared networks). 3GPP them works with IETF on any SIP extensions needed. >> > [MB] One big problem with this proposal is that you must be a member of > 3GPP/GSMA to make contributions and to participate in meetings. > > And, I think having to first do the work in 3GPP and then bring it to IETF > would introduce a tremendous delay for something that's already been > implemented/deployed. While they are proposing to reuse elements and > protocols that are part of an IMS network, the core issue they have is with > interworking SIP with the radio layer protocols. Certainly, one could > implement all the protocols that IMS uses and then use the 3GPP based specs > and proprietary headers to interwork with SIP in the Internet, but that > would be terribly inefficient. > [/MB] > >> >> I would only see IETF having any direct part in this if the proposal was >> only to use unlicensed spectrum by enterprises rather than licensed >> operators, which Jim has negated. >> >> regards >> >> Keith >> >> ------------------------------ >> *From:* Tim Panton new [mailto:thp@westhawk.co.uk] >> *Sent:* 13 February 2014 14:50 >> *To:* DRAGE, Keith (Keith) >> *Cc:* Harvind Samra; Ivo Sedlacek; dispatch@ietf.org >> >> *Subject:* Re: [dispatch] SIP and GSM/UMTS with OpenBTS >> >> >> On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) < >> keith.drage@alcatel-lucent.com> wrote: >> >> Jumping in here, they are relevant in as much as there is no point in >> IETF working on this if there is no known market for it. >> >> Usually those type of projects are published only on April 1st. >> >> So all Ivo is asking is for you to justify that it is worth other people >> working on this as well as yourselves. >> >> Perhaps if you identified the spectrum you believe is available for use >> in the the countries identified, that would be useful. >> >> regards >> >> Keith Drage >> >> >> Ivo's employer seems to see a market for small cells, but looks to tie >> them to existing operator IMS's through >> internet connections "owned by themselves or a partner". >> >> http://www.telecomlead.com/enterprise-networking/mwc-2014-ericsson-announce-small-cell-service-20233/ >> Perhaps that's an April fools joke too (I can't see any avian carriers >> mentioned though)? >> >> It isn't up to the IETF to crown specific solutions. That's the >> market's job. >> >> T. >> >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> > --20cf303ddcfc2ff59904f250a058 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have stated specifics before = as to the context for this and IETF:=A0
http://www.ietf.org/mail-archive/web/dispatch/current/msg05252.html

One o= f the things they are explicitly talking about the Radio layer Call control= protocol interworking with SIP. =A0Now, if folks are saying that this inte= rworking between these call control messages and SIP would be the same in t= he BTS as it would be in the MSC, then a pointer to the exact IMS spec that= provides all these details would be most helpful. =A0My guess is that this= problem doesn't require the complete functionality defined by CT1. =A0= It's certainly possible that there is a subset of those specifications = which could help meet their needs and I assume they would have dug through = those already). But, explicit pointers to those rather than a blanket state= ment that IMS solves this specific problem would be really helpful. =A0

=A0I totall= y agree that the proponents have a lot more detail to provide so that folks= can understand the interworking and functionality that they are wanting th= at is relevant to IETF and SIP.=A0

Mary
On Thu, Feb 13, 2014 at 2:49 PM, Michael Hammer= <michael.hammer@yaanatech.com> wrote:
Mary. Interworking sip with radio proto=
cols is like saying inter working sip with ip. Makes no sense.  So far I ha=
ve not seen any case for work in IETF.  This is more analogous to ITU- T at=
tempt to screw up MPLS as far as I can tell.=20

I asked the question before and still do not see a connection to any IETF w=
ork.  Cut out the business case and nothing has been proposed.=20



Sent with Good (www.good.=
com)
------ Original Message ------
From: Mary Barnes
Sent: Thursday, February 13, 2014 at= 3:19 PM
To: DRAGE, Keith (Keith)
Cc: dispatch@ietf.org
Subject: = [dispatch] SIP and GSM/UMTS with OpenBTS




On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wrote:
Ericsson is not the only vendor that sees a market for small cells, but t= he expectation is that the products are built to the completed 3GPP standar= ds will be deployed in licensed spectrum by owners of that spectrum, although the = boxes may well be owned by 3rd parties.
=A0
These deployments already exist.
=A0
I see Jim has now identified that this proposal is for licensed GSM opera= tors in licensed GSM space.
=A0
Personally, I would suggest if you believe the operators should be pickin= g this up, you take it to 3GPP where the operators are actually present. Th= at is the only way you will see it taken up by GSMA, which you will need to obta= in interoperator agreements to use this (e.g. roaming, shared networks). 3G= PP them works with IETF on any SIP extensions needed.
[MB] One big problem with this proposal is that you= must be a member of 3GPP/GSMA to make contributions and to participate in = meetings. =A0 =A0

And, I think having to first do = the work in 3GPP and then bring it to IETF would introduce a tremendous del= ay for something that's already been implemented/deployed. =A0While the= y are proposing to reuse elements and protocols that are part of an IMS net= work, the core issue they have is with interworking SIP with the radio laye= r protocols. =A0Certainly, one could implement all the protocols that IMS u= ses and then use the 3GPP based specs and proprietary headers to interwork = with SIP in the Internet, but that would be terribly inefficient.=A0
[/MB]=A0
=A0
I would only see IETF having any direct part in this if the proposal was = only to use unlicensed spectrum by enterprises rather than licensed operato= rs, which Jim has negated.
=A0
regards
=A0
Keith

From: Tim Panton new [mailto:thp@westhawk.co.uk]
Sent: 13 February 2014 14:50
To: DRAGE, Keith (Keith)
Cc: Harvind Samra; Ivo Sedlacek; dispatch@ietf.org

Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS


On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent= .com> wrote:

Jumping in here, they are relevant in as much as there is no point in IET= F working on this if there is no known market for it.
=A0
Usually those type of projects are published only on April 1st.
=A0
So all Ivo is asking is for you to justify that it is worth other people = working on this as well as yourselves.
=A0
Perhaps if you identified the spectrum you believe is available for use i= n the the countries identified, that would be useful.
=A0
regards
=A0
Keith Drage

Ivo's employer seems to see a market for small cells, but looks to= tie them to existing operator IMS's through=A0
internet connections "owned by themselves or a partner".
Perhaps that's an April fools joke too (I can't see any avian = carriers mentioned though)?

It isn't up to the IETF to crown specific solutions. That's th= e market's job.

T.




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



--20cf303ddcfc2ff59904f250a058-- From nobody Thu Feb 13 13:47:29 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00CA71A007F for ; Thu, 13 Feb 2014 13:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZ2GJ3wNu7Se for ; Thu, 13 Feb 2014 13:47:17 -0800 (PST) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2031A00C3 for ; Thu, 13 Feb 2014 13:47:17 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id p61so8231054wes.17 for ; Thu, 13 Feb 2014 13:47:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=929l0KRUJfDNv3wqzoVyCCJGzbkR/5srw5ogBtal6JI=; b=EbmnVaVM2/mBUlzz19Aq4AFRTqhrGppCNopq7P1PxWVvciAX57t9nVfT4W+X6njlYX mAXPCO/4vpVvbYG6y3wBRFYSFixNiHkm5KY+pubZ4xCiH2yXIE/5nyOLwZ6RtsldrG+p G82iumafdGM6GguJ4NvUiWXRbUN/xdTynphiQ56IJRCofNjKOH5AUlvUDRZpGz6GUuhj 63et2KUxuV6Tej7pcQEigD6lNRI8SB2X1Qwx+296sAQi3m6wtV9xbmwS4onsfcfudwZc j5nfFT7mtWgt4Nr9WJea2zVNYbUz0V7dJJ+OgdDSiD9TcVtQAn19dHTBmMl3JrziNV7f Xftg== X-Received: by 10.180.105.41 with SMTP id gj9mr8185732wib.28.1392328035517; Thu, 13 Feb 2014 13:47:15 -0800 (PST) Received: from [192.168.0.192] ([95.61.111.78]) by mx.google.com with ESMTPSA id d6sm16929720wic.9.2014.02.13.13.47.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 13:47:14 -0800 (PST) Message-ID: <52FD3D61.2020901@gmail.com> Date: Thu, 13 Feb 2014 22:47:13 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Peter Dunkley References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD36A3.1020606@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/ZaVOriIgRUcbC5lXkfWXOQ04J2s Cc: DISPATCH Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 21:47:22 -0000 El 13/02/2014 22:24, Peter Dunkley escribió: > Hello, > > Because WebSockets is an asynchronous protocol two MSRP peers (that > are clients) cannot use MSRP over WebSockets. > > It could be possible for a WebSocket server to be an MSRP peer (for > example, in the scenario where the server is B2B'ing MSRP like an SBC > will do in IMS for CEMA). Christer Holmberg has expressed an interest > in this scenario and may provide language relating to it for the draft > - but for now this is out of the scope of the draft which explicitly > deals just with with the MSRP through relay scenario. If Christer > does provide some additional language then the draft will cover this > without relay scenario, but if not nothing in the draft should prevent > someone from addressing it in the future with an additional document > (should there be interest). > > From my point-of-view I am only interested in the with relay scenario > at this time. Fair enough, but then maybe the draft should be named "MSRP over webscokets via MSRP relay" to avoid confusions .. ;) In that case, using the TCP/WS/MSRP wouldn't be correct in my point of view and the draft is ok as it is. I was thinking more in the scenario of the MSRP peer also been the Websocket server, that is very similar to the scenario we have in BFCP over websockets. Best regards Sergio From nobody Thu Feb 13 14:03:00 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDD21A0279 for ; Thu, 13 Feb 2014 14:02:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UcgqrqBzMDDh for ; Thu, 13 Feb 2014 14:02:55 -0800 (PST) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1786E1A0334 for ; Thu, 13 Feb 2014 14:02:55 -0800 (PST) Received: by mail-yh0-f52.google.com with SMTP id a41so10734533yho.39 for ; Thu, 13 Feb 2014 14:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XWST50SJWJZN9foABWoCo/ofYavnJX5kFrV2D/3E9Zk=; b=XWYgxYZCUfMX3zmnCtPxLrJmCzrvycQOXGaHgtSMxyeDvWOMSvnop4cdV1BHyK076t MbaHfrYpHfjBPtpQRyosUy8EIDAguX+DueGa7ZQV5fX5VIIi5dez9R9I7qCn/D6CISp1 5Jw2DAmRiPF+s/A+mbTnkHTgkfKemT9YaUG3vQLLd0PQSVe+3yc3KcxtzB+cWoUeC4h7 8k+NuaBIxp4+mqZimpN4EU5Sm1J3kyeeVsWtSt+msKKlYQ7EBKad8juXk9LPnb/gHHFj Su3WPrwpx03jIPfp6xe516NK2i5O0FBsIVd8BpbGuDvJv8I0qtKDvfjsURkmBnXlOLjK 7qBw== MIME-Version: 1.0 X-Received: by 10.236.79.196 with SMTP id i44mr3494166yhe.80.1392328973706; Thu, 13 Feb 2014 14:02:53 -0800 (PST) Received: by 10.170.150.2 with HTTP; Thu, 13 Feb 2014 14:02:53 -0800 (PST) In-Reply-To: <52FD2AE0.7060600@gmail.com> References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD112B.5040209@alum.mit.edu> <52FD2AE0.7060600@gmail.com> Date: Thu, 13 Feb 2014 16:02:53 -0600 Message-ID: From: Mary Barnes To: Sergio Garcia Murillo Content-Type: multipart/alternative; boundary=20cf30050db8e3754504f250d9eb Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/K-Wan0cD1OT2ibVQTKFjyOJ42GA Cc: DISPATCH Subject: Re: [dispatch] X over websockets X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 22:02:57 -0000 --20cf30050db8e3754504f250d9eb Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This topic has previously been raised (a year ago and periodically since then): http://www.ietf.org/mail-archive/web/dispatch/current/msg04693.html The suggestion was to have a "foo" over websocket discussion on the RAI list (which is really a lonely and largely ignored mailing list) but no one has taken that up: http://www.ietf.org/mail-archive/web/dispatch/current/msg04749.html Also, no one has put forth a concrete proposal to deal with it and we don't do work unless someones willing to put in the cycles. Thus, these work items have been trickling in (and out). Since they are deemed useful in some contexts (and not harmful), they've been moving forward. But, it certainly would be good for someone to put in some cycles to define a model and some guidelines for using websockets for any number of RAI protocols. Mary. On Thu, Feb 13, 2014 at 2:28 PM, Sergio Garcia Murillo < sergio.garcia.murillo@gmail.com> wrote: > El 13/02/2014 19:38, Paul Kyzivat escribi=F3: > > On 2/13/14 11:07 AM, Sergio Garcia Murillo wrote: >> >>> What I mean is that I expect quite a lot of "over websocekts" drafts an= d >>> we should try to use the same solution for advertising it in the SDP, >>> and not have each one have their own way of handling it. >>> >> >> Sigh. Yes, once we had the first of these, it was only a matter of time >> before the flood began. >> >> What concerns me is that for every "X over websockets" there is probably >> also a good argument for "X over WebRTC Data Channel". >> >> Are we going to let that happen? >> >> Or for each X are we going to have a beauty contest between websockets >> and data channel? >> >> Or what? >> > > Completely agree, we should try to "close" that discussion once and for > all and not have the same arguments and discussions in each draft. I am n= ot > really aware of the IETF process, but could be possible to create a draft > to address it? > > Best regards > Sergio > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --20cf30050db8e3754504f250d9eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This topic has previously been raised (a year ago and peri= odically since then):

The suggestion was to have a "foo" over webso= cket discussion on the RAI list (which is really a lonely and largely ignor= ed mailing list) but no one has taken that up:

Also, no one has put forth a concrete proposal to deal = with it and we don't do work unless someones willing to put in the cycl= es.=A0

Thus, these work items have been trickli= ng in (and out). =A0Since they are deemed useful in some contexts (and not = harmful), they've been moving forward. =A0But, it certainly would be go= od for someone to put in some cycles to define a model and some guidelines = for using websockets for any number of RAI protocols.=A0

Mary.=A0
=

On Thu, Feb 13, 2014 at 2:28 PM, Sergio = Garcia Murillo <sergio.garcia.murillo@gmail.com> wrote:
El 13/02/2014 19:38, Paul Kyzivat escribi=F3= :

On 2/13/14 11:07 AM, Sergio Garcia Murillo wrote:
What I mean is that I expect quite a lot of "over websocekts" dra= fts and
we should try to use the same solution for advertising it in the SDP,
and not have each one have their own way of handling it.

Sigh. Yes, once we had the first of these, it was only a matter of time bef= ore the flood began.

What concerns me is that for every "X over websockets" there is p= robably also a good argument for "X over WebRTC Data Channel".
Are we going to let that happen?

Or for each X are we going to have a beauty contest between websockets and = data channel?

Or what?

Completely agree, we should try to "close" that discussion once a= nd for all and not have the same arguments and discussions in each draft. I= am not really aware of the IETF process, but could be possible to create a= draft to address it?

Best regards
Sergio


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

--20cf30050db8e3754504f250d9eb-- From nobody Thu Feb 13 15:34:09 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676281A0523 for ; Thu, 13 Feb 2014 15:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bxo-kbu7HPXN for ; Thu, 13 Feb 2014 15:34:00 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id E4D1C1A04F1 for ; Thu, 13 Feb 2014 15:33:57 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s1DNWtnm003161; Thu, 13 Feb 2014 18:32:57 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s1DNRDWt4937713; Thu, 13 Feb 2014 18:27:14 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s1DNRDf54757099; Thu, 13 Feb 2014 18:27:13 -0500 (EST) Date: Thu, 13 Feb 2014 18:27:13 -0500 (EST) Message-Id: <201402132327.s1DNRDf54757099@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Jim Forster In-reply-to: <676E4A52-E702-43BE-9245-5CD558D69497@rangenetworks.com> (jim.forster@rangenetworks.com) References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <676E4A52-E702-43BE-9245-5CD558D69497@rangenetworks.com> Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/CFQlLZtRjWUZ2OZw209sHStisoU Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 23:34:07 -0000 > From: Jim Forster > Date: Thu, 13 Feb 2014 11:46:22 +0000 > Accept-Language: en-US > Cc: "dispatch@ietf.org" Note that this e-mail was essentially unreadable because it is difficult to keep straight what is being quoted (from whom?) and what is Jim's new text. Use the ">" convention for quoting previous messages! However, this does lead me to be able to phrase what I am still unclear about: What is it that you're trying to accomplish? In what way does SIP form a part of this project? I notice that your messages are written from the point of view of someone who is immersed in OpenBTS. Remember, to a first approximation, nobody here knows *anything* about OpenBTS, and a large majority know little or nothing about IMS, 3GPP, or anything else about the cellular infrastructure. Have you settled on a technological structure for this project, or are you at the stage of having business goals and still exploring technologies? Dale From nobody Thu Feb 13 15:36:01 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448531A0509 for ; Thu, 13 Feb 2014 15:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TAbDX65bce7L for ; Thu, 13 Feb 2014 15:35:58 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 06A451A0408 for ; Thu, 13 Feb 2014 15:35:57 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s1DNZ96v017398; Thu, 13 Feb 2014 18:35:12 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s1DNS10w4929046; Thu, 13 Feb 2014 18:28:01 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s1DNS0U64926205; Thu, 13 Feb 2014 18:28:00 -0500 (EST) Date: Thu, 13 Feb 2014 18:28:00 -0500 (EST) Message-Id: <201402132328.s1DNS0U64926205@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Ralph A. Schmid, dk5ras" In-reply-to: <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> (ralph@schmid.xxx) References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/whf4YuR0qmprBG9kNhq1DCJVhSQ Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 23:36:00 -0000 > From: "Ralph A. Schmid, dk5ras" (Is there a reason you insert so many blank lines?) > So imagine a village, a few hundred people living there, most of > them owning mobile phones for communication when they travel to the > town for work or for trading goods - but at home those phones are > useless. > So somebody is able to spent a few thousand dollars, puts an antenna > onto some tree, flips the switch, and a few hundred phones can (and > do) log on. > Now more and more of those low-cost networks grow up, and people > want to connect them. Internet is available in some places, cheap to > buy and install WiFi-links are established, the whole thing evolves, > some simple structure grows. This story makes sense to me. The question seems to be how to interwork the GSM radio call-control protocol with SIP, so that a set of these base stations can operate as an integrated system. You'd want some sort of SIP registrar/proxy to operate as an ITSP, and all of the base stations make SIP connections with it. The next step is for someone to start designing this use of SIP. No doubt a lot of interesting questions will arise, and you may need to design some SIP extensions. But until you've got the design started and can discuss the design decisions, you're not in a position to talk about what SIP extensions are needed. Dale From nobody Thu Feb 13 21:24:36 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2DB1A00EC for ; Thu, 13 Feb 2014 21:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.277 X-Spam-Level: X-Spam-Status: No, score=-0.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adu7kV4jDDtO for ; Thu, 13 Feb 2014 21:24:26 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 191411A00B9 for ; Thu, 13 Feb 2014 21:24:25 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id u14so8976342lbd.15 for ; Thu, 13 Feb 2014 21:24:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Pe5kMlu5R4QJcprILwNAc+UiycJ9do7ceHpZTiC/Kuk=; b=CHTYb+kuJ4UMVzIeCqcx6MQVf2cuXHGvP/IOeClYoVqokFOiGVIKByVZRDoZuAo0S9 Z4CCgOb+bFDRkES/VUURqyBDwktr+XuZpAwLCDOWonG+0Ji90blrg6+TSZ8zDcPmGiK2 Rdq/TNJfAHsKwyZ2puOEWP72+bcylRVFCALm5uzY/AQ5kEOuTQzXW44fVFTtM/wnRv0i NTBYUtfrTnRmmIeRWBQqs4RIFgWr23Ydi2KlxKdujOcH5WLY4Pw4djcx/AyAYm68AHkY wpmvFWitupGHfdgy5D9TJGmzoAQbWU0A0KoKrRd/hbV46wLmHm8lgdG7Zo/XzHsOQ5O/ nr7w== X-Received: by 10.112.45.108 with SMTP id l12mr3505991lbm.21.1392355464001; Thu, 13 Feb 2014 21:24:24 -0800 (PST) MIME-Version: 1.0 Sender: munncha@gmail.com Received: by 10.112.42.170 with HTTP; Thu, 13 Feb 2014 21:23:43 -0800 (PST) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B131C97@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> <949EF20990823C4C85C18D59AA11AD8B131C97@FR712WXCHMBA11.zeu.alcatel-lucent.com> From: Kurtis Heimerl Date: Fri, 14 Feb 2014 14:23:43 +0900 X-Google-Sender-Auth: hiw4TNBs5Zbc7hu-_foGyYijABY Message-ID: To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=001a1134bfc8d53e6904f257049d Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/jX8LSUYsPThqBW-yMcPsZ-pcDqs Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 05:24:31 -0000 --001a1134bfc8d53e6904f257049d Content-Type: text/plain; charset=ISO-8859-1 I've been traveling and there's a lot more thread, but I just wanted to note that spectrum licenses aren't that difficult to acquire when the primary carriers are unwilling to cover an area. Our research group (TIER) had one for testing and the Rhizomatica network has one in rural Oaxaca Mexico, as examples. Saying all of these networks are illegal is a gross miscategorization and completely unfair. On Fri, Feb 14, 2014 at 1:00 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > So you propose that IETF should write standards solely for an illegal > activity? > > One separate point I would make is that telecommunications represents a > significant source of government income in 3rd world countries. Therefore > any such activities would be rapidly cracked down on. > > Keith > > ------------------------------ > *From:* Ralph A. Schmid, dk5ras [mailto:ralph@schmid.xxx] > *Sent:* 13 February 2014 15:28 > *To:* DRAGE, Keith (Keith); 'Harvind Samra'; 'Ivo Sedlacek' > *Cc:* dispatch@ietf.org > *Subject:* RE: [dispatch] SIP and GSM/UMTS with OpenBTS > > I see the purpose of such systems in not-so-developed countries, and > especially in very remote areas of those. > > > > Usually the commercial providers have no interest in covering those, as > there is no revenue from doing so, and > > especially in such countries often the government is not willing to force > operators to cover an area, and/or they > > are not willing/able to enforce such a rule. > > > > So imagine a village, a few hundred people living there, most of them > owning mobile phones for communication > > when they travel to the town for work or for trading goods - but at home > those phones are useless. > > > > Now there are two possibilities - the government does not care about > licenses, or they give a license to operate > > a local network. This is not our problem here, we are techs, no > bureaucrats. > > > > So somebody is able to spent a few thousand dollars, puts an antenna onto > some tree, flips the switch, and > > a few hundred phones can (and do) log on. > > > > Very nice, people can call each other, can call the doctor when they are > ill and injured, the system runs locally > > just fine. > > > > Now more and more of those low-cost networks grow up, and people want to > connect them. Internet is available > > in some places, cheap to buy and install WiFi-links are established, the > whole thing evolves, some simple > > structure grows. > > > > This is the time were some standards are needed. Open standards, cheap > standards, not a 3GPP IMS monster. We > > are not talking here about a nice and clean data center with racks full of > BSCs, MSCs and all that, we are talking > > about simple to maintain structures. It must be some technology a normal > computer guy everywhere in the world > > can understand after reading some manuals. SIP family of procedures was > chosen. > > > > As far as I understand (don't blame when I'm wrong, I'm RF engineer, not a > SIP guy) at the moment the possible > > procedures are not standardized, some extensions or modifications need to > be defined, for being able to cope > > with this kind of mobility (handover etc.) and distributed network > control. This is the scope of this mail thread. > > > > Such systems like described above are not dreams, such systems do exist, > they bring a large benefit to those > > people, micro economics evolve, emergency communication is established, > social interaction is improved. > > > > Now imagine an earthquake or a similar catastrophe - the almost > non-existent infrastructure breaks down > > completely. Emergency teams show up, have no oversight what is happening. > But hey, they unload some > > boxes on top of a hill, fire up their BTS, link it to the headquarter, > many phones log into the system, and > > people can call for assistance, can tell what kind of help is needed in > what place, first responder teams can > > be sent to those places. > > > > > > No fancy and shiny business, just live saving communication somewhere out > in the mud and dirt. Normal > > phone companies do not do this kind of work, but someone needs to. IETF > may be a small gear that makes > > this thing move a bit smoother - it is already moving, that is for sure, > with or without IETF :-) > > > > But I may be wrong...then just hit the DEL-button. > > > Ralph. > > > > > > > > > > *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *DRAGE, > Keith (Keith) > *Sent:* Thursday, February 13, 2014 3:34 PM > *To:* Harvind Samra; Ivo Sedlacek > *Cc:* dispatch@ietf.org > *Subject:* Re: [dispatch] SIP and GSM/UMTS with OpenBTS > > > > Jumping in here, they are relevant in as much as there is no point in IETF > working on this if there is no known market for it. > > > > Usually those type of projects are published only on April 1st. > > > > So all Ivo is asking is for you to justify that it is worth other people > working on this as well as yourselves. > > > > Perhaps if you identified the spectrum you believe is available for use in > the the countries identified, that would be useful. > > > > regards > > > > Keith Drage > > > ------------------------------ > > *From:* dispatch [mailto:dispatch-bounces@ietf.org] > *On Behalf Of *Harvind Samra > *Sent:* 13 February 2014 12:37 > *To:* Ivo Sedlacek > *Cc:* dispatch@ietf.org > *Subject:* Re: [dispatch] SIP and GSM/UMTS with OpenBTS > > Hi Ivo, > > > > I have to ask...why are the questions regarding frequency licensing and > economics relevant? This is a discussion regrading augmenting SIP. > > > > On Feb 13, 2014, at 2:06 AM, Ivo Sedlacek > wrote: > > > > Hello Tim and > all, > > if I understood the proposal correctly, in comparison to 3GPP architecture > you propose: > > - UEs are unchanged > > - BTS > > - uses regular Um reference point towards UEs > > - has a new SIP based interface replacing ABis reference > point > > - BSC, MSC, HSS, SM-SC, ... collapse into one functional entity > "SAS/Asterisk/SMQueue". This new functional entity: > > - uses the new SIP based interface replacing ABis > reference point towards BTS > > - uses another SIP based interface towards remote networks > > Can you please clarify what's the intended business case where the > proposed solution is supposed to be superior over the existing 3GPP > solution? > > E.g. can you please clarify whether you indent to specify a solution for: > > a) carriers with license to use the licensed GSM bands? > > b) individuals/corporates without license to use the licensed GSM bands? > > c) anyone else? > > The original mail suggested b) but then you referred to a) in your mail > stating "But more typically carriers with spectrum licenses are looking for > an economical way to get into rural areas." > > If a), such solution can be deployed anywhere where there are existing GSM > bands in use. However, it will likely require implementation of the full > 3GPP feature set which carriers offer today, including supporting > regulator's requirements, support of handovers, integration with other > operator subsystems (e.g. billing, operation & maintenance subsystems, > ...). Or do you believe that some existing requirements are unnecessary for > deployments in carrier networks? > > You seem to claim above that your proposal can be more economical than > existing solution. Given that new protocol would need to be defined and > functional entities newly developed and tested, I fail to see how this can > be more economical than deployment of existing products which are already > developed, tested, mass produced and mass deployed. Can you provide some > numbers supporting your view? > > > https://www.usenix.org/conference/nsdi13/technical-sessions/presentation/heimurl > just proposes new functionality to be added, unrelated to any potential > replacement of ABis reference point with SIP based interface. > > If b), then such solution can be deployed only in countries where there is > no license needed. You list Sweden as one with UK and Netherlands with > question marks. Also Antarctica was mentioned. > > Can you please provide a reference to regulators' document enabling usage > of GSM bands without license in each of those countries? > > How will interferences be avoided if several individuals/corporates start > using the same GSM band in the same location, particularly if each starts > using power enabling "potential 20 mile radius even for a single cell"? > > Furthermore, even if all of Sweden, UK, Netherlands and Antarctica enable > usage of GSM bands without license, this is still quite limited market. If > the solution is limited only to those countries, even if the required > feature set is smaller, there is little economies of scale. > > Kind regards > > Ivo Sedlacek > > This Communication is Confidential. We only send and receive email on the > basis of the terms set out at www.ericsson.com/email_disclaimer > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > Harvind Samra > > Founder, CTO > > Range Networks > > San Francisco, CA > > ____________________________________________ > > > > Cellular networks made simple and affordable. > > http://www.rangenetworks.com > > ____________________________________________ > > > > > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --001a1134bfc8d53e6904f257049d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've been traveling and there's a lot more thread,= but I just wanted to note that spectrum licenses aren't that difficult= to acquire when the primary carriers are unwilling to cover an area. Our r= esearch group (TIER) had one for testing and the Rhizomatica network has on= e in rural Oaxaca Mexico, as examples. Saying all of these networks are ill= egal is a gross miscategorization and completely unfair. 


On Fri, Feb 1= 4, 2014 at 1:00 AM, DRAGE, Keith (Keith) <keith.drage@alcatel= -lucent.com> wrote:
So you propose that IETF should write standards solely for an illegal act= ivity?
 
One separate point I would make is that telecommunications represents a s= ignificant source of government income in 3rd world countries. Therefore an= y such activities would be rapidly cracked down on.
 
Keith

From: Ralph A. Schmid, dk5ras [mailto:ralph@schmid.xxx]
Sent: 13 February 2014 15:28
To: DRAGE, Keith (Keith); 'Harvind Samra'; 'Ivo Sedlacek= '
Cc: dispatch@= ietf.org
Subject: RE: [dispatch] SIP and GSM/UMTS with OpenBTS

I see the purpos= e of such systems in not-so-developed countries, and especially in very rem= ote areas of those.

 =

Usually the comm= ercial providers have no interest in covering those, as there is no revenue= from doing so, and

especially in su= ch countries often the government is not willing to force operators to cove= r an area, and/or they

are not willing/= able to enforce such a rule.

 =

So imagine a vil= lage, a few hundred people living there, most of them owning mobile phones = for communication

when they travel= to the town for work or for trading goods – but at home those phones= are useless.

 =

Now there are tw= o possibilities – the government does not care about licenses, or the= y give a license to operate

a local network.= This is not our problem here, we are techs, no bureaucrats.

 =

So somebody is a= ble to spent a few thousand dollars, puts an antenna onto some tree, flips = the switch, and

a few hundred ph= ones can (and do) log on.

 =

Very nice, peopl= e can call each other, can call the doctor when they are ill and injured, t= he system runs locally

just fine.

 =

Now more and mor= e of those low-cost networks grow up, and people want to connect them. Inte= rnet is available

in some places, = cheap to buy and install WiFi-links are established, the whole thing evolve= s, some simple

structure grows.

 =

This is the time= were some standards are needed. Open standards, cheap standards, not a 3GP= P IMS monster. We

are not talking = here about a nice and clean data center with racks full of BSCs, MSCs and a= ll that, we are talking

about simple to = maintain structures. It must be some technology a normal computer guy every= where in the world

can understand a= fter reading some manuals. SIP family of procedures was chosen.

 =

As far as I unde= rstand (don’t blame when I’m wrong, I’m RF engineer, not = a SIP guy) at the moment the possible  

procedures are n= ot standardized, some extensions or modifications need to be defined, for b= eing able to cope

with this kind o= f mobility (handover etc.) and distributed network control. This is the sco= pe of this mail thread.

 =

Such systems lik= e described above are not dreams, such systems do exist, they bring a large= benefit to those

people, micro ec= onomics evolve, emergency communication is established, social interaction = is improved.

 =

Now imagine an e= arthquake or a similar catastrophe – the almost non-existent infrastr= ucture breaks down

completely. Emer= gency teams show up, have no oversight what is happening. But hey, they unl= oad some

boxes on top of = a hill, fire up their BTS, link it to the headquarter, many phones log into= the system, and

people can call = for assistance, can tell what kind of help is needed in what place, first r= esponder teams can

be sent to those= places.

 =

 =

No fancy and shi= ny business, just live saving communication somewhere out in the mud and di= rt. Normal

phone companies = do not do this kind of work, but someone needs to. IETF may be a small gear= that makes

this thing move = a bit smoother – it is already moving, that is for sure, with or with= out IETF  :-)

 =

But I may be wro= ng...then just hit the DEL-button.


Ralph.

 =

 =

 =

 =

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith)
Sent: Thursday, February 13, 2014 3:34 PM
To: Harvind Samra; Ivo Sedlacek
Cc: dispatch@= ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS<= /span>

 

Jumping in here, they are relevant i= n as much as there is no point in IETF working on this if there is no known= market for it.

 

Usually those type of projects are p= ublished only on April 1st.

 

So all Ivo is asking is for you to j= ustify that it is worth other people working on this as well as yourselves.=

 

Perhaps if you identified the spectr= um you believe is available for use in the the countries identified, that w= ould be useful.

 

regards

 

Keith Drage

 

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Harvind Samra
Sent: 13 February 2014 12:37
To: Ivo Sedlacek
Cc: dispatch@= ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

Hi Ivo,

 

I have to ask…why are the questions regarding= frequency licensing and economics relevant?  This is a discussion reg= rading augmenting SIP.

 

On Feb 13, 2014, at 2:06 AM, Ivo Sedlacek <ivo.sedlacek@erics= son.com> wrote:



Hello Tim and all,  =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;  

if I understood the proposal c= orrectly, in comparison to 3GPP architecture you propose:

- UEs are unchanged<= /u>

- BTS

     =            - uses regular= Um reference point towards UEs

     =            - has a new SI= P based interface replacing ABis reference point

- BSC, MSC, HSS, SM-SC, ... co= llapse into one functional entity "SAS/Asterisk/SMQueue". This ne= w functional entity:

     =            - uses the new= SIP based interface replacing ABis reference point towards BTS

     =            - uses another= SIP based interface towards remote networks

Can you please clarify what= 9;s the intended business case where the proposed solution is supposed to b= e superior over the existing 3GPP solution?

E.g. can you please clarify wh= ether you indent to specify a solution for:

a) carriers with license to us= e the licensed GSM bands?

b) individuals/corporates with= out license to use the licensed GSM bands?

c) anyone else?<= /span>

The original mail suggested b)= but then you referred to a) in your mail stating "But more typically = carriers with spectrum licenses are looking for an economical way to get into rural areas."

If a), such solution can be de= ployed anywhere where there are existing GSM bands in use. However, it will= likely require implementation of the full 3GPP feature set which carriers offer today, including supporting regulator's requi= rements, support of handovers, integration with other operator subsystems (= e.g. billing, operation & maintenance subsystems, ...). Or do you belie= ve that some existing requirements are unnecessary for deployments in carrier networks?

You seem to claim above that y= our proposal can be more economical than existing solution. Given that new = protocol would need to be defined and functional entities newly developed and tested, I fail to see how this can be more economical = than deployment of existing products which are already developed, tested, m= ass produced and mass deployed. Can you provide some numbers supporting you= r view?

https://www.usenix.org/conference/nsdi13= /technical-sessions/presentation/heimurl just proposes new functionality to be added, unrelated to any potential replace= ment of ABis reference point with SIP based interface.=

If b), then such solution can = be deployed only in countries where there is no license needed. You list Sw= eden as one with UK and Netherlands with question marks. Also Antarctica was mentioned.

Can you please provide a refer= ence to regulators' document enabling usage of GSM bands without licens= e in each of those countries?

How will interferences be avoi= ded if several individuals/corporates start using the same GSM band in the = same location, particularly if each starts using power enabling "potential 20 mile radius even for a single cell"?

Furthermore, even if all of Sw= eden, UK, Netherlands and Antarctica enable usage of GSM bands without lice= nse, this is still quite limited market. If the solution is limited only to those countries, even if the required feature set is sm= aller, there is little economies of scale.

Kind regards

Ivo Sedlacek

This Communication is Confiden= tial. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer=

_____________________________= __________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispat= ch

 

Harvind Samra

Founder, CTO

Range Networks

San Francisco, CA  

____________________________________________=

 

Cellular networks made simple and affordable.  

____________________________________________=

 

 

 

 


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


--001a1134bfc8d53e6904f257049d-- From nobody Thu Feb 13 21:28:10 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3201A00B9 for ; Thu, 13 Feb 2014 21:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1HKFJRW7bGs for ; Thu, 13 Feb 2014 21:28:07 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) by ietfa.amsl.com (Postfix) with ESMTP id E34021A00EE for ; Thu, 13 Feb 2014 21:28:06 -0800 (PST) Received: by mail-lb0-f176.google.com with SMTP id w7so8826666lbi.7 for ; Thu, 13 Feb 2014 21:28:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=FXZpa5IItO7DGeyALdTW7AJ8qRlcUXZBs8sPxZFGolo=; b=VUawfajo32ibw+okyqjfmfZfCPEfCseUg2ruJE/Ix6V33ZDJU0KJ0O5YeQhpglrUWe 5zughijoULnRMTGIw7Y66ONy5fyEtNIMLoy1sBIxr6CXpK7OlbfPDnZChsXc5brwgCpI rlln9YH02x/ALonFws2RCJODzxL7PXYclxlHdKiI9RNLqyZMyj3a5ucYVPtg0B3YbNFw +QJr8hqIaRn7mnmREVTu8c9myiS/dm/PLWqrxH1sL3U//E1cGXsOgNUS4OKvdxQLbuKs mCYeDyjvo22FArURheYuQWKkLOd5yDAmXtyc3kIVrKcQd37iFxXJfMrqAOq3tJcKtCqb Qtog== X-Received: by 10.112.137.65 with SMTP id qg1mr3535386lbb.7.1392355684883; Thu, 13 Feb 2014 21:28:04 -0800 (PST) MIME-Version: 1.0 Sender: munncha@gmail.com Received: by 10.112.42.170 with HTTP; Thu, 13 Feb 2014 21:27:24 -0800 (PST) In-Reply-To: <201402132328.s1DNS0U64926205@shell01.TheWorld.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> <201402132328.s1DNS0U64926205@shell01.TheWorld.com> From: Kurtis Heimerl Date: Fri, 14 Feb 2014 14:27:24 +0900 X-Google-Sender-Auth: -IOyaiGa1M-8UZMBrhMR4wJRdSE Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=089e0116047effa17604f25711cd Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/FLVu0AigjpnBGvvKvajhP6nJElQ Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 05:28:09 -0000 --089e0116047effa17604f25711cd Content-Type: text/plain; charset=ISO-8859-1 OpenBTS is an instance of an Um->SIP gateway. After this implementation, we've become aware that a broader view of the relative correctness of our design would be valuable... and that's why this thread exists. We'd like the IETF to help standardize this gateway model and make sure that the decisions that were made are reasonable, scalable, and intelligent. At least that's my perception on why we're here. Jim may have another. On Fri, Feb 14, 2014 at 8:28 AM, Dale R. Worley wrote: > > From: "Ralph A. Schmid, dk5ras" > > (Is there a reason you insert so many blank lines?) > > > So imagine a village, a few hundred people living there, most of > > them owning mobile phones for communication when they travel to the > > town for work or for trading goods - but at home those phones are > > useless. > > > So somebody is able to spent a few thousand dollars, puts an antenna > > onto some tree, flips the switch, and a few hundred phones can (and > > do) log on. > > > Now more and more of those low-cost networks grow up, and people > > want to connect them. Internet is available in some places, cheap to > > buy and install WiFi-links are established, the whole thing evolves, > > some simple structure grows. > > This story makes sense to me. The question seems to be how to > interwork the GSM radio call-control protocol with SIP, so that a set > of these base stations can operate as an integrated system. You'd > want some sort of SIP registrar/proxy to operate as an ITSP, and all > of the base stations make SIP connections with it. > > The next step is for someone to start designing this use of SIP. No > doubt a lot of interesting questions will arise, and you may need to > design some SIP extensions. But until you've got the design started > and can discuss the design decisions, you're not in a position to talk > about what SIP extensions are needed. > > Dale > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --089e0116047effa17604f25711cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
OpenBTS is an instance of an Um->SIP gateway. After thi= s implementation, we've become aware that a broader view of the relativ= e correctness of our design would be valuable... =A0and that's why this= thread exists. We'd like the IETF to help standardize this gateway mod= el and make sure that the decisions that were made are reasonable, scalable= , and intelligent.=A0

At least that's my perception on why we're here= . Jim may have another.=A0


On Fri, Feb 14, 2014 at 8:28 AM, Dale R. Worley <worley@ariadne.com> wrote:
> From: "Ralph A. Schmid, dk5ras&quo= t; <ralph@schmid.xxx>

(Is there a reason you insert so many blank lines?)

> So imagine a village, a few hundred people living there, most of
> them owning mobile phones for communication when they travel to the > town for work or for trading goods - but at home those phones are
> useless.

> So somebody is able to spent a few thousand doll= ars, puts an antenna
> onto some tree, flips the switch, and a few hundred phones can (and > do) log on.

> Now more and more of those low-cost networks gro= w up, and people
> want to connect them. Internet is available in some places, cheap to > buy and install WiFi-links are established, the whole thing evolves, > some simple structure grows.

This story makes sense to me. =A0The question seems to be how to
interwork the GSM radio call-control protocol with SIP, so that a set
of these base stations can operate as an integrated system. =A0You'd want some sort of SIP registrar/proxy to operate as an ITSP, and all
of the base stations make SIP connections with it.

The next step is for someone to start designing this use of SIP. =A0No
doubt a lot of interesting questions will arise, and you may need to
design some SIP extensions. =A0But until you've got the design started<= br> and can discuss the design decisions, you're not in a position to talk<= br> about what SIP extensions are needed.

Dale

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

--089e0116047effa17604f25711cd-- From nobody Thu Feb 13 23:02:33 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C173E1A012D for ; Thu, 13 Feb 2014 23:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M84_z3qM9AKt for ; Thu, 13 Feb 2014 23:02:28 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 466BC1A00E3 for ; Thu, 13 Feb 2014 23:02:27 -0800 (PST) X-AuditID: c1b4fb25-b7f038e000005d01-30-52fdbf815abd Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C1.DD.23809.18FBDF25; Fri, 14 Feb 2014 08:02:25 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.99]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0387.000; Fri, 14 Feb 2014 08:02:24 +0100 From: Christer Holmberg To: Kurtis Heimerl , "Dale R. Worley" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAAmPICAAALFAIAAAFCAgAAAZICAAAdQgIAALnMAgAZ4WICAAOAQAIAACMEAgAAEaACAAAXeAIAAJYeAgAFsZwCAAXEU6IABHbKAgAAqBACAACCygIAADx+AgACZBYqAAFFnAIAAKpNQ Date: Fri, 14 Feb 2014 07:02:24 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D172166@ESESSMB209.ericsson.se> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> <201402132328.s1DNS0U64926205@shell01.TheWorld.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D172166ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyM+JvjW7j/r9BBk/vC1ksnbSA1WLmkkcs Fi9PlDkwe0ze/5XZY8LJ8+weS5b8ZApgjuKySUnNySxLLdK3S+DKWDr3HFvB6rCK55PFGhif enUxcnJICJhInH0zgQnCFpO4cG89WxcjF4eQwCFGiW0bTzJDOIsZJWYt+svaxcjBwSZgIdH9 TxukQUQgTKLj7ksWEJtZQFvi//V1jCC2sICpxMqpLawQNWYSk6bNApsjInCJUeJUw3+wIhYB VYnJb/ezg8zkFfCV2NybAhIWEtjOI9H8ORTE5hQIlLjVsAxsPiPQcd9PrWGC2CUucevJfKij BSSW7DnPDGGLSrx8/I8VwlaS+LHhEtRt+RJNc5eCreUVEJQ4OfMJywRG0VlIRs1CUjYLSRlE XEdiwe5PbLOg3ly28DUzjH3mwGMmZPEFjOyrGNlzEzNz0suNNjECY+zglt+qOxjvnBM5xCjN waIkzvvhrXOQkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkY+dQ0VDn/tf6/rTjuFf1vW0H6h q1X4xb1HZyYWRweqf2Vayq2TP8OUe1Gjqu6DWQz2hw3OtHquUpy0IeqXbdQB9QBPj5K+2wIi 6v+jV27e6t1g4jUvOiXT5EqHFPtHxQdh+U41G48c0n6xZqnkZdEVa5YtPK+U3bL+2MUbZy9u VNRd7Cgav0OJpTgj0VCLuag4EQCsQ5QafwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/mfnU2H_jjHZLPiysvItOPyaKQN4 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 07:02:31 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D172166ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Simple mapping between two protocols is one thing. IETF has done that in th= e past, e.g. between ISUP and SIP. However, my understanding is that you want more than that. You are looking = at an architecture (or, you want to define one), and you want to define the= SIP procedures etc within that architecture to achieve certain things. Or,= am I wrong? Regards, Christer From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Kurtis Heime= rl Sent: 14. helmikuuta 2014 7:27 To: Dale R. Worley Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS OpenBTS is an instance of an Um->SIP gateway. After this implementation, we= 've become aware that a broader view of the relative correctness of our des= ign would be valuable... and that's why this thread exists. We'd like the = IETF to help standardize this gateway model and make sure that the decision= s that were made are reasonable, scalable, and intelligent. At least that's my perception on why we're here. Jim may have another. On Fri, Feb 14, 2014 at 8:28 AM, Dale R. Worley > wrote: > From: "Ralph A. Schmid, dk5ras" > (Is there a reason you insert so many blank lines?) > So imagine a village, a few hundred people living there, most of > them owning mobile phones for communication when they travel to the > town for work or for trading goods - but at home those phones are > useless. > So somebody is able to spent a few thousand dollars, puts an antenna > onto some tree, flips the switch, and a few hundred phones can (and > do) log on. > Now more and more of those low-cost networks grow up, and people > want to connect them. Internet is available in some places, cheap to > buy and install WiFi-links are established, the whole thing evolves, > some simple structure grows. This story makes sense to me. The question seems to be how to interwork the GSM radio call-control protocol with SIP, so that a set of these base stations can operate as an integrated system. You'd want some sort of SIP registrar/proxy to operate as an ITSP, and all of the base stations make SIP connections with it. The next step is for someone to start designing this use of SIP. No doubt a lot of interesting questions will arise, and you may need to design some SIP extensions. But until you've got the design started and can discuss the design decisions, you're not in a position to talk about what SIP extensions are needed. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_7594FB04B1934943A5C02806D1A2204B1D172166ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Simple mapping between tw= o protocols is one thing. IETF has done that in the past, e.g. between ISUP= and SIP.

 <= /p>

However, my understanding= is that you want more than that. You are looking at an architecture (or, y= ou want to define one), and you want to define the SIP procedures etc within that architecture to achieve certain things. Or, am I wrong?

 <= /p>

Regards,

 <= /p>

Christer

 <= /p>

From: dispatch= [mailto:dispatch-bounces@ietf.org] On Behalf Of Kurtis Heimerl
Sent: 14. helmikuuta 2014 7:27
To: Dale R. Worley
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

 

OpenBTS is an instance of an Um->SIP gateway. Aft= er this implementation, we've become aware that a broader view of the relat= ive correctness of our design would be valuable...  and that's why thi= s thread exists. We'd like the IETF to help standardize this gateway model and make sure that the decisions that were = made are reasonable, scalable, and intelligent. 

 

At least that's my perception on why we're here. Jim= may have another. 

 

On Fri, Feb 14, 2014 at 8:28 AM, Dale R. Worley <= worley@ariadne.com<= /a>> wrote:

> From: "Ralph A. Schmid, dk5ras" <<= a href=3D"mailto:ralph@schmid.xxx">ralph@schmid.xxx>

(Is there a reason you insert so many blank lines?)


> So imagine a village, a few hundred people living there, most of
> them owning mobile phones for communication when they travel to the > town for work or for trading goods - but at home those phones are
> useless.

> So somebody is a= ble to spent a few thousand dollars, puts an antenna
> onto some tree, flips the switch, and a few hundred phones can (and > do) log on.

> Now more and mor= e of those low-cost networks grow up, and people
> want to connect them. Internet is available in some places, cheap to > buy and install WiFi-links are established, the whole thing evolves, > some simple structure grows.

This story makes sense to me.  The question see= ms to be how to
interwork the GSM radio call-control protocol with SIP, so that a set
of these base stations can operate as an integrated system.  You'd
want some sort of SIP registrar/proxy to operate as an ITSP, and all
of the base stations make SIP connections with it.

The next step is for someone to start designing this use of SIP.  No doubt a lot of interesting questions will arise, and you may need to
design some SIP extensions.  But until you've got the design started and can discuss the design decisions, you're not in a position to talk
about what SIP extensions are needed.

Dale


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

 

--_000_7594FB04B1934943A5C02806D1A2204B1D172166ESESSMB209erics_-- From nobody Thu Feb 13 23:57:46 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 104451A0174 for ; Thu, 13 Feb 2014 23:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LYuG3LuH1pb for ; Thu, 13 Feb 2014 23:57:43 -0800 (PST) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id DD67B1A013D for ; Thu, 13 Feb 2014 23:57:42 -0800 (PST) X-AuditID: c1b4fb38-b7f418e000001099-13-52fdcc7454d7 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 55.05.04249.47CCDF25; Fri, 14 Feb 2014 08:57:40 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.164]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Fri, 14 Feb 2014 08:57:40 +0100 From: Ivo Sedlacek To: Tim Panton new Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPKNhhkrZYui7Q4Eii0l2hGkNSOZqzZPjg///39gCAAQEeEA== Date: Fri, 14 Feb 2014 07:57:39 +0000 Message-ID: <39B5E4D390E9BD4890E2B3107900610112662CD1@ESESSMB301.ericsson.se> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> < 52FCF23D.7070608@iptel.org> <39B5E4D390E9BD4890E2B3107900610112662679@ESESSMB301.ericsson.se> <0A527A1E-0789-41D8-902B-A1B12F03E69C@westhawk.co.uk> In-Reply-To: <0A527A1E-0789-41D8-902B-A1B12F03E69C@westhawk.co.uk> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+JvjW7Jmb9BBseaLCyWTlrAarH18jQ2 i1NLT7NYPG08y2ix7v0xFgdWj9Zne1k9liz5yeSxe8oxVo8zJ9M9Lk7bzxTAGsVlk5Kak1mW WqRvl8CVsWrqI6aCbvaKxdN6mBsYD7F2MXJySAiYSBy4vg7KFpO4cG89G4gtJHCEUeLST5cu Ri4gewmjRO+554wgCTYBPYmJW46ANYgIqEvMXHqRCaSIWWAjo8STjb3sIAlhAVOJlVNboIrM JCZNm8XcxcgBZDtJfG4LBQmzCKhKfLh1GKycV8BXYtfjU8wQy+ZwSnz++ZwJJMEJVD/1x2yw xYwCshJX//SC2cwC4hK3nsxngrhaQGLJnvPMELaoxMvH/6C+UZL4seESC0S9jsSC3Z/YIGxt iWULXzNDLBaUODnzCcsERrFZSMbOQtIyC0nLLCQtCxhZVjFyFKcWJ+WmGxlsYgRG2MEtvy12 MF7+a3OIUZqDRUmc9+Nb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjMnvbATuBFS6P1H2 uV/tVt7Zv4WrebH25nUzv02xqzPUL1OSiZC5EiezhnNvvMmHk91PL2ouu6vBvvmMfK+XePJK 8bd+PPyb7x/Lz3n7T9k0+N8Lg3msz3pMVr9tF1y3qlZ54ZGbqe0MZ5Jn+LSde72ReUFuRuiz 3//eac8+cqn30Pekia3h7kosxRmJhlrMRcWJANWRO2Z+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/xbksRqVxsjFHh2z5_dP5RaHK1zU Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 07:57:45 -0000 Hello Tim and all, > Apples and oranges - If I want a continent spanning, roaming capable bill= ion dollar GSM network, then I need an IMS system. > If I want an Um to SIP gateway I can run off solar power and hang in a tr= ee, I'll go for an openBTS like solution. If you want an Um to SIP gateway (for whatever purpose), you need a license= . To get a license, you will need to satisfy regulator's requirements.=20 You still have not provided any references to regulators' document stating = that a GSM band is free in any country. You still have not explain how such BTS "running off solar power and hangin= g in a tree" does not interfere with other BTSs hanging on the next tree. So, I am afraid, the BTS and Um To SIP gateway hanging will be switched off= pretty quickly due to being illegal or causing interferences with other GS= M nodes. Kind regards Ivo Sedlacek From nobody Fri Feb 14 04:11:51 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A47E21A021C for ; Fri, 14 Feb 2014 04:11:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wArM-ckgTWcE for ; Fri, 14 Feb 2014 04:11:45 -0800 (PST) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 088AF1A0212 for ; Fri, 14 Feb 2014 04:11:44 -0800 (PST) Received: by mail-oa0-f45.google.com with SMTP id i11so14340535oag.4 for ; Fri, 14 Feb 2014 04:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ETKMaVntuaUsP290jJC0uQyF1iWNRcg/0abq05rvQ4w=; b=E9MIDhVtJfdi8FzjT9UI9ZdE6Gg1/SyhCoq/vtcm8Gd2SQQHCSpwxorluEdp185ho5 /ayDgNM5cI+P0sgI3+jzYKlnWNbapPLTbjj6MjETKDaMW6wxq53N3UMMw+dhc/VZp7ni d/yILgyKTRJTN34Wl/qa6KNPDQeWfq0FLnZJpjEU60eGHL/STeEQLyd6UAN2N/HaZaYB Gr1cpssdDE1TA8keKrKaEizKBNLzeAybNLCFzZTvCaPwWZ2f6HDeZ1IfnzaiguAo8+O9 KEwZ2pRClBZaup6Q7/0tujAn1LEfMS/RFklu6EXxIwlOulWj7FFjITyH8/oJQJpL0hDD eUNQ== X-Received: by 10.182.126.167 with SMTP id mz7mr256433obb.69.1392379903449; Fri, 14 Feb 2014 04:11:43 -0800 (PST) Received: from [192.168.0.101] ([207.112.119.16]) by mx.google.com with ESMTPSA id wj7sm15517633obc.8.2014.02.14.04.11.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Feb 2014 04:11:42 -0800 (PST) Message-ID: <52FE0800.2080408@gmail.com> Date: Fri, 14 Feb 2014 07:11:44 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> < 52FCF23D.7070608@iptel.org> <39B5E4D390E9BD4890E2B3107900610112662679@ESESSMB301.ericsson.se> <0A527A1E-0789-41D8-902B-A1B12F03E69C@westhawk.co.uk> <39B5E4D390E9BD4890E2B3107900610112662CD1@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112662CD1@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Mi3Tm5KCsYHF21yTvoSgZj0wTfw Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 12:11:50 -0000 Your interventions in particular smack of an attempt to suppress potential competition through intimidation. I'll let you deal with the legalities of that. My personal opinion is that this sort of discussion does not belong on IETF lists. I support Mary's viewpoint that our role is technical only. Let the application find its own place after we do our job. Tom Taylor On 14/02/2014 2:57 AM, Ivo Sedlacek wrote: > Hello Tim and all, > >> Apples and oranges - If I want a continent spanning, roaming capable billion dollar GSM network, then I need an IMS system. >> If I want an Um to SIP gateway I can run off solar power and hang in a tree, I'll go for an openBTS like solution. > > If you want an Um to SIP gateway (for whatever purpose), you need a license. To get a license, you will need to satisfy regulator's requirements. > > You still have not provided any references to regulators' document stating that a GSM band is free in any country. > > You still have not explain how such BTS "running off solar power and hanging in a tree" does not interfere with other BTSs hanging on the next tree. > > So, I am afraid, the BTS and Um To SIP gateway hanging will be switched off pretty quickly due to being illegal or causing interferences with other GSM nodes. > > Kind regards > > Ivo Sedlacek > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Fri Feb 14 05:14:07 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE1E1A01D6 for ; Fri, 14 Feb 2014 05:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f2jMRrUzwHQG for ; Fri, 14 Feb 2014 05:13:53 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id C6AE71A0222 for ; Fri, 14 Feb 2014 05:13:52 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1EDDn0T026289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 14:13:49 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1EDDmER002213 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 14:13:48 +0100 Received: from DEMUMBX001.nsn-intra.net ([169.254.1.157]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 14:13:48 +0100 From: "Belling, Thomas (NSN - DE/Munich)" To: ext Tom Taylor , "dispatch@ietf.org" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAAmPICAAALFAIAAAFCAgAAAZICAAAdQgIAALnMAgAZ4WICAAOAQAIAACMEAgAAEaACAAainlYABYDyFgAEdr4CAACoEAIAAILKAgAAfZYCAAAi7AIAABewAgAD1eYCAAEb+AIAAHdJw Date: Fri, 14 Feb 2014 13:13:48 +0000 Message-ID: References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> < 52FCF23D.7070608@iptel.org> <39B5E4D390E9BD4890E2B3107900610112662679@ESESSMB301.ericsson.se> <0A527A1E-0789-41D8-902B-A1B12F03E69C@westhawk.co.uk> <39B5E4D390E9BD4890E2B3107900610112662CD1@ESESSMB301.ericsson.se> <52FE0800.2080408@gmail.com> In-Reply-To: <52FE0800.2080408@gmail.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.126] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2791 X-purgate-ID: 151667::1392383629-00001A6F-7CFCD2D6/0-0/0-0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/yocgmclFBxnlsIHOnAWp3iNJqu4 Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 13:14:02 -0000 Dear Tom, your proposal for technical work seems to be that you want to describe inte= rworking between 3GPP radio protocols and SIP? Would IETF or 3GPP be a more appropriate organization for that? IETF owns SIP but lacks expertise for the radio protocols. 3GPP knows their own protocols, and also has a certain SIP expertise by now= . 3GPP also has experience with regulatory issues and interference problems t= hat have been mentioned, and works based on operator requirements (that are= your target customers based on your last explanations?). My conclusion thu= s is that 3GPP appears to be the more appropriate forum for such discussion= s. By the way, there is already a comparable 3GPP spec, TS 29.292, although it= was written for a more specific IMS related use case. BR, Thomas ---------------------------------- Dr. Thomas Belling=20 3GPP Standardisation NSN -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of ext Tom Tayl= or Sent: Friday, February 14, 2014 1:12 PM To: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS Your interventions in particular smack of an attempt to suppress potential = competition through intimidation. I'll let you deal with the legalities of = that. My personal opinion is that this sort of discussion does not belong o= n IETF lists. I support Mary's viewpoint that our role is technical only. L= et the application find its own place after we do our job. Tom Taylor On 14/02/2014 2:57 AM, Ivo Sedlacek wrote: > Hello Tim and all, > >> Apples and oranges - If I want a continent spanning, roaming capable bil= lion dollar GSM network, then I need an IMS system. >> If I want an Um to SIP gateway I can run off solar power and hang in a t= ree, I'll go for an openBTS like solution. > > If you want an Um to SIP gateway (for whatever purpose), you need a licen= se. To get a license, you will need to satisfy regulator's requirements. > > You still have not provided any references to regulators' document statin= g that a GSM band is free in any country. > > You still have not explain how such BTS "running off solar power and hang= ing in a tree" does not interfere with other BTSs hanging on the next tree. > > So, I am afraid, the BTS and Um To SIP gateway hanging will be switched o= ff pretty quickly due to being illegal or causing interferences with other = GSM nodes. > > Kind regards > > Ivo Sedlacek > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Fri Feb 14 05:51:00 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B961A0256 for ; Fri, 14 Feb 2014 05:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jx2SEUoGePVL for ; Fri, 14 Feb 2014 05:50:57 -0800 (PST) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6291A0255 for ; Fri, 14 Feb 2014 05:50:57 -0800 (PST) Received: by mail-ob0-f176.google.com with SMTP id gq1so13772007obb.7 for ; Fri, 14 Feb 2014 05:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=5uOxpK930RW824zCEf7xdZdUARA7nHvCgku9LIndfmo=; b=p6ygjon88NsdQlUEQkN2W+5NT53TN0PMLZJgFtKB+qpzPD1r/ohWKgnobpR4R3lNFY EeJQrlGakUyF/KecL+9DfaGX7ZU22ljLZ72YBN/N7oVFrB0oshRVR3o/7rXmUa+Wgsl4 avKrNfUHXQ/zAAdrzoxgnPwR3yQot5VZYkoZr6KI4GEBbFD7Aaswh0lxiJ3kI/sh3ZjQ kORGhG0kOhNmb9CPBv2hgNKI3EBJLrdnqDHrDfsU9PVGUlLsl+3836cJKIPBGAYOz8Wz iDDNi7RFh9tipSC9zmyQp027KiWn9ObYaOdwfAP1D2DF2aQd47uEoyk+6SHzyGZO37E/ bJaA== X-Received: by 10.60.173.147 with SMTP id bk19mr6691292oec.46.1392385855830; Fri, 14 Feb 2014 05:50:55 -0800 (PST) Received: from [192.168.0.101] ([207.112.119.16]) by mx.google.com with ESMTPSA id b2sm36651277oed.7.2014.02.14.05.50.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Feb 2014 05:50:55 -0800 (PST) Message-ID: <52FE1F3F.3020505@gmail.com> Date: Fri, 14 Feb 2014 08:50:55 -0500 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Belling, Thomas (NSN - DE/Munich)" , "dispatch@ietf.org" References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> < 52FCF23D.7070608@iptel.org> <39B5E4D390E9BD4890E2B3107900610112662679@ESESSMB301.ericsson.se> <0A527A1E-0789-41D8-902B-A1B12F03E69C@westhawk.co.uk> <39B5E4D390E9BD4890E2B3107900610112662CD1@ESESSMB301.ericsson.se> <52FE0800.2080408@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/fdcnhEcVCjSjr_yqW65ZoTcnppg Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 13:50:59 -0000 If the WG runs into a dead end for lack of expertise, so be it. Otherwise, this is the IETF, an open forum, and interesting technical problems are surely always welcome. Tom Taylor On 14/02/2014 8:13 AM, Belling, Thomas (NSN - DE/Munich) wrote: > Dear Tom, > > your proposal for technical work seems to be that you want to describe interworking between 3GPP radio protocols and SIP? > > Would IETF or 3GPP be a more appropriate organization for that? > IETF owns SIP but lacks expertise for the radio protocols. > 3GPP knows their own protocols, and also has a certain SIP expertise by now. > 3GPP also has experience with regulatory issues and interference problems that have been mentioned, and works based on operator requirements (that are your target customers based on your last explanations?). My conclusion thus is that 3GPP appears to be the more appropriate forum for such discussions. > > By the way, there is already a comparable 3GPP spec, TS 29.292, although it was written for a more specific IMS related use case. > > BR, Thomas > > > ---------------------------------- > Dr. Thomas Belling > 3GPP Standardisation > NSN > > ..., From nobody Fri Feb 14 07:30:50 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A62BB1A029E for ; Fri, 14 Feb 2014 07:30:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHwYT1rciXub for ; Fri, 14 Feb 2014 07:30:37 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 2179F1A0242 for ; Fri, 14 Feb 2014 07:30:31 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 07:30:34 -0800 From: Michael Hammer To: "mary.ietf.barnes@gmail.com" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAC9HICAAALFAIAAAFCA//96B5CAAI2tgIAALnMAgAZ4WICAAOAQAIAACMEAgAAEaACAAAXeAIAAJYeAgAFsZwCAANo2FIABtI+AgAAqBQCAACCxgIAABEMAgAAK7oCAAFDzgP//goyfgACWJ4CAAKAtAA== Date: Fri, 14 Feb 2014 15:30:27 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF2B047@sc9-ex2k10mb1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBF2A4FF@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.96] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_009D_01CF296F.C63F2750" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/QqWhszxuu1cMKm1NUvxwxjJDL1U Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 15:30:48 -0000 ------=_NextPart_000_009D_01CF296F.C63F2750 Content-Type: multipart/alternative; boundary="----=_NextPart_001_009E_01CF296F.C63F2750" ------=_NextPart_001_009E_01CF296F.C63F2750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mary, The Base Transceiver Station (BTS) is not an LTE component, it is more legacy base station technology. The eNodeB is what LTE uses, which is what IMS would be transported by. The radio access network just provides an IP path from the handset IMS client to the IMS core elements. There is no interworking at SIP layer for anything in the access network. So, 2 cases: Case 1: the radio access network does not have connectivity to the core network: solution may be to have a P2P SIP application that kicks in for local connectivity. This can be developed from current standard SIP protocol. No new SIP attributes have been proposed. Case 2: the radio access network does have connectivity to the core network: The IMS client should be able to connect to the core IMS components and operate as normal in the LTE/IMS/VoLTE network. Again, no new SIP attributes have been proposed. So, I ask again for the third time, what IETF protocol or extension thereto is being proposed? All the radio discussion as far as I can tell is just marketing, looking for approval from IETF for deploying non-compliant 3GPP base stations. I think that may be dangerous and damaging of relationship between IETF and 3GPP. I admit maybe I have missed something, but someone needs to spell out more clearly what they want to standardize. If need be draw a picture. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Thursday, February 13, 2014 4:47 PM To: Michael Hammer Cc: DRAGE, Keith (Keith); dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS I have stated specifics before as to the context for this and IETF: http://www.ietf.org/mail-archive/web/dispatch/current/msg05252.html One of the things they are explicitly talking about the Radio layer Call control protocol interworking with SIP. Now, if folks are saying that this interworking between these call control messages and SIP would be the same in the BTS as it would be in the MSC, then a pointer to the exact IMS spec that provides all these details would be most helpful. My guess is that this problem doesn't require the complete functionality defined by CT1. It's certainly possible that there is a subset of those specifications which could help meet their needs and I assume they would have dug through those already). But, explicit pointers to those rather than a blanket statement that IMS solves this specific problem would be really helpful. I totally agree that the proponents have a lot more detail to provide so that folks can understand the interworking and functionality that they are wanting that is relevant to IETF and SIP. Mary On Thu, Feb 13, 2014 at 2:49 PM, Michael Hammer wrote: Mary. Interworking sip with radio protocols is like saying inter working sip with ip. Makes no sense. So far I have not seen any case for work in IETF. This is more analogous to ITU- T attempt to screw up MPLS as far as I can tell. I asked the question before and still do not see a connection to any IETF work. Cut out the business case and nothing has been proposed. Sent with Good (www.good.com) ------ Original Message ------ From: Mary Barnes Sent: Thursday, February 13, 2014 at 3:19 PM To: DRAGE, Keith (Keith) Cc: dispatch@ietf.org Subject: [dispatch] SIP and GSM/UMTS with OpenBTS On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith) wrote: Ericsson is not the only vendor that sees a market for small cells, but the expectation is that the products are built to the completed 3GPP standards will be deployed in licensed spectrum by owners of that spectrum, although the boxes may well be owned by 3rd parties. These deployments already exist. I see Jim has now identified that this proposal is for licensed GSM operators in licensed GSM space. Personally, I would suggest if you believe the operators should be picking this up, you take it to 3GPP where the operators are actually present. That is the only way you will see it taken up by GSMA, which you will need to obtain interoperator agreements to use this (e.g. roaming, shared networks). 3GPP them works with IETF on any SIP extensions needed. [MB] One big problem with this proposal is that you must be a member of 3GPP/GSMA to make contributions and to participate in meetings. And, I think having to first do the work in 3GPP and then bring it to IETF would introduce a tremendous delay for something that's already been implemented/deployed. While they are proposing to reuse elements and protocols that are part of an IMS network, the core issue they have is with interworking SIP with the radio layer protocols. Certainly, one could implement all the protocols that IMS uses and then use the 3GPP based specs and proprietary headers to interwork with SIP in the Internet, but that would be terribly inefficient. [/MB] I would only see IETF having any direct part in this if the proposal was only to use unlicensed spectrum by enterprises rather than licensed operators, which Jim has negated. regards Keith _____ From: Tim Panton new [mailto:thp@westhawk.co.uk] Sent: 13 February 2014 14:50 To: DRAGE, Keith (Keith) Cc: Harvind Samra; Ivo Sedlacek; dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) wrote: Jumping in here, they are relevant in as much as there is no point in IETF working on this if there is no known market for it. Usually those type of projects are published only on April 1st. So all Ivo is asking is for you to justify that it is worth other people working on this as well as yourselves. Perhaps if you identified the spectrum you believe is available for use in the the countries identified, that would be useful. regards Keith Drage Ivo's employer seems to see a market for small cells, but looks to tie them to existing operator IMS's through internet connections "owned by themselves or a partner". http://www.telecomlead.com/enterprise-networking/mwc-2014-ericsson-announce- small-cell-service-20233/ Perhaps that's an April fools joke too (I can't see any avian carriers mentioned though)? It isn't up to the IETF to crown specific solutions. That's the market's job. T. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_001_009E_01CF296F.C63F2750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mary,

 

The Base Transceiver Station (BTS) is not an LTE component, it is = more legacy base station technology.

The eNodeB is what LTE uses, which is what IMS would be transported = by.

The radio access network just provides an IP path from the handset = IMS client to the IMS core elements.

There is no interworking at SIP layer for anything in the access = network.

 

So, 2 cases: 

Case 1:  the radio access network does not have connectivity to = the core network: 

solution may be to have a P2P SIP application that kicks in for local = connectivity.

This can be developed from current standard SIP protocol.  =

No new SIP attributes have been proposed.

 

Case 2:  the radio access network does have connectivity to the = core network:

The IMS client should be able to connect to the core IMS components = and operate as normal in the LTE/IMS/VoLTE = network.

Again, no new SIP attributes have been = proposed.

 

So, I ask again for the third time, what IETF protocol or extension = thereto is being proposed?

 

All the radio discussion as far as I can tell is just marketing, = looking for approval from IETF for deploying non-compliant 3GPP base = stations.

I think that may be dangerous and damaging of relationship between = IETF and 3GPP.

 

I admit maybe I have missed something, but someone needs to spell out = more clearly what they want to standardize.

If need be draw a picture.

 

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com

Mobile: +1 408-202-9291

500 Yosemite Drive Suite = 120

Milpitas, CA 95035 = USA

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: = Thursday, February 13, 2014 4:47 PM
To: Michael = Hammer
Cc: DRAGE, Keith (Keith); = dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS = with OpenBTS

 

I = have stated specifics before as to the context for this and = IETF: 

Mary

On Thu, Feb 13, 2014 at 2:49 PM, Michael Hammer <michael.hammer@yaanatech.com> = wrote:

Mary. Interworking sip with radio protocols is =
like saying inter working sip with ip. Makes no sense.  So far I =
have not seen any case for work in IETF.  This is more analogous to =
ITU- T attempt to screw up MPLS as far as I can tell. =

 
I asked the question =
before and still do not see a connection to any IETF work.  Cut out =
the business case and nothing has been proposed. =

 
 
= 
 
Sent with Good (www.good.com)

------ Original Message ------ =
From: Mary Barnes
Sent: Thursday, February 13, 2014 = at 3:19 PM
To: DRAGE, Keith (Keith)
Cc: dispatch@ietf.org
Subject: [dispatch] = SIP and GSM/UMTS with OpenBTS

 

 

On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith) = <keith.drage@alcatel-lucent.com> = wrote:

Ericsson is not = the only vendor that sees a market for small cells, but the expectation = is that the products are built to the completed 3GPP standards will be = deployed in licensed spectrum by owners of that spectrum, although the = boxes may well be owned by 3rd parties.

 

These deployments = already exist.

 

I see Jim has now = identified that this proposal is for licensed GSM operators in licensed = GSM space.

 

Personally, I = would suggest if you believe the operators should be picking this up, = you take it to 3GPP where the operators are actually present. That is = the only way you will see it taken up by GSMA, which you will need to = obtain interoperator agreements to use this (e.g. roaming, shared = networks). 3GPP them works with IETF on any SIP extensions = needed.

[MB] One = big problem with this proposal is that you must be a member of 3GPP/GSMA = to make contributions and to participate in meetings.   =  

 

And, I think having to first do the work in 3GPP and = then bring it to IETF would introduce a tremendous delay for something = that's already been implemented/deployed.  While they are proposing = to reuse elements and protocols that are part of an IMS network, the = core issue they have is with interworking SIP with the radio layer = protocols.  Certainly, one could implement all the protocols that = IMS uses and then use the 3GPP based specs and proprietary headers to = interwork with SIP in the Internet, but that would be terribly = inefficient. 

[/MB] 

 

I would only see = IETF having any direct part in this if the proposal was only to use = unlicensed spectrum by enterprises rather than licensed operators, which = Jim has negated.

 

regards=

 

Keith

 

From: Tim Panton new [mailto:thp@westhawk.co.uk]

Sent: 13 February 2014 = 14:50
To: DRAGE, Keith (Keith)
Cc: Harvind Samra; = Ivo Sedlacek; dispatch@ietf.org


Subject: Re: = [dispatch] SIP and GSM/UMTS with OpenBTS

 

 

On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> = wrote:



Jumping in here, = they are relevant in as much as there is no point in IETF working on = this if there is no known market for it.

 

Usually those type = of projects are published only on April 1st.

 

So all Ivo is = asking is for you to justify that it is worth other people working on = this as well as yourselves.

 

Perhaps if you = identified the spectrum you believe is available for use in the the = countries identified, that would be useful.

 

regards=

 

Keith = Drage

 

Ivo's = employer seems to see a market for small cells, but looks to tie them to = existing operator IMS's through 

internet connections "owned by themselves or a = partner".

Perhaps that's an April fools joke too (I can't = see any avian carriers mentioned though)?

 

It isn't up to the IETF to crown specific solutions. = That's the market's job.

 

T.

 

 

 


______________________________________= _________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch=

 

 

------=_NextPart_001_009E_01CF296F.C63F2750-- ------=_NextPart_000_009D_01CF296F.C63F2750 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIx NDE1MzAyNlowIwYJKoZIhvcNAQkEMRYEFPUO30ExB/IXwypvN9LujuWYpVbVMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAFhJodUhGZgd93K6z1sAq11+jBs/Qgyw9vxLYRH1Z NZlO8zXFW0UK3CliLujGqFx/RuzhSdnO+GITG155LYmYdnUNacHU8PjtbDlRXm3xEboDucSR5v9d ZrNSQeqtYmTnmYGjZOfeyhnNYmx/b6v6PE0ourHQ3CgzDhCNTdlkPox1LraY4DtjV6zb4OLUjt8G ik31+qqH90nx5fcUKCt1cizMZWFvbEGR1jtbscNq4Um1cEKHmNvpaUazdv/dKsu5OXr60cWuIj7l d+0UbbrIDcOqAcAfxjShnGfO3ychdonRKhqNbQ9OkAeqqyAG5obSY33npvuQ4ZGxPJE63rHpTgAA AAAAAA== ------=_NextPart_000_009D_01CF296F.C63F2750-- From nobody Fri Feb 14 08:08:48 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 573D81A0270 for ; Fri, 14 Feb 2014 08:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGQe8OdMFpy2 for ; Fri, 14 Feb 2014 08:08:38 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 684E11A025A for ; Fri, 14 Feb 2014 08:08:38 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 08:08:42 -0800 From: Michael Hammer To: "kheimerl@cs.berkeley.edu" , "worley@ariadne.com" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAC9HICAAALFAIAAAFCA//96B5CAAI2tgIAALnMAgAZ4WICAAOAQAIAACMEAgAAEaACAAAXeAIAAJYeAgAFsZwCAANo2FIABtI+AgAAqBQCAACCxgIAADyCAgAACJnGAAOhFAIAAKcuQ Date: Fri, 14 Feb 2014 16:08:35 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF2B24F@sc9-ex2k10mb1.corp.yaanatech.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> <201402132328.s1DNS0U64926205@shell01.TheWorld.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.96] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A7_01CF2975.19FE91A0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/ENuylLZmr4AcjlNS-ntaeRtTxaE Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:08:43 -0000 ------=_NextPart_000_00A7_01CF2975.19FE91A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A8_01CF2975.19FE91A0" ------=_NextPart_001_00A8_01CF2975.19FE91A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit OK, let me add some protocol perspective. Cut and paste courtesy of Wikipedia: **** The Um interface is the air interface for the GSM mobile telephone standard. It is the interface between the mobile station (MS) and the Base transceiver station (BTS). It is called Um because it is the mobile analog to the U interface of ISDN . Um is defined in the GSM 04.xx and 05.xx series of specifications. Um can also support GPRS packet-oriented communication. Um layers[edit ] The layers of GSM are initially defined in GSM 04.01 Section 7 and roughly follow the OSI model . Um is defined in the lower three layers of the model. Network Layer (L3)[edit ] The Um network layer is defined in GSM 04.07 and 04.08 and has three sublayers. A subscriber terminal must establish a connection in each sublayer before accessing the next higher sublayer. 1. Radio Resource (RR). This sublayer manages the assignment and release of logical channels on the radio link. It is normally terminated in the BSC . 2. Mobility Management (MM). This sublayer authenticates users and tracks their movements from cell to cell. It is normally terminated in the VLR or HLR . 3. Call Control (CC). This sublayer connects telephone calls and is taken directly from ITU-T Q.931 . GSM 04.08 Annex E provides a table of corresponding paragraphs in GSM 04.08 and ITU-T Q.931 along with a summary of differences between the two. The CC sublayer is terminated in the MSC . The access order is RR, MM, CC. The release order is the reverse of that. Note that none of these sublayers terminate in the BTS itself. The standard GSM BTS operates only in layers 1 and 2. *** So, the implementation appears to move the MSC to the BTS, along with a Q.931 to SIP GW, such as: ETSI TS 183 036 V3.4.1 (2011-02) Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); ISDN/SIP interworking; Protocol specification Not sure how that saves battery, but that is an implementation question we don't need to answer. Note also that since Um supports GPRS, could the BTS not also support a packet relay for higher layer P2P SIP call control? Just asking. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Kurtis Heimerl Sent: Friday, February 14, 2014 12:27 AM To: Dale R. Worley Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS OpenBTS is an instance of an Um->SIP gateway. After this implementation, we've become aware that a broader view of the relative correctness of our design would be valuable... and that's why this thread exists. We'd like the IETF to help standardize this gateway model and make sure that the decisions that were made are reasonable, scalable, and intelligent. At least that's my perception on why we're here. Jim may have another. On Fri, Feb 14, 2014 at 8:28 AM, Dale R. Worley wrote: > From: "Ralph A. Schmid, dk5ras" (Is there a reason you insert so many blank lines?) > So imagine a village, a few hundred people living there, most of > them owning mobile phones for communication when they travel to the > town for work or for trading goods - but at home those phones are > useless. > So somebody is able to spent a few thousand dollars, puts an antenna > onto some tree, flips the switch, and a few hundred phones can (and > do) log on. > Now more and more of those low-cost networks grow up, and people > want to connect them. Internet is available in some places, cheap to > buy and install WiFi-links are established, the whole thing evolves, > some simple structure grows. This story makes sense to me. The question seems to be how to interwork the GSM radio call-control protocol with SIP, so that a set of these base stations can operate as an integrated system. You'd want some sort of SIP registrar/proxy to operate as an ITSP, and all of the base stations make SIP connections with it. The next step is for someone to start designing this use of SIP. No doubt a lot of interesting questions will arise, and you may need to design some SIP extensions. But until you've got the design started and can discuss the design decisions, you're not in a position to talk about what SIP extensions are needed. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_001_00A8_01CF2975.19FE91A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

OK, let me add some protocol perspective.  Cut and paste = courtesy of Wikipedia:

****

The = Um interface is the air interface for the GSM mobile = telephone standard. It is the interface between the mobile station (MS) and the Base transceiver station (BTS). = It is called Um because it is the mobile analog to the U interface of ISDN. Um is = defined in the GSM 04.xx and 05.xx series of specifications. Um can also = support GPRS packet-oriented communication.

Um layers[edit]

The layers of GSM are initially defined in GSM 04.01 Section 7 = and roughly follow the OSI = model. Um is defined in the lower three layers of the = model.

Network Layer (L3)[edit]

The Um network layer is defined in GSM 04.07 and = 04.08 and has three sublayers. A subscriber terminal must establish a = connection in each sublayer before accessing the next higher = sublayer.

  1. Radio Resource (RR). This = sublayer manages the assignment and release of logical channels on the = radio link. It is normally terminated in the BSC.
  2. Mobility Management (MM). This = sublayer authenticates users and tracks their movements from cell to = cell. It is normally terminated in the VLR or HLR.
  3. Call Control (CC). This sublayer connects telephone calls = and is taken directly from ITU-T = Q.931. GSM 04.08 Annex E provides a table of corresponding = paragraphs in GSM 04.08 and ITU-T Q.931 along with a summary of = differences between the two. The CC sublayer is terminated in the MSC.

The = access order is RR, MM, CC. The release order is the reverse of that. =

Note that none of these = sublayers terminate in the BTS itself. The standard GSM BTS operates = only in layers 1 and 2.

***

So, the implementation appears to move the MSC to the BTS, along with = a Q.931 to SIP GW, such as:

ETSI TS 183 036 V3.4.1 (2011-02) Telecommunications and Internet = converged Services and Protocols for Advanced Networking = (TISPAN);

ISDN/SIP interworking; Protocol specification

 

Not sure how that saves battery, but that is an implementation = question we don’t need to answer.

 

Note also that since Um supports GPRS, could the BTS not also support = a packet relay for higher layer P2P SIP call = control?

 

Just asking.

 

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com

Mobile: +1 408-202-9291

500 Yosemite Drive Suite = 120

Milpitas, CA 95035 = USA

 

From:= = dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Kurtis = Heimerl
Sent: Friday, February 14, 2014 12:27 AM
To: = Dale R. Worley
Cc: dispatch@ietf.org
Subject: Re: = [dispatch] SIP and GSM/UMTS with OpenBTS

 

OpenBTS = is an instance of an Um->SIP gateway. After this implementation, = we've become aware that a broader view of the relative correctness of = our design would be valuable...  and that's why this thread exists. = We'd like the IETF to help standardize this gateway model and make sure = that the decisions that were made are reasonable, scalable, and = intelligent. 

 

At least that's my perception on why we're here. Jim = may have another. 

 

On Fri, Feb 14, 2014 at 8:28 AM, Dale R. Worley <worley@ariadne.com> wrote:

> From: "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx>

(Is = there a reason you insert so many blank lines?)


> So imagine a = village, a few hundred people living there, most of
> them owning = mobile phones for communication when they travel to the
> town for = work or for trading goods - but at home those phones are
> = useless.

> So somebody is able to spent a few = thousand dollars, puts an antenna
> onto some tree, flips the = switch, and a few hundred phones can (and
> do) log = on.

> Now more and more of those low-cost = networks grow up, and people
> want to connect them. Internet is = available in some places, cheap to
> buy and install WiFi-links = are established, the whole thing evolves,
> some simple structure = grows.

This story makes sense = to me.  The question seems to be how to
interwork the GSM radio = call-control protocol with SIP, so that a set
of these base stations = can operate as an integrated system.  You'd
want some sort of = SIP registrar/proxy to operate as an ITSP, and all
of the base = stations make SIP connections with it.

The next step is for = someone to start designing this use of SIP.  No
doubt a lot of = interesting questions will arise, and you may need to
design some SIP = extensions.  But until you've got the design started
and can = discuss the design decisions, you're not in a position to talk
about = what SIP extensions are needed.

Dale


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

 

------=_NextPart_001_00A8_01CF2975.19FE91A0-- ------=_NextPart_000_00A7_01CF2975.19FE91A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIx NDE2MDgzNFowIwYJKoZIhvcNAQkEMRYEFAAl4DNLF9H+iiP5UlYyBIVflH1BMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAOxcoWm3AhKeGKVdPcUq86Uz0wSr3CNpSTPL7k2rS R+zYz6k7IetV1T5P2RXlXc2QG0gaXHehKppHvZWzcSBayjqaVuCHmorUFUOcCj6jV5XU0YfHSTi/ Ki2O2W/Tb9GPp742lMjPuMMbtIvor8ttqp2ma2bO5mKEhTlDUqaHL1AKOZNLs+J+y4UmC8iSZuzA z7j8bH+gguA3YE6wNzanLBfac1G6eLRuNRUp5mqr1tBSNZFwvPJ/HAOjZl0A21JY6l6Vv1cN6ReG vcvfjdhuowWhQaoJPb+ujwbQn8pE6uV9I88a62WM2XWNChDl7et9wEpv9Ph9vIatkytlCLZ6UwAA AAAAAA== ------=_NextPart_000_00A7_01CF2975.19FE91A0-- From nobody Fri Feb 14 08:32:05 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE0A1A02EE for ; Fri, 14 Feb 2014 08:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0cnlHU6pd1t for ; Fri, 14 Feb 2014 08:31:57 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id E369F1A02E3 for ; Fri, 14 Feb 2014 08:31:56 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s1EGUGBW010016; Fri, 14 Feb 2014 11:30:18 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s1EGQc9H5004956; Fri, 14 Feb 2014 11:26:38 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s1EGQbQ35009342; Fri, 14 Feb 2014 11:26:37 -0500 (EST) Date: Fri, 14 Feb 2014 11:26:37 -0500 (EST) Message-Id: <201402141626.s1EGQbQ35009342@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Tom Taylor In-reply-to: <52FE0800.2080408@gmail.com> (tom.taylor.stds@gmail.com) References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> < 52FCF23D.7070608@iptel.org> <39B5E4D390E9BD4890E2B3107900610112662679@ESESSMB301.ericsson.se> <0A527A1E-0789-41D8-902B-A1B12F03E69C@westhawk.co.uk> <39B5E4D390E9BD4890E2B3107900610112662CD1@ESESSMB301.ericsson.se> <52FE0800.2080408@gmail.com> Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/achvDvWBPxlxbuEHIasxKwLikFU Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:32:02 -0000 > From: Tom Taylor > I support Mary's viewpoint that our role is technical only. Let the > application find its own place after we do our job. It does help to know that there is actual demand for a certain functionality before one invests much time figuring out how to provide the functionality. In this case, I expect the OpenBTS people have good contact with the businesses/NGOs/whatever that intend to deploy such systems, and they could report on the demand that has been expressed. Given the complexities of the law in the 230 or so nations of the world -- in all cases, the de-facto rules are different from the official rules -- I would trust local organizations to have a better understanding of whether and how such a system could be deployed in practice than anyone sitting in another country. Dale From nobody Fri Feb 14 08:32:06 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B48111A02FB for ; Fri, 14 Feb 2014 08:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQYgnczoQSba for ; Fri, 14 Feb 2014 08:31:57 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id E17E81A02DF for ; Fri, 14 Feb 2014 08:31:56 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s1EGVhxS017385; Fri, 14 Feb 2014 11:31:45 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s1EGQ9vj5008385; Fri, 14 Feb 2014 11:26:09 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s1EGQ8TB4987131; Fri, 14 Feb 2014 11:26:08 -0500 (EST) Date: Fri, 14 Feb 2014 11:26:08 -0500 (EST) Message-Id: <201402141626.s1EGQ8TB4987131@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Kurtis Heimerl In-reply-to: (kheimerl@cs.berkeley.edu) References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> <201402132328.s1DNS0U64926205@shell01.TheWorld.com> Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/IkrzRxtr6OSJ_SWScfJBv4HyBOw Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:32:03 -0000 > From: Kurtis Heimerl > OpenBTS is an instance of an Um->SIP gateway. After this implementation, > we've become aware that a broader view of the relative correctness of our > design would be valuable... and that's why this thread exists. We'd like > the IETF to help standardize this gateway model and make sure that the > decisions that were made are reasonable, scalable, and intelligent. That makes sense. But do take into account that the IETF does not standardize gateways. SIP is a protocol, and various messages are defined to operate in certain ways. Your gateway is "correct" if it gets the desired results using the standardized facilities provided by SIP. It sounds like what you're looking for is a thorough review of the design's use of SIP. That's not something that the IETF does, though the IETF is a good place to find SIP experts who can assess your design. The first step is to provide a reference to the design documentation. A design can't be reviewed if it isn't documented. Dale From nobody Fri Feb 14 08:54:52 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11EC31A02B0 for ; Fri, 14 Feb 2014 08:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.323 X-Spam-Level: X-Spam-Status: No, score=0.323 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_BACKHAIR_32=1, J_CHICKENPOX_64=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ggmp3JZG09PR for ; Fri, 14 Feb 2014 08:54:44 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) by ietfa.amsl.com (Postfix) with ESMTP id 813251A02CF for ; Fri, 14 Feb 2014 08:54:43 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id w7so9758290lbi.27 for ; Fri, 14 Feb 2014 08:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=uYaXvVvFodW6s+u7q4lxJp39e6+xWrq8PMdanU54q/E=; b=jmSM1DDyJqwMq9gHuPteDR/kfr8ile2JUr5Ujw1m3uXlHESgKIgPJTaYHlmifUKfAp 8BxmDNjmUM/BHv9Rqs5ejJuTmc6ufqrpe6C18mE+2WmqORmQc8S/7mowM1VyTt0+yc26 EY9Wcw7u13kaMWuoLaDB3GS1cxZFcvbJjUbS5ZjbQoR7mw8u+2N71p7az68j4HTDNCU+ nj+RAtn4KtnOytTNkQqG6vVnlTwRZsdJ0k+/hZHhQEx+U7PgndU6z02YkWtt4RHT6rKp 0g8+WqcJtfhjt3jFNU7yeuBtJq99nuUcezmUJsv79rwN/H2s6TisFbJINTUbbrVb+/8o Faew== X-Received: by 10.152.205.163 with SMTP id lh3mr6162863lac.10.1392396881252; Fri, 14 Feb 2014 08:54:41 -0800 (PST) MIME-Version: 1.0 Sender: munncha@gmail.com Received: by 10.112.42.170 with HTTP; Fri, 14 Feb 2014 08:54:01 -0800 (PST) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF2B24F@sc9-ex2k10mb1.corp.yaanatech.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> <201402132328.s1DNS0U64926205@shell01.TheWorld.com> <00C069FD01E0324C9FFCADF539701DB3BBF2B24F@sc9-ex2k10mb1.corp.yaanatech.com> From: Kurtis Heimerl Date: Sat, 15 Feb 2014 01:54:01 +0900 X-Google-Sender-Auth: i_puqinc78Th2UA1iBnOBMErdaA Message-ID: To: Michael Hammer Content-Type: multipart/alternative; boundary=001a1137fb1a7e54ad04f260a91f Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/ZYxLkq-T5Z1ksmkPjk5D7VEEC2c Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:54:48 -0000 --001a1137fb1a7e54ad04f260a91f Content-Type: text/plain; charset=ISO-8859-1 One could use GPRS as a control layer for SIP, but a key property here is our ability to support existing phones, which couldn't use such a layer. On Sat, Feb 15, 2014 at 1:08 AM, Michael Hammer < michael.hammer@yaanatech.com> wrote: > OK, let me add some protocol perspective. Cut and paste courtesy of > Wikipedia: > > **** > > The *Um interface* is the air interfacefor the > GSM mobile telephone standard. It is > the interface between the mobile station(MS) and the Base > transceiver station(BTS). It is called Um because it is the mobile analog to the U > interface of ISDN. > Um is defined in the GSM 04.xx and 05.xx series of specifications. Um can > also support GPRS packet-oriented > communication. > > *Um layers[edit > ]* > > The layers of GSM are initially defined in GSM 04.01 Section 7 and roughly > follow the OSI model . Um is > defined in the lower three layers of the model. > Network Layer (L3)[edit > ] > > The Um network layer is > defined in GSM 04.07 and 04.08 and has three sublayers. A subscriber > terminal must establish a connection in each sublayer before accessing the > next higher sublayer. > > 1. Radio Resource(RR). This sublayer manages the assignment and release of logical channels > on the radio link. It is normally terminated in the BSC > . > 2. Mobility Management(MM). This sublayer authenticates users and tracks their movements from > cell to cell. It is normally terminated in the VLRor > HLR > . > 3. Call Control (CC). This > sublayer connects telephone calls and is taken directly from ITU-T > Q.931 . GSM 04.08 Annex E provides > a table of corresponding paragraphs in GSM 04.08 and ITU-T Q.931 along with > a summary of differences between the two. The CC sublayer is terminated in > the MSC . > > The access order is RR, MM, CC. The release order is the reverse of that. > > Note that none of these sublayers terminate in the BTS itself. The > standard GSM BTS operates only in layers 1 and 2. > > *** > > So, the implementation appears to move the MSC to the BTS, along with a > Q.931 to SIP GW, such as: > > ETSI TS 183 036 V3.4.1 (2011-02) Telecommunications and Internet converged > Services and Protocols for Advanced Networking (TISPAN); > > ISDN/SIP interworking; Protocol specification > > > > Not sure how that saves battery, but that is an implementation question we > don't need to answer. > > > > Note also that since Um supports GPRS, could the BTS not also support a > packet relay for higher layer P2P SIP call control? > > > > Just asking. > > > > *Michael Hammer* > > *Principal Engineer* > > *michael.hammer@yaanatech.com * > > *Mobile: *+1 408-202-9291 > > 500 Yosemite Drive Suite 120 > > Milpitas, CA 95035 USA > > > > *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Kurtis > Heimerl > *Sent:* Friday, February 14, 2014 12:27 AM > *To:* Dale R. Worley > > *Cc:* dispatch@ietf.org > *Subject:* Re: [dispatch] SIP and GSM/UMTS with OpenBTS > > > > OpenBTS is an instance of an Um->SIP gateway. After this implementation, > we've become aware that a broader view of the relative correctness of our > design would be valuable... and that's why this thread exists. We'd like > the IETF to help standardize this gateway model and make sure that the > decisions that were made are reasonable, scalable, and intelligent. > > > > At least that's my perception on why we're here. Jim may have another. > > > > On Fri, Feb 14, 2014 at 8:28 AM, Dale R. Worley > wrote: > > > From: "Ralph A. Schmid, dk5ras" > > (Is there a reason you insert so many blank lines?) > > > > So imagine a village, a few hundred people living there, most of > > them owning mobile phones for communication when they travel to the > > town for work or for trading goods - but at home those phones are > > useless. > > > So somebody is able to spent a few thousand dollars, puts an antenna > > onto some tree, flips the switch, and a few hundred phones can (and > > do) log on. > > > Now more and more of those low-cost networks grow up, and people > > want to connect them. Internet is available in some places, cheap to > > buy and install WiFi-links are established, the whole thing evolves, > > some simple structure grows. > > This story makes sense to me. The question seems to be how to > interwork the GSM radio call-control protocol with SIP, so that a set > of these base stations can operate as an integrated system. You'd > want some sort of SIP registrar/proxy to operate as an ITSP, and all > of the base stations make SIP connections with it. > > The next step is for someone to start designing this use of SIP. No > doubt a lot of interesting questions will arise, and you may need to > design some SIP extensions. But until you've got the design started > and can discuss the design decisions, you're not in a position to talk > about what SIP extensions are needed. > > Dale > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > --001a1137fb1a7e54ad04f260a91f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
One could use GPRS as a control layer for SIP, but a key p= roperty here is our ability to support existing phones, which couldn't = use such a layer. 


On Sat, Feb 15, 2014 at 1:08 AM, Michael Hammer <michael.hammer= @yaanatech.com> wrote:

OK, let me add some protocol perspective.&nb= sp; Cut and paste courtesy of Wikipedia:

****=

The Um interface is the= air interface for the GSM mobile telephone= standard. It is the interface between the mobile stati= on (MS) and the Base transc= eiver station (BTS). It is called Um because it is the mobile analog to= the U interface of ISDN. Um is defined in th= e GSM 04.xx and 05.xx series of specifications. Um can also support GPR= S packet-oriented communication.

Um l= ayers[edit]

The layers of GSM are initially de= fined in GSM 04.01 Section 7 and roughly follow the OSI model= . Um is defined in the lower three layers of the model.

Network Layer (L3)[edit]

The Um network layer is defi= ned in GSM 04.07 and 04.08 and has three sublayers. A subscriber terminal m= ust establish a connection in each sublayer before accessing the next highe= r sublayer.

  1. Radio Resource (RR). This subla= yer manages the assignment and release of logical channels on the radio lin= k. It is normally terminated in the BSC.
  2. Mobility Management (MM). This sublayer authenticates users and tracks= their movements from cell to cell. It is normally terminated in the VLR or HLR.
  3. Call Control<= /a> (CC). This sublayer connects telephone calls and is taken directly from= ITU-T Q.931. GSM 04.08 Annex E provides a table of corresponding= paragraphs in GSM 04.08 and ITU-T Q.931 along with a summary of difference= s between the two. The CC sublayer is terminated in the MSC.

The access order is RR, MM, CC. The release order= is the reverse of that.

Note= that none of these sublayers terminate in the BTS itself. The standard GSM= BTS operates only in layers 1 and 2.

***<= /p>

So, the implementation= appears to move the MSC to the BTS, along with a Q.931 to SIP GW, such as:=

ETSI TS 183 036 V3.4.1 (2= 011-02) Telecommunications and Internet converged Services and Protocols fo= r Advanced Networking (TISPAN);

ISDN/SIP interworking; Pr= otocol specification

 

Not sure how that saves b= attery, but that is an implementation question we don’t need to answe= r.

 

Note also that sinc= e Um supports GPRS, could the BTS not also support a packet relay for highe= r layer P2P SIP call control?

 

Just asking.=

&n= bsp;

Michael Hammer

Principal Enginee= r

michael.hammer@yaanatech.com= =

Mobile: +1 408-202-9291

500 Yosemite Drive Suite 120=

Milpitas, CA 95035 USA

 

From: dispatch [mailto:dispatch-bounc= es@ietf.org] On Behalf Of Kurtis Heimerl
Sent: Friday, February 14, 2014 12:27 AM
To: Dale R. Worle= y


Cc: dispatch@ietf.org
Subject: Re: [dispat= ch] SIP and GSM/UMTS with OpenBTS

 

OpenBTS is an instance of an Um->SIP gateway. After this implemen= tation, we've become aware that a broader view of the relative correctn= ess of our design would be valuable...  and that's why this thread= exists. We'd like the IETF to help standardize this gateway model and = make sure that the decisions that were made are reasonable, scalable, and i= ntelligent. 

 

=

At least that's my perception on why = we're here. Jim may have another. 

 

On Fri, Feb 14, 2014 = at 8:28 AM, Dale R. Worley <worley@ariadne.com> wrote:

> From: "Ralph A. Schmid, dk5ras" <<= a href=3D"mailto:ralph@schmid.xxx" target=3D"_blank">ralph@schmid.xxx&g= t;

(Is there a reason you insert so many blank lines?)=


> So imag= ine a village, a few hundred people living there, most of
> them owni= ng mobile phones for communication when they travel to the
> town for= work or for trading goods - but at home those phones are
> useless.

> So somebody is able to spent a few thousand dolla= rs, puts an antenna
> onto some tree, flips the switch, and a few hun= dred phones can (and
> do) log on.

> Now more and more of those low-cost networks= grow up, and people
> want to connect them. Internet is available in= some places, cheap to
> buy and install WiFi-links are established, the whole thing evolves,> some simple structure grows.

This story makes sense to me.  The question seems to be how to<= br> interwork the GSM radio call-control protocol with SIP, so that a set
of= these base stations can operate as an integrated system.  You'dwant some sort of SIP registrar/proxy to operate as an ITSP, and all
o= f the base stations make SIP connections with it.

The next step is for someone to start designing this use of SIP.  = No
doubt a lot of interesting questions will arise, and you may need to<= br>design some SIP extensions.  But until you've got the design st= arted
and can discuss the design decisions, you're not in a position to talk<= br>about what SIP extensions are needed.
<= br>Dale


_______________________________________________
dispatch mailing lis= t
dispatch@ietf.o= rg
https://www.ietf.org/mailman/listinfo/dispatch

 


--001a1137fb1a7e54ad04f260a91f-- From nobody Fri Feb 14 08:56:24 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A5571A02CF for ; Fri, 14 Feb 2014 08:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtWyRWi_egri for ; Fri, 14 Feb 2014 08:56:19 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5BB1A0270 for ; Fri, 14 Feb 2014 08:56:18 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id l4so9453673lbv.19 for ; Fri, 14 Feb 2014 08:56:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=b2nXz6tNJGV1Oe8/JdfcS6pB6OZZYkgEOaaVuklIvbc=; b=FJxpEnaVBXAp3ZuQU2kh3yobDl1LXkECFA1fUl9seflIfBBfiPdXyvtE+zO9Q8JLEr +FFBg+2JyT+WE/Wujo1g95YSiADvGBavJ2QnSoF3z0UZek/+7UDS0xolH8jIqHHokdAM vEP6QLP7pA/88OWkhNEjYDNvtK2u14M780TT0sPaWq4SgzhlEKc7mmCGMFQbOrdTblgf ntdiYYTG0lWgvDcM0tk9jR7ONp1InWI1JyLjkR8mQrbIxmXbEEYR3Syyu8N6kxoM9/kN NRiE3zbQFnB2ElWy81tUAhT9tNcNWW5NZRsUo2hxyr71mTMTHED/6ql7b2A+oYh6m4Hq 7L0w== X-Received: by 10.112.73.100 with SMTP id k4mr5785308lbv.25.1392396976886; Fri, 14 Feb 2014 08:56:16 -0800 (PST) MIME-Version: 1.0 Sender: munncha@gmail.com Received: by 10.112.42.170 with HTTP; Fri, 14 Feb 2014 08:55:36 -0800 (PST) In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112662CD1@ESESSMB301.ericsson.se> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <39B5E4D390E9BD4890E2B3107900610112662679@ESESSMB301.ericsson.se> <0A527A1E-0789-41D8-902B-A1B12F03E69C@westhawk.co.uk> <39B5E4D390E9BD4890E2B3107900610112662CD1@ESESSMB301.ericsson.se> From: Kurtis Heimerl Date: Sat, 15 Feb 2014 01:55:36 +0900 X-Google-Sender-Auth: oKIlGFKzvkXkhq7lHL6Yj1rza2A Message-ID: To: Ivo Sedlacek Content-Type: multipart/alternative; boundary=001a11c2435831979e04f260af96 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/C2NuYZbwu9qgyEKZZTV6WqDF-OI Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:56:21 -0000 --001a11c2435831979e04f260af96 Content-Type: text/plain; charset=ISO-8859-1 As I mentioned earlier, there are operators with licenses. It's relatively easy to get in some countries for small installations and low-power operation is straight-up unlicensed in others. I'm not sure why you're harping on this. On Fri, Feb 14, 2014 at 4:57 PM, Ivo Sedlacek wrote: > Hello Tim and all, > > > Apples and oranges - If I want a continent spanning, roaming capable > billion dollar GSM network, then I need an IMS system. > > If I want an Um to SIP gateway I can run off solar power and hang in a > tree, I'll go for an openBTS like solution. > > If you want an Um to SIP gateway (for whatever purpose), you need a > license. To get a license, you will need to satisfy regulator's > requirements. > > You still have not provided any references to regulators' document stating > that a GSM band is free in any country. > > You still have not explain how such BTS "running off solar power and > hanging in a tree" does not interfere with other BTSs hanging on the next > tree. > > So, I am afraid, the BTS and Um To SIP gateway hanging will be switched > off pretty quickly due to being illegal or causing interferences with other > GSM nodes. > > Kind regards > > Ivo Sedlacek > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --001a11c2435831979e04f260af96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As I mentioned earlier, there are operators with licenses.= It's relatively easy to get in some countries for small installations = and low-power operation is straight-up unlicensed in others. I'm not su= re why you're harping on this.=A0


On Fri, Feb 1= 4, 2014 at 4:57 PM, Ivo Sedlacek <ivo.sedlacek@ericsson.com>= ; wrote:
Hello Tim and all,

> Apples and oranges - If I want a continent spanning, roaming capable b= illion dollar GSM network, then I need an IMS system.
> If I want an Um to SIP gateway I can run off solar power and hang in a= tree, I'll go for an openBTS like solution.

If you want an Um to SIP gateway (for whatever purpose), you need a l= icense. =A0To get a license, you will need to satisfy regulator's requi= rements.

You still have not provided any references to regulators' document stat= ing that a GSM band is free in any country.

You still have not explain how such BTS "running off solar power and h= anging in a tree" does not interfere with other BTSs hanging on the ne= xt tree.

So, I am afraid, the BTS and Um To SIP gateway hanging will be switched off= pretty quickly due to being illegal or causing interferences with other GS= M nodes.

Kind regards

Ivo Sedlacek

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

--001a11c2435831979e04f260af96-- From nobody Fri Feb 14 08:57:31 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C18F1A02CF for ; Fri, 14 Feb 2014 08:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.831 X-Spam-Level: X-Spam-Status: No, score=-1.831 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfHM6jGUmTtZ for ; Fri, 14 Feb 2014 08:57:17 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0211.outbound.protection.outlook.com [207.46.163.211]) by ietfa.amsl.com (Postfix) with ESMTP id 32CA51A0270 for ; Fri, 14 Feb 2014 08:57:17 -0800 (PST) Received: from BL2PR03MB404.namprd03.prod.outlook.com (10.141.91.149) by BL2PR03MB403.namprd03.prod.outlook.com (10.141.91.148) with Microsoft SMTP Server (TLS) id 15.0.873.15; Fri, 14 Feb 2014 16:57:12 +0000 Received: from BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) by BL2PR03MB404.namprd03.prod.outlook.com ([10.141.91.149]) with mapi id 15.00.0873.009; Fri, 14 Feb 2014 16:57:12 +0000 From: Jim Forster To: Michael Hammer Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIIAAT20AgAAEZwCAAAXeAIAAJYiAgAFsZwCAAWBU1IABLnGAgAAqBACAACCygIAADyCAgACIRrqAAGIlAIAAsyWAgAANgAA= Date: Fri, 14 Feb 2014 16:57:12 +0000 Message-ID: References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> <201402132328.s1DNS0U64926205@shell01.TheWorld.com> <00C069FD01E0324C9FFCADF539701DB3BBF2B24F@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF2B24F@sc9-ex2k10mb1.corp.yaanatech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [202.129.185.171] x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10019001)(189002)(199002)(63696002)(85306002)(79102001)(80022001)(80976001)(87936001)(69226001)(65816001)(54316002)(15202345003)(56776001)(74706001)(54356001)(74876001)(77982001)(33656001)(74366001)(66066001)(74502001)(59766001)(83716003)(19580395003)(83322001)(76786001)(36756003)(74662001)(90146001)(76796001)(31966008)(15188155005)(81342001)(85852003)(83072002)(47446002)(92726001)(56816005)(82746002)(15975445006)(92566001)(81816001)(16799955002)(81686001)(47736001)(95666001)(4396001)(49866001)(50986001)(87266001)(46102001)(81542001)(53806001)(76482001)(93136001)(2656002)(94946001)(94316002)(95416001)(51856001)(16236675002)(93516002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB403; H:BL2PR03MB404.namprd03.prod.outlook.com; CLIP:202.129.185.171; FPR:; MLV:sfv; InfoNoRecordsMX:1; A:1; LANG:en; Content-Type: multipart/signed; boundary="Apple-Mail=_E5443062-12DF-433A-89DB-A6877328062A"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 X-OriginatorOrg: rangenetworks.com Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/x_Awecwo-mHUjo_Yrf_Fg8eNosM Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:57:30 -0000 --Apple-Mail=_E5443062-12DF-433A-89DB-A6877328062A Content-Type: multipart/alternative; boundary="Apple-Mail=_9DC4C95F-515C-4D2B-A075-514C65A8C6B8" --Apple-Mail=_9DC4C95F-515C-4D2B-A075-514C65A8C6B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 All -- so much to catch up every evening, after every day this week with = people that want OpenBTS. :-) Michael, > OK, let me add some protocol perspective. Cut and paste courtesy of = Wikipedia: Thanks. > **** > The Um interface is the air interface for the GSM mobile telephone = standard. It is the interface between the mobile station (MS) and = theBase transceiver station (BTS). It is called Um because it is the = mobile analog to the U interface of ISDN. Um is defined in the GSM 04.xx = and 05.xx series of specifications. Um can also support GPRS = packet-oriented communication. > Um layers[edit] > The layers of GSM are initially defined in GSM 04.01 Section 7 and = roughly follow the OSI model. Um is defined in the lower three layers of = the model. > Network Layer (L3)[edit] > The Um network layer is defined in GSM 04.07 and 04.08 and has three = sublayers. A subscriber terminal must establish a connection in each = sublayer before accessing the next higher sublayer. >=20 > Radio Resource (RR). This sublayer manages the assignment and release = of logical channels on the radio link. It is normally terminated in the = BSC. > Mobility Management (MM). This sublayer authenticates users and tracks = their movements from cell to cell. It is normally terminated in the VLR = or HLR. > Call Control (CC). This sublayer connects telephone calls and is taken = directly from ITU-T Q.931. GSM 04.08 Annex E provides a table of = corresponding paragraphs in GSM 04.08 and ITU-T Q.931 along with a = summary of differences between the two. The CC sublayer is terminated in = the MSC. > The access order is RR, MM, CC. The release order is the reverse of = that. >=20 > Note that none of these sublayers terminate in the BTS itself. The = standard GSM BTS operates only in layers 1 and 2. >=20 Right.=20 OpenBTS isn't quite a standard BTS (but that should have been clear = already, no?). In our case, we terminate all of those locally Well, = call control also involves subscriber authorization (which can be local = or not), and a switching component, such as Freeswitch, Asterix, Kazoo, = etc. These functions have clear implementations in the IETF protocols. = And we go the IETF protocols for these as soon as possible in this = system. > *** > So, the implementation appears to move the MSC to the BTS, along with = a Q.931 to SIP GW, such as: > ETSI TS 183 036 V3.4.1 (2011-02) Telecommunications and Internet = converged Services and Protocols for Advanced Networking (TISPAN); > ISDN/SIP interworking; Protocol specification Yes > Not sure how that saves battery, but that is an implementation = question we don=92t need to answer. True, it's not a protocol issue, but the result of a set of similar = things make it interesting to customers, especially in off-grid and = uncovered area use cases. That's why we've done it. We seek to document = this different sort of thing. By ridiculous hyperbole, one could argue = that the Avian Carrier RFC is also suitable for IP transport, so why do = (Ethernet, GPRS..). Efficiency matters. > Note also that since Um supports GPRS, could the BTS not also support = a packet relay for higher layer P2P SIP call control? I guess, but that's hat's not what has been implemented, seems = convoluted, and would break the interesting use case of isolated = operation, as well as likely impacting the local call reliability if the = backhaul is unreliable. It would also likely increase the required = backhaul bandwidth, which is sometimes precious resource. tWe care = about those things.=20 If power usage, backhaul bandwidth and reliability impact on the system = performance are all considered irrelevant and out of scope by 3GPP, then = now I have a better understanding why customers like this solution over = the standard approach for places that don't now have coverage. Lots more emails, and I like discussion, but I think the proponents will = have to avoid spending all available time responding to them, and will = have to spend time making a document that pulls some of the discussion = together. -- Jim --Apple-Mail=_9DC4C95F-515C-4D2B-A075-514C65A8C6B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
All -- so much to catch up every evening, after = every day this week with people that want OpenBTS. = :-)

Michael,

OK, let me add some protocol perspective.  Cut = and paste courtesy of = Wikipedia:

Thanks.

****
The Um = interface is = the air = interface for = the GSM mobile telephone standard. = It is the interface between the mobile = station (MS) and = theBase transceiver station (BTS). It is called Um = because it is the mobile analog to the U = interface of ISDN. Um is defined in the GSM = 04.xx and 05.xx series of specifications. Um can also support GPRS packet-oriented = communication.
Um layers[edit]
The layers of GSM are initially defined in GSM = 04.01 Section 7 and roughly follow the OSI model. Um = is defined in the lower three layers of the = model.

Network Layer = (L3)[edit]

The Um network = layer is defined = in GSM 04.07 and 04.08 and has three sublayers. A subscriber terminal = must establish a connection in each sublayer before accessing the next = higher sublayer.

  1. Radio Resource (RR). This sublayer manages = the assignment and release of logical channels on the radio link. It is = normally terminated in the BSC.
  2. Mobility Management (MM). This sublayer = authenticates users and tracks their movements from cell to cell. It is = normally terminated in the VLR or HLR.
  3. Call = Control (CC). This = sublayer connects telephone calls and is taken directly from ITU-T Q.931. = GSM 04.08 Annex E provides a table of corresponding paragraphs in GSM = 04.08 and ITU-T Q.931 along with a summary of differences between the = two. The CC sublayer is terminated in the MSC.

The access = order is RR, MM, CC. The release order is the reverse of = that.

Note that none of these sublayers terminate in the BTS = itself. The standard GSM BTS operates only in layers 1 and = 2.

Right. 

OpenBTS isn't quite a standard BTS (but that should have been clear = already, no?). In our case, we terminate all of those locally =  Well, call control also involves subscriber authorization (which = can be local or not), and a switching component, such as Freeswitch, = Asterix, Kazoo, etc. These functions have clear implementations in the = IETF protocols. And we go the IETF protocols for these as soon as = possible in this system.

***
So, the implementation = appears to move the MSC to the BTS, along with a Q.931 to SIP GW, such = as:
ETSI TS 183 036 V3.4.1 (2011-02) Telecommunications = and Internet converged Services and Protocols for Advanced Networking = (TISPAN);
ISDN/SIP interworking; Protocol = specification

Yes

Not sure how that saves battery, = but that is an implementation question we don=92t need to = answer.

True, it's = not a protocol issue, but the result of a set of similar things make it = interesting to customers, especially in off-grid and uncovered area use = cases. That's why we've done it.  We seek to document this = different sort of thing.  By ridiculous hyperbole, one could argue = that the Avian Carrier RFC is also suitable for IP transport, so why do = (Ethernet, GPRS..).  Efficiency = matters.

 Note also that since = Um supports GPRS, could the BTS not also support a packet relay for = higher layer P2P SIP call = control?

I guess, = but that's hat's not what has been implemented, seems convoluted, and = would break the interesting use case of isolated operation, as well as = likely impacting the local call reliability if the backhaul is = unreliable.  It would also likely increase the required backhaul = bandwidth, which is sometimes precious resource.  tWe care about = those things. 

If power usage, backhaul = bandwidth and reliability impact on the system performance are all = considered irrelevant and out of scope by 3GPP, then now I have a better = understanding why customers like this solution over the standard = approach for places that don't now have = coverage.

Lots more emails, and I like = discussion, but I think the proponents will have to avoid spending all = available time responding to them, and will have to spend time making a = document that pulls some of the discussion = together.

  -- = Jim


= --Apple-Mail=_9DC4C95F-515C-4D2B-A075-514C65A8C6B8-- --Apple-Mail=_E5443062-12DF-433A-89DB-A6877328062A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJS/krWAAoJECAtT58A/2SKiCYIAIofegg3Sy49v/2YlgyIHo1g LtDysYz8QMxaqYMWUkrFHVIqrbcLcRQ2kiCK0/XCJ4mjH9O7+8qqC4w7y5D1Di6A +yB/GaGzpuidam5UmREBOkxniwG2yRyGJ2iyU2AJ0TDwHYY5lBoRncT1g9u9FfWg 5UBDn5z2AWAxB982zYcEiqLofeIlgG2tzVI6FWqzjFZq3CklC0ZR3MOLo8MhAHOF nXvstcpVfrhlAU1ejyaPl/6N3mkUTGvBuovg5QxI6c+50gWolhkEQa2TPpqWBEXf WkzI4zEXJvWYMwpnU/8e6+1nAZ0Nd5MLKgMQNoaXiiNPY1gxlwsKGN6RzR+G6u8= =tY10 -----END PGP SIGNATURE----- --Apple-Mail=_E5443062-12DF-433A-89DB-A6877328062A-- From nobody Fri Feb 14 08:59:48 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380081A0300 for ; Fri, 14 Feb 2014 08:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-TnAV_-NGbr for ; Fri, 14 Feb 2014 08:59:36 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4FB1A012E for ; Fri, 14 Feb 2014 08:59:35 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta13.westchester.pa.mail.comcast.net with comcast id SDGc1n0040Fqzac5DGzZ2n; Fri, 14 Feb 2014 16:59:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id SGzZ1n00Y3ZTu2S3UGzZHe; Fri, 14 Feb 2014 16:59:33 +0000 Message-ID: <52FE4B75.5040408@alum.mit.edu> Date: Fri, 14 Feb 2014 11:59:33 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD112B.5040209@alum.mit.edu> <52FD2AE0.7060600@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392397173; bh=hwoM3naw/5v87yuOYwhw0DQpKNVHJlWtYYUG74grDos=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gK4Kzv2qtsVs1CsV60lGO/xOTEow0WXVDnsieL1qJIwy8bi3p/mVk1M453MzQSlBP Ga3VZ/v+61TNA+Jnu8uufpkPTQk85aLVEUrBb7pgRLY8PUAVUD6NSna6KWlMRtBkBh 0SQ91OKfDv4traOWRFKXgB7B+bvFy0EqgvCaQLVmdrITcSUdxqHLtlJpc6jzc/aAUF zw/Qzcfhm11tvwQ0X9J1PClqL5ywz7UmzS4ybP1YxliyascNI1iW1CbEv9m4buTcVD QFewruIi1LyBV85fua7cIJeR5n5cDGTZVc2pTXeQlo/oHhPRzL30ql6GpiEPd4iX0o 6l4rZV7sZJ0RQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/qmtvRODu-AG4ltgGp3WoAItBq6s Subject: Re: [dispatch] X over websockets X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 16:59:47 -0000 On 2/13/14 5:02 PM, Mary Barnes wrote: > This topic has previously been raised (a year ago and periodically since > then): > http://www.ietf.org/mail-archive/web/dispatch/current/msg04693.html > > The suggestion was to have a "foo" over websocket discussion on the RAI > list (which is really a lonely and largely ignored mailing list) but no > one has taken that up: > http://www.ietf.org/mail-archive/web/dispatch/current/msg04749.html > > Also, no one has put forth a concrete proposal to deal with it and we > don't do work unless someones willing to put in the cycles. > > Thus, these work items have been trickling in (and out). Since they are > deemed useful in some contexts (and not harmful), they've been moving > forward. But, it certainly would be good for someone to put in some > cycles to define a model and some guidelines for using websockets for > any number of RAI protocols. Mary, I don't know how to distinguish what belongs on the RAI list vs. the dispatch list. But I have a perception that the dispatch list has a greater following. Thanks, Paul > Mary. > > > On Thu, Feb 13, 2014 at 2:28 PM, Sergio Garcia Murillo > > wrote: > > El 13/02/2014 19:38, Paul Kyzivat escribió: > > On 2/13/14 11:07 AM, Sergio Garcia Murillo wrote: > > What I mean is that I expect quite a lot of "over > websocekts" drafts and > we should try to use the same solution for advertising it in > the SDP, > and not have each one have their own way of handling it. > > > Sigh. Yes, once we had the first of these, it was only a matter > of time before the flood began. > > What concerns me is that for every "X over websockets" there is > probably also a good argument for "X over WebRTC Data Channel". > > Are we going to let that happen? > > Or for each X are we going to have a beauty contest between > websockets and data channel? > > Or what? > > > Completely agree, we should try to "close" that discussion once and > for all and not have the same arguments and discussions in each > draft. I am not really aware of the IETF process, but could be > possible to create a draft to address it? > > Best regards > Sergio > > > _________________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/__listinfo/dispatch > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Fri Feb 14 09:27:28 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673821A02A3 for ; Fri, 14 Feb 2014 09:27:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ij5v2wClMsDm for ; Fri, 14 Feb 2014 09:27:24 -0800 (PST) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D7F0B1A017F for ; Fri, 14 Feb 2014 09:27:23 -0800 (PST) Received: by mail-yh0-f44.google.com with SMTP id f73so12014761yha.31 for ; Fri, 14 Feb 2014 09:27:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4wu8fBi+LATw4xZ5sZXZtI1Zj9g794Wf794PSSWigLQ=; b=H3RBoTGQA+fL91HmHjJd1N5zvbFhSjFp9eSSR4o4ye2YWSM3Vq3LiBYm/DfY1OnGVC 6CUX/mi6vxeibeaKNmKXkvsoqWjQqBMPtlIWApViQp/tApbA8TLdJrMVFAmrzG6bThI/ /bokM8dOvv5WPZb1UTWC02T4GtqTuR3o3+WEu+DWL3O0HPmfpK7XzJ737peXV9054hfw 7vcPdLZYQhqLZji8lc9eoctYNx7Gu8lCGBDoSoiEAW3fQL5wZ7pZwYPQrVnEp3aQdbNu Q6rCLRYIMRUXJlMwVOYt9AKCGO/ejTFpnj1FVmkRSi3IxRkSMlT6EUMo6LeEWMW7ZbSs y1iw== MIME-Version: 1.0 X-Received: by 10.236.4.67 with SMTP id 43mr8608971yhi.9.1392398842264; Fri, 14 Feb 2014 09:27:22 -0800 (PST) Received: by 10.170.150.2 with HTTP; Fri, 14 Feb 2014 09:27:22 -0800 (PST) In-Reply-To: <52FE4B75.5040408@alum.mit.edu> References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD112B.5040209@alum.mit.edu> <52FD2AE0.7060600@gmail.com> <52FE4B75.5040408@alum.mit.edu> Date: Fri, 14 Feb 2014 11:27:22 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11348dbe61022804f2611e4d Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/o3GSU6NgVIHlRtQe0a2oQ2E-J6E Cc: DISPATCH Subject: Re: [dispatch] X over websockets X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 17:27:26 -0000 --001a11348dbe61022804f2611e4d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Feb 14, 2014 at 10:59 AM, Paul Kyzivat wrote= : > On 2/13/14 5:02 PM, Mary Barnes wrote: > >> This topic has previously been raised (a year ago and periodically since >> then): >> http://www.ietf.org/mail-archive/web/dispatch/current/msg04693.html >> >> The suggestion was to have a "foo" over websocket discussion on the RAI >> list (which is really a lonely and largely ignored mailing list) but no >> one has taken that up: >> http://www.ietf.org/mail-archive/web/dispatch/current/msg04749.html >> >> Also, no one has put forth a concrete proposal to deal with it and we >> don't do work unless someones willing to put in the cycles. >> >> Thus, these work items have been trickling in (and out). Since they are >> deemed useful in some contexts (and not harmful), they've been moving >> forward. But, it certainly would be good for someone to put in some >> cycles to define a model and some guidelines for using websockets for >> any number of RAI protocols. >> > > Mary, > > I don't know how to distinguish what belongs on the RAI list vs. the > dispatch list. But I have a perception that the dispatch list has a great= er > following. > [MB] It was the ADs that suggested the topic was to be discussed on the RAI list. But, you are absolutely correct, there are about 200 more people on the DISPATCH list. However, as I regularly state there are some periodic discussions on the RAI list that are also of interest so folks really should consider subscribing to that one: https://www.ietf.org/mailman/listinfo/rai For example, Gonzalo started a RAI process discussion a while back: http://www.ietf.org/mail-archive/web/rai/current/msg01372.html And, Richard posted an important reminder note about deadlines for IETF-89: http://www.ietf.org/mail-archive/web/rai/current/msg01430.html BTW, it's a Friday (today!) for the first time that I can recall in case anyone was thinking it was another Monday deadline as usual. I think in one sense, we've ended up with DISPATCH serving as a RAI Area WG since we don't have the latter. This "new" process has now been in place for 5 years, so maybe it is time to reconsider how the area is organized. But, of course that discussion should happen on the RAI list and involve the ADs ;) [/MB] > > Thanks, > Paul > > Mary. >> >> >> On Thu, Feb 13, 2014 at 2:28 PM, Sergio Garcia Murillo >> > > wrote: >> >> El 13/02/2014 19:38, Paul Kyzivat escribi=F3: >> >> On 2/13/14 11:07 AM, Sergio Garcia Murillo wrote: >> >> What I mean is that I expect quite a lot of "over >> websocekts" drafts and >> we should try to use the same solution for advertising it in >> the SDP, >> and not have each one have their own way of handling it. >> >> >> Sigh. Yes, once we had the first of these, it was only a matter >> of time before the flood began. >> >> What concerns me is that for every "X over websockets" there is >> probably also a good argument for "X over WebRTC Data Channel". >> >> Are we going to let that happen? >> >> Or for each X are we going to have a beauty contest between >> websockets and data channel? >> >> Or what? >> >> >> Completely agree, we should try to "close" that discussion once and >> for all and not have the same arguments and discussions in each >> draft. I am not really aware of the IETF process, but could be >> possible to create a draft to address it? >> >> Best regards >> Sergio >> >> >> _________________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/__listinfo/dispatch >> >> >> >> >> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --001a11348dbe61022804f2611e4d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Feb 14, 2014 at 10:59 AM, Paul Kyzivat &l= t;pkyzivat@alum.= mit.edu> wrote:
On 2/13/14 5:02 PM, Mary Bar= nes wrote:
This topic has previously been raised (a year ago and periodically since then):
http://www.ietf.org/mail-archive/web/dispatch= /current/msg04693.html

The suggestion was to have a "foo" over websocket discussion on t= he RAI
list (which is really a lonely and largely ignored mailing list) but no
one has taken that up:
http://www.ietf.org/mail-archive/web/dispatch= /current/msg04749.html

Also, no one has put forth a concrete proposal to deal with it and we
don't do work unless someones willing to put in the cycles.

Thus, these work items have been trickling in (and out). =A0Since they are<= br> deemed useful in some contexts (and not harmful), they've been moving forward. =A0But, it certainly would be good for someone to put in some
cycles to define a model and some guidelines for using websockets for
any number of RAI protocols.

Mary,

I don't know how to distinguish what belongs on the RAI list vs. the di= spatch list. But I have a perception that the dispatch list has a greater f= ollowing.
[MB] It was the ADs that suggested the topic= was to be discussed on the RAI list. But, you are absolutely correct, ther= e are about 200 more people on the DISPATCH list. However, as I regularly s= tate there are some periodic discussions on the RAI list that are also of i= nterest so folks really should consider subscribing to that one:
For example, Gonzalo started a RAI = process discussion a while back:
And, Richard posted an important reminder note about deadlines for IET= F-89:

BTW, it's a Friday (today!) for the first time that= I can recall in case anyone was thinking it was another Monday deadline as= usual.

I think in one sense, we've ended = up with DISPATCH serving as a RAI Area WG since we don't have the latte= r. =A0This "new" process has now been in place for 5 years, so ma= ybe it is time to reconsider how the area is organized. =A0But, of course t= hat discussion should happen on the RAI list and involve the ADs ;) =A0
=A0
[/MB]

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul

Mary.


On Thu, Feb 13, 2014 at 2:28 PM, Sergio Garcia Murillo
<se= rgio.garcia.murillo@gmail.com
<mailto:sergio.garcia.murillo@gmail.com>> wrote:

=A0 =A0 El 13/02/2014 19:38, Paul Kyzivat escribi=F3:

=A0 =A0 =A0 =A0 On 2/13/14 11:07 AM, Sergio Garcia Murillo wrote:

=A0 =A0 =A0 =A0 =A0 =A0 What I mean is that I expect quite a lot of "o= ver
=A0 =A0 =A0 =A0 =A0 =A0 websocekts" drafts and
=A0 =A0 =A0 =A0 =A0 =A0 we should try to use the same solution for advertis= ing it in
=A0 =A0 =A0 =A0 =A0 =A0 the SDP,
=A0 =A0 =A0 =A0 =A0 =A0 and not have each one have their own way of handlin= g it.


=A0 =A0 =A0 =A0 Sigh. Yes, once we had the first of these, it was only a ma= tter
=A0 =A0 =A0 =A0 of time before the flood began.

=A0 =A0 =A0 =A0 What concerns me is that for every "X over websockets&= quot; there is
=A0 =A0 =A0 =A0 probably also a good argument for "X over WebRTC Data = Channel".

=A0 =A0 =A0 =A0 Are we going to let that happen?

=A0 =A0 =A0 =A0 Or for each X are we going to have a beauty contest between=
=A0 =A0 =A0 =A0 websockets and data channel?

=A0 =A0 =A0 =A0 Or what?


=A0 =A0 Completely agree, we should try to "close" that discussio= n once and
=A0 =A0 for all and not have the same arguments and discussions in each
=A0 =A0 draft. I am not really aware of the IETF process, but could be
=A0 =A0 possible to create a draft to address it?

=A0 =A0 Best regards
=A0 =A0 Sergio


=A0 =A0 _________________________________________________
=A0 =A0 dispatch mailing list
=A0 =A0 dispatch@iet= f.org <mailto:dispatch@ietf.org>
=A0 =A0 https://www.ietf.org/mailman/__listinfo/dispatch
=A0 =A0 <https://www.ietf.org/mailman/listinfo/dispatch>=





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


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

--001a11348dbe61022804f2611e4d-- From nobody Fri Feb 14 10:17:22 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BB61A0338 for ; Fri, 14 Feb 2014 10:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVh80oVCW6a8 for ; Fri, 14 Feb 2014 10:17:13 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3451A0345 for ; Fri, 14 Feb 2014 10:17:13 -0800 (PST) Received: by mail-yk0-f177.google.com with SMTP id q200so24022510ykb.8 for ; Fri, 14 Feb 2014 10:17:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MdE3tlx6+9bhLSnJGkTOBOjFBIwVlGuUs7jYO/nWStA=; b=iQVZFecRe/h9VgnwhidZnqfHikEw24VhY7Va2dl4P9RyU4r2JZQH4m2nGxJl4mtDXU 60WqxBbMrINN2y7f1YTAIJKaMZV7++pBcz6A7YC+Sryvg8AF1nzW0EO78FmXJIlTgW7E +73M4qLoNAaGH750tjxaaA8iCQ19MkCHlOgmEMJNFTmZ3ZWiE7S6fGAkDcKNYAi1JXX0 J20GSbQnbod4D3zKF7LXKjrZHrItUpJvv0ScMCudLNqNvpCYxVr8KoHK6ruH79QA0vDP Hn7GGl5ScVxpj2TpPonJ6gtePsEvNoJ1nBdpg4/NpAwsw7MemlKfwlbZEwIq+RRxuxzQ fwfA== MIME-Version: 1.0 X-Received: by 10.236.191.67 with SMTP id f43mr3872750yhn.60.1392401831890; Fri, 14 Feb 2014 10:17:11 -0800 (PST) Received: by 10.170.150.2 with HTTP; Fri, 14 Feb 2014 10:17:11 -0800 (PST) In-Reply-To: <00C069FD01E0324C9FFCADF539701DB3BBF2B047@sc9-ex2k10mb1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBF2A4FF@sc9-ex2k10mb1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBF2B047@sc9-ex2k10mb1.corp.yaanatech.com> Date: Fri, 14 Feb 2014 12:17:11 -0600 Message-ID: From: Mary Barnes To: Michael Hammer Content-Type: multipart/alternative; boundary=20cf3040e42e93158804f261d0a4 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/qUpWjrfFPOdhZu6u9GiZLKAfOVA Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:17:18 -0000 --20cf3040e42e93158804f261d0a4 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 14, 2014 at 9:30 AM, Michael Hammer < michael.hammer@yaanatech.com> wrote: > Mary, > > > > The Base Transceiver Station (BTS) is not an LTE component, it is more > legacy base station technology. > > The eNodeB is what LTE uses, which is what IMS would be transported by. > > The radio access network just provides an IP path from the handset IMS > client to the IMS core elements. > > There is no interworking at SIP layer for anything in the access network. > [MB] Right. But, it's my understanding that interworking at the SIP layer in the access network is what OpenBTS is about and it's based on a GSM model. I don't have my 6000 pages of GSM specs at hand (I left those on a shelf in my cubicle when I left Nortel) and my book is two decades old, but it was my understanding that the radio layer call control messages are the same ones that are encapsulated into DTAP messages to be sent over the A interface in GSM and they're used for Call Control in the MSC and it would be those that are mapped to SIP (in the BTS) - i.e., these messages: What I would find useful to know is how any of these multi-access IMS systems (that also seem to support GSM access) are doing any mapping? Even if it's done in the IMS core, I would think the model would be similar to the mapping one would do in the BTS in the case of GSM access in an OpenBTS model. [/MB] > > > So, 2 cases: > > Case 1: the radio access network does not have connectivity to the core > network: > > solution may be to have a P2P SIP application that kicks in for local > connectivity. > > This can be developed from current standard SIP protocol. > > No new SIP attributes have been proposed. > [MB] That may be a possibility. That approach would need more detail to see if it's feasible for the deployments being considered. But, if this requires anything new in the cellphone then I don't think it meets the basic requirement of allowing people to use their existing cellphones to make calls. [/MB] > > > Case 2: the radio access network does have connectivity to the core > network: > > The IMS client should be able to connect to the core IMS components and > operate as normal in the LTE/IMS/VoLTE network. > > Again, no new SIP attributes have been proposed. > [MB] My understanding is that OpenBTS is more focused on GSM than IMS. Remember, not everyone in the world is running an IMS network. So, I think in this case, OpenBTS wouldn't be necessary. [/MB] So, I ask again for the third time, what IETF protocol or extension thereto > is being proposed? > > > > All the radio discussion as far as I can tell is just marketing, looking > for approval from IETF for deploying non-compliant 3GPP base stations. > [MB] IETF doesn't approve how anyone deploys any equipment. The concern is understood. But, I think Jiri Kuthan stated this very well in terms of it not at all being unusual for IETF to work on protocols that might have the appearance of displacing existing protocols (and product deployments): http://www.ietf.org/mail-archive/web/dispatch/current/msg05336.html Again, we are dealing with equipment that is already being deployed and appears to serve a useful function in providing connectivity in remote areas that would otherwise not have a way for people to use their cellphones. I believe IETF should take the same stance we did when 3GPP was deciding to use SIP and posit that any changes to IETF protocols must happen in IETF. I do not believe that OpenBTS is requiring any changes to 3GPP protocols. We don't yet know the details of changes to IETF protocols. My understanding at this time is that at a minimum a documented way to interwork the radio layer call control protocol with SIP is needed. Folks are already doing something in this space. I totally agree that the details of what folks are doing now can help inform any decisions on what might be needed in IETF documents. [/MB] I think that may be dangerous and damaging of relationship between IETF and > 3GPP. > [MB] I don't disagree that this could be a difficult situation and could very likely require some liaisons between the two organizations. But, we've been there before in the early 2000s when 3GPP was working on R5 to define the use of SIP in an IMS core network. 3GPP required some new SIP extensions and there was a need to for education on both sides in terms of why 3GPP needed these specific headers which weren't deemed generally applicable to SIP on the open Internet. [/MB] > > > I admit maybe I have missed something, but someone needs to spell out more > clearly what they want to standardize. > [MB] That probably goes both ways in terms of understanding the concerns on both sides. The reason for these discussions is to help us tease out what clearly needs to be standardized. I totally agree that we are not there yet. [/MB] > If need be draw a picture. > [MB] I totally agree a picture would really help. [/MB] > > > *Michael Hammer* > > *Principal Engineer* > > *michael.hammer@yaanatech.com * > > *Mobile: *+1 408-202-9291 > > 500 Yosemite Drive Suite 120 > > Milpitas, CA 95035 USA > > > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* Thursday, February 13, 2014 4:47 PM > *To:* Michael Hammer > *Cc:* DRAGE, Keith (Keith); dispatch@ietf.org > > *Subject:* Re: [dispatch] SIP and GSM/UMTS with OpenBTS > > > > I have stated specifics before as to the context for this and IETF: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg05252.html > > > > One of the things they are explicitly talking about the Radio layer Call > control protocol interworking with SIP. Now, if folks are saying that this > interworking between these call control messages and SIP would be the same > in the BTS as it would be in the MSC, then a pointer to the exact IMS spec > that provides all these details would be most helpful. My guess is that > this problem doesn't require the complete functionality defined by CT1. > It's certainly possible that there is a subset of those specifications > which could help meet their needs and I assume they would have dug through > those already). But, explicit pointers to those rather than a blanket > statement that IMS solves this specific problem would be really helpful. > > > > I totally agree that the proponents have a lot more detail to provide so > that folks can understand the interworking and functionality that they are > wanting that is relevant to IETF and SIP. > > > > Mary > > On Thu, Feb 13, 2014 at 2:49 PM, Michael Hammer < > michael.hammer@yaanatech.com> wrote: > > Mary. Interworking sip with radio protocols is like saying inter working sip with ip. Makes no sense. So far I have not seen any case for work in IETF. This is more analogous to ITU- T attempt to screw up MPLS as far as I can tell. > > > > I asked the question before and still do not see a connection to any IETF work. Cut out the business case and nothing has been proposed. > > > > > > > > Sent with Good (www.good.com) > > ------ Original Message ------ > *From: *Mary Barnes > *Sent: *Thursday, February 13, 2014 at 3:19 PM > *To: *DRAGE, Keith (Keith) > *Cc: *dispatch@ietf.org > *Subject: *[dispatch] SIP and GSM/UMTS with OpenBTS > > > > > > On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote: > > Ericsson is not the only vendor that sees a market for small cells, but > the expectation is that the products are built to the completed 3GPP > standards will be deployed in licensed spectrum by owners of that spectrum, > although the boxes may well be owned by 3rd parties. > > > > These deployments already exist. > > > > I see Jim has now identified that this proposal is for licensed GSM > operators in licensed GSM space. > > > > Personally, I would suggest if you believe the operators should be picking > this up, you take it to 3GPP where the operators are actually present. That > is the only way you will see it taken up by GSMA, which you will need to > obtain interoperator agreements to use this (e.g. roaming, shared > networks). 3GPP them works with IETF on any SIP extensions needed. > > [MB] One big problem with this proposal is that you must be a member of > 3GPP/GSMA to make contributions and to participate in meetings. > > > > And, I think having to first do the work in 3GPP and then bring it to IETF > would introduce a tremendous delay for something that's already been > implemented/deployed. While they are proposing to reuse elements and > protocols that are part of an IMS network, the core issue they have is with > interworking SIP with the radio layer protocols. Certainly, one could > implement all the protocols that IMS uses and then use the 3GPP based specs > and proprietary headers to interwork with SIP in the Internet, but that > would be terribly inefficient. > > [/MB] > > > > I would only see IETF having any direct part in this if the proposal was > only to use unlicensed spectrum by enterprises rather than licensed > operators, which Jim has negated. > > > > regards > > > > Keith > > > ------------------------------ > > *From:* Tim Panton new [mailto:thp@westhawk.co.uk] > > *Sent:* 13 February 2014 14:50 > *To:* DRAGE, Keith (Keith) > *Cc:* Harvind Samra; Ivo Sedlacek; dispatch@ietf.org > > > *Subject:* Re: [dispatch] SIP and GSM/UMTS with OpenBTS > > > > > > On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) < > keith.drage@alcatel-lucent.com> wrote: > > > > Jumping in here, they are relevant in as much as there is no point in IETF > working on this if there is no known market for it. > > > > Usually those type of projects are published only on April 1st. > > > > So all Ivo is asking is for you to justify that it is worth other people > working on this as well as yourselves. > > > > Perhaps if you identified the spectrum you believe is available for use in > the the countries identified, that would be useful. > > > > regards > > > > Keith Drage > > > > Ivo's employer seems to see a market for small cells, but looks to tie > them to existing operator IMS's through > > internet connections "owned by themselves or a partner". > > > http://www.telecomlead.com/enterprise-networking/mwc-2014-ericsson-announce-small-cell-service-20233/ > > Perhaps that's an April fools joke too (I can't see any avian carriers > mentioned though)? > > > > It isn't up to the IETF to crown specific solutions. That's the market's > job. > > > > T. > > > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > --20cf3040e42e93158804f261d0a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 14, 2014 at 9:30 AM= , Michael Hammer <michael.hammer@yaanatech.com> w= rote:

Mary,

=A0<= /p>

The Base Transceiver S= tation (BTS) is not an LTE component, it is more legacy base station techno= logy.

The eNodeB is what LTE us= es, which is what IMS would be transported by.

The radio access network just provides an IP pat= h from the handset IMS client to the IMS core elements.

There is no interworking = at SIP layer for anything in the access network.

[MB] Right. But, it's my understanding that interworking at the SI= P layer in the access network is what OpenBTS is about and it's based o= n a GSM model. I don't have my 6000 pages of GSM specs at hand (I left = those on a shelf in my cubicle when I left Nortel) and my book is two decad= es old, but it was my understanding that the radio layer call control messa= ges are the same ones that are encapsulated into DTAP messages to be sent o= ver the A interface in GSM and they're used for Call Control in the MSC= and it would be those that are mapped to SIP (in the BTS) - i.e., these me= ssages:

What I would find useful to know is how any of these mu= lti-access IMS systems (that also seem to support GSM access) are doing any= mapping? Even if it's done in the IMS core, I would think the model wo= uld be similar to the mapping one would do in the BTS in the case of GSM ac= cess in an OpenBTS model. [/MB]

=A0<= /p>

So, 2 cases:=A0

Case 1:=A0 the radio acce= ss network does not have connectivity to the core network:=A0

solution may be to have a= P2P SIP application that kicks in for local connectivity.

This can be developed fro= m current standard SIP protocol.=A0

No new SIP attributes have been proposed.=

[MB] That may be a possibility. That appr= oach would need more detail to see if it's feasible for the deployments= being considered. But, if this requires anything new in the cellphone then= I don't think it meets the basic requirement of allowing people to use= their existing cellphones to make calls. [/MB]=A0

=A0<= /p>

Case 2:=A0 the radio a= ccess network does have connectivity to the core network:

The IMS client should be = able to connect to the core IMS components and operate as normal in the LTE= /IMS/VoLTE network.

Again, no new SIP attribu= tes have been proposed.

[MB] My und= erstanding is that OpenBTS is more focused on GSM than IMS. Remember, not e= veryone in the world is running an IMS network. =A0So, I think in this case= , OpenBTS wouldn't be necessary. =A0[/MB]=A0

So, I ask again for the third time, what IET= F protocol or extension thereto is being proposed?

=A0<= /p>

All the radio discussi= on as far as I can tell is just marketing, looking for approval from IETF f= or deploying non-compliant 3GPP base stations.

[MB] IETF doesn't approve how anyone depl= oys any equipment. =A0The concern is understood. =A0But, I think Jiri Kutha= n stated this very well in terms of it not at all being unusual for IETF to= work on protocols that might have the appearance of displacing existing pr= otocols (and product deployments): =A0http://www.ietf.org/mail-archive= /web/dispatch/current/msg05336.html

Again, we are dealing with equipment that is already be= ing deployed and appears to serve a useful function in providing connectivi= ty in remote areas that would otherwise not have a way for people to use th= eir cellphones.=A0

I believe IETF should take the same stance we did when = 3GPP was deciding to use SIP and posit that any changes to IETF protocols m= ust happen in IETF. =A0I do not believe that OpenBTS is requiring any chang= es to 3GPP protocols. =A0 =A0We don't yet know the details of changes t= o IETF protocols. =A0My understanding at this time is that at a minimum a d= ocumented way to interwork the radio layer call control protocol=A0with SIP= is needed. Folks are already doing something in this space. =A0I totally a= gree that the details of what folks are doing now can help inform any decis= ions on what might be needed in IETF documents. =A0=A0
[/MB]

I think that may be dange= rous and damaging of relationship between IETF and 3GPP.

[MB] I don't disagree that this could be a difficult = situation and could very likely require =A0some liaisons between the two or= ganizations. But, we've been there before in the early 2000s when 3GPP = was working on R5 to define the use of SIP in an IMS core network. =A03GPP = required some new SIP extensions and there was a need to for education on b= oth sides in terms of why 3GPP needed these specific headers which weren= 9;t deemed generally applicable to SIP on the open Internet. =A0[/MB]=A0

=A0<= /p>

I admit maybe I have m= issed something, but someone needs to spell out more clearly what they want= to standardize.

[MB] That probably goes both ways in terms of= understanding the concerns on both sides. =A0 The reason for these discuss= ions is to help us tease out what clearly needs to be standardized. =A0I to= tally agree that we are not there yet. [/MB]=A0

If need be draw a picture= .

[MB] I totally agree a picture wo= uld really help. [/MB]=A0

=A0<= /p>

= Michael Hammer=

Principal Enginee= r

michael.hammer@yaanatech.com= =

Mobile: +1 408-202-9291

500 Yosemite Drive Suite 120=

Milpitas, CA 95035 USA

=A0

From: Mary Barnes [mailto:mary.ietf.barnes@g= mail.com]
Sent: Thursday, February 13, 2014 4:47 PM
To: Michael Hamm= er
Cc: DRAGE, Keith (Keith); dispatch@ietf.org

<= br> Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS<= /div>

=A0<= u>

I have stated specifics before a= s to the context for this and IETF:=A0

http://www.ietf.or= g/mail-archive/web/dispatch/current/msg05252.html

=A0

One of the things they are explicitly talking about the Radio layer= Call control protocol interworking with SIP. =A0Now, if folks are saying t= hat this interworking between these call control messages and SIP would be = the same in the BTS as it would be in the MSC, then a pointer to the exact = IMS spec that provides all these details would be most helpful. =A0My guess= is that this problem doesn't require the complete functionality define= d by CT1. =A0It's certainly possible that there is a subset of those sp= ecifications which could help meet their needs and I assume they would have= dug through those already). But, explicit pointers to those rather than a = blanket statement that IMS solves this specific problem would be really hel= pful. =A0

=A0

=A0I totally agree that the proponents have a lot more detai= l to provide so that folks can understand the interworking and functionalit= y that they are wanting that is relevant to IETF and SIP.=A0<= /p>

=A0

Mary

On Thu, Feb 13, 2014 at 2:49 PM, Michael Hammer <michael.ham= mer@yaanatech.com> wrote:

Mary. Interworking sip with radio protocols is like saying inter worki=
ng sip with ip. Makes no sense.=A0 So far I have not seen any case for work=
 in IETF.=A0 This is more analogous to ITU- T attempt to screw up MPLS as f=
ar as I can tell. 
=A0
I asked the question before and still do n=
ot see a connection to any IETF work.=A0 Cut out the business case and noth=
ing has been proposed. 
=A0
=A0 
=A0
Sent with Good (www.good.com)

------ Original Message ------
= From: Mary Barnes
Sent: Thursday, February 13, 2014 at 3:19 PM
To: DRAGE, Ke= ith (Keith)
Cc: dispatch@ietf.org
Subject: [dispatch] SIP and GSM/UMTS = with OpenBTS

=A0

=A0

On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith) <keith.drage@alcat= el-lucent.com> wrote:

Ericsson is not the only vendor that sees = a market for small cells, but the expectation is that the products are buil= t to the completed 3GPP standards will be deployed in licensed spectrum by = owners of that spectrum, although the boxes may well be owned by 3rd partie= s.

=A0

The= se deployments already exist.

=A0

I see Jim has now identified that this proposal= is for licensed GSM operators in licensed GSM space.<= /p>

=A0

Per= sonally, I would suggest if you believe the operators should be picking thi= s up, you take it to 3GPP where the operators are actually present. That is= the only way you will see it taken up by GSMA, which you will need to obta= in interoperator agreements to use this (e.g. roaming, shared networks). 3G= PP them works with IETF on any SIP extensions needed.<= /p>

[MB] One big problem with this proposal i= s that you must be a member of 3GPP/GSMA to make contributions and to parti= cipate in meetings. =A0 =A0

=A0

And, I think having = to first do the work in 3GPP and then bring it to IETF would introduce a tr= emendous delay for something that's already been implemented/deployed. = =A0While they are proposing to reuse elements and protocols that are part o= f an IMS network, the core issue they have is with interworking SIP with th= e radio layer protocols. =A0Certainly, one could implement all the protocol= s that IMS uses and then use the 3GPP based specs and proprietary headers t= o interwork with SIP in the Internet, but that would be terribly inefficien= t.=A0

[/MB]=A0

=A0<= u>

I would only see IETF having any direct part in= this if the proposal was only to use unlicensed spectrum by enterprises ra= ther than licensed operators, which Jim has negated.

=A0

reg= ards

=A0

Keith

=A0

From: Tim Panton new [mai= lto:thp@westhawk.co= .uk]

Sent: 13 February 2014 14:50
To:= DRAGE, Keith (Keith)
Cc: Harvind Samra; Ivo Sedlacek; dispatch@ietf.org


Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS<= /span>

=A0

=A0

On = 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com= > wrote:



Jumping in here, they are relevant in as much as there is no p= oint in IETF working on this if there is no known market for it.<= /u>

=A0

Usu= ally those type of projects are published only on April 1st.<= u>

=A0

So = all Ivo is asking is for you to justify that it is worth other people worki= ng on this as well as yourselves.

=A0

Per= haps if you identified the spectrum you believe is available for use in the= the countries identified, that would be useful.

=A0

reg= ards

=A0

Keith Drage

=A0

Ivo's employer seems = to see a market for small cells, but looks to tie them to existing operator= IMS's through=A0

internet connections "owned by thems= elves or a partner".

Perhaps that's an April fools joke to= o (I can't see any avian carriers mentioned though)?

<= /div>

=A0

It isn't up to the IETF to crown specific solutions. That's the mar= ket's job.

= =A0

T.

<= div>

=A0

=A0

=A0=


_______________________________________________
dispatch mailing lis= t
dispatch@ietf.o= rg
https://www.ietf.org/mailman/listinfo/dispatch

=A0

=

=A0

<= /div>

--20cf3040e42e93158804f261d0a4-- From nobody Fri Feb 14 10:43:35 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0337C1A0318 for ; Fri, 14 Feb 2014 10:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXxC2Xwm-G0r for ; Fri, 14 Feb 2014 10:43:24 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9761A0354 for ; Fri, 14 Feb 2014 10:43:09 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 10:43:15 -0800 From: Michael Hammer To: "mary.ietf.barnes@gmail.com" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAC9HICAAALFAIAAAFCA//96B5CAAI2tgIAALnMAgAZ4WICAAOAQAIAACMEAgAAEaACAAAXeAIAAJYeAgAFsZwCAANo2FIABtI+AgAAqBQCAACCxgIAABEMAgAAK7oCAAFDzgP//goyfgACWJ4CAAKAtAIAAt5uA//+ARwA= Date: Fri, 14 Feb 2014 18:43:07 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF2CCA2@sc9-ex2k10mb1.corp.yaanatech.com> References: <00C069FD01E0324C9FFCADF539701DB3BBF2A4FF@sc9-ex2k10mb1.corp.yaanatech.com> <00C069FD01E0324C9FFCADF539701DB3BBF2B047@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.96] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00FD_01CF298A.B098BFE0" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/LfVrc0jAD1hiEFooELizHsdZNo8 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:43:32 -0000 ------=_NextPart_000_00FD_01CF298A.B098BFE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00FE_01CF298A.B098BFE0" ------=_NextPart_001_00FE_01CF298A.B098BFE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mary, I helped clarify for myself with my subsequent Um email. However, the response to that did not say what interworking is needed beyond what the existing ETSI Q.931-SIP spec already covers. So, my current sense is that the protocol and interworking aspects are already done. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Friday, February 14, 2014 1:17 PM To: Michael Hammer Cc: keith.drage@alcatel-lucent.com; dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS On Fri, Feb 14, 2014 at 9:30 AM, Michael Hammer wrote: Mary, The Base Transceiver Station (BTS) is not an LTE component, it is more legacy base station technology. The eNodeB is what LTE uses, which is what IMS would be transported by. The radio access network just provides an IP path from the handset IMS client to the IMS core elements. There is no interworking at SIP layer for anything in the access network. [MB] Right. But, it's my understanding that interworking at the SIP layer in the access network is what OpenBTS is about and it's based on a GSM model. I don't have my 6000 pages of GSM specs at hand (I left those on a shelf in my cubicle when I left Nortel) and my book is two decades old, but it was my understanding that the radio layer call control messages are the same ones that are encapsulated into DTAP messages to be sent over the A interface in GSM and they're used for Call Control in the MSC and it would be those that are mapped to SIP (in the BTS) - i.e., these messages: What I would find useful to know is how any of these multi-access IMS systems (that also seem to support GSM access) are doing any mapping? Even if it's done in the IMS core, I would think the model would be similar to the mapping one would do in the BTS in the case of GSM access in an OpenBTS model. [/MB] So, 2 cases: Case 1: the radio access network does not have connectivity to the core network: solution may be to have a P2P SIP application that kicks in for local connectivity. This can be developed from current standard SIP protocol. No new SIP attributes have been proposed. [MB] That may be a possibility. That approach would need more detail to see if it's feasible for the deployments being considered. But, if this requires anything new in the cellphone then I don't think it meets the basic requirement of allowing people to use their existing cellphones to make calls. [/MB] Case 2: the radio access network does have connectivity to the core network: The IMS client should be able to connect to the core IMS components and operate as normal in the LTE/IMS/VoLTE network. Again, no new SIP attributes have been proposed. [MB] My understanding is that OpenBTS is more focused on GSM than IMS. Remember, not everyone in the world is running an IMS network. So, I think in this case, OpenBTS wouldn't be necessary. [/MB] So, I ask again for the third time, what IETF protocol or extension thereto is being proposed? All the radio discussion as far as I can tell is just marketing, looking for approval from IETF for deploying non-compliant 3GPP base stations. [MB] IETF doesn't approve how anyone deploys any equipment. The concern is understood. But, I think Jiri Kuthan stated this very well in terms of it not at all being unusual for IETF to work on protocols that might have the appearance of displacing existing protocols (and product deployments): http://www.ietf.org/mail-archive/web/dispatch/current/msg05336.html Again, we are dealing with equipment that is already being deployed and appears to serve a useful function in providing connectivity in remote areas that would otherwise not have a way for people to use their cellphones. I believe IETF should take the same stance we did when 3GPP was deciding to use SIP and posit that any changes to IETF protocols must happen in IETF. I do not believe that OpenBTS is requiring any changes to 3GPP protocols. We don't yet know the details of changes to IETF protocols. My understanding at this time is that at a minimum a documented way to interwork the radio layer call control protocol with SIP is needed. Folks are already doing something in this space. I totally agree that the details of what folks are doing now can help inform any decisions on what might be needed in IETF documents. [/MB] I think that may be dangerous and damaging of relationship between IETF and 3GPP. [MB] I don't disagree that this could be a difficult situation and could very likely require some liaisons between the two organizations. But, we've been there before in the early 2000s when 3GPP was working on R5 to define the use of SIP in an IMS core network. 3GPP required some new SIP extensions and there was a need to for education on both sides in terms of why 3GPP needed these specific headers which weren't deemed generally applicable to SIP on the open Internet. [/MB] I admit maybe I have missed something, but someone needs to spell out more clearly what they want to standardize. [MB] That probably goes both ways in terms of understanding the concerns on both sides. The reason for these discussions is to help us tease out what clearly needs to be standardized. I totally agree that we are not there yet. [/MB] If need be draw a picture. [MB] I totally agree a picture would really help. [/MB] Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: Thursday, February 13, 2014 4:47 PM To: Michael Hammer Cc: DRAGE, Keith (Keith); dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS I have stated specifics before as to the context for this and IETF: http://www.ietf.org/mail-archive/web/dispatch/current/msg05252.html One of the things they are explicitly talking about the Radio layer Call control protocol interworking with SIP. Now, if folks are saying that this interworking between these call control messages and SIP would be the same in the BTS as it would be in the MSC, then a pointer to the exact IMS spec that provides all these details would be most helpful. My guess is that this problem doesn't require the complete functionality defined by CT1. It's certainly possible that there is a subset of those specifications which could help meet their needs and I assume they would have dug through those already). But, explicit pointers to those rather than a blanket statement that IMS solves this specific problem would be really helpful. I totally agree that the proponents have a lot more detail to provide so that folks can understand the interworking and functionality that they are wanting that is relevant to IETF and SIP. Mary On Thu, Feb 13, 2014 at 2:49 PM, Michael Hammer wrote: Mary. Interworking sip with radio protocols is like saying inter working sip with ip. Makes no sense. So far I have not seen any case for work in IETF. This is more analogous to ITU- T attempt to screw up MPLS as far as I can tell. I asked the question before and still do not see a connection to any IETF work. Cut out the business case and nothing has been proposed. Sent with Good (www.good.com) ------ Original Message ------ From: Mary Barnes Sent: Thursday, February 13, 2014 at 3:19 PM To: DRAGE, Keith (Keith) Cc: dispatch@ietf.org Subject: [dispatch] SIP and GSM/UMTS with OpenBTS On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith) wrote: Ericsson is not the only vendor that sees a market for small cells, but the expectation is that the products are built to the completed 3GPP standards will be deployed in licensed spectrum by owners of that spectrum, although the boxes may well be owned by 3rd parties. These deployments already exist. I see Jim has now identified that this proposal is for licensed GSM operators in licensed GSM space. Personally, I would suggest if you believe the operators should be picking this up, you take it to 3GPP where the operators are actually present. That is the only way you will see it taken up by GSMA, which you will need to obtain interoperator agreements to use this (e.g. roaming, shared networks). 3GPP them works with IETF on any SIP extensions needed. [MB] One big problem with this proposal is that you must be a member of 3GPP/GSMA to make contributions and to participate in meetings. And, I think having to first do the work in 3GPP and then bring it to IETF would introduce a tremendous delay for something that's already been implemented/deployed. While they are proposing to reuse elements and protocols that are part of an IMS network, the core issue they have is with interworking SIP with the radio layer protocols. Certainly, one could implement all the protocols that IMS uses and then use the 3GPP based specs and proprietary headers to interwork with SIP in the Internet, but that would be terribly inefficient. [/MB] I would only see IETF having any direct part in this if the proposal was only to use unlicensed spectrum by enterprises rather than licensed operators, which Jim has negated. regards Keith _____ From: Tim Panton new [mailto:thp@westhawk.co.uk] Sent: 13 February 2014 14:50 To: DRAGE, Keith (Keith) Cc: Harvind Samra; Ivo Sedlacek; dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) wrote: Jumping in here, they are relevant in as much as there is no point in IETF working on this if there is no known market for it. Usually those type of projects are published only on April 1st. So all Ivo is asking is for you to justify that it is worth other people working on this as well as yourselves. Perhaps if you identified the spectrum you believe is available for use in the the countries identified, that would be useful. regards Keith Drage Ivo's employer seems to see a market for small cells, but looks to tie them to existing operator IMS's through internet connections "owned by themselves or a partner". http://www.telecomlead.com/enterprise-networking/mwc-2014-ericsson-announce- small-cell-service-20233/ Perhaps that's an April fools joke too (I can't see any avian carriers mentioned though)? It isn't up to the IETF to crown specific solutions. That's the market's job. T. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_001_00FE_01CF298A.B098BFE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mary,

 

I helped clarify for myself with my subsequent Um = email.

 

However, the response to that did not say what interworking is needed = beyond what the existing ETSI Q.931-SIP spec already = covers.

 

So, my current sense is that the protocol and interworking aspects = are already done.

 

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com

Mobile: +1 408-202-9291

500 Yosemite Drive Suite = 120

Milpitas, CA 95035 = USA

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: Friday, = February 14, 2014 1:17 PM
To: Michael Hammer
Cc: = keith.drage@alcatel-lucent.com; dispatch@ietf.org
Subject: Re: = [dispatch] SIP and GSM/UMTS with OpenBTS

 

On = Fri, Feb 14, 2014 at 9:30 AM, Michael Hammer <michael.hammer@yaanatech.com> = wrote:

Mary,

 

The Base Transceiver Station (BTS) is not an LTE component, it is = more legacy base station technology.

The eNodeB is what LTE uses, which is what IMS would be transported = by.

The radio access network just provides an IP path from the handset = IMS client to the IMS core elements.

There is no interworking at SIP layer for anything in the access = network.

[MB] Right. But, it's my understanding that = interworking at the SIP layer in the access network is what OpenBTS is = about and it's based on a GSM model. I don't have my 6000 pages of GSM = specs at hand (I left those on a shelf in my cubicle when I left Nortel) = and my book is two decades old, but it was my understanding that the = radio layer call control messages are the same ones that are = encapsulated into DTAP messages to be sent over the A interface in GSM = and they're used for Call Control in the MSC and it would be those that = are mapped to SIP (in the BTS) - i.e., these = messages:

 

What I would find useful to know is how any of these = multi-access IMS systems (that also seem to support GSM access) are = doing any mapping? Even if it's done in the IMS core, I would think the = model would be similar to the mapping one would do in the BTS in the = case of GSM access in an OpenBTS model. = [/MB]

 

So, 2 cases: 

Case 1:  the radio access network does not have connectivity to = the core network: 

solution may be to have a P2P SIP application that kicks in for local = connectivity.

This can be developed from current standard SIP protocol.  =

No new SIP attributes have been = proposed.

[MB] That may be a possibility. That approach would = need more detail to see if it's feasible for the deployments being = considered. But, if this requires anything new in the cellphone then I = don't think it meets the basic requirement of allowing people to use = their existing cellphones to make calls. = [/MB] 

 

Case 2:  the radio access network does have connectivity to the = core network:

The IMS client should be able to connect to the core IMS components = and operate as normal in the LTE/IMS/VoLTE = network.

Again, no new SIP attributes have been = proposed.

[MB] My understanding is that OpenBTS is more focused = on GSM than IMS. Remember, not everyone in the world is running an IMS = network.  So, I think in this case, OpenBTS wouldn't be necessary. =  [/MB] 

 

So, I ask again for the third time, what IETF protocol or extension = thereto is being proposed?

 

All the radio discussion as far as I can tell is just marketing, = looking for approval from IETF for deploying non-compliant 3GPP base = stations.

[MB] IETF doesn't approve how anyone deploys any = equipment.  The concern is understood.  But, I think Jiri = Kuthan stated this very well in terms of it not at all being unusual for = IETF to work on protocols that might have the appearance of displacing = existing protocols (and product deployments):  http://www.ietf.org/mail-archive/web/dispatch/current/msg05336.html

 

Michael = Hammer

Principal = Engineer

michael.hammer@yaanatech.com<= /p>

Mobile: +1 = 408-202-9291

500 = Yosemite Drive Suite 120

Milpitas, CA 95035 USA

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: = Thursday, February 13, 2014 4:47 PM
To: Michael = Hammer
Cc: DRAGE, Keith (Keith); dispatch@ietf.org


Subject: Re: [dispatch] SIP and GSM/UMTS = with OpenBTS

 <= /o:p>

I have = stated specifics before as to the context for this and = IETF: 

 <= /o:p>

One of the = things they are explicitly talking about the Radio layer Call control = protocol interworking with SIP.  Now, if folks are saying that this = interworking between these call control messages and SIP would be the = same in the BTS as it would be in the MSC, then a pointer to the exact = IMS spec that provides all these details would be most helpful.  My = guess is that this problem doesn't require the complete functionality = defined by CT1.  It's certainly possible that there is a subset of = those specifications which could help meet their needs and I assume they = would have dug through those already). But, explicit pointers to those = rather than a blanket statement that IMS solves this specific problem = would be really helpful.  

 <= /o:p>

 I = totally agree that the proponents have a lot more detail to provide so = that folks can understand the interworking and functionality that they = are wanting that is relevant to IETF and = SIP. 

 <= /o:p>

Mary

On Thu, Feb = 13, 2014 at 2:49 PM, Michael Hammer <michael.hammer@yaanatech.com> = wrote:

Mary. Interworking sip with radio protocols is =
like saying inter working sip with ip. Makes no sense.  So far I =
have not seen any case for work in IETF.  This is more analogous to =
ITU- T attempt to screw up MPLS as far as I can tell. =

 
I asked the question =
before and still do not see a connection to any IETF work.  Cut out =
the business case and nothing has been proposed. =

 
 
= 
 
Sent with Good (www.good.com)

------ Original = Message ------
From: Mary Barnes
Sent: Thursday, = February 13, 2014 at 3:19 PM
To: DRAGE, Keith = (Keith)
Cc: dispatch@ietf.org
Subject: [dispatch] = SIP and GSM/UMTS with OpenBTS

 <= /o:p>

 <= /p>

On Thu, Feb = 13, 2014 at 9:28 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> = wrote:

Ericsson is not = the only vendor that sees a market for small cells, but the expectation = is that the products are built to the completed 3GPP standards will be = deployed in licensed spectrum by owners of that spectrum, although the = boxes may well be owned by 3rd parties.

 <= /o:p>

These deployments = already exist.

 <= /o:p>

I see Jim has now = identified that this proposal is for licensed GSM operators in licensed = GSM space.

 <= /o:p>

Personally, I = would suggest if you believe the operators should be picking this up, = you take it to 3GPP where the operators are actually present. That is = the only way you will see it taken up by GSMA, which you will need to = obtain interoperator agreements to use this (e.g. roaming, shared = networks). 3GPP them works with IETF on any SIP extensions = needed.

[MB] One = big problem with this proposal is that you must be a member of 3GPP/GSMA = to make contributions and to participate in meetings.   =  

 <= /o:p>

And, I = think having to first do the work in 3GPP and then bring it to IETF = would introduce a tremendous delay for something that's already been = implemented/deployed.  While they are proposing to reuse elements = and protocols that are part of an IMS network, the core issue they have = is with interworking SIP with the radio layer protocols. =  Certainly, one could implement all the protocols that IMS uses and = then use the 3GPP based specs and proprietary headers to interwork with = SIP in the Internet, but that would be terribly = inefficient. 

[/MB] <= o:p>

 <= /o:p>

I would only see = IETF having any direct part in this if the proposal was only to use = unlicensed spectrum by enterprises rather than licensed operators, which = Jim has negated.

 <= /o:p>

regards=

 <= /o:p>

Keith

 <= /o:p>

From: Tim Panton new [mailto:thp@westhawk.co.uk]

Sent: 13 February 2014 = 14:50
To: DRAGE, Keith (Keith)
Cc: Harvind Samra; = Ivo Sedlacek; dispatch@ietf.org


Subject: Re: = [dispatch] SIP and GSM/UMTS with OpenBTS

 <= /o:p>

 <= /o:p>

On 13 Feb = 2014, at 14:34, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> = wrote:

 <= /p>

Jumping in here, = they are relevant in as much as there is no point in IETF working on = this if there is no known market for it.

 <= /o:p>

Usually those type = of projects are published only on April 1st.

 <= /o:p>

So all Ivo is = asking is for you to justify that it is worth other people working on = this as well as yourselves.

 <= /o:p>

Perhaps if you = identified the spectrum you believe is available for use in the the = countries identified, that would be useful.

 <= /o:p>

regards=

 <= /o:p>

Keith = Drage

 <= /o:p>

Ivo's = employer seems to see a market for small cells, but looks to tie them to = existing operator IMS's through 

internet = connections "owned by themselves or a = partner".

Perhaps = that's an April fools joke too (I can't see any avian carriers mentioned = though)?

 <= /o:p>

It isn't up = to the IETF to crown specific solutions. That's the market's = job.

 <= /o:p>

T.

 <= /o:p>

 <= /o:p>

 <= /o:p>


______________= _________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch=

 <= /o:p>

 <= /o:p>

 

------=_NextPart_001_00FE_01CF298A.B098BFE0-- ------=_NextPart_000_00FD_01CF298A.B098BFE0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIx NDE4NDMwNlowIwYJKoZIhvcNAQkEMRYEFLifiu+ms+WydIioIQcabYYVD8WNMIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAYF3ncttEOMHppkB6BZmoicWa/hxyHGb8HTmouMFX A+vFHznwruOy39vIztXCJXApBCvM9gnhNXq7cKGGw9ZRh8Vyh6V/LAPCvVH46HFGFUdFAt7N4H0L FUya4NdL1TFxfaL2LN6Th2G2tgBvNOv7zw9mw6RKxlJhocnteY2GTNo2C008F1WZ6B+TZD3MMdUB hlgJfkQCrz/QljLY2Sz0/PWfMk9wYazRruyFnL/oVtHYzVIn7gMBnzqvCPuzocsRy5325ACkVp3r OQFg1KTd8/jm908homoE87nWYDyi6zwhwlYLwvRsxvTro3235cvAbjdQKM5IFrMtI69vUYcNuwAA AAAAAA== ------=_NextPart_000_00FD_01CF298A.B098BFE0-- From nobody Fri Feb 14 10:53:17 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7241A02D0 for ; Fri, 14 Feb 2014 10:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4O1A64U_nXh for ; Fri, 14 Feb 2014 10:53:13 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id ACB561A0368 for ; Fri, 14 Feb 2014 10:53:11 -0800 (PST) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta14.westchester.pa.mail.comcast.net with comcast id SDAt1n00316LCl05EJt9mr; Fri, 14 Feb 2014 18:53:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id SJt91n00V3ZTu2S3SJt9Fy; Fri, 14 Feb 2014 18:53:09 +0000 Message-ID: <52FE6615.5010100@alum.mit.edu> Date: Fri, 14 Feb 2014 13:53:09 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> <201402132328.s1DNS0U64926205@shell01.TheWorld.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1392403989; bh=+lOQovcvt04/aCYp75QLH3ndBAllkQgNrEi463sCr+k=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=C3w8577lJKI8Mn5rAJ73Mng395SIn/4Le2eS+nNTTxDdtzzQLvu7+jbZwEJxBg8ur MeMHhMm7ummdfENTS7Kaw+JlhPVzoizQ/vUXk+iVJEtYQN88hM08Tbr9HdM6aF6sqX 5ntgXuprEx55L1mvgIOOAZMFnFQmpd8C1AfsfGbXwSju+hHKuoCfiltDUHiEFEWW/x OQ/eLA7zpZYJfaPPJZzn3yMykoNgs8IZaNP4XVRLzdoYEkLDtH9guzdafd6fpZA1J8 8DKTxFwSWCS4fmLh7r3cDshPFgzBOqCXumNgn98pqLO187S+Dcs2zytnwmXTYT3aSg d7O97LG6kXmUw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/nV7DcoVBMQYYLChb52bR4KYoPko Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 18:53:15 -0000 On 2/14/14 12:27 AM, Kurtis Heimerl wrote: > OpenBTS is an instance of an Um->SIP gateway. After this implementation, > we've become aware that a broader view of the relative correctness of > our design would be valuable... and that's why this thread exists. We'd > like the IETF to help standardize this gateway model and make sure that > the decisions that were made are reasonable, scalable, and intelligent. I have a *little*, old, knowledge of IMS at the sip layer, and almost no understanding of the remainder of 3gpp. I'm trying to make sense of this discussion. IIUC, you have (or plan) a box that talk to 3gpp-compatible UEs over the radio link. This box is sufficient so that the phones connected to it can talk to one another. And your goal is to put a SIP interface on the box so that: 1) several of your boxes can interconnect and establish calls between themselves using SIP over the internet 2) so that these boxes can call other E.164 numbers using SIP over the internet. Do I have the right idea? Are both (1) and (2) goals? Thanks, Paul > At least that's my perception on why we're here. Jim may have another. > > > On Fri, Feb 14, 2014 at 8:28 AM, Dale R. Worley > wrote: > > > From: "Ralph A. Schmid, dk5ras" > > (Is there a reason you insert so many blank lines?) > > > So imagine a village, a few hundred people living there, most of > > them owning mobile phones for communication when they travel to the > > town for work or for trading goods - but at home those phones are > > useless. > > > So somebody is able to spent a few thousand dollars, puts an antenna > > onto some tree, flips the switch, and a few hundred phones can (and > > do) log on. > > > Now more and more of those low-cost networks grow up, and people > > want to connect them. Internet is available in some places, cheap to > > buy and install WiFi-links are established, the whole thing evolves, > > some simple structure grows. > > This story makes sense to me. The question seems to be how to > interwork the GSM radio call-control protocol with SIP, so that a set > of these base stations can operate as an integrated system. You'd > want some sort of SIP registrar/proxy to operate as an ITSP, and all > of the base stations make SIP connections with it. > > The next step is for someone to start designing this use of SIP. No > doubt a lot of interesting questions will arise, and you may need to > design some SIP extensions. But until you've got the design started > and can discuss the design decisions, you're not in a position to talk > about what SIP extensions are needed. > > Dale > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Fri Feb 14 13:54:45 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538FA1A03ED for ; Fri, 14 Feb 2014 13:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytwrQeBq2KOv for ; Fri, 14 Feb 2014 13:54:35 -0800 (PST) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id A68971A036D for ; Fri, 14 Feb 2014 13:54:34 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id m5so5771410qaj.18 for ; Fri, 14 Feb 2014 13:54:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=bkkZHbn/kQhnAZbipklHoIZfcfKQtiy/Ttde/I0Kt7c=; b=Pde6cnotZlV4eBtd/bO2es7yvvWRFpNYt0xmFgbU1OvynsAce5Dfbo6EpjSbyzJlQA OvSCovZHUNfyzMshT2nDjXCe1dSkjxWoCY2XrrmIKKB25CCh1zkLXMzIgBHgR3vBo4eu aWIvOALyjnxEl/uTJtNgAacsUmgz6ncBfIpGKGjBKrWy79MHPrFPDHb+WqVhAmVxvJEj 05+fs8Au7J0lJ1vmrXsFXvV6VnAPLQ4iUtMRAKq2VT/k/EjQu+C+dixrQVgNCWQ6WZYo +D4Q5DVmbRZ5hblxCH3UMjn4FOfoVA6W2T+/gqKaliJ/xotx4WnVt0aLw7s9e8eKjkoi NqdA== X-Gm-Message-State: ALoCoQnuQsBzMWBTWWB6dg4tWWD9WM2p8dagx84CMxuIHB8e6ZWJ8QcfJ0ruu3VgEu/3nIDLXZzp MIME-Version: 1.0 X-Received: by 10.140.83.112 with SMTP id i103mr16547080qgd.100.1392414872912; Fri, 14 Feb 2014 13:54:32 -0800 (PST) Received: by 10.140.101.35 with HTTP; Fri, 14 Feb 2014 13:54:32 -0800 (PST) Date: Fri, 14 Feb 2014 16:54:32 -0500 Message-ID: From: Richard Barnes To: draft-drage-sipping-rfc3455bis@tools.ietf.org, DISPATCH Content-Type: multipart/alternative; boundary=001a11c12c60e15e8204f264d95e Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/S4uj89c6af2N1b-mo2dGdyYZssw Subject: [dispatch] AD review: draft-drage-sipping-rfc3455bis X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 21:54:37 -0000 --001a11c12c60e15e8204f264d95e Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this document in preparation for IETF LC. While I have some reservations about some of the architectural decisions made (e.g., the use of P-Access-Network-Info vs. something from GEOPRIV), the document seems clearly written and interoperable. I have requested IETF LC. Thanks, --Richard --001a11c12c60e15e8204f264d95e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this document in preparation for IETF LC. = =A0While I have some reservations about some of the architectural decisions= made (e.g., the use of P-Access-Network-Info vs. something from GEOPRIV), = the document seems clearly written and interoperable. =A0I have requested I= ETF LC.

Thanks,
--Richard
--001a11c12c60e15e8204f264d95e-- From nobody Fri Feb 14 14:13:15 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FB41A01D1 for ; Fri, 14 Feb 2014 14:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4krlLuDxWSPh for ; Fri, 14 Feb 2014 14:13:07 -0800 (PST) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id BE79D1A00FA for ; Fri, 14 Feb 2014 14:13:06 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id o15so19003409qap.16 for ; Fri, 14 Feb 2014 14:13:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=R7UJ3Hj6S07ar6U643+w0kbVwDjbafjl/UxA7b7Wq90=; b=GZfGBt7MEcLa8AkeDxDJnglSOIjXr+mfXUKB7L0UGpwx1tcwzFtkeOKfOQYTMJWZKE zHIW0Cy8vIBjnfn9MDybxRPKo3XVTyMmXxYfuKnYomFoCIng0hoqK6mgyhH2aGk/SVrF 5uvJjbotXyUn2h24Z421bILdGpC9ihSCNlkTLBaYGNQdl7tOC9NftTelkDGHJv8P8rme +lEHYhzXCayjJ9yg6wWU0TFNxflVUAcrtA5sTvXZRtR/EqPmIfoLVP8GmstQMkiD+J/x 2u0ynx10MhiAHrUU4mTY4agKK68Kwa/Xcrajb6ezWsR9bT9vFr5dTEZoqaEHWJMS+eEZ q56A== X-Gm-Message-State: ALoCoQmvkM2uaXSD1edO1BxUMgbSwJfUG2n9ZJ9VZBa4FwITPjG+wD4AtgNusUH7/Y5o4rl1AfPS MIME-Version: 1.0 X-Received: by 10.140.83.112 with SMTP id i103mr16660849qgd.100.1392415985009; Fri, 14 Feb 2014 14:13:05 -0800 (PST) Received: by 10.140.101.35 with HTTP; Fri, 14 Feb 2014 14:13:04 -0800 (PST) Date: Fri, 14 Feb 2014 17:13:04 -0500 Message-ID: From: Richard Barnes To: draft-vanelburg-dispatch-private-network-ind@tools.ietf.org, DISPATCH Content-Type: multipart/alternative; boundary=001a11c12c602a910c04f2651c65 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/eEvIr-NS04Z2tfOhEP8LUt1b1ag Subject: [dispatch] AD review: draft-vanelburg-dispatch-private-network-ind X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 22:13:11 -0000 --001a11c12c602a910c04f2651c65 Content-Type: text/plain; charset=ISO-8859-1 I have reviewed this draft in preparation for IETF LC. Two comment to be addressed along with other LC comments: 1. In Section 3.6, there is the following sentence: """ The Spec(T) need not specify the same contents and trust domain boundaries that are used for other header fields like for example the P-Asserted-Identity. """ That reads to me as if the requirements for defining a Spec(T) for this document are different than those in RFC 3324. Would the following clarification be more accurate? """ The same information is required to specify a Spec(T) for purposes of P-Private-Network-Indication as for P-Asserted-Identity [RFC3324]. However, if a network is using P-Private-Network-Indication as well as other private headers (such as P-Asserted-Identity), the Spec(T) for each header may be different from the others. """ 2. Please reformat the IANA Considerations to more clearly specify what IANA should put in the registry. The IANA Considerations section of draft-drage-sipping-rfc3455bis does this well: http://tools.ietf.org/html/draft-drage-sipping-rfc3455bis-13#section-7 I have requested IETF LC. Thanks, --Richard --001a11c12c602a910c04f2651c65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have reviewed this draft in preparation for IETF LC. =A0= Two comment to be addressed along with other LC comments:

1. In Section 3.6, there is the following sentence:
""= ;"
The Spec(T) need not specify the same contents and trust domain b= oundaries that are used for other header fields like for example the P-Asse= rted-Identity.
"""
That reads to m= e as if the requirements for defining a Spec(T) for this document are diffe= rent than those in RFC 3324. =A0Would the following clarification be more a= ccurate?
"""
The same information is required to speci= fy a Spec(T) for purposes of P-Private-Network-Indication as for P-Asserted= -Identity [RFC3324]. =A0However, if a network is using P-Private-Network-In= dication as well as other private headers (such as P-Asserted-Identity), th= e Spec(T) for each header may be different from the others.
"""

2. Please reformat the IAN= A Considerations to more clearly specify what IANA should put in the regist= ry. =A0The IANA Considerations section of draft-drage-sipping-rfc3455bis do= es this well:

I have requested IETF LC.

Thanks,
--Richard
--001a11c12c602a910c04f2651c65-- From nobody Fri Feb 14 14:14:35 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273791A00FA for ; Fri, 14 Feb 2014 14:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPH3nl8GH7_i for ; Fri, 14 Feb 2014 14:14:31 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0C41A005C for ; Fri, 14 Feb 2014 14:14:31 -0800 (PST) Received: by mail-ob0-f175.google.com with SMTP id wn1so14561223obc.34 for ; Fri, 14 Feb 2014 14:14:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=QIaBhUSnl3zpTjktso8oxdcAMP2aw2prhA72Oi63W84=; b=LBAXnPr6KjuaXn2WuaRqfHDPUGaRGzMYibeILZjXESXxImqZTxpFd3t5r7CagtgkSS W67hVdewJ6SIKsj1c0Z6ISTZq/yu/y0TreXA/0sGGFWFqUKT27tGVTCgATzvSWD1PoUQ EBDDKM5s0bhBaG9abq1ZQsyW5aGIHWgHHOzlKnf1qjHbBGv6P4URg5GpITgHVcnnN08W YwyJVMbbuU0o7K4rgtYXk1wnyI0SJnvNKPDFCvCZ7bqfl5prn0ZySVph1ZAGxq+ZtYMj I6MHpibWd2bTbAjDQ5AKM821q/NyoPL7RqLxwD9CpmKWWOCaqoko0XuVJDlCjebBWTKb 1b1g== X-Received: by 10.182.33.102 with SMTP id q6mr8677990obi.8.1392416069449; Fri, 14 Feb 2014 14:14:29 -0800 (PST) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.55.106 with HTTP; Fri, 14 Feb 2014 14:14:09 -0800 (PST) In-Reply-To: <201402122055.s1CKtFC64823393@shell01.TheWorld.com> References: <201402122055.s1CKtFC64823393@shell01.TheWorld.com> From: Charles Shen Date: Fri, 14 Feb 2014 17:14:09 -0500 X-Google-Sender-Auth: seBXGAH4Zkv6gFeb7uLcpxTfJRc Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=047d7b5d90b532fde504f2652169 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/xKFBQlxfbYswXiWxFu7LLmCLEeE Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-shen-soc-avalanche-restart-overload X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 22:14:34 -0000 --047d7b5d90b532fde504f2652169 Content-Type: text/plain; charset=UTF-8 Dear Dale, Thank you very much for your review and great comments. I agree with all of the points you raised and will incorporate them into the next revision. Thanks again. Charles On Wed, Feb 12, 2014 at 3:55 PM, Dale R. Worley wrote: > > From: Charles Shen > > > I am looking for your kind opinion on what should be the appropriate next > > step for this document: > > > > -- Should this draft be dispatched to SOC (and their charter amended)? > > -- Should this draft be processed as AD-sponsored? > > -- Should this draft be killed (if it is harmful)? > > I do believe that this draft should be advanced, as this sort of > registration storm causes a problem in practice, though I don't have > any opinion on what would be the proper track for it. > > It would be interesting to know if there have been any large-scale > implementations, and what the results have been in practice. > > In regard to the draft itself, I think a few tweaks would improve it. > > - Clarify that the Restart-Timer value is associated with the URI that > is being registered (for REGISTER) or the URI/event that is being > subscribed to (for SUBSCRIBE and PUBLISH). > > - You may want a more clever way of handling multiple Restart-Timer > values received from different servers during a boot sequence that > sends requests to several servers (which may be incompletely > coordinated with each other). E.g., if the registration server has > a Restart-Timer of 300 and the voicemail server also has a > Restart-Timer of 300, it seems that the UA could safely wait > rand(0:300) then register and subscribe. If the VM server has a zero > restart timer, the UA probably wants to wait until the registration > is done anyway before subscribing to VM. But if the VM server has a > Restart-Timer of 600, there probably should be an additional delay > between registration and subscribing. > > The trouble is that rand(0:300)+rand(0:300) doesn't have the same > distribution as rand(0:600), so you may not want to say "Wait a random > fraction of the difference between the two Restart-Timers." > > Perhaps a workable algorithm is "Choose a random real number > uniformaly between zero and one. Each bootup operation may be > executed no earlier than (the random number) * (the specified > Restart-Timer for that operation) seconds after power-up." That > causes each server to see the time-distribution of requests that it > expects. > > - The text suggests that the Restart-Timer value expires when the > registration expires. ("The validity duration of the Restart-Timer > header is the same as that of the corresponding registration > operation.") That doesn't work at all, because the power failure > may exceed the length of all the registrations. The Restart-Timer > value has to be saved until another value is received for that same > target. > > - You may want to allow/require the UA to place an upper limit on the > Restart-Timer value. At the least, Restart-Timer should not exceed > the maximum registration/subscription duration the UA requests and > the server provides. > > - I expect that you want to require that if a REGISTER response is > received that does not contain Restart-Timer, then the saved > Restart-Timer value is set to zero. That causes the expected > behavior when a registrar that supports Restart-Timer is replaced > with one that does not. > > Dale > --047d7b5d90b532fde504f2652169 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Dale,

Thank you very much for your= review and great comments. I agree with all of the points you raised and w= ill incorporate them into the next revision.=C2=A0

Thanks again.

Charles

On Wed, Feb 12, 2014 at 3:55 PM, Dale R. Worley <wor= ley@ariadne.com> wrote:
> From: Charles Shen <charles@cs.columbia.edu>

> I am looking for your kind opinion on what should be the appropriate n= ext
> step for this document:
>
> -- Should this draft be dispatched to SOC (and their charter amended)?=
> -- Should this draft be processed as AD-sponsored?
> -- Should this draft be killed (if it is harmful)?

I do believe that this draft should be advanced, as this sort of
registration storm causes a problem in practice, though I don't have any opinion on what would be the proper track for it.

It would be interesting to know if there have been any large-scale
implementations, and what the results have been in practice.

In regard to the draft itself, I think a few tweaks would improve it.

- Clarify that the Restart-Timer value is associated with the URI that
=C2=A0 is being registered (for REGISTER) or the URI/event that is being =C2=A0 subscribed to (for SUBSCRIBE and PUBLISH).

- You may want a more clever way of handling multiple Restart-Timer
=C2=A0 values received from different servers during a boot sequence that =C2=A0 sends requests to several servers (which may be incompletely
=C2=A0 coordinated with each other). =C2=A0E.g., if the registration server= has
=C2=A0 a Restart-Timer of 300 and the voicemail server also has a
=C2=A0 Restart-Timer of 300, it seems that the UA could safely wait
=C2=A0 rand(0:300) then register and subscribe. =C2=A0If the VM server has = a zero
=C2=A0 restart timer, the UA probably wants to wait until the registration<= br> =C2=A0 is done anyway before subscribing to VM. =C2=A0But if the VM server = has a
=C2=A0 Restart-Timer of 600, there probably should be an additional delay =C2=A0 between registration and subscribing.

=C2=A0 The trouble is that rand(0:300)+rand(0:300) doesn't have the sam= e
=C2=A0 distribution as rand(0:600), so you may not want to say "Wait a= random
=C2=A0 fraction of the difference between the two Restart-Timers."

=C2=A0 Perhaps a workable algorithm is "Choose a random real number =C2=A0 uniformaly between zero and one. =C2=A0Each bootup operation may be<= br> =C2=A0 executed no earlier than (the random number) * (the specified
=C2=A0 Restart-Timer for that operation) seconds after power-up." =C2= =A0That
=C2=A0 causes each server to see the time-distribution of requests that it<= br> =C2=A0 expects.

- The text suggests that the Restart-Timer value expires when the
=C2=A0 registration expires. =C2=A0("The validity duration of the Rest= art-Timer
=C2=A0 header is the same as that of the corresponding registration
=C2=A0 operation.") =C2=A0That doesn't work at all, because the po= wer failure
=C2=A0 may exceed the length of all the registrations. =C2=A0The Restart-Ti= mer
=C2=A0 value has to be saved until another value is received for that same<= br> =C2=A0 target.

- You may want to allow/require the UA to place an upper limit on the
=C2=A0 Restart-Timer value. =C2=A0At the least, Restart-Timer should not ex= ceed
=C2=A0 the maximum registration/subscription duration the UA requests and =C2=A0 the server provides.

- I expect that you want to require that if a REGISTER response is
=C2=A0 received that does not contain Restart-Timer, then the saved
=C2=A0 Restart-Timer value is set to zero. =C2=A0That causes the expected =C2=A0 behavior when a registrar that supports Restart-Timer is replaced =C2=A0 with one that does not.

Dale

--047d7b5d90b532fde504f2652169-- From nobody Fri Feb 14 14:27:50 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27541A011C for ; Fri, 14 Feb 2014 14:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8ZlcLJJmqUN for ; Fri, 14 Feb 2014 14:27:44 -0800 (PST) Received: from mail.iptel.org (mail.iptel.org [212.79.111.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1C38F1A0145 for ; Fri, 14 Feb 2014 14:27:44 -0800 (PST) Received: from Jiris-MacBook-Pro.local (owli.iptel.org [212.79.111.153]) by mail.iptel.org (Postfix) with ESMTP id 321DE371F08; Fri, 14 Feb 2014 23:27:41 +0100 (CET) Message-ID: <52FE985C.9050004@iptel.org> Date: Fri, 14 Feb 2014 23:27:40 +0100 From: Jiri Kuthan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Ivo Sedlacek , Tim Panton new References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> < 52FCF23D.7070608@iptel.org> <39B5E4D390E9BD4890E2B3107900610112662679@ESESSMB301.ericsson.se> <0A527A1E-0789-41D8-902B-A1B12F03E69C@westhawk.co.uk> <39B5E4D390E9BD4890E2B3107900610112662CD1@ESESSMB301.ericsson.se> In-Reply-To: <39B5E4D390E9BD4890E2B3107900610112662CD1@ESESSMB301.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/F_4AjsajRY8gQonwdpXdz68bOq8 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2014 22:27:47 -0000 /* loosely answering to several other emails */ my esthetic preference is to leave policing spectrum to other more skilled organizations in the area than IETF. I mean whether someone's deployment of a BTS of any kind is legitimate in a region or not seems to me way far beyond protocol design. I think the "usual IETF question" which Michael H. has reiterated few times is if there is some IETF protocol design work to be done on the subject. It is my impression that this is not clear yet, neither to the openbts folks nor to the IETF folks. Not meaning to be critical -- many of most good things emerge of some degree of initial chaos :) Perhaps openbts works just perfect out of the box, and a useful contribution would be a "gateway BCP" like RFC3666 which helped especially in the early SIP adoption days. Maybe there are some hand-over aspects, authentication aspects -- I think it is worth trying to find it out. -jiri On 2/14/14 8:57 AM, Ivo Sedlacek wrote: > Hello Tim and all, > >> Apples and oranges - If I want a continent spanning, roaming capable billion dollar GSM network, then I need an IMS system. >> If I want an Um to SIP gateway I can run off solar power and hang in a tree, I'll go for an openBTS like solution. > > If you want an Um to SIP gateway (for whatever purpose), you need a license. To get a license, you will need to satisfy regulator's requirements. > > You still have not provided any references to regulators' document stating that a GSM band is free in any country. > > You still have not explain how such BTS "running off solar power and hanging in a tree" does not interfere with other BTSs hanging on the next tree. > > So, I am afraid, the BTS and Um To SIP gateway hanging will be switched off pretty quickly due to being illegal or causing interferences with other GSM nodes. > > Kind regards > > Ivo Sedlacek > From nobody Fri Feb 14 17:37:16 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5251A0015 for ; Fri, 14 Feb 2014 17:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYBJe4hw1NwY for ; Fri, 14 Feb 2014 17:37:03 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id D59A01A0012 for ; Fri, 14 Feb 2014 17:37:02 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1F1awAC002946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 19:36:59 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1F1auco004034 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Feb 2014 02:36:56 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Sat, 15 Feb 2014 02:36:56 +0100 From: "DRAGE, Keith (Keith)" To: Mary Barnes Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPKPi9kF9riHfhQ0Se4gDBfVRQX5q1h4VA Date: Sat, 15 Feb 2014 01:36:55 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B132EEA@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00361BF0-F6B9-48DD-80A6-CECD0A7C0A3B@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B131BEF@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B132EEAFR712WXCHMBA11zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/GlMSuwMbVE6TCAlhZlzEPcbS3zk Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 01:37:07 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B132EEAFR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As regards membership of 3GPP and GSMA. What I was suggesting is that 3GPP would be used. This allows you to get ac= cess to more operators and regulators than you would have in IETF, and more= specifically the correct representatives of the operators and regulators. GSMA will follow automatically if you get the operators interest. Membership of 3GPP for small organisations (annual) is not necessarily that= much more expensive that IETF (meeting fees). GSMA membership is not neede= d, and would be very expensive. Keith ________________________________ From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 13 February 2014 20:18 To: DRAGE, Keith (Keith) Cc: Tim Panton new; dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (Keith) > wrote: Ericsson is not the only vendor that sees a market for small cells, but the= expectation is that the products are built to the completed 3GPP standards= will be deployed in licensed spectrum by owners of that spectrum, although= the boxes may well be owned by 3rd parties. These deployments already exist. I see Jim has now identified that this proposal is for licensed GSM operato= rs in licensed GSM space. Personally, I would suggest if you believe the operators should be picking = this up, you take it to 3GPP where the operators are actually present. That= is the only way you will see it taken up by GSMA, which you will need to o= btain interoperator agreements to use this (e.g. roaming, shared networks).= 3GPP them works with IETF on any SIP extensions needed. [MB] One big problem with this proposal is that you must be a member of 3GP= P/GSMA to make contributions and to participate in meetings. And, I think having to first do the work in 3GPP and then bring it to IETF = would introduce a tremendous delay for something that's already been implem= ented/deployed. While they are proposing to reuse elements and protocols t= hat are part of an IMS network, the core issue they have is with interworki= ng SIP with the radio layer protocols. Certainly, one could implement all = the protocols that IMS uses and then use the 3GPP based specs and proprieta= ry headers to interwork with SIP in the Internet, but that would be terribl= y inefficient. [/MB] I would only see IETF having any direct part in this if the proposal was on= ly to use unlicensed spectrum by enterprises rather than licensed operators= , which Jim has negated. regards Keith ________________________________ From: Tim Panton new [mailto:thp@westhawk.co.uk] Sent: 13 February 2014 14:50 To: DRAGE, Keith (Keith) Cc: Harvind Samra; Ivo Sedlacek; dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) > wrote: Jumping in here, they are relevant in as much as there is no point in IETF = working on this if there is no known market for it. Usually those type of projects are published only on April 1st. So all Ivo is asking is for you to justify that it is worth other people wo= rking on this as well as yourselves. Perhaps if you identified the spectrum you believe is available for use in = the the countries identified, that would be useful. regards Keith Drage Ivo's employer seems to see a market for small cells, but looks to tie them= to existing operator IMS's through internet connections "owned by themselves or a partner". http://www.telecomlead.com/enterprise-networking/mwc-2014-ericsson-announce= -small-cell-service-20233/ Perhaps that's an April fools joke too (I can't see any avian carriers ment= ioned though)? It isn't up to the IETF to crown specific solutions. That's the market's jo= b. T. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_949EF20990823C4C85C18D59AA11AD8B132EEAFR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As regards membership of 3GPP and= GSMA.
 
What I was suggesting is that 3GP= P would be used. This allows you to get access to more operators and regula= tors than you would have in IETF, and more specifically the correct representatives of the operators and regulators.=
 
GSMA will follow automatically if= you get the operators interest.
 
Membership of 3GPP for small orga= nisations (annual) is not necessarily that much more expensive that IETF (m= eeting fees). GSMA membership is not needed, and would be very expensive.
 
Keith

From: Mary Barnes [mailto:mary.ietf= .barnes@gmail.com]
Sent: 13 February 2014 20:18
To: DRAGE, Keith (Keith)
Cc: Tim Panton new; dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS




On Thu, Feb 13, 2014 at 9:28 AM, DRAGE, Keith (K= eith) <kei= th.drage@alcatel-lucent.com> wrote:
Ericsson is not the only vendor that sees a market for small cells, but t= he expectation is that the products are built to the completed 3GPP standar= ds will be deployed in licensed spectrum by owners of that spectrum, although the boxes may well be owned by 3rd pa= rties.
 
These deployments already exist.
 
I see Jim has now identified that this proposal is for licensed GSM opera= tors in licensed GSM space.
 
Personally, I would suggest if you believe the operators should be pickin= g this up, you take it to 3GPP where the operators are actually present. Th= at is the only way you will see it taken up by GSMA, which you will need to obtain interoperator agreements to use = this (e.g. roaming, shared networks). 3GPP them works with IETF on any SIP = extensions needed.
[MB] One big problem with this proposal is that you must be a member o= f 3GPP/GSMA to make contributions and to participate in meetings.   &n= bsp;

And, I think having to first do the work in 3GPP and then bring it to = IETF would introduce a tremendous delay for something that's already been i= mplemented/deployed.  While they are proposing to reuse elements and p= rotocols that are part of an IMS network, the core issue they have is with interworking SIP with the radio layer pro= tocols.  Certainly, one could implement all the protocols that IMS use= s and then use the 3GPP based specs and proprietary headers to interwork wi= th SIP in the Internet, but that would be terribly inefficient. 
[/MB] 
 
I would only see IETF having any direct part in this if the proposal was = only to use unlicensed spectrum by enterprises rather than licensed operato= rs, which Jim has negated.
 
regards
 
Keith

From: Tim Panton new [mailto:thp@westhawk.co.uk]
Sent: 13 February 2014 14:50
To: DRAGE, Keith (Keith)
Cc: Harvind Samra; Ivo Sedlacek; dispatch@ietf.org

Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS


On 13 Feb 2014, at 14:34, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent= .com> wrote:

Jumping in here, they are relevant in as much as there is no point in IET= F working on this if there is no known market for it.
 
Usually those type of projects are published only on April 1st.
 
So all Ivo is asking is for you to justify that it is worth other people = working on this as well as yourselves.
 
Perhaps if you identified the spectrum you believe is available for use i= n the the countries identified, that would be useful.
 
regards
 
Keith Drage

Ivo's employer seems to see a market for small cells, but looks to tie= them to existing operator IMS's through 
internet connections "owned by themselves or a partner".
Perhaps that's an April fools joke too (I can't see any avian carriers= mentioned though)?

It isn't up to the IETF to crown specific solutions. That's the market= 's job.

T.




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


--_000_949EF20990823C4C85C18D59AA11AD8B132EEAFR712WXCHMBA11zeu_-- From nobody Fri Feb 14 17:37:18 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CAF81A0012 for ; Fri, 14 Feb 2014 17:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U86Sk248c0UD for ; Fri, 14 Feb 2014 17:37:06 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 1720E1A0017 for ; Fri, 14 Feb 2014 17:37:04 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s1F1awwW002947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 19:36:59 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s1F1aurw004031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Feb 2014 02:36:56 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Sat, 15 Feb 2014 02:36:56 +0100 From: "DRAGE, Keith (Keith)" To: Jiri Kuthan , Harvind Samra , Ivo Sedlacek Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIIAAPqkAgAASvbD///eJAIAAMB4ggAFh0ACAAXHr6IABHNuAgAAqBACAADBv4IAAD6iAgAI35xA= Date: Sat, 15 Feb 2014 01:36:54 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B132EE5@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-luce! nt.com> <52FCF23D.7070608@iptel.org> In-Reply-To: <52FCF23D.7070608@iptel.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Ow9BqFa48v7wBbUrIIe00080NRs Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 01:37:09 -0000 No. But to persuade people to work on anything, you need to persuade them that = there is something there in terms of a market. I'd hardly regard this as so= mething to be treated as an academic exercise. But I would still indicate there is insufficient information around here on= what is being attempted. Rather than having a draft with a set of use case= s and requirements, we are having to try and get it elaborated on the maili= ng list. Keith=20 > -----Original Message----- > From: Jiri Kuthan [mailto:jiri@iptel.org]=20 > Sent: 13 February 2014 16:27 > To: DRAGE, Keith (Keith); Harvind Samra; Ivo Sedlacek > Cc: dispatch@ietf.org > Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS >=20 > On 2/13/14 3:34 PM, DRAGE, Keith (Keith) wrote: > > Jumping in here, they are relevant in as much as there is=20 > no point in IETF working on this if there is no known market for it. >=20 > Hi Keith, >=20 > are you suggesting that IETF processes shall only allow work=20 > on technologies for which there is a known market? >=20 > I'm glad this was not the case in the past, otherwise I would=20 > not be able to send a single email. At least I don't have=20 > memory of IETF business case criteria for the SNMP protocol.=20 > If that shall change in the future, I would like to know what=20 > is the specific IETF criteria for market existence. Can you=20 > elaborate what these are supposed to be? >=20 > -jiri >=20 > p.s. one more question here: I understand your point that I'm=20 > eligible to read emails to this WG mailing list that carry=20 > confidentiality notice on the grounds of group memership.=20 > What I don't understand is whether I'm also permitted (in=20 > departure from the notice) to forward such an email to some=20 > other email address than that of the working group. >=20 >=20 > > Usually those type of projects are published only on April 1st. > > So all Ivo is asking is for you to justify that it is worth=20 > other people working on this as well as yourselves. > > Perhaps if you identified the spectrum you believe is=20 > available for use in the the countries identified, that would=20 > be useful. > > regards > > Keith Drage > = From nobody Fri Feb 14 17:44:02 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D181A0020 for ; Fri, 14 Feb 2014 17:44:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKIcfeTBHw3V for ; Fri, 14 Feb 2014 17:43:56 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4031A0017 for ; Fri, 14 Feb 2014 17:43:55 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1F1hkqi026778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 19:43:48 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1F1hkmS022481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Feb 2014 02:43:46 +0100 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Sat, 15 Feb 2014 02:43:46 +0100 From: "DRAGE, Keith (Keith)" To: Kurtis Heimerl , Michael Hammer Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAA3AICAAALFAIAAAFCAgAAAZICAAAdQgIAALnKAgAZ4SwCAAJlyIIAAPqkAgAASvbD///eJAIAAMB4ggAFh0ACAAXHr6IABHNuAgAAqBACAADBv4IAAmG6qgABRYACAALMlgIAADLGAgACkXoA= Date: Sat, 15 Feb 2014 01:43:45 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B132F29@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> <201402132328.s1DNS0U64926205@shell01.TheWorld.com> <00C069FD01E0324C9FFCADF539701DB3BBF2B24F@sc9-ex2k10mb1.corp.yaanatech.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B132F29FR712WXCHMBA11zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/hN_D-f29giPfwLAdeHZpSxOswgM Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 01:44:00 -0000 --_000_949EF20990823C4C85C18D59AA11AD8B132F29FR712WXCHMBA11zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable GPRS is not a control layer in the way I understand it - it is a mechanism = for providing IP transport, essentially the equivalent functionality of mob= ile IP. Keith ________________________________ From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Kurtis Heime= rl Sent: 14 February 2014 16:54 To: Michael Hammer Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS One could use GPRS as a control layer for SIP, but a key property here is o= ur ability to support existing phones, which couldn't use such a layer. On Sat, Feb 15, 2014 at 1:08 AM, Michael Hammer > wrote: OK, let me add some protocol perspective. Cut and paste courtesy of Wikipe= dia: **** The Um interface is the air interface for the GSM mobile telephone stand= ard. It is the interface between the mobile station (MS) and the Base transceiver station (BTS). It is called Um because it is = the mobile analog to the U interface of ISDN. Um is defined in the GSM 04= .xx and 05.xx series of specifications. Um can also support GPRS packet-oriented communication. Um layers[edit] The layers of GSM are initially defined in GSM 04.01 Section 7 and roughly = follow the OSI model. Um is defined= in the lower three layers of the model. Network Layer (L3)[edit] The Um network layer is defined= in GSM 04.07 and 04.08 and has three sublayers. A subscriber terminal must= establish a connection in each sublayer before accessing the next higher s= ublayer. 1. Radio Resource (RR). This sublayer manages the assignment and release of logical channel= s on the radio link. It is normally terminated in the BSC. 2. Mobility Management= (MM). This sublayer authenticates users and tracks their movements from ce= ll to cell. It is normally terminated in the VLR or HLR. 3. Call Control (CC). This su= blayer connects telephone calls and is taken directly from ITU-T Q.931. GSM 04.08 Annex E provides a table of corr= esponding paragraphs in GSM 04.08 and ITU-T Q.931 along with a summary of d= ifferences between the two. The CC sublayer is terminated in the MSC. The access order is RR, MM, CC. The release order is the reverse of that. Note that none of these sublayers terminate in the BTS itself. The standard= GSM BTS operates only in layers 1 and 2. *** So, the implementation appears to move the MSC to the BTS, along with a Q.9= 31 to SIP GW, such as: ETSI TS 183 036 V3.4.1 (2011-02) Telecommunications and Internet converged = Services and Protocols for Advanced Networking (TISPAN); ISDN/SIP interworking; Protocol specification Not sure how that saves battery, but that is an implementation question we = don't need to answer. Note also that since Um supports GPRS, could the BTS not also support a pac= ket relay for higher layer P2P SIP call control? Just asking. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Kurtis Heimerl Sent: Friday, February 14, 2014 12:27 AM To: Dale R. Worley Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS OpenBTS is an instance of an Um->SIP gateway. After this implementation, we= 've become aware that a broader view of the relative correctness of our des= ign would be valuable... and that's why this thread exists. We'd like the = IETF to help standardize this gateway model and make sure that the decision= s that were made are reasonable, scalable, and intelligent. At least that's my perception on why we're here. Jim may have another. On Fri, Feb 14, 2014 at 8:28 AM, Dale R. Worley > wrote: > From: "Ralph A. Schmid, dk5ras" > (Is there a reason you insert so many blank lines?) > So imagine a village, a few hundred people living there, most of > them owning mobile phones for communication when they travel to the > town for work or for trading goods - but at home those phones are > useless. > So somebody is able to spent a few thousand dollars, puts an antenna > onto some tree, flips the switch, and a few hundred phones can (and > do) log on. > Now more and more of those low-cost networks grow up, and people > want to connect them. Internet is available in some places, cheap to > buy and install WiFi-links are established, the whole thing evolves, > some simple structure grows. This story makes sense to me. The question seems to be how to interwork the GSM radio call-control protocol with SIP, so that a set of these base stations can operate as an integrated system. You'd want some sort of SIP registrar/proxy to operate as an ITSP, and all of the base stations make SIP connections with it. The next step is for someone to start designing this use of SIP. No doubt a lot of interesting questions will arise, and you may need to design some SIP extensions. But until you've got the design started and can discuss the design decisions, you're not in a position to talk about what SIP extensions are needed. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_949EF20990823C4C85C18D59AA11AD8B132F29FR712WXCHMBA11zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
GPRS is not a control layer in th= e way I understand it - it is a mechanism for providing IP transport, essen= tially the equivalent functionality of mobile IP.
 
Keith

From: dispatch [mailto:dispatch-bou= nces@ietf.org] On Behalf Of Kurtis Heimerl
Sent: 14 February 2014 16:54
To: Michael Hammer
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS

One could use GPRS as a control layer for SIP, but a key p= roperty here is our ability to support existing phones, which couldn't use = such a layer. 


On Sat, Feb 15, 2014 at 1:08 AM, Michael Hammer = <micha= el.hammer@yaanatech.com> wrote:

OK, let me add some protocol perspective.&= nbsp; Cut and paste courtesy of Wikipedia:

****

The Um interface is the air interface for the GSM mobile telephone standard. It is the interface between the mobile station (MS) and the Base transceiver station (BTS). It is called Um because it is the mobil= e analog to the U interface of ISDN. Um is defined in the GSM 04.xx and 05.xx series of specifications= . Um can also support GPRS packet-oriented communication.<= /span>

Um la= yers[edit]

The layers of GSM are initially de= fined in GSM 04.01 Section 7 and roughly follow the OSI model. Um is defined in the lower three layers of the model.=

Network Layer (L3)[edit]

The Um network layer is defined in GSM 04.07 and 04.08 and has three sublayers= . A subscriber terminal must establish a connection in each sublayer before= accessing the next higher sublayer.

  1. Radio Resource (RR). This sublayer manages the assignment = and release of logical channels on the radio link. It is normally terminated in the BSC.
  2. Mobility Management (MM). This subl= ayer authenticates users and tracks their movements from cell to cell. It i= s normally terminated in the VLR or HLR.
  3. Call Control (CC). This sublayer connects telepho= ne calls and is taken directly from ITU-T Q.931. GSM 04.08 Annex E provides a table of corresponding = paragraphs in GSM 04.08 and ITU-T Q.931 along with a summary of differences= between the two. The CC sublayer is terminated in the MSC.

The access order is RR, MM, CC. The release order is t= he reverse of that.

Note that none of these sublayers terminate in the BTS= itself. The standard GSM BTS operates only in layers 1 and 2.

***

So, the implementation appears to move the= MSC to the BTS, along with a Q.931 to SIP GW, such as:

ETSI TS 183 036 V3.4.1 (2011-02) Telecommu= nications and Internet converged Services and Protocols for Advanced Networ= king (TISPAN);

ISDN/SIP interworking; Protocol specificat= ion

 

Not sure how that saves battery, but that = is an implementation question we don’t need to answer.<= /span>

 

Note also that since Um supports GPRS, cou= ld the BTS not also support a packet relay for higher layer P2P SIP call co= ntrol?

 

Just asking.

 

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com

Mobile: +1 408-202-9291

500 Yo= semite Drive Suite 120

Milpit= as, CA 95035 USA

 

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Kurtis Heimerl
Sent: Friday, February 14, 2014 12:27 AM
To: Dale R. Worley


Cc: dispatch@= ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS<= /div>

 

OpenBTS is an instance of an Um->SIP gateway. Aft= er this implementation, we've become aware that a broader view of the relat= ive correctness of our design would be valuable...  and that's why thi= s thread exists. We'd like the IETF to help standardize this gateway model and make sure that the decisions that were = made are reasonable, scalable, and intelligent. 

 

At least that's my perception on why we're here. Jim= may have another. 

 

On Fri, Feb 14, 2014 at 8:28 AM, Dale R. Worley <= worley@ariadne.com<= /a>> wrote:

> From: "Ralph A. Schmid, dk5ras" <<= a href=3D"mailto:ralph@schmid.xxx" target=3D"_blank">ralph@schmid.xxx&g= t;

(Is there a reason you insert so many blank lines?)


> So imagine a village, a few hundred people living there, most of
> them owning mobile phones for communication when they travel to the > town for work or for trading goods - but at home those phones are
> useless.

> So somebody is ab= le to spent a few thousand dollars, puts an antenna
> onto some tree, flips the switch, and a few hundred phones can (and > do) log on.

> Now more and more= of those low-cost networks grow up, and people
> want to connect them. Internet is available in some places, cheap to > buy and install WiFi-links are established, the whole thing evolves, > some simple structure grows.

This story makes sense to me.  The question see= ms to be how to
interwork the GSM radio call-control protocol with SIP, so that a set
of these base stations can operate as an integrated system.  You'd
want some sort of SIP registrar/proxy to operate as an ITSP, and all
of the base stations make SIP connections with it.

The next step is for someone to start designing this use of SIP.  No doubt a lot of interesting questions will arise, and you may need to
design some SIP extensions.  But until you've got the design started and can discuss the design decisions, you're not in a position to talk
about what SIP extensions are needed.

Dale


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

 


--_000_949EF20990823C4C85C18D59AA11AD8B132F29FR712WXCHMBA11zeu_-- From nobody Fri Feb 14 19:00:11 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6C7E1A0035 for ; Fri, 14 Feb 2014 19:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qekRBN1t6wGr for ; Fri, 14 Feb 2014 19:00:03 -0800 (PST) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id A10341A0031 for ; Fri, 14 Feb 2014 19:00:03 -0800 (PST) Received: from SC9-EX2K10MB1.corp.yaanatech.com ([fe80::149d:c2e1:8065:2a47]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Fri, 14 Feb 2014 19:00:10 -0800 From: Michael Hammer To: "keith.drage@alcatel-lucent.com" , "kheimerl@cs.berkeley.edu" Thread-Topic: [dispatch] SIP and GSM/UMTS with OpenBTS Thread-Index: AQHPIj0OkF9riHfhQ0Se4gDBfVRQX5qmz3RggAAosQCAAAyAAIAAASOQgAC9HICAAALFAIAAAFCA//96B5CAAI2tgIAALnMAgAZ4WICAAOAQAIAACMEAgAAEaACAAAXeAIAAJYeAgAFsZwCAANo2FIABtI+AgAAqBQCAACCxgIAADyCAgAACJnGAAOhFAIAAKcuQgACWDICAAJQCgP//jmOg Date: Sat, 15 Feb 2014 03:00:00 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF2EF32@sc9-ex2k10mb1.corp.yaanatech.com> References: <040E1A40-BC55-4CFC-834A-FC958DEFDE25@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12A6DE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <60884D2D-1CC8-4A21-97BE-2ACCB49C351D@rangenetworks.com> <7723B448-642F-4138-89DD-379ACC7FA593@rangenetworks.com> <77E6DEC0-BCE1-4607-B52C-A4B6761A4B17@gmail.com> <00C069FD01E0324C9FFCADF539701DB3BBF23E22@sc9-ex2k10mb1.corp.yaanatech.com> <948FB37B-F2D4-4462-8B29-D03FDF65215F@rangenetworks.com> <93B4EA30-0734-439E-A129-B3B91B077720@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B12F6C3@FR712WXCHMBA11.zeu.alcatel-lucent.com> <2B05935E-EB65-4B36-ABD3-09DE9921F8A7@westhawk.co.uk> <949EF20990823C4C85C18D59AA11AD8B12F7CE@FR712WXCHMBA11.zeu.alcatel-lucent.com> <949EF20990823C4C85C18D59AA11AD8B12FA06@FR712WXCHMBA11.zeu.alcatel-lucent.com> <201402121601.s1CG1q0W4835781@shell01.TheWorld.com> <39B5E4D390E9BD4890E2B3107900610112662068@ESESSMB301.ericsson.se> <017BBEA0-CDBE-453D-9E98-77F470BC9181@rangenetworks.com> <949EF20990823C4C85C18D59AA11AD8B1319E6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <00b801cf28d0$3c39c000$b4ad4000$@schmid.xxx> <201402132328.s1DNS0U64926205@shell01.TheWorld.com> <00C069FD01E0324C9FFCADF539701DB3BBF2B24F@sc9-ex2k10mb1.corp.yaanatech.com> <949EF20990823C4C85C18D59AA11AD8B132F29@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B132F29@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.96] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03B3_01CF29CF.DB150270" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/183MdxbxmqTmG1C6rNg2xHYc1F4 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 03:00:10 -0000 ------=_NextPart_000_03B3_01CF29CF.DB150270 Content-Type: multipart/alternative; boundary="----=_NextPart_001_03B4_01CF29CF.DB150270" ------=_NextPart_001_03B4_01CF29CF.DB150270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Correct. I was just suggesting the possibility of giving phones a direct packet connection and then let them run a P2P app on top. However, if this is for lame 2G feature phones, then that might not be possible. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] Sent: Friday, February 14, 2014 8:44 PM To: Kurtis Heimerl; Michael Hammer Cc: dispatch@ietf.org Subject: RE: [dispatch] SIP and GSM/UMTS with OpenBTS GPRS is not a control layer in the way I understand it - it is a mechanism for providing IP transport, essentially the equivalent functionality of mobile IP. Keith _____ From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Kurtis Heimerl Sent: 14 February 2014 16:54 To: Michael Hammer Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS One could use GPRS as a control layer for SIP, but a key property here is our ability to support existing phones, which couldn't use such a layer. On Sat, Feb 15, 2014 at 1:08 AM, Michael Hammer wrote: OK, let me add some protocol perspective. Cut and paste courtesy of Wikipedia: **** The Um interface is the air interface for the GSM mobile telephone standard. It is the interface between the mobile station (MS) and the Base transceiver station (BTS). It is called Um because it is the mobile analog to the U interface of ISDN . Um is defined in the GSM 04.xx and 05.xx series of specifications. Um can also support GPRS packet-oriented communication. Um layers[edit ] The layers of GSM are initially defined in GSM 04.01 Section 7 and roughly follow the OSI model . Um is defined in the lower three layers of the model. Network Layer (L3)[edit ] The Um network layer is defined in GSM 04.07 and 04.08 and has three sublayers. A subscriber terminal must establish a connection in each sublayer before accessing the next higher sublayer. 1. Radio Resource (RR). This sublayer manages the assignment and release of logical channels on the radio link. It is normally terminated in the BSC . 2. Mobility Management (MM). This sublayer authenticates users and tracks their movements from cell to cell. It is normally terminated in the VLR or HLR . 3. Call Control (CC). This sublayer connects telephone calls and is taken directly from ITU-T Q.931 . GSM 04.08 Annex E provides a table of corresponding paragraphs in GSM 04.08 and ITU-T Q.931 along with a summary of differences between the two. The CC sublayer is terminated in the MSC . The access order is RR, MM, CC. The release order is the reverse of that. Note that none of these sublayers terminate in the BTS itself. The standard GSM BTS operates only in layers 1 and 2. *** So, the implementation appears to move the MSC to the BTS, along with a Q.931 to SIP GW, such as: ETSI TS 183 036 V3.4.1 (2011-02) Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); ISDN/SIP interworking; Protocol specification Not sure how that saves battery, but that is an implementation question we don't need to answer. Note also that since Um supports GPRS, could the BTS not also support a packet relay for higher layer P2P SIP call control? Just asking. Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408-202-9291 500 Yosemite Drive Suite 120 Milpitas, CA 95035 USA From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Kurtis Heimerl Sent: Friday, February 14, 2014 12:27 AM To: Dale R. Worley Cc: dispatch@ietf.org Subject: Re: [dispatch] SIP and GSM/UMTS with OpenBTS OpenBTS is an instance of an Um->SIP gateway. After this implementation, we've become aware that a broader view of the relative correctness of our design would be valuable... and that's why this thread exists. We'd like the IETF to help standardize this gateway model and make sure that the decisions that were made are reasonable, scalable, and intelligent. At least that's my perception on why we're here. Jim may have another. On Fri, Feb 14, 2014 at 8:28 AM, Dale R. Worley wrote: > From: "Ralph A. Schmid, dk5ras" (Is there a reason you insert so many blank lines?) > So imagine a village, a few hundred people living there, most of > them owning mobile phones for communication when they travel to the > town for work or for trading goods - but at home those phones are > useless. > So somebody is able to spent a few thousand dollars, puts an antenna > onto some tree, flips the switch, and a few hundred phones can (and > do) log on. > Now more and more of those low-cost networks grow up, and people > want to connect them. Internet is available in some places, cheap to > buy and install WiFi-links are established, the whole thing evolves, > some simple structure grows. This story makes sense to me. The question seems to be how to interwork the GSM radio call-control protocol with SIP, so that a set of these base stations can operate as an integrated system. You'd want some sort of SIP registrar/proxy to operate as an ITSP, and all of the base stations make SIP connections with it. The next step is for someone to start designing this use of SIP. No doubt a lot of interesting questions will arise, and you may need to design some SIP extensions. But until you've got the design started and can discuss the design decisions, you're not in a position to talk about what SIP extensions are needed. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_001_03B4_01CF29CF.DB150270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Correct.  I was just suggesting the possibility of giving phones = a direct packet connection and then let them run a P2P app on = top.

However, if this is for lame 2G feature phones, then that might not = be possible.

 

Michael Hammer

Principal Engineer

michael.hammer@yaanatech.com

Mobile: +1 408-202-9291

500 Yosemite Drive Suite = 120

Milpitas, CA 95035 = USA

 

From:= = DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] =
Sent: Friday, February 14, 2014 8:44 PM
To: Kurtis = Heimerl; Michael Hammer
Cc: = dispatch@ietf.org
Subject: RE: [dispatch] SIP and GSM/UMTS = with OpenBTS

 

GP= RS is not a control layer in the way I understand it - it is a mechanism = for providing IP transport, essentially the equivalent functionality of = mobile IP.

 

Ke= ith

 

From:= = dispatch [mailto:dispatch-bounces@ietf.or= g] On Behalf Of Kurtis Heimerl
Sent: 14 February = 2014 16:54
To: Michael Hammer
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIP and GSM/UMTS with = OpenBTS

One could use = GPRS as a control layer for SIP, but a key property here is our ability = to support existing phones, which couldn't use such a = layer. 

 

On Sat, Feb 15, 2014 at 1:08 AM, Michael Hammer <michael.hammer@yaanatech.com> = wrote:

OK, let me add some protocol perspective.  Cut and paste = courtesy of Wikipedia:

****

The Um interface is the air interface for the GSM mobile telephone standard. It is the interface = between the mobile station (MS) and the = Base transceiver = station (BTS). It is called Um because it is the mobile analog to = the U interface of ISDN. Um is defined in the GSM 04.xx and 05.xx series = of specifications. Um can also support GPRS packet-oriented = communication.

Um layers[edit]

The layers of GSM are initially defined in GSM 04.01 Section 7 = and roughly follow the OSI model. Um is defined in the lower three = layers of the model.

Network = Layer (L3)[edit]

The Um network layer is defined = in GSM 04.07 and 04.08 and has three sublayers. A subscriber terminal = must establish a connection in each sublayer before accessing the next = higher sublayer.

  1. Radio Resource = (RR). This sublayer manages the assignment and release of logical = channels on the radio link. It is normally terminated in the BSC.
  2. Mobility Management = (MM). This sublayer authenticates users and tracks their movements from = cell to cell. It is normally terminated in the VLR or HLR.
  3. Call Control (CC). This sublayer connects = telephone calls and is taken directly from ITU-T Q.931. GSM 04.08 Annex E provides a table of = corresponding paragraphs in GSM 04.08 and ITU-T Q.931 along with a = summary of differences between the two. The CC sublayer is terminated in = the MSC. =

The access order is RR, = MM, CC. The release order is the reverse of that. =

Note that none of these = sublayers terminate in the BTS itself. The standard GSM BTS operates = only in layers 1 and 2.

***

So, the implementation appears to move the MSC to the BTS, along with = a Q.931 to SIP GW, such as:

ETSI TS 183 036 V3.4.1 (2011-02) Telecommunications and Internet = converged Services and Protocols for Advanced Networking = (TISPAN);

ISDN/SIP interworking; Protocol specification

 <= /o:p>

Not sure how that saves battery, but that is an implementation = question we don’t need to answer.

 <= /o:p>

Note also that since Um supports GPRS, could the BTS not also support = a packet relay for higher layer P2P SIP call = control?

 <= /o:p>

Just asking.

 <= /o:p>

Michael = Hammer

Principal = Engineer

michael.hammer@yaanatech.com<= /p>

Mobile: +1 = 408-202-9291

500 = Yosemite Drive Suite 120

Milpitas, CA 95035 USA

 <= /o:p>

From:= = dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of = Kurtis Heimerl
Sent: Friday, February 14, 2014 12:27 = AM
To: Dale R. Worley


Cc: dispatch@ietf.org
Subject: Re: = [dispatch] SIP and GSM/UMTS with OpenBTS

 <= /o:p>

OpenBTS is = an instance of an Um->SIP gateway. After this implementation, we've = become aware that a broader view of the relative correctness of our = design would be valuable...  and that's why this thread exists. = We'd like the IETF to help standardize this gateway model and make sure = that the decisions that were made are reasonable, scalable, and = intelligent. 

 <= /o:p>

At least = that's my perception on why we're here. Jim may have = another. 

 <= /p>

On Fri, Feb = 14, 2014 at 8:28 AM, Dale R. Worley <worley@ariadne.com> wrote:

> From: = "Ralph A. Schmid, dk5ras" <ralph@schmid.xxx>

(Is there a reason you = insert so many blank lines?)


> So = imagine a village, a few hundred people living there, most of
> = them owning mobile phones for communication when they travel to = the
> town for work or for trading goods - but at home those = phones are
> useless.

> So somebody = is able to spent a few thousand dollars, puts an antenna
> onto = some tree, flips the switch, and a few hundred phones can (and
> = do) log on.

> Now more and = more of those low-cost networks grow up, and people
> want to = connect them. Internet is available in some places, cheap to
> buy = and install WiFi-links are established, the whole thing evolves,
> = some simple structure grows.

This story = makes sense to me.  The question seems to be how to
interwork = the GSM radio call-control protocol with SIP, so that a set
of these = base stations can operate as an integrated system.  You'd
want = some sort of SIP registrar/proxy to operate as an ITSP, and all
of = the base stations make SIP connections with it.

The next step is = for someone to start designing this use of SIP.  No
doubt a lot = of interesting questions will arise, and you may need to
design some = SIP extensions.  But until you've got the design started
and can = discuss the design decisions, you're not in a position to talk
about = what SIP extensions are needed.

Dale


________= _______________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch=

 <= /o:p>

 

------=_NextPart_001_03B4_01CF29CF.DB150270-- ------=_NextPart_000_03B3_01CF29CF.DB150270 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRPzCCBBow ggMCAhEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzMwHhcNOTkxMDAxMDAwMDAwWhcNMzYwNzE2MjM1OTU5WjCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDd hNS5tPmn2PMEeJzePdxsExbZet0kUWbAxyZZDawGCMKU0TMf8IM1H24byN6qbhVOVCfvxG0a7Avj DvBEpVfHQFgeo0cfcexg9m2UyBg57f5CGFbf5ExJEHhOAXY1YxI23Wa8AQQ2o1Vo1aI2CayrISZU Bq0/yhTgrMqtBh2V4vid8eBg/8J/dStMzNr+h5kh6rr+PlTX0ll42zxuz6ATABq4J6HkvmeWyqDF s5zdyXWe6zCaX6PN2a54GT8j6VzbKb2tVcgbVIxj9uim6sc3ElyjKR4C2dsfO7TXD1ZHgRUESq+D J9HFWIjB3faqp6MY2miqbRFR4b9la5+WdtE9AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBAKtmjdez useatuZV0AXxnzGNWqrZqkYmD3Htpa1TVmIBRypE6f4/dAsTm7n0TRuy0V+yttKIXLOfzcvUp9lg lYQ6+ME3HWHK57DF5ZHaVKasMYGul97NCKy4wJeAf25ypOdpE5VlH8STPP15jwTUPk/q957OzWd8 T2UC/5GFVHPH/zb3hi3s0F5P/xGfcgbWuBrxTA0mZeJEgB7Hn+Pd6Ara7KUggGlooU9+4WvPB0H6 g468ON2wLhGxa7JCzJq8+UgieUoZD7IcPiB02WrDvvIoeBNWeU9tUOobsLVXsTdmWCPz3A/fCofE 74YF1TgUYJmjS94GlnEs8tu2H6TvP+4wggZCMIIFKqADAgECAhA4qwAv/66Wt1b/OVr7XecbMA0G CSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWdu LCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0xMTA5MDEw MDAwMDBaFw0yMTA4MzEyMzU5NTlaMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMg Q29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBl cnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFs IFN1YnNjcmliZXIgQ0EgLSBHNDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMbsJ/0d Y/Q7HYrB0xzIyIKGtrhKhpKqgVxyyjANL55BIlcwISWQmqP0rCrGiBeGYXITdi7sA8snm48ggDfg 5IraVaZQD/y5XCNpiUKhuh+v7w75pMkK8fg3ssbZkkqufd+4RB+buj+MBv7YI09IUSNqYISo7icv YN+W8hoqjDyPAMxPy/ogjrw19uHwmrYF8/wdP8YUew7a8gXk04MCpsVpcLSp5Fbp2x1c9KY24mu1 Hiot3L677joEsDAIrV9obMa9BpaIhOfmqWQtvDgwu4gmw2dmZrS0d/nAoccOcu9m4uW5yuDzhXc1 mN7UHLD+ZnHiOMtufE9AVeuX2agYHu0CAwEAAaOCAkQwggJAMDgGCCsGAQUFBwEBBCwwKjAoBggr BgEFBQcwAYYcaHR0cDovL3BraS1vY3NwLnZlcmlzaWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEA MGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5zeW1h dXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0P AQH/BAQDAgEGMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFWZXJpU2lnbk1QS0ktMi05NzAdBgNV HQ4EFgQUrfnDk3IttbkoYeSk12DVxApeGgEwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO ZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVk IHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUA A4IBAQDWj8Ham4jys2xNH1gvugFRXXTBRujDuHuf1kDx7/8yuolrwA40Q5+kmeak8F1IM2KFhWH+ I4gijGCbK5xlSZTEojgkSKVcpVBLaOliIqeT6Jkibj1buxBCDh9MdUc0VgmP+L2MPPNcu9KWcFRw Yk3v0RC+nUgsXuyGaweC8D3hJScoLOAWdh6z/eViltKKPV8rrvtcwhO3ZWPLNHZDn9aHmaturZXB AD9GJ4H/Nd4jDkPcFF8y+cop78JSMPWZ3bmB+DolII2CaPK5IYV0ZgThhjkWMvIt1iqoyd7ZAAJP 4xggxaWBVraV3tOCrfh7Jb5kfC6gunAs+Pl14nRNB22EMIIG1zCCBb+gAwIBAgIQEB3dROkPDT0Q 6QYEc74tcjANBgkqhkiG9w0BAQUFADCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVj IENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQ ZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBIC0gRzQwHhcNMTMwNDAxMDAwMDAwWhcNMTQwNDAyMjM1OTU5WjCBzjEu MCwGA1UEAwwlUGVyc29uYSBOb3QgVmFsaWRhdGVkIC0gMTM2NDg0MjY5NDQ0MzErMCkGCSqGSIb3 DQEJARYcbWljaGFlbC5oYW1tZXJAeWFhbmF0ZWNoLmNvbTEPMA0GA1UECwwGUy9NSU1FMR4wHAYD VQQLDBVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxHzAdBgNVBAsMFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHTAbBgNVBAoMFFN5bWFudGVjIENvcnBvcmF0aW9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEAh2AtKQNowI8ILmNvdcY16moA8CH7hjSvGDNofwWsh4quEfZ6VQGtDhhOjUmW6JVq 719MH8FNJcVr8oAiVaK3nNeJTL2wO68LpgX6tcZ/z22pJoz98wHzgfWf3pfEUYrCqYg2V3m6oe0t kd+OaeY8DmPVSpG7as0rkoEzeNwCtmpYjkm96mBO6/AQwsowSLbSuqkEGykp1k47KiPBtxhbp2um IReh94vPrr1O9zXau9oGMvABJjigYQ2e5AhhhDdK8qOkhgkMAJN2nvLqY+VFrnFIsb5noQ/tP2M/ ct9qwRZ5kUaumRqE/XzV3rH8PoacZW/YvcwAp8Gr1ZaHCMRl+wIDAQABo4IC1TCCAtEwDAYDVR0T AQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwIAYDVR0lAQH/BBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMC MB0GA1UdDgQWBBTlvYUx4PMlUy6uvceJkDMK4jBDZjAnBgNVHREEIDAegRxtaWNoYWVsLmhhbW1l ckB5YWFuYXRlY2guY29tMB8GA1UdIwQYMBaAFK35w5NyLbW5KGHkpNdg1cQKXhoBMIIBKwYIKwYB BQUHAQEEggEdMIIBGTCCARUGCCsGAQUFBzAChoIBB2xkYXA6Ly9kaXJlY3RvcnkudmVyaXNpZ24u Y29tL0NOJTIwJTNEJTIwU3ltYW50ZWMlMjBDbGFzcyUyMDElMjBJbmRpdmlkdWFsJTIwU3Vic2Ny aWJlciUyMENBJTIwLSUyMEc0JTJDJTIwT1UlMjAlM0QlMjBQZXJzb25hJTIwTm90JTIwVmFsaWRh dGVkJTJDJTIwT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQyUyME8lMjAl M0QlMjBTeW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDJTIwQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNh dGU7YmluYXJ5MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2Nh XzU2MWMxMDM2OTBjOTdhNjkyNDdhMGVmMDcxYWM4MWFmL0xhdGVzdENSTC5jcmwwbAYDVR0gBGUw YzBhBgtghkgBhvhFAQcXATBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2Nw czAoBggrBgEFBQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTAqBgpghkgBhvhFARAD BBwwGgYRYIZIAYb4RQEQAQICBAGGsxcWBTEwOTIyMA0GCSqGSIb3DQEBBQUAA4IBAQAae/er4pfB TpqK6c/uJ9D8dVJzzNX26akkB8z/29totzbkpFAIlXRh02iNVK+GnsgS1gwu3FOvjgT5M4i+cNxD vTJVcnZNXns75JUGX3UsWQbtSySrVzQx8lMtwW6nXHM5GlEaY8/jKVpambG2q9OHjmwMTz7I4A+y KiiGCGdhE23dFOvku6t/oiwqFnXJmb4o75kbVevKEOd34MIj0P7Q8+1mZcNYEUTYKadoPXFyTWnO 2HTMvFcGgdLFKcqb13clWeW3/B5WjdBimpMjbvwi8ZbrhFdp7Y3NLKFSRH8W29rt0LW7zULxii0z 34NGsBkW9w95PLzTsqmKD4Yv5AkIMYIEkjCCBI4CAQEwgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYD VQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29y azEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFz cyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMAkGBSsO AwIaBQCgggKrMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE0MDIx NTAyNTgxMlowIwYJKoZIhvcNAQkEMRYEFGNX2Ln3aOT08dOEvFQTvOrhvXm1MIGrBgkqhkiG9w0B CQ8xgZ0wgZowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQME AQIwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo MAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMIHMBgkrBgEE AYI3EAQxgb4wgbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3Qg VmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJl ciBDQSAtIEc0AhAQHd1E6Q8NPRDpBgRzvi1yMIHOBgsqhkiG9w0BCRACCzGBvqCBuzCBpjELMAkG A1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRl YyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMT LlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEBAd3UTpDw09 EOkGBHO+LXIwDQYJKoZIhvcNAQEBBQAEggEAOiTSSwhOc2e/cFfWENfLVdw1bWy3cuSnuDW2oSVq bZa196QWDF4ki/Wmg6lB9Tl73+sHpv3y4oEpj+jDJiu2x0DXwIvwT4LIsFEFR7VfloIQeG3kIr/Y EvF0BJWQtmvQyPwH4B9JTkcOF8RNy+eFRjCBn+Djbyvp0APgSR2vb5nsvAQ0iUGs+3QRYg+ezpLf W1Q+RwamZOYee/5tzmFtkTxlQc+J7ISGURBQ+SULBbcFCfhtXT+dlUUO5SBHJ66QnSe44p5psLP4 P5uWovZaPE41+g1n25QzxLMzsyCwfYSm9lVR5dENFMAc4vhppOCOYp2QMB1L7NBJonu10CYsmwAA AAAAAA== ------=_NextPart_000_03B3_01CF29CF.DB150270-- From nobody Sat Feb 15 15:29:38 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003241A016A for ; Sat, 15 Feb 2014 15:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QpL05n1YY-dr for ; Sat, 15 Feb 2014 15:29:35 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 597691A01B4 for ; Sat, 15 Feb 2014 15:29:35 -0800 (PST) Received: from [10.66.246.94] (unknown [64.104.248.145]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F1E50509B5; Sat, 15 Feb 2014 18:29:30 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Cullen Jennings In-Reply-To: <52FD112B.5040209@alum.mit.edu> Date: Sat, 15 Feb 2014 08:38:13 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD112B.5040209@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/N70-xPh6vyBC99p-OS6CKcmDvgA Cc: DISPATCH Subject: Re: [dispatch] X over websockets X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 23:29:37 -0000 On Feb 14, 2014, at 5:38 AM, Paul Kyzivat wrote: > Or for each X are we going to have a beauty contest between websockets = and data channel? Both is the reality of what IETF will probably end up doing=20 >=20 > Or what? This really screams for a common framework that guides how to write a = spec for X over web sockets or data channels.=20 From nobody Sat Feb 15 15:35:40 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9467F1A01E7 for ; Sat, 15 Feb 2014 15:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.561 X-Spam-Level: X-Spam-Status: No, score=-0.561 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_24_48=1.34, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8KoQ9lK_6VZ for ; Sat, 15 Feb 2014 15:35:38 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by ietfa.amsl.com (Postfix) with ESMTP id 686531A01CD for ; Sat, 15 Feb 2014 15:35:38 -0800 (PST) Received: from [10.66.246.94] (unknown [64.104.248.145]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 7EE24509B6; Sat, 15 Feb 2014 18:35:13 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Cullen Jennings In-Reply-To: Date: Sat, 15 Feb 2014 08:42:52 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD36A3.1020606@gmail.com> To: Peter Dunkley X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/XpTW-xtBfkZHQo_y95mVgyHF8vM Cc: DISPATCH Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 23:35:39 -0000 On Feb 14, 2014, at 8:24 AM, Peter Dunkley = wrote: > Because WebSockets is an asynchronous protocol two MSRP peers (that = are clients) cannot use MSRP over WebSockets. Just sort of curios, why can=92t this work? From nobody Sat Feb 15 15:35:45 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 345311A00F5 for ; Sat, 15 Feb 2014 15:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.049 X-Spam-Level: X-Spam-Status: No, score=-110.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMU9LAdt1tb5 for ; Sat, 15 Feb 2014 15:35:42 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id CB6A41A022B for ; Sat, 15 Feb 2014 15:35:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2381; q=dns/txt; s=iport; t=1392507340; x=1393716940; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=H5mEPXH2d2RKcgkCiUo5zUZvYVwt5E9qxIYqoHvFJRY=; b=lziQaAr4WO5Y/uQq34KUrW3wnV39t8IUWzzFsKZX2w2fdglCcA0bUaDI 594lkl0Rewyp6+ZLjc+7E6x5LzHABJbyGx6nxJNrcE+pEUqCVUnWxNvfQ YG/+rynyO6CLk0iNQlNiCiZG4DMscrNd/UkAN+jJGRxbWmMs+S0uiRbmr U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAIH4/1KtJV2c/2dsb2JhbABZDoJ4OFe+bU+BDxZ0giUBAQEDAQEBAWsLBQsCAQgkIicLJQIEDgUUh2kIDck3F44zGzMHgySBFASYLIEykHGCbj+CKg X-IronPort-AV: E=Sophos;i="4.95,852,1384300800"; d="scan'208";a="20775721" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP; 15 Feb 2014 23:35:39 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1FNZdC1016648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 15 Feb 2014 23:35:39 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.105]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Sat, 15 Feb 2014 17:35:39 -0600 From: "Cullen Jennings (fluffy)" To: Charles Shen Thread-Topic: [dispatch] draft-shen-soc-avalanche-restart-overload Thread-Index: AQHPKqahBkj4OIFP6USMZv7/Bsbi+Q== Date: Sat, 15 Feb 2014 23:35:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.246.94] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/cqT-8E7OS2hBRvEOGPod-AWDoHA Cc: DISPATCH Subject: Re: [dispatch] draft-shen-soc-avalanche-restart-overload X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 23:35:45 -0000 This seems like a draft that could benefit from review in a WG. Can someone= fill in a bit of the background of this draft in SOC. I=92m not seeing why= the SOC charter would need to be changed to do this work.=20 On Feb 11, 2014, at 1:35 PM, Charles Shen wrote: > Dear all:=20 >=20 > As advised by Richard Barnes, I am writing to seek opinion from you about= this draft: >=20 > http://datatracker.ietf.org/doc/draft-shen-soc-avalanche-restart-overload= / > A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart Overl= oad Control >=20 > Abstract: > When a large number of clients register with a SIP registrar server > at approximately the same time, the server may become overloaded. > Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests may > have similar effects. Such request avalanches can occur, for > example, after a power failure and recovery in a metropolitan area. > This document describes how to avoid such overload situations. Under > this mechanism, a server estimates an avalanche restart backoff > interval during its normal operation and conveys this interval to its > clients through a new Restart-Timer header in normal response > messages. Once an avalanche restart actually occurs, the clients > perform backoff based on the previously received Restart-Timer header > value before sending out the first request attempt. Thus, the > mechanism spreads all the initial client requests and prevents them > from overloading the server. >=20 > The draft has been presented and discussed in IETF meetings since 2010, a= nd generated interest among the community: >=20 > https://encrypted.google.com/search?as_q=3Ddraft-shen-soc-avalanche-resta= rt-overload&as_sitesearch=3Dwww.ietf.org%2Fmail-archive%2Fweb%2F >=20 > I am looking for your kind opinion on what should be the appropriate next= step for this document: >=20 > -- Should this draft be dispatched to SOC (and their charter amended)? > -- Should this draft be processed as AD-sponsored? > -- Should this draft be killed (if it is harmful)? >=20 > Thank you very much. >=20 > Charles >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Sun Feb 16 11:09:55 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC731A0227 for ; Sun, 16 Feb 2014 11:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWieEVkEmhqY for ; Sun, 16 Feb 2014 11:09:51 -0800 (PST) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 22AD71A020D for ; Sun, 16 Feb 2014 11:09:51 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id g12so16803978oah.3 for ; Sun, 16 Feb 2014 11:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=GLJt2BzKq9Z/+lpdPjT2VB1mzHPZ095U9KtBJMeCoFA=; b=MV7fg2qgN6lQsDBWrEq0zvGqdGMhhE2gs394ZAh7MZsIdiwdDKXZuaDvziTQ56MXJS g+ZyU8QAiBDeN5vM5jQOgKgVfhbwJmPGKPZmWFeWDKmp9GTqxVNc8/utEqKNU2zoPOtr j0sy7U1sNUZzKnFfMhFyE26yi4xV50A8ysQku+nDSDwKkZBNz/gwXBFYZWrcgiKmKKH0 ALKSBDm7XWLE9Th15AtcRoFRSbpRBtVMCET95zlZVgsh7E4nrtFZcPucBS5qpJ11N6dQ hgEvNEGJq/2qSSSxft0gjk8oXsUS02Hch41vNMMuFY85bQdaJgrX6Aawur4zM6uidRTI zVFg== X-Received: by 10.182.113.195 with SMTP id ja3mr2705431obb.46.1392577788688; Sun, 16 Feb 2014 11:09:48 -0800 (PST) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.55.106 with HTTP; Sun, 16 Feb 2014 11:09:28 -0800 (PST) In-Reply-To: References: From: Charles Shen Date: Sun, 16 Feb 2014 14:09:28 -0500 X-Google-Sender-Auth: AYy80VMU2Fki15bQ18FE-BiwMhY Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=089e013d0db06ac0d204f28ac8b1 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/a05N4XwwrZp1LAKviC801ZoYFyo Cc: DISPATCH Subject: Re: [dispatch] draft-shen-soc-avalanche-restart-overload X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 19:09:54 -0000 --089e013d0db06ac0d204f28ac8b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Cullen for your comments, According to my understanding, the current charter description http://datatracker.ietf.org/wg/soc/charter/ does not seem to cover the goal of advancing this draft into a working group deliverable. Please correct me if I were wrong. Thanks Charles On Sat, Feb 15, 2014 at 6:35 PM, Cullen Jennings (fluffy) wrote: > > This seems like a draft that could benefit from review in a WG. Can > someone fill in a bit of the background of this draft in SOC. I=E2=80=99m= not > seeing why the SOC charter would need to be changed to do this work. > > > > On Feb 11, 2014, at 1:35 PM, Charles Shen wrote= : > > > Dear all: > > > > As advised by Richard Barnes, I am writing to seek opinion from you > about this draft: > > > > > http://datatracker.ietf.org/doc/draft-shen-soc-avalanche-restart-overload= / > > A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart > Overload Control > > > > Abstract: > > When a large number of clients register with a SIP registrar server > > at approximately the same time, the server may become overloaded. > > Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests may > > have similar effects. Such request avalanches can occur, for > > example, after a power failure and recovery in a metropolitan area. > > This document describes how to avoid such overload situations. Unde= r > > this mechanism, a server estimates an avalanche restart backoff > > interval during its normal operation and conveys this interval to it= s > > clients through a new Restart-Timer header in normal response > > messages. Once an avalanche restart actually occurs, the clients > > perform backoff based on the previously received Restart-Timer heade= r > > value before sending out the first request attempt. Thus, the > > mechanism spreads all the initial client requests and prevents them > > from overloading the server. > > > > The draft has been presented and discussed in IETF meetings since 2010, > and generated interest among the community: > > > > > https://encrypted.google.com/search?as_q=3Ddraft-shen-soc-avalanche-resta= rt-overload&as_sitesearch=3Dwww.ietf.org%2Fmail-archive%2Fweb%2F > > > > I am looking for your kind opinion on what should be the appropriate > next step for this document: > > > > -- Should this draft be dispatched to SOC (and their charter amended)? > > -- Should this draft be processed as AD-sponsored? > > -- Should this draft be killed (if it is harmful)? > > > > Thank you very much. > > > > Charles > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > --089e013d0db06ac0d204f28ac8b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Cullen for your comments,=C2=A0

= According to my understanding, the current charter description=C2=A0

does not seem to cover the goal of advancing this draft= into a working group deliverable. Please correct me if I were wrong.=C2=A0=

Thanks

Charles




On Sat, Feb 15, 2014 at 6:35 PM, Cullen Jennings (fluffy) <fluf= fy@cisco.com> wrote:

This seems like a draft that could benefit from review in a WG. Can someone= fill in a bit of the background of this draft in SOC. I=E2=80=99m not seei= ng why the SOC charter would need to be changed to do this work.



On Feb 11, 2014, at 1:35 PM, Charles Shen <charles@cs.columbia.edu> wrote:

> Dear all:
>
> As advised by Richard Barnes, I am writing to seek opinion from you ab= out this draft:
>
> http://datatracker.ietf.org/doc/draft-sh= en-soc-avalanche-restart-overload/
> A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart Ov= erload Control
>
> Abstract:
> =C2=A0 =C2=A0When a large number of clients register with a SIP regist= rar server
> =C2=A0 =C2=A0at approximately the same time, the server may become ove= rloaded.
> =C2=A0 =C2=A0Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH req= uests may
> =C2=A0 =C2=A0have similar effects. =C2=A0Such request avalanches can o= ccur, for
> =C2=A0 =C2=A0example, after a power failure and recovery in a metropol= itan area.
> =C2=A0 =C2=A0This document describes how to avoid such overload situat= ions. =C2=A0Under
> =C2=A0 =C2=A0this mechanism, a server estimates an avalanche restart b= ackoff
> =C2=A0 =C2=A0interval during its normal operation and conveys this int= erval to its
> =C2=A0 =C2=A0clients through a new Restart-Timer header in normal resp= onse
> =C2=A0 =C2=A0messages. =C2=A0Once an avalanche restart actually occurs= , the clients
> =C2=A0 =C2=A0perform backoff based on the previously received Restart-= Timer header
> =C2=A0 =C2=A0value before sending out the first request attempt. =C2= =A0Thus, the
> =C2=A0 =C2=A0mechanism spreads all the initial client requests and pre= vents them
> =C2=A0 =C2=A0from overloading the server.
>
> The draft has been presented and discussed in IETF meetings since 2010= , and generated interest among the community:
>
> https://encrypted.google.com/search?as_q=3Ddraft= -shen-soc-avalanche-restart-overload&as_sitesearch=3Dwww.ietf.org%2Fmai= l-archive%2Fweb%2F
>
> I am looking for your kind opinion on what should be the appropriate n= ext step for this document:
>
> -- Should this draft be dispatched to SOC (and their charter amended)?=
> -- Should this draft be processed as AD-sponsored?
> -- Should this draft be killed (if it is harmful)?
>
> Thank you very much.
>
> Charles
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


--089e013d0db06ac0d204f28ac8b1-- From nobody Sun Feb 16 13:17:41 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7EFF1A02D3 for ; Sun, 16 Feb 2014 13:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvaRLSlpE1yQ for ; Sun, 16 Feb 2014 13:17:37 -0800 (PST) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id A2E781A02C1 for ; Sun, 16 Feb 2014 13:17:37 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id ks9so10668318vcb.25 for ; Sun, 16 Feb 2014 13:17:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=crocodilertc.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HXrpONcsVGaBk8/ndk0ivqfH53HmAh+TVqBvqeue5ws=; b=NIQOT113fLURnHR8JaUULbAfsp22+4BQKDCVL2mC3C0juXiNEFJv1vszteOsyHdshy 8AZpaWVKPRW+X6LhxX5ZpmoPimMsEE6Bw/9dj704WY/s2NnSYtqIna8McNwS7rhp/2Re /wEhp3Jhy0iBWayhkfOb2UdY0h2IsCeR/PNKA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HXrpONcsVGaBk8/ndk0ivqfH53HmAh+TVqBvqeue5ws=; b=c/i1lk3e0JfGFJF9QDipepD7wyI2EyImWIt6BskFI8lSH2zM5NeFHGA3wqUf1LYh2C h1RasNHuR3ILI05cV1B2TbCHbhRqrEN2+QKv2CnrHCK0r6b/RCOgBOiaxDMQgA+91TSq 3Cy7PKg8WYIWv2ZnIGZ8aKi9TuZ4161LTV6wtffpGJHC6wtSVa4pcJytGa5he6ZFsePM mlCJ9EXCUgK62Q0UHdSmB21yaF3i/M+Kl/h5UMzI6Ujxs0OlXhjU+jgiSpBCZZzR8hFP 0YQnBjb3NCw+4HfY8xB8wpbnp7zX7A3PmI680o47wznpb4HeiuLXPCcf+PxtX6fVGRB4 W3mg== X-Gm-Message-State: ALoCoQn8OFNXPmkG8b6/qePAmF48j4EbR0F1LTIDtD98E3DIlXB/PbfFD9ybuDOcnlK3oL6nAUhG MIME-Version: 1.0 X-Received: by 10.220.247.68 with SMTP id mb4mr626046vcb.37.1392585455121; Sun, 16 Feb 2014 13:17:35 -0800 (PST) Received: by 10.58.187.114 with HTTP; Sun, 16 Feb 2014 13:17:34 -0800 (PST) In-Reply-To: References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD36A3.1020606@gmail.com> Date: Sun, 16 Feb 2014 21:17:34 +0000 Message-ID: From: Peter Dunkley To: Cullen Jennings Content-Type: multipart/alternative; boundary=089e0122aa5c5f4d7704f28c9158 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/UoNwUTMzP_-fayc18w0mJj38hiY Cc: DISPATCH Subject: Re: [dispatch] I-D Action: draft-pd-dispatch-msrp-websocket-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 21:17:39 -0000 --089e0122aa5c5f4d7704f28c9158 Content-Type: text/plain; charset=ISO-8859-1 I suppose you could have each peer implementing both the WebSocket client and server so that they can both send and handle WebSocket handshakes, but this isn't going to work particularly well when there are NAT devices in between. It certainly won't work for peers that are implemented using Javascript and run in-browser at the moment as the browsers (as far as I know) only implement the WebSocket client. An MSRP relay that is a WebSocket can be used for NAT traversal (in the same way that an ordinary MSRP relay can be) and that is the focus of this draft. In the 3GPP world MSRP is B2B'd through an SBC like device and in that case the peer (which is not a client) could be a WebSocket server - this is something that Christer may be providing language for in the draft. Regards, Peter On 14 February 2014 21:42, Cullen Jennings wrote: > > On Feb 14, 2014, at 8:24 AM, Peter Dunkley > wrote: > > > Because WebSockets is an asynchronous protocol two MSRP peers (that are > clients) cannot use MSRP over WebSockets. > > Just sort of curios, why can't this work? > > > -- Peter Dunkley Technical Director Crocodile RCS Ltd --089e0122aa5c5f4d7704f28c9158 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I suppose you could have each peer implementing both the W= ebSocket client and server so that they can both send and handle WebSocket = handshakes, but this isn't going to work particularly well when there a= re NAT devices in between.  It certainly won't work for peers that= are implemented using Javascript and run in-browser at the moment as the b= rowsers (as far as I know) only implement the WebSocket client.

An MSRP relay that is a WebSocket can be used for NAT traver= sal (in the same way that an ordinary MSRP relay can be) and that is the fo= cus of this draft.  In the 3GPP world MSRP is B2B'd through an SBC= like device and in that case the peer (which is not a client) could be a W= ebSocket server - this is something that Christer may be providing language= for in the draft.

Regards,

Peter


On 14 February 2014 21:42, C= ullen Jennings <fluffy@iii.ca> wrote:

On Feb 14, 2014, at 8:24 AM, Peter Dunkley <peter.dunkley@crocodilertc.net> wrote:

> Because WebSockets is an asynchronous protocol two MSRP peers (that ar= e clients) cannot use MSRP over WebSockets.

Just sort of curios, why can’t this work?





--
Peter Dunkley
<= div>Technical Director
Crocodile RCS Ltd
--089e0122aa5c5f4d7704f28c9158-- From nobody Sun Feb 16 13:23:40 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 547FE1A02C1 for ; Sun, 16 Feb 2014 13:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qg5aofUM4Y6 for ; Sun, 16 Feb 2014 13:23:37 -0800 (PST) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2CE1A02B7 for ; Sun, 16 Feb 2014 13:23:37 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t61so10227155wes.28 for ; Sun, 16 Feb 2014 13:23:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=qeNbhKsHzDjvbqxFQEJZn3pNMkgJ3+fbjacJDEq/tX8=; b=uZQmAmPEPGP3rPYbrspkLld5KyJ8NrvA4vSyrcYkHdppeBSUa2P6GOqyukFECYwHjj sBsIHhXS36ZXXXQAT47GOwOTEAIQ5aSGwzAVDMM0gHXJPpHlGpxaFQ2Yuno+1e3EqWhL sr1joWaSlvWJ+GRRzKY2TzhlsCVxjZXGf/WwZGk2Tsbel7ogXBDgfACPVYRcrk5q8Ui/ /Kv2yqiCpwfCtO0OkGpYo6dtiYjd8chOJEVqOTzKeT3ZFQimY36M2NEYS5LHIKmUBdYE j6+LEzyBkJ2C7RMehcd5tgYnbAUh/XNnM2sR7JmuFl3lg1gsaC0fFIS8ZqQxqqOwTX8q zxFA== X-Received: by 10.181.8.66 with SMTP id di2mr10227554wid.43.1392585814956; Sun, 16 Feb 2014 13:23:34 -0800 (PST) Received: from [192.168.0.192] ([95.61.111.78]) by mx.google.com with ESMTPSA id cm5sm26086926wid.5.2014.02.16.13.23.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Feb 2014 13:23:34 -0800 (PST) Message-ID: <53012C53.1030306@gmail.com> Date: Sun, 16 Feb 2014 22:23:31 +0100 From: Sergio Garcia Murillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20131213005747.777.34301.idtracker@ietfa.amsl.com> <97B47463-42D2-4BA9-AC2F-DF8C67702DDC@cisco.com> <52FCE70C.1030608@gmail.com> <52FD112B.5040209@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/COoIhT1NA7CHFdzo-cSgF1H91Jo Subject: Re: [dispatch] X over websockets X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Feb 2014 21:23:39 -0000 El 14/02/2014 22:38, Cullen Jennings escribió: > This really screams for a common framework that guides how to write a > spec for X over web sockets or data channels. Agree, that was my point from the beginning. I am willing to collaborate in writing that framework. Best regards Sergio From nobody Sun Feb 16 21:49:04 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A78C1A035E for ; Sun, 16 Feb 2014 21:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.049 X-Spam-Level: X-Spam-Status: No, score=-115.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kiGJ5YQyuz0u for ; Sun, 16 Feb 2014 21:49:01 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 18B901A035C for ; Sun, 16 Feb 2014 21:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3296; q=dns/txt; s=iport; t=1392616139; x=1393825739; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hpvKDx+FVn+3uY+BEOTfI5zIyT43vcxNPPiHDwEgV/E=; b=G/hU8JdVAo4g975l3mE6Ujjjmkkdp8sbO7TNjHSwcpNVbeT41gg4+wG/ SonqFbKXzLjgoQSCcnDmoNa+/fW/sRfw4QBa3z8Cz07NVpwkecwpIXcvC wBu8BUQkj9BZJ9BFSiqmiZBCJjRZ3KGSF0DUjf+RQMHZCJZy3MskP85nY c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAKehAVOtJXG8/2dsb2JhbABZDoJ4OFe+ak+BFBZ0giUBAQEDAQEBAWsLBQsCAQgYDCInCyUCBA4FFIdpCA3LAxeOMxszB4MkgRQEmCyBMpBxgm4/gio X-IronPort-AV: E=Sophos;i="4.95,858,1384300800"; d="scan'208";a="304544636" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-6.cisco.com with ESMTP; 17 Feb 2014 05:48:58 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1H5mwKQ013759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Feb 2014 05:48:58 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.105]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Sun, 16 Feb 2014 23:48:57 -0600 From: "Cullen Jennings (fluffy)" To: Charles Shen Thread-Topic: [dispatch] draft-shen-soc-avalanche-restart-overload Thread-Index: AQHPKqahBkj4OIFP6USMZv7/Bsbi+Zq4pIIAgACyuAA= Date: Mon, 17 Feb 2014 05:48:57 +0000 Message-ID: <6012C83D-7E53-4DEC-BAA1-76AA68819672@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.247.16] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/6EKfNXrO9UXF3NYlfm1zBV16SzU Cc: DISPATCH Subject: Re: [dispatch] draft-shen-soc-avalanche-restart-overload X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 05:49:03 -0000 So the terminology for this is always a bit confusing. The Milestones are n= ot typically considered part of the charter but if the WG wanted to do this= work, they could add a Milestone without changing a charter. The question = is does the Charter text cover this type of work. On Feb 17, 2014, at 3:09 AM, Charles Shen wrote: > Thanks Cullen for your comments,=20 >=20 > According to my understanding, the current charter description=20 >=20 > http://datatracker.ietf.org/wg/soc/charter/ >=20 > does not seem to cover the goal of advancing this draft into a working gr= oup deliverable. Please correct me if I were wrong.=20 >=20 > Thanks >=20 > Charles >=20 >=20 >=20 >=20 > On Sat, Feb 15, 2014 at 6:35 PM, Cullen Jennings (fluffy) wrote: >=20 > This seems like a draft that could benefit from review in a WG. Can someo= ne fill in a bit of the background of this draft in SOC. I=92m not seeing w= hy the SOC charter would need to be changed to do this work. >=20 >=20 >=20 > On Feb 11, 2014, at 1:35 PM, Charles Shen wrote= : >=20 > > Dear all: > > > > As advised by Richard Barnes, I am writing to seek opinion from you abo= ut this draft: > > > > http://datatracker.ietf.org/doc/draft-shen-soc-avalanche-restart-overlo= ad/ > > A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart Ove= rload Control > > > > Abstract: > > When a large number of clients register with a SIP registrar server > > at approximately the same time, the server may become overloaded. > > Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests may > > have similar effects. Such request avalanches can occur, for > > example, after a power failure and recovery in a metropolitan area. > > This document describes how to avoid such overload situations. Unde= r > > this mechanism, a server estimates an avalanche restart backoff > > interval during its normal operation and conveys this interval to it= s > > clients through a new Restart-Timer header in normal response > > messages. Once an avalanche restart actually occurs, the clients > > perform backoff based on the previously received Restart-Timer heade= r > > value before sending out the first request attempt. Thus, the > > mechanism spreads all the initial client requests and prevents them > > from overloading the server. > > > > The draft has been presented and discussed in IETF meetings since 2010,= and generated interest among the community: > > > > https://encrypted.google.com/search?as_q=3Ddraft-shen-soc-avalanche-res= tart-overload&as_sitesearch=3Dwww.ietf.org%2Fmail-archive%2Fweb%2F > > > > I am looking for your kind opinion on what should be the appropriate ne= xt step for this document: > > > > -- Should this draft be dispatched to SOC (and their charter amended)? > > -- Should this draft be processed as AD-sponsored? > > -- Should this draft be killed (if it is harmful)? > > > > Thank you very much. > > > > Charles > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 From nobody Mon Feb 17 08:06:01 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21121A03F9 for ; Mon, 17 Feb 2014 08:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKf8jAPn9wnP for ; Mon, 17 Feb 2014 08:05:55 -0800 (PST) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id B90FB1A025F for ; Mon, 17 Feb 2014 08:05:55 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id m1so17732714oag.6 for ; Mon, 17 Feb 2014 08:05:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=8ZP7IRgfF5xQKm7Df/o3Os6hm1328j7IfIUiYbIKgY8=; b=PRHmVduyCvrcdBWCqlQiYPCO40sRHLOMqddelsqr9lPdhO8gL8q+O74/XiWBqFdjyx rOVdaXEjJM5TKrDTuPvqzPO/2nTmdBKv0eCoHjezFuB7L7yP4IRF3H7eky5HIdFo2fZR AS+L9Fen1G7OMesnjs+4NmZDfy1ib+JxbEcE0ifWhlsX+NYNF2Sh6Qc8RnuKyip10/h/ Q88ape7A5Miich8E8dlTRXdsnAtwbP+7k8D3peKwheXLAxSK3iucgPjXi/+LHMdB2x2/ afxPchCgq3NeEYJKL93paEfxWZCmOauD8YTkHwf3GzrNHBPKlXmUkkqPcfhSCW5SWP8E N8HA== X-Received: by 10.60.68.33 with SMTP id s1mr1267036oet.74.1392653153059; Mon, 17 Feb 2014 08:05:53 -0800 (PST) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.55.106 with HTTP; Mon, 17 Feb 2014 08:05:32 -0800 (PST) In-Reply-To: <6012C83D-7E53-4DEC-BAA1-76AA68819672@cisco.com> References: <6012C83D-7E53-4DEC-BAA1-76AA68819672@cisco.com> From: Charles Shen Date: Mon, 17 Feb 2014 11:05:32 -0500 X-Google-Sender-Auth: 36g404vPpZgCj_ouWmqvbOF-a90 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=001a113307527bcabf04f29c544e Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/oKfbn43rphIFd5YUBh59liMJ2vk Cc: DISPATCH Subject: Re: [dispatch] draft-shen-soc-avalanche-restart-overload X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 16:06:00 -0000 --001a113307527bcabf04f29c544e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If that is the case, I at least don't see the current charter excluding the scope of this work from the sentence "The objective of the working group is to develop mechanisms for SIP overload control. The problem domain of SIP overload control can be split into overload control between a user agent and a SIP server and overload control between SIP servers.", as this work fits nicely into the "overload control between a user agent and a SIP server" problem domain. On Mon, Feb 17, 2014 at 12:48 AM, Cullen Jennings (fluffy) wrote: > > So the terminology for this is always a bit confusing. The Milestones are > not typically considered part of the charter but if the WG wanted to do > this work, they could add a Milestone without changing a charter. The > question is does the Charter text cover this type of work. > > > On Feb 17, 2014, at 3:09 AM, Charles Shen wrote= : > > > Thanks Cullen for your comments, > > > > According to my understanding, the current charter description > > > > http://datatracker.ietf.org/wg/soc/charter/ > > > > does not seem to cover the goal of advancing this draft into a working > group deliverable. Please correct me if I were wrong. > > > > Thanks > > > > Charles > > > > > > > > > > On Sat, Feb 15, 2014 at 6:35 PM, Cullen Jennings (fluffy) < > fluffy@cisco.com> wrote: > > > > This seems like a draft that could benefit from review in a WG. Can > someone fill in a bit of the background of this draft in SOC. I=E2=80=99m= not > seeing why the SOC charter would need to be changed to do this work. > > > > > > > > On Feb 11, 2014, at 1:35 PM, Charles Shen > wrote: > > > > > Dear all: > > > > > > As advised by Richard Barnes, I am writing to seek opinion from you > about this draft: > > > > > > > http://datatracker.ietf.org/doc/draft-shen-soc-avalanche-restart-overload= / > > > A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart > Overload Control > > > > > > Abstract: > > > When a large number of clients register with a SIP registrar serve= r > > > at approximately the same time, the server may become overloaded. > > > Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests may > > > have similar effects. Such request avalanches can occur, for > > > example, after a power failure and recovery in a metropolitan area= . > > > This document describes how to avoid such overload situations. > Under > > > this mechanism, a server estimates an avalanche restart backoff > > > interval during its normal operation and conveys this interval to > its > > > clients through a new Restart-Timer header in normal response > > > messages. Once an avalanche restart actually occurs, the clients > > > perform backoff based on the previously received Restart-Timer > header > > > value before sending out the first request attempt. Thus, the > > > mechanism spreads all the initial client requests and prevents the= m > > > from overloading the server. > > > > > > The draft has been presented and discussed in IETF meetings since > 2010, and generated interest among the community: > > > > > > > https://encrypted.google.com/search?as_q=3Ddraft-shen-soc-avalanche-resta= rt-overload&as_sitesearch=3Dwww.ietf.org%2Fmail-archive%2Fweb%2F > > > > > > I am looking for your kind opinion on what should be the appropriate > next step for this document: > > > > > > -- Should this draft be dispatched to SOC (and their charter amended)= ? > > > -- Should this draft be processed as AD-sponsored? > > > -- Should this draft be killed (if it is harmful)? > > > > > > Thank you very much. > > > > > > Charles > > > > > > > > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > --001a113307527bcabf04f29c544e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If that is the case, I at least don't see the current charter = excluding the scope of this work from the sentence "The objective of t= he working group is to develop mechanisms for SIP=C2=A0overload control. T= he problem domain of SIP overload control can be=C2=A0split into overload co= ntrol between a user agent and a SIP server and=C2=A0overload control betwee= n SIP servers.", as this work fits nicely into the "overload cont= rol between a user agent and a SIP server" problem domain.=C2=A0


On Mon, Feb 1= 7, 2014 at 12:48 AM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

So the terminology for this is always a bit confusing. The Milestones are n= ot typically considered part of the charter but if the WG wanted to do this= work, they could add a Milestone without changing a charter. The question = is does the Charter text cover this type of work.


On Feb 17, 2014, at 3:09 AM, Charles Shen <charles@cs.columbia.edu> wrote:

> Thanks Cullen for your comments,
>
> According to my understanding, the current charter description
>
> http://datatracker.ietf.org/wg/soc/charter/
>
> does not seem to cover the goal of advancing this draft into a working= group deliverable. Please correct me if I were wrong.
>
> Thanks
>
> Charles
>
>
>
>
> On Sat, Feb 15, 2014 at 6:35 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:
>
> This seems like a draft that could benefit from review in a WG. Can so= meone fill in a bit of the background of this draft in SOC. I=E2=80=99m not= seeing why the SOC charter would need to be changed to do this work.
>
>
>
> On Feb 11, 2014, at 1:35 PM, Charles Shen <charles@cs.columbia.edu> wrote:
>
> > Dear all:
> >
> > As advised by Richard Barnes, I am writing to seek opinion from y= ou about this draft:
> >
> > http://datatracker.ietf.org/doc/dra= ft-shen-soc-avalanche-restart-overload/
> > A Mechanism for Session Initiation Protocol (SIP) Avalanche Resta= rt Overload Control
> >
> > Abstract:
> > =C2=A0 =C2=A0When a large number of clients register with a SIP r= egistrar server
> > =C2=A0 =C2=A0at approximately the same time, the server may becom= e overloaded.
> > =C2=A0 =C2=A0Near-simultaneous floods of SIP SUBSCRIBE and PUBLIS= H requests may
> > =C2=A0 =C2=A0have similar effects. =C2=A0Such request avalanches = can occur, for
> > =C2=A0 =C2=A0example, after a power failure and recovery in a met= ropolitan area.
> > =C2=A0 =C2=A0This document describes how to avoid such overload s= ituations. =C2=A0Under
> > =C2=A0 =C2=A0this mechanism, a server estimates an avalanche rest= art backoff
> > =C2=A0 =C2=A0interval during its normal operation and conveys thi= s interval to its
> > =C2=A0 =C2=A0clients through a new Restart-Timer header in normal= response
> > =C2=A0 =C2=A0messages. =C2=A0Once an avalanche restart actually o= ccurs, the clients
> > =C2=A0 =C2=A0perform backoff based on the previously received Res= tart-Timer header
> > =C2=A0 =C2=A0value before sending out the first request attempt. = =C2=A0Thus, the
> > =C2=A0 =C2=A0mechanism spreads all the initial client requests an= d prevents them
> > =C2=A0 =C2=A0from overloading the server.
> >
> > The draft has been presented and discussed in IETF meetings since= 2010, and generated interest among the community:
> >
> > https://encrypted.google.com/search?as_q=3D= draft-shen-soc-avalanche-restart-overload&as_sitesearch=3Dwww.ietf.org%= 2Fmail-archive%2Fweb%2F
> >
> > I am looking for your kind opinion on what should be the appropri= ate next step for this document:
> >
> > -- Should this draft be dispatched to SOC (and their charter amen= ded)?
> > -- Should this draft be processed as AD-sponsored?
> > -- Should this draft be killed (if it is harmful)?
> >
> > Thank you very much.
> >
> > Charles
> >
> >
> >
> > _______________________________________________
> > dispatch mailing list
> > dispatch@ietf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
>
>
--001a113307527bcabf04f29c544e-- From nobody Mon Feb 17 08:14:42 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689C01A0228 for ; Mon, 17 Feb 2014 08:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlEysADcX622 for ; Mon, 17 Feb 2014 08:14:38 -0800 (PST) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by ietfa.amsl.com (Postfix) with ESMTP id 45A911A025F for ; Mon, 17 Feb 2014 08:14:33 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id wo20so17320877obc.28 for ; Mon, 17 Feb 2014 08:14:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vVmcGTUFTZioQyBYxMeT88Mx6ev7DVy1ocigesnif6A=; b=JO4HvpKgX1hxAyzNDOtnrWWxjQU4ON1Nd9Tz5BuOV+YHz4ijKvWClupYdAAzUTMfj3 34UkRx33yKtUyJG2u3/kjDiQJpTX79Yh0zDGpw4n59AjSu9nPlaIh6pCm8pRx0vF+mEu lHJxT/8CG7EElqxVyUmQGPtzUh64v6tmLKosiZ/cP/sNNxOezI0hWU3tQQgajh52/Ppy LpYUW2t0DTNJRU+UEEhXCVotw1wEY/T2PYfPmlAxZJDNU9DDG3NgKdtm2FDXNVx0O785 YUNxJk+rCwxKkYcWJD8cVoRpw6EYEdKbdyMbva0GaUiAYNxOasqglwQDEw1M9pU8WfNS f06A== X-Gm-Message-State: ALoCoQmecrBEIDpZ5DMAOBkJgas6zabueeIQZ+E849Zu8j0I3tuCEjvoRqCRlGNDOI9rXf4Le5lB MIME-Version: 1.0 X-Received: by 10.182.160.102 with SMTP id xj6mr21782172obb.19.1392653670476; Mon, 17 Feb 2014 08:14:30 -0800 (PST) Received: by 10.60.69.102 with HTTP; Mon, 17 Feb 2014 08:14:30 -0800 (PST) In-Reply-To: References: <6012C83D-7E53-4DEC-BAA1-76AA68819672@cisco.com> Date: Mon, 17 Feb 2014 11:14:30 -0500 Message-ID: From: Richard Barnes To: Charles Shen Content-Type: multipart/alternative; boundary=bcaec5396c1653020004f29c7310 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/vJlbGiVwgYtsfgvgklekmWSRo3k Cc: "Cullen Jennings \(fluffy\)" , DISPATCH Subject: Re: [dispatch] draft-shen-soc-avalanche-restart-overload X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Feb 2014 16:14:41 -0000 --bcaec5396c1653020004f29c7310 Content-Type: text/plain; charset=ISO-8859-1 I agree that the charter could be read to include this document. We should confirm that the WG agrees, and is willing to take on the document. Charles, could you please start a thread on the SOC list? Thanks, --Richard On Mon, Feb 17, 2014 at 11:05 AM, Charles Shen wrote: > If that is the case, I at least don't see the current charter excluding > the scope of this work from the sentence "The objective of the working > group is to develop mechanisms for SIP overload control. The problem > domain of SIP overload control can be split into overload control between > a user agent and a SIP server and overload control between SIP servers.", > as this work fits nicely into the "overload control between a user agent > and a SIP server" problem domain. > > > > On Mon, Feb 17, 2014 at 12:48 AM, Cullen Jennings (fluffy) < > fluffy@cisco.com> wrote: > >> >> So the terminology for this is always a bit confusing. The Milestones are >> not typically considered part of the charter but if the WG wanted to do >> this work, they could add a Milestone without changing a charter. The >> question is does the Charter text cover this type of work. >> >> >> On Feb 17, 2014, at 3:09 AM, Charles Shen >> wrote: >> >> > Thanks Cullen for your comments, >> > >> > According to my understanding, the current charter description >> > >> > http://datatracker.ietf.org/wg/soc/charter/ >> > >> > does not seem to cover the goal of advancing this draft into a working >> group deliverable. Please correct me if I were wrong. >> > >> > Thanks >> > >> > Charles >> > >> > >> > >> > >> > On Sat, Feb 15, 2014 at 6:35 PM, Cullen Jennings (fluffy) < >> fluffy@cisco.com> wrote: >> > >> > This seems like a draft that could benefit from review in a WG. Can >> someone fill in a bit of the background of this draft in SOC. I'm not >> seeing why the SOC charter would need to be changed to do this work. >> > >> > >> > >> > On Feb 11, 2014, at 1:35 PM, Charles Shen >> wrote: >> > >> > > Dear all: >> > > >> > > As advised by Richard Barnes, I am writing to seek opinion from you >> about this draft: >> > > >> > > >> http://datatracker.ietf.org/doc/draft-shen-soc-avalanche-restart-overload/ >> > > A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart >> Overload Control >> > > >> > > Abstract: >> > > When a large number of clients register with a SIP registrar server >> > > at approximately the same time, the server may become overloaded. >> > > Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests may >> > > have similar effects. Such request avalanches can occur, for >> > > example, after a power failure and recovery in a metropolitan area. >> > > This document describes how to avoid such overload situations. >> Under >> > > this mechanism, a server estimates an avalanche restart backoff >> > > interval during its normal operation and conveys this interval to >> its >> > > clients through a new Restart-Timer header in normal response >> > > messages. Once an avalanche restart actually occurs, the clients >> > > perform backoff based on the previously received Restart-Timer >> header >> > > value before sending out the first request attempt. Thus, the >> > > mechanism spreads all the initial client requests and prevents them >> > > from overloading the server. >> > > >> > > The draft has been presented and discussed in IETF meetings since >> 2010, and generated interest among the community: >> > > >> > > >> https://encrypted.google.com/search?as_q=draft-shen-soc-avalanche-restart-overload&as_sitesearch=www.ietf.org%2Fmail-archive%2Fweb%2F >> > > >> > > I am looking for your kind opinion on what should be the appropriate >> next step for this document: >> > > >> > > -- Should this draft be dispatched to SOC (and their charter amended)? >> > > -- Should this draft be processed as AD-sponsored? >> > > -- Should this draft be killed (if it is harmful)? >> > > >> > > Thank you very much. >> > > >> > > Charles >> > > >> > > >> > > >> > > _______________________________________________ >> > > dispatch mailing list >> > > dispatch@ietf.org >> > > https://www.ietf.org/mailman/listinfo/dispatch >> > >> > >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --bcaec5396c1653020004f29c7310 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree that the charter could be read to include this doc= ument.  We should confirm that the WG agrees, and is willing to take o= n the document.

Charles, could you please start a thread= on the SOC list?

Thanks,
--Richard


On Mon, Feb 17, 2014 at 11:05= AM, Charles Shen <charles@cs.columbia.edu> wrote:
If that is the case, I at least don't see the cu= rrent charter excluding the scope of this work from the sentence "The = objective of the working group is to develop mechanisms for SIP overload control. The pr= oblem domain of SIP overload control can be split into overload control between a user a= gent and a SIP server and overload control between SIP servers.", as this work fits= nicely into the "overload control between a user agent and a SIP serv= er" problem domain. 



On Mon, Feb 1= 7, 2014 at 12:48 AM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

So the terminology for this is always a bit confusing. The Milestones are n= ot typically considered part of the charter but if the WG wanted to do this= work, they could add a Milestone without changing a charter. The question = is does the Charter text cover this type of work.


On Feb 17, 2014, at 3:09 AM, Charles Shen <charles@cs.columbia.edu> wrote:

> Thanks Cullen for your comments,
>
> According to my understanding, the current charter description
>
> http://datatracker.ietf.org/wg/soc/charter/
>
> does not seem to cover the goal of advancing this draft into a working= group deliverable. Please correct me if I were wrong.
>
> Thanks
>
> Charles
>
>
>
>
> On Sat, Feb 15, 2014 at 6:35 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wro= te:
>
> This seems like a draft that could benefit from review in a WG. Can so= meone fill in a bit of the background of this draft in SOC. I’m not s= eeing why the SOC charter would need to be changed to do this work.
>
>
>
> On Feb 11, 2014, at 1:35 PM, Charles Shen <charles@cs.columbia.edu> wrote:=
>
> > Dear all:
> >
> > As advised by Richard Barnes, I am writing to seek opinion from y= ou about this draft:
> >
> > http://datatracker.ietf.org/doc/dra= ft-shen-soc-avalanche-restart-overload/
> > A Mechanism for Session Initiation Protocol (SIP) Avalanche Resta= rt Overload Control
> >
> > Abstract:
> >    When a large number of clients register with a SIP r= egistrar server
> >    at approximately the same time, the server may becom= e overloaded.
> >    Near-simultaneous floods of SIP SUBSCRIBE and PUBLIS= H requests may
> >    have similar effects.  Such request avalanches = can occur, for
> >    example, after a power failure and recovery in a met= ropolitan area.
> >    This document describes how to avoid such overload s= ituations.  Under
> >    this mechanism, a server estimates an avalanche rest= art backoff
> >    interval during its normal operation and conveys thi= s interval to its
> >    clients through a new Restart-Timer header in normal= response
> >    messages.  Once an avalanche restart actually o= ccurs, the clients
> >    perform backoff based on the previously received Res= tart-Timer header
> >    value before sending out the first request attempt. =  Thus, the
> >    mechanism spreads all the initial client requests an= d prevents them
> >    from overloading the server.
> >
> > The draft has been presented and discussed in IETF meetings since= 2010, and generated interest among the community:
> >
> > https://encrypted.google.com/search?as_q=3D= draft-shen-soc-avalanche-restart-overload&as_sitesearch=3Dwww.ietf.org%= 2Fmail-archive%2Fweb%2F
> >
> > I am looking for your kind opinion on what should be the appropri= ate next step for this document:
> >
> > -- Should this draft be dispatched to SOC (and their charter amen= ded)?
> > -- Should this draft be processed as AD-sponsored?
> > -- Should this draft be killed (if it is harmful)?
> >
> > Thank you very much.
> >
> > Charles
> >
> >
> >
> > _______________________________________________
> > dispatch mailing list
> > dispatch@i= etf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
>
>

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


--bcaec5396c1653020004f29c7310-- From nobody Tue Feb 18 06:59:14 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC6F1A064A for ; Tue, 18 Feb 2014 06:59:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.712 X-Spam-Level: X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvUcVjNTAXcB for ; Tue, 18 Feb 2014 06:59:10 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBA21A0514 for ; Tue, 18 Feb 2014 06:59:09 -0800 (PST) Received: by mail-yk0-f177.google.com with SMTP id q200so33597793ykb.8 for ; Tue, 18 Feb 2014 06:59:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fOAnA0mBXkqyOqn9VZGa6eI1NIBOa8+EfzUYsbBBOWc=; b=cDehz2ecaUBFE61F/4FJZhdp58jRLMmfTAEzTwaXHPTTwiKl06hZakKoQ3aS/VpiRc hV4EfS78wBbXnbEPhAckuUrwi94E7LQEZdROZqxxYLVpxjbLQOAkyrq7Fxr09dnnN42U G2no401thp6zk1zkGDp+SBHwpJwwD4Rn7Bsyk/JaCHNqJOfkJ94Jam4bGv2WV/7yvj4G z5ByciPwymkjGSbfCtaAsbjtH6aWhOzMXaEmEC/B/fwrIH4rHuReuqcT8cK7gnGdw4FB W5178rDbwQ28crr5q4c+b9cIz0i/aDVlnzjte9TrIOtvllQOCqWEpNYEAcjX1E7h0qae 8iJw== MIME-Version: 1.0 X-Received: by 10.236.101.227 with SMTP id b63mr29429657yhg.37.1392735546942; Tue, 18 Feb 2014 06:59:06 -0800 (PST) Received: by 10.170.213.85 with HTTP; Tue, 18 Feb 2014 06:59:06 -0800 (PST) In-Reply-To: <20140213133608.31245.qmail@f5mail-224-149.rediffmail.com> References: <20140213133608.31245.qmail@f5mail-224-149.rediffmail.com> Date: Tue, 18 Feb 2014 08:59:06 -0600 Message-ID: From: Mary Barnes To: sunil kumar sinha Content-Type: multipart/alternative; boundary=20cf300e51e58aa9da04f2af835d Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/dQ_v6LMBP1yZnJQBXriTG6aqTOg Cc: DISPATCH Subject: Re: [dispatch] SIP INVITE server transaction X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2014 14:59:12 -0000 --20cf300e51e58aa9da04f2af835d Content-Type: text/plain; charset=ISO-8859-1 This question is more appropriate for the sip-implementors mailing list or even the SIP Forum discussions list: https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors http://www.sipforum.org/content/view/41/165/ (discussion@sipforum.org) Thanks, Mary DISPATCH WG co-chair On Thu, Feb 13, 2014 at 7:36 AM, sunil kumar sinha < sunilkumarsinha9@rediffmail.com> wrote: > Hi, > > SIP INVITE client transaction can retransmit INVITE seven times in case of > unreliable transport before it gets timeout. > > My queries as below > 1.)Does SIP INVITE server transaction also retransmit INVITE? > 2.)If yes, then please share some detail on it. > > Thanks & Regard > sunil > > > > > > Get your own *FREE* website, *FREE* domain & *FREE* mobile app with > Company email. > *Know More >* > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --20cf300e51e58aa9da04f2af835d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This question is more appropriate for the sip-implementors= mailing list or even the SIP Forum discussions list: =A0

Thanks,
Mary
DISPATCH WG co-chair


On Thu, Feb 13, 2014 at= 7:36 AM, sunil kumar sinha <sunilkumarsinha9@rediffmail.com= > wrote:
Hi,

SIP INVITE client transaction can retransmit INVITE seven times in case of = unreliable transport before it gets timeout.

My queries as below
1.)Does SIP INVITE server transaction also retransmit INVITE?
2.)If yes, then please share some detail on it.

Thanks & Regard
sunil



=
Ge= t your own FREE website, FREE domain & FREE mobile app with Company email. =A0
Know More >

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


--20cf300e51e58aa9da04f2af835d-- From nobody Fri Feb 28 15:11:04 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB451A0319 for ; Fri, 28 Feb 2014 15:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.334 X-Spam-Level: *** X-Spam-Status: No, score=3.334 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MANGLED_SEX=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QT85sLEE_iLe for ; Fri, 28 Feb 2014 15:10:56 -0800 (PST) Received: from oproxy18-pub.mail.unifiedlayer.com (oproxy18-pub.mail.unifiedlayer.com [69.89.17.20]) by ietfa.amsl.com (Postfix) with SMTP id DE0A01A0234 for ; Fri, 28 Feb 2014 15:10:55 -0800 (PST) Received: (qmail 1052 invoked by uid 0); 28 Feb 2014 23:10:49 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy18.mail.unifiedlayer.com with SMTP; 28 Feb 2014 23:10:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=3eyQ3ym6mXyypnZpvti/JXlydqKeHj7xMmGQ2FnWKbo=; b=Vgx5P+U4zRbtQsR7cl24Sf8bFlOLnImpNWxyIzGZXsfyGiIqsEZ5d2rz6RuTLzdRmJUiFzVEuUeIKtggqz+4VPvYBUVuEgGF6ID9tCkpMJHmpWjchmxZgPGamvKtvDOK; Received: from [173.79.179.104] (port=56830 helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1WJWZr-0008V7-Pi; Fri, 28 Feb 2014 16:10:48 -0700 From: "Richard Shockey" To: "'DISPATCH'" , Date: Fri, 28 Feb 2014 18:10:42 -0500 Message-ID: <017b01cf34da$500ce150$f026a3f0$@shockey.us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_017C_01CF34B0.673838E0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac802k0Gd98OqLUvSE25OZzCcu0cnA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.79.179.104 authed with richard@shockey.us} Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/_Sq-UEOkG2z6tLqeOjSoJFZbSL4 Subject: [dispatch] FYI ... if you might be in the DC area in late March... X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2014 23:11:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_017C_01CF34B0.673838E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit DA 14-290 Released: February 28, 2014 FCC CHIEF TECHNOLOGIST TO HOST NUMBERING TESTBED WORKSHOP WC Docket No. 13-97 On Tuesday, March 25, 2014, the Commission's Chief Technology Officer (CTO) will host an all-day workshop to facilitate the design and development of a Numbering Testbed. As announced in the Technology Transitions Order, the goal of the Numbering Testbed is to convene a community and provide common resources to enable research into numbering in an all-IP network, unencumbered by the constraints of the legacy network and technologies and ensuring that there is no disruption to them.1 The Numbering Testbed will operate under the auspices of the North American Numbering Council (NANC), which will provide a report to the Commission describing the testbed activities and making recommendations.2 The workshop will be an engineering working session, modeled after Internet Engineering Task Force (IETF) "birds-of-feather" sessions and "hackathons" in which groups of technical experts collaborate intensively to work through technical challenges and create prototype systems. The workshop will focus on the basic design and launch of the Testbed as a non-production, prototype system for managing numbering resources and obtaining information about these resources in a post-transitions world. This workshop has three objectives: (1) to identify gaps in the existing number assignment and management systems that may arise during or after transition to an all-IP environment and opportunities for simplification; (2) to discuss proposals for a general architecture for the Testbed and the numbering related issues it should address; and (3) to facilitate administration and organization (mailing list, conference calls) for those individuals who are interested in doing the prototyping and participating further in the Testbed process.3 Subsequent engineering workshops may be convened, as needed, to assist participants in refining the Testbed and in further exploring the many technical questions raised by an all-IP, post transitions numbering management system. 1 See Technology Transitions et al., GN Docket No. 13-5 et al., Order, Report and Order and Further Notice of Proposed Rulemaking, Report and Order, Order and Further Notice of Proposed Rulemaking, Proposal for Ongoing Data Initiative, FCC 14-5, para. 152 (rel. Jan. 31, 2014) (Technology Transitions Order) (delegating authority to "facilitate the development of a telephony numbering testbed for collaborative, multi-stakeholder research and exploration of technical options and opportunities for telephone numbering in an all-IP network"). Developing ideas in a testbed avoids disrupting current systems and allows interested parties to work through technical feasibility constraints to allow for the broadest range of policy options and outcomes. Id. 2 See id. at para. 168 (encouraging the CTO to collaborate with experts within the Commission, the NANC and other Commission advisory committees, industry standards organizations, academic institutions, and others with numbering management expertise). 3 See id. at para. 167. 2 Participation is open to any and all technical experts. We particularly welcome software and network engineers with experience implementing telephony-related systems and contributing to numbering or naming-related standards. Additional details concerning the workshop agenda will be forthcoming. Attendance. The workshop is open to the public, and will be held at FCC Headquarters, located at 445 12th Street, SW, Washington, DC 20554. All attendees are advised to arrive approximately 30 minutes prior to the start of the workshop to allow time to go through our security process. Attendees are encouraged to pre-register by submitting their name and affiliation via email to Robert Cannon (Robert.Cannon@fcc.gov) in order to expedite the check-in process the day of the event. Please use "Numbering Testbed Workshop" as the subject line in your email. Ex Parte Rules. This proceeding has been designated as a "permit-but-disclose" proceeding in accordance with the Commission's ex parte rules. The meeting site is fully accessible to people using wheelchairs or other mobility aids. Reasonable accommodations for people with disabilities are available upon request. Include a description of the accommodation you will need and tell us how to contact you if we need more information. Make your request as early as possible. Last minute requests will be accepted, but may be impossible to fill. Send an email to: fcc504@fcc.gov or call the Consumer & Governmental Affairs Bureau at 202-418-0530 (voice), 202-418-0432 (tty). Contact: Robert Cannon, Office of Strategic Planning and Policy Analysis, Robert.Cannon@fcc.gov, (202) 418-2421. -FCC Richard Shockey Shockey Consulting LLC http://www.shockey.us Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http://www.sipforum.org "Money is the answer, what is the question?" tm ------=_NextPart_000_017C_01CF34B0.673838E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

DA 14-290

Released: = February 28, 2014

FCC CHIEF = TECHNOLOGIST TO HOST

NUMBERING = TESTBED WORKSHOP

WC Docket No. = 13-97

 

On Tuesday, March 25, 2014, the Commission’s = Chief Technology Officer (CTO) will host an

all-day workshop to facilitate the design and = development of a Numbering Testbed. As announced in the

Technology Transitions Order, the goal of the = Numbering Testbed is to convene a community and

provide common resources to enable research into = numbering in an all-IP network, unencumbered by the

constraints of the legacy network and technologies and = ensuring that there is no disruption to them.1 The

Numbering Testbed will operate under the auspices of = the North American Numbering Council (NANC),

which will provide a report to the Commission = describing the testbed activities and making

recommendations.2

 

The workshop = will be an engineering working session, modeled after Internet = Engineering Task

Force (IETF) = “birds-of-feather” sessions and “hackathons” in = which groups of technical experts

collaborate intensively to work through technical = challenges and create prototype systems. The workshop

will focus on the basic design and launch of the = Testbed as a non-production, prototype system for

managing numbering resources and obtaining information = about these resources in a post-transitions

world. This workshop has three objectives: (1) to = identify gaps in the existing number assignment and

management systems that may arise during or after = transition to an all-IP environment and opportunities

for simplification; (2) to discuss proposals for a = general architecture for the Testbed and the numbering = related

issues it should address; and = (3) to facilitate administration and organization (mailing = list,

conference calls) for those = individuals who are interested in doing the prototyping and = participating

further in the Testbed = process.3

 

Subsequent engineering workshops may be convened, as = needed, to assist participants in refining

the Testbed and in further exploring the many = technical questions raised by an all-IP, post = transitions

numbering management = system.

 

1 See Technology Transitions et al., GN Docket No. = 13-5 et al., Order, Report and Order and Further Notice = of

Proposed Rulemaking, Report and = Order, Order and Further Notice of Proposed Rulemaking, Proposal for = Ongoing

Data Initiative, FCC 14-5, = para. 152 (rel. Jan. 31, 2014) (Technology Transitions Order) = (delegating authority to

“facilitate the development of a telephony = numbering testbed for collaborative, multi-stakeholder research = and

exploration of technical options = and opportunities for telephone numbering in an all-IP network”). = Developing ideas

in a testbed avoids = disrupting current systems and allows interested parties to work through = technical feasibility

constraints to = allow for the broadest range of policy options and outcomes. = Id.

 

2 See id. at para. 168 (encouraging the CTO to = collaborate with experts within the Commission, the NANC and = other

Commission advisory committees, = industry standards organizations, academic institutions, and others = with

numbering management = expertise).

3 See id. at para. = 167.

2

Participation is open to any and all technical = experts. We particularly welcome software and

network engineers with experience implementing = telephony-related systems and contributing to

numbering or naming-related standards. Additional = details concerning the workshop agenda will be

forthcoming.

 

Attendance. = The workshop is open to the public, and will be held at FCC = Headquarters, located

at 445 12th = Street, SW, Washington, DC 20554. All attendees are advised to arrive = approximately 30

minutes prior to the = start of the workshop to allow time to go through our security process. = Attendees are

encouraged to = pre-register by submitting their name and affiliation via email to = Robert Cannon

(Robert.Cannon@fcc.gov) = in order to expedite the check-in process the day of the event. Please = use

“Numbering Testbed = Workshop” as the subject line in your email.

 

Ex Parte = Rules. This proceeding has been designated as a = “permit-but-disclose” proceeding in

accordance with the Commission’s ex parte = rules.

The meeting site is fully = accessible to people using wheelchairs or other = mobility

aids. Reasonable = accommodations for people with disabilities are available upon request. = Include a

description of the = accommodation you will need and tell us how to contact you if we need = more

information. Make your request = as early as possible. Last minute requests will be accepted, but may = be

impossible to fill. Send an email = to: fcc504@fcc.gov or call the Consumer & Governmental = Affairs

Bureau at 202-418-0530 = (voice), 202-418-0432 (tty).

 

Contact: = Robert Cannon, Office of Strategic Planning and Policy = Analysis,

Robert.Cannon@fcc.gov, = (202) 418-2421.

-FCC

 

Richard = Shockey
Shockey Consulting LLC

http://www.shockey.us
Chairman of the Board of = Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype= -linkedin-facebook: = rshockey101
http://www.sipforum.org

"Money is the answer, what is the question?" = tm

 

 

------=_NextPart_000_017C_01CF34B0.673838E0--