From HKaplan@acmepacket.com Thu Jul 1 01:46:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CB773A67C3 for ; Thu, 1 Jul 2010 01:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[AWL=0.474, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2oqk9Xnpmyx for ; Thu, 1 Jul 2010 01:46:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 744A23A67BD for ; Thu, 1 Jul 2010 01:46:54 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 1 Jul 2010 04:47:04 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 1 Jul 2010 04:47:04 -0400 From: Hadriel Kaplan To: "Elwell, John" , Cullen Jennings , Christer Holmberg Date: Thu, 1 Jul 2010 04:47:03 -0400 Thread-Topic: [dispatch] Final Charter for Session-ID? Thread-Index: AcsMlxexqhp/n5RJRR28pUkxgf7t7gAwWuqAAuhKTpA= Message-ID: <430FC6BDED356B4C8498F634416644A91FE0EBB9FD@mail> References: <430FC6BDED356B4C8498F634416644A91DD8F3DF3D@mail> <1D062974A4845E4D8A343C653804920202E2BD88@XMB-BGL-414.cisco.com> <4C10E050.5090102@cisco.com> <9A31589C-D364-4DB8-AA09-78A6772A8A16@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH list Subject: Re: [dispatch] Final Charter for Session-ID? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 08:46:56 -0000 I was proposing that it be for any method type. I don't think that name of= the header confuses anyone. For example "Call-ID" is used for things whic= h have nothing to do with "Calls", yet no one seems confused. -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Wednesday, June 16, 2010 9:45 AM >=20 > When Cullen raised the question, I was wondering whether two dialogs are > related if the media from the session associated with one dialog is > forwarded to the session associated with the other dialog. But then I > realised that this would not apply if you wanted to correlate two dialogs > that are not session-related, e.g., two SUBSCRIBE-initiated dialogs. But > on the other hand, the term session-ID hardly seems the right term for tw= o > related SUBSCRIBE-initiated dialogs, since there is no session involved. >=20 > So the first question to be asked is whether the work should really be > limited to sessions, or whether it could apply to other types of dialog, > or even to non-dialog-forming transactions such as MESSAGE and PUBLISH > when they cross a B2BUA. Depending on the answer to this, the name and > definition of the object we are trying to describe can be selected. >=20 > John From HKaplan@acmepacket.com Thu Jul 1 02:01:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E0D3A67BD for ; Thu, 1 Jul 2010 02:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=1.245, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmX8fdWZUhYU for ; Thu, 1 Jul 2010 02:01:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 57F833A63EC for ; Thu, 1 Jul 2010 02:01:26 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 1 Jul 2010 05:01:37 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 1 Jul 2010 05:01:37 -0400 From: Hadriel Kaplan To: "Dawes, Peter, VF-Group" , "dispatch@ietf.org" Date: Thu, 1 Jul 2010 05:01:36 -0400 Thread-Topic: [dispatch] Final Charter for Session-ID? Thread-Index: AcsIgojlqut4YEMTR9iCbYzMOxUGOQQeVFcg Message-ID: <430FC6BDED356B4C8498F634416644A91FE0EBBA00@mail> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Final Charter for Session-ID? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 09:01:27 -0000 > -----Original Message----- > From: Dawes, Peter, VF-Group [mailto:Peter.Dawes@vodafone.com] > Sent: Thursday, June 10, 2010 5:52 AM > To: dispatch@ietf.org >=20 > Hello All, > I agree with Cullen in that the implementer of a B2BUA will need more > guidance than is in the proposed charter now in order to decide whether > dialogs are related, but I think the first question is how much of this > guidance goes in the charter and how much in the working group drafts. Yes exactly. ISTM that a charter shouldn't define the solution. -hadriel From gonzalo.camarillo@ericsson.com Thu Jul 1 02:06:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4DF3A67C3; Thu, 1 Jul 2010 02:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.243 X-Spam-Level: X-Spam-Status: No, score=-103.243 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfvfYcsl7ZV3; Thu, 1 Jul 2010 02:06:52 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B4B7A3A67AE; Thu, 1 Jul 2010 02:06:51 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-b6-4c2c5ab532e4 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FC.33.19600.5BA5C2C4; Thu, 1 Jul 2010 11:07:02 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 11:07:01 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 11:07:01 +0200 Message-ID: <4C2C5AB4.5020705@ericsson.com> Date: Thu, 01 Jul 2010 12:07:00 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Cullen Jennings References: <20100622170002.02B053A683E@core3.amsl.com> <74B1068E-86C0-426E-8E9B-841C23EE9965@cisco.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2010 09:07:01.0512 (UTC) FILETIME=[C4580880:01CB18FC] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH , IETF Discussion Mailing List Subject: Re: [dispatch] WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 09:06:53 -0000 Hi, let's not start discussing (again) whether this information in carried in a header field or in a body part. Let's discuss the requirement below instead, which seems to be what needs to be clarified in the charter (the details on how to encode this will be largely determined by the requirements the solution should meet). > 5. SIP elements may need to apply policy about passing and screening > the information. I agree the charter needs to be clearer on what types of policies are expected and what is needed to apply them. Discussing about the granularity of those policies would be useful as well. The charter should clarify the questions below: Would a proxy reject a whole request because it carries some type of information (without the proxy knowing the exact contents of the information)?... or would the proxy remove the information and proxy the remainder of the request?... or would the proxy need access to the contents of the information in order to decide what to do? Also, will intermediaries applying policies be proxies or some type of a B2BUA? Thanks, Gonzalo On 01/07/2010 5:31 AM, Cullen Jennings wrote: > > On Jun 29, 2010, at 3:25 AM, Elwell, John wrote: > >> Cullen, >> >> Whilst neither agreeing nor disagreeing with the charter, I did not find anything in the charter that said the information had to be in the SIP header rather than in the body. On what basis do you make that deduction? >> >> John > > When I read > 5. SIP elements may need to apply policy about passing and screening > the information. > > And the discussion about it's not just UA. I reached that perhaps flawed conclusion that proxies needed to be able to change the information when "screening" and thus it needed to be in a header. Note I would have far less of an issue with an opaque container for proprietary information if it was in a body instead of a header and had the types of constraints that SIP-T has. > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From laura.liess.dt@googlemail.com Thu Jul 1 05:53:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC13528C15E; Thu, 1 Jul 2010 05:53:27 -0700 (PDT) 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=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bNgMoQB9yq2; Thu, 1 Jul 2010 05:53:25 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 285743A6BB8; Thu, 1 Jul 2010 05:53:25 -0700 (PDT) Received: by pzk36 with SMTP id 36so416913pzk.31 for ; Thu, 01 Jul 2010 05:53:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TQPAI/9zT5a9lRTmpOfbvyKGvfJ/K1DqVEFBtByoFNw=; b=QYpzKkEec21j/2Ial3ay/VagyMayqRF5Aukl95nnujMSQaBE2zJ5QaZqJvrwdI+Eb1 YZH905/Wr3LsRfC24XvYuca3nC1is/EierqPBZ/wWDW1I4MoJCTQQXOSufyzvkpVs6Rf QBdq7p/Mi9QvVmsNMcRrQtSeMNWSk9/Vs8nFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=aSK4YWy4SDxJsziV/TRJ9z7H3O60wCF5nWZd5bb3tnzPSWuXye+OVNH7nIyUDQGnRH dydawfB+QuIbHFsDo3K+ggs35VZ54+Kbwuu1ZrZuGUepnhnEe2hpCv6Pg/UgGXyK9Qyy yNQXSXxctWushVcLmfT+ys8sAzKXiYD0z8Jlw= MIME-Version: 1.0 Received: by 10.142.157.6 with SMTP id f6mr5454652wfe.94.1277988812449; Thu, 01 Jul 2010 05:53:32 -0700 (PDT) Received: by 10.142.80.15 with HTTP; Thu, 1 Jul 2010 05:53:32 -0700 (PDT) In-Reply-To: <4C2B8ACE.3050301@cisco.com> References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> <4C2A2C19.1030906@cisco.com> <4C2AE94C.4020707@ericsson.com> <617DF0128820F9458AC39149A627EE6C01A66BC2A7@MBX.dialogic.com> <4C2B8ACE.3050301@cisco.com> Date: Thu, 1 Jul 2010 14:53:32 +0200 Message-ID: From: Laura Liess To: Paul Kyzivat , James Rafferty Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , "ietf@ietf.org" , Roland Jesske Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 12:53:28 -0000 In the PSTN, we use the UUI field to transmit information between the Intelligent Network (IN) system and call center agents for the directory enquires service. Everybody in Germany who wants to ask for the phone number of another person dials DT's directory enquires service and is connected to a call center agent who tells him the number he wants to know. Additionaly, only if the caller is a DT customer, the call center agent offers to connect him to this number, so the caller does not need to dial. For everybode else, he does not. So the call center agent needs to get the information whether or not the caller is a DT customer. This is done by routing every directory enquires call to the IN system first. The IN system checks the caller number and inserts the information about whether or not the caller is a DT-customer in the UUI field which is transmited via INAP, ISUP and DSS1 to the call center agent's end device.The call center agent gets a display about this. During the PSTN-migration to SIP, we will have cases where the call center and the IN system are connected to different networks, one to PSTN and the other to SIP. Also, we may have applications as above on pure SIP application servers. > Can you shed some light on *how* this is used, given the lack of any > standards on the content/formatting of this information? The application is DT-specific and needs a DT specification to be supported by the IN system and the call center, but the container to transport the information must be supported by both ends and by the network nodes. > Or is this only used between a caller and a callee that have somehow > obtained contextual information that they both support this feature *and*= a > particular encoding? At least within the DT network, UUI is used between application servers or application servers and "special" end devices as call centers. As far as I know, UUI is currently not part of the DT normal telephony package. Many years ago, it was, but people misused it. We plan to use the "Johnston uui draft" for the scenario described above and we see the need for the proposed WG. Thanks a lot Laura Laura 2010/6/30 Paul Kyzivat : > James, > > Can you shed some light on *how* this is used, given the lack of any > standards on the content/formatting of this information? > > Do you use content=3Disdn-uui and some particular Q.931 protocol discrimi= nator > for which there are formatting standards? > > Or is this only used between a caller and a callee that have somehow > obtained contextual information that they both support this feature *and*= a > particular encoding? > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > > James Rafferty wrote: >> >> Hi, >> My company has had the experience of deploying the pre-standard version = of >> this PSTN to SIP UUI mechanism during the past 2 years. >> As noted in the draft charter, UUI information is widely used on the PST= N >> for applications such as offering input data into call centers and then >> preserving that data as calls get transferred. >> Since many contact centers are now built using SIP, but still have PSTN >> subscribers (via SS7 ISUP or ISDN PRI), there is a need to be able to >> interwork the user to user information from the PSTN side into SIP. =A0I= n our >> experience, the "Johnston uui draft" has accomplished this and we have >> several customers that find this interworking to be valuable. =A0We also= noted >> improvements from early drafts into the later ones in areas such as maki= ng >> better use of the ITU-T protocol discriminator, thus enabling better >> interoperability from the PSTN side into SIP. >> The major deficiency of the current draft is its non-standard status. >> Functionally, we and our customers find this mechanism to be very useful= and >> I'd very much like the IETF to charter the a UUI work group to standardi= ze >> such a mechanism. >> James =A0-----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Gonzalo Camarillo >> Sent: Wednesday, June 30, 2010 2:51 AM >> To: Paul Kyzivat >> Cc: dispatch@ietf.org; DRAGE, Keith (Keith); ietf@ietf.org >> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP >> (cuss) >> >> Hi, >> >> please keep both the IETF and the DISPATCH mailing lists in the >> recipients list in this discussion. >> >> Cheers, >> >> Gonzalo >> >> >> On 29/06/2010 8:23 PM, Paul Kyzivat wrote: >>> >>> DRAGE, Keith (Keith) wrote: >>>> >>>> The UUI information is NOT ISUP. It is a transparent envelope to the >>>> entire ISDN, so it is not part of an ISDN protocol and therefore not p= art of >>>> an ISUP protocol. When carried by ISUP the envelope is bundled up in a= nother >>>> envelope with other information that ISUP carries transparently. >>>> >>>> So I believe, and have said repeatedly in the past, that references to >>>> SIP-T are irrelevant in this case. >>>> >>>> The problem we do have though is that are legacy usages of this >>>> information. In particular applications in PBXs carry it between thems= elves >>>> in ISDN call establishment. The information itself is not standardised= . If >>>> you want to migrate a PBX from DSS1 to SIP, then you have to take this >>>> information into account. The desire is not for a WG group to standard= ise >>>> this existing usage (which in my view would be a complete non-starter)= , but >>>> to allow the transfer of the existing information when migrated to a S= IP >>>> environment. The information transferred does not form part of SIP, an= d >>>> should not be standardised as part of SIP. >>> >>> How many different mechanisms do we have to construct for the purpose o= f >>> tunneling stuff over SIP? >>> >>> Its especially bad if the stuff is neither standardized nor negotiated. >>> It then just provides more opportunity for non-interoperability. >>> >>> It had been my impression that this content was standardized by ITU. >>> If nobody can bother to standardize it, then it hardly seems worth >>> working on. >>> >>> =A0 =A0 =A0 =A0Thanks, >>> =A0 =A0 =A0 =A0Paul >>> >>>> regards >>>> >>>> Keith >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: dispatch-bounces@ietf.org >>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of >>>>> bruno.chatras@orange-ftgroup.com >>>>> Sent: Tuesday, June 29, 2010 1:00 PM >>>>> To: Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org >>>>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI >>>>> for SIP (cuss) >>>>> >>>>> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 >>>>> does state that SIP-T does not come into play when there is >>>>> no PSTN involved. >>>>> >>>>> At the end of clause 2 we can read the following: "4. =A0IP >>>>> origination - IP termination: This is a case for pure SIP. >>>>> SIP-T (either encapsulation or translation of ISUP) does not >>>>> come into play as there is no PSTN interworking." >>>>> >>>>> Besides, SIP-T would require encapsulating a full ISUP >>>>> message (e.g. IAM) while we are interested in just one >>>>> parameter of the message in the context of CUSS. This would I >>>>> believe be a more severe drawback if SIP-T were used for this purpose= . >>>>> >>>>> Bruno >>>>> >>>>> >>>>>> -----Message d'origine----- >>>>>> De : dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo Camarillo >>>>>> Envoy=E9 : mardi 29 juin 2010 13:03 =C0 : DISPATCH Objet : >>>>> >>>>> [dispatch] Fwd: >>>>>> >>>>>> Re: WG Review: Call Control UUI for SIP (cuss) >>>>>> >>>>>> Hi, >>>>>> >>>>>> FYI: note the discussion below on the IETF general list. >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Gonzalo >>>>>> >>>>>> -------- Original Message -------- >>>>>> Subject: Re: WG Review: Call Control UUI for SIP (cuss) >>>>>> Date: Mon, 28 Jun 2010 20:24:23 +0200 >>>>>> From: Cullen Jennings >>>>>> To: iesg@ietf.org >>>>>> CC: IETF Discussion Mailing List >>>>>> >>>>>> >>>>>> As far as I can tell, the WG says they wants to transfer some >>>>>> information to achieve cross vendor interoperability. >>>>>> However, what I believe the charter is actually going to do >>>>> >>>>> is exactly >>>>>> >>>>>> the opposite of that. When you get your head around what >>>>> >>>>> this charter >>>>>> >>>>>> is proposing, it is going to form a more or less opaque >>>>> >>>>> container for >>>>>> >>>>>> transporting proprietary information in a SIP header. It's hard to >>>>>> imagine how this will help interoperability. >>>>>> >>>>>> If we wanted to have interoperability, the charter would say what >>>>>> information needs to be transferred and have the WG define a way to >>>>>> get it between systems in an operable way. >>>>>> What the charter for this WG actually says they are going to do is >>>>>> make a special container for transfer proprietary information. >>>>>> There's not even willing to say what that proprietary >>>>> >>>>> information is >>>>>> >>>>>> used for other than things ISDN UUI which is a =A0non >>>>> >>>>> interoperable and >>>>>> >>>>>> fairly proprietary field in ISDN. >>>>>> Furthermore they have asserted that =A0existing containers >>>>> >>>>> such as SIP-T >>>>>> >>>>>> or SIP bodies can't be used for reasons that are hard to >>>>> >>>>> describe. (I >>>>>> >>>>>> reject the idea that because the call might not involved >>>>> >>>>> the PSTN, it >>>>>> >>>>>> can't use SIP-T). >>>>>> >>>>>> I think the folks that want to do this should get a much clear >>>>>> explanation of how this results in interoperability and why exist >>>>>> approach such as SIP-T will not work before this is chartered. >>>>>> >>>>>> I do think there is a need to standardize some important >>>>> >>>>> call control >>>>>> >>>>>> information used in call centers and related places. >>>>>> However, the "we need a standard container to exchange secret >>>>>> information WG" is a bad idea and violates the sprit of the >>>>> >>>>> SIP change >>>>>> >>>>>> process not to mention the mission of the IETF. >>>>>> >>>>>> In summary, I'm in favor of figuring out what the problems >>>>> >>>>> are people >>>>>> >>>>>> hope to solve with this WG and figuring out a way to write >>>>>> interoperable standards to achieve that. However, I think >>>>> >>>>> this charter >>>>>> >>>>>> should be rejected by the IESG and sent back to the drawing >>>>> >>>>> board. The >>>>>> >>>>>> RAI area has things of higher priority items to work on than a SIP >>>>>> header for transfer proprietary data. >>>>>> >>>>>> >>>>>> >>>>>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote: >>>>>> >>>>>>> A new IETF working group has been proposed in the Real-time >>>>>>> Applications and Infrastructure Area. =A0The IESG has not >>>>>> >>>>>> made any determination as yet. >>>>>>> >>>>>>> The following draft charter was submitted, and is provided for >>>>>>> informational purposes only. Please send your comments to >>>>> >>>>> the IESG >>>>>>> >>>>>>> mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. >>>>>>> >>>>>>> Call Control UUI for SIP =A0(cuss) >>>>>>> -------------------------------------------------- >>>>>>> Current Status: Proposed Working Group >>>>>>> >>>>>>> Last modified: 2010-06-21 >>>>>>> >>>>>>> Chair(s): >>>>>>> =A0TBD >>>>>>> >>>>>>> Real-time Applications and Infrastructure Area Director(s): >>>>>>> =A0Gonzalo Camarillo >>>>> >>>>> Robert Sparks >>>>>>> >>>>>>> >>>>>>> >>>>>>> Real-time Applications and Infrastructure Area Advisor: >>>>>>> =A0Gonzalo Camarillo >>>>>>> >>>>>>> Mailing Lists: TBD >>>>>>> >>>>>>> Description of Working Group: >>>>>>> >>>>>>> The Call Control UUI for SIP (CUSS) working group is chartered to >>>>>>> define a Session Initiation Protocol (SIP) mechanism for >>>>>> >>>>>> transporting >>>>>>> >>>>>>> call-control related user-to-user information (UUI) between User >>>>>>> Agents. >>>>>>> >>>>>>> The mechanism developed in this working group is >>>>> >>>>> applicable in the >>>>>>> >>>>>>> following situations: >>>>>>> >>>>>>> 1. The information is generated and consumed by an >>>>> >>>>> application using >>>>>>> >>>>>>> =A0SIP during session setup but the application is not necessarily >>>>>>> =A0even SIP aware. >>>>>>> 2. The behavior of SIP entities that support it is not >>>>> >>>>> significantly >>>>>>> >>>>>>> =A0changed (as discussed in Section 4 of RFC 5727). >>>>>>> 3. Generally only the User Agent Client (UAC) and User >>>>> >>>>> Agent Server >>>>>>> >>>>>>> =A0(UAS) are interested in the information. >>>>>>> 4. The information is expected to survive retargeting, >>>>> >>>>> redirection, >>>>>>> >>>>>>> =A0and transfers. >>>>>>> 5. SIP elements may need to apply policy about passing >>>>> >>>>> and screening >>>>>>> >>>>>>> =A0the information. >>>>>>> 6. Multi-vendor interoperability is important. >>>>>>> >>>>>>> This mechanism is not applicable in the following situations: >>>>>>> >>>>>>> 1. The behavior of SIP entities that support it is significantly >>>>>>> =A0changed (as discussed in Section 4 of RFC 5727). >>>>>>> 2. The information is generated and consumed at the SIP >>>>> >>>>> layer by SIP >>>>>>> >>>>>>> =A0elements. >>>>>>> 3. SIP elements besides the UAC and UAS might be interested in >>>>>>> =A0consuming (beyond applying policy) the information. >>>>>>> 4. There are specific privacy issues involved with the information >>>>>>> =A0being transported (e.g., geolocation or emergency-related >>>>>>> =A0information). >>>>>>> >>>>>>> User data of the mechanism will be clearly marked with the >>>>>>> application, encoding, semantics, and content type, >>>>>> >>>>>> allowing policy to >>>>>>> >>>>>>> be applied by UAs. =A0The working group will define the >>>>>> >>>>>> information that >>>>>>> >>>>>>> each application must specify to utilize the mechanism. >>>>>> >>>>>> This type of >>>>>>> >>>>>>> application-specific information will be specified in >>>>>> >>>>>> standards-track >>>>>>> >>>>>>> documents. >>>>>>> >>>>>>> One important application of this mechanism is interworking >>>>>> >>>>>> with the >>>>>>> >>>>>>> ISDN User to User Information Service. =A0This application >>>>> >>>>> defined by >>>>>>> >>>>>>> ITU-T Q.931 is extensively deployed in the PSTN today >>>>>> >>>>>> supporting such >>>>>>> >>>>>>> applications as contact centers, call centers, and automatic call >>>>>>> distributors (ACDs). =A0A major barrier to the movement of these >>>>>>> applications to SIP is the lack of a standard mechanism to >>>>>> >>>>>> transport >>>>>>> >>>>>>> this information in SIP. =A0For interworking with ISDN, minimal >>>>>>> information about the content of the UUI is available to >>>>>> >>>>>> the PSTN-SIP >>>>>>> >>>>>>> gateways. =A0In this case only, the content will just >>>>>> >>>>>> indicate ISDN UUI >>>>>>> >>>>>>> Service 1 interworking rather than the actual content. >>>>>>> >>>>>>> Call control UUI is user information conveyed between user agents >>>>>>> during call control operations. =A0As a result, the >>>>>> >>>>>> information must be >>>>>>> >>>>>>> conveyed with the INVITE transaction, and must survive proxy >>>>>>> retargeting, redirection, and transfers. =A0The mechanism >>>>>> >>>>>> must utilize a >>>>>>> >>>>>>> minimum of SIP extensions since it will need to be >>>>>> >>>>>> supported by many >>>>>>> >>>>>>> simple SIP user agents such as PSTN gateways. =A0The mechanism must >>>>>>> interwork with the existing ISDN service but should also be >>>>>> >>>>>> extensible >>>>>>> >>>>>>> for use by other applications and non-ISDN protocols. >>>>>>> >>>>>>> Even though interworking with the PSTN is an important >>>>> >>>>> requirement, >>>>>>> >>>>>>> call control UUI can be exchanged between native SIP >>>>>> >>>>>> clients that do >>>>>>> >>>>>>> not have any ISUP support. Therefore, existing SIP-T >>>>>>> encapsulation-based approaches defined in RFC3372 do not meet the >>>>>>> requirements to transport this type of information. >>>>>>> >>>>>>> Mechanisms based on the SIP INFO method, RFC2976, will not be >>>>>>> considered by the working group since the UUI contents carry >>>>>>> information that must be conveyed during session setup at >>>>> >>>>> the user >>>>>>> >>>>>>> agent - the information must be conveyed with the INVITE >>>>>> >>>>>> transaction. >>>>>>> >>>>>>> The information must be passed with the session setup request >>>>>>> (INVITE), responses to that INVITE, or session >>>>> >>>>> termination requests. >>>>>>> >>>>>>> As a result, it is not possible to use INFO in these cases. >>>>>>> >>>>>>> The group will produce: >>>>>>> >>>>>>> - A problem statement and requirements document for >>>>>> >>>>>> implementing a SIP >>>>>>> >>>>>>> call control UUI mechanism >>>>>>> >>>>>>> - A specification of the SIP extension to best meet those >>>>>> >>>>>> requirements. >>>>>>> >>>>>>> Goals and Milestones >>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>> >>>>>>> Sep 10 - Problem statement and requirements document to IESG >>>>>>> (Informational) >>>>>>> Mar 11 - SIP call control UUI specification to IESG (PS) >>>>>>> _______________________________________________ >>>>>>> IETF-Announce mailing list >>>>>>> IETF-Announce@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>> >>>>>> Cullen Jennings >>>>>> For corporate legal information go to: >>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From dworley@avaya.com Thu Jul 1 06:58:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F6B3A67DB; Thu, 1 Jul 2010 06:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RVb7GX61Rhv; Thu, 1 Jul 2010 06:58:23 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 2F5173A67B2; Thu, 1 Jul 2010 06:58:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,520,1272859200"; d="scan'208";a="225866479" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Jul 2010 09:58:34 -0400 X-IronPort-AV: E=Sophos;i="4.53,520,1272859200"; d="scan'208";a="488016348" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 01 Jul 2010 09:58:34 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.161]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 1 Jul 2010 09:58:33 -0400 From: "WORLEY, Dale R (Dale)" To: Laura Liess , Paul Kyzivat , James Rafferty Date: Thu, 1 Jul 2010 09:56:27 -0400 Thread-Topic: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) Thread-Index: AcsZHH0AtcZOei1LQOWpFprPhNCTwAACLYOJ Message-ID: References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> <4C2A2C19.1030906@cisco.com> <4C2AE94C.4020707@ericsson.com> <617DF0128820F9458AC39149A627EE6C01A66BC2A7@MBX.dialogic.com> <4C2B8ACE.3050301@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , "ietf@ietf.org" , Roland Jesske Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 13:58:24 -0000 ________________________________________ From: ietf-bounces@ietf.org [ietf-bounces@ietf.org] On Behalf Of Laura Lies= s [laura.liess.dt@googlemail.com] Sent: Thursday, July 01, 2010 8:53 AM At least within the DT network, UUI is used between application servers or application servers and "special" end devices as call centers. As far as I know, UUI is currently not part of the DT normal telephony package. Many years ago, it was, but people misused it. _______________________________________________ Can you tell us about the misuse? It might be relevant to the expected usa= ge of the cuss feature. Dale From laura.liess.dt@googlemail.com Thu Jul 1 07:28:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1265D3A67F6; Thu, 1 Jul 2010 07:28:20 -0700 (PDT) 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=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iTI-GMxE52wO; Thu, 1 Jul 2010 07:28:19 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 0FCC13A68A9; Thu, 1 Jul 2010 07:28:19 -0700 (PDT) Received: by pwj2 with SMTP id 2so995727pwj.31 for ; Thu, 01 Jul 2010 07:28:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=kqMNQA10xiq0A2jjJBZaVw+r9YQE0gzg/ewKXJ92gII=; b=IxyRQMVGmvg3tXXrQ7dyE5HkbMwTP21GykafvqhsEy9+ktFXSiLmQRT0TwSwhHp5NI Hgrg+qM3WcRRqVXCs8sdck38tw9X9Uxa4hP474IylZGgRtPCeHLCkmoe29V6oKACW1Yg JDuSJ57eILeGLcRyYxxYr1Qia/BABdL2aaemc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TcNS1Kf5fY5j/ca4WitlQBGqTtI95zGRoK4tbYOqJDi7/fmjmQT1cfeB6Pvipxzhmm HhIMnJZAP6E+MWBvS7aYF3nEbYkSJTJZX473pQ7CXb1kk2Ny8i7DKTX/8EIDQdRZfauJ ZusWPhGBSt8hfgDLn8VhB9kx0YmeKi2MQxSJs= MIME-Version: 1.0 Received: by 10.142.196.5 with SMTP id t5mr12959754wff.54.1277994506325; Thu, 01 Jul 2010 07:28:26 -0700 (PDT) Received: by 10.142.80.15 with HTTP; Thu, 1 Jul 2010 07:28:26 -0700 (PDT) In-Reply-To: References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> <4C2A2C19.1030906@cisco.com> <4C2AE94C.4020707@ericsson.com> <617DF0128820F9458AC39149A627EE6C01A66BC2A7@MBX.dialogic.com> <4C2B8ACE.3050301@cisco.com> Date: Thu, 1 Jul 2010 16:28:26 +0200 Message-ID: From: Laura Liess To: "WORLEY, Dale R (Dale)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , James Rafferty , Roland Jesske , "ietf@ietf.org" Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 14:28:20 -0000 > Can you tell us about the misuse? It might be relevant to the expected u= sage of the cuss feature. I was relevant for that time, when communication was expensive and telephony was billed per minute... In Germany's PSTN, carriers are not allowed to bill for signalling, only for the voice channel usage. Some smart guys built devices which sent many SETUPs messages with UUI and canceled the call setup immediately. So they transmitted their information without paying anything and causing high load on the signalling network. Thanks Laura 2010/7/1 WORLEY, Dale R (Dale) : > ________________________________________ > From: ietf-bounces@ietf.org [ietf-bounces@ietf.org] On Behalf Of Laura Li= ess [laura.liess.dt@googlemail.com] > Sent: Thursday, July 01, 2010 8:53 AM > > At least within the DT network, UUI is used between application > servers or application servers and "special" end devices as call > centers. As far as I know, UUI is currently not part of the DT normal > telephony package. Many years ago, it was, but people misused it. > _______________________________________________ > > Can you tell us about the misuse? =A0It might be relevant to the expected= usage of the cuss feature. > > Dale > From pkyzivat@cisco.com Thu Jul 1 09:48:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A27DA3A68C7 for ; Thu, 1 Jul 2010 09:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.284 X-Spam-Level: X-Spam-Status: No, score=-10.284 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6g1eQ+ygpl6 for ; Thu, 1 Jul 2010 09:48:09 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D26993A6824 for ; Thu, 1 Jul 2010 09:48:08 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOtiLExAZnwM/2dsb2JhbACfaHGkepo6gnEIgiwEiC0 X-IronPort-AV: E=Sophos;i="4.53,520,1272844800"; d="scan'208";a="127792752" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 01 Jul 2010 16:48:19 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o61GmJq0001706; Thu, 1 Jul 2010 16:48:19 GMT Message-ID: <4C2CC6D8.9030002@cisco.com> Date: Thu, 01 Jul 2010 12:48:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Laura Liess References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> <4C2A2C19.1030906@cisco.com> <4C2AE94C.4020707@ericsson.com> <617DF0128820F9458AC39149A627EE6C01A66BC2A7@MBX.dialogic.com> <4C2B8ACE.3050301@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "dispatch@ietf.org" , James Rafferty , Roland Jesske Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 16:48:12 -0000 [removing ietf@ietf.org to avoid inflicting pain on such a broad audience] Laura, So this use is by prior arrangement between the UAC and UAS in a case where the UAC is in a position to know for certain the capabilities of the UAS. Is the usage "standard" to the extent that Q.931 defines a standard for this? What protocol discriminator is used? Is it 0 (user specified - effectively unrestricted use AFAICT), or in the 0x40-0x4F range reserved for "national" use? Thanks, Paul Laura Liess wrote: > In the PSTN, we use the UUI field to transmit information between the > Intelligent Network (IN) system and call center agents for the > directory enquires service. Everybody in Germany who wants to ask for > the phone number of another person dials DT's directory enquires > service and is connected to a call center agent who tells him the > number he wants to know. Additionaly, only if the caller is a DT > customer, the call center agent offers to connect him to this number, > so the caller does not need to dial. For everybode else, he does not. > So the call center agent needs to get the information whether or not > the caller is a DT customer. This is done by routing every directory > enquires call to the IN system first. The IN system checks the caller > number and inserts the information about whether or not the caller is > a DT-customer in the UUI field which is transmited via INAP, ISUP and > DSS1 to the call center agent's end device.The call center agent gets > a display about this. During the PSTN-migration to SIP, we will have > cases where the call center and the IN system are connected to > different networks, one to PSTN and the other to SIP. Also, we may > have applications as above on pure SIP application servers. > >> Can you shed some light on *how* this is used, given the lack of any >> standards on the content/formatting of this information? > > The application is DT-specific and needs a DT specification to be > supported by the IN system and the call center, but the container to > transport the information must be supported by both ends and by the > network nodes. > >> Or is this only used between a caller and a callee that have somehow >> obtained contextual information that they both support this feature *and* a >> particular encoding? > > At least within the DT network, UUI is used between application > servers or application servers and "special" end devices as call > centers. As far as I know, UUI is currently not part of the DT normal > telephony package. Many years ago, it was, but people misused it. > > We plan to use the "Johnston uui draft" for the scenario described > above and we see the need for the proposed WG. > > Thanks a lot > Laura > > > Laura > > > > > > > > > 2010/6/30 Paul Kyzivat : >> James, >> >> Can you shed some light on *how* this is used, given the lack of any >> standards on the content/formatting of this information? >> >> Do you use content=isdn-uui and some particular Q.931 protocol discriminator >> for which there are formatting standards? >> >> Or is this only used between a caller and a callee that have somehow >> obtained contextual information that they both support this feature *and* a >> particular encoding? >> >> Thanks, >> Paul >> >> James Rafferty wrote: >>> Hi, >>> My company has had the experience of deploying the pre-standard version of >>> this PSTN to SIP UUI mechanism during the past 2 years. >>> As noted in the draft charter, UUI information is widely used on the PSTN >>> for applications such as offering input data into call centers and then >>> preserving that data as calls get transferred. >>> Since many contact centers are now built using SIP, but still have PSTN >>> subscribers (via SS7 ISUP or ISDN PRI), there is a need to be able to >>> interwork the user to user information from the PSTN side into SIP. In our >>> experience, the "Johnston uui draft" has accomplished this and we have >>> several customers that find this interworking to be valuable. We also noted >>> improvements from early drafts into the later ones in areas such as making >>> better use of the ITU-T protocol discriminator, thus enabling better >>> interoperability from the PSTN side into SIP. >>> The major deficiency of the current draft is its non-standard status. >>> Functionally, we and our customers find this mechanism to be very useful and >>> I'd very much like the IETF to charter the a UUI work group to standardize >>> such a mechanism. >>> James -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Gonzalo Camarillo >>> Sent: Wednesday, June 30, 2010 2:51 AM >>> To: Paul Kyzivat >>> Cc: dispatch@ietf.org; DRAGE, Keith (Keith); ietf@ietf.org >>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP >>> (cuss) >>> >>> Hi, >>> >>> please keep both the IETF and the DISPATCH mailing lists in the >>> recipients list in this discussion. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> >>> On 29/06/2010 8:23 PM, Paul Kyzivat wrote: >>>> DRAGE, Keith (Keith) wrote: >>>>> The UUI information is NOT ISUP. It is a transparent envelope to the >>>>> entire ISDN, so it is not part of an ISDN protocol and therefore not part of >>>>> an ISUP protocol. When carried by ISUP the envelope is bundled up in another >>>>> envelope with other information that ISUP carries transparently. >>>>> >>>>> So I believe, and have said repeatedly in the past, that references to >>>>> SIP-T are irrelevant in this case. >>>>> >>>>> The problem we do have though is that are legacy usages of this >>>>> information. In particular applications in PBXs carry it between themselves >>>>> in ISDN call establishment. The information itself is not standardised. If >>>>> you want to migrate a PBX from DSS1 to SIP, then you have to take this >>>>> information into account. The desire is not for a WG group to standardise >>>>> this existing usage (which in my view would be a complete non-starter), but >>>>> to allow the transfer of the existing information when migrated to a SIP >>>>> environment. The information transferred does not form part of SIP, and >>>>> should not be standardised as part of SIP. >>>> How many different mechanisms do we have to construct for the purpose of >>>> tunneling stuff over SIP? >>>> >>>> Its especially bad if the stuff is neither standardized nor negotiated. >>>> It then just provides more opportunity for non-interoperability. >>>> >>>> It had been my impression that this content was standardized by ITU. >>>> If nobody can bother to standardize it, then it hardly seems worth >>>> working on. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> regards >>>>> >>>>> Keith >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of >>>>>> bruno.chatras@orange-ftgroup.com >>>>>> Sent: Tuesday, June 29, 2010 1:00 PM >>>>>> To: Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org >>>>>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI >>>>>> for SIP (cuss) >>>>>> >>>>>> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 >>>>>> does state that SIP-T does not come into play when there is >>>>>> no PSTN involved. >>>>>> >>>>>> At the end of clause 2 we can read the following: "4. IP >>>>>> origination - IP termination: This is a case for pure SIP. >>>>>> SIP-T (either encapsulation or translation of ISUP) does not >>>>>> come into play as there is no PSTN interworking." >>>>>> >>>>>> Besides, SIP-T would require encapsulating a full ISUP >>>>>> message (e.g. IAM) while we are interested in just one >>>>>> parameter of the message in the context of CUSS. This would I >>>>>> believe be a more severe drawback if SIP-T were used for this purpose. >>>>>> >>>>>> Bruno >>>>>> >>>>>> >>>>>>> -----Message d'origine----- >>>>>>> De : dispatch-bounces@ietf.org >>>>>>> [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo Camarillo >>>>>>> Envoyé : mardi 29 juin 2010 13:03 À : DISPATCH Objet : >>>>>> [dispatch] Fwd: >>>>>>> Re: WG Review: Call Control UUI for SIP (cuss) >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> FYI: note the discussion below on the IETF general list. >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Gonzalo >>>>>>> >>>>>>> -------- Original Message -------- >>>>>>> Subject: Re: WG Review: Call Control UUI for SIP (cuss) >>>>>>> Date: Mon, 28 Jun 2010 20:24:23 +0200 >>>>>>> From: Cullen Jennings >>>>>>> To: iesg@ietf.org >>>>>>> CC: IETF Discussion Mailing List >>>>>>> >>>>>>> >>>>>>> As far as I can tell, the WG says they wants to transfer some >>>>>>> information to achieve cross vendor interoperability. >>>>>>> However, what I believe the charter is actually going to do >>>>>> is exactly >>>>>>> the opposite of that. When you get your head around what >>>>>> this charter >>>>>>> is proposing, it is going to form a more or less opaque >>>>>> container for >>>>>>> transporting proprietary information in a SIP header. It's hard to >>>>>>> imagine how this will help interoperability. >>>>>>> >>>>>>> If we wanted to have interoperability, the charter would say what >>>>>>> information needs to be transferred and have the WG define a way to >>>>>>> get it between systems in an operable way. >>>>>>> What the charter for this WG actually says they are going to do is >>>>>>> make a special container for transfer proprietary information. >>>>>>> There's not even willing to say what that proprietary >>>>>> information is >>>>>>> used for other than things ISDN UUI which is a non >>>>>> interoperable and >>>>>>> fairly proprietary field in ISDN. >>>>>>> Furthermore they have asserted that existing containers >>>>>> such as SIP-T >>>>>>> or SIP bodies can't be used for reasons that are hard to >>>>>> describe. (I >>>>>>> reject the idea that because the call might not involved >>>>>> the PSTN, it >>>>>>> can't use SIP-T). >>>>>>> >>>>>>> I think the folks that want to do this should get a much clear >>>>>>> explanation of how this results in interoperability and why exist >>>>>>> approach such as SIP-T will not work before this is chartered. >>>>>>> >>>>>>> I do think there is a need to standardize some important >>>>>> call control >>>>>>> information used in call centers and related places. >>>>>>> However, the "we need a standard container to exchange secret >>>>>>> information WG" is a bad idea and violates the sprit of the >>>>>> SIP change >>>>>>> process not to mention the mission of the IETF. >>>>>>> >>>>>>> In summary, I'm in favor of figuring out what the problems >>>>>> are people >>>>>>> hope to solve with this WG and figuring out a way to write >>>>>>> interoperable standards to achieve that. However, I think >>>>>> this charter >>>>>>> should be rejected by the IESG and sent back to the drawing >>>>>> board. The >>>>>>> RAI area has things of higher priority items to work on than a SIP >>>>>>> header for transfer proprietary data. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote: >>>>>>> >>>>>>>> A new IETF working group has been proposed in the Real-time >>>>>>>> Applications and Infrastructure Area. The IESG has not >>>>>>> made any determination as yet. >>>>>>>> The following draft charter was submitted, and is provided for >>>>>>>> informational purposes only. Please send your comments to >>>>>> the IESG >>>>>>>> mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. >>>>>>>> >>>>>>>> Call Control UUI for SIP (cuss) >>>>>>>> -------------------------------------------------- >>>>>>>> Current Status: Proposed Working Group >>>>>>>> >>>>>>>> Last modified: 2010-06-21 >>>>>>>> >>>>>>>> Chair(s): >>>>>>>> TBD >>>>>>>> >>>>>>>> Real-time Applications and Infrastructure Area Director(s): >>>>>>>> Gonzalo Camarillo >>>>>> Robert Sparks >>>>>>>> >>>>>>>> >>>>>>>> Real-time Applications and Infrastructure Area Advisor: >>>>>>>> Gonzalo Camarillo >>>>>>>> >>>>>>>> Mailing Lists: TBD >>>>>>>> >>>>>>>> Description of Working Group: >>>>>>>> >>>>>>>> The Call Control UUI for SIP (CUSS) working group is chartered to >>>>>>>> define a Session Initiation Protocol (SIP) mechanism for >>>>>>> transporting >>>>>>>> call-control related user-to-user information (UUI) between User >>>>>>>> Agents. >>>>>>>> >>>>>>>> The mechanism developed in this working group is >>>>>> applicable in the >>>>>>>> following situations: >>>>>>>> >>>>>>>> 1. The information is generated and consumed by an >>>>>> application using >>>>>>>> SIP during session setup but the application is not necessarily >>>>>>>> even SIP aware. >>>>>>>> 2. The behavior of SIP entities that support it is not >>>>>> significantly >>>>>>>> changed (as discussed in Section 4 of RFC 5727). >>>>>>>> 3. Generally only the User Agent Client (UAC) and User >>>>>> Agent Server >>>>>>>> (UAS) are interested in the information. >>>>>>>> 4. The information is expected to survive retargeting, >>>>>> redirection, >>>>>>>> and transfers. >>>>>>>> 5. SIP elements may need to apply policy about passing >>>>>> and screening >>>>>>>> the information. >>>>>>>> 6. Multi-vendor interoperability is important. >>>>>>>> >>>>>>>> This mechanism is not applicable in the following situations: >>>>>>>> >>>>>>>> 1. The behavior of SIP entities that support it is significantly >>>>>>>> changed (as discussed in Section 4 of RFC 5727). >>>>>>>> 2. The information is generated and consumed at the SIP >>>>>> layer by SIP >>>>>>>> elements. >>>>>>>> 3. SIP elements besides the UAC and UAS might be interested in >>>>>>>> consuming (beyond applying policy) the information. >>>>>>>> 4. There are specific privacy issues involved with the information >>>>>>>> being transported (e.g., geolocation or emergency-related >>>>>>>> information). >>>>>>>> >>>>>>>> User data of the mechanism will be clearly marked with the >>>>>>>> application, encoding, semantics, and content type, >>>>>>> allowing policy to >>>>>>>> be applied by UAs. The working group will define the >>>>>>> information that >>>>>>>> each application must specify to utilize the mechanism. >>>>>>> This type of >>>>>>>> application-specific information will be specified in >>>>>>> standards-track >>>>>>>> documents. >>>>>>>> >>>>>>>> One important application of this mechanism is interworking >>>>>>> with the >>>>>>>> ISDN User to User Information Service. This application >>>>>> defined by >>>>>>>> ITU-T Q.931 is extensively deployed in the PSTN today >>>>>>> supporting such >>>>>>>> applications as contact centers, call centers, and automatic call >>>>>>>> distributors (ACDs). A major barrier to the movement of these >>>>>>>> applications to SIP is the lack of a standard mechanism to >>>>>>> transport >>>>>>>> this information in SIP. For interworking with ISDN, minimal >>>>>>>> information about the content of the UUI is available to >>>>>>> the PSTN-SIP >>>>>>>> gateways. In this case only, the content will just >>>>>>> indicate ISDN UUI >>>>>>>> Service 1 interworking rather than the actual content. >>>>>>>> >>>>>>>> Call control UUI is user information conveyed between user agents >>>>>>>> during call control operations. As a result, the >>>>>>> information must be >>>>>>>> conveyed with the INVITE transaction, and must survive proxy >>>>>>>> retargeting, redirection, and transfers. The mechanism >>>>>>> must utilize a >>>>>>>> minimum of SIP extensions since it will need to be >>>>>>> supported by many >>>>>>>> simple SIP user agents such as PSTN gateways. The mechanism must >>>>>>>> interwork with the existing ISDN service but should also be >>>>>>> extensible >>>>>>>> for use by other applications and non-ISDN protocols. >>>>>>>> >>>>>>>> Even though interworking with the PSTN is an important >>>>>> requirement, >>>>>>>> call control UUI can be exchanged between native SIP >>>>>>> clients that do >>>>>>>> not have any ISUP support. Therefore, existing SIP-T >>>>>>>> encapsulation-based approaches defined in RFC3372 do not meet the >>>>>>>> requirements to transport this type of information. >>>>>>>> >>>>>>>> Mechanisms based on the SIP INFO method, RFC2976, will not be >>>>>>>> considered by the working group since the UUI contents carry >>>>>>>> information that must be conveyed during session setup at >>>>>> the user >>>>>>>> agent - the information must be conveyed with the INVITE >>>>>>> transaction. >>>>>>>> The information must be passed with the session setup request >>>>>>>> (INVITE), responses to that INVITE, or session >>>>>> termination requests. >>>>>>>> As a result, it is not possible to use INFO in these cases. >>>>>>>> >>>>>>>> The group will produce: >>>>>>>> >>>>>>>> - A problem statement and requirements document for >>>>>>> implementing a SIP >>>>>>>> call control UUI mechanism >>>>>>>> >>>>>>>> - A specification of the SIP extension to best meet those >>>>>>> requirements. >>>>>>>> Goals and Milestones >>>>>>>> ==================== >>>>>>>> >>>>>>>> Sep 10 - Problem statement and requirements document to IESG >>>>>>>> (Informational) >>>>>>>> Mar 11 - SIP call control UUI specification to IESG (PS) >>>>>>>> _______________________________________________ >>>>>>>> IETF-Announce mailing list >>>>>>>> IETF-Announce@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>>> Cullen Jennings >>>>>>> For corporate legal information go to: >>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From mperumal@cisco.com Thu Jul 1 10:27:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 132013A690C for ; Thu, 1 Jul 2010 10:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.019 X-Spam-Level: X-Spam-Status: No, score=-9.019 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4Sxs78id8wJ for ; Thu, 1 Jul 2010 10:27:15 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 04F103A68C7 for ; Thu, 1 Jul 2010 10:27:15 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFADttLExAaHte/2dsb2JhbACBQ54lcaUkmi+CXIJJBINvhmA X-IronPort-AV: E=Sophos;i="4.53,520,1272844800"; d="scan'208,217";a="220443689" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 01 Jul 2010 17:27:25 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o61HQhF4014710 for ; Thu, 1 Jul 2010 17:27:24 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Jul 2010 22:57:16 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1942.A65462B1" x-cr-hashedpuzzle: A2q+ Bg3u EEan Fk/r FwQU Gp2i G5aX IibR I2Dn JDT7 JLn3 JSc6 JlEg J82C KpYK LxGA; 1; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {4854D13C-43F1-4398-A01C-D4F26927D816}; bQBwAGUAcgB1AG0AYQBsAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Thu, 01 Jul 2010 17:27:10 GMT; UwBoAG8AdQBsAGQAIABJAEUAVABGACAAaABhAHYAZQAgAGEAIABCAEUASABBAFYARQAgAFcARwAgAGYAbwByACAAUwBCAEMAcwA/AA== x-cr-puzzleid: {4854D13C-43F1-4398-A01C-D4F26927D816} Content-class: urn:content-classes:message Date: Thu, 1 Jul 2010 22:57:10 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IETF have a BEHAVE WG for SBCs? Thread-Index: AcsZQqNEprRLxVMETZSSd7Xx2jr+0w== From: "Muthu ArulMozhi Perumal (mperumal)" To: "DISPATCH list" X-OriginalArrivalTime: 01 Jul 2010 17:27:16.0329 (UTC) FILETIME=[A691A590:01CB1942] Subject: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 17:27:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1942.A65462B1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the past few years there has been a proliferation of Session Border Controller (SBC) deployments in SIP networks mainly because the development of SIP protocol specifications hasn't been able to keep in pace with industry and operator requirements. The common functions they perform and the architectural issues they introduce are described in RFC-5853. =20 Due to lack of well defined guidelines and best current practices many SBC implementations break end-to-end features and introduce problems that are difficult to troubleshoot, many a times because of poor implementations rather than to meet any specific requirements. For example, when they do media processing they assume everything coming on the media channel is RTP, don't do even basic RTP header validations as recommended in RFC-3550, try to decode STUN and DTLS packets as RTP corrupting them and making them useless. =20 I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to the one for NATs, to set guidelines and identify best current practices to encourage better SBC implementations, interoperability and ease of troubleshooting, rather than just keeping quiet and letting them go out of control. =20 Comments? =20 Muthu ------_=_NextPart_001_01CB1942.A65462B1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the = past few years there has been a proliferation of Session Border Controller = (SBC) deployments in SIP networks mainly because the development of SIP = protocol specifications hasn't been able to keep in pace with industry and = operator requirements. The common functions they perform and the architectural = issues they introduce are described in RFC-5853.

 

Due to = lack of well defined guidelines and best current practices many SBC = implementations break end-to-end features and introduce problems that are difficult to troubleshoot, many a times because of poor implementations rather than = to meet any specific requirements. For example, when they do media processing they = assume everything coming on the media channel is RTP, don't do even basic RTP header validations as = recommended in RFC-3550, try to decode STUN and DTLS packets as RTP = corrupting them and making them useless.

 

I am wondering whether IETF should have a BEHAVE = WG for SBCs, similar = to the one for NATs, to set guidelines and identify = best current practices to encourage better SBC implementations, interoperability and = ease of troubleshooting, rather than just keeping quiet and letting them go out = of control.

 

Comments?

 

Muthu

------_=_NextPart_001_01CB1942.A65462B1-- From tme@americafree.tv Thu Jul 1 11:09:58 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 969043A68BA for ; Thu, 1 Jul 2010 11:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.136 X-Spam-Level: X-Spam-Status: No, score=-102.136 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLEBKPpqlCO8 for ; Thu, 1 Jul 2010 11:09:57 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 9C6B63A6A16 for ; Thu, 1 Jul 2010 11:09:57 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 1C5477C74D25; Thu, 1 Jul 2010 14:10:09 -0400 (EDT) Message-Id: <11A9DC48-4385-4D61-9500-9B480FCB9DDE@americafree.tv> From: Marshall Eubanks To: "Muthu ArulMozhi Perumal (mperumal)" In-Reply-To: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 1 Jul 2010 14:10:08 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:09:58 -0000 On Jul 1, 2010, at 1:27 PM, Muthu ArulMozhi Perumal (mperumal) wrote: > In the past few years there has been a proliferation of Session > Border Controller (SBC) deployments in SIP networks mainly because > the development of SIP protocol specifications hasn't been able to > keep in pace with industry and operator requirements. The common > functions they perform and the architectural issues they introduce > are described in RFC-5853. > > Due to lack of well defined guidelines and best current practices > many SBC implementations break end-to-end features and introduce > problems that are difficult to troubleshoot, many a times because of > poor implementations rather than to meet any specific requirements. > For example, when they do media processing they assume everything > coming on the media channel is RTP, don't do even basic RTP header > validations as recommended in RFC-3550, try to decode STUN and DTLS > packets as RTP corrupting them and making them useless. > > I am wondering whether IETF should have a BEHAVE WG for SBCs, > similar to the one for NATs, to set guidelines and identify best > current practices to encourage better SBC implementations, > interoperability and ease of troubleshooting, rather than just > keeping quiet and letting them go out of control. > > Comments? I would support this. This area is a mess IMHO. Regards Marshall > > Muthu > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From dworley@avaya.com Thu Jul 1 11:56:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C7FF3A6A39 for ; Thu, 1 Jul 2010 11:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-pr3d3ft+Tg for ; Thu, 1 Jul 2010 11:56:50 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 3E56F28C0EC for ; Thu, 1 Jul 2010 11:56:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,521,1272859200"; d="scan'208";a="196171744" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Jul 2010 14:57:00 -0400 X-IronPort-AV: E=Sophos;i="4.53,521,1272859200"; d="scan'208";a="477874142" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 Jul 2010 14:56:59 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.161]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 1 Jul 2010 14:56:59 -0400 From: "WORLEY, Dale R (Dale)" To: "Muthu ArulMozhi Perumal (mperumal)" , DISPATCH list Date: Thu, 1 Jul 2010 14:56:31 -0400 Thread-Topic: Should IETF have a BEHAVE WG for SBCs? Thread-Index: AcsZQqNEprRLxVMETZSSd7Xx2jr+0wADHsSe Message-ID: References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 18:56:51 -0000 ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Mu= thu ArulMozhi Perumal (mperumal) [mperumal@cisco.com] I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to th= e one for NATs, to set guidelines and identify best current practices to en= courage better SBC implementations, interoperability and ease of troublesho= oting, rather than just keeping quiet and letting them go out of control. ________________________________________ This is a good idea. Dale From peter.musgrave@magorcorp.com Thu Jul 1 12:29:49 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8548B3A67F5 for ; Thu, 1 Jul 2010 12:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.246 X-Spam-Level: X-Spam-Status: No, score=-1.246 tagged_above=-999 required=5 tests=[AWL=0.731, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIHik6zQQDil for ; Thu, 1 Jul 2010 12:29:48 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 883303A6784 for ; Thu, 1 Jul 2010 12:29:48 -0700 (PDT) Received: by gyh3 with SMTP id 3so1380800gyh.31 for ; Thu, 01 Jul 2010 12:29:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.187.208 with SMTP id cx16mr6541472qcb.66.1278012595544; Thu, 01 Jul 2010 12:29:55 -0700 (PDT) Received: by 10.229.220.10 with HTTP; Thu, 1 Jul 2010 12:29:55 -0700 (PDT) In-Reply-To: References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> Date: Thu, 1 Jul 2010 15:29:55 -0400 Message-ID: From: Peter Musgrave To: "WORLEY, Dale R (Dale)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 19:29:49 -0000 I concur. There is some useful background in RFC5853 and perhaps http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 And then some things which died on the vine such as: http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 and perhaps some others? I don't think any of these deal with RTP issues - so that would be useful information. Also, treatment of ICE etc. would be of interest. Peter Musgrave On Thu, Jul 1, 2010 at 2:56 PM, WORLEY, Dale R (Dale) w= rote: > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of = Muthu ArulMozhi Perumal (mperumal) [mperumal@cisco.com] > > I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to = the one for NATs, to set guidelines and identify best current practices to = encourage better SBC implementations, interoperability and ease of troubles= hooting, rather than just keeping quiet and letting them go out of control. > ________________________________________ > > This is a good idea. > > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From christer.holmberg@ericsson.com Fri Jul 2 00:45:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B263A68A2 for ; Fri, 2 Jul 2010 00:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.727 X-Spam-Level: X-Spam-Status: No, score=-4.727 tagged_above=-999 required=5 tests=[AWL=1.871, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fN9Knmg3mAqZ for ; Fri, 2 Jul 2010 00:45:05 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 830B83A685E for ; Fri, 2 Jul 2010 00:45:03 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-0f-4c2d990a455f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 31.91.10125.A099D2C4; Fri, 2 Jul 2010 09:45:14 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.94]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 2 Jul 2010 09:45:13 +0200 From: Christer Holmberg To: "Muthu ArulMozhi Perumal (mperumal)" , DISPATCH list Date: Fri, 2 Jul 2010 09:45:12 +0200 Thread-Topic: Should IETF have a BEHAVE WG for SBCs? Thread-Index: AcsZQqNEprRLxVMETZSSd7Xx2jr+0wABEqZg Message-ID: References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.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_FF84A09F50A6DC48ACB6714F4666CC7468A5546830ESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 07:45:09 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC7468A5546830ESESSCMS0354e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, If you think the reason for SBCs being deployed is the fact that "the devel= opment of the SIP protocol hasn't been able to keep in pace", isn't THAT th= e problem we should try to fix? What makes you think that this new WG would= "be able to keep in pace"? It took 3,5 (!!!!) years just to produce RFC 3550... Regards, Christer ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Muthu ArulMozhi Perumal (mperumal) Sent: 1. hein=E4kuuta 2010 20:27 To: DISPATCH list Subject: [dispatch] Should IETF have a BEHAVE WG for SBCs? In the past few years there has been a proliferation of Session Border Cont= roller (SBC) deployments in SIP networks mainly because the development of = SIP protocol specifications hasn't been able to keep in pace with industry = and operator requirements. The common functions they perform and the archit= ectural issues they introduce are described in RFC-5853. Due to lack of well defined guidelines and best current practices many SBC = implementations break end-to-end features and introduce problems that are d= ifficult to troubleshoot, many a times because of poor implementations rath= er than to meet any specific requirements. For example, when they do media = processing they assume everything coming on the media channel is RTP, don't= do even basic RTP header validations as recommended in RFC-3550, try to de= code STUN and DTLS packets as RTP corrupting them and making them useless. I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to th= e one for NATs, to set guidelines and identify best current practices to en= courage better SBC implementations, interoperability and ease of troublesho= oting, rather than just keeping quiet and letting them go out of control. Comments? Muthu --_000_FF84A09F50A6DC48ACB6714F4666CC7468A5546830ESESSCMS0354e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
If you think the reason for SBCs being depl= oyed is=20 the fact that "the development of the SIP protocol hasn't been able to keep= in=20 pace", isn't THAT the problem we should try to fix? What makes you think th= at=20 this new WG would "be able to keep in pace"?
 
It took 3,5 (!!!!) years just to produce RFC=20 3550...
 
Regards,
 
Christer
 
 

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Muthu ArulMozhi Pe= rumal=20 (mperumal)
Sent: 1. hein=E4kuuta 2010 20:27
To: DISPA= TCH=20 list
Subject: [dispatch] Should IETF have a BEHAVE WG for=20 SBCs?

In=20 the past few years there has been a proliferation of Session Border Contr= oller=20 (SBC) deployments in SIP networks mainly because the development of SIP=20 protocol specifications hasn't been able to keep in pace with industry an= d=20 operator requirements. The common functions they perform and the architec= tural=20 issues they introduce are described in RFC-5853.

 <= /P>

Due=20 to lack of well defined guidelines and best current practices many SBC=20 implementations break end-to-end features and introduce problems that are= =20 difficult to troubleshoot, many a times because of poor implementations r= ather=20 than to meet any specific requirements. For example, when they do media=20 processing they assume everything coming on the media channel is RTP, don't do even basic RTP=20 header validations as recommended in RFC-3550= , try=20 to decode STUN and DTLS packets as RTP corrupting them and making them=20 useless.

 <= /P>

I=20 am wondering whether IETF should have a BEHAV= E WG for SBCs, similar to= the one=20 for NATs, to set guidelines and identify best= =20 current practices to encourage better SBC implementations, interoperabili= ty=20 and ease of troubleshooting, rather than just keeping quiet and letting t= hem=20 go out of control.

 <= /P>

Comments?

 <= /P>

Muthu

--_000_FF84A09F50A6DC48ACB6714F4666CC7468A5546830ESESSCMS0354e_-- From mperumal@cisco.com Fri Jul 2 04:32:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71F0F3A680C for ; Fri, 2 Jul 2010 04:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.855 X-Spam-Level: X-Spam-Status: No, score=-9.855 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKvo43pBdXGf for ; Fri, 2 Jul 2010 04:32:32 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CD8A43A67EE for ; Fri, 2 Jul 2010 04:32:29 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FANNqLUxAaHte/2dsb2JhbACBQ54dcaNDmkCCW4JJBINyhm0 X-IronPort-AV: E=Sophos;i="4.53,526,1272844800"; d="scan'208,217";a="340611547" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-1.cisco.com with ESMTP; 02 Jul 2010 11:32:40 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o62BWUqT024120; Fri, 2 Jul 2010 11:32:40 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Jul 2010 17:01:41 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB19DA.242ABEB4" x-cr-hashedpuzzle: AXy6 A4NF BmF9 C8W0 DZ57 DbL3 ELEY EzR5 GYtK G/Ii HrDj IgP8 MW+T MdJj NoAF XGGs; 2; YwBoAHIAaQBzAHQAZQByAC4AaABvAGwAbQBiAGUAcgBnAEAAZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AOwBkAGkAcwBwAGEAdABjAGgAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {680B54BD-F6A5-4C99-B4D0-CC3A8D85F3C1}; bQBwAGUAcgB1AG0AYQBsAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Fri, 02 Jul 2010 11:31:32 GMT; UgBFADoAIABTAGgAbwB1AGwAZAAgAEkARQBUAEYAIABoAGEAdgBlACAAYQAgAEIARQBIAEEAVgBFACAAVwBHACAAZgBvAHIAIABTAEIAQwBzAD8A x-cr-puzzleid: {680B54BD-F6A5-4C99-B4D0-CC3A8D85F3C1} Content-class: urn:content-classes:message Date: Fri, 2 Jul 2010 17:01:32 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202030CA48E@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IETF have a BEHAVE WG for SBCs? Thread-Index: AcsZQqNEprRLxVMETZSSd7Xx2jr+0wABEqZgACPhjyA= References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Christer Holmberg" , "DISPATCH list" X-OriginalArrivalTime: 02 Jul 2010 11:31:41.0571 (UTC) FILETIME=[2479AD30:01CB19DA] Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 11:32:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB19DA.242ABEB4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Christer, =20 I am not sure whether we'll be able to keep in pace in the near term, = but I think a focused WG that can come up with guideline and best = current practices for SBCs to be more predictable, pay attention to = end-to-end communication, feature interoperability and ease of = troubleshooting can have a significant influence on current and future = implementations, and lead us to a much better position in the longer = run. =20 Isn't that better than just keeping quiet and letting the problem go out = of control? =20 Muthu =20 =20 From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Friday, July 02, 2010 1:15 PM To: Muthu ArulMozhi Perumal (mperumal); DISPATCH list Subject: RE: Should IETF have a BEHAVE WG for SBCs? =20 =20 Hi, =20 If you think the reason for SBCs being deployed is the fact that "the = development of the SIP protocol hasn't been able to keep in pace", isn't = THAT the problem we should try to fix? What makes you think that this = new WG would "be able to keep in pace"? =20 It took 3,5 (!!!!) years just to produce RFC 3550... =20 Regards, =20 Christer =20 =20 =20 =09 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Muthu ArulMozhi Perumal (mperumal) Sent: 1. hein=E4kuuta 2010 20:27 To: DISPATCH list Subject: [dispatch] Should IETF have a BEHAVE WG for SBCs? In the past few years there has been a proliferation of Session Border = Controller (SBC) deployments in SIP networks mainly because the = development of SIP protocol specifications hasn't been able to keep in = pace with industry and operator requirements. The common functions they = perform and the architectural issues they introduce are described in = RFC-5853. =20 Due to lack of well defined guidelines and best current practices many = SBC implementations break end-to-end features and introduce problems = that are difficult to troubleshoot, many a times because of poor = implementations rather than to meet any specific requirements. For = example, when they do media processing they assume everything coming on = the media channel is RTP, don't do even basic RTP header validations as = recommended in RFC-3550, try to decode STUN and DTLS packets as RTP = corrupting them and making them useless. =20 I am wondering whether IETF should have a BEHAVE WG for SBCs, similar = to the one for NATs, to set guidelines and identify best current = practices to encourage better SBC implementations, interoperability and = ease of troubleshooting, rather than just keeping quiet and letting them = go out of control. =20 Comments? =20 Muthu ------_=_NextPart_001_01CB19DA.242ABEB4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Christer,

 

I am = not sure whether we'll be able to keep in pace in the near term, but I think a = focused WG that can come up with guideline and best = current practices for SBCs to be more predictable, pay = attention to end-to-end communication, feature interoperability and ease of = troubleshooting can have a significant influence on current and future implementations, and = lead us to a much better position in the longer run.

 

Isn't = that better than just keeping quiet and letting the problem go out of = control?

 

Muthu = =A0

 

From: Christer Holmberg = [mailto:christer.holmberg@ericsson.com]
Sent: Friday, July 02, 2010 1:15 PM
To: Muthu ArulMozhi Perumal (mperumal); DISPATCH list
Subject: RE: Should IETF have a BEHAVE WG for = SBCs?

 

 

Hi,

 

If you think the reason for SBCs being deployed is the = fact that "the development of the SIP protocol hasn't been able to keep = in pace", isn't THAT the problem we should try to fix? What makes you = think that this new WG would "be able to keep in pace"?

 

It took 3,5 (!!!!) years just to produce RFC = 3550...

 

Regards,

 

Christer

 

 

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Muthu ArulMozhi = Perumal (mperumal)
Sent: 1. hein=E4kuuta 2010 20:27
To: DISPATCH list
Subject: [dispatch] Should IETF have a BEHAVE WG for = SBCs?

In the = past few years there has been a proliferation of Session Border Controller = (SBC) deployments in SIP networks mainly because the development of SIP = protocol specifications hasn't been able to keep in pace with industry and = operator requirements. The common functions they perform and the architectural = issues they introduce are described in RFC-5853.

 

Due to = lack of well defined guidelines and best current practices many SBC = implementations break end-to-end features and introduce problems that are difficult to troubleshoot, many a times because of poor implementations rather than = to meet any specific requirements. For example, when they do media processing = they assume everything coming on the media channel is RTP, don't do even = basic RTP header validations as recommended in RFC-3550, try to decode STUN and = DTLS packets as RTP corrupting them and making them = useless.

 

I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to the = one for NATs, to set guidelines and identify best current practices to encourage = better SBC implementations, interoperability and ease of troubleshooting, = rather than just keeping quiet and letting them go out of = control.

 

Comments?

 

Muthu

------_=_NextPart_001_01CB19DA.242ABEB4-- From pp3129@att.com Fri Jul 2 05:39:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A8BE3A680F for ; Fri, 2 Jul 2010 05:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.462 X-Spam-Level: X-Spam-Status: No, score=-104.462 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJFpmxA7G9LK for ; Fri, 2 Jul 2010 05:39:04 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 5753A3A635F for ; Fri, 2 Jul 2010 05:39:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-5.tower-161.messagelabs.com!1278074354!13751743!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 11247 invoked from network); 2 Jul 2010 12:39:15 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-5.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 2 Jul 2010 12:39:15 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o62CcpEt021810; Fri, 2 Jul 2010 08:38:51 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o62CcidX021720; Fri, 2 Jul 2010 08:38:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 2 Jul 2010 08:39:07 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B044A8B30@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 4 Thread-Index: AcsYcLgEjfXumzSxR0GLLhA4K8FUZQBBDQCg References: From: "PFAUTZ, PENN L (ATTCORP)" To: "Mary Barnes" , "DISPATCH" Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 12:39:05 -0000 Mary: I understand what you were trying to do in the revised first paragraph, but to be honest, I liked the old version better. Some of the assertions in the new version are questionable. I offer some revised text accordingly. I am also a little concerned about the objective of " Validation protocols will be developed to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. In this context, "responsible" means an administrative domain, which is at least one of the domains, to which a PSTN call to this phone number would be routed." The first sentence seems reasonable but the second seems to imply that multiple domains may be "responsible" for a PSTN number. This is not generally the case. Penn Pfautz -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Wednesday, June 30, 2010 12:24 PM To: DISPATCH Subject: [dispatch] VIPR - proposed charter version 4 Hi all, Below, please find version 4 of the VIPR proposed charter. It's been updated to reflect ML feedback over the past 24 hours. The primary changes are adding some background as to why other solutions are not sufficient and thus a p2p approach is recommended. Also, the deliverables are now described textually rather than listing the current set of individual drafts related to this problem. Regards, Mary (DISPATCH WG co-chair) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D VIPR Charter Proposal (Version 4) WG Name: Verification Involving PSTN Reachability (VIPR) There are two globally deployed address spaces for communications used by more than a billion people daily - phone numbers and DNS rooted address such as web servers and email addresses. The inter-domain signaling design of SIP is primarily designed for email style addresses yet a large percentage of SIP deployments mostly use phone numbers for identifying users. Although ENUM provided a path for mapping E.164 numbers to sip compatible URIs and has been successfully implemented in a number of contexts, privacy and security issues as well as lack of a sufficiently compelling business case have limited the deployment of End User ENUM registries.=20 The goal of this working group is to enable inter-domain communications over the the Internet, using phone numbers to identify the person who is the object of communication without registry deployment. The VIPR WG will develop a peer to peer based approach to finding domains that claim to be responsible for a given phone number to mitigate the involvement of centralized entities to avoid some of the issues encountered by past attempts to support SIP inter-domain communications. Validation protocols will be developed to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. In this context, "responsible" means an administrative domain, which is at least one of the domains, to which a PSTN call to this phone number would be routed. Once the domain responsible for the phone number is found, existing protocols, such as SIP, can be used for inter-domain communications. Some validation protocols may be based on knowledge gathered around a PSTN call; for example, the ability to prove a call was received over the PSTN based on start and stop times. Other validation schemes, such as examining fingerprints or watermarking of PSTN media to show that a domain received a particular PSTN phone call, may also be considered by the working group. This validation will be accomplished using publicly available open interfaces to the PSTN, so the validation can be performed by any domain wishing to participate. The WG will select and standardize at least one validation scheme. The validation mechanism requires a domain to gather and maintain information related to PSTN calls. This information is used by call agents such as phones, SBCs and IP PBXs to route calls. The WG will define a client-server protocol between these call agents and the entity within a domain that maintains the information. To help mitigate SPAM issues when using SIP between domains, the WG will define a mechanism to enable one domain to check that incoming SIP messages are coming from a validated phone number. A phone number is considered validated if it is coming from a domain to which the calling domain had previously successfully placed a PSTN call. The working group will define new SIP headers and option tags, as necessary, to enable this. The essential characteristic of VIPR is establishing authentication by PSTN reachability when it is not possible to use a direct reference to ENUM databases or other direct assertions of PSTN number ownership. Elements such as public ENUM easily coexist with VIPR but no direct interaction with ENUM will be required. The solution set defined by this WG will be incrementally deployable using only existing interfaces to the PSTN. No changes will be required to existing PSTN capabilities, no new database access is needed nor is any new support from PSTN service providers required. The WG will produce the following deliverables: 1) A document describing the requirements, problem statement and architectural approach to support SIP inter-domain communications. 2) A document describing the use of the p2psip protocol (RELOAD) as applied to this problem space. 3) A document defining a scheme for validating the phone numbers using publicly available open interfaces to the PSTN. 4) A document defining client-server protocol between call agents and the entity within a domain that gathers and maintains information related to PSTN calls. 5) A document describing a mechanism to mitigate SPAM issues. The working group will carefully coordinate with the security area, O&M area, as well as the appropriate RAI WGs such as sipcore and p2psip. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From christer.holmberg@ericsson.com Fri Jul 2 05:53:45 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8DE53A680F for ; Fri, 2 Jul 2010 05:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.843 X-Spam-Level: X-Spam-Status: No, score=-4.843 tagged_above=-999 required=5 tests=[AWL=1.755, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJ-2oVJoqycf for ; Fri, 2 Jul 2010 05:53:44 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id A756E3A67DA for ; Fri, 2 Jul 2010 05:53:43 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-a7-4c2de162802b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BE.00.10125.261ED2C4; Fri, 2 Jul 2010 14:53:55 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.2.234.1; Fri, 2 Jul 2010 14:53:54 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.94]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 2 Jul 2010 14:53:53 +0200 From: Christer Holmberg To: "Muthu ArulMozhi Perumal (mperumal)" , DISPATCH list Date: Fri, 2 Jul 2010 14:53:52 +0200 Thread-Topic: Should IETF have a BEHAVE WG for SBCs? Thread-Index: AcsZQqNEprRLxVMETZSSd7Xx2jr+0wABEqZgACPhjyAAA7qi0A== Message-ID: References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C6538049202030CA48E@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C6538049202030CA48E@XMB-BGL-414.cisco.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_FF84A09F50A6DC48ACB6714F4666CC7468A5546B27ESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 12:53:45 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC7468A5546B27ESESSCMS0354e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Could you describe what you think the problems are, and why you think they = are caused by SBCs? Regards, Christer ________________________________ From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] Sent: 2. hein=E4kuuta 2010 14:32 To: Christer Holmberg; DISPATCH list Subject: RE: Should IETF have a BEHAVE WG for SBCs? Hi Christer, I am not sure whether we'll be able to keep in pace in the near term, but I= think a focused WG that can come up with guideline and best current practi= ces for SBCs to be more predictable, pay attention to end-to-end communicat= ion, feature interoperability and ease of troubleshooting can have a signif= icant influence on current and future implementations, and lead us to a muc= h better position in the longer run. Isn't that better than just keeping quiet and letting the problem go out of= control? Muthu From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Friday, July 02, 2010 1:15 PM To: Muthu ArulMozhi Perumal (mperumal); DISPATCH list Subject: RE: Should IETF have a BEHAVE WG for SBCs? Hi, If you think the reason for SBCs being deployed is the fact that "the devel= opment of the SIP protocol hasn't been able to keep in pace", isn't THAT th= e problem we should try to fix? What makes you think that this new WG would= "be able to keep in pace"? It took 3,5 (!!!!) years just to produce RFC 3550... Regards, Christer ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Muthu ArulMozhi Perumal (mperumal) Sent: 1. hein=E4kuuta 2010 20:27 To: DISPATCH list Subject: [dispatch] Should IETF have a BEHAVE WG for SBCs? In the past few years there has been a proliferation of Session Border Cont= roller (SBC) deployments in SIP networks mainly because the development of = SIP protocol specifications hasn't been able to keep in pace with industry = and operator requirements. The common functions they perform and the archit= ectural issues they introduce are described in RFC-5853. Due to lack of well defined guidelines and best current practices many SBC = implementations break end-to-end features and introduce problems that are d= ifficult to troubleshoot, many a times because of poor implementations rath= er than to meet any specific requirements. For example, when they do media = processing they assume everything coming on the media channel is RTP, don't= do even basic RTP header validations as recommended in RFC-3550, try to de= code STUN and DTLS packets as RTP corrupting them and making them useless. I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to th= e one for NATs, to set guidelines and identify best current practices to en= courage better SBC implementations, interoperability and ease of troublesho= oting, rather than just keeping quiet and letting them go out of control. Comments? Muthu --_000_FF84A09F50A6DC48ACB6714F4666CC7468A5546B27ESESSCMS0354e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Could you describe what you think the problems are= , and why=20 you think they are caused by SBCs?
 
Regards,
 
Christer

From: Muthu ArulMozhi Perumal (mperum= al)=20 [mailto:mperumal@cisco.com]
Sent: 2. hein=E4kuuta 2010=20 14:32
To: Christer Holmberg; DISPATCH list
Subject: R= E:=20 Should IETF have a BEHAVE WG for SBCs?

Hi=20 Christer,

 <= /P>

I=20 am not sure whether we'll be able to keep in pace in the near term, but I= =20 think a focused WG that can come up with guid= eline=20 and best current practices for SBCs to be mor= e=20 predictable, pay attention to end-to-end communication, feature=20 interoperability and ease of troubleshooting can have a significant influ= ence=20 on current and future implementations, and lead us to a much better posit= ion=20 in the longer run.

 <= /P>

Isn't=20 that better than just keeping quiet and letting the problem go out of=20 control?

 <= /P>

Muthu=20  

 <= /P>

From:=20 Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent:=20 Friday, July 02, 2010 1:15 PM
To: Muthu ArulMozhi Perumal=20 (mperumal); DISPATCH list
Subject: RE: Should IETF have a BEHAV= E WG=20 for SBCs?

 

 <= o:p>

Hi,

 <= o:p>

If you=20 think the reason for SBCs being deployed is the fact that "the=20 development of the SIP protocol hasn't been able to keep in pace", isn't = THAT=20 the problem we should try to fix? What makes you think that this new WG w= ould=20 "be able to keep in pace"?

 <= o:p>

It=20 took 3,5 (!!!!) years just to produce RFC 3550...

 <= o:p>

Regards,

 <= o:p>

Christer

 <= o:p>

 <= o:p>

=  

From:=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beha= lf Of=20 Muthu ArulMozhi Perumal (mperumal)
Sent: 1. hein=E4kuuta = 2010=20 20:27
To: DISPATCH list
Subject: [dispatch] Should = IETF=20 have a BEHAVE WG for SBCs?=

In=20 the past few years there has been a proliferation of Session Border=20 Controller (SBC) deployments in SIP networks mainly because the develop= ment=20 of SIP protocol specifications hasn't been able to keep in pace with=20 industry and operator requirements. The common functions they perform a= nd=20 the architectural issues they introduce are described in=20 RFC-5853.

 

Due=20 to lack of well defined guidelines and best current practices many SBC= =20 implementations break end-to-end features and introduce problems that a= re=20 difficult to troubleshoot, many a times because of poor implementations= =20 rather than to meet any specific requirements. For example, when they d= o=20 media processing they assume everything coming on the media channel is = RTP,=20 don't do even basic RTP header validations as recommended in RFC-3550, = try=20 to decode STUN and DTLS packets as RTP corrupting them and making them= =20 useless.

 

I=20 am wondering whether IETF should have a BEHAVE WG for SBCs, similar to = the=20 one for NATs, to set guidelines and identify best current practices to= =20 encourage better SBC implementations, interoperability and ease of=20 troubleshooting, rather than just keeping quiet and letting them go out= of=20 control.

 

Comments?

 

Muthu=

--_000_FF84A09F50A6DC48ACB6714F4666CC7468A5546B27ESESSCMS0354e_-- From tme@americafree.tv Fri Jul 2 06:46:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4604A3A67C2 for ; Fri, 2 Jul 2010 06:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.147 X-Spam-Level: X-Spam-Status: No, score=-102.147 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztu3SWzZ6ilA for ; Fri, 2 Jul 2010 06:46:44 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id F1D053A679C for ; Fri, 2 Jul 2010 06:46:43 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id C1D067C9B38F; Fri, 2 Jul 2010 09:46:55 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 2 Jul 2010 09:46:55 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C6538049202030CA48E@XMB-BGL-414.cisco.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 13:46:46 -0000 On Jul 2, 2010, at 8:53 AM, Christer Holmberg wrote: > Hi, > > Could you describe what you think the problems are, and why you =20 > think they are caused by SBCs? Whose SBCs ? More fundamentally, what is an SBC ? What should it do ? In my operational experience, I have seen a wide variety of answers to =20= those questions. The 3GPP world may be an exception (I don't know), =20 but from what I see SBC's are hard to interoperate with because first =20= you have to figure out just what they are doing. Now, maybe this is something that the IETF shouldn't get involved in, =20= but it would be nice to have a standard that vendors followed, and I =20 am not sure where else this would come from. Regards Marshall > > Regards, > > Christer > > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > Sent: 2. hein=E4kuuta 2010 14:32 > To: Christer Holmberg; DISPATCH list > Subject: RE: Should IETF have a BEHAVE WG for SBCs? > > Hi Christer, > > I am not sure whether we'll be able to keep in pace in the near =20 > term, but I think a focused WG that can come up with guideline and =20 > best current practices for SBCs to be more predictable, pay =20 > attention to end-to-end communication, feature interoperability and =20= > ease of troubleshooting can have a significant influence on current =20= > and future implementations, and lead us to a much better position in =20= > the longer run. > > Isn't that better than just keeping quiet and letting the problem go =20= > out of control? > > Muthu > > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Friday, July 02, 2010 1:15 PM > To: Muthu ArulMozhi Perumal (mperumal); DISPATCH list > Subject: RE: Should IETF have a BEHAVE WG for SBCs? > > > Hi, > > If you think the reason for SBCs being deployed is the fact that =20 > "the development of the SIP protocol hasn't been able to keep in =20 > pace", isn't THAT the problem we should try to fix? What makes you =20 > think that this new WG would "be able to keep in pace"? > > It took 3,5 (!!!!) years just to produce RFC 3550... > > Regards, > > Christer > > > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] =20 > On Behalf Of Muthu ArulMozhi Perumal (mperumal) > Sent: 1. hein=E4kuuta 2010 20:27 > To: DISPATCH list > Subject: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > In the past few years there has been a proliferation of Session =20 > Border Controller (SBC) deployments in SIP networks mainly because =20 > the development of SIP protocol specifications hasn't been able to =20 > keep in pace with industry and operator requirements. The common =20 > functions they perform and the architectural issues they introduce =20 > are described in RFC-5853. > > Due to lack of well defined guidelines and best current practices =20 > many SBC implementations break end-to-end features and introduce =20 > problems that are difficult to troubleshoot, many a times because of =20= > poor implementations rather than to meet any specific requirements. =20= > For example, when they do media processing they assume everything =20 > coming on the media channel is RTP, don't do even basic RTP header =20 > validations as recommended in RFC-3550, try to decode STUN and DTLS =20= > packets as RTP corrupting them and making them useless. > > I am wondering whether IETF should have a BEHAVE WG for SBCs, =20 > similar to the one for NATs, to set guidelines and identify best =20 > current practices to encourage better SBC implementations, =20 > interoperability and ease of troubleshooting, rather than just =20 > keeping quiet and letting them go out of control. > > Comments? > > Muthu > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From laura.liess.dt@googlemail.com Fri Jul 2 06:59:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 180DF3A6830 for ; Fri, 2 Jul 2010 06:59:09 -0700 (PDT) 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=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upjQnWW-7RPw for ; Fri, 2 Jul 2010 06:59:07 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 0F99E3A68C0 for ; Fri, 2 Jul 2010 06:59:07 -0700 (PDT) Received: by pzk36 with SMTP id 36so713253pzk.31 for ; Fri, 02 Jul 2010 06:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=igPmsO58rLt8oH8OVRWj+8hDbwcKd6u6jwDhLv9uPlc=; b=iMJ8OPYwqu04zEmQK8gq6C4lzN6M0+oB04QfqTlEC1Jj/Lh+MSXis8m9BPtj2z6t84 OZPdRPZwBq5fxnMqXq9/FJ3JLuUMvPK9gc+sUjikpkK6mtMBsjsv4Jzp73ZIfEhfjJsu jhSFjhC0jZG/HLrd4XmSbuA02ioGqP0aVhsDM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Jo50gTDtx5pdeUHc8F/T2praJmLaPMZQ56z9xXkZ6BQvZYIMT4slv9RDb+PKYis7DW H7RxJmqwZOyfiYOn/qbQEntaiLzcawLoc4wKWiJ9IVgrcosN3/iPCaxgvD9bc6sx2W+P nKm8RXfFtS/uoXQfcGicJPPvokVnZvLauh5I0= MIME-Version: 1.0 Received: by 10.142.142.12 with SMTP id p12mr1155995wfd.13.1278079155568; Fri, 02 Jul 2010 06:59:15 -0700 (PDT) Received: by 10.142.80.15 with HTTP; Fri, 2 Jul 2010 06:59:15 -0700 (PDT) In-Reply-To: <4C2CC6D8.9030002@cisco.com> References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> <4C2A2C19.1030906@cisco.com> <4C2AE94C.4020707@ericsson.com> <617DF0128820F9458AC39149A627EE6C01A66BC2A7@MBX.dialogic.com> <4C2B8ACE.3050301@cisco.com> <4C2CC6D8.9030002@cisco.com> Date: Fri, 2 Jul 2010 15:59:15 +0200 Message-ID: From: Laura Liess To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , James Rafferty , Roland Jesske Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 13:59:09 -0000 Paul, > So this use is by prior arrangement between the UAC and UAS in a case whe= re > the UAC is in a position to know for certain the capabilities of the UAS. Yes, but it may happen that the UAC or the UAS is actually a SIP-PSTN GW which does not realy understand the content. > > Is the usage "standard" to the extent that Q.931 defines a standard for > this? What protocol discriminator is used? Is it 0 (user specified - > effectively unrestricted use AFAICT), or in the 0x40-0x4F range reserved = for > "national" use? The protocol descriminator is 08 "Recommendation Q.931/I.451 user-network call control messages". (I could not find out why they did not take something within the "national use" range. ) Laura > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > > Laura Liess wrote: >> >> In the PSTN, =A0we use the UUI field to transmit information between the >> Intelligent Network (IN) system and call center agents for the >> directory enquires service. Everybody in Germany who wants to ask for >> the phone number of another person dials DT's directory enquires >> service and is connected to a call center agent who tells him the >> number he wants to know. Additionaly, only if the caller is a DT >> customer, the call center agent offers to connect him to this number, >> so the caller does not need to dial. For everybode else, he does not. >> So the call center agent needs to get the information whether or not >> the caller is a DT customer. This is done by routing every directory >> enquires call to the IN system first. The IN system checks the caller >> number and inserts the information about whether or not the caller is >> a DT-customer in the UUI field which is transmited via INAP, ISUP and >> DSS1 to the call center agent's end device.The call center agent gets >> a display about this. During the PSTN-migration to SIP, we will have >> cases where the call center and the IN system are connected to >> different networks, one to PSTN and the other to SIP. =A0Also, we may >> have applications as above on pure SIP application servers. >> >>> Can you shed some light on *how* this is used, given the lack of any >>> standards on the content/formatting of this information? >> >> The application is DT-specific and needs a DT specification to be >> supported by the IN system and the call center, but the container to >> transport the information must be supported by both ends and by the >> network nodes. >> >>> Or is this only used between a caller and a callee that have somehow >>> obtained contextual information that they both support this feature *an= d* >>> a >>> particular encoding? >> >> At least within the DT network, UUI is used between application >> servers or application servers and "special" end devices as call >> centers. As far as I know, UUI is currently not part of the DT normal >> telephony package. Many years ago, it was, but people misused it. >> >> We plan to use the "Johnston uui draft" for the scenario described >> above and we see the need for the proposed WG. >> >> Thanks a lot >> Laura >> >> >> Laura >> >> >> >> >> >> >> >> >> 2010/6/30 Paul Kyzivat : >>> >>> James, >>> >>> Can you shed some light on *how* this is used, given the lack of any >>> standards on the content/formatting of this information? >>> >>> Do you use content=3Disdn-uui and some particular Q.931 protocol >>> discriminator >>> for which there are formatting standards? >>> >>> Or is this only used between a caller and a callee that have somehow >>> obtained contextual information that they both support this feature *an= d* >>> a >>> particular encoding? >>> >>> =A0 =A0 =A0 Thanks, >>> =A0 =A0 =A0 Paul >>> >>> James Rafferty wrote: >>>> >>>> Hi, >>>> My company has had the experience of deploying the pre-standard versio= n >>>> of >>>> this PSTN to SIP UUI mechanism during the past 2 years. >>>> As noted in the draft charter, UUI information is widely used on the >>>> PSTN >>>> for applications such as offering input data into call centers and the= n >>>> preserving that data as calls get transferred. >>>> Since many contact centers are now built using SIP, but still have PST= N >>>> subscribers (via SS7 ISUP or ISDN PRI), there is a need to be able to >>>> interwork the user to user information from the PSTN side into SIP. = =A0In >>>> our >>>> experience, the "Johnston uui draft" has accomplished this and we have >>>> several customers that find this interworking to be valuable. =A0We al= so >>>> noted >>>> improvements from early drafts into the later ones in areas such as >>>> making >>>> better use of the ITU-T protocol discriminator, thus enabling better >>>> interoperability from the PSTN side into SIP. >>>> The major deficiency of the current draft is its non-standard status. >>>> Functionally, we and our customers find this mechanism to be very usef= ul >>>> and >>>> I'd very much like the IETF to charter the a UUI work group to >>>> standardize >>>> such a mechanism. >>>> James =A0-----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>>> Behalf Of Gonzalo Camarillo >>>> Sent: Wednesday, June 30, 2010 2:51 AM >>>> To: Paul Kyzivat >>>> Cc: dispatch@ietf.org; DRAGE, Keith (Keith); ietf@ietf.org >>>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP >>>> (cuss) >>>> >>>> Hi, >>>> >>>> please keep both the IETF and the DISPATCH mailing lists in the >>>> recipients list in this discussion. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> >>>> On 29/06/2010 8:23 PM, Paul Kyzivat wrote: >>>>> >>>>> DRAGE, Keith (Keith) wrote: >>>>>> >>>>>> The UUI information is NOT ISUP. It is a transparent envelope to the >>>>>> entire ISDN, so it is not part of an ISDN protocol and therefore not >>>>>> part of >>>>>> an ISUP protocol. When carried by ISUP the envelope is bundled up in >>>>>> another >>>>>> envelope with other information that ISUP carries transparently. >>>>>> >>>>>> So I believe, and have said repeatedly in the past, that references = to >>>>>> SIP-T are irrelevant in this case. >>>>>> >>>>>> The problem we do have though is that are legacy usages of this >>>>>> information. In particular applications in PBXs carry it between >>>>>> themselves >>>>>> in ISDN call establishment. The information itself is not >>>>>> standardised. If >>>>>> you want to migrate a PBX from DSS1 to SIP, then you have to take th= is >>>>>> information into account. The desire is not for a WG group to >>>>>> standardise >>>>>> this existing usage (which in my view would be a complete >>>>>> non-starter), but >>>>>> to allow the transfer of the existing information when migrated to a >>>>>> SIP >>>>>> environment. The information transferred does not form part of SIP, >>>>>> and >>>>>> should not be standardised as part of SIP. >>>>> >>>>> How many different mechanisms do we have to construct for the purpose >>>>> of >>>>> tunneling stuff over SIP? >>>>> >>>>> Its especially bad if the stuff is neither standardized nor negotiate= d. >>>>> It then just provides more opportunity for non-interoperability. >>>>> >>>>> It had been my impression that this content was standardized by ITU. >>>>> If nobody can bother to standardize it, then it hardly seems worth >>>>> working on. >>>>> >>>>> =A0 =A0 =A0 Thanks, >>>>> =A0 =A0 =A0 Paul >>>>> >>>>>> regards >>>>>> >>>>>> Keith >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: dispatch-bounces@ietf.org >>>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of >>>>>>> bruno.chatras@orange-ftgroup.com >>>>>>> Sent: Tuesday, June 29, 2010 1:00 PM >>>>>>> To: Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org >>>>>>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI >>>>>>> for SIP (cuss) >>>>>>> >>>>>>> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 >>>>>>> does state that SIP-T does not come into play when there is >>>>>>> no PSTN involved. >>>>>>> >>>>>>> At the end of clause 2 we can read the following: "4. =A0IP >>>>>>> origination - IP termination: This is a case for pure SIP. >>>>>>> SIP-T (either encapsulation or translation of ISUP) does not >>>>>>> come into play as there is no PSTN interworking." >>>>>>> >>>>>>> Besides, SIP-T would require encapsulating a full ISUP >>>>>>> message (e.g. IAM) while we are interested in just one >>>>>>> parameter of the message in the context of CUSS. This would I >>>>>>> believe be a more severe drawback if SIP-T were used for this >>>>>>> purpose. >>>>>>> >>>>>>> Bruno >>>>>>> >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : dispatch-bounces@ietf.org >>>>>>>> [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo Camarillo >>>>>>>> Envoy=E9 : mardi 29 juin 2010 13:03 =C0 : DISPATCH Objet : >>>>>>> >>>>>>> [dispatch] Fwd: >>>>>>>> >>>>>>>> Re: WG Review: Call Control UUI for SIP (cuss) >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> FYI: note the discussion below on the IETF general list. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Gonzalo >>>>>>>> >>>>>>>> -------- Original Message -------- >>>>>>>> Subject: Re: WG Review: Call Control UUI for SIP (cuss) >>>>>>>> Date: Mon, 28 Jun 2010 20:24:23 +0200 >>>>>>>> From: Cullen Jennings >>>>>>>> To: iesg@ietf.org >>>>>>>> CC: IETF Discussion Mailing List >>>>>>>> >>>>>>>> >>>>>>>> As far as I can tell, the WG says they wants to transfer some >>>>>>>> information to achieve cross vendor interoperability. >>>>>>>> However, what I believe the charter is actually going to do >>>>>>> >>>>>>> is exactly >>>>>>>> >>>>>>>> the opposite of that. When you get your head around what >>>>>>> >>>>>>> this charter >>>>>>>> >>>>>>>> is proposing, it is going to form a more or less opaque >>>>>>> >>>>>>> container for >>>>>>>> >>>>>>>> transporting proprietary information in a SIP header. It's hard to >>>>>>>> imagine how this will help interoperability. >>>>>>>> >>>>>>>> If we wanted to have interoperability, the charter would say what >>>>>>>> information needs to be transferred and have the WG define a way t= o >>>>>>>> get it between systems in an operable way. >>>>>>>> What the charter for this WG actually says they are going to do is >>>>>>>> make a special container for transfer proprietary information. >>>>>>>> There's not even willing to say what that proprietary >>>>>>> >>>>>>> information is >>>>>>>> >>>>>>>> used for other than things ISDN UUI which is a =A0non >>>>>>> >>>>>>> interoperable and >>>>>>>> >>>>>>>> fairly proprietary field in ISDN. >>>>>>>> Furthermore they have asserted that =A0existing containers >>>>>>> >>>>>>> such as SIP-T >>>>>>>> >>>>>>>> or SIP bodies can't be used for reasons that are hard to >>>>>>> >>>>>>> describe. (I >>>>>>>> >>>>>>>> reject the idea that because the call might not involved >>>>>>> >>>>>>> the PSTN, it >>>>>>>> >>>>>>>> can't use SIP-T). >>>>>>>> >>>>>>>> I think the folks that want to do this should get a much clear >>>>>>>> explanation of how this results in interoperability and why exist >>>>>>>> approach such as SIP-T will not work before this is chartered. >>>>>>>> >>>>>>>> I do think there is a need to standardize some important >>>>>>> >>>>>>> call control >>>>>>>> >>>>>>>> information used in call centers and related places. >>>>>>>> However, the "we need a standard container to exchange secret >>>>>>>> information WG" is a bad idea and violates the sprit of the >>>>>>> >>>>>>> SIP change >>>>>>>> >>>>>>>> process not to mention the mission of the IETF. >>>>>>>> >>>>>>>> In summary, I'm in favor of figuring out what the problems >>>>>>> >>>>>>> are people >>>>>>>> >>>>>>>> hope to solve with this WG and figuring out a way to write >>>>>>>> interoperable standards to achieve that. However, I think >>>>>>> >>>>>>> this charter >>>>>>>> >>>>>>>> should be rejected by the IESG and sent back to the drawing >>>>>>> >>>>>>> board. The >>>>>>>> >>>>>>>> RAI area has things of higher priority items to work on than a SIP >>>>>>>> header for transfer proprietary data. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote: >>>>>>>> >>>>>>>>> A new IETF working group has been proposed in the Real-time >>>>>>>>> Applications and Infrastructure Area. =A0The IESG has not >>>>>>>> >>>>>>>> made any determination as yet. >>>>>>>>> >>>>>>>>> The following draft charter was submitted, and is provided for >>>>>>>>> informational purposes only. Please send your comments to >>>>>>> >>>>>>> the IESG >>>>>>>>> >>>>>>>>> mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. >>>>>>>>> >>>>>>>>> Call Control UUI for SIP =A0(cuss) >>>>>>>>> -------------------------------------------------- >>>>>>>>> Current Status: Proposed Working Group >>>>>>>>> >>>>>>>>> Last modified: 2010-06-21 >>>>>>>>> >>>>>>>>> Chair(s): >>>>>>>>> =A0TBD >>>>>>>>> >>>>>>>>> Real-time Applications and Infrastructure Area Director(s): >>>>>>>>> =A0Gonzalo Camarillo >>>>>>> >>>>>>> Robert Sparks >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Real-time Applications and Infrastructure Area Advisor: >>>>>>>>> =A0Gonzalo Camarillo >>>>>>>>> >>>>>>>>> Mailing Lists: TBD >>>>>>>>> >>>>>>>>> Description of Working Group: >>>>>>>>> >>>>>>>>> The Call Control UUI for SIP (CUSS) working group is chartered to >>>>>>>>> define a Session Initiation Protocol (SIP) mechanism for >>>>>>>> >>>>>>>> transporting >>>>>>>>> >>>>>>>>> call-control related user-to-user information (UUI) between User >>>>>>>>> Agents. >>>>>>>>> >>>>>>>>> The mechanism developed in this working group is >>>>>>> >>>>>>> applicable in the >>>>>>>>> >>>>>>>>> following situations: >>>>>>>>> >>>>>>>>> 1. The information is generated and consumed by an >>>>>>> >>>>>>> application using >>>>>>>>> >>>>>>>>> =A0SIP during session setup but the application is not necessaril= y >>>>>>>>> =A0even SIP aware. >>>>>>>>> 2. The behavior of SIP entities that support it is not >>>>>>> >>>>>>> significantly >>>>>>>>> >>>>>>>>> =A0changed (as discussed in Section 4 of RFC 5727). >>>>>>>>> 3. Generally only the User Agent Client (UAC) and User >>>>>>> >>>>>>> Agent Server >>>>>>>>> >>>>>>>>> =A0(UAS) are interested in the information. >>>>>>>>> 4. The information is expected to survive retargeting, >>>>>>> >>>>>>> redirection, >>>>>>>>> >>>>>>>>> =A0and transfers. >>>>>>>>> 5. SIP elements may need to apply policy about passing >>>>>>> >>>>>>> and screening >>>>>>>>> >>>>>>>>> =A0the information. >>>>>>>>> 6. Multi-vendor interoperability is important. >>>>>>>>> >>>>>>>>> This mechanism is not applicable in the following situations: >>>>>>>>> >>>>>>>>> 1. The behavior of SIP entities that support it is significantly >>>>>>>>> =A0changed (as discussed in Section 4 of RFC 5727). >>>>>>>>> 2. The information is generated and consumed at the SIP >>>>>>> >>>>>>> layer by SIP >>>>>>>>> >>>>>>>>> =A0elements. >>>>>>>>> 3. SIP elements besides the UAC and UAS might be interested in >>>>>>>>> =A0consuming (beyond applying policy) the information. >>>>>>>>> 4. There are specific privacy issues involved with the informatio= n >>>>>>>>> =A0being transported (e.g., geolocation or emergency-related >>>>>>>>> =A0information). >>>>>>>>> >>>>>>>>> User data of the mechanism will be clearly marked with the >>>>>>>>> application, encoding, semantics, and content type, >>>>>>>> >>>>>>>> allowing policy to >>>>>>>>> >>>>>>>>> be applied by UAs. =A0The working group will define the >>>>>>>> >>>>>>>> information that >>>>>>>>> >>>>>>>>> each application must specify to utilize the mechanism. >>>>>>>> >>>>>>>> This type of >>>>>>>>> >>>>>>>>> application-specific information will be specified in >>>>>>>> >>>>>>>> standards-track >>>>>>>>> >>>>>>>>> documents. >>>>>>>>> >>>>>>>>> One important application of this mechanism is interworking >>>>>>>> >>>>>>>> with the >>>>>>>>> >>>>>>>>> ISDN User to User Information Service. =A0This application >>>>>>> >>>>>>> defined by >>>>>>>>> >>>>>>>>> ITU-T Q.931 is extensively deployed in the PSTN today >>>>>>>> >>>>>>>> supporting such >>>>>>>>> >>>>>>>>> applications as contact centers, call centers, and automatic call >>>>>>>>> distributors (ACDs). =A0A major barrier to the movement of these >>>>>>>>> applications to SIP is the lack of a standard mechanism to >>>>>>>> >>>>>>>> transport >>>>>>>>> >>>>>>>>> this information in SIP. =A0For interworking with ISDN, minimal >>>>>>>>> information about the content of the UUI is available to >>>>>>>> >>>>>>>> the PSTN-SIP >>>>>>>>> >>>>>>>>> gateways. =A0In this case only, the content will just >>>>>>>> >>>>>>>> indicate ISDN UUI >>>>>>>>> >>>>>>>>> Service 1 interworking rather than the actual content. >>>>>>>>> >>>>>>>>> Call control UUI is user information conveyed between user agents >>>>>>>>> during call control operations. =A0As a result, the >>>>>>>> >>>>>>>> information must be >>>>>>>>> >>>>>>>>> conveyed with the INVITE transaction, and must survive proxy >>>>>>>>> retargeting, redirection, and transfers. =A0The mechanism >>>>>>>> >>>>>>>> must utilize a >>>>>>>>> >>>>>>>>> minimum of SIP extensions since it will need to be >>>>>>>> >>>>>>>> supported by many >>>>>>>>> >>>>>>>>> simple SIP user agents such as PSTN gateways. =A0The mechanism mu= st >>>>>>>>> interwork with the existing ISDN service but should also be >>>>>>>> >>>>>>>> extensible >>>>>>>>> >>>>>>>>> for use by other applications and non-ISDN protocols. >>>>>>>>> >>>>>>>>> Even though interworking with the PSTN is an important >>>>>>> >>>>>>> requirement, >>>>>>>>> >>>>>>>>> call control UUI can be exchanged between native SIP >>>>>>>> >>>>>>>> clients that do >>>>>>>>> >>>>>>>>> not have any ISUP support. Therefore, existing SIP-T >>>>>>>>> encapsulation-based approaches defined in RFC3372 do not meet the >>>>>>>>> requirements to transport this type of information. >>>>>>>>> >>>>>>>>> Mechanisms based on the SIP INFO method, RFC2976, will not be >>>>>>>>> considered by the working group since the UUI contents carry >>>>>>>>> information that must be conveyed during session setup at >>>>>>> >>>>>>> the user >>>>>>>>> >>>>>>>>> agent - the information must be conveyed with the INVITE >>>>>>>> >>>>>>>> transaction. >>>>>>>>> >>>>>>>>> The information must be passed with the session setup request >>>>>>>>> (INVITE), responses to that INVITE, or session >>>>>>> >>>>>>> termination requests. >>>>>>>>> >>>>>>>>> As a result, it is not possible to use INFO in these cases. >>>>>>>>> >>>>>>>>> The group will produce: >>>>>>>>> >>>>>>>>> - A problem statement and requirements document for >>>>>>>> >>>>>>>> implementing a SIP >>>>>>>>> >>>>>>>>> call control UUI mechanism >>>>>>>>> >>>>>>>>> - A specification of the SIP extension to best meet those >>>>>>>> >>>>>>>> requirements. >>>>>>>>> >>>>>>>>> Goals and Milestones >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>>> >>>>>>>>> Sep 10 - Problem statement and requirements document to IESG >>>>>>>>> (Informational) >>>>>>>>> Mar 11 - SIP call control UUI specification to IESG (PS) >>>>>>>>> _______________________________________________ >>>>>>>>> IETF-Announce mailing list >>>>>>>>> IETF-Announce@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>>>> >>>>>>>> Cullen Jennings >>>>>>>> For corporate legal information go to: >>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> > From richard@shockey.us Sat Jul 3 11:33:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C5323A684A for ; Sat, 3 Jul 2010 11:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.255 X-Spam-Level: X-Spam-Status: No, score=-0.255 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ywf4V-GVol4t for ; Sat, 3 Jul 2010 11:33:28 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 7933C3A67D0 for ; Sat, 3 Jul 2010 11:33:28 -0700 (PDT) Received: (qmail 20956 invoked by uid 0); 3 Jul 2010 18:33:40 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 3 Jul 2010 18:33:40 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=kkxVDsgmfUri3mvIJRD4UPyhcHCQA2vOzkvMiNukV0CLOxBzUajdHngQjKCXfyG4yRgmqH4DZmrAtkK9ia1i3N29VY70hCb2KUxIYOdyoZm7qDGp13BigWG2DWTdDQX0; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OV7X2-0004WS-Dc; Sat, 03 Jul 2010 12:33:40 -0600 From: "Richard Shockey" To: "'Romascanu, Dan \(Dan\)'" , "'Mary Barnes'" References: In-Reply-To: Date: Sat, 3 Jul 2010 14:33:38 -0400 Message-ID: <001201cb1ade$4195f680$c4c1e380$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsYaEYFoTRFDNeFTEGpj7QmoZE2ywAAL8OAAJ0OhmA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'DISPATCH' , 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 18:33:29 -0000 A we already have centralized solutions for interdomain routing based on E.164. its called ENUM in both its private and public instantiations. It works pretty well BTW and globally deployed. IMHO this charter is a non starter and should not be approved on the basis of this statement alone. "finding domains that claim to be responsible for a given phone number" This IMHO is flat out impossible. Validating or authenticating an entity that is "responsible for a phone number" is as bad as " who is the carrier of record" , is a massive rathole. Cullen and Johathan should know better. Certs? LNP ? We have this problem of E.164 validation all the time in SIP and its not going to be solved in the IETF. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, June 30, 2010 11:33 AM To: Mary Barnes Cc: DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 It looks to me that one can imagine 'centralized' solutions which are also based on reusing SIP related functionality developed in RAI. I would rather not close such an option and allow the WG a window of opportunity in which alternate solutions that could meet the same goals can be presented. Dan > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > Sent: Wednesday, June 30, 2010 6:24 PM > To: Romascanu, Dan (Dan) > Cc: DISPATCH; IETF-Discussion list > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > Hi Dan, > > The term peer to peer is intended to exclude mechanisms that > would use a central repository for the information: This was > discussed in an earlier thread: > http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html > > In one sense it is a solution, however, in another sense it > is reusing SIP related functionality defined in RAI and thus > is in a similar vein as specifying the use of SIP in a charter. > > Thanks, > Mary. > > On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) > wrote: > >> The VIPR WG will address this problem by developing a peer to peer > >> based approach to finding domains that claim to be > responsible for a > >> given phone number and validation protocols to ensure a reasonable > >> likelihood that a given domain actually is responsible for > the phone > >> number. > > > > Hi, > > > > Clarification question. What exactly means 'peer to peer > based approach' > > and what kind of approaches are excluded by having this in > the charter. > > Does 'approach' mean solution? If so why does a specific type of > > solution need to be agreed in the charter, while all we > have at hand > > at this point are individual contribution I-Ds that describe the > > 'problem statement and some possible starting points for solutions'? > > > > Thanks and Regards, > > > > Dan > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > >> Sent: Monday, June 28, 2010 8:38 PM > >> To: DISPATCH > >> Subject: [dispatch] VIPR - proposed charter version 3 > >> > > > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From tom111.taylor@bell.net Sat Jul 3 13:08:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D2B63A6911 for ; Sat, 3 Jul 2010 13:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.851 X-Spam-Level: X-Spam-Status: No, score=0.851 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XcOHO3WMnTs for ; Sat, 3 Jul 2010 13:08:14 -0700 (PDT) Received: from blu0-omc4-s10.blu0.hotmail.com (blu0-omc4-s10.blu0.hotmail.com [65.55.111.149]) by core3.amsl.com (Postfix) with ESMTP id B0C913A68EE for ; Sat, 3 Jul 2010 13:08:14 -0700 (PDT) Received: from BLU0-SMTP31 ([65.55.111.135]) by blu0-omc4-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 3 Jul 2010 13:08:26 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP31.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sat, 3 Jul 2010 13:08:26 -0700 Date: Sat, 03 Jul 2010 16:08:23 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Marshall Eubanks References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C6538049202030CA48E@XMB-BGL-414.cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2010 20:08:26.0794 (UTC) FILETIME=[7F7100A0:01CB1AEB] Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 20:08:15 -0000 Perhaps even a taxonomy would be helpful -- SBC vendors could check off which of the identified functions their box performs. Some functions may be susceptible to standardization, and perhaps others might not be. Marshall Eubanks wrote: > > On Jul 2, 2010, at 8:53 AM, Christer Holmberg wrote: > >> Hi, >> >> Could you describe what you think the problems are, and why you think >> they are caused by SBCs? > > Whose SBCs ? > > More fundamentally, what is an SBC ? What should it do ? > > In my operational experience, I have seen a wide variety of answers to > those questions. The 3GPP world may be an exception (I don't know), but > from what I see SBC's are hard to interoperate with because first you > have to figure out just what they are doing. > > Now, maybe this is something that the IETF shouldn't get involved in, > but it would be nice to have a standard that vendors followed, and I am > not sure where else this would come from. > > Regards > Marshall > ... From petithug@acm.org Sat Jul 3 13:39:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B06A3A68E7; Sat, 3 Jul 2010 13:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.666 X-Spam-Level: X-Spam-Status: No, score=-99.666 tagged_above=-999 required=5 tests=[IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pn1ExYZo9Ulr; Sat, 3 Jul 2010 13:39:18 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id CD5693A68DF; Sat, 3 Jul 2010 13:39:14 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 11396DBCC050; Sat, 3 Jul 2010 20:39:14 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 01B0BDBCC04E; Sat, 3 Jul 2010 20:39:11 +0000 (UTC) Message-ID: <4C2F9FEF.4040706@acm.org> Date: Sat, 03 Jul 2010 13:39:11 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Iceowl/1.0b1 Icedove/3.0.5 MIME-Version: 1.0 To: Richard Shockey References: <001201cb1ade$4195f680$c4c1e380$@us> In-Reply-To: <001201cb1ade$4195f680$c4c1e380$@us> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: 'DISPATCH' , 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 20:39:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/03/2010 11:33 AM, Richard Shockey wrote: > A we already have centralized solutions for interdomain routing based on > E.164. its called ENUM in both its private and public instantiations. It > works pretty well BTW and globally deployed. $ host -t NAPTR 7.8.2.4.9.2.3.8.0.4.1.e164.arpa. Host 7.8.2.4.9.2.3.8.0.4.1.e164.arpa. not found: 3(NXDOMAIN) Until this request succeeds, I am supporting the creation of the ViPR WG. > > IMHO this charter is a non starter and should not be approved on the basis > of this statement alone. > > "finding domains that claim to be responsible for a given phone number" > > This IMHO is flat out impossible. Validating or authenticating an entity > that is "responsible for a phone number" is as bad as " who is the carrier > of record" , is a massive rathole. Cullen and Johathan should know better. > Certs? LNP ? > > We have this problem of E.164 validation all the time in SIP and its not > going to be solved in the IETF. > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf > Of Romascanu, Dan (Dan) > Sent: Wednesday, June 30, 2010 11:33 AM > To: Mary Barnes > Cc: DISPATCH; IETF-Discussion list > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > It looks to me that one can imagine 'centralized' solutions which are > also based on reusing SIP related functionality developed in RAI. I > would rather not close such an option and allow the WG a window of > opportunity in which alternate solutions that could meet the same goals > can be presented. > > Dan > > >> -----Original Message----- >> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >> Sent: Wednesday, June 30, 2010 6:24 PM >> To: Romascanu, Dan (Dan) >> Cc: DISPATCH; IETF-Discussion list >> Subject: Re: [dispatch] VIPR - proposed charter version 3 >> >> Hi Dan, >> >> The term peer to peer is intended to exclude mechanisms that >> would use a central repository for the information: This was >> discussed in an earlier thread: >> http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html >> >> In one sense it is a solution, however, in another sense it >> is reusing SIP related functionality defined in RAI and thus >> is in a similar vein as specifying the use of SIP in a charter. >> >> Thanks, >> Mary. >> >> On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) >> wrote: >>>> The VIPR WG will address this problem by developing a peer to peer >>>> based approach to finding domains that claim to be >> responsible for a >>>> given phone number and validation protocols to ensure a reasonable >>>> likelihood that a given domain actually is responsible for >> the phone >>>> number. >>> >>> Hi, >>> >>> Clarification question. What exactly means 'peer to peer >> based approach' >>> and what kind of approaches are excluded by having this in >> the charter. >>> Does 'approach' mean solution? If so why does a specific type of >>> solution need to be agreed in the charter, while all we >> have at hand >>> at this point are individual contribution I-Ds that describe the >>> 'problem statement and some possible starting points for solutions'? >>> >>> Thanks and Regards, >>> >>> Dan >>> - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwvn94ACgkQ9RoMZyVa61dAtwCgj2cDYsio0KOLKt7ZNj8Y7UA4 2Y4AnA1IQwRvzhbuePxXU2XYh9v8DSyh =cUj9 -----END PGP SIGNATURE----- From peter.musgrave@magorcorp.com Sat Jul 3 14:48:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EDEB3A6853; Sat, 3 Jul 2010 14:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PB+Qi-i8eBDW; Sat, 3 Jul 2010 14:48:48 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id B592A3A684E; Sat, 3 Jul 2010 14:48:47 -0700 (PDT) Received: by qyk2 with SMTP id 2so896589qyk.10 for ; Sat, 03 Jul 2010 14:48:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.95.225 with SMTP id e33mr350472qan.331.1278193724068; Sat, 03 Jul 2010 14:48:44 -0700 (PDT) Received: by 10.229.220.10 with HTTP; Sat, 3 Jul 2010 14:48:43 -0700 (PDT) In-Reply-To: <001201cb1ade$4195f680$c4c1e380$@us> References: <001201cb1ade$4195f680$c4c1e380$@us> Date: Sat, 3 Jul 2010 17:48:43 -0400 Message-ID: From: Peter Musgrave To: Richard Shockey Content-Type: multipart/alternative; boundary=00c09f99de73e0a767048a82aacb Cc: DISPATCH , IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Jul 2010 21:48:54 -0000 --00c09f99de73e0a767048a82aacb Content-Type: text/plain; charset=ISO-8859-1 Hi Richard, Clearly we don't want to be trying to solve the impossible - that could take a really long time. The mechanism in the ViPR drafts seemed to be able to accomplish the "finding the party responsible for a number" - and IIRC this is based on *running code* in the Cisco IME. ViPR is frankly not beautiful (in the way ICE is not beautiful) but I do think it can solve a problem which needs to be solved. Hence I support it. Peter Musgrave On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey wrote: > A we already have centralized solutions for interdomain routing based on > E.164. its called ENUM in both its private and public instantiations. It > works pretty well BTW and globally deployed. > > IMHO this charter is a non starter and should not be approved on the basis > of this statement alone. > > "finding domains that claim to be responsible for a given phone number" > > This IMHO is flat out impossible. Validating or authenticating an entity > that is "responsible for a phone number" is as bad as " who is the carrier > of record" , is a massive rathole. Cullen and Johathan should know better. > Certs? LNP ? > > We have this problem of E.164 validation all the time in SIP and its not > going to be solved in the IETF. > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf > Of Romascanu, Dan (Dan) > Sent: Wednesday, June 30, 2010 11:33 AM > To: Mary Barnes > Cc: DISPATCH; IETF-Discussion list > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > It looks to me that one can imagine 'centralized' solutions which are > also based on reusing SIP related functionality developed in RAI. I > would rather not close such an option and allow the WG a window of > opportunity in which alternate solutions that could meet the same goals > can be presented. > > Dan > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > Sent: Wednesday, June 30, 2010 6:24 PM > > To: Romascanu, Dan (Dan) > > Cc: DISPATCH; IETF-Discussion list > > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > > > Hi Dan, > > > > The term peer to peer is intended to exclude mechanisms that > > would use a central repository for the information: This was > > discussed in an earlier thread: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html > > > > In one sense it is a solution, however, in another sense it > > is reusing SIP related functionality defined in RAI and thus > > is in a similar vein as specifying the use of SIP in a charter. > > > > Thanks, > > Mary. > > > > On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) > > wrote: > > >> The VIPR WG will address this problem by developing a peer to peer > > >> based approach to finding domains that claim to be > > responsible for a > > >> given phone number and validation protocols to ensure a reasonable > > >> likelihood that a given domain actually is responsible for > > the phone > > >> number. > > > > > > Hi, > > > > > > Clarification question. What exactly means 'peer to peer > > based approach' > > > and what kind of approaches are excluded by having this in > > the charter. > > > Does 'approach' mean solution? If so why does a specific type of > > > solution need to be agreed in the charter, while all we > > have at hand > > > at this point are individual contribution I-Ds that describe the > > > 'problem statement and some possible starting points for solutions'? > > > > > > Thanks and Regards, > > > > > > Dan > > > > > > > > >> -----Original Message----- > > >> From: dispatch-bounces@ietf.org > > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > > >> Sent: Monday, June 28, 2010 8:38 PM > > >> To: DISPATCH > > >> Subject: [dispatch] VIPR - proposed charter version 3 > > >> > > > > > > _______________________________________________ > 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 > --00c09f99de73e0a767048a82aacb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Richard,

Clearly we don't want to be trying= to solve the impossible - that could take a really long time.=A0

<= /div>
The mechanism in the ViPR drafts seemed to be able to accomplish = the "finding the party responsible for a number" - and IIRC this = is based on *running code* in the Cisco IME.=A0

ViPR is frankly not beautiful (in the way ICE is not be= autiful) but I do think it can solve a problem which needs to be solved. He= nce I support it.=A0

Peter Musgrave

On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey <richard@shockey.us> wrote:
A we already have centralized solutions for interdomain routing based on E.164. its called ENUM in both its private and public instantiations. It works pretty well BTW and globally deployed.

IMHO this charter is a non starter and should not be approved on the basis<= br> of this statement alone.

"finding domains that claim to be responsible for a given phone number= "

This IMHO is flat out impossible. Validating or authenticating an entity that is "responsible for a phone number" is as bad as =A0" w= ho is the carrier
of record" , is a massive rathole. Cullen and Johathan should know bet= ter.
Certs? LNP ?

We have this problem of E.164 validation all the time in SIP and its not going to be solved in the IETF.

-----Original Message-----
From: dispatch-bounces@ietf.or= g [mailto:dispatch-bounces= @ietf.org] On Behalf
Of Romascanu, Dan (Dan)
Sent: Wednesday, June 30, 2010 11:33 AM
To: Mary Barnes
Cc: DISPATCH; IETF-Discussion list
Subject: Re: [dispatch] VIPR - proposed charter version 3

It looks to me that one can imagine 'centralized' solutions which a= re
also based on reusing SIP related functionality developed in RAI. I
would rather not close such an option and allow the WG a window of
opportunity in which alternate solutions that could meet the same goals
can be presented.

Dan


> -----Original Message-----
> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> Sent: Wednesday, June 30, 2010 6:24 PM
> To: Romascanu, Dan (Dan)
> Cc: DISPATCH; IETF-Discussion list
> Subject: Re: [dispatch] VIPR - proposed charter version 3
>
> Hi Dan,
>
> The term peer to peer is intended to exclude mechanisms that
> would use a central repository for the information: =A0This was
> discussed in an earlier thread:
> http://www.ietf.org/mail-archive/web/dispatch/c= urrent/msg02027.html
>
> In one sense it is a solution, however, in another sense it
> is reusing SIP related functionality defined in RAI and thus
> is in a similar vein as specifying the use of SIP in a charter.
>
> Thanks,
> Mary.
>
> On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan)
> <dromasca@avaya.com> w= rote:
> >> The VIPR WG will address this problem by developing a peer to= peer
> >> based approach to finding domains that claim to be
> responsible for a
> >> given phone number and validation protocols to ensure a reaso= nable
> >> likelihood that a given domain actually is responsible for > the phone
> >> number.
> >
> > Hi,
> >
> > Clarification question. What exactly means 'peer to peer
> based approach'
> > and what kind of approaches are excluded by having this in
> the charter.
> > Does 'approach' mean solution? If so why does a specific = type of
> > solution need to be agreed in the charter, while all we
> have at hand
> > at this point are individual contribution I-Ds that describe the<= br> > > 'problem statement and some possible starting points for solu= tions'?
> >
> > Thanks and Regards,
> >
> > Dan
> >
> >
> >> -----Original Message-----
> >> From: dispatch-b= ounces@ietf.org
> >> [mailto:dispatch= -bounces@ietf.org] On Behalf Of Mary Barnes
> >> Sent: Monday, June 28, 2010 8:38 PM
> >> To: DISPATCH
> >> Subject: [dispatch] VIPR - proposed charter version 3
> >>
> >
>
_______________________________________________
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

--00c09f99de73e0a767048a82aacb-- From richard@shockey.us Sun Jul 4 13:48:57 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11A2F3A68D4 for ; Sun, 4 Jul 2010 13:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJCeqiok-f7M for ; Sun, 4 Jul 2010 13:48:47 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id BEFA13A67A3 for ; Sun, 4 Jul 2010 13:48:47 -0700 (PDT) Received: (qmail 23165 invoked by uid 0); 4 Jul 2010 20:48:48 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 4 Jul 2010 20:48:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=IgKKOffrQlcZr8eXS30O3HApg8ptn8su12LISq2W2YO4jj6dDbD3N8D1F9uLvXSEYVuKtfeuZ5YDrd4p3+5ixI287YGKv7T2miw24ovqJJtPu2k9tQqrFIjbRIXBWvC8; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OVW7L-00044a-IW; Sun, 04 Jul 2010 14:48:48 -0600 From: "Richard Shockey" To: "'Peter Musgrave'" References: <001201cb1ade$4195f680$c4c1e380$@us> In-Reply-To: Date: Sun, 4 Jul 2010 16:48:45 -0400 Message-ID: <009f01cb1bba$4c7bcd40$e57367c0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A0_01CB1B98.C56A2D40" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acsa+YKSMZB7klnsTFyT3CbXkJPHXgAvFYfw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'DISPATCH' , 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2010 20:48:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A0_01CB1B98.C56A2D40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Well folks can certainly do what they want to do. And the IETF has a lamentable record of some protocols that don't accomplish much. But the core of this proposed WG is based on a fallacy. ViPR cannot verify or authenticate the responsible party for a E.164 number. It is incapable of doing so since there is no possible administrative chain of trust other than self assertion . Hence the possibility of identity or number/session hijacking is very large. You have to have the cooperation of the national numbering authorities or the issuer of the phone number to authenticate who is the responsible party . ViPR doesn't change that problem either. This has been a well known problem in SIP for some time and that was part of the difficulties that public ENUM had in e164.arpa. ENUM is doing very well BTW as a SS7/TCAP replacement however in private trees BTW. Consequently I think this issue has to be fully defined in the charter and I will gleefully anticipate what the security considerations text will look like. The fact that there is CISCO running code is utterly irrelevant. There is lots of bad code out there. I understand the problem of how do you create SIP federations across domains outside the scope of service providers, but without a comprehensive trust model this is going to fail. I do understand that many folks don't like their voice service providers or PSTN that perpetuates the use of E.164 numbers but this proposal is not going to solve that. IMHO in the absence of any rational trust or security model you can certainly publish something as Informational but getting something past the IESG is another thing entirely. From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] Sent: Saturday, July 03, 2010 5:49 PM To: Richard Shockey Cc: Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 Hi Richard, Clearly we don't want to be trying to solve the impossible - that could take a really long time. The mechanism in the ViPR drafts seemed to be able to accomplish the "finding the party responsible for a number" - and IIRC this is based on *running code* in the Cisco IME. ViPR is frankly not beautiful (in the way ICE is not beautiful) but I do think it can solve a problem which needs to be solved. Hence I support it. Peter Musgrave On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey wrote: A we already have centralized solutions for interdomain routing based on E.164. its called ENUM in both its private and public instantiations. It works pretty well BTW and globally deployed. IMHO this charter is a non starter and should not be approved on the basis of this statement alone. "finding domains that claim to be responsible for a given phone number" This IMHO is flat out impossible. Validating or authenticating an entity that is "responsible for a phone number" is as bad as " who is the carrier of record" , is a massive rathole. Cullen and Johathan should know better. Certs? LNP ? We have this problem of E.164 validation all the time in SIP and its not going to be solved in the IETF. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, June 30, 2010 11:33 AM To: Mary Barnes Cc: DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 It looks to me that one can imagine 'centralized' solutions which are also based on reusing SIP related functionality developed in RAI. I would rather not close such an option and allow the WG a window of opportunity in which alternate solutions that could meet the same goals can be presented. Dan > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > Sent: Wednesday, June 30, 2010 6:24 PM > To: Romascanu, Dan (Dan) > Cc: DISPATCH; IETF-Discussion list > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > Hi Dan, > > The term peer to peer is intended to exclude mechanisms that > would use a central repository for the information: This was > discussed in an earlier thread: > http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html > > In one sense it is a solution, however, in another sense it > is reusing SIP related functionality defined in RAI and thus > is in a similar vein as specifying the use of SIP in a charter. > > Thanks, > Mary. > > On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) > wrote: > >> The VIPR WG will address this problem by developing a peer to peer > >> based approach to finding domains that claim to be > responsible for a > >> given phone number and validation protocols to ensure a reasonable > >> likelihood that a given domain actually is responsible for > the phone > >> number. > > > > Hi, > > > > Clarification question. What exactly means 'peer to peer > based approach' > > and what kind of approaches are excluded by having this in > the charter. > > Does 'approach' mean solution? If so why does a specific type of > > solution need to be agreed in the charter, while all we > have at hand > > at this point are individual contribution I-Ds that describe the > > 'problem statement and some possible starting points for solutions'? > > > > Thanks and Regards, > > > > Dan > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > >> Sent: Monday, June 28, 2010 8:38 PM > >> To: DISPATCH > >> Subject: [dispatch] VIPR - proposed charter version 3 > >> > > > _______________________________________________ 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_00A0_01CB1B98.C56A2D40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well folks can certainly do what they want to do. And the = IETF has a lamentable record of some protocols that don’t accomplish = much. But the core of this proposed WG is based on a fallacy. ViPR cannot verify = or authenticate the responsible party for a E.164 number. It is incapable = of doing so since there is no possible administrative chain of trust other than = self assertion .  Hence the possibility of identity or number/session = hijacking is very large. You have to have the cooperation of the national = numbering authorities or the issuer of the phone number to authenticate who is the responsible party . ViPR doesn’t change that problem = either.

 

This has been a well known problem in SIP for some time = and that was part of the difficulties that public ENUM had in e164.arpa. ENUM is = doing very well BTW as a SS7/TCAP replacement however in private trees BTW. =

 

Consequently I think this issue has to be fully defined = in the charter and I will gleefully anticipate what the security considerations = text will look like.

 

The fact that there is CISCO running code is utterly = irrelevant. There is lots of bad code out there.  I understand the problem of = how do you create SIP federations across domains outside the scope of service providers, but without a comprehensive trust model this is going to = fail.  I do understand that many folks don’t like their voice service = providers or PSTN that perpetuates the use of E.164 numbers but this proposal is not = going to solve that.

 

IMHO in the absence of any rational trust or security = model you can certainly publish something as Informational but getting something past = the IESG is another thing entirely.

 

From:= Peter = Musgrave [mailto:peter.musgrave@magorcorp.com]
Sent: Saturday, July 03, 2010 5:49 PM
To: Richard Shockey
Cc: Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion = list
Subject: Re: [dispatch] VIPR - proposed charter version = 3

 

Hi Richard,

 

Clearly we don't want to be trying to solve the = impossible - that could take a really long time. 

 

The mechanism in the ViPR drafts seemed to be able = to accomplish the "finding the party responsible for a number" - = and IIRC this is based on *running code* in the Cisco = IME. 

 

ViPR is frankly not beautiful (in the way ICE is = not beautiful) but I do think it can solve a problem which needs to be = solved. Hence I support it. 

 

Peter = Musgrave

On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey = <richard@shockey.us> = wrote:

A we already have centralized solutions for = interdomain routing based on
E.164. its called ENUM in both its private and public instantiations. = It
works pretty well BTW and globally deployed.

IMHO this charter is a non starter and should not be approved on the = basis
of this statement alone.

"finding domains that claim to be responsible for a given phone number"

This IMHO is flat out impossible. Validating or authenticating an = entity
that is "responsible for a phone number" is as bad as =  " who is the carrier
of record" , is a massive rathole. Cullen and Johathan should know = better.
Certs? LNP ?

We have this problem of E.164 validation all the time in SIP and its = not
going to be solved in the IETF.

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf
Of Romascanu, Dan (Dan)
Sent: Wednesday, June 30, 2010 11:33 AM
To: Mary Barnes
Cc: DISPATCH; IETF-Discussion list
Subject: Re: [dispatch] VIPR - proposed charter version 3

It looks to me that one can imagine 'centralized' solutions which = are
also based on reusing SIP related functionality developed in RAI. I
would rather not close such an option and allow the WG a window of
opportunity in which alternate solutions that could meet the same = goals
can be presented.

Dan


> -----Original Message-----
> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com= ]
> Sent: Wednesday, June 30, 2010 6:24 PM
> To: Romascanu, Dan (Dan)
> Cc: DISPATCH; IETF-Discussion list
> Subject: Re: [dispatch] VIPR - proposed charter version 3
>
> Hi Dan,
>
> The term peer to peer is intended to exclude mechanisms that
> would use a central repository for the information:  This = was
> discussed in an earlier thread:
> http://www.ietf.org/mail-archive/web/dispatch/current/m= sg02027.html
>
> In one sense it is a solution, however, in another sense it
> is reusing SIP related functionality defined in RAI and thus
> is in a similar vein as specifying the use of SIP in a charter.
>
> Thanks,
> Mary.
>
> On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan)
> <dromasca@avaya.com> wrote:
> >> The VIPR WG will address this problem by developing a peer = to peer
> >> based approach to finding domains that claim to be
> responsible for a
> >> given phone number and validation protocols to ensure a reasonable
> >> likelihood that a given domain actually is responsible = for
> the phone
> >> number.
> >
> > Hi,
> >
> > Clarification question. What exactly means 'peer to peer
> based approach'
> > and what kind of approaches are excluded by having this in
> the charter.
> > Does 'approach' mean solution? If so why does a specific type = of
> > solution need to be agreed in the charter, while all we
> have at hand
> > at this point are individual contribution I-Ds that describe = the
> > 'problem statement and some possible starting points for = solutions'?
> >
> > Thanks and Regards,
> >
> > Dan
> >
> >
> >> -----Original Message-----
> >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes
> >> Sent: Monday, June 28, 2010 8:38 PM
> >> To: DISPATCH
> >> Subject: [dispatch] VIPR - proposed charter version 3
> >>
> >
>
_______________________________________________
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_00A0_01CB1B98.C56A2D40-- From richard@shockey.us Sun Jul 4 18:05:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECA553A680C for ; Sun, 4 Jul 2010 18:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzHnlvzGApSM for ; Sun, 4 Jul 2010 18:05:28 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id E5B2D3A67E3 for ; Sun, 4 Jul 2010 18:05:27 -0700 (PDT) Received: (qmail 6779 invoked by uid 0); 5 Jul 2010 01:05:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 5 Jul 2010 01:05:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=ePjCmyG1XN6ANqT64OSfKiszYbHm9Xz6UIH3gPcNX4EcRRmIvs97iY8c4UVmKmy2MeTeO7W4Tn9s4udq8hJiHOsWU7dyokzjiSZCY1vIBMywQVIfmPKpXNFwPw6zYrtm; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OVa7k-00075N-B5; Sun, 04 Jul 2010 19:05:28 -0600 From: "Richard Shockey" To: "'WORLEY, Dale R \(Dale\)'" , "'Muthu ArulMozhi Perumal \(mperumal\)'" , "'DISPATCH list'" References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> In-Reply-To: Date: Sun, 4 Jul 2010 21:05:26 -0400 Message-ID: <010201cb1bde$27fe54a0$77fafde0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsZQqNEprRLxVMETZSSd7Xx2jr+0wADHsSeAKOM1qA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 01:05:29 -0000 Well the reasons SBC's exist is that the definitions of SIP in the RAI directorate and 3GPP/IMS are out of control and since nature abhors a vacuum SBC's fill that void at the edge of SIP networks. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of WORLEY, Dale R (Dale) Sent: Thursday, July 01, 2010 2:57 PM To: Muthu ArulMozhi Perumal (mperumal); DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Muthu ArulMozhi Perumal (mperumal) [mperumal@cisco.com] I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to the one for NATs, to set guidelines and identify best current practices to encourage better SBC implementations, interoperability and ease of troubleshooting, rather than just keeping quiet and letting them go out of control. ________________________________________ This is a good idea. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From allyn@cisco.com Sun Jul 4 21:15:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DEC33A6888 for ; Sun, 4 Jul 2010 21:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYdmP8jTKgzW for ; Sun, 4 Jul 2010 21:14:55 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B61853A6886 for ; Sun, 4 Jul 2010 21:14:55 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQFACP5MEyrR7Ht/2dsb2JhbACBQp4mcaNMmUSCXIJJBIMhV4Zu X-IronPort-AV: E=Sophos;i="4.53,537,1272844800"; d="scan'208,217";a="221576364" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 05 Jul 2010 04:14:56 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o654EuZ8016127; Mon, 5 Jul 2010 04:14:56 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 4 Jul 2010 21:14:56 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1BF8.9FDCFE6F" x-cr-hashedpuzzle: AeEj Gwmw HXFT IT4O K5I7 NMnV O+AM PAQc P0PP W7QG X97M Ybwe bB9J b6H6 fO9N jdpX; 3; YQBsAGUAeABAAHYAaQBkAHkAbwAuAGMAbwBtADsAZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnADsAaABhAGsAbwBuAC4AZABhAGgAbABlAEAAdABhAG4AZABiAGUAcgBnAC4AYwBvAG0A; Sosha1_v1; 7; {06E0ED1F-4474-44D2-9DFD-1D0B8166FE93}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 05 Jul 2010 04:14:38 GMT; QwBoAGEAcgB0AGUAcgAgAGYAbwByACAAVABlAGwAZQBwAHIAZQBzAGUAbgBjAGUAIABtAHUAbAB0AGkALQBzAHQAcgBlAGEAbQBzACAALQAgAHQAaABpAHIAZAAgAHYAZQByAHMAaQBvAG4A x-cr-puzzleid: {06E0ED1F-4474-44D2-9DFD-1D0B8166FE93} Content-class: urn:content-classes:message Date: Sun, 4 Jul 2010 21:14:38 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Charter for Telepresence multi-streams - third version Thread-Index: Acsb+JW+Ek1HtYEDRs6gZWIUXT8oZQ== From: "Allyn Romanow (allyn)" To: X-OriginalArrivalTime: 05 Jul 2010 04:14:56.0207 (UTC) FILETIME=[A019B5F0:01CB1BF8] Subject: [dispatch] Charter for Telepresence multi-streams - third version X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 04:15:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1BF8.9FDCFE6F Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, This makes the change discussed replacing the text in the third = paragraph under the Charter section with the text suggested on the list. = It also changes title from "... Description of Work" to "...Charter" =20 There weren't any further changes suggested. =20 Thanks, Allyn =20 =20 =20 =20 Multi-streams for Telepresence Charter =20 =20 =20 Background One branch of video conferencing has evolved that is focused on = immersive "being there" experience. Referred to in various ways such as = virtual conferencing, telepresence or media spaces, early systems were = mainly research projects or business systems with limited deployments. = In recent years telepresence systems have seen considerable market = success. Following the model of early systems, the first wave of = commercial systems have been typically located in specially designed = single-purpose rooms with multiple relatively large displays permitting = life size image reproduction, multiple cameras, encoders, decoders and = microphones. These systems have several important characteristics that = are different from more traditional video conferencing systems. =20 =20 The first difference concerns controlling the visual viewpoint in order = to improve participant nonverbal communication. These systems preserve = essential group meeting characteristics such as eye contact, group = gestures, seating order and spatial audio by carefully orchestrating the = miking and camera angles at each of the sites . This is distinct from = the more traditional approach where the geometric relationship between = media streams is not used to preserve inter-stream communication aspects = such as eye contact and group dynamics. =20 =20 A second difference is manipulation of the environment to improve = immersion. With telepresence systems, cinematographic aspects of the = local environment reproduction are carefully planned including color, = table shape, seating and lighting so that when combined with large high = quality displays, a strong sense of a "trompe l'oeil" or "being there" = immersive experience is created. Typical video conference systems do = not include these considerations. =20 As telepresence video systems have become successful in the market, = manufacturers have started exploring delivery of the nonverbal = communication and immersive values of telepresence via smaller, less = expensive and more flexible video conferencing systems for a variety of = venues, such as individual offices, homes and kiosks. These are also = telepresence systems, since the audio and video quality is high enough = to allow clear image reproduction for nonverbal communication, they are = able to send and receive multiple media streams, and large coordinated = multi image displays are available for immersive installations. As the = industry develops, the line between telepresence and video conferencing = may become blurred as nonverbal communication and immersive = installations become broadly available. =20 Problem Although telepresence systems are based on open standards such as RTP, = SIP, H.264, H.323 suite, they cannot easily interoperate with each other = without operator assistance and expensive additional equipment that = translates from one vendor to another. It would be like having to make = sure all parties are on the same equipment (and network) when making a = telephone call. A major factor in the inability of Telepresence systems = to work with each other is that there is no standard description of the = multiple streams that comprise the media flows.=20 =20 For example, in a multiple screen conference, the video and audio = streams sent from remote participants must be understood by receivers so = that they can be presented in a coherent and life-like manner. This = includes the ability to present the remote participants at their true = size for their apparent distance, while maintaining correct eye contact, = gesticular cues, and simultaneously providing a spatial audio sound = stage consistent with the video presentation. The receiving device that = decides how to display the incoming information needs to understand a = number of variables such as the spatial position of the speaker, the = field of view of the cameras, the camera zoom, which media stream is = related to each of the displays, etc.=20 =20 Charter The Telepresence Multi-Streams work item in DISPATCH is chartered to = define and specify for SIP-based systems the content of media = multi-stream messages and the way these will be transported.=20 =20 This work will provide a standard for the exchange of media semantic = information that will foster interoperable end stations and conference = bridges. It will specify variables that describe the semantics of the = media streams and the recommended behavior to achieve interoperability. = =20 =20 This requires considering current widely deployed use cases, as well as = cases that are expected to be implemented using the protocol framework = produced by this work item. The methodology for describing the = variables must allow extensibility of the variables, since telepresence = is still a young technology and may have use cases that are not = currently considered." =20 =20 The work item will identify use cases, define requirements, and define a = method for describing and transporting information about multiple media = streams, including a specification of variables required to support the = use cases. This work item will consider the reuse of existing IETF = protocols and produce an architecture/protocol framework document = describing the protocols required to be implemented to support this = functionality. The document will identify any enhancements required to = existing protocols as well as describing new protocol(s) for = interoperable multi-streams negotiation that may be required. =20 Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and = FECframe. =20 =20 Scope The scope includes both systems that provide a fully immersive = experience, and systems that interwork with them and therefore need to = understand the same multiple stream semantics. =20 =20 The focus of this work is on audio and video multiple streams. Other = media types may be considered, however development of methodologies for = them is not within the scope of this work. =20 Interoperation with standards compliant systems is required, such as = SIP-based video conferencing systems. However, backwards compatibility = with existing non-standards compliant telepresence systems is not = required. =20 =20 =20 The group will produce - Requirements and use cases =20 - Architectural Framework describing the protocols required to be = implemented to support this functionality and identifying existing = protocol enhancements and new protocol functionality required =20 - Specification of a new protocol to support telepresence multi-streams = [if required] =20 Goals and Milestones Nov 2010=20 =20 Use Cases and Requirements to IESG as Informational RFC=20 Nov 2010 March 2011=20 Problem Statement to IESG as Informational RFC Architecture to IESG as Informational RFC=20 March 2011 Revise Charter [IF new protocol is not required] Nov 2011=20 Submit protocol draft to IESG as Proposed Standard RFC=20 =20 ------_=_NextPart_001_01CB1BF8.9FDCFE6F Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Folks,

This makes the change discussed replacing the text in the third paragraph under the Charter section with the text suggested on the list. =

It = also changes title from “… Description of Work” to = “…Charter”

 

There weren’t any further changes suggested.

 

Thanks,

Allyn

 

 

 

 

Multi-streams for = Telepresence Charter

 

 

 

Background

One branch of video conferencing has evolved that is focused on immersive “being there” experience.  Referred to in various ways such as = virtual conferencing, telepresence or media spaces, early systems were mainly = research projects or business systems with limited deployments.  In recent = years telepresence systems have seen considerable market success.  = Following the model of early systems, the first wave of commercial systems have been = typically located in specially designed single-purpose rooms with multiple = relatively large displays permitting life size image reproduction, multiple = cameras, encoders, decoders and microphones.  These systems have several = important characteristics that are different from more traditional video = conferencing systems. 

 

The first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential = group meeting characteristics such as eye contact, group gestures, seating = order and spatial audio by carefully orchestrating the miking and camera angles at = each of the sites . This is distinct from the more traditional approach where = the geometric relationship between media streams is not used to preserve = inter-stream communication aspects such as eye contact and group dynamics.  =

 

A = second difference is manipulation of the environment to improve = immersion.  With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating = and lighting so that when combined with large high quality displays, a = strong sense of a "trompe l'oeil" or "being there" immersive = experience is created.  Typical video conference systems do not include these = considerations.

 

As telepresence video systems have become successful in the market, = manufacturers have started exploring delivery of the nonverbal communication and = immersive values of telepresence via smaller, less expensive and more flexible = video conferencing systems for a variety of venues, such as individual = offices, homes and kiosks. These are also=A0 telepresence systems, since the audio and = video quality is high enough to allow clear image reproduction for nonverbal communication, they are able to send and receive multiple media streams, = and large coordinated multi image displays are available for immersive installations.   As the industry develops, the line between telepresence and video conferencing may become blurred as nonverbal = communication and immersive installations become broadly = available.

 

Problem<= /p>

Although telepresence systems are based on open standards such as RTP, SIP, = H.264, H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one = vendor to another. It would be like having to make sure all parties are on the = same equipment (and network) when making a telephone call. =A0A major factor = in the inability of Telepresence systems to work with each other is that there = is no standard description of the multiple streams that comprise the media = flows.

 

For example, in a multiple screen conference, the video and audio streams sent from = remote participants must be understood by receivers so that they can be = presented in a coherent and life-like manner. This includes the ability to present the = remote participants at their true size for their apparent distance, while = maintaining correct eye contact, gesticular cues, and simultaneously providing a = spatial audio sound stage consistent with the video presentation.=A0 The = receiving device that decides how to display the incoming information needs to understand = a number of variables such as the spatial position of the speaker, the = field of view of the cameras, the camera zoom, which media stream is related to = each of the displays, etc.

 

Charter<= /p>

The Telepresence Multi-Streams work item in DISPATCH is chartered to define = and specify for SIP-based systems the content of media multi-stream messages = and the way these will be transported.

 

This work will provide a standard for the exchange of media semantic = information that will foster interoperable end stations and conference bridges. = It will specify=A0 variables = that describe the semantics of the media streams and the recommended behavior = to achieve interoperability.=A0

 

 

This requires considering current widely deployed use cases, as well as cases = that are expected to be implemented using the protocol framework produced by = this work item.=A0 The methodology for describing the variables must allow extensibility of the variables, since telepresence is still a young = technology and may have use cases that are not currently = considered."

 

 

The work item will identify use cases, define requirements, and define a = method for describing and transporting information about multiple media streams, = including a specification of variables required to support the use cases. This = work item will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols = required to be implemented to support this functionality.=A0 The document will = identify any enhancements required to existing protocols as well as describing new = protocol(s) for interoperable multi-streams negotiation that may be = required.

 

Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and = FECframe.

 

 

Scope

The scope includes both systems that provide a fully immersive experience, and = systems that interwork with them and therefore need to understand the same = multiple stream semantics.

 

 

The focus of this work is on audio and video multiple streams.=A0 Other = media types may be considered, however development of methodologies for them is not = within the scope of this work.

 

Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems.=A0 However, backwards compatibility with existing non-standards compliant telepresence systems is not = required.

 

 

 

The group will produce

- Requirements and use cases

 

- Architectural Framework describing the protocols required to be = implemented to support this functionality and identifying existing protocol = enhancements and new protocol functionality required

 

- Specification of a new protocol to support telepresence multi-streams = [if required]

 

Goals and Milestones

Nov 2010 =

 

Use Cases and Requirements to IESG as Informational RFC

Nov = 2010

March 2011 =

Problem Statement to IESG as Informational RFC

Architecture to IESG as Informational RFC

March = 2011

Revise Charter [IF new protocol is not required]

Nov 2011 =

Submit protocol draft to IESG as Proposed Standard RFC

 

------_=_NextPart_001_01CB1BF8.9FDCFE6F-- From laura.liess.dt@googlemail.com Mon Jul 5 03:23:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C09223A6844 for ; Mon, 5 Jul 2010 03:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.623 X-Spam-Level: X-Spam-Status: No, score=0.623 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhZnuqoukPrv for ; Mon, 5 Jul 2010 03:23:22 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 3660A3A63EC for ; Mon, 5 Jul 2010 03:23:22 -0700 (PDT) Received: by wyg36 with SMTP id 36so1726522wyg.31 for ; Mon, 05 Jul 2010 03:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2EYGvMviUqqYMoesEiJKyjsJvhJBrYAofcyGPRHspH8=; b=WkQ1PffiY+ZGW0eX7fepKiMKbZv7IFZCHO0qSCeuRs9lYATrzQ9AVU+nmHYkVng0+J aADNG3M43Ar2Y4t5B9SKmy5lr/LvnMfWAZU8G/NEomQcGphwxviFHd+5XBSGt2XiLHss F8TjhRL5Jvw/DOmf3pIWQi/Y16C9imuZLNJgE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NwIZ5oKc8hjK5VnTYbQNBw2F7qwOuA2dmsSl/KxVdAMTqKOrb1dz+uy88FdgFXKdQd Fhd76JHHh1fwppqYwVstlYc223qiMW0AWNfuAe4Z2Grlz0txSzhWnqL/8BICOAUW5d5n 9XTe8Ey9/L9ClaiuW2dz9csL0SOazoysoto3g= MIME-Version: 1.0 Received: by 10.227.138.5 with SMTP id y5mr3174782wbt.137.1278325396495; Mon, 05 Jul 2010 03:23:16 -0700 (PDT) Received: by 10.216.181.6 with HTTP; Mon, 5 Jul 2010 03:23:14 -0700 (PDT) In-Reply-To: <4C2CC6D8.9030002@cisco.com> References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> <4C2A2C19.1030906@cisco.com> <4C2AE94C.4020707@ericsson.com> <617DF0128820F9458AC39149A627EE6C01A66BC2A7@MBX.dialogic.com> <4C2B8ACE.3050301@cisco.com> <4C2CC6D8.9030002@cisco.com> Date: Mon, 5 Jul 2010 12:23:14 +0200 Message-ID: From: Laura Liess To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , James Rafferty , Roland Jesske Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 10:23:24 -0000 Paul, I did a little more "digging" within DT about how UUI is used today. There is not only the application I described before. The field is used also for Centrex-like services and also customers can buy it and use it end2end. Different values are used for the protocol discriminator, not only 08. Thanks a lot Laura 2010/7/1 Paul Kyzivat : > [removing ietf@ietf.org to avoid inflicting pain on such a broad audience= ] > > Laura, > > So this use is by prior arrangement between the UAC and UAS in a case whe= re > the UAC is in a position to know for certain the capabilities of the UAS. > > Is the usage "standard" to the extent that Q.931 defines a standard for > this? What protocol discriminator is used? Is it 0 (user specified - > effectively unrestricted use AFAICT), or in the 0x40-0x4F range reserved = for > "national" use? > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > > Laura Liess wrote: >> >> In the PSTN, =A0we use the UUI field to transmit information between the >> Intelligent Network (IN) system and call center agents for the >> directory enquires service. Everybody in Germany who wants to ask for >> the phone number of another person dials DT's directory enquires >> service and is connected to a call center agent who tells him the >> number he wants to know. Additionaly, only if the caller is a DT >> customer, the call center agent offers to connect him to this number, >> so the caller does not need to dial. For everybode else, he does not. >> So the call center agent needs to get the information whether or not >> the caller is a DT customer. This is done by routing every directory >> enquires call to the IN system first. The IN system checks the caller >> number and inserts the information about whether or not the caller is >> a DT-customer in the UUI field which is transmited via INAP, ISUP and >> DSS1 to the call center agent's end device.The call center agent gets >> a display about this. During the PSTN-migration to SIP, we will have >> cases where the call center and the IN system are connected to >> different networks, one to PSTN and the other to SIP. =A0Also, we may >> have applications as above on pure SIP application servers. >> >>> Can you shed some light on *how* this is used, given the lack of any >>> standards on the content/formatting of this information? >> >> The application is DT-specific and needs a DT specification to be >> supported by the IN system and the call center, but the container to >> transport the information must be supported by both ends and by the >> network nodes. >> >>> Or is this only used between a caller and a callee that have somehow >>> obtained contextual information that they both support this feature *an= d* >>> a >>> particular encoding? >> >> At least within the DT network, UUI is used between application >> servers or application servers and "special" end devices as call >> centers. As far as I know, UUI is currently not part of the DT normal >> telephony package. Many years ago, it was, but people misused it. >> >> We plan to use the "Johnston uui draft" for the scenario described >> above and we see the need for the proposed WG. >> >> Thanks a lot >> Laura >> >> >> Laura >> >> >> >> >> >> >> >> >> 2010/6/30 Paul Kyzivat : >>> >>> James, >>> >>> Can you shed some light on *how* this is used, given the lack of any >>> standards on the content/formatting of this information? >>> >>> Do you use content=3Disdn-uui and some particular Q.931 protocol >>> discriminator >>> for which there are formatting standards? >>> >>> Or is this only used between a caller and a callee that have somehow >>> obtained contextual information that they both support this feature *an= d* >>> a >>> particular encoding? >>> >>> =A0 =A0 =A0 Thanks, >>> =A0 =A0 =A0 Paul >>> >>> James Rafferty wrote: >>>> >>>> Hi, >>>> My company has had the experience of deploying the pre-standard versio= n >>>> of >>>> this PSTN to SIP UUI mechanism during the past 2 years. >>>> As noted in the draft charter, UUI information is widely used on the >>>> PSTN >>>> for applications such as offering input data into call centers and the= n >>>> preserving that data as calls get transferred. >>>> Since many contact centers are now built using SIP, but still have PST= N >>>> subscribers (via SS7 ISUP or ISDN PRI), there is a need to be able to >>>> interwork the user to user information from the PSTN side into SIP. = =A0In >>>> our >>>> experience, the "Johnston uui draft" has accomplished this and we have >>>> several customers that find this interworking to be valuable. =A0We al= so >>>> noted >>>> improvements from early drafts into the later ones in areas such as >>>> making >>>> better use of the ITU-T protocol discriminator, thus enabling better >>>> interoperability from the PSTN side into SIP. >>>> The major deficiency of the current draft is its non-standard status. >>>> Functionally, we and our customers find this mechanism to be very usef= ul >>>> and >>>> I'd very much like the IETF to charter the a UUI work group to >>>> standardize >>>> such a mechanism. >>>> James =A0-----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>>> Behalf Of Gonzalo Camarillo >>>> Sent: Wednesday, June 30, 2010 2:51 AM >>>> To: Paul Kyzivat >>>> Cc: dispatch@ietf.org; DRAGE, Keith (Keith); ietf@ietf.org >>>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP >>>> (cuss) >>>> >>>> Hi, >>>> >>>> please keep both the IETF and the DISPATCH mailing lists in the >>>> recipients list in this discussion. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> >>>> On 29/06/2010 8:23 PM, Paul Kyzivat wrote: >>>>> >>>>> DRAGE, Keith (Keith) wrote: >>>>>> >>>>>> The UUI information is NOT ISUP. It is a transparent envelope to the >>>>>> entire ISDN, so it is not part of an ISDN protocol and therefore not >>>>>> part of >>>>>> an ISUP protocol. When carried by ISUP the envelope is bundled up in >>>>>> another >>>>>> envelope with other information that ISUP carries transparently. >>>>>> >>>>>> So I believe, and have said repeatedly in the past, that references = to >>>>>> SIP-T are irrelevant in this case. >>>>>> >>>>>> The problem we do have though is that are legacy usages of this >>>>>> information. In particular applications in PBXs carry it between >>>>>> themselves >>>>>> in ISDN call establishment. The information itself is not >>>>>> standardised. If >>>>>> you want to migrate a PBX from DSS1 to SIP, then you have to take th= is >>>>>> information into account. The desire is not for a WG group to >>>>>> standardise >>>>>> this existing usage (which in my view would be a complete >>>>>> non-starter), but >>>>>> to allow the transfer of the existing information when migrated to a >>>>>> SIP >>>>>> environment. The information transferred does not form part of SIP, >>>>>> and >>>>>> should not be standardised as part of SIP. >>>>> >>>>> How many different mechanisms do we have to construct for the purpose >>>>> of >>>>> tunneling stuff over SIP? >>>>> >>>>> Its especially bad if the stuff is neither standardized nor negotiate= d. >>>>> It then just provides more opportunity for non-interoperability. >>>>> >>>>> It had been my impression that this content was standardized by ITU. >>>>> If nobody can bother to standardize it, then it hardly seems worth >>>>> working on. >>>>> >>>>> =A0 =A0 =A0 Thanks, >>>>> =A0 =A0 =A0 Paul >>>>> >>>>>> regards >>>>>> >>>>>> Keith >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: dispatch-bounces@ietf.org >>>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of >>>>>>> bruno.chatras@orange-ftgroup.com >>>>>>> Sent: Tuesday, June 29, 2010 1:00 PM >>>>>>> To: Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org >>>>>>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI >>>>>>> for SIP (cuss) >>>>>>> >>>>>>> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 >>>>>>> does state that SIP-T does not come into play when there is >>>>>>> no PSTN involved. >>>>>>> >>>>>>> At the end of clause 2 we can read the following: "4. =A0IP >>>>>>> origination - IP termination: This is a case for pure SIP. >>>>>>> SIP-T (either encapsulation or translation of ISUP) does not >>>>>>> come into play as there is no PSTN interworking." >>>>>>> >>>>>>> Besides, SIP-T would require encapsulating a full ISUP >>>>>>> message (e.g. IAM) while we are interested in just one >>>>>>> parameter of the message in the context of CUSS. This would I >>>>>>> believe be a more severe drawback if SIP-T were used for this >>>>>>> purpose. >>>>>>> >>>>>>> Bruno >>>>>>> >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : dispatch-bounces@ietf.org >>>>>>>> [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo Camarillo >>>>>>>> Envoy=E9 : mardi 29 juin 2010 13:03 =C0 : DISPATCH Objet : >>>>>>> >>>>>>> [dispatch] Fwd: >>>>>>>> >>>>>>>> Re: WG Review: Call Control UUI for SIP (cuss) >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> FYI: note the discussion below on the IETF general list. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Gonzalo >>>>>>>> >>>>>>>> -------- Original Message -------- >>>>>>>> Subject: Re: WG Review: Call Control UUI for SIP (cuss) >>>>>>>> Date: Mon, 28 Jun 2010 20:24:23 +0200 >>>>>>>> From: Cullen Jennings >>>>>>>> To: iesg@ietf.org >>>>>>>> CC: IETF Discussion Mailing List >>>>>>>> >>>>>>>> >>>>>>>> As far as I can tell, the WG says they wants to transfer some >>>>>>>> information to achieve cross vendor interoperability. >>>>>>>> However, what I believe the charter is actually going to do >>>>>>> >>>>>>> is exactly >>>>>>>> >>>>>>>> the opposite of that. When you get your head around what >>>>>>> >>>>>>> this charter >>>>>>>> >>>>>>>> is proposing, it is going to form a more or less opaque >>>>>>> >>>>>>> container for >>>>>>>> >>>>>>>> transporting proprietary information in a SIP header. It's hard to >>>>>>>> imagine how this will help interoperability. >>>>>>>> >>>>>>>> If we wanted to have interoperability, the charter would say what >>>>>>>> information needs to be transferred and have the WG define a way t= o >>>>>>>> get it between systems in an operable way. >>>>>>>> What the charter for this WG actually says they are going to do is >>>>>>>> make a special container for transfer proprietary information. >>>>>>>> There's not even willing to say what that proprietary >>>>>>> >>>>>>> information is >>>>>>>> >>>>>>>> used for other than things ISDN UUI which is a =A0non >>>>>>> >>>>>>> interoperable and >>>>>>>> >>>>>>>> fairly proprietary field in ISDN. >>>>>>>> Furthermore they have asserted that =A0existing containers >>>>>>> >>>>>>> such as SIP-T >>>>>>>> >>>>>>>> or SIP bodies can't be used for reasons that are hard to >>>>>>> >>>>>>> describe. (I >>>>>>>> >>>>>>>> reject the idea that because the call might not involved >>>>>>> >>>>>>> the PSTN, it >>>>>>>> >>>>>>>> can't use SIP-T). >>>>>>>> >>>>>>>> I think the folks that want to do this should get a much clear >>>>>>>> explanation of how this results in interoperability and why exist >>>>>>>> approach such as SIP-T will not work before this is chartered. >>>>>>>> >>>>>>>> I do think there is a need to standardize some important >>>>>>> >>>>>>> call control >>>>>>>> >>>>>>>> information used in call centers and related places. >>>>>>>> However, the "we need a standard container to exchange secret >>>>>>>> information WG" is a bad idea and violates the sprit of the >>>>>>> >>>>>>> SIP change >>>>>>>> >>>>>>>> process not to mention the mission of the IETF. >>>>>>>> >>>>>>>> In summary, I'm in favor of figuring out what the problems >>>>>>> >>>>>>> are people >>>>>>>> >>>>>>>> hope to solve with this WG and figuring out a way to write >>>>>>>> interoperable standards to achieve that. However, I think >>>>>>> >>>>>>> this charter >>>>>>>> >>>>>>>> should be rejected by the IESG and sent back to the drawing >>>>>>> >>>>>>> board. The >>>>>>>> >>>>>>>> RAI area has things of higher priority items to work on than a SIP >>>>>>>> header for transfer proprietary data. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote: >>>>>>>> >>>>>>>>> A new IETF working group has been proposed in the Real-time >>>>>>>>> Applications and Infrastructure Area. =A0The IESG has not >>>>>>>> >>>>>>>> made any determination as yet. >>>>>>>>> >>>>>>>>> The following draft charter was submitted, and is provided for >>>>>>>>> informational purposes only. Please send your comments to >>>>>>> >>>>>>> the IESG >>>>>>>>> >>>>>>>>> mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. >>>>>>>>> >>>>>>>>> Call Control UUI for SIP =A0(cuss) >>>>>>>>> -------------------------------------------------- >>>>>>>>> Current Status: Proposed Working Group >>>>>>>>> >>>>>>>>> Last modified: 2010-06-21 >>>>>>>>> >>>>>>>>> Chair(s): >>>>>>>>> =A0TBD >>>>>>>>> >>>>>>>>> Real-time Applications and Infrastructure Area Director(s): >>>>>>>>> =A0Gonzalo Camarillo >>>>>>> >>>>>>> Robert Sparks >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Real-time Applications and Infrastructure Area Advisor: >>>>>>>>> =A0Gonzalo Camarillo >>>>>>>>> >>>>>>>>> Mailing Lists: TBD >>>>>>>>> >>>>>>>>> Description of Working Group: >>>>>>>>> >>>>>>>>> The Call Control UUI for SIP (CUSS) working group is chartered to >>>>>>>>> define a Session Initiation Protocol (SIP) mechanism for >>>>>>>> >>>>>>>> transporting >>>>>>>>> >>>>>>>>> call-control related user-to-user information (UUI) between User >>>>>>>>> Agents. >>>>>>>>> >>>>>>>>> The mechanism developed in this working group is >>>>>>> >>>>>>> applicable in the >>>>>>>>> >>>>>>>>> following situations: >>>>>>>>> >>>>>>>>> 1. The information is generated and consumed by an >>>>>>> >>>>>>> application using >>>>>>>>> >>>>>>>>> =A0SIP during session setup but the application is not necessaril= y >>>>>>>>> =A0even SIP aware. >>>>>>>>> 2. The behavior of SIP entities that support it is not >>>>>>> >>>>>>> significantly >>>>>>>>> >>>>>>>>> =A0changed (as discussed in Section 4 of RFC 5727). >>>>>>>>> 3. Generally only the User Agent Client (UAC) and User >>>>>>> >>>>>>> Agent Server >>>>>>>>> >>>>>>>>> =A0(UAS) are interested in the information. >>>>>>>>> 4. The information is expected to survive retargeting, >>>>>>> >>>>>>> redirection, >>>>>>>>> >>>>>>>>> =A0and transfers. >>>>>>>>> 5. SIP elements may need to apply policy about passing >>>>>>> >>>>>>> and screening >>>>>>>>> >>>>>>>>> =A0the information. >>>>>>>>> 6. Multi-vendor interoperability is important. >>>>>>>>> >>>>>>>>> This mechanism is not applicable in the following situations: >>>>>>>>> >>>>>>>>> 1. The behavior of SIP entities that support it is significantly >>>>>>>>> =A0changed (as discussed in Section 4 of RFC 5727). >>>>>>>>> 2. The information is generated and consumed at the SIP >>>>>>> >>>>>>> layer by SIP >>>>>>>>> >>>>>>>>> =A0elements. >>>>>>>>> 3. SIP elements besides the UAC and UAS might be interested in >>>>>>>>> =A0consuming (beyond applying policy) the information. >>>>>>>>> 4. There are specific privacy issues involved with the informatio= n >>>>>>>>> =A0being transported (e.g., geolocation or emergency-related >>>>>>>>> =A0information). >>>>>>>>> >>>>>>>>> User data of the mechanism will be clearly marked with the >>>>>>>>> application, encoding, semantics, and content type, >>>>>>>> >>>>>>>> allowing policy to >>>>>>>>> >>>>>>>>> be applied by UAs. =A0The working group will define the >>>>>>>> >>>>>>>> information that >>>>>>>>> >>>>>>>>> each application must specify to utilize the mechanism. >>>>>>>> >>>>>>>> This type of >>>>>>>>> >>>>>>>>> application-specific information will be specified in >>>>>>>> >>>>>>>> standards-track >>>>>>>>> >>>>>>>>> documents. >>>>>>>>> >>>>>>>>> One important application of this mechanism is interworking >>>>>>>> >>>>>>>> with the >>>>>>>>> >>>>>>>>> ISDN User to User Information Service. =A0This application >>>>>>> >>>>>>> defined by >>>>>>>>> >>>>>>>>> ITU-T Q.931 is extensively deployed in the PSTN today >>>>>>>> >>>>>>>> supporting such >>>>>>>>> >>>>>>>>> applications as contact centers, call centers, and automatic call >>>>>>>>> distributors (ACDs). =A0A major barrier to the movement of these >>>>>>>>> applications to SIP is the lack of a standard mechanism to >>>>>>>> >>>>>>>> transport >>>>>>>>> >>>>>>>>> this information in SIP. =A0For interworking with ISDN, minimal >>>>>>>>> information about the content of the UUI is available to >>>>>>>> >>>>>>>> the PSTN-SIP >>>>>>>>> >>>>>>>>> gateways. =A0In this case only, the content will just >>>>>>>> >>>>>>>> indicate ISDN UUI >>>>>>>>> >>>>>>>>> Service 1 interworking rather than the actual content. >>>>>>>>> >>>>>>>>> Call control UUI is user information conveyed between user agents >>>>>>>>> during call control operations. =A0As a result, the >>>>>>>> >>>>>>>> information must be >>>>>>>>> >>>>>>>>> conveyed with the INVITE transaction, and must survive proxy >>>>>>>>> retargeting, redirection, and transfers. =A0The mechanism >>>>>>>> >>>>>>>> must utilize a >>>>>>>>> >>>>>>>>> minimum of SIP extensions since it will need to be >>>>>>>> >>>>>>>> supported by many >>>>>>>>> >>>>>>>>> simple SIP user agents such as PSTN gateways. =A0The mechanism mu= st >>>>>>>>> interwork with the existing ISDN service but should also be >>>>>>>> >>>>>>>> extensible >>>>>>>>> >>>>>>>>> for use by other applications and non-ISDN protocols. >>>>>>>>> >>>>>>>>> Even though interworking with the PSTN is an important >>>>>>> >>>>>>> requirement, >>>>>>>>> >>>>>>>>> call control UUI can be exchanged between native SIP >>>>>>>> >>>>>>>> clients that do >>>>>>>>> >>>>>>>>> not have any ISUP support. Therefore, existing SIP-T >>>>>>>>> encapsulation-based approaches defined in RFC3372 do not meet the >>>>>>>>> requirements to transport this type of information. >>>>>>>>> >>>>>>>>> Mechanisms based on the SIP INFO method, RFC2976, will not be >>>>>>>>> considered by the working group since the UUI contents carry >>>>>>>>> information that must be conveyed during session setup at >>>>>>> >>>>>>> the user >>>>>>>>> >>>>>>>>> agent - the information must be conveyed with the INVITE >>>>>>>> >>>>>>>> transaction. >>>>>>>>> >>>>>>>>> The information must be passed with the session setup request >>>>>>>>> (INVITE), responses to that INVITE, or session >>>>>>> >>>>>>> termination requests. >>>>>>>>> >>>>>>>>> As a result, it is not possible to use INFO in these cases. >>>>>>>>> >>>>>>>>> The group will produce: >>>>>>>>> >>>>>>>>> - A problem statement and requirements document for >>>>>>>> >>>>>>>> implementing a SIP >>>>>>>>> >>>>>>>>> call control UUI mechanism >>>>>>>>> >>>>>>>>> - A specification of the SIP extension to best meet those >>>>>>>> >>>>>>>> requirements. >>>>>>>>> >>>>>>>>> Goals and Milestones >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>>> >>>>>>>>> Sep 10 - Problem statement and requirements document to IESG >>>>>>>>> (Informational) >>>>>>>>> Mar 11 - SIP call control UUI specification to IESG (PS) >>>>>>>>> _______________________________________________ >>>>>>>>> IETF-Announce mailing list >>>>>>>>> IETF-Announce@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>>>> >>>>>>>> Cullen Jennings >>>>>>>> For corporate legal information go to: >>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> > From laura.liess.dt@googlemail.com Mon Jul 5 06:10:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFB1A3A687D; Mon, 5 Jul 2010 06:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.253 X-Spam-Level: X-Spam-Status: No, score=0.253 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqdGDVZ7tPrg; Mon, 5 Jul 2010 06:10:46 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id B5AE33A67F9; Mon, 5 Jul 2010 06:10:45 -0700 (PDT) Received: by wwb13 with SMTP id 13so461558wwb.1 for ; Mon, 05 Jul 2010 06:10:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MhF5M3aNzr0hS6hiyOSLobHhMLeOVcP/3HMZGnHIpco=; b=JI8Av8QlVwe9zLRnGDQsebd+NED3o7fv/GXQ+1vVwkpCSTWNyFwNrDN6Jr5dScYlX0 AVJQrG7D7MlegKc0oLf7kEGF42BaX1NpeEYlRTZ//vSLiECm7mlSxJnlG7miWoc3WcKa 86sA2TFtUqN/cN9WZXJ7GOVQ2mhktMa7g0hls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=G5qF+UT9DbG8Y37UDHosU+NYQ3/J+H79odZY3MJq1KhpZdGZJCnvoWrZanbQY0iYU7 BsqNGu9vyjxBYWQXChfZNB0lyduhVHzQC22vw6GBPOCPfv+umGi7O0wslusWhKVlkkVm 6rkRPWJV0y6vLhP6qCNNRWoIHHZFjr3aGUlyM= MIME-Version: 1.0 Received: by 10.227.145.1 with SMTP id b1mr3419998wbv.132.1278335438223; Mon, 05 Jul 2010 06:10:38 -0700 (PDT) Received: by 10.216.181.6 with HTTP; Mon, 5 Jul 2010 06:10:38 -0700 (PDT) In-Reply-To: <4C2C5AB4.5020705@ericsson.com> References: <20100622170002.02B053A683E@core3.amsl.com> <74B1068E-86C0-426E-8E9B-841C23EE9965@cisco.com> <4C2C5AB4.5020705@ericsson.com> Date: Mon, 5 Jul 2010 15:10:38 +0200 Message-ID: From: Laura Liess To: Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: DISPATCH , IETF Discussion Mailing List , Roland Jesske Subject: Re: [dispatch] WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 13:10:48 -0000 Gonzalo, > Would a proxy reject a whole request because it carries some type of > information (without the proxy knowing the exact contents of the > information)?... or would the proxy remove the information and proxy the > remainder of the request?. Today, in the PSTN, DT uses both methods, and needs this also for SIP. The decision depends on different criteria, e.g. the message source (different policies for different customers or different application servers). >.. or would the proxy need access to the > contents of the information in order to decide what to do? There is no need for the proxy to access the content of the information and it does not understand it. >Also, will > intermediaries applying policies be proxies or some type of a B2BUA? The decision is taken by the S-CSCF which is a proxy. This is the DT point of view. Maybe other service providers or PBX-systems have different scenarios. Thanks a lot, Laura 2010/7/1 Gonzalo Camarillo : > Hi, > > let's not start discussing (again) whether this information in carried > in a header field or in a body part. Let's discuss the requirement below > instead, which seems to be what needs to be clarified in the charter > (the details on how to encode this will be largely determined by the > requirements the solution should meet). > >> =A05. SIP elements may need to apply policy about passing and screening >> =A0 the information. > > I agree the charter needs to be clearer on what types of policies are > expected and what is needed to apply them. Discussing about the > granularity of those policies would be useful as well. The charter > should clarify the questions below: > > Would a proxy reject a whole request because it carries some type of > information (without the proxy knowing the exact contents of the > information)?... or would the proxy remove the information and proxy the > remainder of the request?... or would the proxy need access to the > contents of the information in order to decide what to do? Also, will > intermediaries applying policies be proxies or some type of a B2BUA? > > Thanks, > > Gonzalo > > > > On 01/07/2010 5:31 AM, Cullen Jennings wrote: >> >> On Jun 29, 2010, at 3:25 AM, Elwell, John wrote: >> >>> Cullen, >>> >>> Whilst neither agreeing nor disagreeing with the charter, I did not fin= d anything in the charter that said the information had to be in the SIP he= ader rather than in the body. On what basis do you make that deduction? >>> >>> John >> >> When I read >> =A05. SIP elements may need to apply policy about passing and screening >> =A0 the information. >> >> And the discussion about it's not just UA. I reached that perhaps flawed= conclusion that proxies needed to be able to change the information when "= screening" and thus it needed to be in a header. Note I would have far less= of an issue with an opaque container for proprietary information if it was= in a body instead of a header and had the types of constraints that SIP-T = has. >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >> > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > From peter.musgrave@magorcorp.com Mon Jul 5 06:15:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9BE13A698F; Mon, 5 Jul 2010 06:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dml4JNv-zEWP; Mon, 5 Jul 2010 06:14:59 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 0866D3A6985; Mon, 5 Jul 2010 06:14:58 -0700 (PDT) Received: by gwb10 with SMTP id 10so2736047gwb.31 for ; Mon, 05 Jul 2010 06:14:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.233.205 with SMTP id jz13mr1530935qcb.171.1278335696998; Mon, 05 Jul 2010 06:14:56 -0700 (PDT) Received: by 10.229.220.10 with HTTP; Mon, 5 Jul 2010 06:14:56 -0700 (PDT) In-Reply-To: <009f01cb1bba$4c7bcd40$e57367c0$@us> References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> Date: Mon, 5 Jul 2010 09:14:56 -0400 Message-ID: From: Peter Musgrave To: Richard Shockey Content-Type: multipart/alternative; boundary=0016363b8f981f959e048aa3b974 Cc: DISPATCH , IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 13:15:01 -0000 --0016363b8f981f959e048aa3b974 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, I think the charter issue here is an assumption that number ownership is established using ENUM. I agree with you comments about chains of trust, certs etc. and that this is likely impossible but they are not the mechanis= m being proposed in the charter. It states: "Some validation protocols may be based on knowledge gathered around a PSTN call; for example, the ability to prove a call was received over the PSTN based on start and stop times. Other validation schemes, such as examining fingerprints or watermarking of PSTN media to show that a domain received a particular PSTN phone call, may also be considered by the working group. This validation will be accomplished using publicly available open interfaces to the PSTN, so the validation can be performed by any domain wishing to participate. The WG will select and standardize at least one validation scheme." An approach which is given as a sample solution is in the vipr-overview doc= . The fact that there is running code shows the solution has some merit. Can you please clarify what part of this approach you view as impossible? Thanks, Peter Musgrave On Sun, Jul 4, 2010 at 4:48 PM, Richard Shockey wrote: > Well folks can certainly do what they want to do. And the IETF has a > lamentable record of some protocols that don=92t accomplish much. But the= core > of this proposed WG is based on a fallacy. ViPR cannot verify or > authenticate the responsible party for a E.164 number. It is incapable of > doing so since there is no possible administrative chain of trust other t= han > self assertion . Hence the possibility of identity or number/session > hijacking is very large. You have to have the cooperation of the national > numbering authorities or the issuer of the phone number to authenticate w= ho > is the responsible party . ViPR doesn=92t change that problem either. > > > > This has been a well known problem in SIP for some time and that was part > of the difficulties that public ENUM had in e164.arpa. ENUM is doing very > well BTW as a SS7/TCAP replacement however in private trees BTW. > > > > Consequently I think this issue has to be fully defined in the charter an= d > I will gleefully anticipate what the security considerations text will lo= ok > like. > > > > The fact that there is CISCO running code is utterly irrelevant. There is > lots of bad code out there. I understand the problem of how do you creat= e > SIP federations across domains outside the scope of service providers, bu= t > without a comprehensive trust model this is going to fail. I do understa= nd > that many folks don=92t like their voice service providers or PSTN that > perpetuates the use of E.164 numbers but this proposal is not going to so= lve > that. > > > > IMHO in the absence of any rational trust or security model you can > certainly publish something as Informational but getting something past t= he > IESG is another thing entirely. > > > > *From:* Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > *Sent:* Saturday, July 03, 2010 5:49 PM > *To:* Richard Shockey > *Cc:* Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion list > > *Subject:* Re: [dispatch] VIPR - proposed charter version 3 > > > > Hi Richard, > > > > Clearly we don't want to be trying to solve the impossible - that could > take a really long time. > > > > The mechanism in the ViPR drafts seemed to be able to accomplish the > "finding the party responsible for a number" - and IIRC this is based on > *running code* in the Cisco IME. > > > > ViPR is frankly not beautiful (in the way ICE is not beautiful) but I do > think it can solve a problem which needs to be solved. Hence I support it= . > > > > Peter Musgrave > > On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey > wrote: > > A we already have centralized solutions for interdomain routing based on > E.164. its called ENUM in both its private and public instantiations. It > works pretty well BTW and globally deployed. > > IMHO this charter is a non starter and should not be approved on the basi= s > of this statement alone. > > "finding domains that claim to be responsible for a given phone number" > > This IMHO is flat out impossible. Validating or authenticating an entity > that is "responsible for a phone number" is as bad as " who is the carri= er > of record" , is a massive rathole. Cullen and Johathan should know better= . > Certs? LNP ? > > We have this problem of E.164 validation all the time in SIP and its not > going to be solved in the IETF. > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf > Of Romascanu, Dan (Dan) > Sent: Wednesday, June 30, 2010 11:33 AM > To: Mary Barnes > Cc: DISPATCH; IETF-Discussion list > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > It looks to me that one can imagine 'centralized' solutions which are > also based on reusing SIP related functionality developed in RAI. I > would rather not close such an option and allow the WG a window of > opportunity in which alternate solutions that could meet the same goals > can be presented. > > Dan > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > Sent: Wednesday, June 30, 2010 6:24 PM > > To: Romascanu, Dan (Dan) > > Cc: DISPATCH; IETF-Discussion list > > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > > > Hi Dan, > > > > The term peer to peer is intended to exclude mechanisms that > > would use a central repository for the information: This was > > discussed in an earlier thread: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html > > > > In one sense it is a solution, however, in another sense it > > is reusing SIP related functionality defined in RAI and thus > > is in a similar vein as specifying the use of SIP in a charter. > > > > Thanks, > > Mary. > > > > On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) > > wrote: > > >> The VIPR WG will address this problem by developing a peer to peer > > >> based approach to finding domains that claim to be > > responsible for a > > >> given phone number and validation protocols to ensure a reasonable > > >> likelihood that a given domain actually is responsible for > > the phone > > >> number. > > > > > > Hi, > > > > > > Clarification question. What exactly means 'peer to peer > > based approach' > > > and what kind of approaches are excluded by having this in > > the charter. > > > Does 'approach' mean solution? If so why does a specific type of > > > solution need to be agreed in the charter, while all we > > have at hand > > > at this point are individual contribution I-Ds that describe the > > > 'problem statement and some possible starting points for solutions'? > > > > > > Thanks and Regards, > > > > > > Dan > > > > > > > > >> -----Original Message----- > > >> From: dispatch-bounces@ietf.org > > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > > >> Sent: Monday, June 28, 2010 8:38 PM > > >> To: DISPATCH > > >> Subject: [dispatch] VIPR - proposed charter version 3 > > >> > > > > > > _______________________________________________ > 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 > > > --0016363b8f981f959e048aa3b974 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,=A0

I think the charter issue here is an assumption t= hat number ownership is established using ENUM. I agree with you comments a= bout chains of trust, certs etc. and that this is likely impossible but the= y are not the mechanism being proposed in the charter. It states:

"Some validation protocols may be based= on knowledge gathered around a
PSTN call; for example, the ability to p= rove a call was received over
the PSTN based on start and stop times. Other validation schemes, such
a= s examining fingerprints or watermarking of PSTN media to show that a
do= main received a particular PSTN phone call, may also be considered by
the working group. This validation will be accomplished using publicly
a= vailable open interfaces to the PSTN, so the validation can be
performed= by any domain wishing to participate. =A0The WG will select and
standar= dize at least one validation scheme."

An approach which is given as a sample solu= tion is in the vipr-overview doc. The fact that there is running code shows= the solution has some merit.=A0

Can you please clarify what part of this ap= proach you view as impossible?

Thanks,=A0

Peter Musgrave

On Sun, Jul 4, 2010 at 4:48 PM= , Richard Shockey <richard@shockey.us> wrote:

Well = folks can certainly do what they want to do. And the IETF has a lamentable record of some protocols that don=92t accomplish much. But the core of this proposed WG is based on a fallacy. ViPR cannot verify or authenticate the responsible party for a E.164 number. It is incapable of d= oing so since there is no possible administrative chain of trust other than self assertion .=A0 Hence the possibility of identity or number/session hijackin= g is very large. You have to have the cooperation of the national numbering authorities or the issuer of the phone number to authenticate who is the responsible party . ViPR doesn=92t change that problem either.

=A0

This = has been a well known problem in SIP for some time and that was part of the difficulties that public ENUM had in e164.arpa. ENUM is doi= ng very well BTW as a SS7/TCAP replacement however in private trees BTW.

=A0

Conse= quently I think this issue has to be fully defined in the charter and I will gleefully anticipate what the security considerations te= xt will look like.

=A0

The f= act that there is CISCO running code is utterly irrelevant. There is lots of bad code out there. =A0I understand the problem of how do you create SIP federations across domains outside the scope of service providers, but without a comprehensive trust model this is going to fail. = =A0I do understand that many folks don=92t like their voice service providers or PSTN that perpetuates the use of E.164 numbers but this proposal is not goi= ng to solve that.

=A0

IMHO = in the absence of any rational trust or security model you can certainly publish something as Informational but getting something past the IESG is another thing entirely.

=A0

From:= Peter Musgrave [mailto:p= eter.musgrave@magorcorp.com]
Sent: Saturday, July 03, 2010 5:49 PM
To: Richard Shockey
Cc: Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion lis= t


Subject: Re: [dispatch] VIPR - proposed charter version 3

=A0

Hi Richard,

=A0

Clearly we don't want to be trying to solve the = impossible - that could take a really long time.=A0

=A0

The mechanism in the ViPR drafts seemed to be able t= o accomplish the "finding the party responsible for a number" - and IIRC this is based on *running code* in the Cisco IME.=A0

=A0

ViPR is frankly not beautiful (in the way ICE is not beautiful) but I do think it can solve a problem which needs to be solved. Hence I support it.=A0

=A0

Peter Musgrave

On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey <= richard@shockey.us<= /a>> wrote:

A we already have centralized solutions for interdom= ain routing based on
E.164. its called ENUM in both its private and public instantiations. It works pretty well BTW and globally deployed.

IMHO this charter is a non starter and should not be approved on the basis<= br> of this statement alone.

"finding domains that claim to be responsible for a given phone number"

This IMHO is flat out impossible. Validating or authenticating an entity that is "responsible for a phone number" is as bad as =A0" who is the carrier
of record" , is a massive rathole. Cullen and Johathan should know bet= ter.
Certs? LNP ?

We have this problem of E.164 validation all the time in SIP and its not going to be solved in the IETF.

-----Original Message-----
From: dispat= ch-bounces@ietf.org [mailto:disp= atch-bounces@ietf.org] On Behalf
Of Romascanu, Dan (Dan)
Sent: Wednesday, June 30, 2010 11:33 AM
To: Mary Barnes
Cc: DISPATCH; IETF-Discussion list
Subject: Re: [dispatch] VIPR - proposed charter version 3

It looks to me that one can imagine 'centralized' solutions which a= re
also based on reusing SIP related functionality developed in RAI. I
would rather not close such an option and allow the WG a window of
opportunity in which alternate solutions that could meet the same goals
can be presented.

Dan


> -----Original Message-----
> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> Sent: Wednesday, June 30, 2010 6:24 PM
> To: Romascanu, Dan (Dan)
> Cc: DISPATCH; IETF-Discussion list
> Subject: Re: [dispatch] VIPR - proposed charter version 3
>
> Hi Dan,
>
> The term peer to peer is intended to exclude mechanisms that
> would use a central repository for the information: =A0This was
> discussed in an earlier thread:
> http://www.ietf.org/mail-archive/web/dispatch/c= urrent/msg02027.html
>
> In one sense it is a solution, however, in another sense it
> is reusing SIP related functionality defined in RAI and thus
> is in a similar vein as specifying the use of SIP in a charter.
>
> Thanks,
> Mary.
>
> On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan)
> <dromasca@a= vaya.com> wrote:
> >> The VIPR WG will address this problem by developing a peer to peer
> >> based approach to finding domains that claim to be
> responsible for a
> >> given phone number and validation protocols to ensure a reasonable
> >> likelihood that a given domain actually is responsible for > the phone
> >> number.
> >
> > Hi,
> >
> > Clarification question. What exactly means 'peer to peer
> based approach'
> > and what kind of approaches are excluded by having this in
> the charter.
> > Does 'approach' mean solution? If so why does a specific = type of
> > solution need to be agreed in the charter, while all we
> have at hand
> > at this point are individual contribution I-Ds that describe the<= br> > > 'problem statement and some possible starting points for solu= tions'?
> >
> > Thanks and Regards,
> >
> > Dan
> >
> >
> >> -----Original Message-----
> >> From: dispatch-bounces@ietf.org
> >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes
> >> Sent: Monday, June 28, 2010 8:38 PM
> >> To: DISPATCH
> >> Subject: [dispatch] VIPR - proposed charter version 3
> >>
> >
>
_______________________________________________
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

=A0


--0016363b8f981f959e048aa3b974-- From mperumal@cisco.com Mon Jul 5 08:07:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1293E3A67E2 for ; Mon, 5 Jul 2010 08:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y151V9IvOy+w for ; Mon, 5 Jul 2010 08:07:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 99C303A679F for ; Mon, 5 Jul 2010 08:07:07 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFALeRMUxAaHte/2dsb2JhbACBQ54ycaQfmhaCXIJJBIN2hnA X-IronPort-AV: E=Sophos;i="4.53,540,1272844800"; d="scan'208,217";a="265596335" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-2.cisco.com with ESMTP; 05 Jul 2010 15:07:07 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o65F766n021023; Mon, 5 Jul 2010 15:07:06 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Jul 2010 20:37:06 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1C53.BB5A649E" x-cr-hashedpuzzle: AIAi Cw4C DQoB EbBc E/0S F36m KJSZ MQSC OPi3 Ovyx QASn QP0w QpTQ S+M2 VyIy WkCE; 2; YwBoAHIAaQBzAHQAZQByAC4AaABvAGwAbQBiAGUAcgBnAEAAZQByAGkAYwBzAHMAbwBuAC4AYwBvAG0AOwBkAGkAcwBwAGEAdABjAGgAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {7EAB3AB3-90C9-46A7-B2F4-72E775DAADA3}; bQBwAGUAcgB1AG0AYQBsAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 05 Jul 2010 15:06:59 GMT; UgBFADoAIABTAGgAbwB1AGwAZAAgAEkARQBUAEYAIABoAGEAdgBlACAAYQAgAEIARQBIAEEAVgBFACAAVwBHACAAZgBvAHIAIABTAEIAQwBzAD8A x-cr-puzzleid: {7EAB3AB3-90C9-46A7-B2F4-72E775DAADA3} Content-class: urn:content-classes:message Date: Mon, 5 Jul 2010 20:36:59 +0530 Message-ID: <1D062974A4845E4D8A343C6538049202030CA7E0@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IETF have a BEHAVE WG for SBCs? Thread-Index: AcsZQqNEprRLxVMETZSSd7Xx2jr+0wABEqZgACPhjyAAA7qi0ACZzf4Q References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <1D062974A4845E4D8A343C6538049202030CA48E@XMB-BGL-414.cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Christer Holmberg" , "DISPATCH list" X-OriginalArrivalTime: 05 Jul 2010 15:07:06.0834 (UTC) FILETIME=[BBC58B20:01CB1C53] Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 15:07:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1C53.BB5A649E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RFC-5853 already describes some of problems caused by SBCs. However, it = doesn't specify any guidelines or best current practices for addressing = those problems. One of the most common problems is that they don't pass = SIP/SDP hearers they don't understand, even if those headers have = nothing to do with the policy configured at the SBC -- just poor = implementation that breaks many end-to-end features.=20 =20 For example, the Session-ID header described in = draft-kaplan-sip-session-id is one that a good SBC implementation will = pass across to aid troubleshooting. There many other headers that need = to be carefully considered with the requirements specified RFC-5853 to = get guidelines or best practices for SBCs. =20 In essence what I am thinking is that IETF could have an umbrella = BEHAVE-like WG for SBCs that can come with guidelines, best current = practices, and new specifications (such as the notion of a SIP session = and session-ID) that can help us to achieve more predictability, = end-to-end feature interoperability and ease of troubleshooting with = SBCs. =20 Muthu =20 =20 From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Friday, July 02, 2010 6:24 PM To: Muthu ArulMozhi Perumal (mperumal); DISPATCH list Subject: RE: Should IETF have a BEHAVE WG for SBCs? =20 Hi, =20 Could you describe what you think the problems are, and why you think = they are caused by SBCs? =20 Regards, =20 Christer =20 =09 ________________________________ From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com]=20 Sent: 2. hein=E4kuuta 2010 14:32 To: Christer Holmberg; DISPATCH list Subject: RE: Should IETF have a BEHAVE WG for SBCs? Hi Christer, =20 I am not sure whether we'll be able to keep in pace in the near term, = but I think a focused WG that can come up with guideline and best = current practices for SBCs to be more predictable, pay attention to = end-to-end communication, feature interoperability and ease of = troubleshooting can have a significant influence on current and future = implementations, and lead us to a much better position in the longer = run. =20 Isn't that better than just keeping quiet and letting the problem go = out of control? =20 Muthu =20 =20 From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Friday, July 02, 2010 1:15 PM To: Muthu ArulMozhi Perumal (mperumal); DISPATCH list Subject: RE: Should IETF have a BEHAVE WG for SBCs? =20 =20 Hi, =20 If you think the reason for SBCs being deployed is the fact that "the = development of the SIP protocol hasn't been able to keep in pace", isn't = THAT the problem we should try to fix? What makes you think that this = new WG would "be able to keep in pace"? =20 It took 3,5 (!!!!) years just to produce RFC 3550... =20 Regards, =20 Christer =20 =20 =20 =09 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Muthu ArulMozhi Perumal (mperumal) Sent: 1. hein=E4kuuta 2010 20:27 To: DISPATCH list Subject: [dispatch] Should IETF have a BEHAVE WG for SBCs? In the past few years there has been a proliferation of Session Border = Controller (SBC) deployments in SIP networks mainly because the = development of SIP protocol specifications hasn't been able to keep in = pace with industry and operator requirements. The common functions they = perform and the architectural issues they introduce are described in = RFC-5853. =20 Due to lack of well defined guidelines and best current practices many = SBC implementations break end-to-end features and introduce problems = that are difficult to troubleshoot, many a times because of poor = implementations rather than to meet any specific requirements. For = example, when they do media processing they assume everything coming on = the media channel is RTP, don't do even basic RTP header validations as = recommended in RFC-3550, try to decode STUN and DTLS packets as RTP = corrupting them and making them useless. =20 I am wondering whether IETF should have a BEHAVE WG for SBCs, similar = to the one for NATs, to set guidelines and identify best current = practices to encourage better SBC implementations, interoperability and = ease of troubleshooting, rather than just keeping quiet and letting them = go out of control. =20 Comments? =20 Muthu ------_=_NextPart_001_01CB1C53.BB5A649E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

RFC-5853 already describes some of = problems caused by SBCs. However, it doesn't specify = any guidelines or best current practices for addressing those problems. One of the most = common problems is that they don't pass SIP/SDP = hearers they don't understand, even if those headers have nothing to do with the = policy configured at the SBC -- just poor implementation that breaks many = end-to-end features.

 

For = example, the Session-ID header described in draft-kaplan-sip-session-id is one that a good SBC implementation will pass across to aid = troubleshooting. There many other headers that need to be carefully considered with the = requirements specified RFC-5853 to get guidelines or best practices for SBCs.

 

In = essence what I am thinking is that IETF could have an = umbrella BEHAVE-like WG for SBCs that = can come with guidelines, best current practices, and new specifications (such as = the notion of a SIP session and session-ID) that can help us to achieve more predictability, end-to-end feature interoperability and ease of = troubleshooting with SBCs.

 

Muthu = =A0

 

From: Christer Holmberg = [mailto:christer.holmberg@ericsson.com]
Sent: Friday, July 02, 2010 6:24 PM
To: Muthu ArulMozhi Perumal (mperumal); DISPATCH list
Subject: RE: Should IETF have a BEHAVE WG for = SBCs?

 

Hi,

 

Could you describe what you think the problems are, and why = you think they are caused by SBCs?

 

Regards,

 

Christer

 

From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com]
Sent: 2. hein=E4kuuta 2010 14:32
To: Christer Holmberg; DISPATCH list
Subject: RE: Should IETF have a BEHAVE WG for SBCs?

Hi = Christer,

 

I am = not sure whether we'll be able to keep in pace in the near term, but I think a = focused WG that can come up with guideline and best current practices for SBCs = to be more predictable, pay attention to end-to-end communication, feature interoperability and ease of troubleshooting can have a significant = influence on current and future implementations, and lead us to a much better = position in the longer run.

 

Isn't = that better than just keeping quiet and letting the problem go out of = control?

 

Muthu=A0

 

From: Christer Holmberg = [mailto:christer.holmberg@ericsson.com]
Sent: Friday, July 02, 2010 1:15 PM
To: Muthu ArulMozhi Perumal (mperumal); DISPATCH list
Subject: RE: Should IETF have a BEHAVE WG for = SBCs?

 

 

Hi,

 

If you think the reason for SBCs being deployed is the = fact that "the development of the SIP protocol hasn't been able to keep = in pace", isn't THAT the problem we should try to fix? What makes you = think that this new WG would "be able to keep in pace"?

 

It took 3,5 (!!!!) years just to produce RFC = 3550...

 

Regards,

 

Christer

 

 

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Muthu ArulMozhi = Perumal (mperumal)
Sent: 1. hein=E4kuuta 2010 20:27
To: DISPATCH list
Subject: [dispatch] Should IETF have a BEHAVE WG for = SBCs?

In the = past few years there has been a proliferation of Session Border Controller = (SBC) deployments in SIP networks mainly because the development of SIP = protocol specifications hasn't been able to keep in pace with industry and = operator requirements. The common functions they perform and the architectural = issues they introduce are described in RFC-5853.

 

Due to = lack of well defined guidelines and best current practices many SBC = implementations break end-to-end features and introduce problems that are difficult to troubleshoot, many a times because of poor implementations rather than = to meet any specific requirements. For example, when they do media processing = they assume everything coming on the media channel is RTP, don't do even = basic RTP header validations as recommended in RFC-3550, try to decode STUN and = DTLS packets as RTP corrupting them and making them = useless.

 

I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to the = one for NATs, to set guidelines and identify best current practices to encourage = better SBC implementations, interoperability and ease of troubleshooting, = rather than just keeping quiet and letting them go out of = control.

 

Comments?

 

Muthu

------_=_NextPart_001_01CB1C53.BB5A649E-- From richard@shockey.us Mon Jul 5 08:15:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B1713A68ED for ; Mon, 5 Jul 2010 08:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yib6wFOfBzLu for ; Mon, 5 Jul 2010 08:15:01 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id 6E82B3A687E for ; Mon, 5 Jul 2010 08:14:57 -0700 (PDT) Received: (qmail 19484 invoked by uid 0); 5 Jul 2010 15:14:58 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 5 Jul 2010 15:14:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=fswS6B4Q/nRAMsCal5D+qs7qYEawaQjUJR4fkL4XJ1xXOmA6mDfwJLBa+USsyPk00cePwlXiIx0iRTCgQLK+YXEgLl7nDPIDrTexcLKEvJTUsl41VV//5KSTckapPfMs; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OVnNq-0004SS-4D; Mon, 05 Jul 2010 09:14:58 -0600 From: "Richard Shockey" To: "'Peter Musgrave'" References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> In-Reply-To: Date: Mon, 5 Jul 2010 11:14:56 -0400 Message-ID: <000001cb1c54$d461c940$7d255bc0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CB1C33.4D502940" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcscRBESH/9jTDGBQgmtsVQZnOoFogACz4vQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'DISPATCH' , 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 15:15:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CB1C33.4D502940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I don't make that assumption at all. ENUM cannot be used to establish any authoritative mapping of E.164 to domain. I fought that war for 10 years and lost thank you. In addition I reject the assertion in the proposed charter that private federations don't scale. In fact they do and are widely deployed among service providers who in fact self assert their authority over TN's based on their own knowledge of what TN's they are authoritative for and have access to the underlying national telephone numbering databases and signaling mechanism. The charter does not make any mention of Local Number Portability at all. This discussion of running code is irrelevant here and has zero merit in this discussion. In fact a more simplistic approach to the problem statement was developed by Asterisk years ago called DUNDI and though I haven't spoken to Mark Spencer and company in several years about this subject, I don't believe it deployed in any significant way. It's a form of DHT among trusted peers with self validation of the underlying TN's. It works. Fine. That is a private protocol deployed among private Asterisk deployments. There is a ID lying around somewhere. My assertion still holds. Without meaningful cooperation of national numbering authorities it is impossible to establish a chain of trust that can reliably determine the domain of authority for a E.164 number especially in conditions where the number is either disconnected or potentially ported. The validation scheme proposed is essentially it can successfully make a PSTN call. Wow I'm impressed! Then what? My assertion is that the charter has to reflect that there is no reliable chain of trust or validation model for E.164 numbers and consequently assertion of E.164 numbers by domains relies on self validation. The central thesis of this proposed charter is false, that you can authoratively validate a mapping between E.164 and a domain. You want to call this SELF-verification involving PSTN reachability fine. Then you would have a honest statement of what you propose to develop. This is about "truth in protocol development" tm. From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] Sent: Monday, July 05, 2010 9:15 AM To: Richard Shockey Cc: Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 Hi, I think the charter issue here is an assumption that number ownership is established using ENUM. I agree with you comments about chains of trust, certs etc. and that this is likely impossible but they are not the mechanism being proposed in the charter. It states: "Some validation protocols may be based on knowledge gathered around a PSTN call; for example, the ability to prove a call was received over the PSTN based on start and stop times. Other validation schemes, such as examining fingerprints or watermarking of PSTN media to show that a domain received a particular PSTN phone call, may also be considered by the working group. This validation will be accomplished using publicly available open interfaces to the PSTN, so the validation can be performed by any domain wishing to participate. The WG will select and standardize at least one validation scheme." An approach which is given as a sample solution is in the vipr-overview doc. The fact that there is running code shows the solution has some merit. Can you please clarify what part of this approach you view as impossible? Thanks, Peter Musgrave On Sun, Jul 4, 2010 at 4:48 PM, Richard Shockey wrote: Well folks can certainly do what they want to do. And the IETF has a lamentable record of some protocols that don't accomplish much. But the core of this proposed WG is based on a fallacy. ViPR cannot verify or authenticate the responsible party for a E.164 number. It is incapable of doing so since there is no possible administrative chain of trust other than self assertion . Hence the possibility of identity or number/session hijacking is very large. You have to have the cooperation of the national numbering authorities or the issuer of the phone number to authenticate who is the responsible party . ViPR doesn't change that problem either. This has been a well known problem in SIP for some time and that was part of the difficulties that public ENUM had in e164.arpa. ENUM is doing very well BTW as a SS7/TCAP replacement however in private trees BTW. Consequently I think this issue has to be fully defined in the charter and I will gleefully anticipate what the security considerations text will look like. The fact that there is CISCO running code is utterly irrelevant. There is lots of bad code out there. I understand the problem of how do you create SIP federations across domains outside the scope of service providers, but without a comprehensive trust model this is going to fail. I do understand that many folks don't like their voice service providers or PSTN that perpetuates the use of E.164 numbers but this proposal is not going to solve that. IMHO in the absence of any rational trust or security model you can certainly publish something as Informational but getting something past the IESG is another thing entirely. From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] Sent: Saturday, July 03, 2010 5:49 PM To: Richard Shockey Cc: Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 Hi Richard, Clearly we don't want to be trying to solve the impossible - that could take a really long time. The mechanism in the ViPR drafts seemed to be able to accomplish the "finding the party responsible for a number" - and IIRC this is based on *running code* in the Cisco IME. ViPR is frankly not beautiful (in the way ICE is not beautiful) but I do think it can solve a problem which needs to be solved. Hence I support it. Peter Musgrave On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey wrote: A we already have centralized solutions for interdomain routing based on E.164. its called ENUM in both its private and public instantiations. It works pretty well BTW and globally deployed. IMHO this charter is a non starter and should not be approved on the basis of this statement alone. "finding domains that claim to be responsible for a given phone number" This IMHO is flat out impossible. Validating or authenticating an entity that is "responsible for a phone number" is as bad as " who is the carrier of record" , is a massive rathole. Cullen and Johathan should know better. Certs? LNP ? We have this problem of E.164 validation all the time in SIP and its not going to be solved in the IETF. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Wednesday, June 30, 2010 11:33 AM To: Mary Barnes Cc: DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 It looks to me that one can imagine 'centralized' solutions which are also based on reusing SIP related functionality developed in RAI. I would rather not close such an option and allow the WG a window of opportunity in which alternate solutions that could meet the same goals can be presented. Dan > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > Sent: Wednesday, June 30, 2010 6:24 PM > To: Romascanu, Dan (Dan) > Cc: DISPATCH; IETF-Discussion list > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > Hi Dan, > > The term peer to peer is intended to exclude mechanisms that > would use a central repository for the information: This was > discussed in an earlier thread: > http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html > > In one sense it is a solution, however, in another sense it > is reusing SIP related functionality defined in RAI and thus > is in a similar vein as specifying the use of SIP in a charter. > > Thanks, > Mary. > > On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) > wrote: > >> The VIPR WG will address this problem by developing a peer to peer > >> based approach to finding domains that claim to be > responsible for a > >> given phone number and validation protocols to ensure a reasonable > >> likelihood that a given domain actually is responsible for > the phone > >> number. > > > > Hi, > > > > Clarification question. What exactly means 'peer to peer > based approach' > > and what kind of approaches are excluded by having this in > the charter. > > Does 'approach' mean solution? If so why does a specific type of > > solution need to be agreed in the charter, while all we > have at hand > > at this point are individual contribution I-Ds that describe the > > 'problem statement and some possible starting points for solutions'? > > > > Thanks and Regards, > > > > Dan > > > > > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > >> Sent: Monday, June 28, 2010 8:38 PM > >> To: DISPATCH > >> Subject: [dispatch] VIPR - proposed charter version 3 > >> > > > _______________________________________________ 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_0001_01CB1C33.4D502940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t make that assumption at all. ENUM cannot be = used to establish any authoritative mapping of E.164 to domain. I fought that = war for 10 years and lost thank you.

 

In addition I reject the assertion in the proposed = charter that private federations don’t scale. In fact they do and are widely = deployed among service providers who in fact self assert their authority over = TN’s based on their own knowledge of what TN’s they are =  authoritative for and have access to the underlying national telephone numbering databases = and signaling mechanism.

 

The charter does not make any mention of Local Number Portability at all.

 

This discussion of running code is irrelevant here and = has zero merit in this discussion.  In fact a more simplistic approach to = the problem statement was developed by Asterisk years ago called DUNDI and = though I haven’t spoken to Mark Spencer and company in several years about = this subject, I don’t believe it deployed in any significant way. = It’s a form of DHT among trusted peers with self validation of the underlying = TN’s. It works. Fine. That is a private protocol deployed among private = Asterisk deployments.  There is a ID lying around somewhere. =

 

My assertion still holds. Without meaningful cooperation = of national numbering authorities it is impossible to establish a chain of trust = that can reliably determine the domain of authority for a E.164 number especially in = conditions where the number is either disconnected or potentially = ported.

 

The validation scheme proposed is essentially it can = successfully make a PSTN call.  Wow I’m impressed!  Then what? =  My assertion is that the charter has to reflect that there is no reliable = chain of trust or validation model for E.164 numbers and consequently assertion = of  E.164 numbers by domains relies on self validation.  The central thesis = of this proposed charter is false, that you can authoratively validate a mapping between E.164 and a domain.

 

You want to call this SELF-verification involving PSTN = reachability  fine. Then you would have a honest statement of what you propose = to develop. This is about “truth in protocol development” tm. =

 

 

From:= Peter = Musgrave [mailto:peter.musgrave@magorcorp.com]
Sent: Monday, July 05, 2010 9:15 AM
To: Richard Shockey
Cc: Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion = list
Subject: Re: [dispatch] VIPR - proposed charter version = 3

 

Hi, 

 

I think the charter issue here is an assumption = that number ownership is established using ENUM. I agree with you comments about = chains of trust, certs etc. and that this is likely impossible but they are not = the mechanism being proposed in the charter. It states:

 

"Some validation protocols may be based on knowledge gathered around a
PSTN call; for example, the ability to prove a call was received = over
the PSTN based on start and stop times. Other validation schemes, = such
as examining fingerprints or watermarking of PSTN media to show that = a
domain received a particular PSTN phone call, may also be considered = by
the working group. This validation will be accomplished using = publicly
available open interfaces to the PSTN, so the validation can be
performed by any domain wishing to participate.  The WG will select = and
standardize at least one validation scheme."

 

An = approach which is given as a sample solution is in the vipr-overview doc. The = fact that there is running code shows the solution has some = merit. 

 

Can you please clarify what part of this approach you view as = impossible?

 

Thanks, 

 

Peter Musgrave

On Sun, Jul 4, 2010 at 4:48 PM, Richard Shockey = <richard@shockey.us> wrote:

Well folks can certainly do = what they want to do. And the IETF has a lamentable record of some protocols that don’t accomplish much. But the core of this proposed WG is based = on a fallacy. ViPR cannot verify or authenticate the responsible party for a = E.164 number. It is incapable of doing so since there is no possible = administrative chain of trust other than self assertion .  Hence the possibility = of identity or number/session hijacking is very large. You have to have the cooperation of the national numbering authorities or the issuer of the = phone number to authenticate who is the responsible party . ViPR doesn’t = change that problem either.

 

This has been a well known = problem in SIP for some time and that was part of the difficulties that public ENUM = had in e164.arpa. ENUM is doing very well BTW as a SS7/TCAP replacement however = in private trees BTW.

 

Consequently I think this issue = has to be fully defined in the charter and I will gleefully anticipate what the security considerations text will look like.

 

The fact that there is CISCO = running code is utterly irrelevant. There is lots of bad code out there.  I understand the problem of how do you create SIP federations across = domains outside the scope of service providers, but without a comprehensive = trust model this is going to fail.  I do understand that many folks don’t = like their voice service providers or PSTN that perpetuates the use of E.164 = numbers but this proposal is not going to solve that.

 

IMHO in the absence of any = rational trust or security model you can certainly publish something as = Informational but getting something past the IESG is another thing = entirely.

 

From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]
Sent: Saturday, July 03, 2010 5:49 PM
To: Richard Shockey
Cc: Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion = list


Subject: Re: [dispatch] VIPR - proposed charter version = 3

 <= /o:p>

Hi Richard,

 <= /o:p>

Clearly we don't want to be trying to solve the impossible - that could take a = really long time. 

 <= /o:p>

The mechanism in the ViPR drafts seemed to be able to accomplish the = "finding the party responsible for a number" - and IIRC this is based on = *running code* in the Cisco IME. 

 <= /o:p>

ViPR is frankly not beautiful (in the way ICE is not beautiful) but I do = think it can solve a problem which needs to be solved. Hence I support = it. 

 <= /o:p>

Peter Musgrave

On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey <richard@shockey.us> wrote:

A we already have centralized solutions for interdomain routing based = on
E.164. its called ENUM in both its private and public instantiations. = It
works pretty well BTW and globally deployed.

IMHO this charter is a non starter and should not be approved on the = basis
of this statement alone.

"finding domains that claim to be responsible for a given phone number"

This IMHO is flat out impossible. Validating or authenticating an = entity
that is "responsible for a phone number" is as bad as =  " who is the carrier
of record" , is a massive rathole. Cullen and Johathan should know = better.
Certs? LNP ?

We have this problem of E.164 validation all the time in SIP and its = not
going to be solved in the IETF.

-----Original Message-----
From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf
Of Romascanu, Dan (Dan)
Sent: Wednesday, June 30, 2010 11:33 AM
To: Mary Barnes
Cc: DISPATCH; IETF-Discussion list
Subject: Re: [dispatch] VIPR - proposed charter version 3

It looks to me that one can imagine 'centralized' solutions which = are
also based on reusing SIP related functionality developed in RAI. I
would rather not close such an option and allow the WG a window of
opportunity in which alternate solutions that could meet the same = goals
can be presented.

Dan


> -----Original Message-----
> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> Sent: Wednesday, June 30, 2010 6:24 PM
> To: Romascanu, Dan (Dan)
> Cc: DISPATCH; IETF-Discussion list
> Subject: Re: [dispatch] VIPR - proposed charter version 3
>
> Hi Dan,
>
> The term peer to peer is intended to exclude mechanisms that
> would use a central repository for the information:  This = was
> discussed in an earlier thread:
> http://www.ietf.org/mail-archive/web/dispatch/current/m= sg02027.html
>
> In one sense it is a solution, however, in another sense it
> is reusing SIP related functionality defined in RAI and thus
> is in a similar vein as specifying the use of SIP in a charter.
>
> Thanks,
> Mary.
>
> On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan)
> <dromasca@avaya.com> wrote:
> >> The VIPR WG will address this problem by developing a peer = to peer
> >> based approach to finding domains that claim to be
> responsible for a
> >> given phone number and validation protocols to ensure a reasonable
> >> likelihood that a given domain actually is responsible = for
> the phone
> >> number.
> >
> > Hi,
> >
> > Clarification question. What exactly means 'peer to peer
> based approach'
> > and what kind of approaches are excluded by having this in
> the charter.
> > Does 'approach' mean solution? If so why does a specific type = of
> > solution need to be agreed in the charter, while all we
> have at hand
> > at this point are individual contribution I-Ds that describe = the
> > 'problem statement and some possible starting points for = solutions'?
> >
> > Thanks and Regards,
> >
> > Dan
> >
> >
> >> -----Original Message-----
> >> From: dispatch-bounces@ietf.org
> >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes
> >> Sent: Monday, June 28, 2010 8:38 PM
> >> To: DISPATCH
> >> Subject: [dispatch] VIPR - proposed charter version 3
> >>
> >
>
_______________________________________________
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=

 <= /o:p>

 

------=_NextPart_000_0001_01CB1C33.4D502940-- From pkyzivat@cisco.com Mon Jul 5 10:42:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CAD693A691A; Mon, 5 Jul 2010 10:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pt4ZJxG-51eh; Mon, 5 Jul 2010 10:42:50 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3D2783A6889; Mon, 5 Jul 2010 10:42:50 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEa2MUxAZnwN/2dsb2JhbACfdHGkUJokgl2CSASIOg X-IronPort-AV: E=Sophos;i="4.53,541,1272844800"; d="scan'208";a="128967836" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 05 Jul 2010 17:42:51 +0000 Received: from [10.86.251.180] (bxb-vpn3-948.cisco.com [10.86.251.180]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o65Hgo7v004755; Mon, 5 Jul 2010 17:42:51 GMT Message-ID: <4C32199A.80809@cisco.com> Date: Mon, 05 Jul 2010 13:42:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Richard Shockey References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> In-Reply-To: <009f01cb1bba$4c7bcd40$e57367c0$@us> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: 'DISPATCH' , 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 17:42:52 -0000 Richard, Have you actually read and understood the drafts that Jonathan submitted on ViPR? I don't see how you could make the assertions you are making if you had. Thanks, Paul Richard Shockey wrote: > Well folks can certainly do what they want to do. And the IETF has a > lamentable record of some protocols that don’t accomplish much. But the > core of this proposed WG is based on a fallacy. ViPR cannot verify or > authenticate the responsible party for a E.164 number. It is incapable > of doing so since there is no possible administrative chain of trust > other than self assertion . Hence the possibility of identity or > number/session hijacking is very large. You have to have the cooperation > of the national numbering authorities or the issuer of the phone number > to authenticate who is the responsible party . ViPR doesn’t change that > problem either. > > > > This has been a well known problem in SIP for some time and that was > part of the difficulties that public ENUM had in e164.arpa. ENUM is > doing very well BTW as a SS7/TCAP replacement however in private trees BTW. > > > > Consequently I think this issue has to be fully defined in the charter > and I will gleefully anticipate what the security considerations text > will look like. > > > > The fact that there is CISCO running code is utterly irrelevant. There > is lots of bad code out there. I understand the problem of how do you > create SIP federations across domains outside the scope of service > providers, but without a comprehensive trust model this is going to > fail. I do understand that many folks don’t like their voice service > providers or PSTN that perpetuates the use of E.164 numbers but this > proposal is not going to solve that. > > > > IMHO in the absence of any rational trust or security model you can > certainly publish something as Informational but getting something past > the IESG is another thing entirely. > > > > *From:* Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > *Sent:* Saturday, July 03, 2010 5:49 PM > *To:* Richard Shockey > *Cc:* Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion list > *Subject:* Re: [dispatch] VIPR - proposed charter version 3 > > > > Hi Richard, > > > > Clearly we don't want to be trying to solve the impossible - that could > take a really long time. > > > > The mechanism in the ViPR drafts seemed to be able to accomplish the > "finding the party responsible for a number" - and IIRC this is based on > *running code* in the Cisco IME. > > > > ViPR is frankly not beautiful (in the way ICE is not beautiful) but I do > think it can solve a problem which needs to be solved. Hence I support it. > > > > Peter Musgrave > > On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey > wrote: > > A we already have centralized solutions for interdomain routing based on > E.164. its called ENUM in both its private and public instantiations. It > works pretty well BTW and globally deployed. > > IMHO this charter is a non starter and should not be approved on the basis > of this statement alone. > > "finding domains that claim to be responsible for a given phone number" > > This IMHO is flat out impossible. Validating or authenticating an entity > that is "responsible for a phone number" is as bad as " who is the carrier > of record" , is a massive rathole. Cullen and Johathan should know better. > Certs? LNP ? > > We have this problem of E.164 validation all the time in SIP and its not > going to be solved in the IETF. > > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org ] On > Behalf > Of Romascanu, Dan (Dan) > Sent: Wednesday, June 30, 2010 11:33 AM > To: Mary Barnes > Cc: DISPATCH; IETF-Discussion list > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > It looks to me that one can imagine 'centralized' solutions which are > also based on reusing SIP related functionality developed in RAI. I > would rather not close such an option and allow the WG a window of > opportunity in which alternate solutions that could meet the same goals > can be presented. > > Dan > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com > ] > > Sent: Wednesday, June 30, 2010 6:24 PM > > To: Romascanu, Dan (Dan) > > Cc: DISPATCH; IETF-Discussion list > > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > > > Hi Dan, > > > > The term peer to peer is intended to exclude mechanisms that > > would use a central repository for the information: This was > > discussed in an earlier thread: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html > > > > In one sense it is a solution, however, in another sense it > > is reusing SIP related functionality defined in RAI and thus > > is in a similar vein as specifying the use of SIP in a charter. > > > > Thanks, > > Mary. > > > > On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) > > > wrote: > > >> The VIPR WG will address this problem by developing a peer to peer > > >> based approach to finding domains that claim to be > > responsible for a > > >> given phone number and validation protocols to ensure a reasonable > > >> likelihood that a given domain actually is responsible for > > the phone > > >> number. > > > > > > Hi, > > > > > > Clarification question. What exactly means 'peer to peer > > based approach' > > > and what kind of approaches are excluded by having this in > > the charter. > > > Does 'approach' mean solution? If so why does a specific type of > > > solution need to be agreed in the charter, while all we > > have at hand > > > at this point are individual contribution I-Ds that describe the > > > 'problem statement and some possible starting points for solutions'? > > > > > > Thanks and Regards, > > > > > > Dan > > > > > > > > >> -----Original Message----- > > >> From: dispatch-bounces@ietf.org > > >> [mailto:dispatch-bounces@ietf.org > ] On Behalf Of Mary Barnes > > >> Sent: Monday, June 28, 2010 8:38 PM > > >> To: DISPATCH > > >> Subject: [dispatch] VIPR - proposed charter version 3 > > >> > > > > > > _______________________________________________ > 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 richard@shockey.us Mon Jul 5 11:48:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE1C53A68E7 for ; Mon, 5 Jul 2010 11:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvHp8aTv8X1W for ; Mon, 5 Jul 2010 11:48:08 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id 2EE243A67EE for ; Mon, 5 Jul 2010 11:48:08 -0700 (PDT) Received: (qmail 27791 invoked by uid 0); 5 Jul 2010 18:48:08 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 5 Jul 2010 18:48:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=dNNt9CevM26SdPppHbsPqbTuwi0Tch/YSjjdTiR+MHUbQ+KQZLnNRaYtYCIvpDxPSCztOVaEUGvOxR/tTt2ktfbB3Cr/Mmuy2hRhY3bZbRRl5DBw4FWHsrGsFvYcMZqz; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OVqi8-000795-9m; Mon, 05 Jul 2010 12:48:08 -0600 From: "Richard Shockey" To: "'Paul Kyzivat'" References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> In-Reply-To: <4C32199A.80809@cisco.com> Date: Mon, 5 Jul 2010 14:48:06 -0400 Message-ID: <008d01cb1c72$9bdb96a0$d392c3e0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcscaX8dN4iSVSfAR6+wCu3OeaBQegABPUEw Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'DISPATCH' , 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 18:48:09 -0000 Paul of course I've read them, though the PVP document is uniquely dense and gave me a headache. Security by ID Obscurity. My assertion still stands. In the absence of any linkage in the PVP to the E164 numbering authorities and or databases any assertion about verification and validation of a E.164 is in essence self validation. The charter does NOT state that. My point is the proposed charter is badly written and implies a trust model that does not exist. You make a phone call if it answers and you hopefully get a caller ID that hasn't been spoofed then maybe you are OK and maybe you hope the TTL is set to some interval that doesn't cause number hijacking. But gee what happens when the number is disconnected from the PSTN? Hummmm The use of the term validation and or verification here implies authentication and my assertion is that any authentication of the responsible domain for a E.164 number outside of the PSTN service provider or national numbering authority is not possible under the current regulatory circumstances. Consequently the charter implies an ability to develop a solution which we all know is impossible. Solution rewrite the charter to note that fact that this is, in fact, "best efforts" only, "full disclosure" or "caveat emptor" to be precise. I'm not saying it might not work. As I used to tell Mark Spencer about DUNDI it's a fine intra-domain PBX session routing protocol. Might work in some highly integrated industries like airlines, auto etc but the empirical evidence indicates a uphill battle. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Monday, July 05, 2010 1:43 PM To: Richard Shockey Cc: 'Peter Musgrave'; 'DISPATCH'; 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - proposed charter version 3 Richard, Have you actually read and understood the drafts that Jonathan submitted on ViPR? I don't see how you could make the assertions you are making if you had. Thanks, Paul Richard Shockey wrote: > Well folks can certainly do what they want to do. And the IETF has a > lamentable record of some protocols that don't accomplish much. But the > core of this proposed WG is based on a fallacy. ViPR cannot verify or > authenticate the responsible party for a E.164 number. It is incapable > of doing so since there is no possible administrative chain of trust > other than self assertion . Hence the possibility of identity or > number/session hijacking is very large. You have to have the cooperation > of the national numbering authorities or the issuer of the phone number > to authenticate who is the responsible party . ViPR doesn't change that > problem either. > > > > This has been a well known problem in SIP for some time and that was > part of the difficulties that public ENUM had in e164.arpa. ENUM is > doing very well BTW as a SS7/TCAP replacement however in private trees BTW. > > > > Consequently I think this issue has to be fully defined in the charter > and I will gleefully anticipate what the security considerations text > will look like. > > > > The fact that there is CISCO running code is utterly irrelevant. There > is lots of bad code out there. I understand the problem of how do you > create SIP federations across domains outside the scope of service > providers, but without a comprehensive trust model this is going to > fail. I do understand that many folks don't like their voice service > providers or PSTN that perpetuates the use of E.164 numbers but this > proposal is not going to solve that. > > > > IMHO in the absence of any rational trust or security model you can > certainly publish something as Informational but getting something past > the IESG is another thing entirely. > > > > *From:* Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > *Sent:* Saturday, July 03, 2010 5:49 PM > *To:* Richard Shockey > *Cc:* Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion list > *Subject:* Re: [dispatch] VIPR - proposed charter version 3 > > > > Hi Richard, > > > > Clearly we don't want to be trying to solve the impossible - that could > take a really long time. > > > > The mechanism in the ViPR drafts seemed to be able to accomplish the > "finding the party responsible for a number" - and IIRC this is based on > *running code* in the Cisco IME. > > > > ViPR is frankly not beautiful (in the way ICE is not beautiful) but I do > think it can solve a problem which needs to be solved. Hence I support it. > > > > Peter Musgrave > > On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey > wrote: > > A we already have centralized solutions for interdomain routing based on > E.164. its called ENUM in both its private and public instantiations. It > works pretty well BTW and globally deployed. > > IMHO this charter is a non starter and should not be approved on the basis > of this statement alone. > > "finding domains that claim to be responsible for a given phone number" > > This IMHO is flat out impossible. Validating or authenticating an entity > that is "responsible for a phone number" is as bad as " who is the carrier > of record" , is a massive rathole. Cullen and Johathan should know better. > Certs? LNP ? > > We have this problem of E.164 validation all the time in SIP and its not > going to be solved in the IETF. > > -----Original Message----- > From: dispatch-bounces@ietf.org > [mailto:dispatch-bounces@ietf.org ] On > Behalf > Of Romascanu, Dan (Dan) > Sent: Wednesday, June 30, 2010 11:33 AM > To: Mary Barnes > Cc: DISPATCH; IETF-Discussion list > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > It looks to me that one can imagine 'centralized' solutions which are > also based on reusing SIP related functionality developed in RAI. I > would rather not close such an option and allow the WG a window of > opportunity in which alternate solutions that could meet the same goals > can be presented. > > Dan > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com > ] > > Sent: Wednesday, June 30, 2010 6:24 PM > > To: Romascanu, Dan (Dan) > > Cc: DISPATCH; IETF-Discussion list > > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > > > Hi Dan, > > > > The term peer to peer is intended to exclude mechanisms that > > would use a central repository for the information: This was > > discussed in an earlier thread: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg02027.html > > > > In one sense it is a solution, however, in another sense it > > is reusing SIP related functionality defined in RAI and thus > > is in a similar vein as specifying the use of SIP in a charter. > > > > Thanks, > > Mary. > > > > On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) > > > wrote: > > >> The VIPR WG will address this problem by developing a peer to peer > > >> based approach to finding domains that claim to be > > responsible for a > > >> given phone number and validation protocols to ensure a reasonable > > >> likelihood that a given domain actually is responsible for > > the phone > > >> number. > > > > > > Hi, > > > > > > Clarification question. What exactly means 'peer to peer > > based approach' > > > and what kind of approaches are excluded by having this in > > the charter. > > > Does 'approach' mean solution? If so why does a specific type of > > > solution need to be agreed in the charter, while all we > > have at hand > > > at this point are individual contribution I-Ds that describe the > > > 'problem statement and some possible starting points for solutions'? > > > > > > Thanks and Regards, > > > > > > Dan > > > > > > > > >> -----Original Message----- > > >> From: dispatch-bounces@ietf.org > > >> [mailto:dispatch-bounces@ietf.org > ] On Behalf Of Mary Barnes > > >> Sent: Monday, June 28, 2010 8:38 PM > > >> To: DISPATCH > > >> Subject: [dispatch] VIPR - proposed charter version 3 > > >> > > > > > > _______________________________________________ > 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 lconroy@insensate.co.uk Mon Jul 5 16:45:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6603A6781 for ; Mon, 5 Jul 2010 16:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eK2QNLwmXhhp for ; Mon, 5 Jul 2010 16:45:36 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id BF0B33A6982 for ; Mon, 5 Jul 2010 16:45:30 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 5710F2AC0D1; Tue, 6 Jul 2010 00:45:31 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <008d01cb1c72$9bdb96a0$d392c3e0$@us> Date: Tue, 6 Jul 2010 00:45:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk> References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> To: Richard Shockey X-Mailer: Apple Mail (2.1081) Cc: DISPATCH Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jul 2010 23:45:37 -0000 Hi Richard, folks, [removing ietf-general as cross-posting this whole thread doesn't help, = IMHO] I have remained silent so far, but just to clarify... Richard is absolutely correct. The comments on ENUM seemed to miss WHY public ENUM has been hard to = roll out. Each country (or region) has its own idea of Eligibility criteria for = ENUM domain registration in its jurisdiction. One thing they pretty much every one of the authorities agrees on is = that *AT LEAST* there has to be a demonstrable proof that the domain owner is provided (or provides) service via the associated E.164 number. To say that this is a challenge to arrange cheaply or simply (or at all) is an understatement. Trust me; I know to my cost, as does Richard. Even that does not demonstrate that a value published in an ENUM domain MUST be, by some guarantee, always tied to that domain and its = associated E.164 number. If I own a domain, I can provision what I like in that = domain. The validation "hook" is tied some way to the numbering authority for = E.164 numbers in a particular jurisdiction, and there IS no validation = authority that ties a SIP URI to an E.164 number. In private ENUM clouds, carriers "know their own" and trust partner = carriers (at least partially). That's a set of contractual agreements, nothing = more. The real question you have to ask is: can you gain access to the basic information on which the private ENUM domains provisioning is based? If you are part of that federation, then yes (at least you can query the private ENUM tree). If you are outside that federation, then no protocol magic is going to change that fact. Sorry for the long post, but it isn't a protocol issue; that well be LDAP (or something that scales). It's an operational and contractual agreement between CSPs, and last I heard that was not an IETF topic. all the best, Lawrence On 5 Jul 2010, at 19:48, Richard Shockey wrote: > my assertion is that any authentication of the > responsible domain for a E.164 number outside of the PSTN service = provider > or national numbering authority is not possible under the current = regulatory > circumstances. From petithug@acm.org Mon Jul 5 17:18:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8D23A677C for ; Mon, 5 Jul 2010 17:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.966 X-Spam-Level: X-Spam-Status: No, score=-100.966 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IlHxmw9ujlD6 for ; Mon, 5 Jul 2010 17:18:02 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id E694D3A63CB for ; Mon, 5 Jul 2010 17:18:02 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 5A02CDBD401C; Tue, 6 Jul 2010 00:18:04 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 10465DBD4018; Tue, 6 Jul 2010 00:18:01 +0000 (UTC) Message-ID: <4C327638.8030606@acm.org> Date: Mon, 05 Jul 2010 17:18:00 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100620 Iceowl/1.0b1 Icedove/3.0.5 MIME-Version: 1.0 To: Lawrence Conroy References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk> In-Reply-To: <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 00:18:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I see some similarities between ICE and ViPR - probably not surprising as they have a common author. One of the problem that RFC 3489 was trying to solve was: I need to be absolutely sure what kind of NAT I am using to choose the right NAT traversal method. It was discovered that this was an impossible problem to solve, so ICE went back to the requirement (which was not to know the type of NAT, but to establish a media path) and (IMO brilliantly) worked around the impossibility by simply trying all the possible media paths until one succeed. Who cares what kind of crappy software is in the NAT box, as long as we can make a reliable call. ENUM is the RFC 3489 of E.164 mapping. What ViPR propose is to use reality, i.e. PSTN calls that succeeded, to calculate a probability that a specific domain is, at a certain time, the owner of an E.164 number. Sure there is a lot of details to iron out, but that would be the mission of the WG. And BTW, the E.164 phone number that I put in my previous email is owned by a SIP provider and connected to a videophone on my desk. Try to call it from Skype and see if we can establish a video connection. I am willing to bet that in 12-24 months, ViPR will permit this. On 07/05/2010 04:45 PM, Lawrence Conroy wrote: > Hi Richard, folks, > [removing ietf-general as cross-posting this whole thread doesn't help, IMHO] > I have remained silent so far, but just to clarify... > Richard is absolutely correct. > The comments on ENUM seemed to miss WHY public ENUM has been hard to roll out. > > Each country (or region) has its own idea of Eligibility criteria for ENUM > domain registration in its jurisdiction. > One thing they pretty much every one of the authorities agrees on is that > *AT LEAST* there has to be a demonstrable proof that the domain owner is > provided (or provides) service via the associated E.164 number. > > To say that this is a challenge to arrange cheaply or simply (or at all) > is an understatement. Trust me; I know to my cost, as does Richard. > > Even that does not demonstrate that a value published in an ENUM domain > MUST be, by some guarantee, always tied to that domain and its associated > E.164 number. If I own a domain, I can provision what I like in that domain. > > The validation "hook" is tied some way to the numbering authority for E.164 > numbers in a particular jurisdiction, and there IS no validation authority > that ties a SIP URI to an E.164 number. > > In private ENUM clouds, carriers "know their own" and trust partner carriers > (at least partially). That's a set of contractual agreements, nothing more. > > The real question you have to ask is: can you gain access to the basic > information on which the private ENUM domains provisioning is based? > If you are part of that federation, then yes (at least you can query the > private ENUM tree). > If you are outside that federation, then no protocol magic is going to > change that fact. > > Sorry for the long post, but it isn't a protocol issue; that well be > LDAP (or something that scales). It's an operational and contractual > agreement between CSPs, and last I heard that was not an IETF topic. > > all the best, > Lawrence > > On 5 Jul 2010, at 19:48, Richard Shockey wrote: >> my assertion is that any authentication of the >> responsible domain for a E.164 number outside of the PSTN service provider >> or national numbering authority is not possible under the current regulatory >> circumstances. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwydjQACgkQ9RoMZyVa61eaeACfVT/IMeGCJH5oyet+OEm/T8SS ZOkAoI7x/pMc8Riv/7U1Z9dMyCyZAv/k =VGrz -----END PGP SIGNATURE----- From richard@shockey.us Mon Jul 5 18:27:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81FC93A6903 for ; Mon, 5 Jul 2010 18:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.036 X-Spam-Level: X-Spam-Status: No, score=-0.036 tagged_above=-999 required=5 tests=[AWL=-0.371, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTCvXvx7z5QB for ; Mon, 5 Jul 2010 18:27:02 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id 6A3EB3A68F1 for ; Mon, 5 Jul 2010 18:27:02 -0700 (PDT) Received: (qmail 26776 invoked by uid 0); 6 Jul 2010 01:27:04 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 6 Jul 2010 01:27:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=h7zDKkUEIvdTvouXTa1KCjQ/L0rqbcD1be7kEshe5j/sMMlZgKSc8Mnc7HqUscCNVfWLzvqkRcGGZyTA1bP2hiBGE8FK/CUoLnSdeO/gZNLjOM1rWGFjMgU38G+NSpc7; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OVwwB-0007ZJ-Kk; Mon, 05 Jul 2010 19:27:03 -0600 From: "Richard Shockey" To: "'Lawrence Conroy'" References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk> In-Reply-To: <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk> Date: Mon, 5 Jul 2010 21:27:01 -0400 Message-ID: <01f801cb1caa$5667eaa0$0337bfe0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcscnCkWhjKI35+fQNiG3Tjx6egbNAADFVqg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'DISPATCH' , 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 01:27:03 -0000 Thank you Brother Conroy... this is a full IETF discussion since it does involve the creation of a new working group that does not seem to understand what is actually involved in E.164 validation. I do understand what this is really about..how do we screw global voice service providers since the IETF has not been able to convince normal folk to use SIP URI's. A reasonable objective, but I haven't seen many SIP URI on the back of plumbing or tree conservation trucks driving down my Reston VA neighborhoods recently. HTTP URI's are another thing. The real ultimate question is, can we, the SIP community, possibly learn to live with E.164 in SIP in some rational manner? Phone numbers are not going to go away as much as my dear friend Henry Sinnreich would prefer. -----Original Message----- From: Lawrence Conroy [mailto:lconroy@insensate.co.uk] Sent: Monday, July 05, 2010 7:46 PM To: Richard Shockey Cc: Paul Kyzivat; DISPATCH Subject: Re: [dispatch] VIPR - proposed charter version 3 Hi Richard, folks, [removing ietf-general as cross-posting this whole thread doesn't help, IMHO] I have remained silent so far, but just to clarify... Richard is absolutely correct. The comments on ENUM seemed to miss WHY public ENUM has been hard to roll out. Each country (or region) has its own idea of Eligibility criteria for ENUM domain registration in its jurisdiction. One thing they pretty much every one of the authorities agrees on is that *AT LEAST* there has to be a demonstrable proof that the domain owner is provided (or provides) service via the associated E.164 number. To say that this is a challenge to arrange cheaply or simply (or at all) is an understatement. Trust me; I know to my cost, as does Richard. Even that does not demonstrate that a value published in an ENUM domain MUST be, by some guarantee, always tied to that domain and its associated E.164 number. If I own a domain, I can provision what I like in that domain. The validation "hook" is tied some way to the numbering authority for E.164 numbers in a particular jurisdiction, and there IS no validation authority that ties a SIP URI to an E.164 number. In private ENUM clouds, carriers "know their own" and trust partner carriers (at least partially). That's a set of contractual agreements, nothing more. The real question you have to ask is: can you gain access to the basic information on which the private ENUM domains provisioning is based? If you are part of that federation, then yes (at least you can query the private ENUM tree). If you are outside that federation, then no protocol magic is going to change that fact. Sorry for the long post, but it isn't a protocol issue; that well be LDAP (or something that scales). It's an operational and contractual agreement between CSPs, and last I heard that was not an IETF topic. all the best, Lawrence On 5 Jul 2010, at 19:48, Richard Shockey wrote: > my assertion is that any authentication of the > responsible domain for a E.164 number outside of the PSTN service provider > or national numbering authority is not possible under the current regulatory > circumstances. From HKaplan@acmepacket.com Tue Jul 6 01:21:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA8D93A6947 for ; Tue, 6 Jul 2010 01:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGSi+q4wyoQZ for ; Tue, 6 Jul 2010 01:21:59 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A663D3A6870 for ; Tue, 6 Jul 2010 01:21:58 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 6 Jul 2010 04:21:59 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 6 Jul 2010 04:21:59 -0400 From: Hadriel Kaplan To: "gao.yang2@zte.com.cn" , "dispatch@ietf.org" Date: Tue, 6 Jul 2010 04:22:03 -0400 Thread-Topic: About Final Charter for Session-ID: Thread-Index: AcsX8TSxpF8TKusISfW1BbzTSCSwlwE8uU+A Message-ID: <430FC6BDED356B4C8498F634416644A91FE874DCB1@mail> 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: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A91FE874DCB1mail_" MIME-Version: 1.0 Subject: Re: [dispatch] About Final Charter for Session-ID: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 08:22:00 -0000 --_000_430FC6BDED356B4C8498F634416644A91FE874DCB1mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Right, my intention was to NOT impact/affect/include dialog-matching, or an= ything but troubleshooting. But of course a charter and WG is a consensus-= based decision, not mine, so if others feel they want more they can argue f= or it. -hadriel ________________________________ From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn] Sent: Tuesday, June 29, 2010 9:08 PM To: dispatch@ietf.org Cc: Hadriel Kaplan Subject: About Final Charter for Session-ID: Hi, By the charter and the original text named draft-kaplan-sip-session-id-02, = this work is just focused on troubleshooting usage. But I was told that *someone* want to use this session-id in Replace header= usage, to do dialog-matching. I think this would be UPDATE of RFC3891. So, I'd like to confirm that this charter and coming draft would not do suc= h thing normatively. Thanks, Gao =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_430FC6BDED356B4C8498F634416644A91FE874DCB1mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Right, my intention was to NOT impact/= affect/include dialog-matching, or anything but troubleshooting.  But of course a cha= rter and WG is a consensus-based decision, not mine, so if others feel they want more they can argue for it.

-hadriel

 

 

From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
Sent: Tuesday, June 29, 2010= 9:08 PM
To: dispatch@ietf.org
Cc: Hadriel Kaplan
Subject: About Final Charter= for Session-ID:

 


Hi,

By the charter and the original text named draft-kaplan-sip-session-id-02, thi= s work is just focused on troubleshooting usage.

But I was told that *someone* want to use this session-id in Replace header usa= ge, to do dialog-matching. I think this would be UPDATE of RFC3891.

So, I'd like to confirm that this charter and coming draft would not do such th= ing normatively.

Thanks,

Gao

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<=
o:p> 
------------=
--------------------------------------------
= 
ZTE Inf=
ormation Security Notice: The information containe=
d in this mail is solely property of&nbs=
p;the sender's organization. This mail communicati=
on is confidential. Recipients named above ar=
e obligated to maintain secrecy and are =
not permitted to disclose the contents of&nbs=
p;this communication to others.
This em=
ail and any files transmitted with it ar=
e confidential and intended solely for the&nb=
sp;use of the individual or entity to wh=
om they are addressed. If you have recei=
ved this email in error please notify th=
e originator of the message. Any views e=
xpressed in this message are those of th=
e individual sender.
This me=
ssage has been scanned for viruses and S=
pam by ZTE Anti-Spam system.
--_000_430FC6BDED356B4C8498F634416644A91FE874DCB1mail_-- From peter.musgrave@magorcorp.com Tue Jul 6 05:20:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 821B13A6905; Tue, 6 Jul 2010 05:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2mcDae90OGW; Tue, 6 Jul 2010 05:20:50 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 110643A6900; Tue, 6 Jul 2010 05:20:49 -0700 (PDT) Received: by vws14 with SMTP id 14so5985523vws.31 for ; Tue, 06 Jul 2010 05:20:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.190.14 with SMTP id dg14mr2567199qcb.49.1278418846582; Tue, 06 Jul 2010 05:20:46 -0700 (PDT) Received: by 10.229.220.10 with HTTP; Tue, 6 Jul 2010 05:20:46 -0700 (PDT) In-Reply-To: <01f801cb1caa$5667eaa0$0337bfe0$@us> References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk> <01f801cb1caa$5667eaa0$0337bfe0$@us> Date: Tue, 6 Jul 2010 08:20:46 -0400 Message-ID: From: Peter Musgrave To: Richard Shockey Content-Type: multipart/alternative; boundary=00163630f61f39a0c9048ab71588 Cc: DISPATCH , IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 12:20:51 -0000 --00163630f61f39a0c9048ab71588 Content-Type: text/plain; charset=ISO-8859-1 Hi, >From my perspective what this is really about is the ability for me to have interoperable ad-hoc video calls between businesses which can be established via SIP with a "good enough" level of authentication and security. ViPR appears to be the best candidate at this point. It has the advantage that it is self-contained and not reliant on any centralized mechanism. It is clearly not perfect and there will be issues which need careful consideration (including some of the security issues you have raised w.r.t. call id spoofing, number migration etc.). Is there a specific disclaimer you would like to see added to the charter so these limitations are clearly set forth in the WG definition or is your objection irreconcilable? Regards, Peter Musgrave On Mon, Jul 5, 2010 at 9:27 PM, Richard Shockey wrote: > Thank you Brother Conroy... this is a full IETF discussion since it does > involve the creation of a new working group that does not seem to > understand > what is actually involved in E.164 validation. > > I do understand what this is really about..how do we screw global voice > service providers since the IETF has not been able to convince normal folk > to use SIP URI's. > > A reasonable objective, but I haven't seen many SIP URI on the back of > plumbing or tree conservation trucks driving down my Reston VA > neighborhoods > recently. HTTP URI's are another thing. > > The real ultimate question is, can we, the SIP community, possibly learn to > live with E.164 in SIP in some rational manner? Phone numbers are not going > to go away as much as my dear friend Henry Sinnreich would prefer. > > -----Original Message----- > From: Lawrence Conroy [mailto:lconroy@insensate.co.uk] > Sent: Monday, July 05, 2010 7:46 PM > To: Richard Shockey > Cc: Paul Kyzivat; DISPATCH > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > Hi Richard, folks, > [removing ietf-general as cross-posting this whole thread doesn't help, > IMHO] > I have remained silent so far, but just to clarify... > Richard is absolutely correct. > The comments on ENUM seemed to miss WHY public ENUM has been hard to roll > out. > > Each country (or region) has its own idea of Eligibility criteria for ENUM > domain registration in its jurisdiction. > One thing they pretty much every one of the authorities agrees on is that > *AT LEAST* there has to be a demonstrable proof that the domain owner is > provided (or provides) service via the associated E.164 number. > > To say that this is a challenge to arrange cheaply or simply (or at all) > is an understatement. Trust me; I know to my cost, as does Richard. > > Even that does not demonstrate that a value published in an ENUM domain > MUST be, by some guarantee, always tied to that domain and its associated > E.164 number. If I own a domain, I can provision what I like in that > domain. > > The validation "hook" is tied some way to the numbering authority for E.164 > numbers in a particular jurisdiction, and there IS no validation authority > that ties a SIP URI to an E.164 number. > > In private ENUM clouds, carriers "know their own" and trust partner > carriers > (at least partially). That's a set of contractual agreements, nothing more. > > The real question you have to ask is: can you gain access to the basic > information on which the private ENUM domains provisioning is based? > If you are part of that federation, then yes (at least you can query the > private ENUM tree). > If you are outside that federation, then no protocol magic is going to > change that fact. > > Sorry for the long post, but it isn't a protocol issue; that well be > LDAP (or something that scales). It's an operational and contractual > agreement between CSPs, and last I heard that was not an IETF topic. > > all the best, > Lawrence > > On 5 Jul 2010, at 19:48, Richard Shockey wrote: > > my assertion is that any authentication of the > > responsible domain for a E.164 number outside of the PSTN service > provider > > or national numbering authority is not possible under the current > regulatory > > circumstances. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --00163630f61f39a0c9048ab71588 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=A0

From my perspective what this is really about is = the ability for me to have interoperable ad-hoc video calls between busines= ses which can be established via SIP with a "good enough" level o= f authentication and security.=A0

ViPR appears to be the best candidate at this point. It= has the advantage that it is self-contained and not reliant on any central= ized mechanism. It is clearly not perfect and there will be issues which ne= ed careful consideration (including some of the security issues you have ra= ised w.r.t. call id spoofing, number migration etc.).=A0

Is there a specific disclaimer you would like to see ad= ded to the charter so these limitations are clearly set forth in the WG def= inition or is your objection irreconcilable?

Regar= ds,

Peter Musgrave



On Mon, Jul 5, 2010 at 9:27 PM, Richard Shockey <richard@shockey.us= > wrote:
Thank you Brother Conroy... this is a full = IETF discussion since it does
involve the creation of a new working group that does not seem to understan= d
what is actually involved in E.164 validation.

I do understand what this is really about..how do we screw global voice
service providers since the IETF has not been able to convince normal folk<= br> to use SIP URI's.

A reasonable objective, but I haven't seen many SIP URI on the back of<= br> plumbing or tree conservation trucks driving down my Reston VA neighborhood= s
recently. HTTP URI's are another thing.

The real ultimate question is, can we, the SIP community, possibly learn to=
live with E.164 in SIP in some rational manner? Phone numbers are not going=
to go away as much as my dear friend Henry Sinnreich would prefer.

-----Original Message-----
From: Lawrence Conroy [mailto:lc= onroy@insensate.co.uk]
Sent: Monday, July 05, 2010 7:46 PM
To: Richard Shockey
Cc: Paul Kyzivat; DISPATCH
Subject: Re: [dispatch] VIPR - proposed charter version 3

Hi Richard, folks,
=A0[removing ietf-general as cross-posting this whole thread doesn't he= lp,
IMHO]
I have remained silent so far, but just to clarify...
Richard is absolutely correct.
The comments on ENUM seemed to miss WHY public ENUM has been hard to roll out.

Each country (or region) has its own idea of Eligibility criteria for ENUM<= br> domain registration in its jurisdiction.
One thing they pretty much every one of the authorities agrees on is that *AT LEAST* there has to be a demonstrable proof that the domain owner is provided (or provides) service via the associated E.164 number.

To say that this is a challenge to arrange cheaply or simply (or at all) is an understatement. Trust me; I know to my cost, as does Richard.

Even that does not demonstrate that a value published in an ENUM domain
MUST be, by some guarantee, always tied to that domain and its associated E.164 number. If I own a domain, I can provision what I like in that domain= .

The validation "hook" is tied some way to the numbering authority= for E.164
numbers in a particular jurisdiction, and there IS no validation authority<= br> that ties a SIP URI to an E.164 number.

In private ENUM clouds, carriers "know their own" and trust partn= er carriers
(at least partially). That's a set of contractual agreements, nothing m= ore.

The real question you have to ask is: can you gain access to the basic
information on which the private ENUM domains provisioning is based?
If you are part of that federation, then yes (at least you can query the private ENUM tree).
If you are outside that federation, then no protocol magic is going to
change that fact.

Sorry for the long post, but it isn't a protocol issue; that well be LDAP (or something that scales). It's an operational and contractual agreement between CSPs, and last I heard that was not an IETF topic.

all the best,
=A0Lawrence

On 5 Jul 2010, at 19:48, Richard Shockey wrote:
> my assertion is that any authentication of the
> responsible domain for a E.164 number outside of the PSTN service prov= ider
> or national numbering authority is not possible under the current
regulatory
> circumstances.

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

--00163630f61f39a0c9048ab71588-- From adam@nostrum.com Tue Jul 6 07:28:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00F1B3A6946; Tue, 6 Jul 2010 07:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1TuehA-jRRr; Tue, 6 Jul 2010 07:28:30 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id DD0473A6902; Tue, 6 Jul 2010 07:28:29 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o66ESUWS013425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jul 2010 09:28:30 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C333D8E.6090505@nostrum.com> Date: Tue, 06 Jul 2010 09:28:30 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Peter Musgrave References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk> <01f801cb1caa$5667eaa0$0337bfe0$@us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: DISPATCH , IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 14:28:31 -0000 On 7/6/10 7:20 AM, Peter Musgrave wrote: > From my perspective what this is really about is the ability for me to > have interoperable ad-hoc video calls between businesses which can be > established via SIP with a "good enough" level of authentication and > security. You're looking in the wrong place, then. The problem is that VIPR really provides something more like "random failure surprise," as some portion of the call attempts must go over the (non-video-capable) PSTN. The user doesn't have any idea about, or control over, when this will happen. So while it might be something you could use for personal purposes -- where frequent video call setup failures would be okay -- I doubt it's a viable video solution in a business environment. To run a business, you need something better than "random failure surprise". /a From peter.musgrave@magorcorp.com Tue Jul 6 08:32:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2052F3A680D; Tue, 6 Jul 2010 08:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.552 X-Spam-Level: X-Spam-Status: No, score=-1.552 tagged_above=-999 required=5 tests=[AWL=0.424, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ChZG75nMGhcr; Tue, 6 Jul 2010 08:32:12 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id D84283A65A6; Tue, 6 Jul 2010 08:32:11 -0700 (PDT) Received: by gxk3 with SMTP id 3so1487013gxk.31 for ; Tue, 06 Jul 2010 08:32:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.226.208 with SMTP id ix16mr2765641qcb.175.1278428452981; Tue, 06 Jul 2010 08:00:52 -0700 (PDT) Received: by 10.229.220.10 with HTTP; Tue, 6 Jul 2010 08:00:52 -0700 (PDT) In-Reply-To: <4C333D8E.6090505@nostrum.com> References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk> <01f801cb1caa$5667eaa0$0337bfe0$@us> <4C333D8E.6090505@nostrum.com> Date: Tue, 6 Jul 2010 11:00:52 -0400 Message-ID: From: Peter Musgrave To: Adam Roach , Cullen Jennings , jonathan@rosen.net Content-Type: multipart/alternative; boundary=001636310151cf8dff048ab95178 Cc: DISPATCH , IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 15:32:13 -0000 --001636310151cf8dff048ab95178 Content-Type: text/plain; charset=ISO-8859-1 Yeah. Sigh. I guess the issue then becomes whether this is enough of a step in right direction that it can be built on - and whether it's worth the effort. Cullen/Jonathan - can you speak to any of the operational issues w.r.t. 'failure surprise' in the existing implementation? Regards, Peter Musgrave On Tue, Jul 6, 2010 at 10:28 AM, Adam Roach wrote: > On 7/6/10 7:20 AM, Peter Musgrave wrote: > >> From my perspective what this is really about is the ability for me to >> have interoperable ad-hoc video calls between businesses which can be >> established via SIP with a "good enough" level of authentication and >> security. >> > > > You're looking in the wrong place, then. > > The problem is that VIPR really provides something more like "random > failure surprise," as some portion of the call attempts must go over the > (non-video-capable) PSTN. The user doesn't have any idea about, or control > over, when this will happen. So while it might be something you could use > for personal purposes -- where frequent video call setup failures would be > okay -- I doubt it's a viable video solution in a business environment. To > run a business, you need something better than "random failure surprise". > > /a > --001636310151cf8dff048ab95178 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yeah.=A0Sigh.=A0

I guess the issue then becomes whether = this is enough of a step in right direction that it can be built on - and w= hether it's worth the effort.=A0

Cullen/Jonath= an - can you speak to any of the operational issues w.r.t. 'failure sur= prise' in the existing implementation?

Regards,

Peter Musgrave
On Tue, Jul 6, 2010 at 10:28 AM, Adam Roach <adam@nostrum.com= > wrote:
=A0On 7/6/10 7:20 AM, Pet= er Musgrave wrote:
>From my perspective what this is really about is the ability for me to have= interoperable ad-hoc video calls between businesses which can be establish= ed via SIP with a "good enough" level of authentication and secur= ity.


You're looking in the wrong place, then.

The problem is that VIPR really provides something more like "random f= ailure surprise," as some portion of the call attempts must go over th= e (non-video-capable) PSTN. The user doesn't have any idea about, or co= ntrol over, when this will happen. So while it might be something you could= use for personal purposes -- where frequent video call setup failures woul= d be okay -- I doubt it's a viable video solution in a business environ= ment. To run a business, you need something better than "random failur= e surprise".

/a

--001636310151cf8dff048ab95178-- From adam@nostrum.com Tue Jul 6 08:39:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21DF83A63C9; Tue, 6 Jul 2010 08:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZ2lixciOyQq; Tue, 6 Jul 2010 08:39:36 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E16523A67E5; Tue, 6 Jul 2010 08:39:35 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o66FdZJL020461 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jul 2010 10:39:35 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C334E37.10200@nostrum.com> Date: Tue, 06 Jul 2010 10:39:35 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Peter Musgrave References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk> <01f801cb1caa$5667eaa0$0337bfe0$@us> <4C333D8E.6090505@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: DISPATCH , IETF-Discussion list , jonathan@rosen.net Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 15:39:37 -0000 On 7/6/10 10:00 AM, Peter Musgrave wrote: > Yeah. Sigh. > > I guess the issue then becomes whether this is enough of a step in > right direction that it can be built on - and whether it's worth the > effort. > > Cullen/Jonathan - can you speak to any of the operational issues > w.r.t. 'failure surprise' in the existing implementation? Well, to be clear, with voice communications, you don't end up with "random failure surprise". You end up with "random quality surprise". Some of your voice communications go over whatever codec your device uses for VoIP, which is probably a nice broadband codec. But some calls will randomly use the PSTN, with an 8 kHz sampling frequency and a notch-pass filter at 2600 Hz. While that's kind of an unpleasant property, it's not enough to disqualify it from normal business use. My point was that it's not a reasonable multimedia solution. If all you're looking for is feature parity with the PSTN, it's a passable solution, even if just barely. /a From richard@shockey.us Tue Jul 6 08:56:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCB3E3A698C for ; Tue, 6 Jul 2010 08:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.076 X-Spam-Level: X-Spam-Status: No, score=0.076 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7I7G-2GB8Y-n for ; Tue, 6 Jul 2010 08:56:12 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id E55163A6985 for ; Tue, 6 Jul 2010 08:56:11 -0700 (PDT) Received: (qmail 13931 invoked by uid 0); 6 Jul 2010 15:56:14 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 6 Jul 2010 15:56:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:thread-index:Content-Language:X-Identified-User; b=nh0w9rr3Rgws6SpdEGJI0FG0jiZ4bkyFZJiWiftw1BqTO0C5k+x7e/c1TcTRz1ivPY5OZcraNW/4fdjAVNSx1Ts/O7+mbe9TViB0XM52rjJYfOnJhrOLOAzLhtKVe8RK; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OWAVJ-0002o9-NU; Tue, 06 Jul 2010 09:56:14 -0600 From: "Richard Shockey" To: "'Peter Musgrave'" References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk> <01f801cb1caa$5667eaa0$0337bfe0$@us> In-Reply-To: Date: Tue, 6 Jul 2010 11:56:12 -0400 Message-ID: <00db01cb1d23$c273c920$475b5b60$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DC_01CB1D02.3B622920" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcsdBapWawYuaaFnRRG4Ym/NFnrikAAHZYnA Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'DISPATCH' , 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - Speaking of Video Calls .. X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 15:56:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00DC_01CB1D02.3B622920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Speaking of ad-hoc video calls. Side bar issue.. Has anyone figured out who to talk to at Apple about FaceTime? Granted Apple has had a few "issues" to deal with recently but the silence on how they plan to publish their profile is deafening. I call Steve's office if I have to ..but From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] Sent: Tuesday, July 06, 2010 8:21 AM To: Richard Shockey Cc: Lawrence Conroy; DISPATCH; IETF-Discussion list Subject: Re: [dispatch] VIPR - proposed charter version 3 Hi, >From my perspective what this is really about is the ability for me to have interoperable ad-hoc video calls between businesses which can be established via SIP with a "good enough" level of authentication and security. ------=_NextPart_000_00DC_01CB1D02.3B622920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Speaking of ad-hoc video calls.

 

Side bar issue.. Has anyone figured out who to talk to at = Apple about FaceTime?  Granted Apple has had a few “issues” = to deal with recently but the silence on how they plan to publish their profile is = deafening.

 

I call Steve’s office if I have to ..but =

 

From:= Peter = Musgrave [mailto:peter.musgrave@magorcorp.com]
Sent: Tuesday, July 06, 2010 8:21 AM
To: Richard Shockey
Cc: Lawrence Conroy; DISPATCH; IETF-Discussion list
Subject: Re: [dispatch] VIPR - proposed charter version = 3

 

Hi, 

 

From my perspective what this is really about is = the ability for me to have interoperable ad-hoc video calls between businesses which = can be established via SIP with a "good enough" level of = authentication and security. 

 

------=_NextPart_000_00DC_01CB1D02.3B622920-- From richard@shockey.us Tue Jul 6 10:06:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4F263A690F for ; Tue, 6 Jul 2010 10:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.368 X-Spam-Level: X-Spam-Status: No, score=-1.368 tagged_above=-999 required=5 tests=[AWL=1.231, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVJluW1sJyOM for ; Tue, 6 Jul 2010 10:06:42 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 70C9C3A6A57 for ; Tue, 6 Jul 2010 10:06:42 -0700 (PDT) Received: (qmail 4151 invoked by uid 0); 6 Jul 2010 17:06:44 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 6 Jul 2010 17:06:44 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:thread-index:Content-Language:X-Identified-User; b=G96b+foelx3pi7Kaa/gMoIqU6rwxahH6L26bua3Ed7xABma3Afj2EDr5rn41q9G/x2XDiuaPIcoX6wOEbtMY7t6Fbtpxtpex0CpjjCGCq4yaRzzktccj4+ZuELJRwxse; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OWBbY-0000Lr-EJ; Tue, 06 Jul 2010 11:06:44 -0600 From: "Richard Shockey" To: "'Adam Roach'" , "'Peter Musgrave'" References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk> <01f801cb1caa$5667eaa0$0337bfe0$@us> <4C333D8E.6090505@nostrum.com> <4C334E37.10200@nostrum.com> In-Reply-To: <4C334E37.10200@nostrum.com> Date: Tue, 6 Jul 2010 13:06:42 -0400 Message-ID: <016401cb1d2d$9c240050$d46c00f0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcsdIXVXlk+egPk+RxKOOUgrlTHuOgAC40xQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'DISPATCH' , 'IETF-Discussion list' , jonathan@rosen.net Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 17:06:44 -0000 Adam is entirely right here. The question is do you want to standardize such a service in the IETF. "Best Efforts" is not a problem on the Internet in general. After all about 14% of all international call traffic is now going over Skype. You simply have to make that clear from the outset which is why IMHO the charter as it is currently written is unacceptable. -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Adam Roach Sent: Tuesday, July 06, 2010 11:40 AM To: Peter Musgrave Cc: Cullen Jennings; DISPATCH; Richard Shockey; IETF-Discussion list; jonathan@rosen.net Subject: Re: [dispatch] VIPR - proposed charter version 3 On 7/6/10 10:00 AM, Peter Musgrave wrote: > Yeah. Sigh. > > I guess the issue then becomes whether this is enough of a step in > right direction that it can be built on - and whether it's worth the > effort. > > Cullen/Jonathan - can you speak to any of the operational issues > w.r.t. 'failure surprise' in the existing implementation? Well, to be clear, with voice communications, you don't end up with "random failure surprise". You end up with "random quality surprise". Some of your voice communications go over whatever codec your device uses for VoIP, which is probably a nice broadband codec. But some calls will randomly use the PSTN, with an 8 kHz sampling frequency and a notch-pass filter at 2600 Hz. While that's kind of an unpleasant property, it's not enough to disqualify it from normal business use. My point was that it's not a reasonable multimedia solution. If all you're looking for is feature parity with the PSTN, it's a passable solution, even if just barely. /a _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From pkyzivat@cisco.com Tue Jul 6 10:23:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B12A3A6980; Tue, 6 Jul 2010 10:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YlPIzDSEqcr; Tue, 6 Jul 2010 10:23:58 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5269A3A6944; Tue, 6 Jul 2010 10:23:58 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFMDM0xAZnwN/2dsb2JhbACgAnGnP5pNhSUEiDo X-IronPort-AV: E=Sophos;i="4.53,547,1272844800"; d="scan'208";a="129313803" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2010 17:24:00 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o66HO09Y028662; Tue, 6 Jul 2010 17:24:00 GMT Message-ID: <4C3366B0.8080005@cisco.com> Date: Tue, 06 Jul 2010 13:24:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Richard Shockey References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> In-Reply-To: <008d01cb1c72$9bdb96a0$d392c3e0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'DISPATCH' , 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 17:23:59 -0000 Richard Shockey wrote: > Paul of course I've read them, though the PVP document is uniquely dense and > gave me a headache. Security by ID Obscurity. > > My assertion still stands. In the absence of any linkage in the PVP to the > E164 numbering authorities and or databases any assertion about verification > and validation of a E.164 is in essence self validation. The charter does > NOT state that. My point is the proposed charter is badly written and > implies a trust model that does not exist. > > You make a phone call if it answers and you hopefully get a caller ID that > hasn't been spoofed then maybe you are OK and maybe you hope the TTL is set > to some interval that doesn't cause number hijacking. But gee what happens > when the number is disconnected from the PSTN? Hummmm > > The use of the term validation and or verification here implies > authentication and my assertion is that any authentication of the > responsible domain for a E.164 number outside of the PSTN service provider > or national numbering authority is not possible under the current regulatory > circumstances. Consequently the charter implies an ability to develop a > solution which we all know is impossible. Perhaps better terms can be found and used. But the end effect is that the destination you reach using ViPR has the same assuredness of being who you thought it would be as an actual PSTN call has. For the most part, that is a level of assurance that many people are comfortable with, even if we know that is not as reliable as most people think it is. And regardless of whether it is as good as people would like, it is as good as can be had in most cases with the current state of the art. Thanks, Paul From pp3129@att.com Tue Jul 6 10:32:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B8273A6878 for ; Tue, 6 Jul 2010 10:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fFIF7ktDs3q7 for ; Tue, 6 Jul 2010 10:32:05 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id DE1283A682B for ; Tue, 6 Jul 2010 10:32:04 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-8.tower-167.messagelabs.com!1278437525!20109391!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 4932 invoked from network); 6 Jul 2010 17:32:06 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-8.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Jul 2010 17:32:06 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o66HVfpx000843 for ; Tue, 6 Jul 2010 13:31:41 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o66HVaQt000753 for ; Tue, 6 Jul 2010 13:31:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Jul 2010 13:32:00 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B044A9168@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <4C3366B0.8080005@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 3 Thread-Index: AcsdMBB6Ox23hZp2QoGa8E9ti8VvGwAAHGgA References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com><008d01cb1c72$9bdb96a0$d392c3e0$@us> <4C3366B0.8080005@cisco.com> From: "PFAUTZ, PENN L (ATTCORP)" To: "DISPATCH" Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 17:32:06 -0000 Paul: I'm not sure I agree with the statement "But the end effect is that the destination you reach using ViPR has the same assuredness of being who you thought it would be as an actual PSTN=20 call has." If call traverses mulitple networks on a particular PSTN routing couldn't any of those assert responsibility for the number? Thanks, Penn Pfautz -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Tuesday, July 06, 2010 1:24 PM To: Richard Shockey Cc: 'DISPATCH'; 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - proposed charter version 3 Richard Shockey wrote: > Paul of course I've read them, though the PVP document is uniquely dense and > gave me a headache. Security by ID Obscurity.=20 >=20 > My assertion still stands. In the absence of any linkage in the PVP to the > E164 numbering authorities and or databases any assertion about verification > and validation of a E.164 is in essence self validation. The charter does > NOT state that. My point is the proposed charter is badly written and > implies a trust model that does not exist. >=20 > You make a phone call if it answers and you hopefully get a caller ID that > hasn't been spoofed then maybe you are OK and maybe you hope the TTL is set > to some interval that doesn't cause number hijacking. But gee what happens > when the number is disconnected from the PSTN? Hummmm >=20 > The use of the term validation and or verification here implies > authentication and my assertion is that any authentication of the > responsible domain for a E.164 number outside of the PSTN service provider > or national numbering authority is not possible under the current regulatory > circumstances. Consequently the charter implies an ability to develop a > solution which we all know is impossible.=20 Perhaps better terms can be found and used. But the end effect is that the destination you reach using ViPR has the=20 same assuredness of being who you thought it would be as an actual PSTN=20 call has. For the most part, that is a level of assurance that many people are=20 comfortable with, even if we know that is not as reliable as most people think it is. And regardless of whether it is as good as people would=20 like, it is as good as can be had in most cases with the current state=20 of the art. Thanks, Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Tue Jul 6 10:47:49 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FDC93A688A for ; Tue, 6 Jul 2010 10:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y-OViG4s1ZC for ; Tue, 6 Jul 2010 10:47:48 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E18603A683E for ; Tue, 6 Jul 2010 10:47:47 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC8JM0xAZnwM/2dsb2JhbACgAnGnQZpThSUEiDo X-IronPort-AV: E=Sophos;i="4.53,547,1272844800"; d="scan'208";a="129323361" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 06 Jul 2010 17:47:50 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o66Hlntm004559; Tue, 6 Jul 2010 17:47:50 GMT Message-ID: <4C336C46.4040105@cisco.com> Date: Tue, 06 Jul 2010 13:47:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "PFAUTZ, PENN L (ATTCORP)" References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com><008d01cb1c72$9bdb96a0$d392c3e0$@us> <4C3366B0.8080005@cisco.com> <35FE871E2B085542A35726420E29DA6B044A9168@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B044A9168@gaalpa1msgusr7a.ugd.att.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 17:47:49 -0000 PFAUTZ, PENN L (ATTCORP) wrote: > Paul: > I'm not sure I agree with the statement > > "But the end effect is that the destination you reach using ViPR has the > > same assuredness of being who you thought it would be as an actual PSTN > call has." > > If call traverses mulitple networks on a particular PSTN routing > couldn't any of those assert responsibility for the number? In that case, couldn't any of those networks have *answered* the call? For PSTN calls you have to trust the intermediate PSTN network elements. If they lie then you are screwed. If those same elements lie by connecting your call to a bogus ViPR server then you are equally screwed. Thanks, Paul > Thanks, > > Penn Pfautz > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Tuesday, July 06, 2010 1:24 PM > To: Richard Shockey > Cc: 'DISPATCH'; 'IETF-Discussion list' > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > > > Richard Shockey wrote: >> Paul of course I've read them, though the PVP document is uniquely > dense and >> gave me a headache. Security by ID Obscurity. >> >> My assertion still stands. In the absence of any linkage in the PVP to > the >> E164 numbering authorities and or databases any assertion about > verification >> and validation of a E.164 is in essence self validation. The charter > does >> NOT state that. My point is the proposed charter is badly written and >> implies a trust model that does not exist. >> >> You make a phone call if it answers and you hopefully get a caller ID > that >> hasn't been spoofed then maybe you are OK and maybe you hope the TTL > is set >> to some interval that doesn't cause number hijacking. But gee what > happens >> when the number is disconnected from the PSTN? Hummmm >> >> The use of the term validation and or verification here implies >> authentication and my assertion is that any authentication of the >> responsible domain for a E.164 number outside of the PSTN service > provider >> or national numbering authority is not possible under the current > regulatory >> circumstances. Consequently the charter implies an ability to develop > a >> solution which we all know is impossible. > > Perhaps better terms can be found and used. > > But the end effect is that the destination you reach using ViPR has the > same assuredness of being who you thought it would be as an actual PSTN > call has. > > For the most part, that is a level of assurance that many people are > comfortable with, even if we know that is not as reliable as most people > > think it is. And regardless of whether it is as good as people would > like, it is as good as can be had in most cases with the current state > of the art. > > 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 > From gao.yang2@zte.com.cn Tue Jul 6 22:47:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF4C73A6407 for ; Tue, 6 Jul 2010 22:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 122tYw0Ykep8 for ; Tue, 6 Jul 2010 22:47:43 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 058EF3A659B for ; Tue, 6 Jul 2010 22:47:41 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 38343992332426; Wed, 7 Jul 2010 13:47:10 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 83990.2776214488; Wed, 7 Jul 2010 13:47:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o675lJDh086065; Wed, 7 Jul 2010 13:47:20 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <430FC6BDED356B4C8498F634416644A91FE874DCB1@mail> To: Hadriel Kaplan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 7 Jul 2010 13:43:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-07 13:47:12, Serialize complete at 2010-07-07 13:47:12 Content-Type: multipart/alternative; boundary="=_alternative 001FB7D948257759_=" X-MAIL: mse2.zte.com.cn o675lJDh086065 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] About Final Charter for Session-ID: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 05:47:44 -0000 This is a multipart message in MIME format. --=_alternative 001FB7D948257759_= Content-Type: text/plain; charset="US-ASCII" Hi Hadriel, > Right, my intention was to NOT impact/affect/include dialog- > matching, or anything but troubleshooting. This is my understanding of the charter and the text. Then, I am right at this point. > But of course a charter > and WG is a consensus-based decision, not mine, so if others feel > they want more they can argue for it. Quit true. And I will seek time to make a more detailed discussion for this topic. And I hope people who care about "replace header's dialog-matching problem" join in this discussion then. Gao > -hadriel > > > > From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn] > Sent: Tuesday, June 29, 2010 9:08 PM > To: dispatch@ietf.org > Cc: Hadriel Kaplan > Subject: About Final Charter for Session-ID: > > > Hi, > > By the charter and the original text named draft-kaplan-sip-session- > id-02, this work is just focused on troubleshooting usage. > > But I was told that *someone* want to use this session-id in Replace > header usage, to do dialog-matching. I think this would be UPDATE of RFC3891. > > So, I'd like to confirm that this charter and coming draft would not > do such thing normatively. > > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please > notify the originator of the message. Any views expressed in this > message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 001FB7D948257759_= Content-Type: text/html; charset="US-ASCII"
Hi Hadriel,

> Right, my intention was to NOT impact/affect/include dialog-
> matching, or anything but troubleshooting.  

This is my understanding of the charter and the text. Then, I am right at this point.

> But of course a charter
> and WG is a consensus-based decision, not mine, so if others feel
> they want more they can argue for it.

Quit true. And I will seek time to make a more detailed discussion for this topic. And I hope people who care about "replace header's dialog-matching problem" join in this discussion then.

Gao

> -hadriel
>  
>  
>
> From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
> Sent: Tuesday, June 29, 2010 9:08 PM
> To: dispatch@ietf.org
> Cc: Hadriel Kaplan
> Subject: About Final Charter for Session-ID:
>  
>
> Hi,
>
> By the charter and the original text named draft-kaplan-sip-session-
> id-02, this work is just focused on troubleshooting usage.
>
> But I was told that *someone* want to use this session-id in Replace
> header usage, to do dialog-matching. I think this would be UPDATE of RFC3891.
>
> So, I'd like to confirm that this charter and coming draft would not
> do such thing normatively.
>
> Thanks,
>
> Gao
>
> ===================================
> Zip    : 210012
> Tel    : 87211
> Tel2   :(+86)-025-52877211
> e_mail : gao.yang2@zte.com.cn
> ===================================
>  
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated
> to maintain secrecy and are not permitted to disclose the contents
> of this communication to others.
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please
> notify the originator of the message. Any views expressed in this
> message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 001FB7D948257759_=-- From HKaplan@acmepacket.com Wed Jul 7 03:04:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55D623A68B0 for ; Wed, 7 Jul 2010 03:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4CLpg6-8QLp for ; Wed, 7 Jul 2010 03:04:06 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9CB893A67CC for ; Wed, 7 Jul 2010 03:04:05 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 7 Jul 2010 06:04:08 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 7 Jul 2010 06:04:07 -0400 From: Hadriel Kaplan To: "gao.yang2@zte.com.cn" Date: Wed, 7 Jul 2010 06:03:36 -0400 Thread-Topic: [dispatch] About Final Charter for Session-ID: Thread-Index: Acsdl+/AhWlcPHQTQg2N4zYo4T9ttQAI3uEA Message-ID: <430FC6BDED356B4C8498F634416644A91FE874DF8B@mail> References: <430FC6BDED356B4C8498F634416644A91FE874DCB1@mail> In-Reply-To: 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_430FC6BDED356B4C8498F634416644A91FE874DF8Bmail_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] About Final Charter for Session-ID: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 10:04:07 -0000 --_000_430FC6BDED356B4C8498F634416644A91FE874DF8Bmail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Gao, Have you taken a look at the email thread about session-id and dialog-match= ing, starting at the following email message?: http://www.ietf.org/mail-archive/web/dispatch/current/msg01658.html I think a replaces usage would have the same issues. -hadriel ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of gao.yang2@zte.com.cn Sent: Wednesday, July 07, 2010 1:44 AM To: Hadriel Kaplan Cc: dispatch@ietf.org Subject: Re: [dispatch] About Final Charter for Session-ID: Hi Hadriel, > Right, my intention was to NOT impact/affect/include dialog- > matching, or anything but troubleshooting. This is my understanding of the charter and the text. Then, I am right at t= his point. > But of course a charter > and WG is a consensus-based decision, not mine, so if others feel > they want more they can argue for it. Quit true. And I will seek time to make a more detailed discussion for this= topic. And I hope people who care about "replace header's dialog-matching = problem" join in this discussion then. Gao > -hadriel > > > > From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn] > Sent: Tuesday, June 29, 2010 9:08 PM > To: dispatch@ietf.org > Cc: Hadriel Kaplan > Subject: About Final Charter for Session-ID: > > > Hi, > > By the charter and the original text named draft-kaplan-sip-session- > id-02, this work is just focused on troubleshooting usage. > > But I was told that *someone* want to use this session-id in Replace > header usage, to do dialog-matching. I think this would be UPDATE of RFC3= 891. > > So, I'd like to confirm that this charter and coming draft would not > do such thing normatively. > > Thanks, > > Gao > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated > to maintain secrecy and are not permitted to disclose the contents > of this communication to others. > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please > notify the originator of the message. Any views expressed in this > message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_430FC6BDED356B4C8498F634416644A91FE874DF8Bmail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Gao,

Have you taken a look at the email thr= ead about session-id and dialog-matching, starting at the following email messa= ge?:

http://www.ietf.org/mail-archive/web/dispatch/current/msg01658.html

I think a replaces usage would have th= e same issues.

 

-hadriel

 

 

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of gao.yang2@zte.com.cn
Sent: Wednesday, July 07, 20= 10 1:44 AM
To: Hadriel Kaplan
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Abou= t Final Charter for Session-ID:

 


Hi Hadriel,

> Right, my intention was to NOT impact/affect/include dialog-
> matching, or anything but troubleshooti= ng.  

Th= is is my understanding of the charter and the text. Then, I am right at this point.<= /span>

&g= t; But of course a charter
> and WG is a consensus-based decision, n= ot mine, so if others feel
> they want more they can argue for it.

Qu= it true. And I will seek time to make a more detailed discussion for this topic. And= I hope people who care about "replace header's dialog-matching problem&q= uot; join in this discussion then.

Ga= o

&g= t; -hadriel
&g= t;  
&g= t;  
&g= t;
> From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
> Sent: Tuesday, June 29, 2010 9:08 PM
> To: dispatc= h@ietf.org
> Cc: Hadriel= Kaplan
> Subject: About Final Charter for Sessio= n-ID:
&g= t;  
&g= t;
> Hi,
>
> By the charter and the original text na= med draft-kaplan-sip-session-
> id-02, this work is just focused on troubleshooting usage.
>
> But I was told that *someone* want to u= se this session-id in Replace
> header usage, to do dialog-matching. I = think this would be UPDATE of RFC3891.
>
> So, I'd like to confirm that this chart= er and coming draft would not
> do such thing normatively. =
>
> Thanks,
>
> Gao
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Zip    : 210012 > Tel    : 87211 > Tel2   :(+86)-025-52877211<= /tt>
> e_mail : gao.yang2@zte.com.cn
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
&g= t;  
&g= t; --------------------------------------------------------=
&g= t; ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail
> communication is confidential. Recipien= ts named above are obligated
> to maintain secrecy and are not permitt= ed to disclose the contents
> of this communication to others.=
&g= t; This email and any files transmitted with it are confidential and =
> intended solely for the use of the indi= vidual or entity to whom they
> are addressed. If you have received thi= s email in error please
> notify the originator of the message. A= ny views expressed in this
> message are those of the individual sen= der.
&g= t; This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

<=
o:p> 
------------=
--------------------------------------------
= 
ZTE Inf=
ormation Security Notice: The information containe=
d in this mail is solely property of&nbs=
p;the sender's organization. This mail communicati=
on is confidential. Recipients named above ar=
e obligated to maintain secrecy and are =
not permitted to disclose the contents of&nbs=
p;this communication to others.
This em=
ail and any files transmitted with it ar=
e confidential and intended solely for the&nb=
sp;use of the individual or entity to wh=
om they are addressed. If you have recei=
ved this email in error please notify th=
e originator of the message. Any views e=
xpressed in this message are those of th=
e individual sender.
This me=
ssage has been scanned for viruses and S=
pam by ZTE Anti-Spam system.
--_000_430FC6BDED356B4C8498F634416644A91FE874DF8Bmail_-- From gao.yang2@zte.com.cn Wed Jul 7 03:52:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E3583A659C for ; Wed, 7 Jul 2010 03:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.206 X-Spam-Level: X-Spam-Status: No, score=-94.206 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, J_CHICKENPOX_91=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5hYJ2T1rmef for ; Wed, 7 Jul 2010 03:52:39 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 34D773A67EA for ; Wed, 7 Jul 2010 03:52:37 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 55234992332426; Wed, 7 Jul 2010 18:51:14 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 83990.2776214488; Wed, 7 Jul 2010 18:52:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o67Ah4oV039656; Wed, 7 Jul 2010 18:43:13 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <430FC6BDED356B4C8498F634416644A91FE874DF8B@mail> To: Hadriel Kaplan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 7 Jul 2010 18:39:27 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-07 18:42:59, Serialize complete at 2010-07-07 18:42:59 Content-Type: multipart/alternative; boundary="=_alternative 003ACC5C48257759_=" X-MAIL: mse2.zte.com.cn o67Ah4oV039656 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] About Final Charter for Session-ID: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 10:52:43 -0000 This is a multipart message in MIME format. --=_alternative 003ACC5C48257759_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgSGFkcmllbCwNCg0KSSBtZXQgdGhlIHNhbWUgcHJvYmxlbSBhcyB5b3Ugc2hvd2VkIGluIHlv dXIgbWFpbChyZWxhdGluZyAzR1BQJ3MgDQpjb25mZXJlbmNlIHNlcnZpY2UpIGluIG91ciByZWFs IElNUyBkZXBsb3ltZW50LiBUaGUgb3JpZ2luYWwgYW5kIGRpcmVjdGx5IA0KaWRlYSBmb3IgbWUg aXMgdGhlIHNhbWUgYXMgdGhlIHByb3Nwb3NhbCBzaG93ZWQgaW4geW91ciBtYWlsLCB0byBpbnZl bnQgYSANCm5ldyBoZWFkZXIgdG8gZG8gZGlhbG9nLW1hdGNoaW5nIGJleW9uZCBCMkJVQSBlcXVp cG1lbnQoSSBldmVuIGhhdmUgYSANCnBhdGVudCBmb3IgYSBuZXcgaGVhZGVyIHRvIGRvIGRpYWxv Zy1tYXRjaGluZykuDQoNCkJ1dCB3aHkgbm93IEkgcmVqZWN0IHRoZSB3YXk/IFRoZXJlIGFyZSB0 d28gbWFpbiByZWFzb25zIGhlcmU6DQoNCjEuIFRoaXMgd29yayBpcyBVUERBVEUgUkZDMzg5MShh cyBJIHNhaWQgYmVmb3JlKS4gQW5kIGV2ZW4gd2UgbWFrZSB0aGlzIA0KKnBvdGVudGlhbCBVUERB VEUgUkZDMzg5MSBEcmFmdC9SRkMqLCBob3cgbWF5IFVBcyB3b3VsZCBzdXBwb3J0IGl0LCBhbmQg SSANCnRoaW5rIHRoZXJlIHN0aWxsIHdvdWxkIGJlIGEgc2VyaW91cyBpbnRlcndvcmtpbmcgaXNz dWUuDQoNCjIuIFBoaWxvc29waHkgYW5kIG1ldGhvZG9sb2d5Og0KQXMgd2Uga25vdywgYmFzaWMg U0lQIFJGQ3Moc3RhbmRhcmQgdHJhY2spIG9ubHkgZGVmaW5lIHJ1bGVzIGFib3V0IFVBQy9VQVMg DQphbmQgcHJveHkuIFRoZXJlJ3Mgbm8gbm9ybWF0aXZlIGRlZmluaXRpb24gYWJvdXQgQjJCVUEo UkZDMzcyNSBpcyBCQ1AgDQpsZXZlbCkuIEluIGZhY3QsIEIyQlVBIGlzIGltcGxlbWVudGF0aW9u IGxldmVsIHVzYWdlIG9mIHN0YW5kYXJkIHRyYWNrIFNJUCANClJGQ3MuDQpTbywgSSBkb24ndCB0 aGluayBpdCBpcyBhcHByb3ByaWF0ZSB0byB1c2UgQjJCVUEncyBpbXBsZW1lbnRhdGlvbiBsZXZl bCANCnByb2JsZW0gYXMgcmVhc29uIGZvciBkZW1hbmRpbmcgc3RhbmRhcmQgdHJhY2sgU0lQIFJG QydzIGNvcnJlY3Rpb24uDQoNClRoYW5rcywNCg0KR2FvDQoNCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDogODcyMTENCiBUZWwy ICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KSGFkcmllbCBLYXBsYW4g PEhLYXBsYW5AYWNtZXBhY2tldC5jb20+IA0KMjAxMC0wNy0wNyAxODowMw0KDQrK1bz+yMsNCiJn YW8ueWFuZzJAenRlLmNvbS5jbiIgPGdhby55YW5nMkB6dGUuY29tLmNuPg0Ks63LzQ0KImRpc3Bh dGNoQGlldGYub3JnIiA8ZGlzcGF0Y2hAaWV0Zi5vcmc+DQrW98ziDQpSRTogW2Rpc3BhdGNoXSBB Ym91dCBGaW5hbCBDaGFydGVyIGZvciBTZXNzaW9uLUlEOg0KDQoNCg0KDQoNCg0KR2FvLA0KSGF2 ZSB5b3UgdGFrZW4gYSBsb29rIGF0IHRoZSBlbWFpbCB0aHJlYWQgYWJvdXQgc2Vzc2lvbi1pZCBh bmQgDQpkaWFsb2ctbWF0Y2hpbmcsIHN0YXJ0aW5nIGF0IHRoZSBmb2xsb3dpbmcgZW1haWwgbWVz c2FnZT86DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZGlzcGF0Y2gvY3Vy cmVudC9tc2cwMTY1OC5odG1sDQpJIHRoaW5rIGEgcmVwbGFjZXMgdXNhZ2Ugd291bGQgaGF2ZSB0 aGUgc2FtZSBpc3N1ZXMuDQogDQotaGFkcmllbA0KIA0KIA0KDQpGcm9tOiBkaXNwYXRjaC1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gT24gDQpCZWhh bGYgT2YgZ2FvLnlhbmcyQHp0ZS5jb20uY24NClNlbnQ6IFdlZG5lc2RheSwgSnVseSAwNywgMjAx MCAxOjQ0IEFNDQpUbzogSGFkcmllbCBLYXBsYW4NCkNjOiBkaXNwYXRjaEBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtkaXNwYXRjaF0gQWJvdXQgRmluYWwgQ2hhcnRlciBmb3IgU2Vzc2lvbi1JRDoN CiANCg0KSGkgSGFkcmllbCwgDQoNCj4gUmlnaHQsIG15IGludGVudGlvbiB3YXMgdG8gTk9UIGlt cGFjdC9hZmZlY3QvaW5jbHVkZSBkaWFsb2ctDQo+IG1hdGNoaW5nLCBvciBhbnl0aGluZyBidXQg dHJvdWJsZXNob290aW5nLiAgIA0KDQpUaGlzIGlzIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGNo YXJ0ZXIgYW5kIHRoZSB0ZXh0LiBUaGVuLCBJIGFtIHJpZ2h0IGF0IA0KdGhpcyBwb2ludC4gDQoN Cj4gQnV0IG9mIGNvdXJzZSBhIGNoYXJ0ZXIgDQo+IGFuZCBXRyBpcyBhIGNvbnNlbnN1cy1iYXNl ZCBkZWNpc2lvbiwgbm90IG1pbmUsIHNvIGlmIG90aGVycyBmZWVsIA0KPiB0aGV5IHdhbnQgbW9y ZSB0aGV5IGNhbiBhcmd1ZSBmb3IgaXQuIA0KDQpRdWl0IHRydWUuIEFuZCBJIHdpbGwgc2VlayB0 aW1lIHRvIG1ha2UgYSBtb3JlIGRldGFpbGVkIGRpc2N1c3Npb24gZm9yIA0KdGhpcyB0b3BpYy4g QW5kIEkgaG9wZSBwZW9wbGUgd2hvIGNhcmUgYWJvdXQgInJlcGxhY2UgaGVhZGVyJ3MgDQpkaWFs b2ctbWF0Y2hpbmcgcHJvYmxlbSIgam9pbiBpbiB0aGlzIGRpc2N1c3Npb24gdGhlbi4gDQoNCkdh byANCg0KPiAtaGFkcmllbCANCj4gICANCj4gICANCj4gDQo+IEZyb206IGdhby55YW5nMkB6dGUu Y29tLmNuIFttYWlsdG86Z2FvLnlhbmcyQHp0ZS5jb20uY25dIA0KPiBTZW50OiBUdWVzZGF5LCBK dW5lIDI5LCAyMDEwIDk6MDggUE0NCj4gVG86IGRpc3BhdGNoQGlldGYub3JnDQo+IENjOiBIYWRy aWVsIEthcGxhbg0KPiBTdWJqZWN0OiBBYm91dCBGaW5hbCBDaGFydGVyIGZvciBTZXNzaW9uLUlE OiANCj4gICANCj4gDQo+IEhpLCANCj4gDQo+IEJ5IHRoZSBjaGFydGVyIGFuZCB0aGUgb3JpZ2lu YWwgdGV4dCBuYW1lZCBkcmFmdC1rYXBsYW4tc2lwLXNlc3Npb24tDQo+IGlkLTAyLCB0aGlzIHdv cmsgaXMganVzdCBmb2N1c2VkIG9uIHRyb3VibGVzaG9vdGluZyB1c2FnZS4gDQo+IA0KPiBCdXQg SSB3YXMgdG9sZCB0aGF0ICpzb21lb25lKiB3YW50IHRvIHVzZSB0aGlzIHNlc3Npb24taWQgaW4g UmVwbGFjZQ0KPiBoZWFkZXIgdXNhZ2UsIHRvIGRvIGRpYWxvZy1tYXRjaGluZy4gSSB0aGluayB0 aGlzIHdvdWxkIGJlIFVQREFURSBvZiANClJGQzM4OTEuDQo+IA0KPiBTbywgSSdkIGxpa2UgdG8g Y29uZmlybSB0aGF0IHRoaXMgY2hhcnRlciBhbmQgY29taW5nIGRyYWZ0IHdvdWxkIG5vdA0KPiBk byBzdWNoIHRoaW5nIG5vcm1hdGl2ZWx5LiANCj4gDQo+IFRoYW5rcywgDQo+IA0KPiBHYW8gDQo+ IA0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiBaaXAgICAgOiAyMTAw MTINCj4gVGVsICAgIDogODcyMTENCj4gVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCj4gZV9t YWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0gDQo+ICAgDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tIA0KPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgDQo+IG1haWwgaXMgc29sZWx5IHByb3Bl cnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCANCj4gY29tbXVuaWNh dGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCANCj4gdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xv c2UgdGhlIGNvbnRlbnRzIA0KPiBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLiANCj4g VGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVu dGlhbCBhbmQgDQo+IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5DQo+IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIA0KPiBub3RpZnkgdGhlIG9yaWdpbmF0 b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyANCj4gbWVzc2Fn ZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLiANCj4gVGhpcyBtZXNzYWdlIGhh cyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSANCnN5 c3RlbS4NCiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyANCnNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2Vu ZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyANCmNvbmZpZGVu dGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNl Y3JlY3kgYW5kIA0KYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9m IHRoaXMgY29tbXVuaWNhdGlvbiB0byANCm90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxl cyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIA0Kc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkg YXJlIGFkZHJlc3NlZC4gDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9y IHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdz IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSANCmluZGl2aWR1YWwg c2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNw YW0gYnkgWlRFIEFudGktU3BhbSANCnN5c3RlbS4NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBz b2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNv bW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBv YmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlz Y2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlz IGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFs IGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50 aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3Nh Z2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUg aW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Igdmly dXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 003ACC5C48257759_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEhhZHJpZWwsPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIG1ldCB0aGUgc2FtZSBw cm9ibGVtIGFzIHlvdSBzaG93ZWQNCmluIHlvdXIgbWFpbChyZWxhdGluZyAzR1BQJ3MgY29uZmVy ZW5jZSBzZXJ2aWNlKSBpbiBvdXIgcmVhbCBJTVMgZGVwbG95bWVudC4NClRoZSBvcmlnaW5hbCBh bmQgZGlyZWN0bHkgaWRlYSBmb3IgbWUgaXMgdGhlIHNhbWUgYXMgdGhlIHByb3Nwb3NhbCBzaG93 ZWQNCmluIHlvdXIgbWFpbCwgdG8gaW52ZW50IGEgbmV3IGhlYWRlciB0byBkbyBkaWFsb2ctbWF0 Y2hpbmcgYmV5b25kIEIyQlVBDQplcXVpcG1lbnQoSSBldmVuIGhhdmUgYSBwYXRlbnQgZm9yIGEg bmV3IGhlYWRlciB0byBkbyBkaWFsb2ctbWF0Y2hpbmcpLjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QnV0IHdoeSBub3cgSSByZWplY3QgdGhlIHdheT8g VGhlcmUNCmFyZSB0d28gbWFpbiByZWFzb25zIGhlcmU6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4xLiBUaGlzIHdvcmsgaXMgVVBEQVRFIFJGQzM4OTEo YXMgSQ0Kc2FpZCBiZWZvcmUpLiBBbmQgZXZlbiB3ZSBtYWtlIHRoaXMgKnBvdGVudGlhbCBVUERB VEUgUkZDMzg5MSBEcmFmdC9SRkMqLA0KaG93IG1heSBVQXMgd291bGQgc3VwcG9ydCBpdCwgYW5k IEkgdGhpbmsgdGhlcmUgc3RpbGwgd291bGQgYmUgYSBzZXJpb3VzDQppbnRlcndvcmtpbmcgaXNz dWUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4yLiBQ aGlsb3NvcGh5IGFuZCBtZXRob2RvbG9neTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkFzIHdlIGtub3csIGJhc2ljIFNJUCBSRkNzKHN0YW5kYXJkDQp0cmFjaykg b25seSBkZWZpbmUgcnVsZXMgYWJvdXQgVUFDL1VBUyBhbmQgcHJveHkuIFRoZXJlJ3Mgbm8gbm9y bWF0aXZlDQpkZWZpbml0aW9uIGFib3V0IEIyQlVBKFJGQzM3MjUgaXMgQkNQIGxldmVsKS4gSW4g ZmFjdCwgQjJCVUEgaXMgaW1wbGVtZW50YXRpb24NCmxldmVsIHVzYWdlIG9mIHN0YW5kYXJkIHRy YWNrIFNJUCBSRkNzLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ U28sIEkgZG9uJ3QgdGhpbmsgaXQgaXMgYXBwcm9wcmlhdGUNCnRvIHVzZSBCMkJVQSdzIGltcGxl bWVudGF0aW9uIGxldmVsIHByb2JsZW0gYXMgcmVhc29uIGZvciBkZW1hbmRpbmcgc3RhbmRhcmQN CnRyYWNrIFNJUCBSRkMncyBjb3JyZWN0aW9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4N CiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIx MTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdh by55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+ SGFkcmllbCBLYXBsYW4gJmx0O0hLYXBsYW5AYWNtZXBhY2tldC5jb20mZ3Q7PC9iPg0KPC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDctMDcgMTg6MDM8L2Zv bnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrV vP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1 b3Q7Z2FvLnlhbmcyQHp0ZS5jb20uY24mcXVvdDsgJmx0O2dhby55YW5nMkB6dGUuY29tLmNuJmd0 OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXpl PTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7ZGlzcGF0Y2hAaWV0Zi5vcmcmcXVvdDsgJmx0O2Rp c3BhdGNoQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFtkaXNwYXRjaF0gQWJv dXQgRmluYWwgQ2hhcnRlciBmb3INClNlc3Npb24tSUQ6PC9mb250PjwvdGFibGU+DQo8YnI+DQo8 dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+ DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwi Pkdhbyw8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwi PkhhdmUgeW91IHRha2VuIGEgbG9vayBhdCB0aGUNCmVtYWlsIHRocmVhZCBhYm91dCBzZXNzaW9u LWlkIGFuZCBkaWFsb2ctbWF0Y2hpbmcsIHN0YXJ0aW5nIGF0IHRoZSBmb2xsb3dpbmcNCmVtYWls IG1lc3NhZ2U/OjwvZm9udD4NCjxicj48YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvZGlzcGF0Y2gvY3VycmVudC9tc2cwMTY1OC5odG1sIj48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZSBmYWNlPSJBcmlhbCI+PHU+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL2Rpc3BhdGNoL2N1cnJlbnQvbXNnMDE2NTguaHRtbDwvdT48L2ZvbnQ+PC9hPg0KPGJy Pjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj5JIHRoaW5rIGEgcmVwbGFj ZXMgdXNhZ2Ugd291bGQNCmhhdmUgdGhlIHNhbWUgaXNzdWVzLjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj4taGFkcmllbDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJBcmlhbCI+Jm5ic3A7PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+DQo8 ZGl2IGFsaWduPWNlbnRlcj4NCjxicj4NCjxocj48L2Rpdj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iVGFob21hIj48Yj5Gcm9tOjwvYj4gZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPmdhby55YW5n MkB6dGUuY29tLmNuPGI+PGJyPg0KU2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAwNywgMjAxMCAx OjQ0IEFNPGI+PGJyPg0KVG86PC9iPiBIYWRyaWVsIEthcGxhbjxiPjxicj4NCkNjOjwvYj4gZGlz cGF0Y2hAaWV0Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtkaXNwYXRjaF0gQWJvdXQg RmluYWwgQ2hhcnRlciBmb3IgU2Vzc2lvbi1JRDo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+PGJyPg0KSGkgSGFkcmllbCw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci Pjxicj4NCjxicj4NCiZndDsgUmlnaHQsIG15IGludGVudGlvbiB3YXMgdG8gTk9UIGltcGFjdC9h ZmZlY3QvaW5jbHVkZSBkaWFsb2ctPGJyPg0KJmd0OyBtYXRjaGluZywgb3IgYW55dGhpbmcgYnV0 IHRyb3VibGVzaG9vdGluZy4gJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ PGJyPg0KVGhpcyBpcyBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBjaGFydGVyIGFuZCB0aGUgdGV4 dC4gVGhlbiwgSSBhbSByaWdodA0KYXQgdGhpcyBwb2ludC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxicj4NCiZndDsgQnV0IG9mIGNvdXJzZSBhIGNoYXJ0ZXIgPGJyPg0KJmd0OyBh bmQgV0cgaXMgYSBjb25zZW5zdXMtYmFzZWQgZGVjaXNpb24sIG5vdCBtaW5lLCBzbyBpZiBvdGhl cnMgZmVlbA0KPGJyPg0KJmd0OyB0aGV5IHdhbnQgbW9yZSB0aGV5IGNhbiBhcmd1ZSBmb3IgaXQu PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPGJyPg0KPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KUXVpdCB0cnVlLiBBbmQgSSB3 aWxsIHNlZWsgdGltZSB0byBtYWtlIGEgbW9yZSBkZXRhaWxlZCBkaXNjdXNzaW9uIGZvcg0KdGhp cyB0b3BpYy4gQW5kIEkgaG9wZSBwZW9wbGUgd2hvIGNhcmUgYWJvdXQgJnF1b3Q7cmVwbGFjZSBo ZWFkZXIncyBkaWFsb2ctbWF0Y2hpbmcNCnByb2JsZW0mcXVvdDsgam9pbiBpbiB0aGlzIGRpc2N1 c3Npb24gdGhlbi48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpHYW88L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDxicj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgLWhhZHJpZWw8L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij48YnI+DQomZ3Q7ICZuYnNwOzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IEZyb206IGdhby55YW5nMkB6dGUuY29tLmNuIFttYWlsdG86Z2FvLnlhbmcyQHp0 ZS5jb20uY25dIDxicj4NCiZndDsgU2VudDogVHVlc2RheSwgSnVuZSAyOSwgMjAxMCA5OjA4IFBN PGJyPg0KJmd0OyBUbzogZGlzcGF0Y2hAaWV0Zi5vcmc8YnI+DQomZ3Q7IENjOiBIYWRyaWVsIEth cGxhbjxicj4NCiZndDsgU3ViamVjdDogQWJvdXQgRmluYWwgQ2hhcnRlciBmb3IgU2Vzc2lvbi1J RDo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQomZ3Q7ICZuYnNwOzwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhpLCA8YnI+DQomZ3Q7IDxicj4N CiZndDsgQnkgdGhlIGNoYXJ0ZXIgYW5kIHRoZSBvcmlnaW5hbCB0ZXh0IG5hbWVkIGRyYWZ0LWth cGxhbi1zaXAtc2Vzc2lvbi08YnI+DQomZ3Q7IGlkLTAyLCB0aGlzIHdvcmsgaXMganVzdCBmb2N1 c2VkIG9uIHRyb3VibGVzaG9vdGluZyB1c2FnZS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEJ1dCBJ IHdhcyB0b2xkIHRoYXQgKnNvbWVvbmUqIHdhbnQgdG8gdXNlIHRoaXMgc2Vzc2lvbi1pZCBpbiBS ZXBsYWNlPGJyPg0KJmd0OyBoZWFkZXIgdXNhZ2UsIHRvIGRvIGRpYWxvZy1tYXRjaGluZy4gSSB0 aGluayB0aGlzIHdvdWxkIGJlIFVQREFURQ0Kb2YgUkZDMzg5MS48YnI+DQomZ3Q7IDxicj4NCiZn dDsgU28sIEknZCBsaWtlIHRvIGNvbmZpcm0gdGhhdCB0aGlzIGNoYXJ0ZXIgYW5kIGNvbWluZyBk cmFmdCB3b3VsZCBub3Q8YnI+DQomZ3Q7IGRvIHN1Y2ggdGhpbmcgbm9ybWF0aXZlbHkuIDxicj4N CiZndDsgPGJyPg0KJmd0OyBUaGFua3MsIDxicj4NCiZndDsgPGJyPg0KJmd0OyBHYW8gPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0K Jmd0OyBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KJmd0OyBUZWwgJm5ic3A7ICZuYnNw OzogODcyMTE8YnI+DQomZ3Q7IFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQom Z3Q7IGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KJmd0OyA9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZn dDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2Zv bnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQomZ3Q7IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+PGJyPg0KJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNl OiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCjxicj4NCiZndDsgbWFpbCBpcyBz b2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIDxi cj4NCiZndDsgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQg YWJvdmUgYXJlIG9ibGlnYXRlZA0KPGJyPg0KJmd0OyB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBh cmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMNCjxicj4NCiZndDsgb2Yg dGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 YnI+DQomZ3Q7IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFy ZSBjb25maWRlbnRpYWwgYW5kDQo8YnI+DQomZ3Q7IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVz ZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5PGJyPg0KJmd0OyBhcmUg YWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFz ZSA8YnI+DQomZ3Q7IG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZp ZXdzIGV4cHJlc3NlZCBpbiB0aGlzDQo8YnI+DQomZ3Q7IG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRo ZSBpbmRpdmlkdWFsIHNlbmRlci48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQomZ3Q7 IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpU RSBBbnRpLVNwYW0NCnN5c3RlbS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPlpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZQ0KaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMg bWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4NClRo aXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBh Ym92ZSBhcmUgb2JsaWdhdGVkDQp0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1p dHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcw0KY29tbXVuaWNhdGlvbiB0byBv dGhlcnMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+VGhpcyBl bWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkDQp3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwg YW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbA0Kb3IgZW50 aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluDQplcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkDQppbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRo ZSBpbmRpdmlkdWFsIHNlbmRlci48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJp ZXIgTmV3Ij5UaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcw0KYW5kIFNw YW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uPC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF Jm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJz cDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwm bmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtz ZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7 bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFp bnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0 dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2Ym bmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZu YnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZu YnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNw O2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNw O3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91 Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJz cDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3Im bmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtl eHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhv c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5i c3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7 dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3Bh bSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 003ACC5C48257759_=-- From gao.yang2@zte.com.cn Wed Jul 7 04:16:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48E393A67AB for ; Wed, 7 Jul 2010 04:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.23 X-Spam-Level: X-Spam-Status: No, score=-98.23 tagged_above=-999 required=5 tests=[AWL=-3.608, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-z4dWO8Lvpu for ; Wed, 7 Jul 2010 04:16:04 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 1CC483A65A5 for ; Wed, 7 Jul 2010 04:15:57 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 38343992332426; Wed, 7 Jul 2010 19:15:25 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 83990.2776214488; Wed, 7 Jul 2010 19:15:54 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o67BG4qr092622; Wed, 7 Jul 2010 19:16:04 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <430FC6BDED356B4C8498F634416644A91FE874DF8B@mail> To: Hadriel Kaplan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 7 Jul 2010 19:12:17 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-07 19:15:50, Serialize complete at 2010-07-07 19:15:50 Content-Type: multipart/alternative; boundary="=_alternative 003DCDF148257759_=" X-MAIL: mse2.zte.com.cn o67BG4qr092622 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] About Final Charter for Session-ID: //Solution and experience sharing on the problem X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 11:16:06 -0000 This is a multipart message in MIME format. --=_alternative 003DCDF148257759_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 Rm9yIGFsbCBwZW9wbGUgY2FyZSBhYm91dCB0aGUgUmVwbGFjZSBoZWFkZXIgcHJvYmxlbSwNCg0K QXMgdGhlIHByb2JsZW0gb3JpZ2luIGlzIEIyQlVBIGVxdWlwbWVudCwgdGhlIHNvbHV0aW9uIHNo b3VsZCBiZSBsaW1pdGVkIA0KdG8vYXJvdW5kIGl0c2VsZiwgdG8ga2VlcCB0aGluZ3Mgc2ltcGxl LiBJdCBpcyBub3QgcHJvcGVyIHRvIGFzayBvdGhlciANCippbm5vY2VudCogbmV0d29yayBlbGVt ZW50L2VxdWlwbWVudCB0byBkbyBtb3JlIGZvciBpdC4NCg0KQW5kIHBlb3BsZSB3aG8gZmFtaWxp YXIgd2l0aCAyNC4yMjkga25vdyB0aGF0IHJvdXRpbmcgQjJCVUEgQVMgc2hvdWxkIA0KY2hhbmdl IHRoZSBkaWFsb2cgaW5mb3JtYXRpb24gaW4gdGhlIHJlcGxhY2UgaGVhZGVyIGZyb20gZGlhbG9n MSB0byANCmRpYWxvZzIoZGlhbG9nMS8yIG1lYW5zIGdlbmVyYWwgdHdvIGRpYWxvZyBvbiB0aGUg QjJCVUEncyB0d28gc2lkZXMpLiANCg0KU28sIHdlIGNhbiBleHRlbmQgdGhlIGNoYW5naW5nLWRp YWxvZy1pbmZvcm1hdGlvbiBydWxlIGZyb20gcm91dGluZyBCMkJVQSANCkFTIHRvIG90aGVyIEIy QlVBIGVxdWlwbWVtdCwgc3VjaCBhcyBCR1cvU0JDLg0KDQorLS0tLSsgICAgICArLS0tLS0rICAg ICAgKy0tLS0rICAgICAgKy0tLS0tKyAgICAgICstLS0tKw0KICB8VUEtQXwgICAgICB8QjJCVUF8 ICAgICAgfCBBUyB8ICAgICAgfEIyQlVBfCAgICAgIHxVQS1CfA0KICArLS0tLSsgICAgICArLS0t LS0rICAgICAgKy0tLS0rICAgICAgKy0tLS0tKyAgICAgICstLS0tKw0KICAgIHwgICAgICAgICAg ICB8ICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICAgIHwNCiAgICB8SU5WSVRFICAg ICAgfCAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgICB8DQogICAgfGNhbGxpZDox YSAgIHxjYWxsaWQ6MWIgICB8Y2FsbGlkOjFjICB8Y2FsbGlkOjFkICAgfA0KICAgIHwtLS0tLS0t LS0tLT58LS0tLS0tLS0tLS0+fC0tLS0tLS0tLS0+fC0tLS0tLS0tLS0tPnwNCiAgICB8c2Vzc2lk OjEgICAgfHNlc3NpZDoxICAgIHxzZXNzaWQ6MSAgIHxzZXNzaWQ6MSAgICB8DQogICAgfCAgICAg ICAgICAgIHwgICAgICAgICAgICB8ICAgICAgICAgICB8ICAgICAgICAgICAgfA0KICAgIHxJTlZJ VEUgICAgICB8ICAgICAgICAgICAgfCAgICAgICAgICAgfCAgICAgICAgICAgIHwNCiAgICB8Y2Fs bGlkOjJhICAgfGNhbGxpZDoyYiAgIHwgICAgICAgICAgIHwgICAgICAgICAgICB8DQogICAgfC0t LS0tLS0tLS0tPnwtLS0tLS0tLS0tLT58ICAgICAgICAgICB8ICAgICAgICAgICAgfA0KICAgIHxz ZXNzaWQ6MiAgICB8c2Vzc2lkOjIgICAgfHJlLUlOVklURSAgfCAgICAgICAgICAgIHwNCiAgICB8 Ukw8c2Vzc2lkOjE+fFJMPHNlc3NpZDoxPnxjYWxsaWQ6MWMgIHxjYWxsaWQ6MWQgICB8DQogICAg fCAgICAgICAgICAgIHwgICAgICAgICAgICB8LS0tLS0tLS0tLT58LS0tLS0tLS0tLS0+fA0KICAg IHwgICAgICAgICAgICB8ICAgICAgICAgICAgfHNlc3NpZDoxICAgfHNlc3NpZDoxICAgIHwNCiAg ICB8ICAgICAgICAgICAgfCAgICAgICAgICAgIHwgICAgICAgICAgIHwgICAgICAgICAgICB8DQoN Cg0KRnVydGhlciwgaW4gb3VyIHJlYWwgSU1TIGRlcGxveW1lbnQgdXNlIGNhc2VzLCBJIGZpbmQg dGhlcmUncyBzdGlsbCBvbmUgDQpzcGVjaWFsIHNpdHVhdGlvbiBmb3Igcm91dGluZyBCMkJVQSBB Uy4gQXMgd2Uga25vdywgYWNjZXNzL2VkZ2UgbmV0d29yayANCmVsZW1lbnRzLCBzdWNoIGFzIEJH VywgU0JDIGFyZSBhbHdheXMgaW4gdGhlIGNhbGwgc2lnbmFsbGluZyBwYXRoLCBubyANCm1hdHRl ciBmb3IgY2FsbGlkOmlhIG9yIGNhbGxpZDoyYS4gQnV0IG9uZSByb3V0aW5nIEIyQlVBIEFTIHdv dWxkIGluIHRoZSANCmNhbGwgc2lnbmFsbGluZyBwYXRoIGZvciBjYWxsaWQ6MWEsIHdoaWxlIGFi c2VudCBmb3IgdGhlIGNhbGwgc2lnbmFsbGluZyANCnBhdGggZm9yIGNhbGxpZDoxYi4gT25lIGV4 YW1wbGUgaXM6IHdoZW4gVUEtQSBjYWxsIFVBLUIsIHRoZXJlIHdvdWxkIGJlIA0Kb25lIEFTIGZv ciBVQS1BJ3Mgb3JpZ2luYXRpbmctc3VwcGxlbWVudC1zZXJ2aWNlLiBCdXQgdGhlIEFTIHdvdWxk IG5vdCBiZSANCnRyaWdnZXJlZCB3aGVuIFVBLUEgY2FsbCB0aGUgY29uZmVyZW5jZSBQU0kuDQoN CkZvciB0aGlzIHNwZWNpYWwgc2l0dWF0aW9uLCBteSBzb2x1dGlvbiBpcyB0byBtYWtlIHRoZSBB UyB3b3VsZCBiZSANCnRyaWdnZXJlZCB3aGVuIHRoZSBuZXcgSU5WSVRFKGNhbGxpZDoyYSkgaGFz IGEgcmVwbGFjZSBoZWFkZXIgd2l0aCANCmRpYWxvZy1pbmZvcm1hdGlvbiBhcyBjYWxsaWQ6MWEu IEFuZCB0aGlzIGNvbXBseXMgd2l0aCBjdXJyZW50IGlGQyANCm1lY2hhbmlzbS4gVGhlIG5ldyB0 aGluZyBpcyB0aGUgcm91dGluZyBCMkJVQSBzaG91bGQgbW9kaWZ5IHRoZSBVQS1BJ3MgaUZDIA0K dG8gZ3VhcmFudGVlIGl0IHdvdWxkIGJlIHRyaWdnZXJlZCBpbiB0aGUgbmV3IGNhbGwncyBzaWdu YWxsaW5nIHBhdGgsIGFuZCANCmRvIHRoZSBjaGFuZ2luZyB0aGUgZGlhbG9nIGluZm9ybWF0aW9u IHdvcmsgYXMgZGVmaW5lZCBpbiAyNC4yMjkuDQoNClRoYW5rcywNCg0KR2FvDQoNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDog ODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6 dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KSGFk cmllbCBLYXBsYW4gPEhLYXBsYW5AYWNtZXBhY2tldC5jb20+IA0KMjAxMC0wNy0wNyAxODowMw0K DQrK1bz+yMsNCiJnYW8ueWFuZzJAenRlLmNvbS5jbiIgPGdhby55YW5nMkB6dGUuY29tLmNuPg0K s63LzQ0KImRpc3BhdGNoQGlldGYub3JnIiA8ZGlzcGF0Y2hAaWV0Zi5vcmc+DQrW98ziDQpSRTog W2Rpc3BhdGNoXSBBYm91dCBGaW5hbCBDaGFydGVyIGZvciBTZXNzaW9uLUlEOg0KDQoNCg0KDQoN Cg0KR2FvLA0KSGF2ZSB5b3UgdGFrZW4gYSBsb29rIGF0IHRoZSBlbWFpbCB0aHJlYWQgYWJvdXQg c2Vzc2lvbi1pZCBhbmQgDQpkaWFsb2ctbWF0Y2hpbmcsIHN0YXJ0aW5nIGF0IHRoZSBmb2xsb3dp bmcgZW1haWwgbWVzc2FnZT86DQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv ZGlzcGF0Y2gvY3VycmVudC9tc2cwMTY1OC5odG1sDQpJIHRoaW5rIGEgcmVwbGFjZXMgdXNhZ2Ug d291bGQgaGF2ZSB0aGUgc2FtZSBpc3N1ZXMuDQogDQotaGFkcmllbA0KIA0KIA0KDQpGcm9tOiBk aXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9y Z10gT24gDQpCZWhhbGYgT2YgZ2FvLnlhbmcyQHp0ZS5jb20uY24NClNlbnQ6IFdlZG5lc2RheSwg SnVseSAwNywgMjAxMCAxOjQ0IEFNDQpUbzogSGFkcmllbCBLYXBsYW4NCkNjOiBkaXNwYXRjaEBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gQWJvdXQgRmluYWwgQ2hhcnRlciBmb3Ig U2Vzc2lvbi1JRDoNCiANCg0KSGkgSGFkcmllbCwgDQoNCj4gUmlnaHQsIG15IGludGVudGlvbiB3 YXMgdG8gTk9UIGltcGFjdC9hZmZlY3QvaW5jbHVkZSBkaWFsb2ctDQo+IG1hdGNoaW5nLCBvciBh bnl0aGluZyBidXQgdHJvdWJsZXNob290aW5nLiAgIA0KDQpUaGlzIGlzIG15IHVuZGVyc3RhbmRp bmcgb2YgdGhlIGNoYXJ0ZXIgYW5kIHRoZSB0ZXh0LiBUaGVuLCBJIGFtIHJpZ2h0IGF0IA0KdGhp cyBwb2ludC4gDQoNCj4gQnV0IG9mIGNvdXJzZSBhIGNoYXJ0ZXIgDQo+IGFuZCBXRyBpcyBhIGNv bnNlbnN1cy1iYXNlZCBkZWNpc2lvbiwgbm90IG1pbmUsIHNvIGlmIG90aGVycyBmZWVsIA0KPiB0 aGV5IHdhbnQgbW9yZSB0aGV5IGNhbiBhcmd1ZSBmb3IgaXQuIA0KDQpRdWl0IHRydWUuIEFuZCBJ IHdpbGwgc2VlayB0aW1lIHRvIG1ha2UgYSBtb3JlIGRldGFpbGVkIGRpc2N1c3Npb24gZm9yIA0K dGhpcyB0b3BpYy4gQW5kIEkgaG9wZSBwZW9wbGUgd2hvIGNhcmUgYWJvdXQgInJlcGxhY2UgaGVh ZGVyJ3MgDQpkaWFsb2ctbWF0Y2hpbmcgcHJvYmxlbSIgam9pbiBpbiB0aGlzIGRpc2N1c3Npb24g dGhlbi4gDQoNCkdhbyANCg0KPiAtaGFkcmllbCANCj4gICANCj4gICANCj4gDQo+IEZyb206IGdh by55YW5nMkB6dGUuY29tLmNuIFttYWlsdG86Z2FvLnlhbmcyQHp0ZS5jb20uY25dIA0KPiBTZW50 OiBUdWVzZGF5LCBKdW5lIDI5LCAyMDEwIDk6MDggUE0NCj4gVG86IGRpc3BhdGNoQGlldGYub3Jn DQo+IENjOiBIYWRyaWVsIEthcGxhbg0KPiBTdWJqZWN0OiBBYm91dCBGaW5hbCBDaGFydGVyIGZv ciBTZXNzaW9uLUlEOiANCj4gICANCj4gDQo+IEhpLCANCj4gDQo+IEJ5IHRoZSBjaGFydGVyIGFu ZCB0aGUgb3JpZ2luYWwgdGV4dCBuYW1lZCBkcmFmdC1rYXBsYW4tc2lwLXNlc3Npb24tDQo+IGlk LTAyLCB0aGlzIHdvcmsgaXMganVzdCBmb2N1c2VkIG9uIHRyb3VibGVzaG9vdGluZyB1c2FnZS4g DQo+IA0KPiBCdXQgSSB3YXMgdG9sZCB0aGF0ICpzb21lb25lKiB3YW50IHRvIHVzZSB0aGlzIHNl c3Npb24taWQgaW4gUmVwbGFjZQ0KPiBoZWFkZXIgdXNhZ2UsIHRvIGRvIGRpYWxvZy1tYXRjaGlu Zy4gSSB0aGluayB0aGlzIHdvdWxkIGJlIFVQREFURSBvZiANClJGQzM4OTEuDQo+IA0KPiBTbywg SSdkIGxpa2UgdG8gY29uZmlybSB0aGF0IHRoaXMgY2hhcnRlciBhbmQgY29taW5nIGRyYWZ0IHdv dWxkIG5vdA0KPiBkbyBzdWNoIHRoaW5nIG5vcm1hdGl2ZWx5LiANCj4gDQo+IFRoYW5rcywgDQo+ IA0KPiBHYW8gDQo+IA0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiBa aXAgICAgOiAyMTAwMTINCj4gVGVsICAgIDogODcyMTENCj4gVGVsMiAgIDooKzg2KS0wMjUtNTI4 NzcyMTENCj4gZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj4gPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT0gDQo+ICAgDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJp dHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgDQo+IG1haWwgaXMg c29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCAN Cj4gY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUg YXJlIG9ibGlnYXRlZCANCj4gdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0 ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIA0KPiBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8g b3RoZXJzLiANCj4gVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQg YXJlIGNvbmZpZGVudGlhbCBhbmQgDQo+IGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5DQo+IGFyZSBhZGRyZXNzZWQuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIA0KPiBub3RpZnkg dGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhp cyANCj4gbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLiANCj4gVGhp cyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFu dGktU3BhbSANCnN5c3RlbS4NCiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBU aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyANCnNvbGVseSBwcm9wZXJ0 eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBp cyANCmNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRv IG1haW50YWluIHNlY3JlY3kgYW5kIA0KYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhl IGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byANCm90aGVycy4NClRoaXMgZW1haWwg YW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGlu dGVuZGVkIA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0 byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgDQp0aGUgbWVzc2Fn ZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSAN CmluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZp cnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSANCnN5c3RlbS4NCg0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4g VGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVk IGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJt aXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBv dGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUg Y29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Ig b2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0 aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nh bm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 003DCDF148257759_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZvciBhbGwgcGVvcGxlIGNhcmUg YWJvdXQgdGhlIFJlcGxhY2UNCmhlYWRlciBwcm9ibGVtLDwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXMgdGhlIHByb2JsZW0gb3JpZ2luIGlzIEIyQlVB IGVxdWlwbWVudCwNCnRoZSBzb2x1dGlvbiBzaG91bGQgYmUgbGltaXRlZCB0by9hcm91bmQgaXRz ZWxmLCB0byBrZWVwIHRoaW5ncyBzaW1wbGUuDQpJdCBpcyBub3QgcHJvcGVyIHRvIGFzayBvdGhl ciAqaW5ub2NlbnQqIG5ldHdvcmsgZWxlbWVudC9lcXVpcG1lbnQgdG8gZG8NCm1vcmUgZm9yIGl0 LjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QW5kIHBl b3BsZSB3aG8gZmFtaWxpYXIgd2l0aCAyNC4yMjkNCmtub3cgdGhhdCByb3V0aW5nIEIyQlVBIEFT IHNob3VsZCBjaGFuZ2UgdGhlIGRpYWxvZyBpbmZvcm1hdGlvbiBpbiB0aGUNCnJlcGxhY2UgaGVh ZGVyIGZyb20gZGlhbG9nMSB0byBkaWFsb2cyKGRpYWxvZzEvMiBtZWFucyBnZW5lcmFsIHR3byBk aWFsb2cNCm9uIHRoZSBCMkJVQSdzIHR3byBzaWRlcykuIDwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U28sIHdlIGNhbiBleHRlbmQgdGhlIGNoYW5naW5n LWRpYWxvZy1pbmZvcm1hdGlvbg0KcnVsZSBmcm9tIHJvdXRpbmcgQjJCVUEgQVMgdG8gb3RoZXIg QjJCVUEgZXF1aXBtZW10LCBzdWNoIGFzIEJHVy9TQkMuPC9mb250Pg0KPGJyPg0KPGJyPjx0dD48 Zm9udCBzaXplPTM+Ky0tLS0rICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLS0tKyAmbmJzcDsgJm5i c3A7ICZuYnNwOystLS0tKw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsrLS0tLS0rICZuYnNwOyAmbmJz cDsgJm5ic3A7Ky0tLS0rPGJyPg0KICZuYnNwO3xVQS1BfCAmbmJzcDsgJm5ic3A7ICZuYnNwO3xC MkJVQXwgJm5ic3A7ICZuYnNwOyAmbmJzcDt8IEFTIHwgJm5ic3A7DQombmJzcDsgJm5ic3A7fEIy QlVBfCAmbmJzcDsgJm5ic3A7ICZuYnNwO3xVQS1CfDxicj4NCiAmbmJzcDsrLS0tLSsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsrLS0tLS0rICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLS0rICZuYnNwOw0K Jm5ic3A7ICZuYnNwOystLS0tLSsgJm5ic3A7ICZuYnNwOyAmbmJzcDsrLS0tLSs8YnI+DQogJm5i c3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3w8YnI+DQogJm5ic3A7ICZuYnNwO3xJTlZJVEUgJm5ic3A7ICZuYnNwOyAmbmJzcDt8 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwO3w8YnI+DQogJm5ic3A7ICZuYnNwO3xjYWxsaWQ6MWEgJm5ic3A7IHxjYWxsaWQ6 MWIgJm5ic3A7IHxjYWxsaWQ6MWMgJm5ic3A7fGNhbGxpZDoxZA0KJm5ic3A7IHw8YnI+DQogJm5i c3A7ICZuYnNwO3wtLS0tLS0tLS0tLSZndDt8LS0tLS0tLS0tLS0mZ3Q7fC0tLS0tLS0tLS0mZ3Q7 fC0tLS0tLS0tLS0tJmd0O3w8YnI+DQogJm5ic3A7ICZuYnNwO3xzZXNzaWQ6MSAmbmJzcDsgJm5i c3A7fHNlc3NpZDoxICZuYnNwOyAmbmJzcDt8c2Vzc2lkOjEgJm5ic3A7DQp8c2Vzc2lkOjEgJm5i c3A7ICZuYnNwO3w8YnI+DQogJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+DQogJm5ic3A7ICZuYnNwO3xJTlZJVEUg Jm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZuYnNwOyAmbmJz cDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+DQogJm5ic3A7ICZuYnNwO3xjYWxs aWQ6MmEgJm5ic3A7IHxjYWxsaWQ6MmIgJm5ic3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8 YnI+DQogJm5ic3A7ICZuYnNwO3wtLS0tLS0tLS0tLSZndDt8LS0tLS0tLS0tLS0mZ3Q7fCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyB8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiAmbmJzcDsgJm5ic3A7fHNlc3NpZDoyICZuYnNwOyAm bmJzcDt8c2Vzc2lkOjIgJm5ic3A7ICZuYnNwO3xyZS1JTlZJVEUNCiZuYnNwO3wgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KICZuYnNwOyAmbmJzcDt8Ukwm bHQ7c2Vzc2lkOjEmZ3Q7fFJMJmx0O3Nlc3NpZDoxJmd0O3xjYWxsaWQ6MWMgJm5ic3A7fGNhbGxp ZDoxZA0KJm5ic3A7IHw8YnI+DQogJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3wtLS0tLS0tLS0tJmd0O3wtLS0tLS0tLS0tLSZndDt8PGJyPg0KICZuYnNwOyAmbmJz cDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8c2Vzc2lkOjEgJm5ic3A7IHxzZXNzaWQ6 MSAmbmJzcDsgJm5ic3A7fDxicj4NCiAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJm5ic3A7DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCjwvZm9udD48L3R0Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GdXJ0aGVyLCBpbiBvdXIgcmVh bCBJTVMgZGVwbG95bWVudA0KdXNlIGNhc2VzLCBJIGZpbmQgdGhlcmUncyBzdGlsbCBvbmUgc3Bl Y2lhbCBzaXR1YXRpb24gZm9yIHJvdXRpbmcgQjJCVUENCkFTLiBBcyB3ZSBrbm93LCBhY2Nlc3Mv ZWRnZSBuZXR3b3JrIGVsZW1lbnRzLCBzdWNoIGFzIEJHVywgU0JDIGFyZSBhbHdheXMNCmluIHRo ZSBjYWxsIHNpZ25hbGxpbmcgcGF0aCwgbm8gbWF0dGVyIGZvciBjYWxsaWQ6aWEgb3IgY2FsbGlk OjJhLiBCdXQNCm9uZSByb3V0aW5nIEIyQlVBIEFTIHdvdWxkIGluIHRoZSBjYWxsIHNpZ25hbGxp bmcgcGF0aCBmb3IgY2FsbGlkOjFhLCB3aGlsZQ0KYWJzZW50IGZvciB0aGUgY2FsbCBzaWduYWxs aW5nIHBhdGggZm9yIGNhbGxpZDoxYi4gT25lIGV4YW1wbGUgaXM6IHdoZW4NClVBLUEgY2FsbCBV QS1CLCB0aGVyZSB3b3VsZCBiZSBvbmUgQVMgZm9yIFVBLUEncyBvcmlnaW5hdGluZy1zdXBwbGVt ZW50LXNlcnZpY2UuDQpCdXQgdGhlIEFTIHdvdWxkIG5vdCBiZSB0cmlnZ2VyZWQgd2hlbiBVQS1B IGNhbGwgdGhlIGNvbmZlcmVuY2UgUFNJLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Rm9yIHRoaXMgc3BlY2lhbCBzaXR1YXRpb24sIG15IHNvbHV0aW9u DQppcyB0byBtYWtlIHRoZSBBUyB3b3VsZCBiZSB0cmlnZ2VyZWQgd2hlbiB0aGUgbmV3IElOVklU RShjYWxsaWQ6MmEpIGhhcw0KYSByZXBsYWNlIGhlYWRlciB3aXRoIGRpYWxvZy1pbmZvcm1hdGlv biBhcyBjYWxsaWQ6MWEuIEFuZCB0aGlzIGNvbXBseXMNCndpdGggY3VycmVudCBpRkMgbWVjaGFu aXNtLiBUaGUgbmV3IHRoaW5nIGlzIHRoZSByb3V0aW5nIEIyQlVBIHNob3VsZCBtb2RpZnkNCnRo ZSBVQS1BJ3MgaUZDIHRvIGd1YXJhbnRlZSBpdCB3b3VsZCBiZSB0cmlnZ2VyZWQgaW4gdGhlIG5l dyBjYWxsJ3Mgc2lnbmFsbGluZw0KcGF0aCwgYW5kIGRvIHRoZSBjaGFuZ2luZyB0aGUgZGlhbG9n IGluZm9ybWF0aW9uIHdvcmsgYXMgZGVmaW5lZCBpbiAyNC4yMjkuPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAm bmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQog ZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj48Yj5IYWRyaWVsIEthcGxhbiAmbHQ7SEthcGxhbkBhY21lcGFja2V0LmNvbSZndDs8 L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC0wNy0w NyAxODowMzwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4mcXVvdDtnYW8ueWFuZzJAenRlLmNvbS5jbiZxdW90OyAmbHQ7Z2FvLnlhbmcyQHp0 ZS5jb20uY24mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJp Z2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtkaXNwYXRjaEBpZXRmLm9yZyZx dW90OyAmbHQ7ZGlzcGF0Y2hAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98zi PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SRTogW2Rp c3BhdGNoXSBBYm91dCBGaW5hbCBDaGFydGVyIGZvcg0KU2Vzc2lvbi1JRDo8L2ZvbnQ+PC90YWJs ZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8 YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBm YWNlPSJBcmlhbCI+R2FvLDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBm YWNlPSJBcmlhbCI+SGF2ZSB5b3UgdGFrZW4gYSBsb29rIGF0IHRoZQ0KZW1haWwgdGhyZWFkIGFi b3V0IHNlc3Npb24taWQgYW5kIGRpYWxvZy1tYXRjaGluZywgc3RhcnRpbmcgYXQgdGhlIGZvbGxv d2luZw0KZW1haWwgbWVzc2FnZT86PC9mb250Pg0KPGJyPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0 Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9kaXNwYXRjaC9jdXJyZW50L21zZzAxNjU4Lmh0bWwiPjxm b250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9IkFyaWFsIj48dT5odHRwOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvZGlzcGF0Y2gvY3VycmVudC9tc2cwMTY1OC5odG1sPC91PjwvZm9u dD48L2E+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPkkgdGhp bmsgYSByZXBsYWNlcyB1c2FnZSB3b3VsZA0KaGF2ZSB0aGUgc2FtZSBpc3N1ZXMuPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj4mbmJzcDs8L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPi1oYWRyaWVsPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj4mbmJzcDs8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPiZuYnNw OzwvZm9udD4NCjxkaXYgYWxpZ249Y2VudGVyPg0KPGJyPg0KPGhyPjwvZGl2Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPkZyb206PC9iPiBkaXNwYXRjaC1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+Z2FvLnlhbmcyQHp0ZS5jb20uY248Yj48YnI+DQpTZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5 IDA3LCAyMDEwIDE6NDQgQU08Yj48YnI+DQpUbzo8L2I+IEhhZHJpZWwgS2FwbGFuPGI+PGJyPg0K Q2M6PC9iPiBkaXNwYXRjaEBpZXRmLm9yZzxiPjxicj4NClN1YmplY3Q6PC9iPiBSZTogW2Rpc3Bh dGNoXSBBYm91dCBGaW5hbCBDaGFydGVyIGZvciBTZXNzaW9uLUlEOjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpIaSBIYWRyaWVsLDwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PGJyPg0KPGJyPg0KJmd0OyBSaWdodCwgbXkgaW50ZW50aW9uIHdhcyB0byBO T1QgaW1wYWN0L2FmZmVjdC9pbmNsdWRlIGRpYWxvZy08YnI+DQomZ3Q7IG1hdGNoaW5nLCBvciBh bnl0aGluZyBidXQgdHJvdWJsZXNob290aW5nLiAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij48YnI+DQpUaGlzIGlzIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGNoYXJ0ZXIg YW5kIHRoZSB0ZXh0LiBUaGVuLCBJIGFtIHJpZ2h0DQphdCB0aGlzIHBvaW50LjwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KJmd0OyBCdXQgb2YgY291cnNlIGEgY2hhcnRlciA8 YnI+DQomZ3Q7IGFuZCBXRyBpcyBhIGNvbnNlbnN1cy1iYXNlZCBkZWNpc2lvbiwgbm90IG1pbmUs IHNvIGlmIG90aGVycyBmZWVsDQo8YnI+DQomZ3Q7IHRoZXkgd2FudCBtb3JlIHRoZXkgY2FuIGFy Z3VlIGZvciBpdC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8 YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpRdWl0IHRy dWUuIEFuZCBJIHdpbGwgc2VlayB0aW1lIHRvIG1ha2UgYSBtb3JlIGRldGFpbGVkIGRpc2N1c3Np b24gZm9yDQp0aGlzIHRvcGljLiBBbmQgSSBob3BlIHBlb3BsZSB3aG8gY2FyZSBhYm91dCAmcXVv dDtyZXBsYWNlIGhlYWRlcidzIGRpYWxvZy1tYXRjaGluZw0KcHJvYmxlbSZxdW90OyBqb2luIGlu IHRoaXMgZGlzY3Vzc2lvbiB0aGVuLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxi cj4NCkdhbzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPGJyPg0K PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KJmd0OyAtaGFkcmll bDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KJmd0OyAmbmJzcDs8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPjxicj4NCiZndDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 YnI+DQomZ3Q7IDxicj4NCiZndDsgRnJvbTogZ2FvLnlhbmcyQHp0ZS5jb20uY24gW21haWx0bzpn YW8ueWFuZzJAenRlLmNvbS5jbl0gPGJyPg0KJmd0OyBTZW50OiBUdWVzZGF5LCBKdW5lIDI5LCAy MDEwIDk6MDggUE08YnI+DQomZ3Q7IFRvOiBkaXNwYXRjaEBpZXRmLm9yZzxicj4NCiZndDsgQ2M6 IEhhZHJpZWwgS2FwbGFuPGJyPg0KJmd0OyBTdWJqZWN0OiBBYm91dCBGaW5hbCBDaGFydGVyIGZv ciBTZXNzaW9uLUlEOjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgJm5ic3A7 PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQomZ3Q7IDxicj4NCiZndDsgSGksIDxicj4N CiZndDsgPGJyPg0KJmd0OyBCeSB0aGUgY2hhcnRlciBhbmQgdGhlIG9yaWdpbmFsIHRleHQgbmFt ZWQgZHJhZnQta2FwbGFuLXNpcC1zZXNzaW9uLTxicj4NCiZndDsgaWQtMDIsIHRoaXMgd29yayBp cyBqdXN0IGZvY3VzZWQgb24gdHJvdWJsZXNob290aW5nIHVzYWdlLiA8YnI+DQomZ3Q7IDxicj4N CiZndDsgQnV0IEkgd2FzIHRvbGQgdGhhdCAqc29tZW9uZSogd2FudCB0byB1c2UgdGhpcyBzZXNz aW9uLWlkIGluIFJlcGxhY2U8YnI+DQomZ3Q7IGhlYWRlciB1c2FnZSwgdG8gZG8gZGlhbG9nLW1h dGNoaW5nLiBJIHRoaW5rIHRoaXMgd291bGQgYmUgVVBEQVRFDQpvZiBSRkMzODkxLjxicj4NCiZn dDsgPGJyPg0KJmd0OyBTbywgSSdkIGxpa2UgdG8gY29uZmlybSB0aGF0IHRoaXMgY2hhcnRlciBh bmQgY29taW5nIGRyYWZ0IHdvdWxkIG5vdDxicj4NCiZndDsgZG8gc3VjaCB0aGluZyBub3JtYXRp dmVseS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcywgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEdhbyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT08YnI+DQomZ3Q7IFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQomZ3Q7IFRlbCAm bmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiZndDsgVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3 NzIxMTxicj4NCiZndDsgZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQomZ3Q7ID09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PGJyPg0KJmd0OyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQomZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1 cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcw0KPGJyPg0KJmd0 OyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBU aGlzIG1haWwgPGJyPg0KJmd0OyBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBp ZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkDQo8YnI+DQomZ3Q7IHRvIG1haW50YWluIHNl Y3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cw0KPGJy Pg0KJmd0OyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxicj4NCiZndDsgVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVk IHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQNCjxicj4NCiZndDsgaW50ZW5kZWQgc29sZWx5 IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXk8YnI+ DQomZ3Q7IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IgcGxlYXNlIDxicj4NCiZndDsgbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMNCjxicj4NCiZndDsgbWVzc2FnZSBhcmUg dGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci Pjxicj4NCiZndDsgVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5k IFNwYW0gYnkgWlRFIEFudGktU3BhbQ0Kc3lzdGVtLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPiZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q291cmllciBOZXciPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlDQppbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5p emF0aW9uLg0KVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGll bnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQNCnRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFy ZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzDQpjb21tdW5p Y2F0aW9uIHRvIG90aGVycy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij5UaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQNCndpdGggaXQgYXJlIGNv bmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsDQpvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4NCmVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Ig b2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQNCmluIHRoaXMgbWVzc2FnZSBhcmUg dGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPlRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1 c2VzDQphbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS48L2ZvbnQ+DQo8YnI+DQo8YnI+ PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZu YnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlz Jm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWls Jm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lw aWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7 dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3Qm bmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVu dHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhl cnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3Ry YW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5i c3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1 c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZu YnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7 SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwm bmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7 b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2 aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDth cmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRl ci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJz cDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5i c3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 003DCDF148257759_=-- From mperumal@cisco.com Wed Jul 7 04:40:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6DAD3A659C for ; Wed, 7 Jul 2010 04:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.123 X-Spam-Level: X-Spam-Status: No, score=-8.123 tagged_above=-999 required=5 tests=[AWL=-1.175, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, J_CHICKENPOX_91=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrFucwXTLFMh for ; Wed, 7 Jul 2010 04:40:40 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 0D2833A67AB for ; Wed, 7 Jul 2010 04:40:40 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAKoENExAaHte/2dsb2JhbACBQ4FanG5xpXiJIgiRQYQudgSDdoZ0 X-IronPort-AV: E=Sophos;i="4.53,552,1272844800"; d="scan'208,217";a="266024691" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-2.cisco.com with ESMTP; 07 Jul 2010 11:40:41 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o67Beetd027579; Wed, 7 Jul 2010 11:40:40 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Jul 2010 17:10:40 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1DC9.39408656" Date: Wed, 7 Jul 2010 17:10:35 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020319A18F@XMB-BGL-414.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] About Final Charter for Session-ID: Thread-Index: AcsdwqYaB4zGljV8RnqCUQ/3xWRXVwABjdTA References: <430FC6BDED356B4C8498F634416644A91FE874DF8B@mail> From: "Muthu ArulMozhi Perumal (mperumal)" To: , "Hadriel Kaplan" X-OriginalArrivalTime: 07 Jul 2010 11:40:40.0273 (UTC) FILETIME=[39A1D410:01CB1DC9] Cc: dispatch@ietf.org Subject: Re: [dispatch] About Final Charter for Session-ID: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 11:40:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1DC9.39408656 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable That's one the primary reasons why I think IETF should have at least a = BEHAVE-like WG for B2BUAs/SBCs. =20 Muthu =20 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of gao.yang2@zte.com.cn Sent: Wednesday, July 07, 2010 4:09 PM To: Hadriel Kaplan Cc: dispatch@ietf.org Subject: Re: [dispatch] About Final Charter for Session-ID: =20 Hi Hadriel,=20 I met the same problem as you showed in your mail(relating 3GPP's = conference service) in our real IMS deployment. The original and = directly idea for me is the same as the prosposal showed in your mail, = to invent a new header to do dialog-matching beyond B2BUA equipment(I = even have a patent for a new header to do dialog-matching).=20 But why now I reject the way? There are two main reasons here:=20 1. This work is UPDATE RFC3891(as I said before). And even we make this = *potential UPDATE RFC3891 Draft/RFC*, how may UAs would support it, and = I think there still would be a serious interworking issue.=20 2. Philosophy and methodology:=20 As we know, basic SIP RFCs(standard track) only define rules about = UAC/UAS and proxy. There's no normative definition about B2BUA(RFC3725 = is BCP level). In fact, B2BUA is implementation level usage of standard = track SIP RFCs.=20 So, I don't think it is appropriate to use B2BUA's implementation level = problem as reason for demanding standard track SIP RFC's correction.=20 Thanks,=20 Gao=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 Hadriel Kaplan =20 2010-07-07 18:03=20 =CA=D5=BC=FE=C8=CB "gao.yang2@zte.com.cn" =20 =B3=AD=CB=CD "dispatch@ietf.org" =20 =D6=F7=CC=E2 RE: [dispatch] About Final Charter for Session-ID: =20 =09 Gao,=20 Have you taken a look at the email thread about session-id and = dialog-matching, starting at the following email message?:=20 http://www.ietf.org/mail-archive/web/dispatch/current/msg01658.html = =20 I think a replaces usage would have the same issues.=20 =20 -hadriel=20 =20 =20 =20 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of gao.yang2@zte.com.cn Sent: Wednesday, July 07, 2010 1:44 AM To: Hadriel Kaplan Cc: dispatch@ietf.org Subject: Re: [dispatch] About Final Charter for Session-ID:=20 =20 Hi Hadriel,=20 > Right, my intention was to NOT impact/affect/include dialog- > matching, or anything but troubleshooting. =20 This is my understanding of the charter and the text. Then, I am right = at this point.=20 > But of course a charter=20 > and WG is a consensus-based decision, not mine, so if others feel=20 > they want more they can argue for it.=20 Quit true. And I will seek time to make a more detailed discussion for = this topic. And I hope people who care about "replace header's = dialog-matching problem" join in this discussion then.=20 Gao=20 > -hadriel=20 > =20 > =20 >=20 > From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]=20 > Sent: Tuesday, June 29, 2010 9:08 PM > To: dispatch@ietf.org > Cc: Hadriel Kaplan > Subject: About Final Charter for Session-ID:=20 > =20 >=20 > Hi,=20 >=20 > By the charter and the original text named draft-kaplan-sip-session- > id-02, this work is just focused on troubleshooting usage.=20 >=20 > But I was told that *someone* want to use this session-id in Replace > header usage, to do dialog-matching. I think this would be UPDATE of = RFC3891. >=20 > So, I'd like to confirm that this charter and coming draft would not > do such thing normatively.=20 >=20 > Thanks,=20 >=20 > Gao=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > =20 > --------------------------------------------------------=20 > ZTE Information Security Notice: The information contained in this=20 > mail is solely property of the sender's organization. This mail=20 > communication is confidential. Recipients named above are obligated=20 > to maintain secrecy and are not permitted to disclose the contents=20 > of this communication to others.=20 > This email and any files transmitted with it are confidential and=20 > intended solely for the use of the individual or entity to whom they > are addressed. If you have received this email in error please=20 > notify the originator of the message. Any views expressed in this=20 > message are those of the individual sender.=20 > This message has been scanned for viruses and Spam by ZTE Anti-Spam = system.=20 =20 --------------------------------------------------------=20 ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others.=20 This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender.=20 This message has been scanned for viruses and Spam by ZTE Anti-Spam = system.=20 =20 -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail = is solely property of the sender's organization. This mail communication = is confidential. Recipients named above are obligated to maintain = secrecy and are not permitted to disclose the contents of this = communication to others. This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. ------_=_NextPart_001_01CB1DC9.39408656 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

That's = one the primary reasons why I think IETF should = have at least a BEHAVE-like WG for B2BUAs/SBCs.

 

Muthu

 

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of gao.yang2@zte.com.cn
Sent: Wednesday, July 07, 2010 4:09 PM
To: Hadriel Kaplan
Cc: dispatch@ietf.org
Subject: Re: [dispatch] About Final Charter for = Session-ID:

 


Hi = Hadriel,

I met = the same problem as you showed in your mail(relating 3GPP's conference service) = in our real IMS deployment. The original and directly idea for me is the same = as the prosposal showed in your mail, to invent a new header to do = dialog-matching beyond B2BUA equipment(I even have a patent for a new header to do dialog-matching).

But = why now I reject the way? There are two main reasons here:

1. = This work is UPDATE RFC3891(as I said before). And even we make this *potential = UPDATE RFC3891 Draft/RFC*, how may UAs would support it, and I think there = still would be a serious interworking issue.

2. = Philosophy and methodology:
As we = know, basic SIP RFCs(standard track) only define rules about UAC/UAS and = proxy. There's no normative definition about B2BUA(RFC3725 is BCP level). In = fact, B2BUA is implementation level usage of standard track SIP RFCs. =
So, I = don't think it is appropriate to use B2BUA's implementation level problem as = reason for demanding standard track SIP RFC's correction.

Thanks,

Gao =

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Hadriel Kaplan <HKaplan@acmepacket.com>

2010-07-07 18:03

=CA=D5=BC=FE=C8=CB

"gao.yang= 2@zte.com.cn" <gao.yang2@zte.com.cn>

=B3=AD=CB=CD

"dispatch= @ietf.org" <dispatch@ietf.org>

=D6=F7=CC=E2

RE: [dispatch] About Final Charter for Session-ID:

 




Ga= o,
Ha= ve you taken a look at the email thread about session-id and = dialog-matching, starting at the following email message?:
http://www.ie= tf.org/mail-archive/web/dispatch/current/msg01658.html
I think a replaces usage would have the same issues.
&n= bsp;
-h= adriel
&n= bsp;
&n= bsp;

 


From:= dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of gao.yang2@zte.com.cn
Sent: Wednesday, July 07, 2010 1:44 AM
To: Hadriel Kaplan
Cc: dispatch@ietf.org
Subject: Re: [dispatch] About Final Charter for Session-ID: =
 

Hi Hadriel, =

> Right, my intention was to NOT impact/affect/include dialog-
> matching, or anything but troubleshooting.  

This is my understanding of the charter and the text. Then, I am right = at this point.

> But of course a charter
> and WG is a consensus-based decision, not mine, so if others feel =
> they want more they can argue for it.

Quit true. And I will seek time to make a more detailed discussion for = this topic. And I hope people who care about "replace header's = dialog-matching problem" join in this discussion then.

Gao

> -hadriel
>   =
>   =
>
> From: gao.yang2@zte.com.cn [mailto:gao.yang2@zte.com.cn]
> Sent: Tuesday, June 29, 2010 9:08 PM
> To: dispatch@ietf.org
> Cc: Hadriel Kaplan
> Subject: About Final Charter for Session-ID:
>   =
>
> Hi,
>
> By the charter and the original text named = draft-kaplan-sip-session-
> id-02, this work is just focused on troubleshooting usage.
>
> But I was told that *someone* want to use this session-id in = Replace
> header usage, to do dialog-matching. I think this would be UPDATE = of RFC3891.
>
> So, I'd like to confirm that this charter and coming draft would = not
> do such thing normatively.
>
> Thanks,
>
> Gao
>
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> Zip    : 210012
> Tel    : 87211
> Tel2   :(+86)-025-52877211
> e_mail : gao.yang2@zte.com.cn
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>   =
> = --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this =
> mail is solely property of the sender's organization. This mail =
> communication is confidential. Recipients named above are obligated =
> to maintain secrecy and are not permitted to disclose the contents =
> of this communication to others.
> This email and any files transmitted with it are confidential and =
> intended solely for the use of the individual or entity to whom = they
> are addressed. If you have received this email in error please
> notify the originator of the message. Any views expressed in this =
> message are those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
  =
--------------------------------------------------------
ZTE = Information Security Notice: The information contained in this mail is solely = property of the sender's organization. This mail communication is confidential. = Recipients named above are obligated to maintain secrecy and are not permitted to = disclose the contents of this communication to others.
This email = and any files transmitted with it are confidential and intended solely for the = use of the individual or entity to whom they are addressed. If you have = received this email in error please notify the originator of the message. Any views = expressed in this message are those of the individual sender.
This message = has been scanned for viruses and Spam by ZTE Anti-Spam system. = 

 
----------------------------------------=
----------------
ZTE Information Se=
curity Notice: The information contained in=
 this mail is solely property of the sender's organization. Th=
is mail communication is confidential. Recipients na=
med above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
= 
This email and any files transmitted with it are confidential an=
d intended solely for the use of the individual or entity to whom they are addressed. If=
 you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam sy=
stem.
------_=_NextPart_001_01CB1DC9.39408656-- From gao.yang2@zte.com.cn Wed Jul 7 04:50:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F116B3A67F1 for ; Wed, 7 Jul 2010 04:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.332 X-Spam-Level: X-Spam-Status: No, score=-97.332 tagged_above=-999 required=5 tests=[AWL=-0.897, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, J_CHICKENPOX_91=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9OpGu9DjhFo for ; Wed, 7 Jul 2010 04:50:44 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 290B53A67EA for ; Wed, 7 Jul 2010 04:50:42 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 38343992332426; Wed, 7 Jul 2010 19:50:10 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 83990.2904150393; Wed, 7 Jul 2010 19:50:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o67Bomfb022479; Wed, 7 Jul 2010 19:50:48 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <1D062974A4845E4D8A343C65380492020319A18F@XMB-BGL-414.cisco.com> To: "Muthu ArulMozhi Perumal (mperumal)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 7 Jul 2010 19:46:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-07 19:50:33, Serialize complete at 2010-07-07 19:50:33 Content-Type: multipart/alternative; boundary="=_alternative 0040FAD948257759_=" X-MAIL: mse2.zte.com.cn o67Bomfb022479 Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] About Final Charter for Session-ID: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 11:50:46 -0000 This is a multipart message in MIME format. --=_alternative 0040FAD948257759_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 TXV0aHUsDQoNClllcy4gSSBhZ3JlZSB3aXRoIHRoZXNlIHdvcmRzIGluIHlvdXIgbWFpbDoNCiJE dWUgdG8gbGFjayBvZiB3ZWxsIGRlZmluZWQgZ3VpZGVsaW5lcyBhbmQgYmVzdCBjdXJyZW50IHBy YWN0aWNlcyBtYW55IA0KU0JDIGltcGxlbWVudGF0aW9ucyBicmVhayBlbmQtdG8tZW5kIGZlYXR1 cmVzIg0KDQpTbywgSSB0aGluayBhbnkgQjJCVUEgcHJvYmxlbSBzaG91bGQgbWFrZSBpdCBzb2x1 dGlvbiBpbi1zY29wZSBvZiB0aGUgDQpCMkJVQSBpdHNlbGYgb3IganVzdCBhcm91bmQgaXQuDQoN ClRoYW5rcywNCg0KR2FvDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQog WmlwICAgIDogMjEwMDEyDQogVGVsICAgIDogODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3 NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KDQoNCg0KIk11dGh1IEFydWxNb3poaSBQZXJ1bWFsIChtcGVydW1h bCkiIDxtcGVydW1hbEBjaXNjby5jb20+IA0KMjAxMC0wNy0wNyAxOTo0MA0KDQrK1bz+yMsNCjxn YW8ueWFuZzJAenRlLmNvbS5jbj4sICJIYWRyaWVsIEthcGxhbiIgPEhLYXBsYW5AYWNtZXBhY2tl dC5jb20+DQqzrcvNDQo8ZGlzcGF0Y2hAaWV0Zi5vcmc+DQrW98ziDQpSRTogW2Rpc3BhdGNoXSBB Ym91dCBGaW5hbCBDaGFydGVyIGZvciBTZXNzaW9uLUlEOg0KDQoNCg0KDQoNCg0KVGhhdCdzIG9u ZSB0aGUgcHJpbWFyeSByZWFzb25zIHdoeSBJIHRoaW5rIElFVEYgc2hvdWxkIGhhdmUgYXQgbGVh c3QgYSANCkJFSEFWRS1saWtlIFdHIGZvciBCMkJVQXMvU0JDcy4NCiANCk11dGh1DQogDQpGcm9t OiBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRm Lm9yZ10gT24gDQpCZWhhbGYgT2YgZ2FvLnlhbmcyQHp0ZS5jb20uY24NClNlbnQ6IFdlZG5lc2Rh eSwgSnVseSAwNywgMjAxMCA0OjA5IFBNDQpUbzogSGFkcmllbCBLYXBsYW4NCkNjOiBkaXNwYXRj aEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gQWJvdXQgRmluYWwgQ2hhcnRlciBm b3IgU2Vzc2lvbi1JRDoNCiANCg0KSGkgSGFkcmllbCwgDQoNCkkgbWV0IHRoZSBzYW1lIHByb2Js ZW0gYXMgeW91IHNob3dlZCBpbiB5b3VyIG1haWwocmVsYXRpbmcgM0dQUCdzIA0KY29uZmVyZW5j ZSBzZXJ2aWNlKSBpbiBvdXIgcmVhbCBJTVMgZGVwbG95bWVudC4gVGhlIG9yaWdpbmFsIGFuZCBk aXJlY3RseSANCmlkZWEgZm9yIG1lIGlzIHRoZSBzYW1lIGFzIHRoZSBwcm9zcG9zYWwgc2hvd2Vk IGluIHlvdXIgbWFpbCwgdG8gaW52ZW50IGEgDQpuZXcgaGVhZGVyIHRvIGRvIGRpYWxvZy1tYXRj aGluZyBiZXlvbmQgQjJCVUEgZXF1aXBtZW50KEkgZXZlbiBoYXZlIGEgDQpwYXRlbnQgZm9yIGEg bmV3IGhlYWRlciB0byBkbyBkaWFsb2ctbWF0Y2hpbmcpLiANCg0KQnV0IHdoeSBub3cgSSByZWpl Y3QgdGhlIHdheT8gVGhlcmUgYXJlIHR3byBtYWluIHJlYXNvbnMgaGVyZTogDQoNCjEuIFRoaXMg d29yayBpcyBVUERBVEUgUkZDMzg5MShhcyBJIHNhaWQgYmVmb3JlKS4gQW5kIGV2ZW4gd2UgbWFr ZSB0aGlzIA0KKnBvdGVudGlhbCBVUERBVEUgUkZDMzg5MSBEcmFmdC9SRkMqLCBob3cgbWF5IFVB cyB3b3VsZCBzdXBwb3J0IGl0LCBhbmQgSSANCnRoaW5rIHRoZXJlIHN0aWxsIHdvdWxkIGJlIGEg c2VyaW91cyBpbnRlcndvcmtpbmcgaXNzdWUuIA0KDQoyLiBQaGlsb3NvcGh5IGFuZCBtZXRob2Rv bG9neTogDQpBcyB3ZSBrbm93LCBiYXNpYyBTSVAgUkZDcyhzdGFuZGFyZCB0cmFjaykgb25seSBk ZWZpbmUgcnVsZXMgYWJvdXQgVUFDL1VBUyANCmFuZCBwcm94eS4gVGhlcmUncyBubyBub3JtYXRp dmUgZGVmaW5pdGlvbiBhYm91dCBCMkJVQShSRkMzNzI1IGlzIEJDUCANCmxldmVsKS4gSW4gZmFj dCwgQjJCVUEgaXMgaW1wbGVtZW50YXRpb24gbGV2ZWwgdXNhZ2Ugb2Ygc3RhbmRhcmQgdHJhY2sg U0lQIA0KUkZDcy4gDQpTbywgSSBkb24ndCB0aGluayBpdCBpcyBhcHByb3ByaWF0ZSB0byB1c2Ug QjJCVUEncyBpbXBsZW1lbnRhdGlvbiBsZXZlbCANCnByb2JsZW0gYXMgcmVhc29uIGZvciBkZW1h bmRpbmcgc3RhbmRhcmQgdHJhY2sgU0lQIFJGQydzIGNvcnJlY3Rpb24uIA0KDQpUaGFua3MsIA0K DQpHYW8gDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQpaaXAgICAgOiAy MTAwMTINClRlbCAgICA6IDg3MjExDQpUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KZV9tYWls IDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09IA0KDQoNCkhhZHJpZWwgS2FwbGFuIDxIS2FwbGFuQGFjbWVwYWNrZXQuY29tPiANCjIwMTAt MDctMDcgMTg6MDMgDQoNCg0KytW8/sjLDQoiZ2FvLnlhbmcyQHp0ZS5jb20uY24iIDxnYW8ueWFu ZzJAenRlLmNvbS5jbj4gDQqzrcvNDQoiZGlzcGF0Y2hAaWV0Zi5vcmciIDxkaXNwYXRjaEBpZXRm Lm9yZz4gDQrW98ziDQpSRTogW2Rpc3BhdGNoXSBBYm91dCBGaW5hbCBDaGFydGVyIGZvciBTZXNz aW9uLUlEOg0KIA0KDQoNCg0KDQoNCg0KDQoNCkdhbywgDQpIYXZlIHlvdSB0YWtlbiBhIGxvb2sg YXQgdGhlIGVtYWlsIHRocmVhZCBhYm91dCBzZXNzaW9uLWlkIGFuZCANCmRpYWxvZy1tYXRjaGlu Zywgc3RhcnRpbmcgYXQgdGhlIGZvbGxvd2luZyBlbWFpbCBtZXNzYWdlPzogDQpodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZGlzcGF0Y2gvY3VycmVudC9tc2cwMTY1OC5odG1s IA0KSSB0aGluayBhIHJlcGxhY2VzIHVzYWdlIHdvdWxkIGhhdmUgdGhlIHNhbWUgaXNzdWVzLiAN CiAgDQotaGFkcmllbCANCiAgDQogIA0KIA0KDQoNCkZyb206IGRpc3BhdGNoLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnXSBPbiANCkJlaGFsZiBPZiBn YW8ueWFuZzJAenRlLmNvbS5jbg0KU2VudDogV2VkbmVzZGF5LCBKdWx5IDA3LCAyMDEwIDE6NDQg QU0NClRvOiBIYWRyaWVsIEthcGxhbg0KQ2M6IGRpc3BhdGNoQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW2Rpc3BhdGNoXSBBYm91dCBGaW5hbCBDaGFydGVyIGZvciBTZXNzaW9uLUlEOiANCiAgDQoN CkhpIEhhZHJpZWwsIA0KDQo+IFJpZ2h0LCBteSBpbnRlbnRpb24gd2FzIHRvIE5PVCBpbXBhY3Qv YWZmZWN0L2luY2x1ZGUgZGlhbG9nLQ0KPiBtYXRjaGluZywgb3IgYW55dGhpbmcgYnV0IHRyb3Vi bGVzaG9vdGluZy4gICANCg0KVGhpcyBpcyBteSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBjaGFydGVy IGFuZCB0aGUgdGV4dC4gVGhlbiwgSSBhbSByaWdodCBhdCANCnRoaXMgcG9pbnQuIA0KDQo+IEJ1 dCBvZiBjb3Vyc2UgYSBjaGFydGVyIA0KPiBhbmQgV0cgaXMgYSBjb25zZW5zdXMtYmFzZWQgZGVj aXNpb24sIG5vdCBtaW5lLCBzbyBpZiBvdGhlcnMgZmVlbCANCj4gdGhleSB3YW50IG1vcmUgdGhl eSBjYW4gYXJndWUgZm9yIGl0LiANCg0KUXVpdCB0cnVlLiBBbmQgSSB3aWxsIHNlZWsgdGltZSB0 byBtYWtlIGEgbW9yZSBkZXRhaWxlZCBkaXNjdXNzaW9uIGZvciANCnRoaXMgdG9waWMuIEFuZCBJ IGhvcGUgcGVvcGxlIHdobyBjYXJlIGFib3V0ICJyZXBsYWNlIGhlYWRlcidzIA0KZGlhbG9nLW1h dGNoaW5nIHByb2JsZW0iIGpvaW4gaW4gdGhpcyBkaXNjdXNzaW9uIHRoZW4uIA0KDQpHYW8gDQoN Cj4gLWhhZHJpZWwgDQo+ICAgDQo+ICAgDQo+IA0KPiBGcm9tOiBnYW8ueWFuZzJAenRlLmNvbS5j biBbbWFpbHRvOmdhby55YW5nMkB6dGUuY29tLmNuXSANCj4gU2VudDogVHVlc2RheSwgSnVuZSAy OSwgMjAxMCA5OjA4IFBNDQo+IFRvOiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBDYzogSGFkcmllbCBL YXBsYW4NCj4gU3ViamVjdDogQWJvdXQgRmluYWwgQ2hhcnRlciBmb3IgU2Vzc2lvbi1JRDogDQo+ ICAgDQo+IA0KPiBIaSwgDQo+IA0KPiBCeSB0aGUgY2hhcnRlciBhbmQgdGhlIG9yaWdpbmFsIHRl eHQgbmFtZWQgZHJhZnQta2FwbGFuLXNpcC1zZXNzaW9uLQ0KPiBpZC0wMiwgdGhpcyB3b3JrIGlz IGp1c3QgZm9jdXNlZCBvbiB0cm91Ymxlc2hvb3RpbmcgdXNhZ2UuIA0KPiANCj4gQnV0IEkgd2Fz IHRvbGQgdGhhdCAqc29tZW9uZSogd2FudCB0byB1c2UgdGhpcyBzZXNzaW9uLWlkIGluIFJlcGxh Y2UNCj4gaGVhZGVyIHVzYWdlLCB0byBkbyBkaWFsb2ctbWF0Y2hpbmcuIEkgdGhpbmsgdGhpcyB3 b3VsZCBiZSBVUERBVEUgb2YgDQpSRkMzODkxLg0KPiANCj4gU28sIEknZCBsaWtlIHRvIGNvbmZp cm0gdGhhdCB0aGlzIGNoYXJ0ZXIgYW5kIGNvbWluZyBkcmFmdCB3b3VsZCBub3QNCj4gZG8gc3Vj aCB0aGluZyBub3JtYXRpdmVseS4gDQo+IA0KPiBUaGFua3MsIA0KPiANCj4gR2FvIA0KPiANCj4g PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gWmlwICAgIDogMjEwMDEyDQo+ IFRlbCAgICA6IDg3MjExDQo+IFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQo+IGVfbWFpbCA6 IGdhby55YW5nMkB6dGUuY29tLmNuDQo+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09IA0KPiAgIA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSANCj4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIA0KPiBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBv ZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgDQo+IGNvbW11bmljYXRpb24g aXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgDQo+ IHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRo ZSBjb250ZW50cyANCj4gb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4gDQo+IFRoaXMg ZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwg YW5kIA0KPiBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdob20gdGhleQ0KPiBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSANCj4gbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9m IHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgDQo+IG1lc3NhZ2UgYXJl IHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4gDQo+IFRoaXMgbWVzc2FnZSBoYXMgYmVl biBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0u IA0KICANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tIA0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgDQpzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRl cidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgDQpjb25maWRlbnRp YWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNy ZWN5IGFuZCANCmFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0 aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhlcnMuIA0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVz IHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgDQpzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBh cmUgYWRkcmVzc2VkLiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Ig cGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiANCnRoZSBtZXNzYWdlLiBBbnkgdmlld3Mg ZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIA0KaW5kaXZpZHVhbCBz ZW5kZXIuIA0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNw YW0gYnkgWlRFIEFudGktU3BhbSANCnN5c3RlbS4gDQogDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3Vy aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgDQpz b2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNv bW11bmljYXRpb24gaXMgDQpjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJl IG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCANCmFyZSBub3QgcGVybWl0dGVkIHRv IGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhlcnMu DQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlk ZW50aWFsIGFuZCBpbnRlbmRlZCANCnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIA0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9m IA0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0 aG9zZSBvZiB0aGUgDQppbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBz Y2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0uDQoN Cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBv cmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVj aXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5k IGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11 bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVk IHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNl IG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4g SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRo ZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMg bWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdl IGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBz eXN0ZW0uDQo= --=_alternative 0040FAD948257759_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk11dGh1LDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+WWVzLiBJIGFncmVlIHdpdGggdGhl c2Ugd29yZHMgaW4geW91cg0KbWFpbDo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPiZxdW90O0R1ZSB0byBsYWNrIG9mIHdlbGwgZGVmaW5lZCBndWlkZWxpbmVzDQph bmQgYmVzdCBjdXJyZW50IHByYWN0aWNlcyBtYW55IFNCQyBpbXBsZW1lbnRhdGlvbnMgYnJlYWsg ZW5kLXRvLWVuZCBmZWF0dXJlcyZxdW90OzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+U28sIEkgdGhpbmsgYW55IEIyQlVBIHByb2JsZW0gc2hvdWxkDQpt YWtlIGl0IHNvbHV0aW9uIGluLXNjb3BlIG9mIHRoZSBCMkJVQSBpdHNlbGYgb3IganVzdCBhcm91 bmQgaXQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5U aGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5H YW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAy MTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDoo Kzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+ DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzUl Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtNdXRodSBBcnVsTW96aGkg UGVydW1hbA0KKG1wZXJ1bWFsKSZxdW90OyAmbHQ7bXBlcnVtYWxAY2lzY28uY29tJmd0OzwvYj4g PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDctMDcgMTk6 NDA8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+Jmx0O2dhby55YW5nMkB6dGUuY29tLmNuJmd0OywgJnF1b3Q7SGFkcmllbA0KS2FwbGFuJnF1 b3Q7ICZsdDtIS2FwbGFuQGFjbWVwYWNrZXQuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Jmx0 O2Rpc3BhdGNoQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UkU6IFtkaXNwYXRjaF0g QWJvdXQgRmluYWwgQ2hhcnRlciBmb3INClNlc3Npb24tSUQ6PC9mb250PjwvdGFibGU+DQo8YnI+ DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFi bGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5UaGF0 J3Mgb25lIHRoZSBwcmltYXJ5IHJlYXNvbnMgd2h5DQpJIHRoaW5rIElFVEYgc2hvdWxkIGhhdmUg YXQgbGVhc3QgYSBCRUhBVkUtbGlrZSBXRyBmb3IgQjJCVUFzL1NCQ3MuPC9mb250Pg0KPHA+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPk11dGh1PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij4mbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0iVGFob21h Ij48Yj5Gcm9tOjwvYj4gZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRpc3BhdGNo LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPmdhby55YW5nMkB6dGUuY29t LmNuPGI+PGJyPg0KU2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAwNywgMjAxMCA0OjA5IFBNPGI+ PGJyPg0KVG86PC9iPiBIYWRyaWVsIEthcGxhbjxiPjxicj4NCkNjOjwvYj4gZGlzcGF0Y2hAaWV0 Zi5vcmc8Yj48YnI+DQpTdWJqZWN0OjwvYj4gUmU6IFtkaXNwYXRjaF0gQWJvdXQgRmluYWwgQ2hh cnRlciBmb3IgU2Vzc2lvbi1JRDo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IkFyaWFsIj48YnI+DQpIaSBIYWRyaWVsLDwvZm9udD48 Zm9udCBzaXplPTM+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4N CkkgbWV0IHRoZSBzYW1lIHByb2JsZW0gYXMgeW91IHNob3dlZCBpbiB5b3VyIG1haWwocmVsYXRp bmcgM0dQUCdzIGNvbmZlcmVuY2UNCnNlcnZpY2UpIGluIG91ciByZWFsIElNUyBkZXBsb3ltZW50 LiBUaGUgb3JpZ2luYWwgYW5kIGRpcmVjdGx5IGlkZWEgZm9yDQptZSBpcyB0aGUgc2FtZSBhcyB0 aGUgcHJvc3Bvc2FsIHNob3dlZCBpbiB5b3VyIG1haWwsIHRvIGludmVudCBhIG5ldyBoZWFkZXIN CnRvIGRvIGRpYWxvZy1tYXRjaGluZyBiZXlvbmQgQjJCVUEgZXF1aXBtZW50KEkgZXZlbiBoYXZl IGEgcGF0ZW50IGZvciBhDQpuZXcgaGVhZGVyIHRvIGRvIGRpYWxvZy1tYXRjaGluZykuPC9mb250 Pjxmb250IHNpemU9Mz4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJy Pg0KQnV0IHdoeSBub3cgSSByZWplY3QgdGhlIHdheT8gVGhlcmUgYXJlIHR3byBtYWluIHJlYXNv bnMgaGVyZTo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPg0KPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBm YWNlPSJBcmlhbCI+PGJyPg0KMS4gVGhpcyB3b3JrIGlzIFVQREFURSBSRkMzODkxKGFzIEkgc2Fp ZCBiZWZvcmUpLiBBbmQgZXZlbiB3ZSBtYWtlIHRoaXMNCipwb3RlbnRpYWwgVVBEQVRFIFJGQzM4 OTEgRHJhZnQvUkZDKiwgaG93IG1heSBVQXMgd291bGQgc3VwcG9ydCBpdCwgYW5kDQpJIHRoaW5r IHRoZXJlIHN0aWxsIHdvdWxkIGJlIGEgc2VyaW91cyBpbnRlcndvcmtpbmcgaXNzdWUuPC9mb250 Pjxmb250IHNpemU9Mz4NCjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxi cj4NCjIuIFBoaWxvc29waHkgYW5kIG1ldGhvZG9sb2d5OjwvZm9udD48Zm9udCBzaXplPTM+IDwv Zm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NCkFzIHdlIGtub3csIGJhc2ljIFNJ UCBSRkNzKHN0YW5kYXJkIHRyYWNrKSBvbmx5IGRlZmluZSBydWxlcyBhYm91dCBVQUMvVUFTDQph bmQgcHJveHkuIFRoZXJlJ3Mgbm8gbm9ybWF0aXZlIGRlZmluaXRpb24gYWJvdXQgQjJCVUEoUkZD MzcyNSBpcyBCQ1AgbGV2ZWwpLg0KSW4gZmFjdCwgQjJCVUEgaXMgaW1wbGVtZW50YXRpb24gbGV2 ZWwgdXNhZ2Ugb2Ygc3RhbmRhcmQgdHJhY2sgU0lQIFJGQ3MuPC9mb250Pjxmb250IHNpemU9Mz4N CjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQXJpYWwiPjxicj4NClNvLCBJIGRvbid0IHRoaW5r IGl0IGlzIGFwcHJvcHJpYXRlIHRvIHVzZSBCMkJVQSdzIGltcGxlbWVudGF0aW9uIGxldmVsDQpw cm9ibGVtIGFzIHJlYXNvbiBmb3IgZGVtYW5kaW5nIHN0YW5kYXJkIHRyYWNrIFNJUCBSRkMncyBj b3JyZWN0aW9uLjwvZm9udD48Zm9udCBzaXplPTM+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0y IGZhY2U9IkFyaWFsIj48YnI+DQpUaGFua3MsPC9mb250Pjxmb250IHNpemU9Mz4gPGJyPg0KPC9m b250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KR2FvPC9mb250Pjxmb250IHNpemU9 Mz4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJBcmlhbCI+PGJyPg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQpaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEy PGJyPg0KVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KVGVsMiAmbmJzcDsgOigrODYpLTAy NS01Mjg3NzIxMTxicj4NCmVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8 L2ZvbnQ+DQo8cD4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lk dGg9NDUlPjxmb250IHNpemU9MSBmYWNlPSJBcmlhbCI+PGI+SGFkcmllbCBLYXBsYW4gJmx0O0hL YXBsYW5AYWNtZXBhY2tldC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZh Y2U9IkFyaWFsIj4yMDEwLTA3LTA3IDE4OjAzPC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pg0K PHRkIHdpZHRoPTU0JT4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQgd2lkdGg9MTElPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTE+ytW8/sjLPC9m b250PjwvZGl2Pg0KPHRkIHdpZHRoPTg4JT48Zm9udCBzaXplPTEgZmFjZT0iQXJpYWwiPiZxdW90 O2dhby55YW5nMkB6dGUuY29tLmNuJnF1b3Q7DQombHQ7Z2FvLnlhbmcyQHp0ZS5jb20uY24mZ3Q7 PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MT6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNp emU9MSBmYWNlPSJBcmlhbCI+JnF1b3Q7ZGlzcGF0Y2hAaWV0Zi5vcmcmcXVvdDsgJmx0O2Rpc3Bh dGNoQGlldGYub3JnJmd0OzwvZm9udD48Zm9udCBzaXplPTM+DQo8L2ZvbnQ+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xPtb3zOI8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj5SRTogW2Rpc3BhdGNoXSBBYm91dCBG aW5hbCBDaGFydGVyIGZvciBTZXNzaW9uLUlEOjwvZm9udD48L3RhYmxlPg0KPHA+PGZvbnQgc2l6 ZT0zPiZuYnNwOzwvZm9udD4NCjxwPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZCB3aWR0aD01MCU+DQo8dGQgd2lkdGg9NTAlPjwvdGFibGU+DQo8YnI+PC90 YWJsZT4NCjxwPjxmb250IHNpemU9Mz48YnI+DQo8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNv bG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPjxicj4NCkdhbyw8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPjxicj4NCkhhdmUg eW91IHRha2VuIGEgbG9vayBhdCB0aGUgZW1haWwgdGhyZWFkIGFib3V0IHNlc3Npb24taWQgYW5k IGRpYWxvZy1tYXRjaGluZywNCnN0YXJ0aW5nIGF0IHRoZSBmb2xsb3dpbmcgZW1haWwgbWVzc2Fn ZT86PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1 Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL2Rpc3BhdGNoL2N1cnJlbnQvbXNnMDE2NTguaHRtbCI+PGZvbnQgc2l6ZT0yIGNvbG9y PWJsdWUgZmFjZT0iQXJpYWwiPjx1Pmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dl Yi9kaXNwYXRjaC9jdXJyZW50L21zZzAxNjU4Lmh0bWw8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTM+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPjxicj4N CkkgdGhpbmsgYSByZXBsYWNlcyB1c2FnZSB3b3VsZCBoYXZlIHRoZSBzYW1lIGlzc3Vlcy48L2Zv bnQ+PGZvbnQgc2l6ZT0zPg0KPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9 IkFyaWFsIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQXJpYWwiPjxicj4NCi1oYWRyaWVsPC9mb250Pjxmb250 IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkFyaWFsIj48 YnI+DQogPC9mb250Pjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGNvbG9y PSMwMDAwODAgZmFjZT0iQXJpYWwiPjxicj4NCiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwv Zm9udD4NCjxkaXYgYWxpZ249Y2VudGVyPg0KPHA+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD4N CjxwPg0KPGhyPjwvZGl2Pg0KPHA+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+PGI+PGJyPg0K RnJvbTo8L2I+IGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaXNwYXRjaC1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5nYW8ueWFuZzJAenRlLmNvbS5jbjxi Pjxicj4NClNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkgMDcsIDIwMTAgMTo0NCBBTTxiPjxicj4N ClRvOjwvYj4gSGFkcmllbCBLYXBsYW48Yj48YnI+DQpDYzo8L2I+IGRpc3BhdGNoQGlldGYub3Jn PGI+PGJyPg0KU3ViamVjdDo8L2I+IFJlOiBbZGlzcGF0Y2hdIEFib3V0IEZpbmFsIENoYXJ0ZXIg Zm9yIFNlc3Npb24tSUQ6PC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48YnI+DQogPC9mb250Pjxmb250IHNpemU9Mz4mbmJzcDs8 L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQo8YnI+DQpIaSBIYWRy aWVsLDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250Pjxm b250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KPGJyPg0KJmd0OyBSaWdodCwgbXkg aW50ZW50aW9uIHdhcyB0byBOT1QgaW1wYWN0L2FmZmVjdC9pbmNsdWRlIGRpYWxvZy08YnI+DQom Z3Q7IG1hdGNoaW5nLCBvciBhbnl0aGluZyBidXQgdHJvdWJsZXNob290aW5nLiAmbmJzcDs8L2Zv bnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQo8YnI+DQpUaGlzIGlzIG15IHVuZGVyc3RhbmRp bmcgb2YgdGhlIGNoYXJ0ZXIgYW5kIHRoZSB0ZXh0LiBUaGVuLCBJIGFtIHJpZ2h0DQphdCB0aGlz IHBvaW50LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4gPC9mb250 Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KPGJyPg0KJmd0OyBCdXQgb2Yg Y291cnNlIGEgY2hhcnRlciA8YnI+DQomZ3Q7IGFuZCBXRyBpcyBhIGNvbnNlbnN1cy1iYXNlZCBk ZWNpc2lvbiwgbm90IG1pbmUsIHNvIGlmIG90aGVycyBmZWVsDQo8YnI+DQomZ3Q7IHRoZXkgd2Fu dCBtb3JlIHRoZXkgY2FuIGFyZ3VlIGZvciBpdC48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 YnI+DQo8YnI+DQpRdWl0IHRydWUuIEFuZCBJIHdpbGwgc2VlayB0aW1lIHRvIG1ha2UgYSBtb3Jl IGRldGFpbGVkIGRpc2N1c3Npb24gZm9yDQp0aGlzIHRvcGljLiBBbmQgSSBob3BlIHBlb3BsZSB3 aG8gY2FyZSBhYm91dCAmcXVvdDtyZXBsYWNlIGhlYWRlcidzIGRpYWxvZy1tYXRjaGluZw0KcHJv YmxlbSZxdW90OyBqb2luIGluIHRoaXMgZGlzY3Vzc2lvbiB0aGVuLjwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxicj4NCjxicj4NCkdhbzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0K PGJyPg0KJmd0OyAtaGFkcmllbDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJv bWFuIj4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KJmd0OyAm bmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48 Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgJm5ic3A7PC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZh Y2U9IkNvdXJpZXIgTmV3Ij48YnI+DQomZ3Q7IDxicj4NCiZndDsgRnJvbTogZ2FvLnlhbmcyQHp0 ZS5jb20uY24gW21haWx0bzpnYW8ueWFuZzJAenRlLmNvbS5jbl0gPGJyPg0KJmd0OyBTZW50OiBU dWVzZGF5LCBKdW5lIDI5LCAyMDEwIDk6MDggUE08YnI+DQomZ3Q7IFRvOiBkaXNwYXRjaEBpZXRm Lm9yZzxicj4NCiZndDsgQ2M6IEhhZHJpZWwgS2FwbGFuPGJyPg0KJmd0OyBTdWJqZWN0OiBBYm91 dCBGaW5hbCBDaGFydGVyIGZvciBTZXNzaW9uLUlEOjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXci Pjxicj4NCiZndDsgJm5ic3A7PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQomZ3Q7IDxi cj4NCiZndDsgSGksIDxicj4NCiZndDsgPGJyPg0KJmd0OyBCeSB0aGUgY2hhcnRlciBhbmQgdGhl IG9yaWdpbmFsIHRleHQgbmFtZWQgZHJhZnQta2FwbGFuLXNpcC1zZXNzaW9uLTxicj4NCiZndDsg aWQtMDIsIHRoaXMgd29yayBpcyBqdXN0IGZvY3VzZWQgb24gdHJvdWJsZXNob290aW5nIHVzYWdl LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQnV0IEkgd2FzIHRvbGQgdGhhdCAqc29tZW9uZSogd2Fu dCB0byB1c2UgdGhpcyBzZXNzaW9uLWlkIGluIFJlcGxhY2U8YnI+DQomZ3Q7IGhlYWRlciB1c2Fn ZSwgdG8gZG8gZGlhbG9nLW1hdGNoaW5nLiBJIHRoaW5rIHRoaXMgd291bGQgYmUgVVBEQVRFDQpv ZiBSRkMzODkxLjxicj4NCiZndDsgPGJyPg0KJmd0OyBTbywgSSdkIGxpa2UgdG8gY29uZmlybSB0 aGF0IHRoaXMgY2hhcnRlciBhbmQgY29taW5nIGRyYWZ0IHdvdWxkIG5vdDxicj4NCiZndDsgZG8g c3VjaCB0aGluZyBub3JtYXRpdmVseS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcywgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEdhbyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7IFppcCAmbmJzcDsgJm5ic3A7OiAyMTAw MTI8YnI+DQomZ3Q7IFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiZndDsgVGVsMiAmbmJz cDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiZndDsgZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5j b20uY248YnI+DQomZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPg0KPC9mb250Pjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KJmd0OyAmbmJzcDs8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQomZ3Q7IFpU RSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcw0KPGJyPg0KJmd0OyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVy J3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgPGJyPg0KJmd0OyBjb21tdW5pY2F0aW9uIGlzIGNv bmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkDQo8YnI+DQom Z3Q7IHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3Nl IHRoZSBjb250ZW50cw0KPGJyPg0KJmd0OyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJz LjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9u dCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgVGhpcyBlbWFpbCBhbmQgYW55 IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQNCjxicj4NCiZn dDsgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0 eSB0byB3aG9tIHRoZXk8YnI+DQomZ3Q7IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIDxicj4NCiZndDsgbm90aWZ5IHRoZSBvcmln aW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMNCjxicj4N CiZndDsgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxicj4NCiZndDsgVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5u ZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbQ0Kc3lzdGVtLjwvZm9udD48 Zm9udCBzaXplPTM+IDwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxicj4N CiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPiZuYnNwOzwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPC9mb250Pjxmb250IHNpemU9Mz4NCjwvZm9udD48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxicj4NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6 IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsDQppcyBzb2xlbHkgcHJvcGVy dHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24N CmlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRv IG1haW50YWluIHNlY3JlY3kNCmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUg Y29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvDQpvdGhlcnMuPC9mb250Pjxmb250IHNp emU9Mz4gPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PGJyPg0KVGhpcyBl bWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBh bmQgaW50ZW5kZWQNCnNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRp dHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YNCnRoZSBtZXNz YWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhl IGluZGl2aWR1YWwNCnNlbmRlci48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48YnI+DQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5l ZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS48L2ZvbnQ+PGZv bnQgc2l6ZT0zPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz4mbmJzcDs8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0zPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPC9mb250Pg0KPGJyPjxmb250IHNpemU9Mz5aVEU8L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4gPC9mb250Pjxmb250IHNpemU9Mz5JbmZvcm1hdGlvbjwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9 Mz5TZWN1cml0eTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0zPk5vdGljZTo8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3 Ij4NCjwvZm9udD48Zm9udCBzaXplPTM+VGhlPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3Vy aWVyIE5ldyI+IDwvZm9udD48Zm9udCBzaXplPTM+aW5mb3JtYXRpb248L2ZvbnQ+PGZvbnQgc2l6 ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTM+Y29udGFpbmVkPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+IDwvZm9udD48Zm9udCBzaXplPTM+ aW48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBz aXplPTM+dGhpczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPiA8L2ZvbnQ+ PGZvbnQgc2l6ZT0zPm1haWw8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4N CjwvZm9udD48Zm9udCBzaXplPTM+aXM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIg TmV3Ij4gPC9mb250Pjxmb250IHNpemU9Mz5zb2xlbHk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTM+cHJvcGVydHk8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4gPC9mb250Pjxmb250IHNpemU9Mz5vZjwvZm9udD48 Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9Mz50aGU8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4gPC9mb250Pjxmb250IHNpemU9 Mz5zZW5kZXInczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250 Pjxmb250IHNpemU9Mz5vcmdhbml6YXRpb24uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3Vy aWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPlRoaXM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZh Y2U9IkNvdXJpZXIgTmV3Ij4gPC9mb250Pjxmb250IHNpemU9Mz5tYWlsPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPmNvbW11bmljYXRp b248L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBz aXplPTM+aXM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4gPC9mb250Pjxm b250IHNpemU9Mz5jb25maWRlbnRpYWwuPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVy IE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPlJlY2lwaWVudHM8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IkNvdXJpZXIgTmV3Ij4gPC9mb250Pjxmb250IHNpemU9Mz5uYW1lZDwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9Mz5hYm92ZTwv Zm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0z PmFyZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250 IHNpemU9Mz5vYmxpZ2F0ZWQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4g PC9mb250Pjxmb250IHNpemU9Mz50bzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBO ZXciPg0KPC9mb250Pjxmb250IHNpemU9Mz5tYWludGFpbjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iQ291cmllciBOZXciPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPnNlY3JlY3k8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTM+YW5kPC9mb250 Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+IDwvZm9udD48Zm9udCBzaXplPTM+YXJl PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6 ZT0zPm5vdDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPiA8L2ZvbnQ+PGZv bnQgc2l6ZT0zPnBlcm1pdHRlZDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXci Pg0KPC9mb250Pjxmb250IHNpemU9Mz50bzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmll ciBOZXciPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPmRpc2Nsb3NlPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPnRoZTwvZm9udD48Zm9udCBz aXplPTMgZmFjZT0iQ291cmllciBOZXciPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPmNvbnRlbnRzPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0z Pm9mPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+IDwvZm9udD48Zm9udCBz aXplPTM+dGhpczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250 Pjxmb250IHNpemU9Mz5jb21tdW5pY2F0aW9uPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3Vy aWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPnRvPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJDb3VyaWVyIE5ldyI+IDwvZm9udD48Zm9udCBzaXplPTM+b3RoZXJzLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTM+VGhpczwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPiA8 L2ZvbnQ+PGZvbnQgc2l6ZT0zPmVtYWlsPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVy IE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPmFuZDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0i Q291cmllciBOZXciPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPmFueTwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9Mz5maWxlczwvZm9udD48Zm9u dCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPnRyYW5zbWl0 dGVkPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQg c2l6ZT0zPndpdGg8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4gPC9mb250 Pjxmb250IHNpemU9Mz5pdDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0K PC9mb250Pjxmb250IHNpemU9Mz5hcmU8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIg TmV3Ij4gPC9mb250Pjxmb250IHNpemU9Mz5jb25maWRlbnRpYWw8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTM+YW5kPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+IDwvZm9udD48Zm9udCBzaXplPTM+aW50ZW5kZWQ8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXpl PTM+c29sZWx5PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+IDwvZm9udD48 Zm9udCBzaXplPTM+Zm9yPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8 L2ZvbnQ+PGZvbnQgc2l6ZT0zPnRoZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBO ZXciPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPnVzZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291 cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9Mz5vZjwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iQ291cmllciBOZXciPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPnRoZTwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9Mz5pbmRpdmlkdWFsPC9m b250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+IDwvZm9udD48Zm9udCBzaXplPTM+ b3I8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBz aXplPTM+ZW50aXR5PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+IDwvZm9u dD48Zm9udCBzaXplPTM+dG88L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4N CjwvZm9udD48Zm9udCBzaXplPTM+d2hvbTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmll ciBOZXciPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPnRoZXk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTM+YXJlPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJDb3VyaWVyIE5ldyI+IDwvZm9udD48Zm9udCBzaXplPTM+YWRkcmVzc2VkLjwvZm9u dD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9Mz5J ZjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zPnlvdTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxm b250IHNpemU9Mz5oYXZlPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+IDwv Zm9udD48Zm9udCBzaXplPTM+cmVjZWl2ZWQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJp ZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTM+dGhpczwvZm9udD48Zm9udCBzaXplPTMgZmFj ZT0iQ291cmllciBOZXciPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPmVtYWlsPC9mb250Pjxmb250IHNp emU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPmluPC9mb250Pjxm b250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+IDwvZm9udD48Zm9udCBzaXplPTM+ZXJyb3I8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXpl PTM+cGxlYXNlPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+IDwvZm9udD48 Zm9udCBzaXplPTM+bm90aWZ5PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+ DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPnRoZTwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmll ciBOZXciPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPm9yaWdpbmF0b3I8L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTM+b2Y8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4gPC9mb250Pjxmb250IHNpemU9Mz50aGU8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTM+bWVz c2FnZS48L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4gPC9mb250Pjxmb250 IHNpemU9Mz5Bbnk8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9u dD48Zm9udCBzaXplPTM+dmlld3M8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3 Ij4gPC9mb250Pjxmb250IHNpemU9Mz5leHByZXNzZWQ8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTM+aW48L2ZvbnQ+PGZvbnQgc2l6ZT0z IGZhY2U9IkNvdXJpZXIgTmV3Ij4gPC9mb250Pjxmb250IHNpemU9Mz50aGlzPC9mb250Pjxmb250 IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPm1lc3NhZ2U8 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4gPC9mb250Pjxmb250IHNpemU9 Mz5hcmU8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9u dCBzaXplPTM+dGhvc2U8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4gPC9m b250Pjxmb250IHNpemU9Mz5vZjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXci Pg0KPC9mb250Pjxmb250IHNpemU9Mz50aGU8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJp ZXIgTmV3Ij4gPC9mb250Pjxmb250IHNpemU9Mz5pbmRpdmlkdWFsPC9mb250Pjxmb250IHNpemU9 MyBmYWNlPSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPnNlbmRlci48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0zPlRoaXM8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIg TmV3Ij4gPC9mb250Pjxmb250IHNpemU9Mz5tZXNzYWdlPC9mb250Pjxmb250IHNpemU9MyBmYWNl PSJDb3VyaWVyIE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPmhhczwvZm9udD48Zm9udCBzaXpl PTMgZmFjZT0iQ291cmllciBOZXciPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0zPmJlZW48L2ZvbnQ+PGZv bnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXplPTM+c2Nhbm5l ZDwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPiA8L2ZvbnQ+PGZvbnQgc2l6 ZT0zPmZvcjwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxm b250IHNpemU9Mz52aXJ1c2VzPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIE5ldyI+ IDwvZm9udD48Zm9udCBzaXplPTM+YW5kPC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVy IE5ldyI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0zPlNwYW08L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9 IkNvdXJpZXIgTmV3Ij4gPC9mb250Pjxmb250IHNpemU9Mz5ieTwvZm9udD48Zm9udCBzaXplPTMg ZmFjZT0iQ291cmllciBOZXciPg0KPC9mb250Pjxmb250IHNpemU9Mz5aVEU8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4gPC9mb250Pjxmb250IHNpemU9Mz5BbnRpLVNwYW08 L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIgTmV3Ij4NCjwvZm9udD48Zm9udCBzaXpl PTM+c3lzdGVtLjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9u Jm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJz cDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xl bHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdh bml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMm bmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUm bmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVj eSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7 ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2Nv bW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2Fu ZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQm bmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3Nv bGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZu YnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDty ZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVh c2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4m bmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDto YXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQm bmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8 L3ByZT4= --=_alternative 0040FAD948257759_=-- From gao.yang2@zte.com.cn Wed Jul 7 05:41:49 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD6C93A6814 for ; Wed, 7 Jul 2010 05:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.021 X-Spam-Level: X-Spam-Status: No, score=-98.021 tagged_above=-999 required=5 tests=[AWL=3.816, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMAMd7Fmq7jd for ; Wed, 7 Jul 2010 05:41:47 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id E95873A67B6 for ; Wed, 7 Jul 2010 05:41:46 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 55234992332426; Wed, 7 Jul 2010 20:40:27 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 83990.1120268331; Wed, 7 Jul 2010 20:41:41 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o67CXUjd034050; Wed, 7 Jul 2010 20:39:57 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: "Muthu ArulMozhi Perumal (mperumal)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 7 Jul 2010 20:22:09 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-07 20:39:41, Serialize complete at 2010-07-07 20:39:41 Content-Type: multipart/alternative; boundary="=_alternative 0044339F48257759_=" X-MAIL: mse2.zte.com.cn o67CXUjd034050 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 12:41:50 -0000 This is a multipart message in MIME format. --=_alternative 0044339F48257759_= Content-Type: text/plain; charset="US-ASCII" As Muthu just shared his point in my thread, then I read this thread just now. Some comments: 1. I'd like to see this work going on, as SBC is really luck of guidelines. 2. It is meaningful to emphasize e2e philosophy/methodology for any B2BUA equipment, including SBC. Though this looks like well known rule. But comsidering SBC industry actuality, it is meaningful then. Suggesting about the *potential* WG: 1. BCP level guidelines for SBC's usage of e2e defined SIP RFCs; 2. Informational/standard track solutioion draft/RFCs for RFC5853. And I also suggest you to consult RFC5853's authors's viewpoints. Thanks, Gao [dispatch] Should IETF have a BEHAVE WG for SBCs? From: "Muthu ArulMozhi Perumal (mperumal)" To: "DISPATCH list" Date: Thu, 1 Jul 2010 22:57:10 +0530 In the past few years there has been a proliferation of Session Border Controller (SBC) deployments in SIP networks mainly because the development of SIP protocol specifications hasn't been able to keep in pace with industry and operator requirements. The common functions they perform and the architectural issues they introduce are described in RFC-5853. Due to lack of well defined guidelines and best current practices many SBC implementations break end-to-end features and introduce problems that are difficult to troubleshoot, many a times because of poor implementations rather than to meet any specific requirements. For example, when they do media processing they assume everything coming on the media channel is RTP, don't do even basic RTP header validations as recommended in RFC-3550, try to decode STUN and DTLS packets as RTP corrupting them and making them useless. I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to the one for NATs, to set guidelines and identify best current practices to encourage better SBC implementations, interoperability and ease of troubleshooting, rather than just keeping quiet and letting them go out of control. Comments? Muthu =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0044339F48257759_= Content-Type: text/html; charset="US-ASCII"
As Muthu just shared his point in my thread, then I read this thread just now. Some comments:

1. I'd like to see this work going on, as SBC is really luck of guidelines.

2. It is meaningful to emphasize e2e philosophy/methodology for any B2BUA equipment, including SBC. Though this looks like well known rule. But comsidering SBC industry actuality, it is meaningful then.

Suggesting about the *potential* WG:
1. BCP level guidelines for SBC's usage of e2e defined SIP RFCs;
2. Informational/standard track solutioion draft/RFCs for RFC5853.

And I also suggest you to consult RFC5853's authors's viewpoints.

Thanks,

Gao


[dispatch] Should IETF have a BEHAVE WG for SBCs?
In the past few years there has been a proliferation of Session Border Controller (SBC) deployments in SIP networks mainly because the development of SIP protocol specifications hasn't been able to keep in pace with industry and operator requirements. The common functions they perform and the architectural issues they introduce are described in RFC-5853.

 

Due to lack of well defined guidelines and best current practices many SBC implementations break end-to-end features and introduce problems that are difficult to troubleshoot, many a times because of poor implementations rather than to meet any specific requirements. For example, when they do media processing they assume everything coming on the media channel is RTP, don't do even basic RTP header validations as recommended in RFC-3550, try to decode STUN and DTLS packets as RTP corrupting them and making them useless.

 

I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to the one for NATs, to set guidelines and identify best current practices to encourage better SBC implementations, interoperability and ease of troubleshooting, rather than just keeping quiet and letting them go out of control.

 

Comments?

 

Muthu




===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0044339F48257759_=-- From fluffy@cisco.com Wed Jul 7 09:22:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B498D3A679F for ; Wed, 7 Jul 2010 09:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV-XEWAiJp52 for ; Wed, 7 Jul 2010 09:22:54 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id ACD6D3A65A6 for ; Wed, 7 Jul 2010 09:22:54 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,554,1272844800"; d="scan'208";a="266086268" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 07 Jul 2010 16:22:58 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o67GMva8010142; Wed, 7 Jul 2010 16:22:57 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> Date: Wed, 7 Jul 2010 10:22:56 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8F5532A2-7017-48B2-897F-6FA6E50EE68A@cisco.com> References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> To: Muthu ArulMozhi Perumal (mperumal) X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 16:22:55 -0000 We had a BOF on pretty much this topic. Some people wrote drafts. There = was pretty much no energy to even send comments on it and it was hard to = find authors. It was eventually published as RFC 5853 and we all need to = give Jani Hautakorpi a big thanks for that.=20 The whole experience around 5843 does left me thinking that it was = better to consider B2BUA in any draft and effected any type of UA = including B2BUA. When we ask the question "should we make SBC = interoperate better" we get a resounding yes from everyone. When asked = so what do we need to change to make that happen we get a resounding = "might do that some of the time but certainly not all the time from the = SBC vendors". I like the idea of finding specific addressable problems = such as Hadriels session-id stuff then going and figuring out how to fix = that problem. If there are other specific problems that can be fixed, by = all means write some drafts and get some proposals on the table.=20 On Jul 1, 2010, at 11:27 AM, Muthu ArulMozhi Perumal (mperumal) wrote: > In the past few years there has been a proliferation of Session Border = Controller (SBC) deployments in SIP networks mainly because the = development of SIP protocol specifications hasn't been able to keep in = pace with industry and operator requirements. The common functions they = perform and the architectural issues they introduce are described in = RFC-5853. > =20 > Due to lack of well defined guidelines and best current practices many = SBC implementations break end-to-end features and introduce problems = that are difficult to troubleshoot, many a times because of poor = implementations rather than to meet any specific requirements. For = example, when they do media processing they assume everything coming on = the media channel is RTP, don't do even basic RTP header validations as = recommended in RFC-3550, try to decode STUN and DTLS packets as = RTPcorrupting them and making them useless. > =20 > I am wondering whether IETF should have a BEHAVE WG for SBCs, similar = to the one for NATs, to set guidelines and identify best current = practices to encourage better SBC implementations, interoperability and = ease of troubleshooting, rather than just keeping quiet and letting them = go out of control. > =20 > Comments? > =20 > Muthu > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed Jul 7 09:40:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39BF3A67E5 for ; Wed, 7 Jul 2010 09:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.299 X-Spam-Level: X-Spam-Status: No, score=-109.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juJJqkCOSbTp for ; Wed, 7 Jul 2010 09:40:41 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id DA0543A65A6 for ; Wed, 7 Jul 2010 09:40:41 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHNLNEyrRN+K/2dsb2JhbACgEnGnAppsgluCSQSDH1mERQ X-IronPort-AV: E=Sophos;i="4.53,554,1272844800"; d="scan'208";a="229610484" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 07 Jul 2010 16:40:42 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o67GeeWe020055 for ; Wed, 7 Jul 2010 16:40:41 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com> Date: Wed, 7 Jul 2010 10:40:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com> To: DISPATCH list X-Mailer: Apple Mail (2.1081) Subject: Re: [dispatch] Charter for Telepresence multi-streams - third version X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 16:40:43 -0000 I'm wondering if we could get a thread going about what are some of the = specific problems we need to solve then dispatch theses problems to = appropriate WGs.=20 For example one problem is when a session involves two video session on = multiple screens how does one signal which stream is displayed on the = right and left screen.=20 I think having a list of specific problems would help get this moving = faster.=20 Cullen =20 On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote: > Folks, > This makes the change discussed replacing the text in the third = paragraph under the Charter section with the text suggested on the list. > It also changes title from =93=85 Description of Work=94 to =93=85Charte= r=94 > =20 > There weren=92t any further changes suggested. > =20 > Thanks, > Allyn > =20 > =20 > =20 > =20 > Multi-streams for Telepresence Charter > =20 > =20 > =20 > Background > One branch of video conferencing has evolved that is focused on = immersive =93being there=94 experience. Referred to in various ways = such as virtual conferencing, telepresence or media spaces, early = systems were mainly research projects or business systems with limited = deployments. In recent years telepresence systems have seen = considerable market success. Following the model of early systems, the = first wave of commercial systems have been typically located in = specially designed single-purpose rooms with multiple relatively large = displays permitting life size image reproduction, multiple cameras, = encoders, decoders and microphones. These systems have several = important characteristics that are different from more traditional video = conferencing systems.=20 > =20 > The first difference concerns controlling the visual viewpoint in = order to improve participant nonverbal communication. These systems = preserve essential group meeting characteristics such as eye contact, = group gestures, seating order and spatial audio by carefully = orchestrating the miking and camera angles at each of the sites . This = is distinct from the more traditional approach where the geometric = relationship between media streams is not used to preserve inter-stream = communication aspects such as eye contact and group dynamics.=20 > =20 > A second difference is manipulation of the environment to improve = immersion. With telepresence systems, cinematographic aspects of the = local environment reproduction are carefully planned including color, = table shape, seating and lighting so that when combined with large high = quality displays, a strong sense of a "trompe l'oeil" or "being there" = immersive experience is created. Typical video conference systems do = not include these considerations. > =20 > As telepresence video systems have become successful in the market, = manufacturers have started exploring delivery of the nonverbal = communication and immersive values of telepresence via smaller, less = expensive and more flexible video conferencing systems for a variety of = venues, such as individual offices, homes and kiosks. These are also = telepresence systems, since the audio and video quality is high enough = to allow clear image reproduction for nonverbal communication, they are = able to send and receive multiple media streams, and large coordinated = multi image displays are available for immersive installations. As the = industry develops, the line between telepresence and video conferencing = may become blurred as nonverbal communication and immersive = installations become broadly available. > =20 > Problem > Although telepresence systems are based on open standards such as RTP, = SIP, H.264, H.323 suite, they cannot easily interoperate with each other = without operator assistance and expensive additional equipment that = translates from one vendor to another. It would be like having to make = sure all parties are on the same equipment (and network) when making a = telephone call. A major factor in the inability of Telepresence systems = to work with each other is that there is no standard description of the = multiple streams that comprise the media flows. > =20 > For example, in a multiple screen conference, the video and audio = streams sent from remote participants must be understood by receivers so = that they can be presented in a coherent and life-like manner. This = includes the ability to present the remote participants at their true = size for their apparent distance, while maintaining correct eye contact, = gesticular cues, and simultaneously providing a spatial audio sound = stage consistent with the video presentation. The receiving device that = decides how to display the incoming information needs to understand a = number of variables such as the spatial position of the speaker, the = field of view of the cameras, the camera zoom, which media stream is = related to each of the displays, etc. > =20 > Charter > The Telepresence Multi-Streams work item in DISPATCH is chartered to = define and specify for SIP-based systems the content of media = multi-stream messages and the way these will be transported. > =20 > This work will provide a standard for the exchange of media semantic = information that will foster interoperable end stations and conference = bridges. It will specify variables that describe the semantics of the = media streams and the recommended behavior to achieve interoperability.=20= > =20 > =20 > This requires considering current widely deployed use cases, as well = as cases that are expected to be implemented using the protocol = framework produced by this work item. The methodology for describing = the variables must allow extensibility of the variables, since = telepresence is still a young technology and may have use cases that are = not currently considered." > =20 > =20 > The work item will identify use cases, define requirements, and define = a method for describing and transporting information about multiple = media streams, including a specification of variables required to = support the use cases. This work item will consider the reuse of = existing IETF protocols and produce an architecture/protocol framework = document describing the protocols required to be implemented to support = this functionality. The document will identify any enhancements = required to existing protocols as well as describing new protocol(s) for = interoperable multi-streams negotiation that may be required. > =20 > Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and = FECframe. > =20 > =20 > Scope > The scope includes both systems that provide a fully immersive = experience, and systems that interwork with them and therefore need to = understand the same multiple stream semantics. > =20 > =20 > The focus of this work is on audio and video multiple streams. Other = media types may be considered, however development of methodologies for = them is not within the scope of this work. > =20 > Interoperation with standards compliant systems is required, such as = SIP-based video conferencing systems. However, backwards compatibility = with existing non-standards compliant telepresence systems is not = required. > =20 > =20 > =20 > The group will produce > - Requirements and use cases > =20 > - Architectural Framework describing the protocols required to be = implemented to support this functionality and identifying existing = protocol enhancements and new protocol functionality required > =20 > - Specification of a new protocol to support telepresence = multi-streams [if required] > =20 > Goals and Milestones > Nov 2010 > =20 > Use Cases and Requirements to IESG as Informational RFC > Nov 2010 > March 2011 > Problem Statement to IESG as Informational RFC > Architecture to IESG as Informational RFC > March 2011 > Revise Charter [IF new protocol is not required] > Nov 2011 > Submit protocol draft to IESG as Proposed Standard RFC > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From dwing@cisco.com Wed Jul 7 12:10:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C31E3A68C7 for ; Wed, 7 Jul 2010 12:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.382 X-Spam-Level: X-Spam-Status: No, score=-10.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHtJVN5UdZ34 for ; Wed, 7 Jul 2010 12:10:32 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 03C853A684C for ; Wed, 7 Jul 2010 12:10:31 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACNuNEyrR7Hu/2dsb2JhbACUZ4srcaY8mmaCW4JJBIN4 X-IronPort-AV: E=Sophos;i="4.53,554,1272844800"; d="scan'208";a="266150544" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 07 Jul 2010 19:10:34 +0000 Received: from dwingWS ([10.21.118.57]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o67JAXo7006507; Wed, 7 Jul 2010 19:10:33 GMT From: "Dan Wing" To: "'Peter Musgrave'" , "'WORLEY, Dale R \(Dale\)'" References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> In-Reply-To: Date: Wed, 7 Jul 2010 12:10:32 -0700 Message-ID: <27fc01cb1e08$13467f70$39d37e50$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-Index: AcsZU86jRPVWPgSdTae4h/5WTKjMqQEtAUyg Cc: 'DISPATCH list' Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 19:10:33 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Peter Musgrave > Sent: Thursday, July 01, 2010 12:30 PM > To: WORLEY, Dale R (Dale) > Cc: DISPATCH list > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > I concur. > > There is some useful background in RFC5853 and perhaps > http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 > > And then some things which died on the vine such as: > http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 > and perhaps some others? http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-02 died. -d > I don't think any of these deal with RTP issues - so that would be > useful information. > > Also, treatment of ICE etc. would be of interest. > > Peter Musgrave > > > On Thu, Jul 1, 2010 at 2:56 PM, WORLEY, Dale R (Dale) > wrote: > > ________________________________________ > > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf > Of Muthu ArulMozhi Perumal (mperumal) [mperumal@cisco.com] > > > > I am wondering whether IETF should have a BEHAVE WG for SBCs, similar > to the one for NATs, to set guidelines and identify best current > practices to encourage better SBC implementations, interoperability and > ease of troubleshooting, rather than just keeping quiet and letting > them go out of control. > > ________________________________________ > > > > This is a good idea. > > > > 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 allyn@cisco.com Wed Jul 7 12:41:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76743A687D for ; Wed, 7 Jul 2010 12:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.299 X-Spam-Level: X-Spam-Status: No, score=-9.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k6JIruzYJex for ; Wed, 7 Jul 2010 12:41:12 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7C6703A6909 for ; Wed, 7 Jul 2010 12:41:11 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKh1NEyrRN+K/2dsb2JhbACgFnGmA5pmgluCSQSDH1mGcg X-IronPort-AV: E=Sophos;i="4.53,554,1272844800"; d="scan'208";a="229676024" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 07 Jul 2010 19:41:14 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o67JeXsY019067; Wed, 7 Jul 2010 19:41:14 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Jul 2010 12:41:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: Cq4r Djm/ FanX FoVD F7IV IrKL J+GV LIHQ Lh5n L9fM R25V Sky2 T994 U6gV ZYSQ ZukS; 2; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnADsAcwB0AGUAcABoAGUAbgAuAGIAbwB0AHoAawBvAEAAcABvAGwAeQBjAG8AbQAuAGMAbwBtAA==; Sosha1_v1; 7; {23BF9BDC-0F64-4F05-A784-9F519D2E7154}; YQBsAGwAeQBuAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Wed, 07 Jul 2010 19:40:52 GMT; UgBFADoAIABbAGQAaQBzAHAAYQB0AGMAaABdACAAQwBoAGEAcgB0AGUAcgAgAGYAbwByACAAVABlAGwAZQBwAHIAZQBzAGUAbgBjAGUAIABtAHUAbAB0AGkALQBzAHQAcgBlAGEAbQBzACAALQAgAHQAaABpAHIAZAB2AGUAcgBzAGkAbwBuAA== x-cr-puzzleid: {23BF9BDC-0F64-4F05-A784-9F519D2E7154} Content-class: urn:content-classes:message Date: Wed, 7 Jul 2010 12:40:52 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C333D2@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter for Telepresence multi-streams - thirdversion Thread-Index: Acsd8zzE60lnEkGRQWGh2B3EzgWESgAF9FKA References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com> From: "Allyn Romanow (allyn)" To: "Cullen Jennings (fluffy)" , "DISPATCH list" X-OriginalArrivalTime: 07 Jul 2010 19:41:02.0687 (UTC) FILETIME=[55212EF0:01CB1E0C] Cc: "Botzko, Stephen" Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 19:41:14 -0000 Hi Cullen, We just put out a problem statement draft - http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-prob-stat ement-00. The document is not complete, but we feel it is a solid beginning. It does address the example you mention. The use case doc also describes this case in some detail. http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases -00 Do you not feel that the problem statement draft can serve as a good basis for discussion of problems? Thanks, Allyn -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings (fluffy) Sent: Wednesday, July 07, 2010 9:41 AM To: DISPATCH list Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion I'm wondering if we could get a thread going about what are some of the specific problems we need to solve then dispatch theses problems to appropriate WGs.=20 For example one problem is when a session involves two video session on multiple screens how does one signal which stream is displayed on the right and left screen.=20 I think having a list of specific problems would help get this moving faster.=20 Cullen =20 On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote: > Folks, > This makes the change discussed replacing the text in the third paragraph under the Charter section with the text suggested on the list. > It also changes title from "... Description of Work" to "...Charter" > =20 > There weren't any further changes suggested. > =20 > Thanks, > Allyn > =20 > =20 > =20 > =20 > Multi-streams for Telepresence Charter > =20 > =20 > =20 > Background > One branch of video conferencing has evolved that is focused on immersive "being there" experience. Referred to in various ways such as virtual conferencing, telepresence or media spaces, early systems were mainly research projects or business systems with limited deployments. In recent years telepresence systems have seen considerable market success. Following the model of early systems, the first wave of commercial systems have been typically located in specially designed single-purpose rooms with multiple relatively large displays permitting life size image reproduction, multiple cameras, encoders, decoders and microphones. These systems have several important characteristics that are different from more traditional video conferencing systems.=20 > =20 > The first difference concerns controlling the visual viewpoint in order to improve participant nonverbal communication. These systems preserve essential group meeting characteristics such as eye contact, group gestures, seating order and spatial audio by carefully orchestrating the miking and camera angles at each of the sites . This is distinct from the more traditional approach where the geometric relationship between media streams is not used to preserve inter-stream communication aspects such as eye contact and group dynamics.=20 > =20 > A second difference is manipulation of the environment to improve immersion. With telepresence systems, cinematographic aspects of the local environment reproduction are carefully planned including color, table shape, seating and lighting so that when combined with large high quality displays, a strong sense of a "trompe l'oeil" or "being there" immersive experience is created. Typical video conference systems do not include these considerations. > =20 > As telepresence video systems have become successful in the market, manufacturers have started exploring delivery of the nonverbal communication and immersive values of telepresence via smaller, less expensive and more flexible video conferencing systems for a variety of venues, such as individual offices, homes and kiosks. These are also telepresence systems, since the audio and video quality is high enough to allow clear image reproduction for nonverbal communication, they are able to send and receive multiple media streams, and large coordinated multi image displays are available for immersive installations. As the industry develops, the line between telepresence and video conferencing may become blurred as nonverbal communication and immersive installations become broadly available. > =20 > Problem > Although telepresence systems are based on open standards such as RTP, SIP, H.264, H.323 suite, they cannot easily interoperate with each other without operator assistance and expensive additional equipment that translates from one vendor to another. It would be like having to make sure all parties are on the same equipment (and network) when making a telephone call. A major factor in the inability of Telepresence systems to work with each other is that there is no standard description of the multiple streams that comprise the media flows. > =20 > For example, in a multiple screen conference, the video and audio streams sent from remote participants must be understood by receivers so that they can be presented in a coherent and life-like manner. This includes the ability to present the remote participants at their true size for their apparent distance, while maintaining correct eye contact, gesticular cues, and simultaneously providing a spatial audio sound stage consistent with the video presentation. The receiving device that decides how to display the incoming information needs to understand a number of variables such as the spatial position of the speaker, the field of view of the cameras, the camera zoom, which media stream is related to each of the displays, etc. > =20 > Charter > The Telepresence Multi-Streams work item in DISPATCH is chartered to define and specify for SIP-based systems the content of media multi-stream messages and the way these will be transported. > =20 > This work will provide a standard for the exchange of media semantic information that will foster interoperable end stations and conference bridges. It will specify variables that describe the semantics of the media streams and the recommended behavior to achieve interoperability.=20 > =20 > =20 > This requires considering current widely deployed use cases, as well as cases that are expected to be implemented using the protocol framework produced by this work item. The methodology for describing the variables must allow extensibility of the variables, since telepresence is still a young technology and may have use cases that are not currently considered." > =20 > =20 > The work item will identify use cases, define requirements, and define a method for describing and transporting information about multiple media streams, including a specification of variables required to support the use cases. This work item will consider the reuse of existing IETF protocols and produce an architecture/protocol framework document describing the protocols required to be implemented to support this functionality. The document will identify any enhancements required to existing protocols as well as describing new protocol(s) for interoperable multi-streams negotiation that may be required. > =20 > Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and FECframe. > =20 > =20 > Scope > The scope includes both systems that provide a fully immersive experience, and systems that interwork with them and therefore need to understand the same multiple stream semantics. > =20 > =20 > The focus of this work is on audio and video multiple streams. Other media types may be considered, however development of methodologies for them is not within the scope of this work. > =20 > Interoperation with standards compliant systems is required, such as SIP-based video conferencing systems. However, backwards compatibility with existing non-standards compliant telepresence systems is not required. > =20 > =20 > =20 > The group will produce > - Requirements and use cases > =20 > - Architectural Framework describing the protocols required to be implemented to support this functionality and identifying existing protocol enhancements and new protocol functionality required > =20 > - Specification of a new protocol to support telepresence multi-streams [if required] > =20 > Goals and Milestones > Nov 2010 > =20 > Use Cases and Requirements to IESG as Informational RFC > Nov 2010 > March 2011 > Problem Statement to IESG as Informational RFC > Architecture to IESG as Informational RFC > March 2011 > Revise Charter [IF new protocol is not required] > Nov 2011 > Submit protocol draft to IESG as Proposed Standard RFC > =20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From fluffy@cisco.com Wed Jul 7 12:55:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A93753A68DD; Wed, 7 Jul 2010 12:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.019 X-Spam-Level: X-Spam-Status: No, score=-109.019 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDuT6lQi8J0u; Wed, 7 Jul 2010 12:55:21 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 7D8083A687D; Wed, 7 Jul 2010 12:55:20 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,554,1272844800"; d="scan'208";a="223066969" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 07 Jul 2010 19:55:23 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o67JtASE002993; Wed, 7 Jul 2010 19:55:14 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 7 Jul 2010 13:55:10 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2A1051E9-99DC-458C-B96B-0BE7FB4CD4C1@cisco.com> References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> <4C2A2C19.1030906@cisco.com> <4C2AE94C.4020707@ericsson.com> <617DF0128820F9458AC39149A627EE6C01A66BC2A7@MBX.dialogic.com> <4C2B8ACE.3050301@cisco.com> To: Laura Liess X-Mailer: Apple Mail (2.1081) Cc: "dispatch@ietf.org" , James Rafferty , Roland Jesske , "ietf@ietf.org" Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 19:55:23 -0000 This example is excellent - thank you for providing it. I think it is = pretty representative of other examples I have seen and I am in favor of = having solutions to use cases such as this - I'm just not seeing why = this charter is the appropriate way to do it. Given we are talking about transferring some information between UA in a = single providers network, and this information would likely be stripped = by an SBC at the edge of the network, and that different operators may = use the same code points for different things, this all seems like = something that might just be better carried in one of the existing SIP = extensibility mechanisms such as media-type out of the vendor tree. Cullen PS - I doing my best to avoid the debate on if the CSCF are proxies or = B2BUA, I view things that need to understand and even change SIP bodies = as B2BUA but regardless, I think we can both agree that CSCF can and do = look at bodies such as SDP and would work with what I proposed above.=20 On Jul 1, 2010, at 6:53 AM, Laura Liess wrote: > In the PSTN, we use the UUI field to transmit information between the > Intelligent Network (IN) system and call center agents for the > directory enquires service. Everybody in Germany who wants to ask for > the phone number of another person dials DT's directory enquires > service and is connected to a call center agent who tells him the > number he wants to know. Additionaly, only if the caller is a DT > customer, the call center agent offers to connect him to this number, > so the caller does not need to dial. For everybode else, he does not. > So the call center agent needs to get the information whether or not > the caller is a DT customer. This is done by routing every directory > enquires call to the IN system first. The IN system checks the caller > number and inserts the information about whether or not the caller is > a DT-customer in the UUI field which is transmited via INAP, ISUP and > DSS1 to the call center agent's end device.The call center agent gets > a display about this. During the PSTN-migration to SIP, we will have > cases where the call center and the IN system are connected to > different networks, one to PSTN and the other to SIP. Also, we may > have applications as above on pure SIP application servers. >=20 >> Can you shed some light on *how* this is used, given the lack of any >> standards on the content/formatting of this information? >=20 > The application is DT-specific and needs a DT specification to be > supported by the IN system and the call center, but the container to > transport the information must be supported by both ends and by the > network nodes. >=20 >> Or is this only used between a caller and a callee that have somehow >> obtained contextual information that they both support this feature = *and* a >> particular encoding? >=20 > At least within the DT network, UUI is used between application > servers or application servers and "special" end devices as call > centers. As far as I know, UUI is currently not part of the DT normal > telephony package. Many years ago, it was, but people misused it. >=20 > We plan to use the "Johnston uui draft" for the scenario described > above and we see the need for the proposed WG. >=20 > Thanks a lot > Laura >=20 >=20 > Laura >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > 2010/6/30 Paul Kyzivat : >> James, >>=20 >> Can you shed some light on *how* this is used, given the lack of any >> standards on the content/formatting of this information? >>=20 >> Do you use content=3Disdn-uui and some particular Q.931 protocol = discriminator >> for which there are formatting standards? >>=20 >> Or is this only used between a caller and a callee that have somehow >> obtained contextual information that they both support this feature = *and* a >> particular encoding? >>=20 >> Thanks, >> Paul >>=20 >> James Rafferty wrote: >>>=20 >>> Hi, >>> My company has had the experience of deploying the pre-standard = version of >>> this PSTN to SIP UUI mechanism during the past 2 years. >>> As noted in the draft charter, UUI information is widely used on the = PSTN >>> for applications such as offering input data into call centers and = then >>> preserving that data as calls get transferred. >>> Since many contact centers are now built using SIP, but still have = PSTN >>> subscribers (via SS7 ISUP or ISDN PRI), there is a need to be able = to >>> interwork the user to user information from the PSTN side into SIP. = In our >>> experience, the "Johnston uui draft" has accomplished this and we = have >>> several customers that find this interworking to be valuable. We = also noted >>> improvements from early drafts into the later ones in areas such as = making >>> better use of the ITU-T protocol discriminator, thus enabling better >>> interoperability from the PSTN side into SIP. >>> The major deficiency of the current draft is its non-standard = status. >>> Functionally, we and our customers find this mechanism to be very = useful and >>> I'd very much like the IETF to charter the a UUI work group to = standardize >>> such a mechanism. >>> James -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On >>> Behalf Of Gonzalo Camarillo >>> Sent: Wednesday, June 30, 2010 2:51 AM >>> To: Paul Kyzivat >>> Cc: dispatch@ietf.org; DRAGE, Keith (Keith); ietf@ietf.org >>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP >>> (cuss) >>>=20 >>> Hi, >>>=20 >>> please keep both the IETF and the DISPATCH mailing lists in the >>> recipients list in this discussion. >>>=20 >>> Cheers, >>>=20 >>> Gonzalo >>>=20 >>>=20 >>> On 29/06/2010 8:23 PM, Paul Kyzivat wrote: >>>>=20 >>>> DRAGE, Keith (Keith) wrote: >>>>>=20 >>>>> The UUI information is NOT ISUP. It is a transparent envelope to = the >>>>> entire ISDN, so it is not part of an ISDN protocol and therefore = not part of >>>>> an ISUP protocol. When carried by ISUP the envelope is bundled up = in another >>>>> envelope with other information that ISUP carries transparently. >>>>>=20 >>>>> So I believe, and have said repeatedly in the past, that = references to >>>>> SIP-T are irrelevant in this case. >>>>>=20 >>>>> The problem we do have though is that are legacy usages of this >>>>> information. In particular applications in PBXs carry it between = themselves >>>>> in ISDN call establishment. The information itself is not = standardised. If >>>>> you want to migrate a PBX from DSS1 to SIP, then you have to take = this >>>>> information into account. The desire is not for a WG group to = standardise >>>>> this existing usage (which in my view would be a complete = non-starter), but >>>>> to allow the transfer of the existing information when migrated to = a SIP >>>>> environment. The information transferred does not form part of = SIP, and >>>>> should not be standardised as part of SIP. >>>>=20 >>>> How many different mechanisms do we have to construct for the = purpose of >>>> tunneling stuff over SIP? >>>>=20 >>>> Its especially bad if the stuff is neither standardized nor = negotiated. >>>> It then just provides more opportunity for non-interoperability. >>>>=20 >>>> It had been my impression that this content was standardized by = ITU. >>>> If nobody can bother to standardize it, then it hardly seems worth >>>> working on. >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>>> regards >>>>>=20 >>>>> Keith >>>>>=20 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of >>>>>> bruno.chatras@orange-ftgroup.com >>>>>> Sent: Tuesday, June 29, 2010 1:00 PM >>>>>> To: Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org >>>>>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI >>>>>> for SIP (cuss) >>>>>>=20 >>>>>> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 >>>>>> does state that SIP-T does not come into play when there is >>>>>> no PSTN involved. >>>>>>=20 >>>>>> At the end of clause 2 we can read the following: "4. IP >>>>>> origination - IP termination: This is a case for pure SIP. >>>>>> SIP-T (either encapsulation or translation of ISUP) does not >>>>>> come into play as there is no PSTN interworking." >>>>>>=20 >>>>>> Besides, SIP-T would require encapsulating a full ISUP >>>>>> message (e.g. IAM) while we are interested in just one >>>>>> parameter of the message in the context of CUSS. This would I >>>>>> believe be a more severe drawback if SIP-T were used for this = purpose. >>>>>>=20 >>>>>> Bruno >>>>>>=20 >>>>>>=20 >>>>>>> -----Message d'origine----- >>>>>>> De : dispatch-bounces@ietf.org >>>>>>> [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo = Camarillo >>>>>>> Envoy=E9 : mardi 29 juin 2010 13:03 =C0 : DISPATCH Objet : >>>>>>=20 >>>>>> [dispatch] Fwd: >>>>>>>=20 >>>>>>> Re: WG Review: Call Control UUI for SIP (cuss) >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> FYI: note the discussion below on the IETF general list. >>>>>>>=20 >>>>>>> Cheers, >>>>>>>=20 >>>>>>> Gonzalo >>>>>>>=20 >>>>>>> -------- Original Message -------- >>>>>>> Subject: Re: WG Review: Call Control UUI for SIP (cuss) >>>>>>> Date: Mon, 28 Jun 2010 20:24:23 +0200 >>>>>>> From: Cullen Jennings >>>>>>> To: iesg@ietf.org >>>>>>> CC: IETF Discussion Mailing List >>>>>>>=20 >>>>>>>=20 >>>>>>> As far as I can tell, the WG says they wants to transfer some >>>>>>> information to achieve cross vendor interoperability. >>>>>>> However, what I believe the charter is actually going to do >>>>>>=20 >>>>>> is exactly >>>>>>>=20 >>>>>>> the opposite of that. When you get your head around what >>>>>>=20 >>>>>> this charter >>>>>>>=20 >>>>>>> is proposing, it is going to form a more or less opaque >>>>>>=20 >>>>>> container for >>>>>>>=20 >>>>>>> transporting proprietary information in a SIP header. It's hard = to >>>>>>> imagine how this will help interoperability. >>>>>>>=20 >>>>>>> If we wanted to have interoperability, the charter would say = what >>>>>>> information needs to be transferred and have the WG define a way = to >>>>>>> get it between systems in an operable way. >>>>>>> What the charter for this WG actually says they are going to do = is >>>>>>> make a special container for transfer proprietary information. >>>>>>> There's not even willing to say what that proprietary >>>>>>=20 >>>>>> information is >>>>>>>=20 >>>>>>> used for other than things ISDN UUI which is a non >>>>>>=20 >>>>>> interoperable and >>>>>>>=20 >>>>>>> fairly proprietary field in ISDN. >>>>>>> Furthermore they have asserted that existing containers >>>>>>=20 >>>>>> such as SIP-T >>>>>>>=20 >>>>>>> or SIP bodies can't be used for reasons that are hard to >>>>>>=20 >>>>>> describe. (I >>>>>>>=20 >>>>>>> reject the idea that because the call might not involved >>>>>>=20 >>>>>> the PSTN, it >>>>>>>=20 >>>>>>> can't use SIP-T). >>>>>>>=20 >>>>>>> I think the folks that want to do this should get a much clear >>>>>>> explanation of how this results in interoperability and why = exist >>>>>>> approach such as SIP-T will not work before this is chartered. >>>>>>>=20 >>>>>>> I do think there is a need to standardize some important >>>>>>=20 >>>>>> call control >>>>>>>=20 >>>>>>> information used in call centers and related places. >>>>>>> However, the "we need a standard container to exchange secret >>>>>>> information WG" is a bad idea and violates the sprit of the >>>>>>=20 >>>>>> SIP change >>>>>>>=20 >>>>>>> process not to mention the mission of the IETF. >>>>>>>=20 >>>>>>> In summary, I'm in favor of figuring out what the problems >>>>>>=20 >>>>>> are people >>>>>>>=20 >>>>>>> hope to solve with this WG and figuring out a way to write >>>>>>> interoperable standards to achieve that. However, I think >>>>>>=20 >>>>>> this charter >>>>>>>=20 >>>>>>> should be rejected by the IESG and sent back to the drawing >>>>>>=20 >>>>>> board. The >>>>>>>=20 >>>>>>> RAI area has things of higher priority items to work on than a = SIP >>>>>>> header for transfer proprietary data. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote: >>>>>>>=20 >>>>>>>> A new IETF working group has been proposed in the Real-time >>>>>>>> Applications and Infrastructure Area. The IESG has not >>>>>>>=20 >>>>>>> made any determination as yet. >>>>>>>>=20 >>>>>>>> The following draft charter was submitted, and is provided for >>>>>>>> informational purposes only. Please send your comments to >>>>>>=20 >>>>>> the IESG >>>>>>>>=20 >>>>>>>> mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. >>>>>>>>=20 >>>>>>>> Call Control UUI for SIP (cuss) >>>>>>>> -------------------------------------------------- >>>>>>>> Current Status: Proposed Working Group >>>>>>>>=20 >>>>>>>> Last modified: 2010-06-21 >>>>>>>>=20 >>>>>>>> Chair(s): >>>>>>>> TBD >>>>>>>>=20 >>>>>>>> Real-time Applications and Infrastructure Area Director(s): >>>>>>>> Gonzalo Camarillo >>>>>>=20 >>>>>> Robert Sparks >>>>>>>>=20 >>>>>>>> >>>>>>>>=20 >>>>>>>> Real-time Applications and Infrastructure Area Advisor: >>>>>>>> Gonzalo Camarillo >>>>>>>>=20 >>>>>>>> Mailing Lists: TBD >>>>>>>>=20 >>>>>>>> Description of Working Group: >>>>>>>>=20 >>>>>>>> The Call Control UUI for SIP (CUSS) working group is chartered = to >>>>>>>> define a Session Initiation Protocol (SIP) mechanism for >>>>>>>=20 >>>>>>> transporting >>>>>>>>=20 >>>>>>>> call-control related user-to-user information (UUI) between = User >>>>>>>> Agents. >>>>>>>>=20 >>>>>>>> The mechanism developed in this working group is >>>>>>=20 >>>>>> applicable in the >>>>>>>>=20 >>>>>>>> following situations: >>>>>>>>=20 >>>>>>>> 1. The information is generated and consumed by an >>>>>>=20 >>>>>> application using >>>>>>>>=20 >>>>>>>> SIP during session setup but the application is not = necessarily >>>>>>>> even SIP aware. >>>>>>>> 2. The behavior of SIP entities that support it is not >>>>>>=20 >>>>>> significantly >>>>>>>>=20 >>>>>>>> changed (as discussed in Section 4 of RFC 5727). >>>>>>>> 3. Generally only the User Agent Client (UAC) and User >>>>>>=20 >>>>>> Agent Server >>>>>>>>=20 >>>>>>>> (UAS) are interested in the information. >>>>>>>> 4. The information is expected to survive retargeting, >>>>>>=20 >>>>>> redirection, >>>>>>>>=20 >>>>>>>> and transfers. >>>>>>>> 5. SIP elements may need to apply policy about passing >>>>>>=20 >>>>>> and screening >>>>>>>>=20 >>>>>>>> the information. >>>>>>>> 6. Multi-vendor interoperability is important. >>>>>>>>=20 >>>>>>>> This mechanism is not applicable in the following situations: >>>>>>>>=20 >>>>>>>> 1. The behavior of SIP entities that support it is = significantly >>>>>>>> changed (as discussed in Section 4 of RFC 5727). >>>>>>>> 2. The information is generated and consumed at the SIP >>>>>>=20 >>>>>> layer by SIP >>>>>>>>=20 >>>>>>>> elements. >>>>>>>> 3. SIP elements besides the UAC and UAS might be interested in >>>>>>>> consuming (beyond applying policy) the information. >>>>>>>> 4. There are specific privacy issues involved with the = information >>>>>>>> being transported (e.g., geolocation or emergency-related >>>>>>>> information). >>>>>>>>=20 >>>>>>>> User data of the mechanism will be clearly marked with the >>>>>>>> application, encoding, semantics, and content type, >>>>>>>=20 >>>>>>> allowing policy to >>>>>>>>=20 >>>>>>>> be applied by UAs. The working group will define the >>>>>>>=20 >>>>>>> information that >>>>>>>>=20 >>>>>>>> each application must specify to utilize the mechanism. >>>>>>>=20 >>>>>>> This type of >>>>>>>>=20 >>>>>>>> application-specific information will be specified in >>>>>>>=20 >>>>>>> standards-track >>>>>>>>=20 >>>>>>>> documents. >>>>>>>>=20 >>>>>>>> One important application of this mechanism is interworking >>>>>>>=20 >>>>>>> with the >>>>>>>>=20 >>>>>>>> ISDN User to User Information Service. This application >>>>>>=20 >>>>>> defined by >>>>>>>>=20 >>>>>>>> ITU-T Q.931 is extensively deployed in the PSTN today >>>>>>>=20 >>>>>>> supporting such >>>>>>>>=20 >>>>>>>> applications as contact centers, call centers, and automatic = call >>>>>>>> distributors (ACDs). A major barrier to the movement of these >>>>>>>> applications to SIP is the lack of a standard mechanism to >>>>>>>=20 >>>>>>> transport >>>>>>>>=20 >>>>>>>> this information in SIP. For interworking with ISDN, minimal >>>>>>>> information about the content of the UUI is available to >>>>>>>=20 >>>>>>> the PSTN-SIP >>>>>>>>=20 >>>>>>>> gateways. In this case only, the content will just >>>>>>>=20 >>>>>>> indicate ISDN UUI >>>>>>>>=20 >>>>>>>> Service 1 interworking rather than the actual content. >>>>>>>>=20 >>>>>>>> Call control UUI is user information conveyed between user = agents >>>>>>>> during call control operations. As a result, the >>>>>>>=20 >>>>>>> information must be >>>>>>>>=20 >>>>>>>> conveyed with the INVITE transaction, and must survive proxy >>>>>>>> retargeting, redirection, and transfers. The mechanism >>>>>>>=20 >>>>>>> must utilize a >>>>>>>>=20 >>>>>>>> minimum of SIP extensions since it will need to be >>>>>>>=20 >>>>>>> supported by many >>>>>>>>=20 >>>>>>>> simple SIP user agents such as PSTN gateways. The mechanism = must >>>>>>>> interwork with the existing ISDN service but should also be >>>>>>>=20 >>>>>>> extensible >>>>>>>>=20 >>>>>>>> for use by other applications and non-ISDN protocols. >>>>>>>>=20 >>>>>>>> Even though interworking with the PSTN is an important >>>>>>=20 >>>>>> requirement, >>>>>>>>=20 >>>>>>>> call control UUI can be exchanged between native SIP >>>>>>>=20 >>>>>>> clients that do >>>>>>>>=20 >>>>>>>> not have any ISUP support. Therefore, existing SIP-T >>>>>>>> encapsulation-based approaches defined in RFC3372 do not meet = the >>>>>>>> requirements to transport this type of information. >>>>>>>>=20 >>>>>>>> Mechanisms based on the SIP INFO method, RFC2976, will not be >>>>>>>> considered by the working group since the UUI contents carry >>>>>>>> information that must be conveyed during session setup at >>>>>>=20 >>>>>> the user >>>>>>>>=20 >>>>>>>> agent - the information must be conveyed with the INVITE >>>>>>>=20 >>>>>>> transaction. >>>>>>>>=20 >>>>>>>> The information must be passed with the session setup request >>>>>>>> (INVITE), responses to that INVITE, or session >>>>>>=20 >>>>>> termination requests. >>>>>>>>=20 >>>>>>>> As a result, it is not possible to use INFO in these cases. >>>>>>>>=20 >>>>>>>> The group will produce: >>>>>>>>=20 >>>>>>>> - A problem statement and requirements document for >>>>>>>=20 >>>>>>> implementing a SIP >>>>>>>>=20 >>>>>>>> call control UUI mechanism >>>>>>>>=20 >>>>>>>> - A specification of the SIP extension to best meet those >>>>>>>=20 >>>>>>> requirements. >>>>>>>>=20 >>>>>>>> Goals and Milestones >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>>=20 >>>>>>>> Sep 10 - Problem statement and requirements document to IESG >>>>>>>> (Informational) >>>>>>>> Mar 11 - SIP call control UUI specification to IESG (PS) >>>>>>>> _______________________________________________ >>>>>>>> IETF-Announce mailing list >>>>>>>> IETF-Announce@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>>>=20 >>>>>>> Cullen Jennings >>>>>>> For corporate legal information go to: >>>>>>> = http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>>=20 >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>=20 >>>=20 >>> _______________________________________________ >>> 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 >>=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed Jul 7 12:56:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5C1C3A697B for ; Wed, 7 Jul 2010 12:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.555 X-Spam-Level: X-Spam-Status: No, score=-108.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkhrX9BvmxsE for ; Wed, 7 Jul 2010 12:56:27 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0C09E3A695F for ; Wed, 7 Jul 2010 12:56:24 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOt4NEyrR7Hu/2dsb2JhbACgF3GlbJpkhSQEg3iERQ X-IronPort-AV: E=Sophos;i="4.53,554,1272844800"; d="scan'208";a="341890170" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 07 Jul 2010 19:56:27 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o67JuQVI013917; Wed, 7 Jul 2010 19:56:26 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <001201cb1ade$4195f680$c4c1e380$@us> Date: Wed, 7 Jul 2010 13:56:25 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <001201cb1ade$4195f680$c4c1e380$@us> To: Richard Shockey X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 19:56:28 -0000 I agree with Richard that finding the single administrative organization = that "owns" a phone number is a huge rat hole but that's not what we are = trying to do with "responsible" in this context - I would like to point = out the charter text In this context, "responsible" means an administrative domain, which is at least one of the domains, to = which a PSTN call to this phone number would be routed. So let's consider my mobile phone number. It's an AT&T plan, so AT&T = could route it anywhere. It's in the US so Nuestar could change the LNP = database to route it anywhere. Cisco pays for it so I imagine the right = Cisco person could call up AT&T and have the number sent to anywhere. = It's my number in that Cisco lets make take it when I leave and I can = move it to another carrier of my choosing so I can make it go anywhere. = Right now it is forwarded to google voice because I am in Calgary and = want it to ring my phone at home instead of paying roaming charges. = (Thank you Google for making the one place you can use google voice = outside the US be where I just happen to live). So Google could route it = anywhere - they currently are routing it to Rogers, Tellus, AT&T, and = probably a few more - any of those carriers could route it anywhere. And = google uses someone like Level 3 to do that routing so they could route = it anywhere. And who knows how many other internet or PSTN transit = providers and peering like providers had a chance to route it anywhere. = The sheer number of SS7 dips that happen in a single call to my cell = number results in is probably more than the SS7 vendors ever imagined = in their wildest dreams. Yah VoIP. So in some sense all these operators = are "responsible" for making sure that my call is not say routed to the = wrong place. However, they seem to do a fine job of that and if they = stopped doing a fine job of that I would adjust the carriers = "responsible" for my number such that they did do a fine job of it.=20 Part of the idea in ViPR was to realize that finding a single owner of a = number is a rat hole and instead focus on the fact that several domains = all cooperate to terminate a call to a given number. So I don't see a = problem with the "responsible" - it nicely side steps the whole = "ownership" issue with numbers yet still results in a workable solution = that results in similar security properties to the existing PSTN which = seem to be adequate for many purposes. Cullen ( and just to repeat my previous email on the subject, all my posts = related to VIPR are from me as an individual contributor and not as = chair. Mary will handle the chair stuff for this topic ) On Jul 3, 2010, at 12:33 PM, Richard Shockey wrote: >=20 > "finding domains that claim to be responsible for a given phone = number" >=20 > This IMHO is flat out impossible. Validating or authenticating an = entity > that is "responsible for a phone number" is as bad as " who is the = carrier > of record" , is a massive rathole. Cullen and Johathan should know = better. > Certs? LNP ?=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed Jul 7 12:56:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0436D3A695F for ; Wed, 7 Jul 2010 12:56:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.577 X-Spam-Level: X-Spam-Status: No, score=-109.577 tagged_above=-999 required=5 tests=[AWL=1.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAU3Oqsn69Wx for ; Wed, 7 Jul 2010 12:56:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ABA903A687D for ; Wed, 7 Jul 2010 12:56:42 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK94NEyrR7Hu/2dsb2JhbACgF3Gla5pkgluCSQSDeIRF X-IronPort-AV: E=Sophos;i="4.53,554,1272844800"; d="scan'208";a="555624713" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 07 Jul 2010 19:56:45 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o67JuQVJ013917; Wed, 7 Jul 2010 19:56:44 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <018901cb0cd9$5ebc5af0$1c3510d0$%roni@huawei.com> Date: Wed, 7 Jul 2010 13:56:44 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <018901cb0cd9$5ebc5af0$1c3510d0$%roni@huawei.com> To: Roni Even X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTNReachability (VIPR) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 19:56:44 -0000 On Jun 15, 2010, at 4:23 PM, Roni Even wrote: > Hi Cullen, > I think that other standard body should be consulted like ITU. What would you like to ask the ITU about?=20 > The reason is > that I see that one assumption is to use the PSTN numbering plan using = also > the caller id. > My experience is that this is not information that can be > reliable when going between PSTN service providers and it gets worse = on > international calls. Yes, caller-id is often missing and is trival to spoof. That is why none = of vipr drafts uses calling name or number. I'm not really sure what you = are getting at here.=20 > Roni Even >=20 > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] = On > > Behalf Of Cullen Jennings > > Sent: Tuesday, June 01, 2010 7:55 PM > > To: DISPATCH list > > Subject: [dispatch] Charter Proposal: Verification Involving PSTN > > Reachability (VIPR) > > > > > > I've been talking to a lot of people about the VIPR drafts - here = is a > > first cut of a proposal for a WG that could do this. I'm sure the > > charter proposal needs a bunch of work but I wanted to get the > > discussion rolling on the list. > > > > Thanks, Cullen > > > > (PS - this is sent in my individual contributor role. Take all my = posts > > about VIPR to be in my individual role not my co-chair role) > > > > ------------------------------------------------------- > > > > ViPR Charter Proposal (Version 0) > > > > WG Name: Verification Involving PSTN Reachability (VIPR) > > > > There are two globally deployed address spaces for communications = that > > more than a billion people use on a daily basis. They are phone = numbers > > and DNS rooted address such as web servers and email addresses. The > > federation design of SIP is primarily designed for email style > > addresses yet a large percentage of SIP deployments primarily use = phone > > numbers for identifying users. The goal of this working group is to > > allows people to use SIP to federate over the the internet while = still > > using phone numbers to identify the person they wish to communicate > > with. > > > > The VIPR WG will address this problem by developing a peer to peer > > based approach to finding SIP domains that claim to be responsible = for > > a given phone number and the WG will design validation protocols to > > ensure a reasonable likelihood that a given domain actually is > > responsible for the phone number. One initial validation protocol = will > > be based on a domain being able to prove it received a particular = phone > > call over the PSTN based on both sides knowing the start and stop = times > > of that call. Other validation schemes, such as examining = fingerprints > > or watermarking of PSTN media, to show that a domain received a > > particular PSTN phone call may be considered by the working group. = To > > help mitigate SPAM over SIP issues, the WG will define an token = based > > authorization scheme so that domain using SIP to federate can choose = to > > check that incoming SIP calls are from a domain that successfully > > validated a phone number. > > > > The problem statement and some possible starting points for = solutions > > are further desired in the following internet drafts which shall = form > > the bases of the WG documents: > > draft-rosenberg-dispatch-vipr-overview > > draft-rosenberg-dispatch-vipr-reload-usage > > draft-rosenberg-dispatch-vipr-pvp > > draft-rosenberg-dispatch-vipr-sip-antispam > > > > The working group will carefully coordinate with the security area, = O&M > > area, as well as the appropriate RAI WG including sipcore and = p2psip. > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From dworley@avaya.com Wed Jul 7 09:36:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379263A67E5 for ; Wed, 7 Jul 2010 09:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.336 X-Spam-Level: X-Spam-Status: No, score=-1.336 tagged_above=-999 required=5 tests=[AWL=1.263, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqlPWV3fMyDx for ; Wed, 7 Jul 2010 09:36:21 -0700 (PDT) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 95BFD3A679F for ; Wed, 7 Jul 2010 09:36:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.53,554,1272859200"; d="scan'208";a="24074904" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 07 Jul 2010 12:36:05 -0400 X-IronPort-AV: E=Sophos;i="4.53,554,1272859200"; d="scan'208";a="479710567" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 07 Jul 2010 12:35:35 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.161]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 7 Jul 2010 12:35:35 -0400 From: "WORLEY, Dale R (Dale)" To: "dispatch@ietf.org" Date: Wed, 7 Jul 2010 12:33:02 -0400 Thread-Topic: "Alert-Info URN" work has been moved to the SALUD WG Thread-Index: AQHLHfJr8YODxaL3t0qE4NLtyTB72Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 07 Jul 2010 12:58:14 -0700 Subject: [dispatch] "Alert-Info URN" work has been moved to the SALUD WG X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 16:36:23 -0000 The "Alert-Info URN" work has been moved to the SALUD (SIP ALerting for Use= r Devices) working group, whose mailing list is . You can = subscribe at https://www.ietf.org/mailman/listinfo/salud Dale From pp3129@att.com Wed Jul 7 13:05:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40B793A68CE for ; Wed, 7 Jul 2010 13:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2K5ODmopxbk6 for ; Wed, 7 Jul 2010 13:05:45 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id E25F53A68F9 for ; Wed, 7 Jul 2010 13:05:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-4.tower-161.messagelabs.com!1278533146!24271156!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 24470 invoked from network); 7 Jul 2010 20:05:47 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Jul 2010 20:05:47 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o67K5LHl012296; Wed, 7 Jul 2010 16:05:22 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o67K5JJq012264; Wed, 7 Jul 2010 16:05:19 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Jul 2010 16:05:42 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B044A97DA@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 3 Thread-Index: AcseDpl3J0uCvU1BTXGGKoe3KS5c9wAAF1YA References: <001201cb1ade$4195f680$c4c1e380$@us> From: "PFAUTZ, PENN L (ATTCORP)" To: "Cullen Jennings" , "Richard Shockey" Cc: DISPATCH list Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 20:05:46 -0000 Cullen: I think you example represents one of the concerns some of us have. Say you've temporarily set up forwarding or used a specific long distance carrier for a particular call. Should the forwarded-to or currently chosen carrier be able to represent itself as a domain that should be routed to once you remove forwarding or stop using a particular LD carrier? Likewise, if you (God forbid:-) port your number from AT&T to Verizon will there be mechanisms to delete AT&T as a route-to domain? Penn=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Wednesday, July 07, 2010 3:56 PM To: Richard Shockey Cc: DISPATCH list Subject: Re: [dispatch] VIPR - proposed charter version 3 I agree with Richard that finding the single administrative organization that "owns" a phone number is a huge rat hole but that's not what we are trying to do with "responsible" in this context - I would like to point out the charter text In this context, "responsible" means an administrative domain, which is at least one of the domains, to which a PSTN call to this phone number would be routed. So let's consider my mobile phone number. It's an AT&T plan, so AT&T could route it anywhere. It's in the US so Nuestar could change the LNP database to route it anywhere. Cisco pays for it so I imagine the right Cisco person could call up AT&T and have the number sent to anywhere. It's my number in that Cisco lets make take it when I leave and I can move it to another carrier of my choosing so I can make it go anywhere. Right now it is forwarded to google voice because I am in Calgary and want it to ring my phone at home instead of paying roaming charges. (Thank you Google for making the one place you can use google voice outside the US be where I just happen to live). So Google could route it anywhere - they currently are routing it to Rogers, Tellus, AT&T, and probably a few more - any of those carriers could route it anywhere. And google uses someone like Level 3 to do that routing so they could route it anywhere. And who knows how many other internet or PSTN transit prov iders and peering like providers had a chance to route it anywhere. The sheer number of SS7 dips that happen in a single call to my cell number results in is probably more than the SS7 vendors ever imagined in their wildest dreams. Yah VoIP. So in some sense all these operators are "responsible" for making sure that my call is not say routed to the wrong place. However, they seem to do a fine job of that and if they stopped doing a fine job of that I would adjust the carriers "responsible" for my number such that they did do a fine job of it.=20 Part of the idea in ViPR was to realize that finding a single owner of a number is a rat hole and instead focus on the fact that several domains all cooperate to terminate a call to a given number. So I don't see a problem with the "responsible" - it nicely side steps the whole "ownership" issue with numbers yet still results in a workable solution that results in similar security properties to the existing PSTN which seem to be adequate for many purposes. Cullen ( and just to repeat my previous email on the subject, all my posts related to VIPR are from me as an individual contributor and not as chair. Mary will handle the chair stuff for this topic ) On Jul 3, 2010, at 12:33 PM, Richard Shockey wrote: >=20 > "finding domains that claim to be responsible for a given phone number" >=20 > This IMHO is flat out impossible. Validating or authenticating an entity > that is "responsible for a phone number" is as bad as " who is the carrier > of record" , is a massive rathole. Cullen and Johathan should know better. > Certs? LNP ?=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From maltarai@cisco.com Wed Jul 7 13:29:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F3A3A3A68B8 for ; Wed, 7 Jul 2010 13:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rplUEEF8bXIs for ; Wed, 7 Jul 2010 13:29:08 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E07033A686B for ; Wed, 7 Jul 2010 13:29:07 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOOANEytJV2a/2dsb2JhbACgGHGlYJpghSQEg3iGcg X-IronPort-AV: E=Sophos;i="4.53,554,1272844800"; d="scan'208";a="129714588" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2010 20:29:04 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o67KT4kS000841; Wed, 7 Jul 2010 20:29:04 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Jul 2010 15:29:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Jul 2010 15:28:17 -0500 Message-ID: <04CA7DCC63584C4D8967FF818D80965B01B2C8AB@XMB-RCD-113.cisco.com> In-Reply-To: <35FE871E2B085542A35726420E29DA6B044A97DA@gaalpa1msgusr7a.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 3 Thread-Index: AcseDpl3J0uCvU1BTXGGKoe3KS5c9wAAF1YAAAB1gFA= References: <001201cb1ade$4195f680$c4c1e380$@us> <35FE871E2B085542A35726420E29DA6B044A97DA@gaalpa1msgusr7a.ugd.att.com> From: "Mohammad Al-Taraireh (maltarai)" To: "PFAUTZ, PENN L (ATTCORP)" , "Cullen Jennings (fluffy)" , "Richard Shockey" X-OriginalArrivalTime: 07 Jul 2010 20:29:04.0275 (UTC) FILETIME=[0AB09E30:01CB1E13] Cc: DISPATCH list Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 20:29:10 -0000 These are excellent questions, however, they are almost implementation specific. Any node that is in the routing path, and terminates the call (to apply some kind of policy or feature like call forwarding) can potentially give you a ViPR SIP route to reach that node by passing the pstn assuming the validation for that call happen successfully, which in turn means that this node must be ViPR enabled.=20 In cases where learned ViPR routes fail due to the number being unallocated or assigned to a different carrier, the ViPR call should fail in this case, and the call should be forced to go over the pstn again to allow re learn the new SIP route.=20 ViPR provides on going self learning, and healing if necessary for ViPR calls that fail to get setup. Of course some of this need to be spelled out in the specification.=20 Mo A -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of PFAUTZ, PENN L (ATTCORP) Sent: Wednesday, July 07, 2010 4:06 PM To: Cullen Jennings (fluffy); Richard Shockey Cc: DISPATCH list Subject: Re: [dispatch] VIPR - proposed charter version 3 Cullen: I think you example represents one of the concerns some of us have. Say you've temporarily set up forwarding or used a specific long distance carrier for a particular call. Should the forwarded-to or currently chosen carrier be able to represent itself as a domain that should be routed to once you remove forwarding or stop using a particular LD carrier? Likewise, if you (God forbid:-) port your number from AT&T to Verizon will there be mechanisms to delete AT&T as a route-to domain? Penn -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Wednesday, July 07, 2010 3:56 PM To: Richard Shockey Cc: DISPATCH list Subject: Re: [dispatch] VIPR - proposed charter version 3 I agree with Richard that finding the single administrative organization that "owns" a phone number is a huge rat hole but that's not what we are trying to do with "responsible" in this context - I would like to point out the charter text In this context, "responsible" means an administrative domain, which is at least one of the domains, to which a PSTN call to this phone number would be routed. So let's consider my mobile phone number. It's an AT&T plan, so AT&T could route it anywhere. It's in the US so Nuestar could change the LNP database to route it anywhere. Cisco pays for it so I imagine the right Cisco person could call up AT&T and have the number sent to anywhere. It's my number in that Cisco lets make take it when I leave and I can move it to another carrier of my choosing so I can make it go anywhere. Right now it is forwarded to google voice because I am in Calgary and want it to ring my phone at home instead of paying roaming charges. (Thank you Google for making the one place you can use google voice outside the US be where I just happen to live). So Google could route it anywhere - they currently are routing it to Rogers, Tellus, AT&T, and probably a few more - any of those carriers could route it anywhere. And google uses someone like Level 3 to do that routing so they could route it anywhere. And who knows how many other internet or PSTN transit prov iders and peering like providers had a chance to route it anywhere. The sheer number of SS7 dips that happen in a single call to my cell number results in is probably more than the SS7 vendors ever imagined in their wildest dreams. Yah VoIP. So in some sense all these operators are "responsible" for making sure that my call is not say routed to the wrong place. However, they seem to do a fine job of that and if they stopped doing a fine job of that I would adjust the carriers "responsible" for my number such that they did do a fine job of it.=20 Part of the idea in ViPR was to realize that finding a single owner of a number is a rat hole and instead focus on the fact that several domains all cooperate to terminate a call to a given number. So I don't see a problem with the "responsible" - it nicely side steps the whole "ownership" issue with numbers yet still results in a workable solution that results in similar security properties to the existing PSTN which seem to be adequate for many purposes. Cullen ( and just to repeat my previous email on the subject, all my posts related to VIPR are from me as an individual contributor and not as chair. Mary will handle the chair stuff for this topic ) On Jul 3, 2010, at 12:33 PM, Richard Shockey wrote: >=20 > "finding domains that claim to be responsible for a given phone number" >=20 > This IMHO is flat out impossible. Validating or authenticating an entity > that is "responsible for a phone number" is as bad as " who is the carrier > of record" , is a massive rathole. Cullen and Johathan should know better. > Certs? LNP ?=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ 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 Even.roni@huawei.com Wed Jul 7 13:35:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B69D3A68B8 for ; Wed, 7 Jul 2010 13:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HM-dOBZ2kO0B for ; Wed, 7 Jul 2010 13:35:30 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id D0C3E3A686B for ; Wed, 7 Jul 2010 13:35:29 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L57000HPFUYF5@szxga04-in.huawei.com> for dispatch@ietf.org; Thu, 08 Jul 2010 04:35:23 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5700B9PFUYFV@szxga04-in.huawei.com> for dispatch@ietf.org; Thu, 08 Jul 2010 04:35:22 +0800 (CST) Received: from windows8d787f9 ([109.66.52.27]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L570098LFUQIC@szxml02-in.huawei.com>; Thu, 08 Jul 2010 04:35:22 +0800 (CST) Date: Wed, 07 Jul 2010 23:34:52 +0300 From: Roni Even In-reply-to: To: 'Cullen Jennings' Message-id: <017001cb1e13$df126e10$9d374a30$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcseDokt/ohiYMH/RbyQu1fGXX7QpAABJsBQ References: <018901cb0cd9$5ebc5af0$1c3510d0$%roni@huawei.com> Cc: 'DISPATCH list' Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTNReachability (VIPR) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 20:35:31 -0000 Cullen, I am not talking about the vipr drafts but about the charter, I thought we are discussion a charter and not a solution. "One initial validation protocol will be based on a domain being able to prove it received a particular phone call over the PSTN based on both sides knowing the start and stop times of that call" What do you mean by "received a particular phone call" - my understanding from reading the sentence is that it is based on the caller ID; the start and stop time may not be unique, so my reading is that the charter means caller-id and start and stop time. Roni Even > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, July 07, 2010 10:57 PM > To: Roni Even > Cc: DISPATCH list > Subject: Re: [dispatch] Charter Proposal: Verification Involving > PSTNReachability (VIPR) > > > On Jun 15, 2010, at 4:23 PM, Roni Even wrote: > > > Hi Cullen, > > I think that other standard body should be consulted like ITU. > > What would you like to ask the ITU about? > > > The reason is > > that I see that one assumption is to use the PSTN numbering plan > using also > > the caller id. > > My experience is that this is not information that can be > > reliable when going between PSTN service providers and it gets worse > on > > international calls. > > Yes, caller-id is often missing and is trival to spoof. That is why > none of vipr drafts uses calling name or number. I'm not really sure > what you are getting at here. > > > > Roni Even > > > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On > > > Behalf Of Cullen Jennings > > > Sent: Tuesday, June 01, 2010 7:55 PM > > > To: DISPATCH list > > > Subject: [dispatch] Charter Proposal: Verification Involving PSTN > > > Reachability (VIPR) > > > > > > > > > I've been talking to a lot of people about the VIPR drafts - here > is a > > > first cut of a proposal for a WG that could do this. I'm sure the > > > charter proposal needs a bunch of work but I wanted to get the > > > discussion rolling on the list. > > > > > > Thanks, Cullen > > > > > > (PS - this is sent in my individual contributor role. Take all my > posts > > > about VIPR to be in my individual role not my co-chair role) > > > > > > ------------------------------------------------------- > > > > > > ViPR Charter Proposal (Version 0) > > > > > > WG Name: Verification Involving PSTN Reachability (VIPR) > > > > > > There are two globally deployed address spaces for communications > that > > > more than a billion people use on a daily basis. They are phone > numbers > > > and DNS rooted address such as web servers and email addresses. The > > > federation design of SIP is primarily designed for email style > > > addresses yet a large percentage of SIP deployments primarily use > phone > > > numbers for identifying users. The goal of this working group is to > > > allows people to use SIP to federate over the the internet while > still > > > using phone numbers to identify the person they wish to communicate > > > with. > > > > > > The VIPR WG will address this problem by developing a peer to peer > > > based approach to finding SIP domains that claim to be responsible > for > > > a given phone number and the WG will design validation protocols to > > > ensure a reasonable likelihood that a given domain actually is > > > responsible for the phone number. One initial validation protocol > will > > > be based on a domain being able to prove it received a particular > phone > > > call over the PSTN based on both sides knowing the start and stop > times > > > of that call. Other validation schemes, such as examining > fingerprints > > > or watermarking of PSTN media, to show that a domain received a > > > particular PSTN phone call may be considered by the working group. > To > > > help mitigate SPAM over SIP issues, the WG will define an token > based > > > authorization scheme so that domain using SIP to federate can > choose to > > > check that incoming SIP calls are from a domain that successfully > > > validated a phone number. > > > > > > The problem statement and some possible starting points for > solutions > > > are further desired in the following internet drafts which shall > form > > > the bases of the WG documents: > > > draft-rosenberg-dispatch-vipr-overview > > > draft-rosenberg-dispatch-vipr-reload-usage > > > draft-rosenberg-dispatch-vipr-pvp > > > draft-rosenberg-dispatch-vipr-sip-antispam > > > > > > The working group will carefully coordinate with the security area, > O&M > > > area, as well as the appropriate RAI WG including sipcore and > p2psip. > > > > > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > From maltarai@cisco.com Wed Jul 7 13:44:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9082A3A68F0 for ; Wed, 7 Jul 2010 13:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8JqM6zbCyEF for ; Wed, 7 Jul 2010 13:44:20 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B88D33A689C for ; Wed, 7 Jul 2010 13:44:19 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGeENEytJV2c/2dsb2JhbACgGHGlSJpcgluCSQSDeIZy X-IronPort-AV: E=Sophos;i="4.53,554,1272844800"; d="scan'208";a="129718924" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 07 Jul 2010 20:44:22 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o67KiMYR023321; Wed, 7 Jul 2010 20:44:22 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Jul 2010 15:44:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 7 Jul 2010 15:44:17 -0500 Message-ID: <04CA7DCC63584C4D8967FF818D80965B01B2C8C0@XMB-RCD-113.cisco.com> In-Reply-To: <017001cb1e13$df126e10$9d374a30$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter Proposal: Verification Involving PSTNReachability (VIPR) Thread-Index: AcseDokt/ohiYMH/RbyQu1fGXX7QpAABJsBQAABcwcA= References: <018901cb0cd9$5ebc5af0$1c3510d0$%roni@huawei.com> <017001cb1e13$df126e10$9d374a30$%roni@huawei.com> From: "Mohammad Al-Taraireh (maltarai)" To: "Roni Even" , "Cullen Jennings (fluffy)" X-OriginalArrivalTime: 07 Jul 2010 20:44:22.0720 (UTC) FILETIME=[2E203400:01CB1E15] Cc: DISPATCH list Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTNReachability (VIPR) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 20:44:21 -0000 It is really the key parameters about the pstn call that both sides can agree on. Of course the start, and stop time of the call assuming NTP is being used with some delta error margin should be acceptable. The caller ID should not be a mandatory key since it might not be present in all cases, however, the called number must be required, and must be the same on both VCRs.=20 Mo A=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, July 07, 2010 4:35 PM To: Cullen Jennings (fluffy) Cc: 'DISPATCH list' Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTNReachability (VIPR) Cullen, I am not talking about the vipr drafts but about the charter, I thought we are discussion a charter and not a solution. "One initial validation protocol will be based on a domain being able to prove it received a particular phone call over the PSTN based on both sides knowing the start and stop times of that call" What do you mean by "received a particular phone call" - my understanding from reading the sentence is that it is based on the caller ID; the start and stop time may not be unique, so my reading is that the charter means caller-id and start and stop time. Roni Even > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Wednesday, July 07, 2010 10:57 PM > To: Roni Even > Cc: DISPATCH list > Subject: Re: [dispatch] Charter Proposal: Verification Involving=20 > PSTNReachability (VIPR) >=20 >=20 > On Jun 15, 2010, at 4:23 PM, Roni Even wrote: >=20 > > Hi Cullen, > > I think that other standard body should be consulted like ITU. >=20 > What would you like to ask the ITU about? >=20 > > The reason is > > that I see that one assumption is to use the PSTN numbering plan > using also > > the caller id. > > My experience is that this is not information that can be reliable=20 > > when going between PSTN service providers and it gets worse > on > > international calls. >=20 > Yes, caller-id is often missing and is trival to spoof. That is why=20 > none of vipr drafts uses calling name or number. I'm not really sure=20 > what you are getting at here. >=20 >=20 > > Roni Even > > > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On > > > Behalf Of Cullen Jennings > > > Sent: Tuesday, June 01, 2010 7:55 PM > > > To: DISPATCH list > > > Subject: [dispatch] Charter Proposal: Verification Involving PSTN=20 > > > Reachability (VIPR) > > > > > > > > > I've been talking to a lot of people about the VIPR drafts - here > is a > > > first cut of a proposal for a WG that could do this. I'm sure the=20 > > > charter proposal needs a bunch of work but I wanted to get the=20 > > > discussion rolling on the list. > > > > > > Thanks, Cullen > > > > > > (PS - this is sent in my individual contributor role. Take all my > posts > > > about VIPR to be in my individual role not my co-chair role) > > > > > > ------------------------------------------------------- > > > > > > ViPR Charter Proposal (Version 0) > > > > > > WG Name: Verification Involving PSTN Reachability (VIPR) > > > > > > There are two globally deployed address spaces for communications > that > > > more than a billion people use on a daily basis. They are phone > numbers > > > and DNS rooted address such as web servers and email addresses.=20 > > > The federation design of SIP is primarily designed for email style > > > addresses yet a large percentage of SIP deployments primarily use > phone > > > numbers for identifying users. The goal of this working group is=20 > > > to allows people to use SIP to federate over the the internet=20 > > > while > still > > > using phone numbers to identify the person they wish to=20 > > > communicate with. > > > > > > The VIPR WG will address this problem by developing a peer to peer > > > based approach to finding SIP domains that claim to be responsible > for > > > a given phone number and the WG will design validation protocols=20 > > > to ensure a reasonable likelihood that a given domain actually is=20 > > > responsible for the phone number. One initial validation protocol > will > > > be based on a domain being able to prove it received a particular > phone > > > call over the PSTN based on both sides knowing the start and stop > times > > > of that call. Other validation schemes, such as examining > fingerprints > > > or watermarking of PSTN media, to show that a domain received a=20 > > > particular PSTN phone call may be considered by the working group. > To > > > help mitigate SPAM over SIP issues, the WG will define an token > based > > > authorization scheme so that domain using SIP to federate can > choose to > > > check that incoming SIP calls are from a domain that successfully=20 > > > validated a phone number. > > > > > > The problem statement and some possible starting points for > solutions > > > are further desired in the following internet drafts which shall > form > > > the bases of the WG documents: > > > draft-rosenberg-dispatch-vipr-overview > > > draft-rosenberg-dispatch-vipr-reload-usage > > > draft-rosenberg-dispatch-vipr-pvp > > > draft-rosenberg-dispatch-vipr-sip-antispam > > > > > > The working group will carefully coordinate with the security=20 > > > area, > O&M > > > area, as well as the appropriate RAI WG including sipcore and > p2psip. > > > > > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From gao.yang2@zte.com.cn Wed Jul 7 19:21:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6110A3A69F6 for ; Wed, 7 Jul 2010 19:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.633 X-Spam-Level: X-Spam-Status: No, score=-97.633 tagged_above=-999 required=5 tests=[AWL=0.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AK4gEJIO2hqJ for ; Wed, 7 Jul 2010 19:21:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 2B5ED3A67F3 for ; Wed, 7 Jul 2010 19:21:19 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 38343992332426; Thu, 8 Jul 2010 10:20:48 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 11511.1340537845; Thu, 8 Jul 2010 10:13:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o682DBxm076546; Thu, 8 Jul 2010 10:20:11 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <8F5532A2-7017-48B2-897F-6FA6E50EE68A@cisco.com> To: Cullen Jennings MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 8 Jul 2010 10:16:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-08 10:20:07, Serialize complete at 2010-07-08 10:20:07 Content-Type: multipart/alternative; boundary="=_alternative 000CB5914825775A_=" X-MAIL: mse2.zte.com.cn o682DBxm076546 Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 02:21:23 -0000 This is a multipart message in MIME format. --=_alternative 000CB5914825775A_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQ3VsbGVuLA0KDQpJIGFncmVlIG1vc3Qgb2YgeW91ciBwb2ludHMsIGVzcGVjaWFsbHkgZm9y IHRoZSBzdWdnZXN0aW5nIGFib3V0IGZpbmRpbmcgDQpzcGVjaWZpYyBhZGRyZXNzYWJsZSBwcm9i bGVtcyBhcyB0aGUgYmFzZSBvZiB0aGUgd29yay4gVGhpcyBpcyBhIHByYWN0aWNhbCANCndheS4N Cg0KQnV0IEkgaGF2ZSBhIHRpbnkgZGlmZmVyZW50IHBvaW50IHRvd2FyZHMgd2hldGhlciBzaG91 bGQgQjJCVUEgYmUgDQpkaXNjdXNzZWQvZGVmaW5lZCBpbiBhbnkgZHJhZnQgYW5kIGVmZmVjdGVk IGFueSB0eXBlIG9mIFVBIGluY2x1ZGluZyBCMkJVQSANCm9yIG5vdC4gSSdkIGxpa2UgdG8gc2Vl IG1vcmUgYW5kIG1vcmUgQkNQIGxldmVsIGRyYWZ0L1JGQyBhYm91dCBCMkJVQSwgYnV0IA0KSSBk b24ndCB0aGluayBhbnkgbm9ybWF0aXZlIG9uZSBuZWVkIHRvIGRlZmluZSB0aGluZ3MgZm9yIEIy QlVBIGFzIGJhc2ljIA0KcnVsZXMuIFRvIGJlIG1pdGlnYXRvcnksIG5vcm1hdGl2ZSBvbmUgY2Fu L21heSBkZWZpbmUgdGhpbmdzIGZvciBCMkJVQSwgDQpidXQgc2hvdWxkIG5vdCBiZSBtYW5kYXRv cnkuDQoNClRoZSByZWFzb24gd2h5IEkgdGhpbmsgd2Ugc2hvdWxkIG5vdCBtYWtlIGl0IGFzIGEg bWFuZGF0b3J5IHJ1bGUsIGlzIHRoYXQgDQpCMkJVQSBpcyBqdXN0IHVzYWdlIG9mIFVBQy9VQVMg cnVsZXMgYW5kIGlzIGp1c3QgaW1wbGVtZW50YXRpb24gbGV2ZWwgDQp0aGluZywgbm90IG5vcm1h dGl2ZSBsZXZlbCB0aGluZy4gDQpJZiB0aGUgQjJCVUEgYmVoYXZlcyBhcyB0aGUgbm9ybWF0aXZl bHkgZGVmaW5lZCBVQUMgYW5kIFVBUywgaXQgaXMgT0suIEFuZCANCkIyQlVBIE1VU1QgbWFrZSBp dHNlbGYgbG9va3MgbGlrZSBhIG5vcm1hbCBVQUMgb3IgVUFTIGZyb20gb3RoZXIgc2lkZXMnIA0K dmlldy4gU28sIHRoZXJlJ3Mgbm8gbmVlZCB0byBkbyBtb3JlIHJ1bGUvZGVmaW50aW9uIGZvciB0 aGUgQjJCVUEuIEFuZCBJIA0KZG8gbm90IHByZWZlciB0byBzZWUgYW55IG5vcm1hdGl2ZSB0ZXh0 IGRvIG1vcmUgcnVsZSBmb3IgQjJCVUEsIGFuZCBhbGxvdyANCml0IGRvIG1vcmUgb3IgbGVzcyB0 aGluZ3MgdGhhbiBub3JtYWwgVUFDL1VBUy4NCg0KVGhhbmtzLA0KDQpHYW8NCg0KPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4 NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0 ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQpDdWxs ZW4gSmVubmluZ3MgPGZsdWZmeUBjaXNjby5jb20+IA0Kt6K8/sjLOiAgZGlzcGF0Y2gtYm91bmNl c0BpZXRmLm9yZw0KMjAxMC0wNy0wOCAwMDoyMg0KDQrK1bz+yMsNCk11dGh1IEFydWxNb3poaSBQ ZXJ1bWFsIChtcGVydW1hbCkgPG1wZXJ1bWFsQGNpc2NvLmNvbT4NCrOty80NCkRJU1BBVENIIGxp c3QgPGRpc3BhdGNoQGlldGYub3JnPg0K1vfM4g0KUmU6IFtkaXNwYXRjaF0gU2hvdWxkIElFVEYg aGF2ZSBhIEJFSEFWRSBXRyBmb3IgU0JDcz8NCg0KDQoNCg0KDQoNCg0KV2UgaGFkIGEgQk9GIG9u IHByZXR0eSBtdWNoIHRoaXMgdG9waWMuIFNvbWUgcGVvcGxlIHdyb3RlIGRyYWZ0cy4gVGhlcmUg DQp3YXMgcHJldHR5IG11Y2ggbm8gZW5lcmd5IHRvIGV2ZW4gc2VuZCBjb21tZW50cyBvbiBpdCBh bmQgaXQgd2FzIGhhcmQgdG8gDQpmaW5kIGF1dGhvcnMuIEl0IHdhcyBldmVudHVhbGx5IHB1Ymxp c2hlZCBhcyBSRkMgNTg1MyBhbmQgd2UgYWxsIG5lZWQgdG8gDQpnaXZlIEphbmkgSGF1dGFrb3Jw aSBhIGJpZyB0aGFua3MgZm9yIHRoYXQuIA0KDQpUaGUgd2hvbGUgZXhwZXJpZW5jZSBhcm91bmQg NTg0MyBkb2VzIGxlZnQgbWUgdGhpbmtpbmcgdGhhdCBpdCB3YXMgYmV0dGVyIA0KdG8gY29uc2lk ZXIgQjJCVUEgaW4gYW55IGRyYWZ0IGFuZCBlZmZlY3RlZCBhbnkgdHlwZSBvZiBVQSBpbmNsdWRp bmcgDQpCMkJVQS4gV2hlbiB3ZSBhc2sgdGhlIHF1ZXN0aW9uICJzaG91bGQgd2UgbWFrZSBTQkMg aW50ZXJvcGVyYXRlIGJldHRlciIgDQp3ZSBnZXQgYSByZXNvdW5kaW5nIHllcyBmcm9tIGV2ZXJ5 b25lLiBXaGVuIGFza2VkIHNvIHdoYXQgZG8gd2UgbmVlZCB0byANCmNoYW5nZSB0byBtYWtlIHRo YXQgaGFwcGVuIHdlIGdldCBhIHJlc291bmRpbmcgIm1pZ2h0IGRvIHRoYXQgc29tZSBvZiB0aGUg DQp0aW1lIGJ1dCBjZXJ0YWlubHkgbm90IGFsbCB0aGUgdGltZSBmcm9tIHRoZSBTQkMgdmVuZG9y cyIuIEkgbGlrZSB0aGUgaWRlYSANCm9mIGZpbmRpbmcgc3BlY2lmaWMgYWRkcmVzc2FibGUgcHJv YmxlbXMgc3VjaCBhcyBIYWRyaWVscyBzZXNzaW9uLWlkIHN0dWZmIA0KdGhlbiBnb2luZyBhbmQg ZmlndXJpbmcgb3V0IGhvdyB0byBmaXggdGhhdCBwcm9ibGVtLiBJZiB0aGVyZSBhcmUgb3RoZXIg DQpzcGVjaWZpYyBwcm9ibGVtcyB0aGF0IGNhbiBiZSBmaXhlZCwgYnkgYWxsIG1lYW5zIHdyaXRl IHNvbWUgZHJhZnRzIGFuZCANCmdldCBzb21lIHByb3Bvc2FscyBvbiB0aGUgdGFibGUuIA0KDQoN Cg0KDQpPbiBKdWwgMSwgMjAxMCwgYXQgMTE6MjcgQU0sIE11dGh1IEFydWxNb3poaSBQZXJ1bWFs IChtcGVydW1hbCkgd3JvdGU6DQoNCj4gSW4gdGhlIHBhc3QgZmV3IHllYXJzIHRoZXJlIGhhcyBi ZWVuIGEgcHJvbGlmZXJhdGlvbiBvZiBTZXNzaW9uIEJvcmRlciANCkNvbnRyb2xsZXIgKFNCQykg ZGVwbG95bWVudHMgaW4gU0lQIG5ldHdvcmtzIG1haW5seSBiZWNhdXNlIHRoZSANCmRldmVsb3Bt ZW50IG9mIFNJUCBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucyBoYXNuJ3QgYmVlbiBhYmxlIHRvIGtl ZXAgaW4gDQpwYWNlIHdpdGggaW5kdXN0cnkgYW5kIG9wZXJhdG9yIHJlcXVpcmVtZW50cy4gVGhl IGNvbW1vbiBmdW5jdGlvbnMgdGhleSANCnBlcmZvcm0gYW5kIHRoZSBhcmNoaXRlY3R1cmFsIGlz c3VlcyB0aGV5IGludHJvZHVjZSBhcmUgZGVzY3JpYmVkIGluIA0KUkZDLTU4NTMuDQo+IA0KPiBE dWUgdG8gbGFjayBvZiB3ZWxsIGRlZmluZWQgZ3VpZGVsaW5lcyBhbmQgYmVzdCBjdXJyZW50IHBy YWN0aWNlcyBtYW55IA0KU0JDIGltcGxlbWVudGF0aW9ucyBicmVhayBlbmQtdG8tZW5kIGZlYXR1 cmVzIGFuZCBpbnRyb2R1Y2UgcHJvYmxlbXMgdGhhdCANCmFyZSBkaWZmaWN1bHQgdG8gdHJvdWJs ZXNob290LCBtYW55IGEgdGltZXMgYmVjYXVzZSBvZiBwb29yIA0KaW1wbGVtZW50YXRpb25zIHJh dGhlciB0aGFuIHRvIG1lZXQgYW55IHNwZWNpZmljIHJlcXVpcmVtZW50cy4gRm9yIA0KZXhhbXBs ZSwgd2hlbiB0aGV5IGRvIG1lZGlhIHByb2Nlc3NpbmcgdGhleSBhc3N1bWUgZXZlcnl0aGluZyBj b21pbmcgb24gDQp0aGUgbWVkaWEgY2hhbm5lbCBpcyBSVFAsIGRvbid0IGRvIGV2ZW4gYmFzaWMg UlRQIGhlYWRlciB2YWxpZGF0aW9ucyBhcyANCnJlY29tbWVuZGVkIGluIFJGQy0zNTUwLCB0cnkg dG8gZGVjb2RlIFNUVU4gYW5kIERUTFMgcGFja2V0cyBhcyANClJUUGNvcnJ1cHRpbmcgdGhlbSBh bmQgbWFraW5nIHRoZW0gdXNlbGVzcy4NCj4gDQo+IEkgYW0gd29uZGVyaW5nIHdoZXRoZXIgSUVU RiBzaG91bGQgaGF2ZSBhIEJFSEFWRSBXRyBmb3IgU0JDcywgc2ltaWxhciB0byANCnRoZSBvbmUg Zm9yIE5BVHMsIHRvIHNldCBndWlkZWxpbmVzIGFuZCBpZGVudGlmeSBiZXN0IGN1cnJlbnQgcHJh Y3RpY2VzIHRvIA0KZW5jb3VyYWdlIGJldHRlciBTQkMgaW1wbGVtZW50YXRpb25zLCBpbnRlcm9w ZXJhYmlsaXR5IGFuZCBlYXNlIG9mIA0KdHJvdWJsZXNob290aW5nLCByYXRoZXIgdGhhbiBqdXN0 IGtlZXBpbmcgcXVpZXQgYW5kIGxldHRpbmcgdGhlbSBnbyBvdXQgb2YgDQpjb250cm9sLg0KPiAN Cj4gQ29tbWVudHM/DQo+IA0KPiBNdXRodQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCj4gZGlzcGF0Y2hA aWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRj aA0KDQoNCkN1bGxlbiBKZW5uaW5ncw0KRm9yIGNvcnBvcmF0ZSBsZWdhbCBpbmZvcm1hdGlvbiBn byB0bzoNCmh0dHA6Ly93d3cuY2lzY28uY29tL3dlYi9hYm91dC9kb2luZ19idXNpbmVzcy9sZWdh bC9jcmkvaW5kZXguaHRtbA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCmRpc3BhdGNoIG1haWxpbmcgbGlzdA0KZGlzcGF0Y2hAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCg0KDQoNCg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRh aW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdh bml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBp ZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFy ZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmlj YXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdp dGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9m IHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBv cmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVz c2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhh cyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0 ZW0uDQo= --=_alternative 000CB5914825775A_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEN1bGxlbiw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYWdyZWUgbW9zdCBvZiB5 b3VyIHBvaW50cywgZXNwZWNpYWxseQ0KZm9yIHRoZSBzdWdnZXN0aW5nIGFib3V0IDwvZm9udD48 dHQ+PGZvbnQgc2l6ZT0yPmZpbmRpbmcgc3BlY2lmaWMgYWRkcmVzc2FibGUNCnByb2JsZW1zPC9m b250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiBhcyB0aGUgYmFzZSBvZiB0 aGUNCndvcmsuIFRoaXMgaXMgYSBwcmFjdGljYWwgd2F5LjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QnV0IEkgaGF2ZSBhIHRpbnkgZGlmZmVyZW50IHBv aW50IHRvd2FyZHMNCjwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPndoZXRoZXIgc2hvdWxkIEIyQlVB IGJlIGRpc2N1c3NlZC9kZWZpbmVkIGluIGFueQ0KZHJhZnQgYW5kIGVmZmVjdGVkIGFueSB0eXBl IG9mIFVBIGluY2x1ZGluZyBCMkJVQSBvciBub3QuIEknZCBsaWtlIHRvIHNlZQ0KbW9yZSBhbmQg bW9yZSBCQ1AgbGV2ZWwgZHJhZnQvUkZDIGFib3V0IEIyQlVBLCBidXQgSSBkb24ndCB0aGluayBh bnkgbm9ybWF0aXZlDQpvbmUgbmVlZCB0byBkZWZpbmUgdGhpbmdzIGZvciBCMkJVQSBhcyBiYXNp YyBydWxlcy4gVG8gYmUgbWl0aWdhdG9yeSwgbm9ybWF0aXZlDQpvbmUgY2FuL21heSBkZWZpbmUg dGhpbmdzIGZvciBCMkJVQSwgYnV0IHNob3VsZCBub3QgYmUgbWFuZGF0b3J5LjwvZm9udD48L3R0 Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+VGhlIHJlYXNvbiB3aHkgSSB0aGluayB3ZSBz aG91bGQgbm90IG1ha2UgaXQgYXMgYQ0KbWFuZGF0b3J5IHJ1bGUsIGlzIHRoYXQgQjJCVUEgaXMg anVzdCB1c2FnZSBvZiBVQUMvVUFTIHJ1bGVzIGFuZCBpcyBqdXN0DQppbXBsZW1lbnRhdGlvbiBs ZXZlbCB0aGluZywgbm90IG5vcm1hdGl2ZSBsZXZlbCB0aGluZy4gPC9mb250PjwvdHQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklmIHRoZSBCMkJVQSBiZWhhdmVzIGFzIHRo ZSBub3JtYXRpdmVseQ0KZGVmaW5lZCBVQUMgYW5kIFVBUywgaXQgaXMgT0suIEFuZCBCMkJVQSBN VVNUIG1ha2UgaXRzZWxmIGxvb2tzIGxpa2UgYQ0Kbm9ybWFsIFVBQyBvciBVQVMgZnJvbSBvdGhl ciBzaWRlcycgdmlldy4gU28sIHRoZXJlJ3Mgbm8gbmVlZCB0byBkbyBtb3JlDQpydWxlL2RlZmlu dGlvbiBmb3IgdGhlIEIyQlVBLiBBbmQgSSBkbyBub3QgcHJlZmVyIHRvIHNlZSBhbnkgbm9ybWF0 aXZlDQp0ZXh0IGRvIG1vcmUgcnVsZSBmb3IgQjJCVUEsIGFuZCBhbGxvdyBpdCBkbyBtb3JlIG9y IGxlc3MgdGhpbmdzIHRoYW4gbm9ybWFsDQpVQUMvVUFTLjwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7 OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFp bCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+PGI+Q3VsbGVuIEplbm5pbmdzICZsdDtmbHVmZnlAY2lzY28uY29tJmd0OzwvYj4NCjwvZm9u dD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtkaXNw YXRjaC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjIwMTAtMDctMDggMDA6MjI8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdp ZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+TXV0aHUgQXJ1bE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFs KSAmbHQ7bXBlcnVtYWxAY2lzY28uY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+RElTUEFUQ0gg bGlzdCAmbHQ7ZGlzcGF0Y2hAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98zi PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW2Rp c3BhdGNoXSBTaG91bGQgSUVURiBoYXZlIGEgQkVIQVZFDQpXRyBmb3IgU0JDcz88L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCldl IGhhZCBhIEJPRiBvbiBwcmV0dHkgbXVjaCB0aGlzIHRvcGljLiBTb21lIHBlb3BsZSB3cm90ZSBk cmFmdHMuIFRoZXJlDQp3YXMgcHJldHR5IG11Y2ggbm8gZW5lcmd5IHRvIGV2ZW4gc2VuZCBjb21t ZW50cyBvbiBpdCBhbmQgaXQgd2FzIGhhcmQgdG8NCmZpbmQgYXV0aG9ycy4gSXQgd2FzIGV2ZW50 dWFsbHkgcHVibGlzaGVkIGFzIFJGQyA1ODUzIGFuZCB3ZSBhbGwgbmVlZCB0bw0KZ2l2ZSBKYW5p IEhhdXRha29ycGkgYSBiaWcgdGhhbmtzIGZvciB0aGF0LiA8YnI+DQo8YnI+DQpUaGUgd2hvbGUg ZXhwZXJpZW5jZSBhcm91bmQgNTg0MyBkb2VzIGxlZnQgbWUgdGhpbmtpbmcgdGhhdCBpdCB3YXMg YmV0dGVyDQp0byBjb25zaWRlciBCMkJVQSBpbiBhbnkgZHJhZnQgYW5kIGVmZmVjdGVkIGFueSB0 eXBlIG9mIFVBIGluY2x1ZGluZyBCMkJVQS4NCldoZW4gd2UgYXNrIHRoZSBxdWVzdGlvbiAmcXVv dDtzaG91bGQgd2UgbWFrZSBTQkMgaW50ZXJvcGVyYXRlIGJldHRlciZxdW90Ow0Kd2UgZ2V0IGEg cmVzb3VuZGluZyB5ZXMgZnJvbSBldmVyeW9uZS4gV2hlbiBhc2tlZCBzbyB3aGF0IGRvIHdlIG5l ZWQgdG8NCmNoYW5nZSB0byBtYWtlIHRoYXQgaGFwcGVuIHdlIGdldCBhIHJlc291bmRpbmcgJnF1 b3Q7bWlnaHQgZG8gdGhhdCBzb21lDQpvZiB0aGUgdGltZSBidXQgY2VydGFpbmx5IG5vdCBhbGwg dGhlIHRpbWUgZnJvbSB0aGUgU0JDIHZlbmRvcnMmcXVvdDsuDQpJIGxpa2UgdGhlIGlkZWEgb2Yg ZmluZGluZyBzcGVjaWZpYyBhZGRyZXNzYWJsZSBwcm9ibGVtcyBzdWNoIGFzIEhhZHJpZWxzDQpz ZXNzaW9uLWlkIHN0dWZmIHRoZW4gZ29pbmcgYW5kIGZpZ3VyaW5nIG91dCBob3cgdG8gZml4IHRo YXQgcHJvYmxlbS4gSWYNCnRoZXJlIGFyZSBvdGhlciBzcGVjaWZpYyBwcm9ibGVtcyB0aGF0IGNh biBiZSBmaXhlZCwgYnkgYWxsIG1lYW5zIHdyaXRlDQpzb21lIGRyYWZ0cyBhbmQgZ2V0IHNvbWUg cHJvcG9zYWxzIG9uIHRoZSB0YWJsZS4gPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24g SnVsIDEsIDIwMTAsIGF0IDExOjI3IEFNLCBNdXRodSBBcnVsTW96aGkgUGVydW1hbCAobXBlcnVt YWwpIHdyb3RlOjxicj4NCjxicj4NCiZndDsgSW4gdGhlIHBhc3QgZmV3IHllYXJzIHRoZXJlIGhh cyBiZWVuIGEgcHJvbGlmZXJhdGlvbiBvZiBTZXNzaW9uIEJvcmRlcg0KQ29udHJvbGxlciAoU0JD KSBkZXBsb3ltZW50cyBpbiBTSVAgbmV0d29ya3MgbWFpbmx5IGJlY2F1c2UgdGhlIGRldmVsb3Bt ZW50DQpvZiBTSVAgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbnMgaGFzbid0IGJlZW4gYWJsZSB0byBr ZWVwIGluIHBhY2Ugd2l0aCBpbmR1c3RyeQ0KYW5kIG9wZXJhdG9yIHJlcXVpcmVtZW50cy4gVGhl IGNvbW1vbiBmdW5jdGlvbnMgdGhleSBwZXJmb3JtIGFuZCB0aGUgYXJjaGl0ZWN0dXJhbA0KaXNz dWVzIHRoZXkgaW50cm9kdWNlIGFyZSBkZXNjcmliZWQgaW4gUkZDLTU4NTMuPGJyPg0KJmd0OyAm bmJzcDs8YnI+DQomZ3Q7IER1ZSB0byBsYWNrIG9mIHdlbGwgZGVmaW5lZCBndWlkZWxpbmVzIGFu ZCBiZXN0IGN1cnJlbnQgcHJhY3RpY2VzDQptYW55IFNCQyBpbXBsZW1lbnRhdGlvbnMgYnJlYWsg ZW5kLXRvLWVuZCBmZWF0dXJlcyBhbmQgaW50cm9kdWNlIHByb2JsZW1zDQp0aGF0IGFyZSBkaWZm aWN1bHQgdG8gdHJvdWJsZXNob290LCBtYW55IGEgdGltZXMgYmVjYXVzZSBvZiBwb29yIGltcGxl bWVudGF0aW9ucw0KcmF0aGVyIHRoYW4gdG8gbWVldCBhbnkgc3BlY2lmaWMgcmVxdWlyZW1lbnRz LiBGb3IgZXhhbXBsZSwgd2hlbiB0aGV5IGRvDQptZWRpYSBwcm9jZXNzaW5nIHRoZXkgYXNzdW1l IGV2ZXJ5dGhpbmcgY29taW5nIG9uIHRoZSBtZWRpYSBjaGFubmVsIGlzDQpSVFAsIGRvbid0IGRv IGV2ZW4gYmFzaWMgUlRQIGhlYWRlciB2YWxpZGF0aW9ucyBhcyByZWNvbW1lbmRlZCBpbiBSRkMt MzU1MCwNCnRyeSB0byBkZWNvZGUgU1RVTiBhbmQgRFRMUyBwYWNrZXRzIGFzIFJUUGNvcnJ1cHRp bmcgdGhlbSBhbmQgbWFraW5nIHRoZW0NCnVzZWxlc3MuPGJyPg0KJmd0OyAmbmJzcDs8YnI+DQom Z3Q7IEkgYW0gd29uZGVyaW5nIHdoZXRoZXIgSUVURiBzaG91bGQgaGF2ZSBhIEJFSEFWRSBXRyBm b3IgU0JDcywgc2ltaWxhcg0KdG8gdGhlIG9uZSBmb3IgTkFUcywgdG8gc2V0IGd1aWRlbGluZXMg YW5kIGlkZW50aWZ5IGJlc3QgY3VycmVudCBwcmFjdGljZXMNCnRvIGVuY291cmFnZSBiZXR0ZXIg U0JDIGltcGxlbWVudGF0aW9ucywgaW50ZXJvcGVyYWJpbGl0eSBhbmQgZWFzZSBvZiB0cm91Ymxl c2hvb3RpbmcsDQpyYXRoZXIgdGhhbiBqdXN0IGtlZXBpbmcgcXVpZXQgYW5kIGxldHRpbmcgdGhl bSBnbyBvdXQgb2YgY29udHJvbC48YnI+DQomZ3Q7ICZuYnNwOzxicj4NCiZndDsgQ29tbWVudHM/ PGJyPg0KJmd0OyAmbmJzcDs8YnI+DQomZ3Q7IE11dGh1PGJyPg0KJmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgZGlzcGF0Y2ggbWFp bGluZyBsaXN0PGJyPg0KJmd0OyBkaXNwYXRjaEBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaDxicj4NCjxicj4NCjxicj4NCkN1 bGxlbiBKZW5uaW5nczxicj4NCkZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86 PGJyPg0KaHR0cDovL3d3dy5jaXNjby5jb20vd2ViL2Fib3V0L2RvaW5nX2J1c2luZXNzL2xlZ2Fs L2NyaS9pbmRleC5odG1sPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpkaXNwYXRjaCBtYWlsaW5nIGxpc3Q8 YnI+DQpkaXNwYXRjaEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZGlzcGF0Y2g8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJl Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7 VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJz cDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJz cDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50 cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZu YnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNw O3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZu YnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4N ClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNt aXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDth bmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7 dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZu YnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNw O2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmln aW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdz Jm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZu YnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0K VGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2Zv ciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtB bnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 000CB5914825775A_=-- From fluffy@cisco.com Wed Jul 7 20:47:45 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AACAD3A67CC for ; Wed, 7 Jul 2010 20:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.918 X-Spam-Level: X-Spam-Status: No, score=-109.918 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swRf5iU1Fy+I for ; Wed, 7 Jul 2010 20:47:44 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id DA6113A67B6 for ; Wed, 7 Jul 2010 20:47:44 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioHAIvnNEyrR7Hu/2dsb2JhbACTWYxAcaRommCFJQSDeYRG X-IronPort-AV: E=Sophos;i="4.53,556,1272844800"; d="scan'208";a="155391416" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 08 Jul 2010 03:47:48 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o683llrH018808; Thu, 8 Jul 2010 03:47:48 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 7 Jul 2010 21:47:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 03:47:45 -0000 On Jul 7, 2010, at 8:16 PM, wrote: >=20 > Hi Cullen,=20 >=20 > I agree most of your points, especially for the suggesting about = finding specific addressable problems as the base of the work. This is a = practical way.=20 >=20 > But I have a tiny different point towards whether should B2BUA be = discussed/defined in any draft and effected any type of UA including = B2BUA or not. I'd like to see more and more BCP level draft/RFC about = B2BUA, but I don't think any normative one need to define things for = B2BUA as basic rules. To be mitigatory, normative one can/may define = things for B2BUA, but should not be mandatory.=20 >=20 > The reason why I think we should not make it as a mandatory rule, is = that B2BUA is just usage of UAC/UAS rules and is just implementation = level thing, not normative level thing.=20 > If the B2BUA behaves as the normatively defined UAC and UAS, it is OK. = And B2BUA MUST make itself looks like a normal UAC or UAS from other = sides' view. So, there's no need to do more rule/defintion for the = B2BUA. And I do not prefer to see any normative text do more rule for = B2BUA, and allow it do more or less things than normal UAC/UAS.=20 >=20 > Thanks,=20 >=20 > Gao=20 That makes sense to me.=20 From fluffy@cisco.com Wed Jul 7 21:26:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A7E03A67B6; Wed, 7 Jul 2010 21:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.088 X-Spam-Level: X-Spam-Status: No, score=-110.088 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAV7UgH0Kw-j; Wed, 7 Jul 2010 21:26:47 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 331F53A6359; Wed, 7 Jul 2010 21:26:46 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPrvNEyrR7Hu/2dsb2JhbACgGXGkNZpihSUEg3mERg X-IronPort-AV: E=Sophos;i="4.53,556,1272844800"; d="scan'208";a="223230712" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 08 Jul 2010 04:26:49 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o684QlFi009250; Thu, 8 Jul 2010 04:26:48 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 7 Jul 2010 22:26:46 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> <7E21458B-10A8-468F-8344-9374B3D1EBAE@insensate.co.uk> <01f801cb1caa$5667eaa0$0337bfe0$@us> <4C333D8E.6090505@nostrum.com> To: Peter Musgrave X-Mailer: Apple Mail (2.1081) Cc: DISPATCH , IETF-Discussion list , jonathan@rosen.net Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 04:26:51 -0000 The user surprise is problem is largely masked by the user preference = problem so in practice it is not a big deal.=20 Let me explain what I mean by this. I have a video phone on my desk and = so does my boss and they are on the same "PBX" and can trivially do = video between each other. However, when my boss calls the number of my = video phone, he does not actually expect to get video. My preferences = may have totally turned that off. I may have forwarded the phone to my = cell phone. I may have just "muted" the camera because I am wearing a = jacket and tie and would not want him to catch me in that. The call may = go to voice mail because I was on another call. Users are not = particularly surprised when the video is not there. Similarly, they are = not very surprised when the audio quality is radically different than = they might have hoped due to the other parties preference. My boss's = phone and mine both do wideband audio but we are not surprised when we = don't get that. Audio preferences included putting people on speaker = phones, using just about mobile phone and so on, taking calls while = riding a bike and so on. But let's not get too wrapped up in this. This whole topic is a non = issue with a validation scheme that transferred some random secret in = the first second of the PSTN call then did real time validation followed = by moving the call (still in first few seconds of the call) from the = PSTN to the IP network. One can imagine how to insert this into the = audio by using watermarking or by fingerprinting existing media. A = validation scheme like this is much better than the start/stop time = based one proposed in the current vipr drafts but unfortunately it = requires changing something in the media path at both ends and doing = that takes longer to deploy. So the current validation scheme is pretty = easy to get rolled out as everything was already collecting CDR in some = form but a media path validation scheme could work in real time instead = of waiting to the end of the PSTN call to validate.=20 On Jul 6, 2010, at 9:00 AM, Peter Musgrave wrote: > Yeah. Sigh.=20 >=20 > I guess the issue then becomes whether this is enough of a step in = right direction that it can be built on - and whether it's worth the = effort.=20 >=20 > Cullen/Jonathan - can you speak to any of the operational issues = w.r.t. 'failure surprise' in the existing implementation? >=20 > Regards, >=20 > Peter Musgrave >=20 > On Tue, Jul 6, 2010 at 10:28 AM, Adam Roach wrote: > On 7/6/10 7:20 AM, Peter Musgrave wrote: > =46rom my perspective what this is really about is the ability for me = to have interoperable ad-hoc video calls between businesses which can be = established via SIP with a "good enough" level of authentication and = security. >=20 >=20 > You're looking in the wrong place, then. >=20 > The problem is that VIPR really provides something more like "random = failure surprise," as some portion of the call attempts must go over the = (non-video-capable) PSTN. The user doesn't have any idea about, or = control over, when this will happen. So while it might be something you = could use for personal purposes -- where frequent video call setup = failures would be okay -- I doubt it's a viable video solution in a = business environment. To run a business, you need something better than = "random failure surprise". >=20 > /a >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed Jul 7 21:36:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89D1C3A67B6 for ; Wed, 7 Jul 2010 21:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw0BlkMaq8yI for ; Wed, 7 Jul 2010 21:36:20 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 268573A67AB for ; Wed, 7 Jul 2010 21:36:20 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI7yNExAZnwM/2dsb2JhbACgGXGkM5pfhSUEg3mERg X-IronPort-AV: E=Sophos;i="4.53,556,1272844800"; d="scan'208";a="129850398" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Jul 2010 04:36:23 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o684aMaC017691; Thu, 8 Jul 2010 04:36:22 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4C3366B0.8080005@cisco.com> Date: Wed, 7 Jul 2010 22:36:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <2745B157-DE20-4C04-9CB1-3CA3568297A8@cisco.com> References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> <4C3366B0.8080005@cisco.com> To: Richard Shockey X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 04:36:21 -0000 Richard,=20 This is pretty different than self validation. Self validation, such as = DUNDI, is where a user Alice says that calls to 123 should go to here = and other people have to believe that and send call so 123 to Alice. = That is not what is going on here. Here Alice says, I'd like to be 123 = then Bob goes to validate that before Bob believes it. Bob phones 123 = over the PSTN at some random point in time for a random length of time. = Note this did use LNP and everything else to decide where the PSTN call = got routed to. If Alice really did get that call, then she knows the = start and stop time of it and can prove to Bob that she knows the start = and stop time. The reason the PVP draft makes your head want to explode = is partially due to the complexity is dealing with the errors in Bob and = Alice's measurement of the the start and stop time as well as make sure = that Alice can prove she knows the time without revealing what the time = actually was to an attacker but that's all standard crypto /security = stuff.=20 Note in no way did Alice need to use Bob's caller-ID. All this did was = level the inherent security in that the PSTN routes to the a call to 123 = to correct place and use that to leverage up a secure connection between = Alice and Bob on the IP network.=20 Hope that helps clarify On Jul 6, 2010, at 11:24 AM, Paul Kyzivat wrote: >=20 >=20 > Richard Shockey wrote: >> Paul of course I've read them, though the PVP document is uniquely = dense and >> gave me a headache. Security by ID Obscurity. My assertion still = stands. In the absence of any linkage in the PVP to the >> E164 numbering authorities and or databases any assertion about = verification >> and validation of a E.164 is in essence self validation. The charter = does >> NOT state that. My point is the proposed charter is badly written and >> implies a trust model that does not exist. >> You make a phone call if it answers and you hopefully get a caller ID = that >> hasn't been spoofed then maybe you are OK and maybe you hope the TTL = is set >> to some interval that doesn't cause number hijacking. But gee what = happens >> when the number is disconnected from the PSTN? Hummmm >> The use of the term validation and or verification here implies >> authentication and my assertion is that any authentication of the >> responsible domain for a E.164 number outside of the PSTN service = provider >> or national numbering authority is not possible under the current = regulatory >> circumstances. Consequently the charter implies an ability to = develop a >> solution which we all know is impossible.=20 >=20 > Perhaps better terms can be found and used. >=20 > But the end effect is that the destination you reach using ViPR has = the same assuredness of being who you thought it would be as an actual = PSTN call has. >=20 > For the most part, that is a level of assurance that many people are = comfortable with, even if we know that is not as reliable as most people = think it is. And regardless of whether it is as good as people would = like, it is as good as can be had in most cases with the current state = of the art. >=20 > Thanks, > Paul > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed Jul 7 21:56:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C0FD3A681A for ; Wed, 7 Jul 2010 21:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.19 X-Spam-Level: X-Spam-Status: No, score=-110.19 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THeZXpnXaIDX for ; Wed, 7 Jul 2010 21:56:35 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4F34D3A68FC for ; Wed, 7 Jul 2010 21:56:35 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD73NEyrR7Hu/2dsb2JhbACgGXGkJppfglyCSQSDeYRG X-IronPort-AV: E=Sophos;i="4.53,556,1272844800"; d="scan'208";a="555861716" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 08 Jul 2010 04:56:39 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o684ubQ9027105; Thu, 8 Jul 2010 04:56:38 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <017001cb1e13$df126e10$9d374a30$%roni@huawei.com> Date: Wed, 7 Jul 2010 22:56:37 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <018901cb0cd9$5ebc5af0$1c3510d0$%roni@huawei.com> <017001cb1e13$df126e10$9d374a30$%roni@huawei.com> To: Roni Even X-Mailer: Apple Mail (2.1081) Cc: 'DISPATCH list' Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTNReachability (VIPR) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 04:56:36 -0000 On Jul 7, 2010, at 2:34 PM, Roni Even wrote: > Cullen, > I am not talking about the vipr drafts but about the charter, I = thought we > are discussion a charter and not a solution. > "One initial validation protocol will be based on a domain being able = to > prove it received a particular phone call over the PSTN based on both = sides > knowing the start and stop times of that call" > What do you mean by "received a particular phone call" - my = understanding > from reading the sentence is that it is based on the caller ID; the = start > and stop time may not be unique, so my reading is that the charter = means > caller-id and start and stop time. By "particular call" I think the charter is trying to get at it is the = same call. There nothing mentioned anywhere about caller id in the = charter. Caller id + time would not be a very good identifer of a call = since many enterprises set all the caller of all outbound calls to the = same main number for the company. Any suggestions on how to make this = clearer in the charter?=20 >=20 > Roni Even >=20 >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Wednesday, July 07, 2010 10:57 PM >> To: Roni Even >> Cc: DISPATCH list >> Subject: Re: [dispatch] Charter Proposal: Verification Involving >> PSTNReachability (VIPR) >>=20 >>=20 >> On Jun 15, 2010, at 4:23 PM, Roni Even wrote: >>=20 >>> Hi Cullen, >>> I think that other standard body should be consulted like ITU. >>=20 >> What would you like to ask the ITU about? >>=20 >>> The reason is >>> that I see that one assumption is to use the PSTN numbering plan >> using also >>> the caller id. >>> My experience is that this is not information that can be >>> reliable when going between PSTN service providers and it gets worse >> on >>> international calls. >>=20 >> Yes, caller-id is often missing and is trival to spoof. That is why >> none of vipr drafts uses calling name or number. I'm not really sure >> what you are getting at here. >>=20 >>=20 >>> Roni Even >>>=20 >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >> On >>>> Behalf Of Cullen Jennings >>>> Sent: Tuesday, June 01, 2010 7:55 PM >>>> To: DISPATCH list >>>> Subject: [dispatch] Charter Proposal: Verification Involving PSTN >>>> Reachability (VIPR) >>>>=20 >>>>=20 >>>> I've been talking to a lot of people about the VIPR drafts - here >> is a >>>> first cut of a proposal for a WG that could do this. I'm sure the >>>> charter proposal needs a bunch of work but I wanted to get the >>>> discussion rolling on the list. >>>>=20 >>>> Thanks, Cullen >>>>=20 >>>> (PS - this is sent in my individual contributor role. Take all my >> posts >>>> about VIPR to be in my individual role not my co-chair role) >>>>=20 >>>> ------------------------------------------------------- >>>>=20 >>>> ViPR Charter Proposal (Version 0) >>>>=20 >>>> WG Name: Verification Involving PSTN Reachability (VIPR) >>>>=20 >>>> There are two globally deployed address spaces for communications >> that >>>> more than a billion people use on a daily basis. They are phone >> numbers >>>> and DNS rooted address such as web servers and email addresses. The >>>> federation design of SIP is primarily designed for email style >>>> addresses yet a large percentage of SIP deployments primarily use >> phone >>>> numbers for identifying users. The goal of this working group is to >>>> allows people to use SIP to federate over the the internet while >> still >>>> using phone numbers to identify the person they wish to communicate >>>> with. >>>>=20 >>>> The VIPR WG will address this problem by developing a peer to peer >>>> based approach to finding SIP domains that claim to be responsible >> for >>>> a given phone number and the WG will design validation protocols to >>>> ensure a reasonable likelihood that a given domain actually is >>>> responsible for the phone number. One initial validation protocol >> will >>>> be based on a domain being able to prove it received a particular >> phone >>>> call over the PSTN based on both sides knowing the start and stop >> times >>>> of that call. Other validation schemes, such as examining >> fingerprints >>>> or watermarking of PSTN media, to show that a domain received a >>>> particular PSTN phone call may be considered by the working group. >> To >>>> help mitigate SPAM over SIP issues, the WG will define an token >> based >>>> authorization scheme so that domain using SIP to federate can >> choose to >>>> check that incoming SIP calls are from a domain that successfully >>>> validated a phone number. >>>>=20 >>>> The problem statement and some possible starting points for >> solutions >>>> are further desired in the following internet drafts which shall >> form >>>> the bases of the WG documents: >>>> draft-rosenberg-dispatch-vipr-overview >>>> draft-rosenberg-dispatch-vipr-reload-usage >>>> draft-rosenberg-dispatch-vipr-pvp >>>> draft-rosenberg-dispatch-vipr-sip-antispam >>>>=20 >>>> The working group will carefully coordinate with the security area, >> O&M >>>> area, as well as the appropriate RAI WG including sipcore and >> p2psip. >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>=20 >>>=20 >>=20 >>=20 >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>=20 >=20 >=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From dwing@cisco.com Wed Jul 7 22:00:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B9F3A68FC; Wed, 7 Jul 2010 22:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.436 X-Spam-Level: X-Spam-Status: No, score=-10.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zelNw6SOtNje; Wed, 7 Jul 2010 22:00:41 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 2404C3A68C8; Wed, 7 Jul 2010 22:00:41 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,556,1272844800"; d="scan'208";a="223243902" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 08 Jul 2010 05:00:45 +0000 Received: from dwingWS ([10.21.73.198]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6850h06016645; Thu, 8 Jul 2010 05:00:44 GMT From: "Dan Wing" To: "'Richard Shockey'" , "'Paul Kyzivat'" References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> In-Reply-To: <008d01cb1c72$9bdb96a0$d392c3e0$@us> Date: Wed, 7 Jul 2010 22:00:44 -0700 Message-ID: <2a2201cb1e5a$85b5df90$91219eb0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-Index: AcscaX8dN4iSVSfAR6+wCu3OeaBQegABPUEwAGgp2uA= Cc: 'DISPATCH' , 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 05:00:43 -0000 > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of > Richard Shockey > Sent: Monday, July 05, 2010 11:48 AM > To: 'Paul Kyzivat' > Cc: 'DISPATCH'; 'IETF-Discussion list'; 'Peter Musgrave' > Subject: RE: [dispatch] VIPR - proposed charter version 3 > > Paul of course I've read them, though the PVP document is uniquely > dense and gave me a headache. Security by ID Obscurity. > > My assertion still stands. In the absence of any linkage in the PVP to > the E164 numbering authorities and or databases any assertion about > verification and validation of a E.164 is in essence self validation. > The charter does NOT state that. My point is the proposed charter is badly > written and implies a trust model that does not exist. I guess your "no-SS7" hat doesn't fit anymore? That trust model which "does not exist" is exactly the trust model that we all use, daily, whenever we dial the pizza joint across the street, the paint contractor with the spiffy one-page advertisement in the yellow pages, pay FedEx or the postal service to deliver a package, or pay a shipper to send a crate full of Champagne from France to some other country, or call the Sears & Roebuck catalog number give them our credit card and expect them to use a shipper (FedEx/postal service/UPS/DHL) to send us the product. I agree that trust model is imperfect. But that trust model is what delivers almost all of the commerce and business in the world. To assert that this trust model "does not exist" is a false assertion. > You make a phone call if it answers and you hopefully get a caller ID > that > hasn't been spoofed then maybe you are OK and maybe you hope the TTL is > set > to some interval that doesn't cause number hijacking. But gee what > happens when the number is disconnected from the PSTN? Hummmm Similar disconnections (and resales) of telephone numbers happen, today, on the PSTN. I dial a restaurant (now out of business) which has taken over the same physical location (oh my gosh, Identity Thieves!) and paid to acquire the previous restaurant's phone number. Other, non-restaurant businesses do similar things. SBC bought the assets of AT&T including its brand name, doing something similar with the att.com domain itself and, I'm sure, with its 800 services. So, it's not as if querying SS7 would provide some magic sauce to prevent the problem. The problem is different, to be sure, just as IP addresses, domain names, physical (street) addresses, email addresses, telephone numbers, are not all quite exactly "the same". But each is considered an "identity" to a varying degree. > The use of the term validation and or verification here implies > authentication and my assertion is that any authentication of the > responsible domain for a E.164 number outside of the PSTN service > provider > or national numbering authority is not possible under the current > regulatory circumstances. Consequently the charter implies an > ability to develop a solution which we all know is impossible. I disagree. > Solution rewrite the charter to note that fact that this is, in fact, > "best efforts" only, "full disclosure" or "caveat emptor" to be > precise. Once I know someone owned an E.164 and I can, afterwards, do crypto to ensure I know I'm talking to the same entity -- that is *far* more reliable than what occurs, today, on the PSTN. The PSTN where phone numbers are bought and sold willy-nilly. > I'm not saying it might not work. As I used to tell Mark Spencer about > DUNDI > it's a fine intra-domain PBX session routing protocol. Might work in > some > highly integrated industries like airlines, auto etc but the empirical > evidence indicates a uphill battle. -d > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Monday, July 05, 2010 1:43 PM > To: Richard Shockey > Cc: 'Peter Musgrave'; 'DISPATCH'; 'IETF-Discussion list' > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > Richard, > > Have you actually read and understood the drafts that Jonathan > submitted > on ViPR? I don't see how you could make the assertions you are making > if > you had. > > Thanks, > Paul > > Richard Shockey wrote: > > Well folks can certainly do what they want to do. And the IETF has a > > lamentable record of some protocols that don't accomplish much. But > the > > core of this proposed WG is based on a fallacy. ViPR cannot verify or > > authenticate the responsible party for a E.164 number. It is > incapable > > of doing so since there is no possible administrative chain of trust > > other than self assertion . Hence the possibility of identity or > > number/session hijacking is very large. You have to have the > cooperation > > of the national numbering authorities or the issuer of the phone > number > > to authenticate who is the responsible party . ViPR doesn't change > that > > problem either. > > > > > > > > This has been a well known problem in SIP for some time and that was > > part of the difficulties that public ENUM had in e164.arpa. ENUM is > > doing very well BTW as a SS7/TCAP replacement however in private > trees > BTW. > > > > > > > > Consequently I think this issue has to be fully defined in the > charter > > and I will gleefully anticipate what the security considerations text > > will look like. > > > > > > > > The fact that there is CISCO running code is utterly irrelevant. > There > > is lots of bad code out there. I understand the problem of how do > you > > create SIP federations across domains outside the scope of service > > providers, but without a comprehensive trust model this is going to > > fail. I do understand that many folks don't like their voice service > > providers or PSTN that perpetuates the use of E.164 numbers but this > > proposal is not going to solve that. > > > > > > > > IMHO in the absence of any rational trust or security model you can > > certainly publish something as Informational but getting something > past > > the IESG is another thing entirely. > > > > > > > > *From:* Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > > *Sent:* Saturday, July 03, 2010 5:49 PM > > *To:* Richard Shockey > > *Cc:* Romascanu, Dan (Dan); Mary Barnes; DISPATCH; IETF-Discussion > list > > *Subject:* Re: [dispatch] VIPR - proposed charter version 3 > > > > > > > > Hi Richard, > > > > > > > > Clearly we don't want to be trying to solve the impossible - that > could > > take a really long time. > > > > > > > > The mechanism in the ViPR drafts seemed to be able to accomplish the > > "finding the party responsible for a number" - and IIRC this is based > on > > *running code* in the Cisco IME. > > > > > > > > ViPR is frankly not beautiful (in the way ICE is not beautiful) but I > do > > think it can solve a problem which needs to be solved. Hence I > support it. > > > > > > > > > Peter Musgrave > > > > On Sat, Jul 3, 2010 at 2:33 PM, Richard Shockey > > wrote: > > > > A we already have centralized solutions for interdomain routing based > on > > E.164. its called ENUM in both its private and public instantiations. > It > > works pretty well BTW and globally deployed. > > > > IMHO this charter is a non starter and should not be approved on the > basis > > of this statement alone. > > > > "finding domains that claim to be responsible for a given phone > number" > > > > This IMHO is flat out impossible. Validating or authenticating an > entity > > that is "responsible for a phone number" is as bad as " who is the > carrier > > of record" , is a massive rathole. Cullen and Johathan should know > better. > > Certs? LNP ? > > > > We have this problem of E.164 validation all the time in SIP and its > not > > going to be solved in the IETF. > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org ] > On > > Behalf > > Of Romascanu, Dan (Dan) > > Sent: Wednesday, June 30, 2010 11:33 AM > > To: Mary Barnes > > Cc: DISPATCH; IETF-Discussion list > > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > > > It looks to me that one can imagine 'centralized' solutions which are > > also based on reusing SIP related functionality developed in RAI. I > > would rather not close such an option and allow the WG a window of > > opportunity in which alternate solutions that could meet the same > goals > > can be presented. > > > > Dan > > > > > > > -----Original Message----- > > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com > > ] > > > Sent: Wednesday, June 30, 2010 6:24 PM > > > To: Romascanu, Dan (Dan) > > > Cc: DISPATCH; IETF-Discussion list > > > Subject: Re: [dispatch] VIPR - proposed charter version 3 > > > > > > Hi Dan, > > > > > > The term peer to peer is intended to exclude mechanisms that > > > would use a central repository for the information: This was > > > discussed in an earlier thread: > > > http://www.ietf.org/mail- > archive/web/dispatch/current/msg02027.html > > > > > > In one sense it is a solution, however, in another sense it > > > is reusing SIP related functionality defined in RAI and thus > > > is in a similar vein as specifying the use of SIP in a charter. > > > > > > Thanks, > > > Mary. > > > > > > On Wed, Jun 30, 2010 at 5:42 AM, Romascanu, Dan (Dan) > > > > wrote: > > > >> The VIPR WG will address this problem by developing a peer to > peer > > > >> based approach to finding domains that claim to be > > > responsible for a > > > >> given phone number and validation protocols to ensure a > reasonable > > > >> likelihood that a given domain actually is responsible for > > > the phone > > > >> number. > > > > > > > > Hi, > > > > > > > > Clarification question. What exactly means 'peer to peer > > > based approach' > > > > and what kind of approaches are excluded by having this in > > > the charter. > > > > Does 'approach' mean solution? If so why does a specific type of > > > > solution need to be agreed in the charter, while all we > > > have at hand > > > > at this point are individual contribution I-Ds that describe the > > > > 'problem statement and some possible starting points for > solutions'? > > > > > > > > Thanks and Regards, > > > > > > > > Dan > > > > > > > > > > > >> -----Original Message----- > > > >> From: dispatch-bounces@ietf.org bounces@ietf.org> > > > >> [mailto:dispatch-bounces@ietf.org > > ] On Behalf Of Mary Barnes > > > >> Sent: Monday, June 28, 2010 8:38 PM > > > >> To: DISPATCH > > > >> Subject: [dispatch] VIPR - proposed charter version 3 > > > >> > > > > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From Even.roni@huawei.com Wed Jul 7 22:11:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577923A6974 for ; Wed, 7 Jul 2010 22:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Y2O2UkIqtVJ for ; Wed, 7 Jul 2010 22:11:41 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 957523A6993 for ; Wed, 7 Jul 2010 22:11:37 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5800JPM3R48O@szxga03-in.huawei.com> for dispatch@ietf.org; Thu, 08 Jul 2010 13:11:28 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L58006VX3R4CL@szxga03-in.huawei.com> for dispatch@ietf.org; Thu, 08 Jul 2010 13:11:28 +0800 (CST) Received: from windows8d787f9 (bzq-109-66-52-27.red.bezeqint.net [109.66.52.27]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L58009EI3QTK5@szxml01-in.huawei.com>; Thu, 08 Jul 2010 13:11:28 +0800 (CST) Date: Thu, 08 Jul 2010 08:10:51 +0300 From: Roni Even In-reply-to: To: 'Cullen Jennings' Message-id: <018e01cb1e5b$f79363c0$e6ba2b40$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcseWgpdMoMZFRGIS0Gto9liWYyUFwAAdMlg References: <018901cb0cd9$5ebc5af0$1c3510d0$%roni@huawei.com> <017001cb1e13$df126e10$9d374a30$%roni@huawei.com> Cc: 'DISPATCH list' Subject: Re: [dispatch] Charter Proposal: Verification Involving PSTNReachability (VIPR) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 05:11:46 -0000 Cullen, Version 4 of the charter fixed it Roni > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Thursday, July 08, 2010 7:57 AM > To: Roni Even > Cc: 'DISPATCH list' > Subject: Re: [dispatch] Charter Proposal: Verification Involving > PSTNReachability (VIPR) > > > On Jul 7, 2010, at 2:34 PM, Roni Even wrote: > > > Cullen, > > I am not talking about the vipr drafts but about the charter, I > thought we > > are discussion a charter and not a solution. > > "One initial validation protocol will be based on a domain being able > to > > prove it received a particular phone call over the PSTN based on both > sides > > knowing the start and stop times of that call" > > What do you mean by "received a particular phone call" - my > understanding > > from reading the sentence is that it is based on the caller ID; the > start > > and stop time may not be unique, so my reading is that the charter > means > > caller-id and start and stop time. > > By "particular call" I think the charter is trying to get at it is the > same call. There nothing mentioned anywhere about caller id in the > charter. Caller id + time would not be a very good identifer of a call > since many enterprises set all the caller of all outbound calls to the > same main number for the company. Any suggestions on how to make this > clearer in the charter? > > > > > Roni Even > > > >> -----Original Message----- > >> From: Cullen Jennings [mailto:fluffy@cisco.com] > >> Sent: Wednesday, July 07, 2010 10:57 PM > >> To: Roni Even > >> Cc: DISPATCH list > >> Subject: Re: [dispatch] Charter Proposal: Verification Involving > >> PSTNReachability (VIPR) > >> > >> > >> On Jun 15, 2010, at 4:23 PM, Roni Even wrote: > >> > >>> Hi Cullen, > >>> I think that other standard body should be consulted like ITU. > >> > >> What would you like to ask the ITU about? > >> > >>> The reason is > >>> that I see that one assumption is to use the PSTN numbering plan > >> using also > >>> the caller id. > >>> My experience is that this is not information that can be > >>> reliable when going between PSTN service providers and it gets > worse > >> on > >>> international calls. > >> > >> Yes, caller-id is often missing and is trival to spoof. That is why > >> none of vipr drafts uses calling name or number. I'm not really sure > >> what you are getting at here. > >> > >> > >>> Roni Even > >>> > >>>> -----Original Message----- > >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > >> On > >>>> Behalf Of Cullen Jennings > >>>> Sent: Tuesday, June 01, 2010 7:55 PM > >>>> To: DISPATCH list > >>>> Subject: [dispatch] Charter Proposal: Verification Involving PSTN > >>>> Reachability (VIPR) > >>>> > >>>> > >>>> I've been talking to a lot of people about the VIPR drafts - here > >> is a > >>>> first cut of a proposal for a WG that could do this. I'm sure the > >>>> charter proposal needs a bunch of work but I wanted to get the > >>>> discussion rolling on the list. > >>>> > >>>> Thanks, Cullen > >>>> > >>>> (PS - this is sent in my individual contributor role. Take all my > >> posts > >>>> about VIPR to be in my individual role not my co-chair role) > >>>> > >>>> ------------------------------------------------------- > >>>> > >>>> ViPR Charter Proposal (Version 0) > >>>> > >>>> WG Name: Verification Involving PSTN Reachability (VIPR) > >>>> > >>>> There are two globally deployed address spaces for communications > >> that > >>>> more than a billion people use on a daily basis. They are phone > >> numbers > >>>> and DNS rooted address such as web servers and email addresses. > The > >>>> federation design of SIP is primarily designed for email style > >>>> addresses yet a large percentage of SIP deployments primarily use > >> phone > >>>> numbers for identifying users. The goal of this working group is > to > >>>> allows people to use SIP to federate over the the internet while > >> still > >>>> using phone numbers to identify the person they wish to > communicate > >>>> with. > >>>> > >>>> The VIPR WG will address this problem by developing a peer to peer > >>>> based approach to finding SIP domains that claim to be responsible > >> for > >>>> a given phone number and the WG will design validation protocols > to > >>>> ensure a reasonable likelihood that a given domain actually is > >>>> responsible for the phone number. One initial validation protocol > >> will > >>>> be based on a domain being able to prove it received a particular > >> phone > >>>> call over the PSTN based on both sides knowing the start and stop > >> times > >>>> of that call. Other validation schemes, such as examining > >> fingerprints > >>>> or watermarking of PSTN media, to show that a domain received a > >>>> particular PSTN phone call may be considered by the working group. > >> To > >>>> help mitigate SPAM over SIP issues, the WG will define an token > >> based > >>>> authorization scheme so that domain using SIP to federate can > >> choose to > >>>> check that incoming SIP calls are from a domain that successfully > >>>> validated a phone number. > >>>> > >>>> The problem statement and some possible starting points for > >> solutions > >>>> are further desired in the following internet drafts which shall > >> form > >>>> the bases of the WG documents: > >>>> draft-rosenberg-dispatch-vipr-overview > >>>> draft-rosenberg-dispatch-vipr-reload-usage > >>>> draft-rosenberg-dispatch-vipr-pvp > >>>> draft-rosenberg-dispatch-vipr-sip-antispam > >>>> > >>>> The working group will carefully coordinate with the security > area, > >> O&M > >>>> area, as well as the appropriate RAI WG including sipcore and > >> p2psip. > >>>> > >>>> > >>>> _______________________________________________ > >>>> dispatch mailing list > >>>> dispatch@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/dispatch > >>> > >>> > >> > >> > >> Cullen Jennings > >> For corporate legal information go to: > >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >> > > > > > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > From fluffy@cisco.com Wed Jul 7 23:45:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EF0E3A6803 for ; Wed, 7 Jul 2010 23:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.856 X-Spam-Level: X-Spam-Status: No, score=-109.856 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McicYNq7tD1G for ; Wed, 7 Jul 2010 23:45:52 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 9142F3A659B for ; Wed, 7 Jul 2010 23:45:52 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAcRNUyrRN+J/2dsb2JhbACgG3GkCppnhSUEg3mERg X-IronPort-AV: E=Sophos;i="4.53,556,1272844800"; d="scan'208";a="266252971" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2010 06:45:56 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o686jINC004845; Thu, 8 Jul 2010 06:45:55 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <35FE871E2B085542A35726420E29DA6B044A97DA@gaalpa1msgusr7a.ugd.att.com> Date: Thu, 8 Jul 2010 00:45:54 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <001201cb1ade$4195f680$c4c1e380$@us> <35FE871E2B085542A35726420E29DA6B044A97DA@gaalpa1msgusr7a.ugd.att.com> To: "PFAUTZ, PENN L (ATTCORP)" X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 06:45:54 -0000 This is definitely worth talking about. Let's take the case of a two = mobile providers where the user ported a number, say 123, out of = provider A and into provider B. It's easy to imagine that a provider A = might do VIPR for all it's mobile phones that were video enabled so that = theses phones could make video calls to enterprise and home video = systems. It would also be possible to do this using an over the top = approach but lets assume carrier A did do VIPR for it's phones. Now the = 123 number ports from A to B. If carrier A wanted to play nice they = could just remove their DHT entry for the number 123, however, lets = assume they don't do that. Eventually the validation for 123 to A is = going to expire and user will revalidate to B but in the meantime, users = are going to see both A and B advertising 123 - A may have validated in = the past but only B will validate after the port. This should likely = trigger and early re-validation but it can't be instant or it is a DOS = attack vector. Before the re-validation happens that will move stuff to = B, A is going to get call to 123 which is a number they ported to B. A = may be required in some jurisdiction to actually forward the call to B. = Keep in mind that when you port a number from A to B, A could easily not = route any calls from their network to 123 over to B. But they do route = calls to 123 over to B for business and legal reasons. In the over the = top case, the legal and business reason may not be there but it is = likely the end user or enterprise so the number has not changed.=20 A related issue that is in my opinion a much larger issue is when a user = cancels there phone number and the provider gives the number to a new = user. In this case the current VIRP drafts propose having the validation = time be less than the time the provider waits to give out old number to = a new user.=20 On Jul 7, 2010, at 2:05 PM, PFAUTZ, PENN L (ATTCORP) wrote: > Cullen: > I think you example represents one of the concerns some of us have. = Say > you've temporarily set up forwarding or used a specific long distance > carrier for a particular call. Should the forwarded-to or currently > chosen carrier be able to represent itself as a domain that should be > routed to once you remove forwarding or stop using a particular LD > carrier? Likewise, if you (God forbid:-) port your number from AT&T to > Verizon will there be mechanisms to delete AT&T as a route-to domain? >=20 > Penn=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Wednesday, July 07, 2010 3:56 PM > To: Richard Shockey > Cc: DISPATCH list > Subject: Re: [dispatch] VIPR - proposed charter version 3 >=20 >=20 > I agree with Richard that finding the single administrative = organization > that "owns" a phone number is a huge rat hole but that's not what we = are > trying to do with "responsible" in this context - I would like to = point > out the charter text >=20 > In this context, "responsible" means an > administrative domain, which is at least one of the domains, to > which > a PSTN call to this phone number would be routed. >=20 > So let's consider my mobile phone number. It's an AT&T plan, so AT&T > could route it anywhere. It's in the US so Nuestar could change the = LNP > database to route it anywhere. Cisco pays for it so I imagine the = right > Cisco person could call up AT&T and have the number sent to anywhere. > It's my number in that Cisco lets make take it when I leave and I can > move it to another carrier of my choosing so I can make it go = anywhere. > Right now it is forwarded to google voice because I am in Calgary and > want it to ring my phone at home instead of paying roaming charges. > (Thank you Google for making the one place you can use google voice > outside the US be where I just happen to live). So Google could route = it > anywhere - they currently are routing it to Rogers, Tellus, AT&T, and > probably a few more - any of those carriers could route it anywhere. = And > google uses someone like Level 3 to do that routing so they could = route > it anywhere. And who knows how many other internet or PSTN transit = prov > iders and peering like providers had a chance to route it anywhere. = The > sheer number of SS7 dips that happen in a single call to my cell = number > results in is probably more than the SS7 vendors ever imagined in = their > wildest dreams. Yah VoIP. So in some sense all these operators are > "responsible" for making sure that my call is not say routed to the > wrong place. However, they seem to do a fine job of that and if they > stopped doing a fine job of that I would adjust the carriers > "responsible" for my number such that they did do a fine job of it.=20 >=20 > Part of the idea in ViPR was to realize that finding a single owner of = a > number is a rat hole and instead focus on the fact that several = domains > all cooperate to terminate a call to a given number. So I don't see a > problem with the "responsible" - it nicely side steps the whole > "ownership" issue with numbers yet still results in a workable = solution > that results in similar security properties to the existing PSTN which > seem to be adequate for many purposes. >=20 > Cullen >=20 > ( and just to repeat my previous email on the subject, all my posts > related to VIPR are from me as an individual contributor and not as > chair. Mary will handle the chair stuff for this topic ) >=20 >=20 > On Jul 3, 2010, at 12:33 PM, Richard Shockey wrote: >=20 >>=20 >> "finding domains that claim to be responsible for a given phone > number" >>=20 >> This IMHO is flat out impossible. Validating or authenticating an > entity >> that is "responsible for a phone number" is as bad as " who is the > carrier >> of record" , is a massive rathole. Cullen and Johathan should know > better. >> Certs? LNP ?=20 >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Wed Jul 7 23:46:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A6B73A6A03 for ; Wed, 7 Jul 2010 23:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.042 X-Spam-Level: X-Spam-Status: No, score=-110.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qUiORe3HVaa1 for ; Wed, 7 Jul 2010 23:46:12 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id C1CB73A69B1 for ; Wed, 7 Jul 2010 23:46:12 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,556,1272844800"; d="scan'208";a="342047182" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 08 Jul 2010 06:46:16 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o686jIND004845; Thu, 8 Jul 2010 06:46:15 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C333D2@xmb-sjc-221.amer.cisco.com> Date: Thu, 8 Jul 2010 00:46:15 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C333D2@xmb-sjc-221.amer.cisco.com> To: Allyn Romanow (allyn) X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list , "Botzko, Stephen" Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 06:46:14 -0000 Theses look great - I hope people on the list take some time to read them. On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote: > Hi Cullen, > > We just put out a problem statement draft - > http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-prob-stat > ement-00. The document is not complete, but we feel it is a solid > beginning. It does address the example you mention. The use case doc > also describes this case in some detail. > http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases > -00 > > > Do you not feel that the problem statement draft can serve as a good > basis for discussion of problems? > > Thanks, > Allyn > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings (fluffy) > Sent: Wednesday, July 07, 2010 9:41 AM > To: DISPATCH list > Subject: Re: [dispatch] Charter for Telepresence multi-streams - > thirdversion > > > I'm wondering if we could get a thread going about what are some of the > specific problems we need to solve then dispatch theses problems to > appropriate WGs. > > For example one problem is when a session involves two video session on > multiple screens how does one signal which stream is displayed on the > right and left screen. > > I think having a list of specific problems would help get this moving > faster. > > Cullen > > > On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote: > >> Folks, >> This makes the change discussed replacing the text in the third > paragraph under the Charter section with the text suggested on the list. >> It also changes title from "... Description of Work" to "...Charter" >> >> There weren't any further changes suggested. >> >> Thanks, >> Allyn >> >> >> >> >> Multi-streams for Telepresence Charter >> >> >> >> Background >> One branch of video conferencing has evolved that is focused on > immersive "being there" experience. Referred to in various ways such as > virtual conferencing, telepresence or media spaces, early systems were > mainly research projects or business systems with limited deployments. > In recent years telepresence systems have seen considerable market > success. Following the model of early systems, the first wave of > commercial systems have been typically located in specially designed > single-purpose rooms with multiple relatively large displays permitting > life size image reproduction, multiple cameras, encoders, decoders and > microphones. These systems have several important characteristics that > are different from more traditional video conferencing systems. >> >> The first difference concerns controlling the visual viewpoint in > order to improve participant nonverbal communication. These systems > preserve essential group meeting characteristics such as eye contact, > group gestures, seating order and spatial audio by carefully > orchestrating the miking and camera angles at each of the sites . This > is distinct from the more traditional approach where the geometric > relationship between media streams is not used to preserve inter-stream > communication aspects such as eye contact and group dynamics. >> >> A second difference is manipulation of the environment to improve > immersion. With telepresence systems, cinematographic aspects of the > local environment reproduction are carefully planned including color, > table shape, seating and lighting so that when combined with large high > quality displays, a strong sense of a "trompe l'oeil" or "being there" > immersive experience is created. Typical video conference systems do > not include these considerations. >> >> As telepresence video systems have become successful in the market, > manufacturers have started exploring delivery of the nonverbal > communication and immersive values of telepresence via smaller, less > expensive and more flexible video conferencing systems for a variety of > venues, such as individual offices, homes and kiosks. These are also > telepresence systems, since the audio and video quality is high enough > to allow clear image reproduction for nonverbal communication, they are > able to send and receive multiple media streams, and large coordinated > multi image displays are available for immersive installations. As the > industry develops, the line between telepresence and video conferencing > may become blurred as nonverbal communication and immersive > installations become broadly available. >> >> Problem >> Although telepresence systems are based on open standards such as RTP, > SIP, H.264, H.323 suite, they cannot easily interoperate with each other > without operator assistance and expensive additional equipment that > translates from one vendor to another. It would be like having to make > sure all parties are on the same equipment (and network) when making a > telephone call. A major factor in the inability of Telepresence systems > to work with each other is that there is no standard description of the > multiple streams that comprise the media flows. >> >> For example, in a multiple screen conference, the video and audio > streams sent from remote participants must be understood by receivers so > that they can be presented in a coherent and life-like manner. This > includes the ability to present the remote participants at their true > size for their apparent distance, while maintaining correct eye contact, > gesticular cues, and simultaneously providing a spatial audio sound > stage consistent with the video presentation. The receiving device that > decides how to display the incoming information needs to understand a > number of variables such as the spatial position of the speaker, the > field of view of the cameras, the camera zoom, which media stream is > related to each of the displays, etc. >> >> Charter >> The Telepresence Multi-Streams work item in DISPATCH is chartered to > define and specify for SIP-based systems the content of media > multi-stream messages and the way these will be transported. >> >> This work will provide a standard for the exchange of media semantic > information that will foster interoperable end stations and conference > bridges. It will specify variables that describe the semantics of the > media streams and the recommended behavior to achieve interoperability. >> >> >> This requires considering current widely deployed use cases, as well > as cases that are expected to be implemented using the protocol > framework produced by this work item. The methodology for describing > the variables must allow extensibility of the variables, since > telepresence is still a young technology and may have use cases that are > not currently considered." >> >> >> The work item will identify use cases, define requirements, and define > a method for describing and transporting information about multiple > media streams, including a specification of variables required to > support the use cases. This work item will consider the reuse of > existing IETF protocols and produce an architecture/protocol framework > document describing the protocols required to be implemented to support > this functionality. The document will identify any enhancements > required to existing protocols as well as describing new protocol(s) for > interoperable multi-streams negotiation that may be required. >> >> Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and > FECframe. >> >> >> Scope >> The scope includes both systems that provide a fully immersive > experience, and systems that interwork with them and therefore need to > understand the same multiple stream semantics. >> >> >> The focus of this work is on audio and video multiple streams. Other > media types may be considered, however development of methodologies for > them is not within the scope of this work. >> >> Interoperation with standards compliant systems is required, such as > SIP-based video conferencing systems. However, backwards compatibility > with existing non-standards compliant telepresence systems is not > required. >> >> >> >> The group will produce >> - Requirements and use cases >> >> - Architectural Framework describing the protocols required to be > implemented to support this functionality and identifying existing > protocol enhancements and new protocol functionality required >> >> - Specification of a new protocol to support telepresence > multi-streams [if required] >> >> Goals and Milestones >> Nov 2010 >> >> Use Cases and Requirements to IESG as Informational RFC >> Nov 2010 >> March 2011 >> Problem Statement to IESG as Informational RFC >> Architecture to IESG as Informational RFC >> March 2011 >> Revise Charter [IF new protocol is not required] >> Nov 2011 >> Submit protocol draft to IESG as Proposed Standard RFC >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From peter.musgrave@magorcorp.com Thu Jul 8 03:45:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7954D3A6A39 for ; Thu, 8 Jul 2010 03:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csPfWkTsmKiV for ; Thu, 8 Jul 2010 03:45:48 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id F2ADC3A6A17 for ; Thu, 8 Jul 2010 03:45:47 -0700 (PDT) Received: by qyk2 with SMTP id 2so2831394qyk.10 for ; Thu, 08 Jul 2010 03:45:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.69.20 with SMTP id x20mr4421577qai.347.1278585948874; Thu, 08 Jul 2010 03:45:48 -0700 (PDT) Received: by 10.229.220.10 with HTTP; Thu, 8 Jul 2010 03:45:48 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C333D2@xmb-sjc-221.amer.cisco.com> Date: Thu, 8 Jul 2010 06:45:48 -0400 Message-ID: From: Peter Musgrave To: Cullen Jennings Content-Type: multipart/alternative; boundary=001485ec0f4e4c2726048addfd35 Cc: DISPATCH list , "Botzko, Stephen" Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 10:45:50 -0000 --001485ec0f4e4c2726048addfd35 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Allyn/Stephen, I read through these. I think they do a good job of establishing scope and raising issues and as a bonus they are very easy to read. Is there a need to talk about interop with standard video SIP gear? If I us= e a TP suite to call a desktop SIP client or a 1080p video conferencing terminal is there anything about how that should behave that is worth defining under this work or is that viewed as out of scope? As for draft-romanow-dispatch-telepresence-use-cases-00.txt 1. (nit) *"*This draft =85" paragraph has a number of A's sprinkled in (typos?) 3. "We describe=85display stream" I assume display stream is a stream from = a document camera (as distinct from video stream being from a participant camera?). This term does not match the words used in the previous paragraph= . Thanks, Peter Musgrave On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings wrote: > > Theses look great - I hope people on the list take some time to read them= . > > On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote: > > > Hi Cullen, > > > > We just put out a problem statement draft - > > http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-prob-sta= t > > ement-00. The document is not complete, but we feel it is a solid > > beginning. It does address the example you mention. The use case doc > > also describes this case in some detail. > > http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-case= s > > -00 > > > > > > Do you not feel that the problem statement draft can serve as a good > > basis for discussion of problems? > > > > Thanks, > > Allyn > > > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Cullen Jennings (fluffy) > > Sent: Wednesday, July 07, 2010 9:41 AM > > To: DISPATCH list > > Subject: Re: [dispatch] Charter for Telepresence multi-streams - > > thirdversion > > > > > > I'm wondering if we could get a thread going about what are some of the > > specific problems we need to solve then dispatch theses problems to > > appropriate WGs. > > > > For example one problem is when a session involves two video session on > > multiple screens how does one signal which stream is displayed on the > > right and left screen. > > > > I think having a list of specific problems would help get this moving > > faster. > > > > Cullen > > > > > > On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote: > > > >> Folks, > >> This makes the change discussed replacing the text in the third > > paragraph under the Charter section with the text suggested on the list= . > >> It also changes title from "... Description of Work" to "...Charter" > >> > >> There weren't any further changes suggested. > >> > >> Thanks, > >> Allyn > >> > >> > >> > >> > >> Multi-streams for Telepresence Charter > >> > >> > >> > >> Background > >> One branch of video conferencing has evolved that is focused on > > immersive "being there" experience. Referred to in various ways such a= s > > virtual conferencing, telepresence or media spaces, early systems were > > mainly research projects or business systems with limited deployments. > > In recent years telepresence systems have seen considerable market > > success. Following the model of early systems, the first wave of > > commercial systems have been typically located in specially designed > > single-purpose rooms with multiple relatively large displays permitting > > life size image reproduction, multiple cameras, encoders, decoders and > > microphones. These systems have several important characteristics that > > are different from more traditional video conferencing systems. > >> > >> The first difference concerns controlling the visual viewpoint in > > order to improve participant nonverbal communication. These systems > > preserve essential group meeting characteristics such as eye contact, > > group gestures, seating order and spatial audio by carefully > > orchestrating the miking and camera angles at each of the sites . This > > is distinct from the more traditional approach where the geometric > > relationship between media streams is not used to preserve inter-stream > > communication aspects such as eye contact and group dynamics. > >> > >> A second difference is manipulation of the environment to improve > > immersion. With telepresence systems, cinematographic aspects of the > > local environment reproduction are carefully planned including color, > > table shape, seating and lighting so that when combined with large high > > quality displays, a strong sense of a "trompe l'oeil" or "being there" > > immersive experience is created. Typical video conference systems do > > not include these considerations. > >> > >> As telepresence video systems have become successful in the market, > > manufacturers have started exploring delivery of the nonverbal > > communication and immersive values of telepresence via smaller, less > > expensive and more flexible video conferencing systems for a variety of > > venues, such as individual offices, homes and kiosks. These are also > > telepresence systems, since the audio and video quality is high enough > > to allow clear image reproduction for nonverbal communication, they are > > able to send and receive multiple media streams, and large coordinated > > multi image displays are available for immersive installations. As th= e > > industry develops, the line between telepresence and video conferencing > > may become blurred as nonverbal communication and immersive > > installations become broadly available. > >> > >> Problem > >> Although telepresence systems are based on open standards such as RTP, > > SIP, H.264, H.323 suite, they cannot easily interoperate with each othe= r > > without operator assistance and expensive additional equipment that > > translates from one vendor to another. It would be like having to make > > sure all parties are on the same equipment (and network) when making a > > telephone call. A major factor in the inability of Telepresence system= s > > to work with each other is that there is no standard description of the > > multiple streams that comprise the media flows. > >> > >> For example, in a multiple screen conference, the video and audio > > streams sent from remote participants must be understood by receivers s= o > > that they can be presented in a coherent and life-like manner. This > > includes the ability to present the remote participants at their true > > size for their apparent distance, while maintaining correct eye contact= , > > gesticular cues, and simultaneously providing a spatial audio sound > > stage consistent with the video presentation. The receiving device tha= t > > decides how to display the incoming information needs to understand a > > number of variables such as the spatial position of the speaker, the > > field of view of the cameras, the camera zoom, which media stream is > > related to each of the displays, etc. > >> > >> Charter > >> The Telepresence Multi-Streams work item in DISPATCH is chartered to > > define and specify for SIP-based systems the content of media > > multi-stream messages and the way these will be transported. > >> > >> This work will provide a standard for the exchange of media semantic > > information that will foster interoperable end stations and conference > > bridges. It will specify variables that describe the semantics of the > > media streams and the recommended behavior to achieve interoperability. > >> > >> > >> This requires considering current widely deployed use cases, as well > > as cases that are expected to be implemented using the protocol > > framework produced by this work item. The methodology for describing > > the variables must allow extensibility of the variables, since > > telepresence is still a young technology and may have use cases that ar= e > > not currently considered." > >> > >> > >> The work item will identify use cases, define requirements, and define > > a method for describing and transporting information about multiple > > media streams, including a specification of variables required to > > support the use cases. This work item will consider the reuse of > > existing IETF protocols and produce an architecture/protocol framework > > document describing the protocols required to be implemented to support > > this functionality. The document will identify any enhancements > > required to existing protocols as well as describing new protocol(s) fo= r > > interoperable multi-streams negotiation that may be required. > >> > >> Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and > > FECframe. > >> > >> > >> Scope > >> The scope includes both systems that provide a fully immersive > > experience, and systems that interwork with them and therefore need to > > understand the same multiple stream semantics. > >> > >> > >> The focus of this work is on audio and video multiple streams. Other > > media types may be considered, however development of methodologies for > > them is not within the scope of this work. > >> > >> Interoperation with standards compliant systems is required, such as > > SIP-based video conferencing systems. However, backwards compatibility > > with existing non-standards compliant telepresence systems is not > > required. > >> > >> > >> > >> The group will produce > >> - Requirements and use cases > >> > >> - Architectural Framework describing the protocols required to be > > implemented to support this functionality and identifying existing > > protocol enhancements and new protocol functionality required > >> > >> - Specification of a new protocol to support telepresence > > multi-streams [if required] > >> > >> Goals and Milestones > >> Nov 2010 > >> > >> Use Cases and Requirements to IESG as Informational RFC > >> Nov 2010 > >> March 2011 > >> Problem Statement to IESG as Informational RFC > >> Architecture to IESG as Informational RFC > >> March 2011 > >> Revise Charter [IF new protocol is not required] > >> Nov 2011 > >> Submit protocol draft to IESG as Proposed Standard RFC > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > > > Cullen Jennings > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --001485ec0f4e4c2726048addfd35 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi Allyn= /Stephen,


I read through these. I think they do a good job of establishing scope and = raising issues and as a bonus they are very easy to read.


Is there a need to talk about interop with standard video SIP gear? If I us= e a TP suite to call a desktop SIP client or a 1080p video conferencing ter= minal is there anything about how that should behave that is worth defining= under this work or is that viewed as out of scope?=A0


=

As for d= raft-romanow-dispatch-telepresence-use-cases-00.txt


1. (nit)=

"= ;This draft =85" paragraph has a number of A's sprinkled in (t= ypos?)


3. "= ;We describe=85display stream" I assume display stream is a stream fro= m a document camera (as distinct from video stream being from a participant= camera?). This term does not match the words used in the previous paragrap= h.


=

Thanks,= =A0

<= br>

Peter Mu= sgrave



On Thu, Jul 8, 2010= at 2:46 AM, Cullen Jennings <fluffy@cisco.com> wrote:

Theses look great - I hope people on the list take some time to read them.<= br>

On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote:

> Hi Cullen,
>
> We just put out a problem statement draft -
> http://tools.ietf.org/html/draft-romanow-d= ispatch-telepresence-prob-stat
> ement-00. The document is not complete, but we feel it is a solid
> beginning. =A0It does address the example you mention. The use case do= c
> also describes this case in some detail.
> http://tools.ietf.org/html/draft-romanow-d= ispatch-telepresence-use-cases
> -00
>
>
> Do you not feel that the problem statement draft can serve as a good > basis for discussion of problems?
>
> Thanks,
> Allyn
>
>
> -----Original Message-----
> From: dispatch-bounces@ie= tf.org [mailto:dispatch-bo= unces@ietf.org] On
> Behalf Of Cullen Jennings (fluffy)
> Sent: Wednesday, July 07, 2010 9:41 AM
> To: DISPATCH list
> Subject: Re: [dispatch] Charter for Telepresence multi-streams -
> thirdversion
>
>
> I'm wondering if we could get a thread going about what are some o= f the
> specific problems we =A0need to solve =A0then dispatch theses problems= to
> appropriate WGs.
>
> For example one problem is when a session involves two video session o= n
> multiple screens how does one signal which stream is displayed on the<= br> > right and left screen.
>
> I think having a list of specific problems would help get this moving<= br> > faster.
>
> Cullen
>
>
> On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote:
>
>> Folks,
>> This makes the change discussed replacing the text in the third > paragraph under the Charter section with the text suggested on the lis= t.
>> It also changes title from "... Description of Work" to = "...Charter"
>>
>> There weren't any further changes suggested.
>>
>> Thanks,
>> Allyn
>>
>>
>>
>>
>> Multi-streams for Telepresence Charter
>>
>>
>>
>> Background
>> One branch of video conferencing has evolved that is focused on > immersive "being there" experience. =A0Referred to in variou= s ways such as
> virtual conferencing, telepresence or media spaces, early systems were=
> mainly research projects or business systems with limited deployments.=
> In recent years telepresence systems have seen considerable market
> success. =A0Following the model of early systems, the first wave of > commercial systems have been typically located in specially designed > single-purpose rooms with multiple relatively large displays permittin= g
> life size image reproduction, multiple cameras, encoders, decoders and=
> microphones. =A0These systems have several important characteristics t= hat
> are different from more traditional video conferencing systems.
>>
>> The first difference concerns controlling the visual viewpoint in<= br> > order to improve participant nonverbal communication. These systems > preserve essential group meeting characteristics such as eye contact,<= br> > group gestures, seating order and spatial audio by carefully
> orchestrating the miking and camera angles at each of the sites . This=
> is distinct from the more traditional approach where the geometric
> relationship between media streams is not used to preserve inter-strea= m
> communication aspects such as eye contact and group dynamics.
>>
>> A second difference is manipulation of the environment to improve<= br> > immersion. =A0With telepresence systems, cinematographic aspects of th= e
> local environment reproduction are carefully planned including color,<= br> > table shape, seating and lighting so that when combined with large hig= h
> quality displays, a strong sense of a "trompe l'oeil" or= "being there"
> immersive experience is created. =A0Typical video conference systems d= o
> not include these considerations.
>>
>> As telepresence video systems have become successful in the market= ,
> manufacturers have started exploring delivery of the nonverbal
> communication and immersive values of telepresence via smaller, less > expensive and more flexible video conferencing systems for a variety o= f
> venues, such as individual offices, homes and kiosks. These are also > telepresence systems, since the audio and video quality is high enough=
> to allow clear image reproduction for nonverbal communication, they ar= e
> able to send and receive multiple media streams, and large coordinated=
> multi image displays are available for immersive installations. =A0 As= the
> industry develops, the line between telepresence and video conferencin= g
> may become blurred as nonverbal communication and immersive
> installations become broadly available.
>>
>> Problem
>> Although telepresence systems are based on open standards such as = RTP,
> SIP, H.264, H.323 suite, they cannot easily interoperate with each oth= er
> without operator assistance and expensive additional equipment that > translates from one vendor to another. It would be like having to make=
> sure all parties are on the same equipment (and network) when making a=
> telephone call. =A0A major factor in the inability of Telepresence sys= tems
> to work with each other is that there is no standard description of th= e
> multiple streams that comprise the media flows.
>>
>> For example, in a multiple screen conference, the video and audio<= br> > streams sent from remote participants must be understood by receivers = so
> that they can be presented in a coherent and life-like manner. This > includes the ability to present the remote participants at their true<= br> > size for their apparent distance, while maintaining correct eye contac= t,
> gesticular cues, and simultaneously providing a spatial audio sound > stage consistent with the video presentation. =A0The receiving device = that
> decides how to display the incoming information needs to understand a<= br> > number of variables such as the spatial position of the speaker, the > field of view of the cameras, the camera zoom, which media stream is > related to each of the displays, etc.
>>
>> Charter
>> The Telepresence Multi-Streams work item in DISPATCH is chartered = to
> define and specify for SIP-based systems the content of media
> multi-stream messages and the way these will be transported.
>>
>> This work will provide a standard for the exchange of media semant= ic
> information that will foster interoperable end stations and conference=
> bridges. It will specify =A0variables that describe the semantics of t= he
> media streams and the recommended behavior to achieve interoperability= .
>>
>>
>> This requires considering current widely deployed use cases, as we= ll
> as cases that are expected to be implemented using the protocol
> framework produced by this work item. =A0The methodology for describin= g
> the variables must allow extensibility of the variables, since
> telepresence is still a young technology and may have use cases that a= re
> not currently considered."
>>
>>
>> The work item will identify use cases, define requirements, and de= fine
> a method for describing and transporting information about multiple > media streams, including a specification of variables required to
> support the use cases. This work item will consider the reuse of
> existing IETF protocols and produce an architecture/protocol framework=
> document describing the protocols required to be implemented to suppor= t
> this functionality. =A0The document will identify any enhancements
> required to existing protocols as well as describing new protocol(s) f= or
> interoperable multi-streams negotiation that may be required.
>>
>> Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT,= and
> FECframe.
>>
>>
>> Scope
>> The scope includes both systems that provide a fully immersive
> experience, and systems that interwork with them and therefore need to=
> understand the same multiple stream semantics.
>>
>>
>> The focus of this work is on audio and video multiple streams. =A0= Other
> media types may be considered, however development of methodologies fo= r
> them is not within the scope of this work.
>>
>> Interoperation with standards compliant systems is required, such = as
> SIP-based video conferencing systems. =A0However, backwards compatibil= ity
> with existing non-standards compliant telepresence systems is not
> required.
>>
>>
>>
>> The group will produce
>> - Requirements and use cases
>>
>> - Architectural Framework describing the protocols required to be<= br> > implemented to support this functionality and identifying existing
> protocol enhancements and new protocol functionality required
>>
>> - Specification of a new protocol to support telepresence
> multi-streams [if required]
>>
>> Goals and Milestones
>> Nov 2010
>>
>> Use Cases and Requirements to IESG as Informational RFC
>> Nov 2010
>> March 2011
>> Problem Statement to IESG as Informational RFC
>> Architecture to IESG as Informational RFC
>> March 2011
>> Revise Charter [IF new protocol is not required]
>> Nov 2011
>> Submit protocol draft to IESG as Proposed Standard RFC
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
>
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/le= gal/cri/index.html
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/c= ri/index.html



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

--001485ec0f4e4c2726048addfd35-- From tme@americafree.tv Thu Jul 8 05:04:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 740563A6A90 for ; Thu, 8 Jul 2010 05:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.297 X-Spam-Level: X-Spam-Status: No, score=-102.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OULvaTV3VZSB for ; Thu, 8 Jul 2010 05:04:07 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id D16E83A6A92 for ; Thu, 8 Jul 2010 05:04:05 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 546407D94D18; Thu, 8 Jul 2010 08:04:09 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Peter Musgrave In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Jul 2010 08:04:08 -0400 References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C333D2@xmb-sjc-221.amer.cisco.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list , "Botzko, Stephen" Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 12:04:09 -0000 On Jul 8, 2010, at 6:45 AM, Peter Musgrave wrote: > Hi Allyn/Stephen, > > I read through these. I think they do a good job of establishing =20 > scope and raising issues and as a bonus they are very easy to read. > > Is there a need to talk about interop with standard video SIP gear? =20= > If I use a TP suite to call a desktop SIP client or a 1080p video =20 > conferencing terminal is there anything about how that should behave =20= > that is worth defining under this work or is that viewed as out of =20 > scope? > Read Section 4.2 in Use Cases = http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases-0= 0#section-4.2 which deals with "1 screen units," which is of course what most =20 videoconferencing currently is. Is that what you were looking for ? Regards Marshall > As for draft-romanow-dispatch-telepresence-use-cases-00.txt > > 1. (nit) > "This draft =85" paragraph has a number of A's sprinkled in (typos?) > > 3. "We describe=85display stream" I assume display stream is a stream =20= > from a document camera (as distinct from video stream being from a =20 > participant camera?). This term does not match the words used in the =20= > previous paragraph. > > Thanks, > > Peter Musgrave > > > On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings =20 > wrote: > > Theses look great - I hope people on the list take some time to read =20= > them. > > On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote: > > > Hi Cullen, > > > > We just put out a problem statement draft - > > = http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-prob-stat > > ement-00. The document is not complete, but we feel it is a solid > > beginning. It does address the example you mention. The use case =20= > doc > > also describes this case in some detail. > > = http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases > > -00 > > > > > > Do you not feel that the problem statement draft can serve as a good > > basis for discussion of problems? > > > > Thanks, > > Allyn > > > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] =20= > On > > Behalf Of Cullen Jennings (fluffy) > > Sent: Wednesday, July 07, 2010 9:41 AM > > To: DISPATCH list > > Subject: Re: [dispatch] Charter for Telepresence multi-streams - > > thirdversion > > > > > > I'm wondering if we could get a thread going about what are some =20 > of the > > specific problems we need to solve then dispatch theses problems =20= > to > > appropriate WGs. > > > > For example one problem is when a session involves two video =20 > session on > > multiple screens how does one signal which stream is displayed on =20= > the > > right and left screen. > > > > I think having a list of specific problems would help get this =20 > moving > > faster. > > > > Cullen > > > > > > On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote: > > > >> Folks, > >> This makes the change discussed replacing the text in the third > > paragraph under the Charter section with the text suggested on the =20= > list. > >> It also changes title from "... Description of Work" to =20 > "...Charter" > >> > >> There weren't any further changes suggested. > >> > >> Thanks, > >> Allyn > >> > >> > >> > >> > >> Multi-streams for Telepresence Charter > >> > >> > >> > >> Background > >> One branch of video conferencing has evolved that is focused on > > immersive "being there" experience. Referred to in various ways =20 > such as > > virtual conferencing, telepresence or media spaces, early systems =20= > were > > mainly research projects or business systems with limited =20 > deployments. > > In recent years telepresence systems have seen considerable market > > success. Following the model of early systems, the first wave of > > commercial systems have been typically located in specially designed > > single-purpose rooms with multiple relatively large displays =20 > permitting > > life size image reproduction, multiple cameras, encoders, decoders =20= > and > > microphones. These systems have several important characteristics =20= > that > > are different from more traditional video conferencing systems. > >> > >> The first difference concerns controlling the visual viewpoint in > > order to improve participant nonverbal communication. These systems > > preserve essential group meeting characteristics such as eye =20 > contact, > > group gestures, seating order and spatial audio by carefully > > orchestrating the miking and camera angles at each of the sites . =20= > This > > is distinct from the more traditional approach where the geometric > > relationship between media streams is not used to preserve inter-=20 > stream > > communication aspects such as eye contact and group dynamics. > >> > >> A second difference is manipulation of the environment to improve > > immersion. With telepresence systems, cinematographic aspects of =20= > the > > local environment reproduction are carefully planned including =20 > color, > > table shape, seating and lighting so that when combined with large =20= > high > > quality displays, a strong sense of a "trompe l'oeil" or "being =20 > there" > > immersive experience is created. Typical video conference systems =20= > do > > not include these considerations. > >> > >> As telepresence video systems have become successful in the market, > > manufacturers have started exploring delivery of the nonverbal > > communication and immersive values of telepresence via smaller, less > > expensive and more flexible video conferencing systems for a =20 > variety of > > venues, such as individual offices, homes and kiosks. These are also > > telepresence systems, since the audio and video quality is high =20 > enough > > to allow clear image reproduction for nonverbal communication, =20 > they are > > able to send and receive multiple media streams, and large =20 > coordinated > > multi image displays are available for immersive installations. =20= > As the > > industry develops, the line between telepresence and video =20 > conferencing > > may become blurred as nonverbal communication and immersive > > installations become broadly available. > >> > >> Problem > >> Although telepresence systems are based on open standards such as =20= > RTP, > > SIP, H.264, H.323 suite, they cannot easily interoperate with each =20= > other > > without operator assistance and expensive additional equipment that > > translates from one vendor to another. It would be like having to =20= > make > > sure all parties are on the same equipment (and network) when =20 > making a > > telephone call. A major factor in the inability of Telepresence =20 > systems > > to work with each other is that there is no standard description =20 > of the > > multiple streams that comprise the media flows. > >> > >> For example, in a multiple screen conference, the video and audio > > streams sent from remote participants must be understood by =20 > receivers so > > that they can be presented in a coherent and life-like manner. This > > includes the ability to present the remote participants at their =20 > true > > size for their apparent distance, while maintaining correct eye =20 > contact, > > gesticular cues, and simultaneously providing a spatial audio sound > > stage consistent with the video presentation. The receiving =20 > device that > > decides how to display the incoming information needs to =20 > understand a > > number of variables such as the spatial position of the speaker, the > > field of view of the cameras, the camera zoom, which media stream is > > related to each of the displays, etc. > >> > >> Charter > >> The Telepresence Multi-Streams work item in DISPATCH is chartered =20= > to > > define and specify for SIP-based systems the content of media > > multi-stream messages and the way these will be transported. > >> > >> This work will provide a standard for the exchange of media =20 > semantic > > information that will foster interoperable end stations and =20 > conference > > bridges. It will specify variables that describe the semantics of =20= > the > > media streams and the recommended behavior to achieve =20 > interoperability. > >> > >> > >> This requires considering current widely deployed use cases, as =20 > well > > as cases that are expected to be implemented using the protocol > > framework produced by this work item. The methodology for =20 > describing > > the variables must allow extensibility of the variables, since > > telepresence is still a young technology and may have use cases =20 > that are > > not currently considered." > >> > >> > >> The work item will identify use cases, define requirements, and =20 > define > > a method for describing and transporting information about multiple > > media streams, including a specification of variables required to > > support the use cases. This work item will consider the reuse of > > existing IETF protocols and produce an architecture/protocol =20 > framework > > document describing the protocols required to be implemented to =20 > support > > this functionality. The document will identify any enhancements > > required to existing protocols as well as describing new =20 > protocol(s) for > > interoperable multi-streams negotiation that may be required. > >> > >> Relevant work to be drawn upon has been done in XCON, MMUSIC, =20 > AVT, and > > FECframe. > >> > >> > >> Scope > >> The scope includes both systems that provide a fully immersive > > experience, and systems that interwork with them and therefore =20 > need to > > understand the same multiple stream semantics. > >> > >> > >> The focus of this work is on audio and video multiple streams. =20 > Other > > media types may be considered, however development of =20 > methodologies for > > them is not within the scope of this work. > >> > >> Interoperation with standards compliant systems is required, such =20= > as > > SIP-based video conferencing systems. However, backwards =20 > compatibility > > with existing non-standards compliant telepresence systems is not > > required. > >> > >> > >> > >> The group will produce > >> - Requirements and use cases > >> > >> - Architectural Framework describing the protocols required to be > > implemented to support this functionality and identifying existing > > protocol enhancements and new protocol functionality required > >> > >> - Specification of a new protocol to support telepresence > > multi-streams [if required] > >> > >> Goals and Milestones > >> Nov 2010 > >> > >> Use Cases and Requirements to IESG as Informational RFC > >> Nov 2010 > >> March 2011 > >> Problem Statement to IESG as Informational RFC > >> Architecture to IESG as Informational RFC > >> March 2011 > >> Revise Charter [IF new protocol is not required] > >> Nov 2011 > >> Submit protocol draft to IESG as Proposed Standard RFC > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > > > Cullen Jennings > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > 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.musgrave@magorcorp.com Thu Jul 8 05:21:40 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033093A6A9F for ; Thu, 8 Jul 2010 05:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.618 X-Spam-Level: X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZNNSkpVRf5I for ; Thu, 8 Jul 2010 05:21:37 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 5879F3A6A9D for ; Thu, 8 Jul 2010 05:21:37 -0700 (PDT) Received: by qyk2 with SMTP id 2so2859817qyk.10 for ; Thu, 08 Jul 2010 05:21:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.18.1 with SMTP id u1mr1736441qaa.164.1278591697985; Thu, 08 Jul 2010 05:21:37 -0700 (PDT) Received: by 10.229.220.10 with HTTP; Thu, 8 Jul 2010 05:21:37 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C333D2@xmb-sjc-221.amer.cisco.com> Date: Thu, 8 Jul 2010 08:21:37 -0400 Message-ID: From: Peter Musgrave To: Marshall Eubanks Content-Type: multipart/alternative; boundary=00c09f9b0c37f8a2a1048adf5305 Cc: DISPATCH list , "Botzko, Stephen" Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 12:21:40 -0000 --00c09f9b0c37f8a2a1048adf5305 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Marshall, 4.2 is part of it - although there may be specific limitations that a VC unit has that a one screen TP system does not. (Also, ideally there would b= e a way to work with such legacy systems without them supporting new TP features in SIP). I am also interested in whether heterogenous mixes of TP rooms and legacy SIP video units in multi-party conferences is something viewed as in charte= r - or if it's better to keep things simple and just limit the scope to issue= s of TP interop. Regards, Peter Musgrave On Thu, Jul 8, 2010 at 8:04 AM, Marshall Eubanks wrote= : > > On Jul 8, 2010, at 6:45 AM, Peter Musgrave wrote: > > Hi Allyn/Stephen, >> >> I read through these. I think they do a good job of establishing scope a= nd >> raising issues and as a bonus they are very easy to read. >> >> Is there a need to talk about interop with standard video SIP gear? If I >> use a TP suite to call a desktop SIP client or a 1080p video conferencin= g >> terminal is there anything about how that should behave that is worth >> defining under this work or is that viewed as out of scope? >> >> > Read Section 4.2 in Use Cases > > > http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases-= 00#section-4.2 > > which deals with "1 screen units," which is of course what most > videoconferencing currently is. Is that what you were looking for ? > > Regards > Marshall > > > > As for draft-romanow-dispatch-telepresence-use-cases-00.txt >> >> 1. (nit) >> "This draft =85" paragraph has a number of A's sprinkled in (typos?) >> >> 3. "We describe=85display stream" I assume display stream is a stream fr= om a >> document camera (as distinct from video stream being from a participant >> camera?). This term does not match the words used in the previous paragr= aph. >> >> Thanks, >> >> Peter Musgrave >> >> >> On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings wrote= : >> >> Theses look great - I hope people on the list take some time to read the= m. >> >> On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote: >> >> > Hi Cullen, >> > >> > We just put out a problem statement draft - >> > >> http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-prob-stat >> > ement-00. The document is not complete, but we feel it is a solid >> > beginning. It does address the example you mention. The use case doc >> > also describes this case in some detail. >> > >> http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases >> > -00 >> > >> > >> > Do you not feel that the problem statement draft can serve as a good >> > basis for discussion of problems? >> > >> > Thanks, >> > Allyn >> > >> > >> > -----Original Message----- >> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> > Behalf Of Cullen Jennings (fluffy) >> > Sent: Wednesday, July 07, 2010 9:41 AM >> > To: DISPATCH list >> > Subject: Re: [dispatch] Charter for Telepresence multi-streams - >> > thirdversion >> > >> > >> > I'm wondering if we could get a thread going about what are some of th= e >> > specific problems we need to solve then dispatch theses problems to >> > appropriate WGs. >> > >> > For example one problem is when a session involves two video session o= n >> > multiple screens how does one signal which stream is displayed on the >> > right and left screen. >> > >> > I think having a list of specific problems would help get this moving >> > faster. >> > >> > Cullen >> > >> > >> > On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote: >> > >> >> Folks, >> >> This makes the change discussed replacing the text in the third >> > paragraph under the Charter section with the text suggested on the lis= t. >> >> It also changes title from "... Description of Work" to "...Charter" >> >> >> >> There weren't any further changes suggested. >> >> >> >> Thanks, >> >> Allyn >> >> >> >> >> >> >> >> >> >> Multi-streams for Telepresence Charter >> >> >> >> >> >> >> >> Background >> >> One branch of video conferencing has evolved that is focused on >> > immersive "being there" experience. Referred to in various ways such = as >> > virtual conferencing, telepresence or media spaces, early systems were >> > mainly research projects or business systems with limited deployments. >> > In recent years telepresence systems have seen considerable market >> > success. Following the model of early systems, the first wave of >> > commercial systems have been typically located in specially designed >> > single-purpose rooms with multiple relatively large displays permittin= g >> > life size image reproduction, multiple cameras, encoders, decoders and >> > microphones. These systems have several important characteristics tha= t >> > are different from more traditional video conferencing systems. >> >> >> >> The first difference concerns controlling the visual viewpoint in >> > order to improve participant nonverbal communication. These systems >> > preserve essential group meeting characteristics such as eye contact, >> > group gestures, seating order and spatial audio by carefully >> > orchestrating the miking and camera angles at each of the sites . This >> > is distinct from the more traditional approach where the geometric >> > relationship between media streams is not used to preserve inter-strea= m >> > communication aspects such as eye contact and group dynamics. >> >> >> >> A second difference is manipulation of the environment to improve >> > immersion. With telepresence systems, cinematographic aspects of the >> > local environment reproduction are carefully planned including color, >> > table shape, seating and lighting so that when combined with large hig= h >> > quality displays, a strong sense of a "trompe l'oeil" or "being there" >> > immersive experience is created. Typical video conference systems do >> > not include these considerations. >> >> >> >> As telepresence video systems have become successful in the market, >> > manufacturers have started exploring delivery of the nonverbal >> > communication and immersive values of telepresence via smaller, less >> > expensive and more flexible video conferencing systems for a variety o= f >> > venues, such as individual offices, homes and kiosks. These are also >> > telepresence systems, since the audio and video quality is high enough >> > to allow clear image reproduction for nonverbal communication, they ar= e >> > able to send and receive multiple media streams, and large coordinated >> > multi image displays are available for immersive installations. As t= he >> > industry develops, the line between telepresence and video conferencin= g >> > may become blurred as nonverbal communication and immersive >> > installations become broadly available. >> >> >> >> Problem >> >> Although telepresence systems are based on open standards such as RTP= , >> > SIP, H.264, H.323 suite, they cannot easily interoperate with each oth= er >> > without operator assistance and expensive additional equipment that >> > translates from one vendor to another. It would be like having to make >> > sure all parties are on the same equipment (and network) when making a >> > telephone call. A major factor in the inability of Telepresence syste= ms >> > to work with each other is that there is no standard description of th= e >> > multiple streams that comprise the media flows. >> >> >> >> For example, in a multiple screen conference, the video and audio >> > streams sent from remote participants must be understood by receivers = so >> > that they can be presented in a coherent and life-like manner. This >> > includes the ability to present the remote participants at their true >> > size for their apparent distance, while maintaining correct eye contac= t, >> > gesticular cues, and simultaneously providing a spatial audio sound >> > stage consistent with the video presentation. The receiving device th= at >> > decides how to display the incoming information needs to understand a >> > number of variables such as the spatial position of the speaker, the >> > field of view of the cameras, the camera zoom, which media stream is >> > related to each of the displays, etc. >> >> >> >> Charter >> >> The Telepresence Multi-Streams work item in DISPATCH is chartered to >> > define and specify for SIP-based systems the content of media >> > multi-stream messages and the way these will be transported. >> >> >> >> This work will provide a standard for the exchange of media semantic >> > information that will foster interoperable end stations and conference >> > bridges. It will specify variables that describe the semantics of the >> > media streams and the recommended behavior to achieve interoperability= . >> >> >> >> >> >> This requires considering current widely deployed use cases, as well >> > as cases that are expected to be implemented using the protocol >> > framework produced by this work item. The methodology for describing >> > the variables must allow extensibility of the variables, since >> > telepresence is still a young technology and may have use cases that a= re >> > not currently considered." >> >> >> >> >> >> The work item will identify use cases, define requirements, and defin= e >> > a method for describing and transporting information about multiple >> > media streams, including a specification of variables required to >> > support the use cases. This work item will consider the reuse of >> > existing IETF protocols and produce an architecture/protocol framework >> > document describing the protocols required to be implemented to suppor= t >> > this functionality. The document will identify any enhancements >> > required to existing protocols as well as describing new protocol(s) f= or >> > interoperable multi-streams negotiation that may be required. >> >> >> >> Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, an= d >> > FECframe. >> >> >> >> >> >> Scope >> >> The scope includes both systems that provide a fully immersive >> > experience, and systems that interwork with them and therefore need to >> > understand the same multiple stream semantics. >> >> >> >> >> >> The focus of this work is on audio and video multiple streams. Other >> > media types may be considered, however development of methodologies fo= r >> > them is not within the scope of this work. >> >> >> >> Interoperation with standards compliant systems is required, such as >> > SIP-based video conferencing systems. However, backwards compatibilit= y >> > with existing non-standards compliant telepresence systems is not >> > required. >> >> >> >> >> >> >> >> The group will produce >> >> - Requirements and use cases >> >> >> >> - Architectural Framework describing the protocols required to be >> > implemented to support this functionality and identifying existing >> > protocol enhancements and new protocol functionality required >> >> >> >> - Specification of a new protocol to support telepresence >> > multi-streams [if required] >> >> >> >> Goals and Milestones >> >> Nov 2010 >> >> >> >> Use Cases and Requirements to IESG as Informational RFC >> >> Nov 2010 >> >> March 2011 >> >> Problem Statement to IESG as Informational RFC >> >> Architecture to IESG as Informational RFC >> >> March 2011 >> >> Revise Charter [IF new protocol is not required] >> >> Nov 2011 >> >> Submit protocol draft to IESG as Proposed Standard RFC >> >> >> >> _______________________________________________ >> >> dispatch mailing list >> >> dispatch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dispatch >> > >> > >> > Cullen Jennings >> > For corporate legal information go to: >> > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> > >> > >> > >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> >> >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> >> _______________________________________________ >> 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 >> > > --00c09f9b0c37f8a2a1048adf5305 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Marshall,=A0

4.2 is part of it - although there may b= e specific limitations that a VC unit has that a one screen TP system does = not. (Also, ideally there would be a way to work with such legacy systems w= ithout them supporting new TP features in SIP).=A0

I am also interested in whether heterogenous mixes of T= P rooms and legacy SIP video units in multi-party conferences is something = viewed as in charter - or if it's better to keep things simple and just= limit the scope to issues of TP interop.=A0

Regards,=A0

Peter Musgrave
=
On Thu, Jul 8, 2010 at 8:04 AM, Marshall Eub= anks <tme@americ= afree.tv> wrote:

On Jul 8, 2010, at 6:45 AM, Peter Musgrave wrote:

Hi Allyn/Stephen,

I read through these. I think they do a good job of establishing scope and = raising issues and as a bonus they are very easy to read.

Is there a need to talk about interop with standard video SIP gear? If I us= e a TP suite to call a desktop SIP client or a 1080p video conferencing ter= minal is there anything about how that should behave that is worth defining= under this work or is that viewed as out of scope?


Read Section 4.2 in Use Cases

http://tools.ietf.org/html/draft= -romanow-dispatch-telepresence-use-cases-00#section-4.2

which deals with "1 screen units," which is of course what most v= ideoconferencing currently is. Is that what you were looking for ?

Regards
Marshall



As for draft-romanow-dispatch-telepresence-use-cases-00.txt

1. (nit)
"This draft =85" paragraph has a number of A's sprinkled in (= typos?)

3. "We describe=85display stream" I assume display stream is a st= ream from a document camera (as distinct from video stream being from a par= ticipant camera?). This term does not match the words used in the previous = paragraph.

Thanks,

Peter Musgrave


On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings <fluffy@cisco.com> wrote:

Theses look great - I hope people on the list take some time to read them.<= br>
On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote:

> Hi Cullen,
>
> We just put out a problem statement draft -
> http://tools.ietf.org/html/draft-romanow-d= ispatch-telepresence-prob-stat
> ement-00. The document is not complete, but we feel it is a solid
> beginning. =A0It does address the example you mention. The use case do= c
> also describes this case in some detail.
> http://tools.ietf.org/html/draft-romanow-d= ispatch-telepresence-use-cases
> -00
>
>
> Do you not feel that the problem statement draft can serve as a good > basis for discussion of problems?
>
> Thanks,
> Allyn
>
>
> -----Original Message-----
> From: d= ispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Cullen Jennings (fluffy)
> Sent: Wednesday, July 07, 2010 9:41 AM
> To: DISPATCH list
> Subject: Re: [dispatch] Charter for Telepresence multi-streams -
> thirdversion
>
>
> I'm wondering if we could get a thread going about what are some o= f the
> specific problems we =A0need to solve =A0then dispatch theses problems= to
> appropriate WGs.
>
> For example one problem is when a session involves two video session o= n
> multiple screens how does one signal which stream is displayed on the<= br> > right and left screen.
>
> I think having a list of specific problems would help get this moving<= br> > faster.
>
> Cullen
>
>
> On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote:
>
>> Folks,
>> This makes the change discussed replacing the text in the third > paragraph under the Charter section with the text suggested on the lis= t.
>> It also changes title from "... Description of Work" to = "...Charter"
>>
>> There weren't any further changes suggested.
>>
>> Thanks,
>> Allyn
>>
>>
>>
>>
>> Multi-streams for Telepresence Charter
>>
>>
>>
>> Background
>> One branch of video conferencing has evolved that is focused on > immersive "being there" experience. =A0Referred to in variou= s ways such as
> virtual conferencing, telepresence or media spaces, early systems were=
> mainly research projects or business systems with limited deployments.=
> In recent years telepresence systems have seen considerable market
> success. =A0Following the model of early systems, the first wave of > commercial systems have been typically located in specially designed > single-purpose rooms with multiple relatively large displays permittin= g
> life size image reproduction, multiple cameras, encoders, decoders and=
> microphones. =A0These systems have several important characteristics t= hat
> are different from more traditional video conferencing systems.
>>
>> The first difference concerns controlling the visual viewpoint in<= br> > order to improve participant nonverbal communication. These systems > preserve essential group meeting characteristics such as eye contact,<= br> > group gestures, seating order and spatial audio by carefully
> orchestrating the miking and camera angles at each of the sites . This=
> is distinct from the more traditional approach where the geometric
> relationship between media streams is not used to preserve inter-strea= m
> communication aspects such as eye contact and group dynamics.
>>
>> A second difference is manipulation of the environment to improve<= br> > immersion. =A0With telepresence systems, cinematographic aspects of th= e
> local environment reproduction are carefully planned including color,<= br> > table shape, seating and lighting so that when combined with large hig= h
> quality displays, a strong sense of a "trompe l'oeil" or= "being there"
> immersive experience is created. =A0Typical video conference systems d= o
> not include these considerations.
>>
>> As telepresence video systems have become successful in the market= ,
> manufacturers have started exploring delivery of the nonverbal
> communication and immersive values of telepresence via smaller, less > expensive and more flexible video conferencing systems for a variety o= f
> venues, such as individual offices, homes and kiosks. These are also > telepresence systems, since the audio and video quality is high enough=
> to allow clear image reproduction for nonverbal communication, they ar= e
> able to send and receive multiple media streams, and large coordinated=
> multi image displays are available for immersive installations. =A0 As= the
> industry develops, the line between telepresence and video conferencin= g
> may become blurred as nonverbal communication and immersive
> installations become broadly available.
>>
>> Problem
>> Although telepresence systems are based on open standards such as = RTP,
> SIP, H.264, H.323 suite, they cannot easily interoperate with each oth= er
> without operator assistance and expensive additional equipment that > translates from one vendor to another. It would be like having to make=
> sure all parties are on the same equipment (and network) when making a=
> telephone call. =A0A major factor in the inability of Telepresence sys= tems
> to work with each other is that there is no standard description of th= e
> multiple streams that comprise the media flows.
>>
>> For example, in a multiple screen conference, the video and audio<= br> > streams sent from remote participants must be understood by receivers = so
> that they can be presented in a coherent and life-like manner. This > includes the ability to present the remote participants at their true<= br> > size for their apparent distance, while maintaining correct eye contac= t,
> gesticular cues, and simultaneously providing a spatial audio sound > stage consistent with the video presentation. =A0The receiving device = that
> decides how to display the incoming information needs to understand a<= br> > number of variables such as the spatial position of the speaker, the > field of view of the cameras, the camera zoom, which media stream is > related to each of the displays, etc.
>>
>> Charter
>> The Telepresence Multi-Streams work item in DISPATCH is chartered = to
> define and specify for SIP-based systems the content of media
> multi-stream messages and the way these will be transported.
>>
>> This work will provide a standard for the exchange of media semant= ic
> information that will foster interoperable end stations and conference=
> bridges. It will specify =A0variables that describe the semantics of t= he
> media streams and the recommended behavior to achieve interoperability= .
>>
>>
>> This requires considering current widely deployed use cases, as we= ll
> as cases that are expected to be implemented using the protocol
> framework produced by this work item. =A0The methodology for describin= g
> the variables must allow extensibility of the variables, since
> telepresence is still a young technology and may have use cases that a= re
> not currently considered."
>>
>>
>> The work item will identify use cases, define requirements, and de= fine
> a method for describing and transporting information about multiple > media streams, including a specification of variables required to
> support the use cases. This work item will consider the reuse of
> existing IETF protocols and produce an architecture/protocol framework=
> document describing the protocols required to be implemented to suppor= t
> this functionality. =A0The document will identify any enhancements
> required to existing protocols as well as describing new protocol(s) f= or
> interoperable multi-streams negotiation that may be required.
>>
>> Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT,= and
> FECframe.
>>
>>
>> Scope
>> The scope includes both systems that provide a fully immersive
> experience, and systems that interwork with them and therefore need to=
> understand the same multiple stream semantics.
>>
>>
>> The focus of this work is on audio and video multiple streams. =A0= Other
> media types may be considered, however development of methodologies fo= r
> them is not within the scope of this work.
>>
>> Interoperation with standards compliant systems is required, such = as
> SIP-based video conferencing systems. =A0However, backwards compatibil= ity
> with existing non-standards compliant telepresence systems is not
> required.
>>
>>
>>
>> The group will produce
>> - Requirements and use cases
>>
>> - Architectural Framework describing the protocols required to be<= br> > implemented to support this functionality and identifying existing
> protocol enhancements and new protocol functionality required
>>
>> - Specification of a new protocol to support telepresence
> multi-streams [if required]
>>
>> Goals and Milestones
>> Nov 2010
>>
>> Use Cases and Requirements to IESG as Informational RFC
>> Nov 2010
>> March 2011
>> Problem Statement to IESG as Informational RFC
>> Architecture to IESG as Informational RFC
>> March 2011
>> Revise Charter [IF new protocol is not required]
>> Nov 2011
>> Submit protocol draft to IESG as Proposed Standard RFC
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ie= tf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
>
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/le= gal/cri/index.html
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/c= ri/index.html



_______________________________________________
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


--00c09f9b0c37f8a2a1048adf5305-- From christer.holmberg@ericsson.com Thu Jul 8 05:32:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D0533A6AA5 for ; Thu, 8 Jul 2010 05:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8N2tFkf+dJOe for ; Thu, 8 Jul 2010 05:31:43 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 46D1D3A6A94 for ; Thu, 8 Jul 2010 05:30:47 -0700 (PDT) X-AuditID: c1b4fb39-b7bc4ae000006582-53-4c35c4e6ebfc Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C3.D2.25986.6E4C53C4; Thu, 8 Jul 2010 14:30:31 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.94]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 8 Jul 2010 14:30:30 +0200 From: Christer Holmberg To: Cullen Jennings , Muthu ArulMozhi Perumal Date: Thu, 8 Jul 2010 14:26:40 +0200 Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: Acsd8LXFGejeJl1iTMGytkFwVBpJogAqBvkn Message-ID: References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com>, <8F5532A2-7017-48B2-897F-6FA6E50EE68A@cisco.com> In-Reply-To: <8F5532A2-7017-48B2-897F-6FA6E50EE68A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 12:32:21 -0000 Hi, I agree. The purpose of RFC 5843 was to identity what SBCs are doing, why they do it= , and the potential problems it may cause, and then try to come up with sta= ndard mechanisms in order to solve specific problems. Regards, Christer ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Cu= llen Jennings [fluffy@cisco.com] Sent: Wednesday, July 07, 2010 7:22 PM To: Muthu ArulMozhi Perumal Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? We had a BOF on pretty much this topic. Some people wrote drafts. There was= pretty much no energy to even send comments on it and it was hard to find = authors. It was eventually published as RFC 5853 and we all need to give Ja= ni Hautakorpi a big thanks for that. The whole experience around 5843 does left me thinking that it was better t= o consider B2BUA in any draft and effected any type of UA including B2BUA. = When we ask the question "should we make SBC interoperate better" we get a = resounding yes from everyone. When asked so what do we need to change to ma= ke that happen we get a resounding "might do that some of the time but cert= ainly not all the time from the SBC vendors". I like the idea of finding sp= ecific addressable problems such as Hadriels session-id stuff then going an= d figuring out how to fix that problem. If there are other specific problem= s that can be fixed, by all means write some drafts and get some proposals = on the table. On Jul 1, 2010, at 11:27 AM, Muthu ArulMozhi Perumal (mperumal) wrote: > In the past few years there has been a proliferation of Session Border Co= ntroller (SBC) deployments in SIP networks mainly because the development o= f SIP protocol specifications hasn't been able to keep in pace with industr= y and operator requirements. The common functions they perform and the arch= itectural issues they introduce are described in RFC-5853. > > Due to lack of well defined guidelines and best current practices many SB= C implementations break end-to-end features and introduce problems that are= difficult to troubleshoot, many a times because of poor implementations ra= ther than to meet any specific requirements. For example, when they do medi= a processing they assume everything coming on the media channel is RTP, don= 't do even basic RTP header validations as recommended in RFC-3550, try to = decode STUN and DTLS packets as RTPcorrupting them and making them useless. > > I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to = the one for NATs, to set guidelines and identify best current practices to = encourage better SBC implementations, interoperability and ease of troubles= hooting, rather than just keeping quiet and letting them go out of control. > > Comments? > > Muthu > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch= From tme@americafree.tv Thu Jul 8 05:45:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628483A6AAF for ; Thu, 8 Jul 2010 05:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.33 X-Spam-Level: X-Spam-Status: No, score=-102.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1CaswysP33u for ; Thu, 8 Jul 2010 05:45:58 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id DC5723A6AAC for ; Thu, 8 Jul 2010 05:45:57 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id D3F2A7D97395; Thu, 8 Jul 2010 08:46:01 -0400 (EDT) Message-Id: <32A6C275-C7BC-4562-BE14-ADDC0C4C42C0@americafree.tv> From: Marshall Eubanks To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Jul 2010 08:46:01 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com>, <8F5532A2-7017-48B2-897F-6FA6E50EE68A@cisco.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 12:45:59 -0000 On Jul 8, 2010, at 8:26 AM, Christer Holmberg wrote: > Hi, > > I agree. > > The purpose of RFC 5843 5843 ? I think you and Cullen mean rfc 5853, Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments, which indeed looks like a useful start here. Regards Marshall > was to identity what SBCs are doing, why they do it, and the > potential problems it may cause, and then try to come up with > standard mechanisms in order to solve specific problems. > > Regards, > > Christer > > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings [fluffy@cisco.com] > Sent: Wednesday, July 07, 2010 7:22 PM > To: Muthu ArulMozhi Perumal > Cc: DISPATCH list > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > We had a BOF on pretty much this topic. Some people wrote drafts. > There was pretty much no energy to even send comments on it and it > was hard to find authors. It was eventually published as RFC 5853 > and we all need to give Jani Hautakorpi a big thanks for that. > > The whole experience around 5843 does left me thinking that it was > better to consider B2BUA in any draft and effected any type of UA > including B2BUA. When we ask the question "should we make SBC > interoperate better" we get a resounding yes from everyone. When > asked so what do we need to change to make that happen we get a > resounding "might do that some of the time but certainly not all the > time from the SBC vendors". I like the idea of finding specific > addressable problems such as Hadriels session-id stuff then going > and figuring out how to fix that problem. If there are other > specific problems that can be fixed, by all means write some drafts > and get some proposals on the table. > > > > > On Jul 1, 2010, at 11:27 AM, Muthu ArulMozhi Perumal (mperumal) wrote: > >> In the past few years there has been a proliferation of Session >> Border Controller (SBC) deployments in SIP networks mainly because >> the development of SIP protocol specifications hasn't been able to >> keep in pace with industry and operator requirements. The common >> functions they perform and the architectural issues they introduce >> are described in RFC-5853. >> >> Due to lack of well defined guidelines and best current practices >> many SBC implementations break end-to-end features and introduce >> problems that are difficult to troubleshoot, many a times because >> of poor implementations rather than to meet any specific >> requirements. For example, when they do media processing they >> assume everything coming on the media channel is RTP, don't do even >> basic RTP header validations as recommended in RFC-3550, try to >> decode STUN and DTLS packets as RTPcorrupting them and making them >> useless. >> >> I am wondering whether IETF should have a BEHAVE WG for SBCs, >> similar to the one for NATs, to set guidelines and identify best >> current practices to encourage better SBC implementations, >> interoperability and ease of troubleshooting, rather than just >> keeping quiet and letting them go out of control. >> >> Comments? >> >> Muthu >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > 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 hakon.dahle@tandberg.com Thu Jul 8 05:48:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6BA03A6A8A for ; Thu, 8 Jul 2010 05:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWVbjtoekWpQ for ; Thu, 8 Jul 2010 05:48:08 -0700 (PDT) Received: from mail204.messagelabs.com (mail204.messagelabs.com [85.158.143.51]) by core3.amsl.com (Postfix) with SMTP id D31103A6AAF for ; Thu, 8 Jul 2010 05:48:07 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: hakon.dahle@tandberg.com X-Msg-Ref: server-13.tower-204.messagelabs.com!1278593290!11422595!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [62.70.2.252] Received: (qmail 13596 invoked from network); 8 Jul 2010 12:48:10 -0000 Received: from unknown (HELO OSLEXCP11.eu.tandberg.int) (62.70.2.252) by server-13.tower-204.messagelabs.com with SMTP; 8 Jul 2010 12:48:10 -0000 Received: from oslexcp1.eu.tandberg.int ([10.47.136.29]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Thu, 8 Jul 2010 14:48:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1E9B.D20E1C3B" Date: Thu, 8 Jul 2010 14:48:09 +0200 Message-ID: <9F6ACAE02B6DD040A1E259977622CFDB08C24E86@oslexcp1.eu.tandberg.int> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter for Telepresence multi-streams - thirdversion Thread-Index: AcsemCPXeYWxfeM8SuOJNs2ShzcpigAAWhtA References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C333D2@xmb-sjc-221.amer.cisco.com> From: =?iso-8859-1?Q?H=E5kon_Dahle?= To: X-OriginalArrivalTime: 08 Jul 2010 12:48:10.0593 (UTC) FILETIME=[D2395D10:01CB1E9B] Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 12:48:17 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1E9B.D20E1C3B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Peter - =20 I agree with you in that Section 4.2 only partly addresses the problem. = It states:=20 =20 "The display sizes and camera fields of view at both sites are basically = similar, such that each camera view is designed to show two people = sitting side by side" =20 Section 4.2 hence implicitly addresses a single-screen immersive = telepresence (TP) system, since it assumes similar camera view and = screen size as the multi-screen TP room. =20 Heterogenous mixing of immersive TP rooms with "legacy" single = screen/dual screen SIP and H.323 video units reflects a very typical = use case: Most deployments will consist of a small number of immersive = TP rooms (could be a mix of single and multi-screen), a larger number of = regular meeting room system (single screen/dual screen), and an even = larger number of high definition desktop voice & video appliances / = video phones.=20 =20 In fact, the ability to mix in audio-only calls is also important. This = is another very typical use case (whenever a large meeting is called, = someone will not be able to attend in person due to travel - telephony = is often the only option) =20 -h =20 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Peter Musgrave Sent: 8. juli 2010 13:22 To: Marshall Eubanks Cc: DISPATCH list; Botzko,Stephen Subject: Re: [dispatch] Charter for Telepresence multi-streams - = thirdversion =20 Hi Marshall,=20 =20 4.2 is part of it - although there may be specific limitations that a VC = unit has that a one screen TP system does not. (Also, ideally there = would be a way to work with such legacy systems without them supporting = new TP features in SIP).=20 =20 I am also interested in whether heterogenous mixes of TP rooms and = legacy SIP video units in multi-party conferences is something viewed as = in charter - or if it's better to keep things simple and just limit the = scope to issues of TP interop.=20 =20 Regards,=20 =20 Peter Musgrave On Thu, Jul 8, 2010 at 8:04 AM, Marshall Eubanks = wrote: On Jul 8, 2010, at 6:45 AM, Peter Musgrave wrote: Hi Allyn/Stephen, I read through these. I think they do a good job of establishing scope = and raising issues and as a bonus they are very easy to read. Is there a need to talk about interop with standard video SIP gear? If I = use a TP suite to call a desktop SIP client or a 1080p video = conferencing terminal is there anything about how that should behave = that is worth defining under this work or is that viewed as out of = scope? Read Section 4.2 in Use Cases http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases-= 00#section-4.2 which deals with "1 screen units," which is of course what most = videoconferencing currently is. Is that what you were looking for ? Regards Marshall As for draft-romanow-dispatch-telepresence-use-cases-00.txt 1. (nit) "This draft ..." paragraph has a number of A's sprinkled in (typos?) 3. "We describe...display stream" I assume display stream is a stream = from a document camera (as distinct from video stream being from a = participant camera?). This term does not match the words used in the = previous paragraph. Thanks, Peter Musgrave On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings = wrote: Theses look great - I hope people on the list take some time to read = them. On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote: > Hi Cullen, > > We just put out a problem statement draft - > = http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-prob-stat > ement-00. The document is not complete, but we feel it is a solid > beginning. It does address the example you mention. The use case doc > also describes this case in some detail. > = http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases > -00 > > > Do you not feel that the problem statement draft can serve as a good > basis for discussion of problems? > > Thanks, > Allyn > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings (fluffy) > Sent: Wednesday, July 07, 2010 9:41 AM > To: DISPATCH list > Subject: Re: [dispatch] Charter for Telepresence multi-streams - > thirdversion > > > I'm wondering if we could get a thread going about what are some of = the > specific problems we need to solve then dispatch theses problems to > appropriate WGs. > > For example one problem is when a session involves two video session = on > multiple screens how does one signal which stream is displayed on the > right and left screen. > > I think having a list of specific problems would help get this moving > faster. > > Cullen > > > On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote: > >> Folks, >> This makes the change discussed replacing the text in the third > paragraph under the Charter section with the text suggested on the = list. >> It also changes title from "... Description of Work" to "...Charter" >> >> There weren't any further changes suggested. >> >> Thanks, >> Allyn >> >> >> >> >> Multi-streams for Telepresence Charter >> >> >> >> Background >> One branch of video conferencing has evolved that is focused on > immersive "being there" experience. Referred to in various ways such = as > virtual conferencing, telepresence or media spaces, early systems were > mainly research projects or business systems with limited deployments. > In recent years telepresence systems have seen considerable market > success. Following the model of early systems, the first wave of > commercial systems have been typically located in specially designed > single-purpose rooms with multiple relatively large displays = permitting > life size image reproduction, multiple cameras, encoders, decoders and > microphones. These systems have several important characteristics = that > are different from more traditional video conferencing systems. >> >> The first difference concerns controlling the visual viewpoint in > order to improve participant nonverbal communication. These systems > preserve essential group meeting characteristics such as eye contact, > group gestures, seating order and spatial audio by carefully > orchestrating the miking and camera angles at each of the sites . This > is distinct from the more traditional approach where the geometric > relationship between media streams is not used to preserve = inter-stream > communication aspects such as eye contact and group dynamics. >> >> A second difference is manipulation of the environment to improve > immersion. With telepresence systems, cinematographic aspects of the > local environment reproduction are carefully planned including color, > table shape, seating and lighting so that when combined with large = high > quality displays, a strong sense of a "trompe l'oeil" or "being there" > immersive experience is created. Typical video conference systems do > not include these considerations. >> >> As telepresence video systems have become successful in the market, > manufacturers have started exploring delivery of the nonverbal > communication and immersive values of telepresence via smaller, less > expensive and more flexible video conferencing systems for a variety = of > venues, such as individual offices, homes and kiosks. These are also > telepresence systems, since the audio and video quality is high enough > to allow clear image reproduction for nonverbal communication, they = are > able to send and receive multiple media streams, and large coordinated > multi image displays are available for immersive installations. As = the > industry develops, the line between telepresence and video = conferencing > may become blurred as nonverbal communication and immersive > installations become broadly available. >> >> Problem >> Although telepresence systems are based on open standards such as = RTP, > SIP, H.264, H.323 suite, they cannot easily interoperate with each = other > without operator assistance and expensive additional equipment that > translates from one vendor to another. It would be like having to make > sure all parties are on the same equipment (and network) when making a > telephone call. A major factor in the inability of Telepresence = systems > to work with each other is that there is no standard description of = the > multiple streams that comprise the media flows. >> >> For example, in a multiple screen conference, the video and audio > streams sent from remote participants must be understood by receivers = so > that they can be presented in a coherent and life-like manner. This > includes the ability to present the remote participants at their true > size for their apparent distance, while maintaining correct eye = contact, > gesticular cues, and simultaneously providing a spatial audio sound > stage consistent with the video presentation. The receiving device = that > decides how to display the incoming information needs to understand a > number of variables such as the spatial position of the speaker, the > field of view of the cameras, the camera zoom, which media stream is > related to each of the displays, etc. >> >> Charter >> The Telepresence Multi-Streams work item in DISPATCH is chartered to > define and specify for SIP-based systems the content of media > multi-stream messages and the way these will be transported. >> >> This work will provide a standard for the exchange of media semantic > information that will foster interoperable end stations and conference > bridges. It will specify variables that describe the semantics of the > media streams and the recommended behavior to achieve = interoperability. >> >> >> This requires considering current widely deployed use cases, as well > as cases that are expected to be implemented using the protocol > framework produced by this work item. The methodology for describing > the variables must allow extensibility of the variables, since > telepresence is still a young technology and may have use cases that = are > not currently considered." >> >> >> The work item will identify use cases, define requirements, and = define > a method for describing and transporting information about multiple > media streams, including a specification of variables required to > support the use cases. This work item will consider the reuse of > existing IETF protocols and produce an architecture/protocol framework > document describing the protocols required to be implemented to = support > this functionality. The document will identify any enhancements > required to existing protocols as well as describing new protocol(s) = for > interoperable multi-streams negotiation that may be required. >> >> Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, = and > FECframe. >> >> >> Scope >> The scope includes both systems that provide a fully immersive > experience, and systems that interwork with them and therefore need to > understand the same multiple stream semantics. >> >> >> The focus of this work is on audio and video multiple streams. Other > media types may be considered, however development of methodologies = for > them is not within the scope of this work. >> >> Interoperation with standards compliant systems is required, such as > SIP-based video conferencing systems. However, backwards = compatibility > with existing non-standards compliant telepresence systems is not > required. >> >> >> >> The group will produce >> - Requirements and use cases >> >> - Architectural Framework describing the protocols required to be > implemented to support this functionality and identifying existing > protocol enhancements and new protocol functionality required >> >> - Specification of a new protocol to support telepresence > multi-streams [if required] >> >> Goals and Milestones >> Nov 2010 >> >> Use Cases and Requirements to IESG as Informational RFC >> Nov 2010 >> March 2011 >> Problem Statement to IESG as Informational RFC >> Architecture to IESG as Informational RFC >> March 2011 >> Revise Charter [IF new protocol is not required] >> Nov 2011 >> Submit protocol draft to IESG as Proposed Standard RFC >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ 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 =20 ------_=_NextPart_001_01CB1E9B.D20E1C3B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Peter –

 

I agree with you in that Section 4.2 only partly addresses the =
problem. It states: 
 
“The display sizes and camera fields =
of view at both sites are basically similar, such that each camera view =
is designed to show two people sitting side by side”

 

Section 4.2 hence implicitly addresses a single-screen immersive = telepresence (TP) system, since it assumes similar camera view and = screen size as the multi-screen TP room.

 

Heterogenous mixing of immersive TP rooms with “legacy” = single screen/dual screen SIP and H.323 =A0video units reflects a very = typical use case: Most deployments will consist of a small number of = immersive TP rooms (could be a mix of single and multi-screen), a larger = number of regular meeting room system (single screen/dual screen), and = an even larger number of high definition desktop voice & video = appliances / video phones.

 

In fact, the ability to mix in audio-only calls is also important. = This is another very typical use case (whenever a large meeting is = called, someone will not be able to attend in person due to travel = – telephony is often the only option)

 

-h

 

From:= = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Peter Musgrave
Sent: 8. juli 2010 = 13:22
To: Marshall Eubanks
Cc: DISPATCH list; = Botzko,Stephen
Subject: Re: [dispatch] Charter for = Telepresence multi-streams - thirdversion

 

Hi Marshall, 

 

4.2 is part of it - although there may be specific = limitations that a VC unit has that a one screen TP system does not. = (Also, ideally there would be a way to work with such legacy systems = without them supporting new TP features in = SIP). 

 

I = am also interested in whether heterogenous mixes of TP rooms and legacy = SIP video units in multi-party conferences is something viewed as in = charter - or if it's better to keep things simple and just limit the = scope to issues of TP interop. 

 

Regards, 

 

Peter Musgrave

On Thu, Jul 8, 2010 at 8:04 AM, Marshall Eubanks = <tme@americafree.tv> = wrote:


On Jul 8, 2010, at 6:45 AM, Peter = Musgrave wrote:

Hi Allyn/Stephen,

I read through = these. I think they do a good job of establishing scope and raising = issues and as a bonus they are very easy to read.

Is there a need = to talk about interop with standard video SIP gear? If I use a TP suite = to call a desktop SIP client or a 1080p video conferencing terminal is = there anything about how that should behave that is worth defining under = this work or is that viewed as out of scope?


Read Section 4.2 in = Use Cases

http://tools.ietf.org/html/draft-romanow-dispatch-telep= resence-use-cases-00#section-4.2

which deals with "1 = screen units," which is of course what most videoconferencing = currently is. Is that what you were looking for = ?

Regards
Marshall


As for = draft-romanow-dispatch-telepresence-use-cases-00.txt

1. = (nit)
"This draft …" paragraph has a number of A's = sprinkled in (typos?)

3. "We describe…display = stream" I assume display stream is a stream from a document camera = (as distinct from video stream being from a participant camera?). This = term does not match the words used in the previous = paragraph.

Thanks,

Peter Musgrave


On Thu, Jul = 8, 2010 at 2:46 AM, Cullen Jennings <fluffy@cisco.com> wrote:

Theses look = great - I hope people on the list take some time to read them.

On = Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote:

> Hi = Cullen,
>
> We just put out a problem statement draft = -
> http://tools.ietf.org/html/draft-romanow-dispatch-telep= resence-prob-stat
> ement-00. The document is not complete, = but we feel it is a solid
> beginning.  It does address the = example you mention. The use case doc
> also describes this case = in some detail.
> http://tools.ietf.org/html/draft-romanow-dispatch-telep= resence-use-cases
> -00
>
>
> Do you not = feel that the problem statement draft can serve as a good
> basis = for discussion of problems?
>
> Thanks,
> = Allyn
>
>
> -----Original Message-----
> From: = dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of = Cullen Jennings (fluffy)
> Sent: Wednesday, July 07, 2010 9:41 = AM
> To: DISPATCH list
> Subject: Re: [dispatch] Charter for = Telepresence multi-streams -
> = thirdversion
>
>
> I'm wondering if we could get a = thread going about what are some of the
> specific problems we =  need to solve  then dispatch theses problems to
> = appropriate WGs.
>
> For example one problem is when a = session involves two video session on
> multiple screens how does = one signal which stream is displayed on the
> right and left = screen.
>
> I think having a list of specific problems would = help get this moving
> faster.
>
> = Cullen
>
>
> On Jul 4, 2010, at 10:14 PM, Allyn = Romanow (allyn) wrote:
>
>> Folks,
>> This makes = the change discussed replacing the text in the third
> paragraph = under the Charter section with the text suggested on the = list.
>> It also changes title from "... Description of = Work" to "...Charter"
>>
>> There = weren't any further changes suggested.
>>
>> = Thanks,
>> = Allyn
>>
>>
>>
>>
>> = Multi-streams for Telepresence = Charter
>>
>>
>>
>> = Background
>> One branch of video conferencing has evolved that = is focused on
> immersive "being there" experience. =  Referred to in various ways such as
> virtual conferencing, = telepresence or media spaces, early systems were
> mainly research = projects or business systems with limited deployments.
> In recent = years telepresence systems have seen considerable market
> = success.  Following the model of early systems, the first wave = of
> commercial systems have been typically located in specially = designed
> single-purpose rooms with multiple relatively large = displays permitting
> life size image reproduction, multiple = cameras, encoders, decoders and
> microphones.  These systems = have several important characteristics that
> are different from = more traditional video conferencing systems.
>>
>> The = first difference concerns controlling the visual viewpoint in
> = order to improve participant nonverbal communication. These = systems
> preserve essential group meeting characteristics such as = eye contact,
> group gestures, seating order and spatial audio by = carefully
> orchestrating the miking and camera angles at each of = the sites . This
> is distinct from the more traditional approach = where the geometric
> relationship between media streams is not = used to preserve inter-stream
> communication aspects such as eye = contact and group dynamics.
>>
>> A second difference = is manipulation of the environment to improve
> immersion. =  With telepresence systems, cinematographic aspects of the
> = local environment reproduction are carefully planned including = color,
> table shape, seating and lighting so that when combined = with large high
> quality displays, a strong sense of a = "trompe l'oeil" or "being there"
> immersive = experience is created.  Typical video conference systems do
> = not include these considerations.
>>
>> As = telepresence video systems have become successful in the market,
> = manufacturers have started exploring delivery of the nonverbal
> = communication and immersive values of telepresence via smaller, = less
> expensive and more flexible video conferencing systems for = a variety of
> venues, such as individual offices, homes and = kiosks. These are also
> telepresence systems, since the audio and = video quality is high enough
> to allow clear image reproduction = for nonverbal communication, they are
> able to send and receive = multiple media streams, and large coordinated
> multi image = displays are available for immersive installations.   As = the
> industry develops, the line between telepresence and video = conferencing
> may become blurred as nonverbal communication and = immersive
> installations become broadly = available.
>>
>> Problem
>> Although = telepresence systems are based on open standards such as RTP,
> = SIP, H.264, H.323 suite, they cannot easily interoperate with each = other
> without operator assistance and expensive additional = equipment that
> translates from one vendor to another. It would = be like having to make
> sure all parties are on the same = equipment (and network) when making a
> telephone call.  A = major factor in the inability of Telepresence systems
> to work = with each other is that there is no standard description of the
> = multiple streams that comprise the media flows.
>>
>> = For example, in a multiple screen conference, the video and = audio
> streams sent from remote participants must be understood = by receivers so
> that they can be presented in a coherent and = life-like manner. This
> includes the ability to present the = remote participants at their true
> size for their apparent = distance, while maintaining correct eye contact,
> gesticular = cues, and simultaneously providing a spatial audio sound
> stage = consistent with the video presentation.  The receiving device = that
> decides how to display the incoming information needs to = understand a
> number of variables such as the spatial position of = the speaker, the
> field of view of the cameras, the camera zoom, = which media stream is
> related to each of the displays, = etc.
>>
>> Charter
>> The Telepresence = Multi-Streams work item in DISPATCH is chartered to
> define and = specify for SIP-based systems the content of media
> multi-stream = messages and the way these will be transported.
>>
>> = This work will provide a standard for the exchange of media = semantic
> information that will foster interoperable end stations = and conference
> bridges. It will specify  variables that = describe the semantics of the
> media streams and the recommended = behavior to achieve = interoperability.
>>
>>
>> This requires = considering current widely deployed use cases, as well
> as cases = that are expected to be implemented using the protocol
> framework = produced by this work item.  The methodology for describing
> = the variables must allow extensibility of the variables, since
> = telepresence is still a young technology and may have use cases that = are
> not currently = considered."
>>
>>
>> The work item will = identify use cases, define requirements, and define
> a method for = describing and transporting information about multiple
> media = streams, including a specification of variables required to
> = support the use cases. This work item will consider the reuse of
> = existing IETF protocols and produce an architecture/protocol = framework
> document describing the protocols required to be = implemented to support
> this functionality.  The document = will identify any enhancements
> required to existing protocols as = well as describing new protocol(s) for
> interoperable = multi-streams negotiation that may be required.
>>
>> = Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, = and
> FECframe.
>>
>>
>> = Scope
>> The scope includes both systems that provide a fully = immersive
> experience, and systems that interwork with them and = therefore need to
> understand the same multiple stream = semantics.
>>
>>
>> The focus of this work is = on audio and video multiple streams.  Other
> media types may = be considered, however development of methodologies for
> them is = not within the scope of this work.
>>
>> = Interoperation with standards compliant systems is required, such = as
> SIP-based video conferencing systems.  However, = backwards compatibility
> with existing non-standards compliant = telepresence systems is not
> = required.
>>
>>
>>
>> The group will = produce
>> - Requirements and use cases
>>
>> = - Architectural Framework describing the protocols required to = be
> implemented to support this functionality and identifying = existing
> protocol enhancements and new protocol functionality = required
>>
>> - Specification of a new protocol to = support telepresence
> multi-streams [if = required]
>>
>> Goals and Milestones
>> Nov = 2010
>>
>> Use Cases and Requirements to IESG as = Informational RFC
>> Nov 2010
>> March = 2011
>> Problem Statement to IESG as Informational = RFC
>> Architecture to IESG as Informational RFC
>> = March 2011
>> Revise Charter [IF new protocol is not = required]
>> Nov 2011
>> Submit protocol draft to IESG = as Proposed Standard RFC
>>
>> = _______________________________________________
>> dispatch = mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
&= gt;
>
> Cullen Jennings
> For corporate legal = information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri= /index.html
>
>
>
> = _______________________________________________
> dispatch mailing = list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch
<= br>
Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri= /index.html



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

 

 

------_=_NextPart_001_01CB1E9B.D20E1C3B-- From tom111.taylor@bell.net Thu Jul 8 05:49:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D9C3A6AB8 for ; Thu, 8 Jul 2010 05:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.375 X-Spam-Level: * X-Spam-Status: No, score=1.375 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_50=0.001, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMx7KOcgIVZe for ; Thu, 8 Jul 2010 05:49:45 -0700 (PDT) Received: from blu0-omc4-s33.blu0.hotmail.com (blu0-omc4-s33.blu0.hotmail.com [65.55.111.172]) by core3.amsl.com (Postfix) with ESMTP id AA1593A6AAF for ; Thu, 8 Jul 2010 05:49:45 -0700 (PDT) Received: from BLU0-SMTP60 ([65.55.111.136]) by blu0-omc4-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Jul 2010 05:49:49 -0700 X-Originating-IP: [70.26.17.94] X-Originating-Email: [tom111.taylor@bell.net] Message-ID: Received: from [192.168.2.11] ([70.26.17.94]) by BLU0-SMTP60.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Jul 2010 05:49:48 -0700 Date: Thu, 08 Jul 2010 08:49:47 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dan Wing References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com> In-Reply-To: <27fc01cb1e08$13467f70$39d37e50$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2010 12:49:49.0069 (UTC) FILETIME=[0CEB9BD0:01CB1E9C] Cc: 'DISPATCH list' Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 12:49:46 -0000 http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-03 has just been submitted. Dan Wing wrote: >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Peter Musgrave >> Sent: Thursday, July 01, 2010 12:30 PM >> To: WORLEY, Dale R (Dale) >> Cc: DISPATCH list >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >> >> I concur. >> >> There is some useful background in RFC5853 and perhaps >> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 >> >> And then some things which died on the vine such as: >> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >> and perhaps some others? > > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-02 died. > > -d ... From christer.holmberg@ericsson.com Thu Jul 8 05:50:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2147E3A6AB0 for ; Thu, 8 Jul 2010 05:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcmN6D2UWAmh for ; Thu, 8 Jul 2010 05:50:44 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 6398C3A6AAD for ; Thu, 8 Jul 2010 05:50:43 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-67-4c35c9a6924b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 74.66.10125.6A9C53C4; Thu, 8 Jul 2010 14:50:47 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.94]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 8 Jul 2010 14:50:46 +0200 From: Christer Holmberg To: Marshall Eubanks Date: Thu, 8 Jul 2010 14:50:04 +0200 Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: Acsem5+kvSY2OE07TkCbu9VPOs1SMwAAHcLL Message-ID: References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com>, <8F5532A2-7017-48B2-897F-6FA6E50EE68A@cisco.com> , <32A6C275-C7BC-4562-BE14-ADDC0C4C42C0@americafree.tv> In-Reply-To: <32A6C275-C7BC-4562-BE14-ADDC0C4C42C0@americafree.tv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 12:50:46 -0000 Hi, >>The purpose of RFC 5843 > >5843 ? I think you and Cullen mean rfc 5853, >Requirements from Session Initiation Protocol (SIP) Session Border >Control (SBC) Deployments, >which indeed looks like a useful start here. Correct. At least that's what I meant :) Regards, Christer > was to identity what SBCs are doing, why they do it, and the > potential problems it may cause, and then try to come up with > standard mechanisms in order to solve specific problems. > > Regards, > > Christer > > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings [fluffy@cisco.com] > Sent: Wednesday, July 07, 2010 7:22 PM > To: Muthu ArulMozhi Perumal > Cc: DISPATCH list > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > We had a BOF on pretty much this topic. Some people wrote drafts. > There was pretty much no energy to even send comments on it and it > was hard to find authors. It was eventually published as RFC 5853 > and we all need to give Jani Hautakorpi a big thanks for that. > > The whole experience around 5843 does left me thinking that it was > better to consider B2BUA in any draft and effected any type of UA > including B2BUA. When we ask the question "should we make SBC > interoperate better" we get a resounding yes from everyone. When > asked so what do we need to change to make that happen we get a > resounding "might do that some of the time but certainly not all the > time from the SBC vendors". I like the idea of finding specific > addressable problems such as Hadriels session-id stuff then going > and figuring out how to fix that problem. If there are other > specific problems that can be fixed, by all means write some drafts > and get some proposals on the table. > > > > > On Jul 1, 2010, at 11:27 AM, Muthu ArulMozhi Perumal (mperumal) wrote: > >> In the past few years there has been a proliferation of Session >> Border Controller (SBC) deployments in SIP networks mainly because >> the development of SIP protocol specifications hasn't been able to >> keep in pace with industry and operator requirements. The common >> functions they perform and the architectural issues they introduce >> are described in RFC-5853. >> >> Due to lack of well defined guidelines and best current practices >> many SBC implementations break end-to-end features and introduce >> problems that are difficult to troubleshoot, many a times because >> of poor implementations rather than to meet any specific >> requirements. For example, when they do media processing they >> assume everything coming on the media channel is RTP, don't do even >> basic RTP header validations as recommended in RFC-3550, try to >> decode STUN and DTLS packets as RTPcorrupting them and making them >> useless. >> >> I am wondering whether IETF should have a BEHAVE WG for SBCs, >> similar to the one for NATs, to set guidelines and identify best >> current practices to encourage better SBC implementations, >> interoperability and ease of troubleshooting, rather than just >> keeping quiet and letting them go out of control. >> >> Comments? >> >> Muthu >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > 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 tme@americafree.tv Thu Jul 8 06:17:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 601193A6AC3 for ; Thu, 8 Jul 2010 06:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.207 X-Spam-Level: X-Spam-Status: No, score=-102.207 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LQcXuBaw7ol for ; Thu, 8 Jul 2010 06:17:45 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 52F023A6AB3 for ; Thu, 8 Jul 2010 06:17:45 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 2E5C97D9913A; Thu, 8 Jul 2010 09:17:49 -0400 (EDT) Message-Id: <9A604364-5BBB-41AE-88E8-9D9E94AD669C@americafree.tv> From: Marshall Eubanks To: =?ISO-8859-1?Q?H=E5kon_Dahle?= In-Reply-To: <9F6ACAE02B6DD040A1E259977622CFDB08C24E86@oslexcp1.eu.tandberg.int> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Jul 2010 09:17:48 -0400 References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C333D2@xmb-sjc-221.amer.cisco.com> <9F6ACAE02B6DD040A1E259977622CFDB08C24E86@oslexcp1.eu.tandberg.int> X-Mailer: Apple Mail (2.936) Cc: dispatch@ietf.org Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 13:17:47 -0000 On Jul 8, 2010, at 8:48 AM, H=E5kon Dahle wrote: > Peter =96 > > I agree with you in that Section 4.2 only partly addresses the =20 > problem. It states: > > =93The display sizes and camera fields of view at both sites are =20 > basically similar, such that each camera view is designed to show =20 > two people sitting side by side=94 > > Section 4.2 hence implicitly addresses a single-screen immersive =20 > telepresence (TP) system, since it assumes similar camera view and =20 > screen size as the multi-screen TP room. The attempt in the use cases document was to start with a simple case =20= (4.1) and grow in complexity from there. So, 4.2 was deliberately kept =20= close in nature to 4.1, which is why this (somewhat artificial) =20 restriction. This could, of course, be changed... Regards Marshall > > Heterogenous mixing of immersive TP rooms with =93legacy=94 single =20 > screen/dual screen SIP and H.323 video units reflects a very =20 > typical use case: Most deployments will consist of a small number of =20= > immersive TP rooms (could be a mix of single and multi-screen), a =20 > larger number of regular meeting room system (single screen/dual =20 > screen), and an even larger number of high definition desktop voice =20= > & video appliances / video phones. > > In fact, the ability to mix in audio-only calls is also important. =20 > This is another very typical use case (whenever a large meeting is =20 > called, someone will not be able to attend in person due to travel =96 = =20 > telephony is often the only option) > > -h > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] =20 > On Behalf Of Peter Musgrave > Sent: 8. juli 2010 13:22 > To: Marshall Eubanks > Cc: DISPATCH list; Botzko,Stephen > Subject: Re: [dispatch] Charter for Telepresence multi-streams - =20 > thirdversion > > Hi Marshall, > > 4.2 is part of it - although there may be specific limitations that =20= > a VC unit has that a one screen TP system does not. (Also, ideally =20 > there would be a way to work with such legacy systems without them =20 > supporting new TP features in SIP). > > I am also interested in whether heterogenous mixes of TP rooms and =20 > legacy SIP video units in multi-party conferences is something =20 > viewed as in charter - or if it's better to keep things simple and =20 > just limit the scope to issues of TP interop. > > Regards, > > Peter Musgrave > > On Thu, Jul 8, 2010 at 8:04 AM, Marshall Eubanks =20 > wrote: > > On Jul 8, 2010, at 6:45 AM, Peter Musgrave wrote: > > Hi Allyn/Stephen, > > I read through these. I think they do a good job of establishing =20 > scope and raising issues and as a bonus they are very easy to read. > > Is there a need to talk about interop with standard video SIP gear? =20= > If I use a TP suite to call a desktop SIP client or a 1080p video =20 > conferencing terminal is there anything about how that should behave =20= > that is worth defining under this work or is that viewed as out of =20 > scope? > > > Read Section 4.2 in Use Cases > > = http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases-0= 0#section-4.2 > > which deals with "1 screen units," which is of course what most =20 > videoconferencing currently is. Is that what you were looking for ? > > Regards > Marshall > > > > As for draft-romanow-dispatch-telepresence-use-cases-00.txt > > 1. (nit) > "This draft =85" paragraph has a number of A's sprinkled in (typos?) > > 3. "We describe=85display stream" I assume display stream is a stream =20= > from a document camera (as distinct from video stream being from a =20 > participant camera?). This term does not match the words used in the =20= > previous paragraph. > > Thanks, > > Peter Musgrave > > > On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings =20 > wrote: > > Theses look great - I hope people on the list take some time to read =20= > them. > > On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote: > > > Hi Cullen, > > > > We just put out a problem statement draft - > > = http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-prob-stat > > ement-00. The document is not complete, but we feel it is a solid > > beginning. It does address the example you mention. The use case =20= > doc > > also describes this case in some detail. > > = http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases > > -00 > > > > > > Do you not feel that the problem statement draft can serve as a good > > basis for discussion of problems? > > > > Thanks, > > Allyn > > > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] =20= > On > > Behalf Of Cullen Jennings (fluffy) > > Sent: Wednesday, July 07, 2010 9:41 AM > > To: DISPATCH list > > Subject: Re: [dispatch] Charter for Telepresence multi-streams - > > thirdversion > > > > > > I'm wondering if we could get a thread going about what are some =20 > of the > > specific problems we need to solve then dispatch theses problems =20= > to > > appropriate WGs. > > > > For example one problem is when a session involves two video =20 > session on > > multiple screens how does one signal which stream is displayed on =20= > the > > right and left screen. > > > > I think having a list of specific problems would help get this =20 > moving > > faster. > > > > Cullen > > > > > > On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote: > > > >> Folks, > >> This makes the change discussed replacing the text in the third > > paragraph under the Charter section with the text suggested on the =20= > list. > >> It also changes title from "... Description of Work" to =20 > "...Charter" > >> > >> There weren't any further changes suggested. > >> > >> Thanks, > >> Allyn > >> > >> > >> > >> > >> Multi-streams for Telepresence Charter > >> > >> > >> > >> Background > >> One branch of video conferencing has evolved that is focused on > > immersive "being there" experience. Referred to in various ways =20 > such as > > virtual conferencing, telepresence or media spaces, early systems =20= > were > > mainly research projects or business systems with limited =20 > deployments. > > In recent years telepresence systems have seen considerable market > > success. Following the model of early systems, the first wave of > > commercial systems have been typically located in specially designed > > single-purpose rooms with multiple relatively large displays =20 > permitting > > life size image reproduction, multiple cameras, encoders, decoders =20= > and > > microphones. These systems have several important characteristics =20= > that > > are different from more traditional video conferencing systems. > >> > >> The first difference concerns controlling the visual viewpoint in > > order to improve participant nonverbal communication. These systems > > preserve essential group meeting characteristics such as eye =20 > contact, > > group gestures, seating order and spatial audio by carefully > > orchestrating the miking and camera angles at each of the sites . =20= > This > > is distinct from the more traditional approach where the geometric > > relationship between media streams is not used to preserve inter-=20 > stream > > communication aspects such as eye contact and group dynamics. > >> > >> A second difference is manipulation of the environment to improve > > immersion. With telepresence systems, cinematographic aspects of =20= > the > > local environment reproduction are carefully planned including =20 > color, > > table shape, seating and lighting so that when combined with large =20= > high > > quality displays, a strong sense of a "trompe l'oeil" or "being =20 > there" > > immersive experience is created. Typical video conference systems =20= > do > > not include these considerations. > >> > >> As telepresence video systems have become successful in the market, > > manufacturers have started exploring delivery of the nonverbal > > communication and immersive values of telepresence via smaller, less > > expensive and more flexible video conferencing systems for a =20 > variety of > > venues, such as individual offices, homes and kiosks. These are also > > telepresence systems, since the audio and video quality is high =20 > enough > > to allow clear image reproduction for nonverbal communication, =20 > they are > > able to send and receive multiple media streams, and large =20 > coordinated > > multi image displays are available for immersive installations. =20= > As the > > industry develops, the line between telepresence and video =20 > conferencing > > may become blurred as nonverbal communication and immersive > > installations become broadly available. > >> > >> Problem > >> Although telepresence systems are based on open standards such as =20= > RTP, > > SIP, H.264, H.323 suite, they cannot easily interoperate with each =20= > other > > without operator assistance and expensive additional equipment that > > translates from one vendor to another. It would be like having to =20= > make > > sure all parties are on the same equipment (and network) when =20 > making a > > telephone call. A major factor in the inability of Telepresence =20 > systems > > to work with each other is that there is no standard description =20 > of the > > multiple streams that comprise the media flows. > >> > >> For example, in a multiple screen conference, the video and audio > > streams sent from remote participants must be understood by =20 > receivers so > > that they can be presented in a coherent and life-like manner. This > > includes the ability to present the remote participants at their =20 > true > > size for their apparent distance, while maintaining correct eye =20 > contact, > > gesticular cues, and simultaneously providing a spatial audio sound > > stage consistent with the video presentation. The receiving =20 > device that > > decides how to display the incoming information needs to =20 > understand a > > number of variables such as the spatial position of the speaker, the > > field of view of the cameras, the camera zoom, which media stream is > > related to each of the displays, etc. > >> > >> Charter > >> The Telepresence Multi-Streams work item in DISPATCH is chartered =20= > to > > define and specify for SIP-based systems the content of media > > multi-stream messages and the way these will be transported. > >> > >> This work will provide a standard for the exchange of media =20 > semantic > > information that will foster interoperable end stations and =20 > conference > > bridges. It will specify variables that describe the semantics of =20= > the > > media streams and the recommended behavior to achieve =20 > interoperability. > >> > >> > >> This requires considering current widely deployed use cases, as =20 > well > > as cases that are expected to be implemented using the protocol > > framework produced by this work item. The methodology for =20 > describing > > the variables must allow extensibility of the variables, since > > telepresence is still a young technology and may have use cases =20 > that are > > not currently considered." > >> > >> > >> The work item will identify use cases, define requirements, and =20 > define > > a method for describing and transporting information about multiple > > media streams, including a specification of variables required to > > support the use cases. This work item will consider the reuse of > > existing IETF protocols and produce an architecture/protocol =20 > framework > > document describing the protocols required to be implemented to =20 > support > > this functionality. The document will identify any enhancements > > required to existing protocols as well as describing new =20 > protocol(s) for > > interoperable multi-streams negotiation that may be required. > >> > >> Relevant work to be drawn upon has been done in XCON, MMUSIC, =20 > AVT, and > > FECframe. > >> > >> > >> Scope > >> The scope includes both systems that provide a fully immersive > > experience, and systems that interwork with them and therefore =20 > need to > > understand the same multiple stream semantics. > >> > >> > >> The focus of this work is on audio and video multiple streams. =20 > Other > > media types may be considered, however development of =20 > methodologies for > > them is not within the scope of this work. > >> > >> Interoperation with standards compliant systems is required, such =20= > as > > SIP-based video conferencing systems. However, backwards =20 > compatibility > > with existing non-standards compliant telepresence systems is not > > required. > >> > >> > >> > >> The group will produce > >> - Requirements and use cases > >> > >> - Architectural Framework describing the protocols required to be > > implemented to support this functionality and identifying existing > > protocol enhancements and new protocol functionality required > >> > >> - Specification of a new protocol to support telepresence > > multi-streams [if required] > >> > >> Goals and Milestones > >> Nov 2010 > >> > >> Use Cases and Requirements to IESG as Informational RFC > >> Nov 2010 > >> March 2011 > >> Problem Statement to IESG as Informational RFC > >> Architecture to IESG as Informational RFC > >> March 2011 > >> Revise Charter [IF new protocol is not required] > >> Nov 2011 > >> Submit protocol draft to IESG as Proposed Standard RFC > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > > > Cullen Jennings > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > 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 tme@americafree.tv Thu Jul 8 06:42:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2FDB3A6818 for ; Thu, 8 Jul 2010 06:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.365 X-Spam-Level: X-Spam-Status: No, score=-102.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9gpg--oTBxn for ; Thu, 8 Jul 2010 06:42:37 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id C084C3A659C for ; Thu, 8 Jul 2010 06:42:36 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 3713E7D9A724; Thu, 8 Jul 2010 09:41:54 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Peter Musgrave In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Jul 2010 09:41:53 -0400 References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C333D2@xmb-sjc-221.amer.cisco.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list , "Botzko, Stephen" Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 13:42:39 -0000 Dear Peter; On Jul 8, 2010, at 8:21 AM, Peter Musgrave wrote: > Hi Marshall, > > 4.2 is part of it - although there may be specific limitations that =20= > a VC unit has that a one screen TP system does not. I am not aware of any; if you know of any, please let me know. I define immersive telepresence as a system to make you feel that you =20= and remote participants are in the same room. Telepresence is a combination of telecommunications technology (high =20 quality video, matching of audio and video handedness, etc.) and =20 "stagecraft" (the layout and decor of the room, the inconspicuous =20 locations of cameras and microphones, etc.). In this work at the IETF =20= we will focus on the technology, and the stagecraft is out of scope. =20 Most of the technological complications with telepresence occur =20 precisely because you have multiple screens and multiple participants, =20= so adding in single screen units doesn't IMO add too much complexity. > (Also, ideally there would be a way to work with such legacy systems =20= > without them supporting new TP features in SIP). > > I am also interested in whether heterogenous mixes of TP rooms and =20 > legacy SIP video units in multi-party conferences is something =20 > viewed as in charter - or if it's better to keep things simple and =20 > just limit the scope to issues of TP interop. > I feel that "heterogenous mixes" should be in charter. On the scope of this work : there are vastly more videoconferencing =20 units using H.323 than SIP, and whether or not we should worry about H.=20= 323 interop is something that I think should be decided in this =20 charter discussion. (I am neutral about this; bringing in H.323 brings =20= in a whole host of complications, but it is definitely the IPv4 of the =20= videoconferencing world.) Regards Marshall > Regards, > > Peter Musgrave > > On Thu, Jul 8, 2010 at 8:04 AM, Marshall Eubanks =20 > wrote: > > On Jul 8, 2010, at 6:45 AM, Peter Musgrave wrote: > > Hi Allyn/Stephen, > > I read through these. I think they do a good job of establishing =20 > scope and raising issues and as a bonus they are very easy to read. > > Is there a need to talk about interop with standard video SIP gear? =20= > If I use a TP suite to call a desktop SIP client or a 1080p video =20 > conferencing terminal is there anything about how that should behave =20= > that is worth defining under this work or is that viewed as out of =20 > scope? > > > Read Section 4.2 in Use Cases > > = http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases-0= 0#section-4.2 > > which deals with "1 screen units," which is of course what most =20 > videoconferencing currently is. Is that what you were looking for ? > > Regards > Marshall > > > > As for draft-romanow-dispatch-telepresence-use-cases-00.txt > > 1. (nit) > "This draft =85" paragraph has a number of A's sprinkled in (typos?) > > 3. "We describe=85display stream" I assume display stream is a stream =20= > from a document camera (as distinct from video stream being from a =20 > participant camera?). This term does not match the words used in the =20= > previous paragraph. > > Thanks, > > Peter Musgrave > > > On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings =20 > wrote: > > Theses look great - I hope people on the list take some time to read =20= > them. > > On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote: > > > Hi Cullen, > > > > We just put out a problem statement draft - > > = http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-prob-stat > > ement-00. The document is not complete, but we feel it is a solid > > beginning. It does address the example you mention. The use case =20= > doc > > also describes this case in some detail. > > = http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases > > -00 > > > > > > Do you not feel that the problem statement draft can serve as a good > > basis for discussion of problems? > > > > Thanks, > > Allyn > > > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] =20= > On > > Behalf Of Cullen Jennings (fluffy) > > Sent: Wednesday, July 07, 2010 9:41 AM > > To: DISPATCH list > > Subject: Re: [dispatch] Charter for Telepresence multi-streams - > > thirdversion > > > > > > I'm wondering if we could get a thread going about what are some =20 > of the > > specific problems we need to solve then dispatch theses problems =20= > to > > appropriate WGs. > > > > For example one problem is when a session involves two video =20 > session on > > multiple screens how does one signal which stream is displayed on =20= > the > > right and left screen. > > > > I think having a list of specific problems would help get this =20 > moving > > faster. > > > > Cullen > > > > > > On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote: > > > >> Folks, > >> This makes the change discussed replacing the text in the third > > paragraph under the Charter section with the text suggested on the =20= > list. > >> It also changes title from "... Description of Work" to =20 > "...Charter" > >> > >> There weren't any further changes suggested. > >> > >> Thanks, > >> Allyn > >> > >> > >> > >> > >> Multi-streams for Telepresence Charter > >> > >> > >> > >> Background > >> One branch of video conferencing has evolved that is focused on > > immersive "being there" experience. Referred to in various ways =20 > such as > > virtual conferencing, telepresence or media spaces, early systems =20= > were > > mainly research projects or business systems with limited =20 > deployments. > > In recent years telepresence systems have seen considerable market > > success. Following the model of early systems, the first wave of > > commercial systems have been typically located in specially designed > > single-purpose rooms with multiple relatively large displays =20 > permitting > > life size image reproduction, multiple cameras, encoders, decoders =20= > and > > microphones. These systems have several important characteristics =20= > that > > are different from more traditional video conferencing systems. > >> > >> The first difference concerns controlling the visual viewpoint in > > order to improve participant nonverbal communication. These systems > > preserve essential group meeting characteristics such as eye =20 > contact, > > group gestures, seating order and spatial audio by carefully > > orchestrating the miking and camera angles at each of the sites . =20= > This > > is distinct from the more traditional approach where the geometric > > relationship between media streams is not used to preserve inter-=20 > stream > > communication aspects such as eye contact and group dynamics. > >> > >> A second difference is manipulation of the environment to improve > > immersion. With telepresence systems, cinematographic aspects of =20= > the > > local environment reproduction are carefully planned including =20 > color, > > table shape, seating and lighting so that when combined with large =20= > high > > quality displays, a strong sense of a "trompe l'oeil" or "being =20 > there" > > immersive experience is created. Typical video conference systems =20= > do > > not include these considerations. > >> > >> As telepresence video systems have become successful in the market, > > manufacturers have started exploring delivery of the nonverbal > > communication and immersive values of telepresence via smaller, less > > expensive and more flexible video conferencing systems for a =20 > variety of > > venues, such as individual offices, homes and kiosks. These are also > > telepresence systems, since the audio and video quality is high =20 > enough > > to allow clear image reproduction for nonverbal communication, =20 > they are > > able to send and receive multiple media streams, and large =20 > coordinated > > multi image displays are available for immersive installations. =20= > As the > > industry develops, the line between telepresence and video =20 > conferencing > > may become blurred as nonverbal communication and immersive > > installations become broadly available. > >> > >> Problem > >> Although telepresence systems are based on open standards such as =20= > RTP, > > SIP, H.264, H.323 suite, they cannot easily interoperate with each =20= > other > > without operator assistance and expensive additional equipment that > > translates from one vendor to another. It would be like having to =20= > make > > sure all parties are on the same equipment (and network) when =20 > making a > > telephone call. A major factor in the inability of Telepresence =20 > systems > > to work with each other is that there is no standard description =20 > of the > > multiple streams that comprise the media flows. > >> > >> For example, in a multiple screen conference, the video and audio > > streams sent from remote participants must be understood by =20 > receivers so > > that they can be presented in a coherent and life-like manner. This > > includes the ability to present the remote participants at their =20 > true > > size for their apparent distance, while maintaining correct eye =20 > contact, > > gesticular cues, and simultaneously providing a spatial audio sound > > stage consistent with the video presentation. The receiving =20 > device that > > decides how to display the incoming information needs to =20 > understand a > > number of variables such as the spatial position of the speaker, the > > field of view of the cameras, the camera zoom, which media stream is > > related to each of the displays, etc. > >> > >> Charter > >> The Telepresence Multi-Streams work item in DISPATCH is chartered =20= > to > > define and specify for SIP-based systems the content of media > > multi-stream messages and the way these will be transported. > >> > >> This work will provide a standard for the exchange of media =20 > semantic > > information that will foster interoperable end stations and =20 > conference > > bridges. It will specify variables that describe the semantics of =20= > the > > media streams and the recommended behavior to achieve =20 > interoperability. > >> > >> > >> This requires considering current widely deployed use cases, as =20 > well > > as cases that are expected to be implemented using the protocol > > framework produced by this work item. The methodology for =20 > describing > > the variables must allow extensibility of the variables, since > > telepresence is still a young technology and may have use cases =20 > that are > > not currently considered." > >> > >> > >> The work item will identify use cases, define requirements, and =20 > define > > a method for describing and transporting information about multiple > > media streams, including a specification of variables required to > > support the use cases. This work item will consider the reuse of > > existing IETF protocols and produce an architecture/protocol =20 > framework > > document describing the protocols required to be implemented to =20 > support > > this functionality. The document will identify any enhancements > > required to existing protocols as well as describing new =20 > protocol(s) for > > interoperable multi-streams negotiation that may be required. > >> > >> Relevant work to be drawn upon has been done in XCON, MMUSIC, =20 > AVT, and > > FECframe. > >> > >> > >> Scope > >> The scope includes both systems that provide a fully immersive > > experience, and systems that interwork with them and therefore =20 > need to > > understand the same multiple stream semantics. > >> > >> > >> The focus of this work is on audio and video multiple streams. =20 > Other > > media types may be considered, however development of =20 > methodologies for > > them is not within the scope of this work. > >> > >> Interoperation with standards compliant systems is required, such =20= > as > > SIP-based video conferencing systems. However, backwards =20 > compatibility > > with existing non-standards compliant telepresence systems is not > > required. > >> > >> > >> > >> The group will produce > >> - Requirements and use cases > >> > >> - Architectural Framework describing the protocols required to be > > implemented to support this functionality and identifying existing > > protocol enhancements and new protocol functionality required > >> > >> - Specification of a new protocol to support telepresence > > multi-streams [if required] > >> > >> Goals and Milestones > >> Nov 2010 > >> > >> Use Cases and Requirements to IESG as Informational RFC > >> Nov 2010 > >> March 2011 > >> Problem Statement to IESG as Informational RFC > >> Architecture to IESG as Informational RFC > >> March 2011 > >> Revise Charter [IF new protocol is not required] > >> Nov 2011 > >> Submit protocol draft to IESG as Proposed Standard RFC > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > > > Cullen Jennings > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > 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 stephen.botzko@gmail.com Thu Jul 8 07:20:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7D7E3A6820 for ; Thu, 8 Jul 2010 07:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.598 X-Spam-Level: X-Spam-Status: No, score=-1.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_31=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hrn4Y6M52YSv for ; Thu, 8 Jul 2010 07:20:42 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 0A6EE3A6964 for ; Thu, 8 Jul 2010 07:20:41 -0700 (PDT) Received: by wwb24 with SMTP id 24so3236734wwb.13 for ; Thu, 08 Jul 2010 07:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=TUYWow5wkoNs3PFTGjZfeqK6vijyHXToKBTEbTyZiCQ=; b=Ffi+sRxciJnS03wXlrD7POMu7SR/tfdfH9HCfxhjy81m79eDl0JV70gWbLzGbC5OkZ BymLZQEYbGHpruTx28Sw2ijhHMjBr7nQauZOD32hgakqCOa5Wl7DRFz60pfPfuR54Y9u P7r5+PJ60MyQ2Z6NmQnvzdFO/1g4HqMk7qhu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=IKryRvPpBg1MqleyyUHp/sk5H+XO8cgRE0V7m6X4seY7ltqG3YrKmqNHxKeoJjkzSJ BoDAoToOxttwROsNSYvIxEKEhsna3hF+e+U+poYOPCW7agU4Ar3XNMo/RogbMhNAQHBP 2pURKby+hwJPkoJaQ0dHBPYIvuqIvqKd46fc8= MIME-Version: 1.0 Received: by 10.227.154.136 with SMTP id o8mr4229378wbw.189.1278598841841; Thu, 08 Jul 2010 07:20:41 -0700 (PDT) Received: by 10.216.80.84 with HTTP; Thu, 8 Jul 2010 07:20:41 -0700 (PDT) In-Reply-To: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C333D2@xmb-sjc-221.amer.cisco.com> Date: Thu, 8 Jul 2010 10:20:41 -0400 Message-ID: From: stephen botzko To: Peter Musgrave Content-Type: multipart/alternative; boundary=00163646d33ec737df048ae0fd70 Cc: DISPATCH list , "Botzko, Stephen" Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 14:20:45 -0000 --00163646d33ec737df048ae0fd70 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Peter Thanks for the feedback. I agree that interop with standard video SIP gear will clearly be a requirement. Since people are finding the drafts unclear on that point, we should clarify them. As far as Marshall's comment on H.323 goes, if the telepresence systems interoperate with normal SIP video endpoints, then they will also interoperate with normal SIP<->H.323 gateways. Stephen Botzko On Thu, Jul 8, 2010 at 6:45 AM, Peter Musgrave wrote: > Hi Allyn/Stephen, > > > I read through these. I think they do a good job of establishing scope an= d > raising issues and as a bonus they are very easy to read. > > > Is there a need to talk about interop with standard video SIP gear? If I > use a TP suite to call a desktop SIP client or a 1080p video conferencing > terminal is there anything about how that should behave that is worth > defining under this work or is that viewed as out of scope? > > > As for draft-romanow-dispatch-telepresence-use-cases-00.txt > > > 1. (nit) > > *"*This draft =85" paragraph has a number of A's sprinkled in (typos?) > > > 3. "We describe=85display stream" I assume display stream is a stream fro= m a > document camera (as distinct from video stream being from a participant > camera?). This term does not match the words used in the previous paragra= ph. > > > Thanks, > > > Peter Musgrave > > > On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings wrote: > >> >> Theses look great - I hope people on the list take some time to read the= m. >> >> On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote: >> >> > Hi Cullen, >> > >> > We just put out a problem statement draft - >> > >> http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-prob-stat >> > ement-00. The document is not complete, but we feel it is a solid >> > beginning. It does address the example you mention. The use case doc >> > also describes this case in some detail. >> > >> http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases >> > -00 >> > >> > >> > Do you not feel that the problem statement draft can serve as a good >> > basis for discussion of problems? >> > >> > Thanks, >> > Allyn >> > >> > >> > -----Original Message----- >> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> > Behalf Of Cullen Jennings (fluffy) >> > Sent: Wednesday, July 07, 2010 9:41 AM >> > To: DISPATCH list >> > Subject: Re: [dispatch] Charter for Telepresence multi-streams - >> > thirdversion >> > >> > >> > I'm wondering if we could get a thread going about what are some of th= e >> > specific problems we need to solve then dispatch theses problems to >> > appropriate WGs. >> > >> > For example one problem is when a session involves two video session o= n >> > multiple screens how does one signal which stream is displayed on the >> > right and left screen. >> > >> > I think having a list of specific problems would help get this moving >> > faster. >> > >> > Cullen >> > >> > >> > On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote: >> > >> >> Folks, >> >> This makes the change discussed replacing the text in the third >> > paragraph under the Charter section with the text suggested on the lis= t. >> >> It also changes title from "... Description of Work" to "...Charter" >> >> >> >> There weren't any further changes suggested. >> >> >> >> Thanks, >> >> Allyn >> >> >> >> >> >> >> >> >> >> Multi-streams for Telepresence Charter >> >> >> >> >> >> >> >> Background >> >> One branch of video conferencing has evolved that is focused on >> > immersive "being there" experience. Referred to in various ways such = as >> > virtual conferencing, telepresence or media spaces, early systems were >> > mainly research projects or business systems with limited deployments. >> > In recent years telepresence systems have seen considerable market >> > success. Following the model of early systems, the first wave of >> > commercial systems have been typically located in specially designed >> > single-purpose rooms with multiple relatively large displays permittin= g >> > life size image reproduction, multiple cameras, encoders, decoders and >> > microphones. These systems have several important characteristics tha= t >> > are different from more traditional video conferencing systems. >> >> >> >> The first difference concerns controlling the visual viewpoint in >> > order to improve participant nonverbal communication. These systems >> > preserve essential group meeting characteristics such as eye contact, >> > group gestures, seating order and spatial audio by carefully >> > orchestrating the miking and camera angles at each of the sites . This >> > is distinct from the more traditional approach where the geometric >> > relationship between media streams is not used to preserve inter-strea= m >> > communication aspects such as eye contact and group dynamics. >> >> >> >> A second difference is manipulation of the environment to improve >> > immersion. With telepresence systems, cinematographic aspects of the >> > local environment reproduction are carefully planned including color, >> > table shape, seating and lighting so that when combined with large hig= h >> > quality displays, a strong sense of a "trompe l'oeil" or "being there" >> > immersive experience is created. Typical video conference systems do >> > not include these considerations. >> >> >> >> As telepresence video systems have become successful in the market, >> > manufacturers have started exploring delivery of the nonverbal >> > communication and immersive values of telepresence via smaller, less >> > expensive and more flexible video conferencing systems for a variety o= f >> > venues, such as individual offices, homes and kiosks. These are also >> > telepresence systems, since the audio and video quality is high enough >> > to allow clear image reproduction for nonverbal communication, they ar= e >> > able to send and receive multiple media streams, and large coordinated >> > multi image displays are available for immersive installations. As t= he >> > industry develops, the line between telepresence and video conferencin= g >> > may become blurred as nonverbal communication and immersive >> > installations become broadly available. >> >> >> >> Problem >> >> Although telepresence systems are based on open standards such as RTP= , >> > SIP, H.264, H.323 suite, they cannot easily interoperate with each oth= er >> > without operator assistance and expensive additional equipment that >> > translates from one vendor to another. It would be like having to make >> > sure all parties are on the same equipment (and network) when making a >> > telephone call. A major factor in the inability of Telepresence syste= ms >> > to work with each other is that there is no standard description of th= e >> > multiple streams that comprise the media flows. >> >> >> >> For example, in a multiple screen conference, the video and audio >> > streams sent from remote participants must be understood by receivers = so >> > that they can be presented in a coherent and life-like manner. This >> > includes the ability to present the remote participants at their true >> > size for their apparent distance, while maintaining correct eye contac= t, >> > gesticular cues, and simultaneously providing a spatial audio sound >> > stage consistent with the video presentation. The receiving device th= at >> > decides how to display the incoming information needs to understand a >> > number of variables such as the spatial position of the speaker, the >> > field of view of the cameras, the camera zoom, which media stream is >> > related to each of the displays, etc. >> >> >> >> Charter >> >> The Telepresence Multi-Streams work item in DISPATCH is chartered to >> > define and specify for SIP-based systems the content of media >> > multi-stream messages and the way these will be transported. >> >> >> >> This work will provide a standard for the exchange of media semantic >> > information that will foster interoperable end stations and conference >> > bridges. It will specify variables that describe the semantics of the >> > media streams and the recommended behavior to achieve interoperability= . >> >> >> >> >> >> This requires considering current widely deployed use cases, as well >> > as cases that are expected to be implemented using the protocol >> > framework produced by this work item. The methodology for describing >> > the variables must allow extensibility of the variables, since >> > telepresence is still a young technology and may have use cases that a= re >> > not currently considered." >> >> >> >> >> >> The work item will identify use cases, define requirements, and defin= e >> > a method for describing and transporting information about multiple >> > media streams, including a specification of variables required to >> > support the use cases. This work item will consider the reuse of >> > existing IETF protocols and produce an architecture/protocol framework >> > document describing the protocols required to be implemented to suppor= t >> > this functionality. The document will identify any enhancements >> > required to existing protocols as well as describing new protocol(s) f= or >> > interoperable multi-streams negotiation that may be required. >> >> >> >> Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, an= d >> > FECframe. >> >> >> >> >> >> Scope >> >> The scope includes both systems that provide a fully immersive >> > experience, and systems that interwork with them and therefore need to >> > understand the same multiple stream semantics. >> >> >> >> >> >> The focus of this work is on audio and video multiple streams. Other >> > media types may be considered, however development of methodologies fo= r >> > them is not within the scope of this work. >> >> >> >> Interoperation with standards compliant systems is required, such as >> > SIP-based video conferencing systems. However, backwards compatibilit= y >> > with existing non-standards compliant telepresence systems is not >> > required. >> >> >> >> >> >> >> >> The group will produce >> >> - Requirements and use cases >> >> >> >> - Architectural Framework describing the protocols required to be >> > implemented to support this functionality and identifying existing >> > protocol enhancements and new protocol functionality required >> >> >> >> - Specification of a new protocol to support telepresence >> > multi-streams [if required] >> >> >> >> Goals and Milestones >> >> Nov 2010 >> >> >> >> Use Cases and Requirements to IESG as Informational RFC >> >> Nov 2010 >> >> March 2011 >> >> Problem Statement to IESG as Informational RFC >> >> Architecture to IESG as Informational RFC >> >> March 2011 >> >> Revise Charter [IF new protocol is not required] >> >> Nov 2011 >> >> Submit protocol draft to IESG as Proposed Standard RFC >> >> >> >> _______________________________________________ >> >> dispatch mailing list >> >> dispatch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dispatch >> > >> > >> > Cullen Jennings >> > For corporate legal information go to: >> > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> > >> > >> > >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> >> >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> >> _______________________________________________ >> 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 > > --00163646d33ec737df048ae0fd70 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Peter

Thanks for the feedback.

I agree that interop with s= tandard video SIP gear will clearly be a requirement.=A0 Since people are f= inding the drafts unclear on that point, we should clarify them.

As = far as Marshall's comment on H.323 goes, if the telepresence systems in= teroperate with normal SIP video endpoints, then they will also interoperat= e with normal SIP<->H.323 gateways.=A0

Stephen Botzko

On Thu, Jul 8, 2010 at= 6:45 AM, Peter Musgrave <peter.musgrave@magorcorp.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border= -left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

Hi Allyn/Stephen,


I read through these. I think they do a good job of establishing scope and = raising issues and as a bonus they are very easy to read.


Is there a need to talk about interop with standard video SIP gear? If I us= e a TP suite to call a desktop SIP client or a 1080p video conferencing ter= minal is there anything about how that should behave that is worth defining= under this work or is that viewed as out of scope?=A0


As for draft-romanow-dispatch-telepresence-use-cas= es-00.txt


1. (nit)

"This draft =85&q= uot; paragraph has a number of A's sprinkled in (typos?)


3. "We describe=85displa= y stream" I assume display stream is a stream from a document camera (= as distinct from video stream being from a participant camera?). This term = does not match the words used in the previous paragraph.


Thanks,=A0


Peter Musgrave



On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings <fluffy@cisco.com><= /span> wrote:

Theses look great - I hope people on the list take some time to read them.<= br>

On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote:

> Hi Cullen,
>
> We just put out a problem statement draft -
> http://tools.ietf.org/html/draft-romanow-d= ispatch-telepresence-prob-stat
> ement-00. The document is not complete, but we feel it is a solid
> beginning. =A0It does address the example you mention. The use case do= c
> also describes this case in some detail.
> http://tools.ietf.org/html/draft-romanow-d= ispatch-telepresence-use-cases
> -00
>
>
> Do you not feel that the problem statement draft can serve as a good > basis for discussion of problems?
>
> Thanks,
> Allyn
>
>
> -----Original Message-----
> From: d= ispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf Of Cullen Jennings (fluffy)
> Sent: Wednesday, July 07, 2010 9:41 AM
> To: DISPATCH list
> Subject: Re: [dispatch] Charter for Telepresence multi-streams -
> thirdversion
>
>
> I'm wondering if we could get a thread going about what are some o= f the
> specific problems we =A0need to solve =A0then dispatch theses problems= to
> appropriate WGs.
>
> For example one problem is when a session involves two video session o= n
> multiple screens how does one signal which stream is displayed on the<= br> > right and left screen.
>
> I think having a list of specific problems would help get this moving<= br> > faster.
>
> Cullen
>
>
> On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote:
>
>> Folks,
>> This makes the change discussed replacing the text in the third > paragraph under the Charter section with the text suggested on the lis= t.
>> It also changes title from "... Description of Work" to = "...Charter"
>>
>> There weren't any further changes suggested.
>>
>> Thanks,
>> Allyn
>>
>>
>>
>>
>> Multi-streams for Telepresence Charter
>>
>>
>>
>> Background
>> One branch of video conferencing has evolved that is focused on > immersive "being there" experience. =A0Referred to in variou= s ways such as
> virtual conferencing, telepresence or media spaces, early systems were=
> mainly research projects or business systems with limited deployments.=
> In recent years telepresence systems have seen considerable market
> success. =A0Following the model of early systems, the first wave of > commercial systems have been typically located in specially designed > single-purpose rooms with multiple relatively large displays permittin= g
> life size image reproduction, multiple cameras, encoders, decoders and=
> microphones. =A0These systems have several important characteristics t= hat
> are different from more traditional video conferencing systems.
>>
>> The first difference concerns controlling the visual viewpoint in<= br> > order to improve participant nonverbal communication. These systems > preserve essential group meeting characteristics such as eye contact,<= br> > group gestures, seating order and spatial audio by carefully
> orchestrating the miking and camera angles at each of the sites . This=
> is distinct from the more traditional approach where the geometric
> relationship between media streams is not used to preserve inter-strea= m
> communication aspects such as eye contact and group dynamics.
>>
>> A second difference is manipulation of the environment to improve<= br> > immersion. =A0With telepresence systems, cinematographic aspects of th= e
> local environment reproduction are carefully planned including color,<= br> > table shape, seating and lighting so that when combined with large hig= h
> quality displays, a strong sense of a "trompe l'oeil" or= "being there"
> immersive experience is created. =A0Typical video conference systems d= o
> not include these considerations.
>>
>> As telepresence video systems have become successful in the market= ,
> manufacturers have started exploring delivery of the nonverbal
> communication and immersive values of telepresence via smaller, less > expensive and more flexible video conferencing systems for a variety o= f
> venues, such as individual offices, homes and kiosks. These are also > telepresence systems, since the audio and video quality is high enough=
> to allow clear image reproduction for nonverbal communication, they ar= e
> able to send and receive multiple media streams, and large coordinated=
> multi image displays are available for immersive installations. =A0 As= the
> industry develops, the line between telepresence and video conferencin= g
> may become blurred as nonverbal communication and immersive
> installations become broadly available.
>>
>> Problem
>> Although telepresence systems are based on open standards such as = RTP,
> SIP, H.264, H.323 suite, they cannot easily interoperate with each oth= er
> without operator assistance and expensive additional equipment that > translates from one vendor to another. It would be like having to make=
> sure all parties are on the same equipment (and network) when making a=
> telephone call. =A0A major factor in the inability of Telepresence sys= tems
> to work with each other is that there is no standard description of th= e
> multiple streams that comprise the media flows.
>>
>> For example, in a multiple screen conference, the video and audio<= br> > streams sent from remote participants must be understood by receivers = so
> that they can be presented in a coherent and life-like manner. This > includes the ability to present the remote participants at their true<= br> > size for their apparent distance, while maintaining correct eye contac= t,
> gesticular cues, and simultaneously providing a spatial audio sound > stage consistent with the video presentation. =A0The receiving device = that
> decides how to display the incoming information needs to understand a<= br> > number of variables such as the spatial position of the speaker, the > field of view of the cameras, the camera zoom, which media stream is > related to each of the displays, etc.
>>
>> Charter
>> The Telepresence Multi-Streams work item in DISPATCH is chartered = to
> define and specify for SIP-based systems the content of media
> multi-stream messages and the way these will be transported.
>>
>> This work will provide a standard for the exchange of media semant= ic
> information that will foster interoperable end stations and conference=
> bridges. It will specify =A0variables that describe the semantics of t= he
> media streams and the recommended behavior to achieve interoperability= .
>>
>>
>> This requires considering current widely deployed use cases, as we= ll
> as cases that are expected to be implemented using the protocol
> framework produced by this work item. =A0The methodology for describin= g
> the variables must allow extensibility of the variables, since
> telepresence is still a young technology and may have use cases that a= re
> not currently considered."
>>
>>
>> The work item will identify use cases, define requirements, and de= fine
> a method for describing and transporting information about multiple > media streams, including a specification of variables required to
> support the use cases. This work item will consider the reuse of
> existing IETF protocols and produce an architecture/protocol framework=
> document describing the protocols required to be implemented to suppor= t
> this functionality. =A0The document will identify any enhancements
> required to existing protocols as well as describing new protocol(s) f= or
> interoperable multi-streams negotiation that may be required.
>>
>> Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT,= and
> FECframe.
>>
>>
>> Scope
>> The scope includes both systems that provide a fully immersive
> experience, and systems that interwork with them and therefore need to=
> understand the same multiple stream semantics.
>>
>>
>> The focus of this work is on audio and video multiple streams. =A0= Other
> media types may be considered, however development of methodologies fo= r
> them is not within the scope of this work.
>>
>> Interoperation with standards compliant systems is required, such = as
> SIP-based video conferencing systems. =A0However, backwards compatibil= ity
> with existing non-standards compliant telepresence systems is not
> required.
>>
>>
>>
>> The group will produce
>> - Requirements and use cases
>>
>> - Architectural Framework describing the protocols required to be<= br> > implemented to support this functionality and identifying existing
> protocol enhancements and new protocol functionality required
>>
>> - Specification of a new protocol to support telepresence
> multi-streams [if required]
>>
>> Goals and Milestones
>> Nov 2010
>>
>> Use Cases and Requirements to IESG as Informational RFC
>> Nov 2010
>> March 2011
>> Problem Statement to IESG as Informational RFC
>> Architecture to IESG as Informational RFC
>> March 2011
>> Revise Charter [IF new protocol is not required]
>> Nov 2011
>> Submit protocol draft to IESG as Proposed Standard RFC
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ie= tf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
>
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/le= gal/cri/index.html
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/c= ri/index.html



_______________________________________________
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


--00163646d33ec737df048ae0fd70-- From allyn@cisco.com Thu Jul 8 07:24:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5BF63A6ADC for ; Thu, 8 Jul 2010 07:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.948 X-Spam-Level: X-Spam-Status: No, score=-9.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uAiQ4G-7UAh for ; Thu, 8 Jul 2010 07:23:58 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BB96C3A6845 for ; Thu, 8 Jul 2010 07:23:58 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOZ7NUyrR7H+/2dsb2JhbACgK3GmKppnglyCSQSDIFmGcg X-IronPort-AV: E=Sophos;i="4.53,558,1272844800"; d="scan'208,217";a="342150606" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 08 Jul 2010 14:24:02 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o68EO29j000201; Thu, 8 Jul 2010 14:24:02 GMT Received: from xmb-sjc-221.amer.cisco.com ([128.107.191.80]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Jul 2010 07:24:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB1EA9.366849CC" Date: Thu, 8 Jul 2010 07:24:01 -0700 Message-ID: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01D04F23@xmb-sjc-221.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Charter for Telepresence multi-streams - thirdversion Thread-Index: Acseiryr60tGjzjjT8CwGZPLCc3fsgAHi8Fw References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C333D2@xmb-sjc-221.amer.cisco.com> From: "Allyn Romanow (allyn)" To: "Peter Musgrave" , "Cullen Jennings (fluffy)" X-OriginalArrivalTime: 08 Jul 2010 14:24:02.0429 (UTC) FILETIME=[3695E2D0:01CB1EA9] Cc: DISPATCH list , "Botzko, Stephen" Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 14:24:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB1EA9.366849CC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Peter, Thanks for your comments. =20 In answer to your questions - yes, I believe that interop with standard video SIP is in scope. And yes display stream is from a document camera - we can change to be consistent. =20 Allyn ________________________________ From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 Sent: Thursday, July 08, 2010 3:46 AM To: Cullen Jennings (fluffy) Cc: Allyn Romanow (allyn); DISPATCH list; Botzko, Stephen Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion =09 =09 Hi Allyn/Stephen, =09 =09 I read through these. I think they do a good job of establishing scope and raising issues and as a bonus they are very easy to read. =09 =09 Is there a need to talk about interop with standard video SIP gear? If I use a TP suite to call a desktop SIP client or a 1080p video conferencing terminal is there anything about how that should behave that is worth defining under this work or is that viewed as out of scope?=20 =09 =09 As for draft-romanow-dispatch-telepresence-use-cases-00.txt =09 =09 1. (nit) "This draft ..." paragraph has a number of A's sprinkled in (typos?) =09 =09 3. "We describe...display stream" I assume display stream is a stream from a document camera (as distinct from video stream being from a participant camera?). This term does not match the words used in the previous paragraph. =09 =09 Thanks,=20 =09 =09 Peter Musgrave On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings wrote: =09 Theses look great - I hope people on the list take some time to read them. =09 On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote: =09 > Hi Cullen, > > We just put out a problem statement draft - > http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-prob-stat > ement-00. The document is not complete, but we feel it is a solid > beginning. It does address the example you mention. The use case doc > also describes this case in some detail. > http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases > -00 > > > Do you not feel that the problem statement draft can serve as a good > basis for discussion of problems? > > Thanks, > Allyn > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings (fluffy) > Sent: Wednesday, July 07, 2010 9:41 AM > To: DISPATCH list > Subject: Re: [dispatch] Charter for Telepresence multi-streams - > thirdversion > > > I'm wondering if we could get a thread going about what are some of the > specific problems we need to solve then dispatch theses problems to > appropriate WGs. > > For example one problem is when a session involves two video session on > multiple screens how does one signal which stream is displayed on the > right and left screen. > > I think having a list of specific problems would help get this moving > faster. > > Cullen > > > On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote: > >> Folks, >> This makes the change discussed replacing the text in the third > paragraph under the Charter section with the text suggested on the list. >> It also changes title from "... Description of Work" to "...Charter" >> >> There weren't any further changes suggested. >> >> Thanks, >> Allyn >> >> >> >> >> Multi-streams for Telepresence Charter >> >> >> >> Background >> One branch of video conferencing has evolved that is focused on > immersive "being there" experience. Referred to in various ways such as > virtual conferencing, telepresence or media spaces, early systems were > mainly research projects or business systems with limited deployments. > In recent years telepresence systems have seen considerable market > success. Following the model of early systems, the first wave of > commercial systems have been typically located in specially designed > single-purpose rooms with multiple relatively large displays permitting > life size image reproduction, multiple cameras, encoders, decoders and > microphones. These systems have several important characteristics that > are different from more traditional video conferencing systems. >> >> The first difference concerns controlling the visual viewpoint in > order to improve participant nonverbal communication. These systems > preserve essential group meeting characteristics such as eye contact, > group gestures, seating order and spatial audio by carefully > orchestrating the miking and camera angles at each of the sites . This > is distinct from the more traditional approach where the geometric > relationship between media streams is not used to preserve inter-stream > communication aspects such as eye contact and group dynamics. >> >> A second difference is manipulation of the environment to improve > immersion. With telepresence systems, cinematographic aspects of the > local environment reproduction are carefully planned including color, > table shape, seating and lighting so that when combined with large high > quality displays, a strong sense of a "trompe l'oeil" or "being there" > immersive experience is created. Typical video conference systems do > not include these considerations. >> >> As telepresence video systems have become successful in the market, > manufacturers have started exploring delivery of the nonverbal > communication and immersive values of telepresence via smaller, less > expensive and more flexible video conferencing systems for a variety of > venues, such as individual offices, homes and kiosks. These are also > telepresence systems, since the audio and video quality is high enough > to allow clear image reproduction for nonverbal communication, they are > able to send and receive multiple media streams, and large coordinated > multi image displays are available for immersive installations. As the > industry develops, the line between telepresence and video conferencing > may become blurred as nonverbal communication and immersive > installations become broadly available. >> >> Problem >> Although telepresence systems are based on open standards such as RTP, > SIP, H.264, H.323 suite, they cannot easily interoperate with each other > without operator assistance and expensive additional equipment that > translates from one vendor to another. It would be like having to make > sure all parties are on the same equipment (and network) when making a > telephone call. A major factor in the inability of Telepresence systems > to work with each other is that there is no standard description of the > multiple streams that comprise the media flows. >> >> For example, in a multiple screen conference, the video and audio > streams sent from remote participants must be understood by receivers so > that they can be presented in a coherent and life-like manner. This > includes the ability to present the remote participants at their true > size for their apparent distance, while maintaining correct eye contact, > gesticular cues, and simultaneously providing a spatial audio sound > stage consistent with the video presentation. The receiving device that > decides how to display the incoming information needs to understand a > number of variables such as the spatial position of the speaker, the > field of view of the cameras, the camera zoom, which media stream is > related to each of the displays, etc. >> >> Charter >> The Telepresence Multi-Streams work item in DISPATCH is chartered to > define and specify for SIP-based systems the content of media > multi-stream messages and the way these will be transported. >> >> This work will provide a standard for the exchange of media semantic > information that will foster interoperable end stations and conference > bridges. It will specify variables that describe the semantics of the > media streams and the recommended behavior to achieve interoperability. >> >> >> This requires considering current widely deployed use cases, as well > as cases that are expected to be implemented using the protocol > framework produced by this work item. The methodology for describing > the variables must allow extensibility of the variables, since > telepresence is still a young technology and may have use cases that are > not currently considered." >> >> >> The work item will identify use cases, define requirements, and define > a method for describing and transporting information about multiple > media streams, including a specification of variables required to > support the use cases. This work item will consider the reuse of > existing IETF protocols and produce an architecture/protocol framework > document describing the protocols required to be implemented to support > this functionality. The document will identify any enhancements > required to existing protocols as well as describing new protocol(s) for > interoperable multi-streams negotiation that may be required. >> >> Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and > FECframe. >> >> >> Scope >> The scope includes both systems that provide a fully immersive > experience, and systems that interwork with them and therefore need to > understand the same multiple stream semantics. >> >> >> The focus of this work is on audio and video multiple streams. Other > media types may be considered, however development of methodologies for > them is not within the scope of this work. >> >> Interoperation with standards compliant systems is required, such as > SIP-based video conferencing systems. However, backwards compatibility > with existing non-standards compliant telepresence systems is not > required. >> >> >> >> The group will produce >> - Requirements and use cases >> >> - Architectural Framework describing the protocols required to be > implemented to support this functionality and identifying existing > protocol enhancements and new protocol functionality required >> >> - Specification of a new protocol to support telepresence > multi-streams [if required] >> >> Goals and Milestones >> Nov 2010 >> >> Use Cases and Requirements to IESG as Informational RFC >> Nov 2010 >> March 2011 >> Problem Statement to IESG as Informational RFC >> Architecture to IESG as Informational RFC >> March 2011 >> Revise Charter [IF new protocol is not required] >> Nov 2011 >> Submit protocol draft to IESG as Proposed Standard RFC >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch =09 =09 Cullen Jennings For corporate legal information go to: =09 http://www.cisco.com/web/about/doing_business/legal/cri/index.html =09 =09 =09 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =09 ------_=_NextPart_001_01CB1EA9.366849CC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Peter,
Thanks for your comments.
 
In answer to your questions - yes, I believe = that interop=20 with standard video SIP is in scope. And yes display stream is from a = document=20 camera - we can change to be consistent.
 
Allyn

From: Peter Musgrave=20 [mailto:peter.musgrave@magorcorp.com]
Sent: Thursday, July = 08, 2010=20 3:46 AM
To: Cullen Jennings (fluffy)
Cc: Allyn = Romanow=20 (allyn); DISPATCH list; Botzko, Stephen
Subject: Re: = [dispatch]=20 Charter for Telepresence multi-streams - = thirdversion

Hi Allyn/Stephen,


I read through these. I = think they=20 do a good job of establishing scope and raising issues and as a bonus = they are=20 very easy to read.


Is there a need to talk = about=20 interop with standard video SIP gear? If I use a TP suite to call a = desktop=20 SIP client or a 1080p video conferencing terminal is there anything = about how=20 that should behave that is worth defining under this work or is that = viewed as=20 out of scope? 


As for=20 draft-romanow-dispatch-telepresence-use-cases-00.txt


1. (nit)

"This draft = …" paragraph has=20 a number of A's sprinkled in (typos?)


3. "We = describe…display stream" I=20 assume display stream is a stream from a document camera (as distinct = from=20 video stream being from a participant camera?). This term does not = match the=20 words used in the previous paragraph.


Thanks, 


Peter Musgrave



On Thu, Jul 8, 2010 at 2:46 AM, Cullen = Jennings <fluffy@cisco.com>=20 wrote:

Theses=20 look great - I hope people on the list take some time to read = them.

On Jul 7, 2010, at 1:40 PM, Allyn Romanow = (allyn)=20 wrote:

> Hi Cullen,
>
> We just put out a = problem=20 statement draft -
> http://tools.ietf.org/html/draft-romanow-dispatch-telepre= sence-prob-stat
>=20 ement-00. The document is not complete, but we feel it is a = solid
>=20 beginning.  It does address the example you mention. The use = case=20 doc
> also describes this case in some detail.
> http://tools.ietf.org/html/draft-romanow-dispatch-telepre= sence-use-cases
>=20 -00
>
>
> Do you not feel that the problem = statement draft=20 can serve as a good
> basis for discussion of=20 problems?
>
> Thanks,
> = Allyn
>
>
>=20 -----Original Message-----
> From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] = On
> Behalf Of Cullen Jennings (fluffy)
> Sent: = Wednesday, July=20 07, 2010 9:41 AM
> To: DISPATCH list
> Subject: Re: = [dispatch]=20 Charter for Telepresence multi-streams -
>=20 thirdversion
>
>
> I'm wondering if we could get a = thread=20 going about what are some of the
> specific problems we =  need to=20 solve  then dispatch theses problems to
> appropriate=20 WGs.
>
> For example one problem is when a session = involves two=20 video session on
> multiple screens how does one signal which = stream=20 is displayed on the
> right and left screen.
>
> I = think=20 having a list of specific problems would help get this = moving
>=20 faster.
>
> Cullen
>
>
> On Jul 4, = 2010, at=20 10:14 PM, Allyn Romanow (allyn) wrote:
>
>>=20 Folks,
>> This makes the change discussed replacing the = text in the=20 third
> paragraph under the Charter section with the text = suggested on=20 the list.
>> It also changes title from "... Description of = Work"=20 to "...Charter"
>>
>> There weren't any further = changes=20 suggested.
>>
>> Thanks,
>>=20 Allyn
>>
>>
>>
>>
>>=20 Multi-streams for Telepresence=20 Charter
>>
>>
>>
>>=20 Background
>> One branch of video conferencing has evolved = that is=20 focused on
> immersive "being there" experience. =  Referred to in=20 various ways such as
> virtual conferencing, telepresence or = media=20 spaces, early systems were
> mainly research projects or = business=20 systems with limited deployments.
> In recent years = telepresence=20 systems have seen considerable market
> success. =  Following the=20 model of early systems, the first wave of
> commercial systems = have=20 been typically located in specially designed
> single-purpose = rooms=20 with multiple relatively large displays permitting
> life size = image=20 reproduction, multiple cameras, encoders, decoders and
> = microphones.=20  These systems have several important characteristics = that
> are=20 different from more traditional video conferencing=20 systems.
>>
>> The first difference concerns = controlling=20 the visual viewpoint in
> order to improve participant = nonverbal=20 communication. These systems
> preserve essential group = meeting=20 characteristics such as eye contact,
> group gestures, seating = order=20 and spatial audio by carefully
> orchestrating the miking and = camera=20 angles at each of the sites . This
> is distinct from the more = traditional approach where the geometric
> relationship = between media=20 streams is not used to preserve inter-stream
> communication = aspects=20 such as eye contact and group dynamics.
>>
>> A = second=20 difference is manipulation of the environment to improve
> = immersion.=20  With telepresence systems, cinematographic aspects of = the
>=20 local environment reproduction are carefully planned including=20 color,
> table shape, seating and lighting so that when = combined with=20 large high
> quality displays, a strong sense of a "trompe = l'oeil" or=20 "being there"
> immersive experience is created.  Typical = video=20 conference systems do
> not include these=20 considerations.
>>
>> As telepresence video = systems have=20 become successful in the market,
> manufacturers have started=20 exploring delivery of the nonverbal
> communication and = immersive=20 values of telepresence via smaller, less
> expensive and more = flexible=20 video conferencing systems for a variety of
> venues, such as=20 individual offices, homes and kiosks. These are also
> = telepresence=20 systems, since the audio and video quality is high enough
> to = allow=20 clear image reproduction for nonverbal communication, they = are
> able=20 to send and receive multiple media streams, and large = coordinated
>=20 multi image displays are available for immersive installations. =   As=20 the
> industry develops, the line between telepresence and = video=20 conferencing
> may become blurred as nonverbal communication = and=20 immersive
> installations become broadly=20 available.
>>
>> Problem
>> Although = telepresence=20 systems are based on open standards such as RTP,
> SIP, H.264, = H.323=20 suite, they cannot easily interoperate with each other
> = without=20 operator assistance and expensive additional equipment that
>=20 translates from one vendor to another. It would be like having to=20 make
> sure all parties are on the same equipment (and = network) when=20 making a
> telephone call.  A major factor in the = inability of=20 Telepresence systems
> to work with each other is that there = is no=20 standard description of the
> multiple streams that comprise = the media=20 flows.
>>
>> For example, in a multiple screen = conference,=20 the video and audio
> streams sent from remote participants = must be=20 understood by receivers so
> that they can be presented in a = coherent=20 and life-like manner. This
> includes the ability to present = the=20 remote participants at their true
> size for their apparent = distance,=20 while maintaining correct eye contact,
> gesticular cues, and=20 simultaneously providing a spatial audio sound
> stage = consistent with=20 the video presentation.  The receiving device that
> = decides how=20 to display the incoming information needs to understand a
> = number of=20 variables such as the spatial position of the speaker, the
> = field of=20 view of the cameras, the camera zoom, which media stream is
> = related=20 to each of the displays, etc.
>>
>> = Charter
>>=20 The Telepresence Multi-Streams work item in DISPATCH is chartered = to
>=20 define and specify for SIP-based systems the content of = media
>=20 multi-stream messages and the way these will be=20 transported.
>>
>> This work will provide a = standard for=20 the exchange of media semantic
> information that will foster=20 interoperable end stations and conference
> bridges. It will = specify=20  variables that describe the semantics of the
> media = streams and=20 the recommended behavior to achieve=20 interoperability.
>>
>>
>> This requires=20 considering current widely deployed use cases, as well
> as = cases that=20 are expected to be implemented using the protocol
> framework = produced=20 by this work item.  The methodology for describing
> the=20 variables must allow extensibility of the variables, since
>=20 telepresence is still a young technology and may have use cases that = are
> not currently = considered."
>>
>>
>>=20 The work item will identify use cases, define requirements, and=20 define
> a method for describing and transporting information = about=20 multiple
> media streams, including a specification of = variables=20 required to
> support the use cases. This work item will = consider the=20 reuse of
> existing IETF protocols and produce an=20 architecture/protocol framework
> document describing the = protocols=20 required to be implemented to support
> this functionality. =  The=20 document will identify any enhancements
> required to existing = protocols as well as describing new protocol(s) for
> = interoperable=20 multi-streams negotiation that may be = required.
>>
>>=20 Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT,=20 and
> FECframe.
>>
>>
>> = Scope
>>=20 The scope includes both systems that provide a fully = immersive
>=20 experience, and systems that interwork with them and therefore need=20 to
> understand the same multiple stream=20 semantics.
>>
>>
>> The focus of this = work is on=20 audio and video multiple streams.  Other
> media types = may be=20 considered, however development of methodologies for
> them is = not=20 within the scope of this work.
>>
>> = Interoperation with=20 standards compliant systems is required, such as
> SIP-based = video=20 conferencing systems.  However, backwards compatibility
> = with=20 existing non-standards compliant telepresence systems is not
> = required.
>>
>>
>>
>> The group = will=20 produce
>> - Requirements and use = cases
>>
>> -=20 Architectural Framework describing the protocols required to = be
>=20 implemented to support this functionality and identifying = existing
>=20 protocol enhancements and new protocol functionality=20 required
>>
>> - Specification of a new protocol = to=20 support telepresence
> multi-streams [if=20 required]
>>
>> Goals and Milestones
>> = Nov=20 2010
>>
>> Use Cases and Requirements to IESG as=20 Informational RFC
>> Nov 2010
>> March = 2011
>>=20 Problem Statement to IESG as Informational RFC
>> = Architecture to=20 IESG as Informational RFC
>> March 2011
>> Revise = Charter=20 [IF new protocol is not required]
>> Nov 2011
>> = Submit=20 protocol draft to IESG as Proposed Standard = RFC
>>
>>=20 _______________________________________________
>> dispatch = mailing=20 list
>> dispatch@ietf.org
>> = https://www.ietf.org/mailman/listinfo/dispatch
>= ;
>
>=20 Cullen Jennings
> For corporate legal information go = to:
> http://www.cisco.com/web/about/doing_business/legal/cri/i= ndex.html
>
>
>
>=20 _______________________________________________
> dispatch = mailing=20 list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch

Cullen=20 Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/i= ndex.html



____________________________________________= ___
dispatch=20 mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

------_=_NextPart_001_01CB1EA9.366849CC-- From fluffy@cisco.com Thu Jul 8 07:59:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67E613A6ADF for ; Thu, 8 Jul 2010 07:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.307 X-Spam-Level: X-Spam-Status: No, score=-110.307 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaaRZ36wiwZl for ; Thu, 8 Jul 2010 07:59:55 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id AFC743A6A25 for ; Thu, 8 Jul 2010 07:59:55 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,558,1272844800"; d="scan'208";a="556084606" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 08 Jul 2010 15:00:00 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o68Exwx3018159; Thu, 8 Jul 2010 14:59:59 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <32A6C275-C7BC-4562-BE14-ADDC0C4C42C0@americafree.tv> Date: Thu, 8 Jul 2010 08:59:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <84018774-E536-452A-BD49-51CE88C7E1E1@cisco.com> References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com>, <8F5532A2-7017-48B2-897F-6FA6E50EE68A@cisco.com> <32A6C275-C7BC-4562-BE14-ADDC0C4C42C0@americafree.tv> To: Marshall Eubanks X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 14:59:56 -0000 On Jul 8, 2010, at 6:46 AM, Marshall Eubanks wrote: >=20 > On Jul 8, 2010, at 8:26 AM, Christer Holmberg wrote: >=20 >> Hi, >>=20 >> I agree. >>=20 >> The purpose of RFC 5843 >=20 > 5843 ? I think you and Cullen mean rfc 5853, > Requirements from Session Initiation Protocol (SIP) Session Border = Control (SBC) Deployments, > which indeed looks like a useful start here. oops - good catch. Yes I meant 5853 From Stephen.Botzko@polycom.com Thu Jul 8 07:27:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C21D83A6ACA for ; Thu, 8 Jul 2010 07:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fb1z5jQ4siqF for ; Thu, 8 Jul 2010 07:27:20 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by core3.amsl.com (Postfix) with ESMTP id B63E43A6845 for ; Thu, 8 Jul 2010 07:27:20 -0700 (PDT) Received: from crpehubprd02.polycom.com (10.236.0.154) by Crpehubprd01.polycom.com (10.236.0.158) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 8 Jul 2010 07:27:24 -0700 Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by crpehubprd02.polycom.com ([fe80::f130:2d7a:eae7:37f3%11]) with mapi; Thu, 8 Jul 2010 07:27:24 -0700 From: "Botzko, Stephen" To: "'Allyn Romanow (allyn)'" , Peter Musgrave , "Cullen Jennings (fluffy)" Date: Thu, 8 Jul 2010 07:27:24 -0700 Thread-Topic: [dispatch] Charter for Telepresence multi-streams - thirdversion Thread-Index: Acseiryr60tGjzjjT8CwGZPLCc3fsgAHi8FwAAAadKA= Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C333D2@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01D04F23@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01D04F23@xmb-sjc-221.amer.cisco.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_C5D089C86687BC4DBBABE1CC5B3E45FC0AF11D78CRPMBOXPRD01pol_" MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 08 Jul 2010 08:34:25 -0700 Cc: DISPATCH list Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 14:27:26 -0000 --_000_C5D089C86687BC4DBBABE1CC5B3E45FC0AF11D78CRPMBOXPRD01pol_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Though "display stream" can be from a document camera, in general it can al= so be captured from a PC screen or some other source (such as DVD). As All= yn indicates, it is not from a participant camera. Stephen ________________________________ From: Allyn Romanow (allyn) [mailto:allyn@cisco.com] Sent: Thursday, July 08, 2010 10:24 AM To: Peter Musgrave; Cullen Jennings (fluffy) Cc: DISPATCH list; Botzko, Stephen Subject: RE: [dispatch] Charter for Telepresence multi-streams - thirdversi= on Hi Peter, Thanks for your comments. In answer to your questions - yes, I believe that interop with standard vid= eo SIP is in scope. And yes display stream is from a document camera - we c= an change to be consistent. Allyn ________________________________ From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] Sent: Thursday, July 08, 2010 3:46 AM To: Cullen Jennings (fluffy) Cc: Allyn Romanow (allyn); DISPATCH list; Botzko, Stephen Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversi= on Hi Allyn/Stephen, I read through these. I think they do a good job of establishing scope and = raising issues and as a bonus they are very easy to read. Is there a need to talk about interop with standard video SIP gear? If I us= e a TP suite to call a desktop SIP client or a 1080p video conferencing ter= minal is there anything about how that should behave that is worth defining= under this work or is that viewed as out of scope? As for draft-romanow-dispatch-telepresence-use-cases-00.txt 1. (nit) "This draft ..." paragraph has a number of A's sprinkled in (typos?) 3. "We describe...display stream" I assume display stream is a stream from = a document camera (as distinct from video stream being from a participant c= amera?). This term does not match the words used in the previous paragraph. Thanks, Peter Musgrave On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings > wrote: Theses look great - I hope people on the list take some time to read them. On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote: > Hi Cullen, > > We just put out a problem statement draft - > http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-prob-stat > ement-00. The document is not complete, but we feel it is a solid > beginning. It does address the example you mention. The use case doc > also describes this case in some detail. > http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases > -00 > > > Do you not feel that the problem statement draft can serve as a good > basis for discussion of problems? > > Thanks, > Allyn > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto= :dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings (fluffy) > Sent: Wednesday, July 07, 2010 9:41 AM > To: DISPATCH list > Subject: Re: [dispatch] Charter for Telepresence multi-streams - > thirdversion > > > I'm wondering if we could get a thread going about what are some of the > specific problems we need to solve then dispatch theses problems to > appropriate WGs. > > For example one problem is when a session involves two video session on > multiple screens how does one signal which stream is displayed on the > right and left screen. > > I think having a list of specific problems would help get this moving > faster. > > Cullen > > > On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote: > >> Folks, >> This makes the change discussed replacing the text in the third > paragraph under the Charter section with the text suggested on the list. >> It also changes title from "... Description of Work" to "...Charter" >> >> There weren't any further changes suggested. >> >> Thanks, >> Allyn >> >> >> >> >> Multi-streams for Telepresence Charter >> >> >> >> Background >> One branch of video conferencing has evolved that is focused on > immersive "being there" experience. Referred to in various ways such as > virtual conferencing, telepresence or media spaces, early systems were > mainly research projects or business systems with limited deployments. > In recent years telepresence systems have seen considerable market > success. Following the model of early systems, the first wave of > commercial systems have been typically located in specially designed > single-purpose rooms with multiple relatively large displays permitting > life size image reproduction, multiple cameras, encoders, decoders and > microphones. These systems have several important characteristics that > are different from more traditional video conferencing systems. >> >> The first difference concerns controlling the visual viewpoint in > order to improve participant nonverbal communication. These systems > preserve essential group meeting characteristics such as eye contact, > group gestures, seating order and spatial audio by carefully > orchestrating the miking and camera angles at each of the sites . This > is distinct from the more traditional approach where the geometric > relationship between media streams is not used to preserve inter-stream > communication aspects such as eye contact and group dynamics. >> >> A second difference is manipulation of the environment to improve > immersion. With telepresence systems, cinematographic aspects of the > local environment reproduction are carefully planned including color, > table shape, seating and lighting so that when combined with large high > quality displays, a strong sense of a "trompe l'oeil" or "being there" > immersive experience is created. Typical video conference systems do > not include these considerations. >> >> As telepresence video systems have become successful in the market, > manufacturers have started exploring delivery of the nonverbal > communication and immersive values of telepresence via smaller, less > expensive and more flexible video conferencing systems for a variety of > venues, such as individual offices, homes and kiosks. These are also > telepresence systems, since the audio and video quality is high enough > to allow clear image reproduction for nonverbal communication, they are > able to send and receive multiple media streams, and large coordinated > multi image displays are available for immersive installations. As the > industry develops, the line between telepresence and video conferencing > may become blurred as nonverbal communication and immersive > installations become broadly available. >> >> Problem >> Although telepresence systems are based on open standards such as RTP, > SIP, H.264, H.323 suite, they cannot easily interoperate with each other > without operator assistance and expensive additional equipment that > translates from one vendor to another. It would be like having to make > sure all parties are on the same equipment (and network) when making a > telephone call. A major factor in the inability of Telepresence systems > to work with each other is that there is no standard description of the > multiple streams that comprise the media flows. >> >> For example, in a multiple screen conference, the video and audio > streams sent from remote participants must be understood by receivers so > that they can be presented in a coherent and life-like manner. This > includes the ability to present the remote participants at their true > size for their apparent distance, while maintaining correct eye contact, > gesticular cues, and simultaneously providing a spatial audio sound > stage consistent with the video presentation. The receiving device that > decides how to display the incoming information needs to understand a > number of variables such as the spatial position of the speaker, the > field of view of the cameras, the camera zoom, which media stream is > related to each of the displays, etc. >> >> Charter >> The Telepresence Multi-Streams work item in DISPATCH is chartered to > define and specify for SIP-based systems the content of media > multi-stream messages and the way these will be transported. >> >> This work will provide a standard for the exchange of media semantic > information that will foster interoperable end stations and conference > bridges. It will specify variables that describe the semantics of the > media streams and the recommended behavior to achieve interoperability. >> >> >> This requires considering current widely deployed use cases, as well > as cases that are expected to be implemented using the protocol > framework produced by this work item. The methodology for describing > the variables must allow extensibility of the variables, since > telepresence is still a young technology and may have use cases that are > not currently considered." >> >> >> The work item will identify use cases, define requirements, and define > a method for describing and transporting information about multiple > media streams, including a specification of variables required to > support the use cases. This work item will consider the reuse of > existing IETF protocols and produce an architecture/protocol framework > document describing the protocols required to be implemented to support > this functionality. The document will identify any enhancements > required to existing protocols as well as describing new protocol(s) for > interoperable multi-streams negotiation that may be required. >> >> Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, and > FECframe. >> >> >> Scope >> The scope includes both systems that provide a fully immersive > experience, and systems that interwork with them and therefore need to > understand the same multiple stream semantics. >> >> >> The focus of this work is on audio and video multiple streams. Other > media types may be considered, however development of methodologies for > them is not within the scope of this work. >> >> Interoperation with standards compliant systems is required, such as > SIP-based video conferencing systems. However, backwards compatibility > with existing non-standards compliant telepresence systems is not > required. >> >> >> >> The group will produce >> - Requirements and use cases >> >> - Architectural Framework describing the protocols required to be > implemented to support this functionality and identifying existing > protocol enhancements and new protocol functionality required >> >> - Specification of a new protocol to support telepresence > multi-streams [if required] >> >> Goals and Milestones >> Nov 2010 >> >> Use Cases and Requirements to IESG as Informational RFC >> Nov 2010 >> March 2011 >> Problem Statement to IESG as Informational RFC >> Architecture to IESG as Informational RFC >> March 2011 >> Revise Charter [IF new protocol is not required] >> Nov 2011 >> Submit protocol draft to IESG as Proposed Standard RFC >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_C5D089C86687BC4DBBABE1CC5B3E45FC0AF11D78CRPMBOXPRD01pol_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Though “display stream” ca= n be from a document camera, in general it can also be captured from a PC screen or som= e other source (such as DVD).  As Allyn indicates, it is not from a part= icipant camera.

 

Stephen

 

From: Allyn Ro= manow (allyn) [mailto:allyn@cisco.com]
Sent: Thursday, July 08, 201= 0 10:24 AM
To: Peter Musgrave; Cullen Jennings (fluffy)
Cc: DISPATCH list; Botzko, S= tephen
Subject: RE: [dispatch] Char= ter for Telepresence multi-streams - thirdversion

 

Hi Peter,

Thanks for your comments.

 

In answer to your questions - yes, I believe that interop with standard video SIP is in scope. And yes display stream is from a document camera - we can change to be consistent.

 

Allyn

 

From:= = Peter Musgrave [mailto:peter.musgrave@magorcorp.com]
Sent: Thursday, July 08, 201= 0 3:46 AM
To: Cullen Jennings (fluffy)=
Cc: Allyn Romanow (allyn); DISPATCH list; Botzko, Stephen
Subject: Re: [dispatch] Char= ter for Telepresence multi-streams - thirdversion

Hi Allyn/Stephen,<= /span>

 

I read through these. I think= they do a good job of establishing scope and raising issues and as a bonus they = are very easy to read.

 

Is there a need to talk about interop with standard video SIP gear? If I use a TP suite to call a desktop= SIP client or a 1080p video conferencing terminal is there anything about how t= hat should behave that is worth defining under this work or is that viewed as o= ut of scope? 

 

As for draft-romanow-dispatch-telepresence-use-cases-00.txt

&nb= sp;

1. (nit)

"This draft …" paragraph has a number of A's sprinkled in (typos?)

&nb= sp;

3. "We describe…di= splay stream" I assume display stream is a stream from a document camera (as distinct from video stream being from a participant camera?). This term doe= s not match the words used in the previous paragraph.

 

Thanks, 

 

Peter Musgrave

 

 

On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings <fluffy@cisco.com> wrote:=


Theses look great - I hope people on the list take some time to read them.<= o:p>


On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote:

> Hi Cullen,
>
> We just put out a problem statement draft -
> http://tools.ietf.org/html/draft-romanow-dispatch-telepre= sence-prob-stat
> ement-00. The document is not complete, but we feel it is a solid
> beginning.  It does address the example you mention. The use case= doc
> also describes this case in some detail.
> http://tools.ietf.org/html/draft-romanow-dispatch-telepre= sence-use-cases
> -00
>
>
> Do you not feel that the problem statement draft can serve as a good > basis for discussion of problems?
>
> Thanks,
> Allyn
>
>
> -----Original Message-----
> From: dispatch-bounces@ie= tf.org [mailto:dispatch-bounces@ietf.= org] On
> Behalf Of Cullen Jennings (fluffy)
> Sent: Wednesday, July 07, 2010 9:41 AM
> To: DISPATCH list
> Subject: Re: [dispatch] Charter for Telepresence multi-streams -
> thirdversion
>
>
> I'm wondering if we could get a thread going about what are some of th= e
> specific problems we  need to solve  then dispatch theses problems to
> appropriate WGs.
>
> For example one problem is when a session involves two video session o= n
> multiple screens how does one signal which stream is displayed on the<= br> > right and left screen.
>
> I think having a list of specific problems would help get this moving<= br> > faster.
>
> Cullen
>
>
> On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote:
>
>> Folks,
>> This makes the change discussed replacing the text in the third > paragraph under the Charter section with the text suggested on the lis= t.
>> It also changes title from "... Description of Work" to "...Charter"
>>
>> There weren't any further changes suggested.
>>
>> Thanks,
>> Allyn
>>
>>
>>
>>
>> Multi-streams for Telepresence Charter
>>
>>
>>
>> Background
>> One branch of video conferencing has evolved that is focused on > immersive "being there" experience.  Referred to in var= ious ways such as
> virtual conferencing, telepresence or media spaces, early systems were=
> mainly research projects or business systems with limited deployments.=
> In recent years telepresence systems have seen considerable market
> success.  Following the model of early systems, the first wave of=
> commercial systems have been typically located in specially designed > single-purpose rooms with multiple relatively large displays permittin= g
> life size image reproduction, multiple cameras, encoders, decoders and=
> microphones.  These systems have several important characteristic= s that
> are different from more traditional video conferencing systems.
>>
>> The first difference concerns controlling the visual viewpoint in<= br> > order to improve participant nonverbal communication. These systems > preserve essential group meeting characteristics such as eye contact,<= br> > group gestures, seating order and spatial audio by carefully
> orchestrating the miking and camera angles at each of the sites . This=
> is distinct from the more traditional approach where the geometric
> relationship between media streams is not used to preserve inter-strea= m
> communication aspects such as eye contact and group dynamics.
>>
>> A second difference is manipulation of the environment to improve<= br> > immersion.  With telepresence systems, cinematographic aspects of= the
> local environment reproduction are carefully planned including color,<= br> > table shape, seating and lighting so that when combined with large hig= h
> quality displays, a strong sense of a "trompe l'oeil" or "being there"
> immersive experience is created.  Typical video conference system= s do
> not include these considerations.
>>
>> As telepresence video systems have become successful in the market= ,
> manufacturers have started exploring delivery of the nonverbal
> communication and immersive values of telepresence via smaller, less > expensive and more flexible video conferencing systems for a variety o= f
> venues, such as individual offices, homes and kiosks. These are also > telepresence systems, since the audio and video quality is high enough=
> to allow clear image reproduction for nonverbal communication, they ar= e
> able to send and receive multiple media streams, and large coordinated=
> multi image displays are available for immersive installations.  = As the
> industry develops, the line between telepresence and video conferencin= g
> may become blurred as nonverbal communication and immersive
> installations become broadly available.
>>
>> Problem
>> Although telepresence systems are based on open standards such as = RTP,
> SIP, H.264, H.323 suite, they cannot easily interoperate with each oth= er
> without operator assistance and expensive additional equipment that > translates from one vendor to another. It would be like having to make=
> sure all parties are on the same equipment (and network) when making a=
> telephone call.  A major factor in the inability of Telepresence systems
> to work with each other is that there is no standard description of th= e
> multiple streams that comprise the media flows.
>>
>> For example, in a multiple screen conference, the video and audio<= br> > streams sent from remote participants must be understood by receivers = so
> that they can be presented in a coherent and life-like manner. This > includes the ability to present the remote participants at their true<= br> > size for their apparent distance, while maintaining correct eye contac= t,
> gesticular cues, and simultaneously providing a spatial audio sound > stage consistent with the video presentation.  The receiving devi= ce that
> decides how to display the incoming information needs to understand a<= br> > number of variables such as the spatial position of the speaker, the > field of view of the cameras, the camera zoom, which media stream is > related to each of the displays, etc.
>>
>> Charter
>> The Telepresence Multi-Streams work item in DISPATCH is chartered = to
> define and specify for SIP-based systems the content of media
> multi-stream messages and the way these will be transported.
>>
>> This work will provide a standard for the exchange of media semant= ic
> information that will foster interoperable end stations and conference=
> bridges. It will specify  variables that describe the semantics o= f the
> media streams and the recommended behavior to achieve interoperability= .
>>
>>
>> This requires considering current widely deployed use cases, as we= ll
> as cases that are expected to be implemented using the protocol
> framework produced by this work item.  The methodology for descri= bing
> the variables must allow extensibility of the variables, since
> telepresence is still a young technology and may have use cases that a= re
> not currently considered."
>>
>>
>> The work item will identify use cases, define requirements, and de= fine
> a method for describing and transporting information about multiple > media streams, including a specification of variables required to
> support the use cases. This work item will consider the reuse of
> existing IETF protocols and produce an architecture/protocol framework=
> document describing the protocols required to be implemented to suppor= t
> this functionality.  The document will identify any enhancements<= br> > required to existing protocols as well as describing new protocol(s) f= or
> interoperable multi-streams negotiation that may be required.
>>
>> Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT,= and
> FECframe.
>>
>>
>> Scope
>> The scope includes both systems that provide a fully immersive
> experience, and systems that interwork with them and therefore need to=
> understand the same multiple stream semantics.
>>
>>
>> The focus of this work is on audio and video multiple streams.  Other
> media types may be considered, however development of methodologies fo= r
> them is not within the scope of this work.
>>
>> Interoperation with standards compliant systems is required, such = as
> SIP-based video conferencing systems.  However, backwards compatibility
> with existing non-standards compliant telepresence systems is not
> required.
>>
>>
>>
>> The group will produce
>> - Requirements and use cases
>>
>> - Architectural Framework describing the protocols required to be<= br> > implemented to support this functionality and identifying existing
> protocol enhancements and new protocol functionality required
>>
>> - Specification of a new protocol to support telepresence
> multi-streams [if required]
>>
>> Goals and Milestones
>> Nov 2010
>>
>> Use Cases and Requirements to IESG as Informational RFC
>> Nov 2010
>> March 2011
>> Problem Statement to IESG as Informational RFC
>> Architecture to IESG as Informational RFC
>> March 2011
>> Revise Charter [IF new protocol is not required]
>> Nov 2011
>> Submit protocol draft to IESG as Proposed Standard RFC
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
>
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/i= ndex.html
>
>
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/i= ndex.html



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

 

--_000_C5D089C86687BC4DBBABE1CC5B3E45FC0AF11D78CRPMBOXPRD01pol_-- From dwing@cisco.com Thu Jul 8 08:42:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4B773A6A5A for ; Thu, 8 Jul 2010 08:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.455 X-Spam-Level: X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guLHDvxBiV4V for ; Thu, 8 Jul 2010 08:42:30 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E877F3A6AF9 for ; Thu, 8 Jul 2010 08:42:30 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAC+ONUyrR7H+/2dsb2JhbACVBYsrcaZWmnCFJQSDeQ X-IronPort-AV: E=Sophos;i="4.53,559,1272844800"; d="scan'208";a="223556452" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 08 Jul 2010 15:42:35 +0000 Received: from dwingWS ([10.21.73.141]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o68FgZk1023161; Thu, 8 Jul 2010 15:42:35 GMT From: "Dan Wing" To: "'Tom Taylor'" References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com> In-Reply-To: Date: Thu, 8 Jul 2010 08:42:34 -0700 Message-ID: <022f01cb1eb4$2f9f59b0$8ede0d10$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsenA6q60yCgh8nSFWo6VMku+G+rwAF5E6A Content-Language: en-us Cc: 'DISPATCH list' Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 15:42:31 -0000 > -----Original Message----- > From: Tom Taylor [mailto:tom111.taylor@bell.net] > Sent: Thursday, July 08, 2010 5:50 AM > To: Dan Wing > Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-03 > has just been submitted. Splendid. I refer to the media latching in that document frequently. Myself, I would be happier if IETF could find it possible to include the acronym-that-must-not-be-spoken (SBC) in SBC-related specifications -- no matter if an SBC working group is formed or not. Calling them 'middleboxes' is too vague to be useful, much like "gateway" is too vague (a gateway to the PSTN? a router?) Call a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC an SBC. -d > Dan Wing wrote: > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > On > >> Behalf Of Peter Musgrave > >> Sent: Thursday, July 01, 2010 12:30 PM > >> To: WORLEY, Dale R (Dale) > >> Cc: DISPATCH list > >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >> > >> I concur. > >> > >> There is some useful background in RFC5853 and perhaps > >> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 > >> > >> And then some things which died on the vine such as: > >> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 > >> and perhaps some others? > > > > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes- > 02 died. > > > > -d > ... From richard@shockey.us Thu Jul 8 08:46:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028233A6B1C for ; Thu, 8 Jul 2010 08:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.518 X-Spam-Level: X-Spam-Status: No, score=-1.518 tagged_above=-999 required=5 tests=[AWL=0.747, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9h-oqrvbkkNI for ; Thu, 8 Jul 2010 08:46:54 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id A125F3A6B19 for ; Thu, 8 Jul 2010 08:46:54 -0700 (PDT) Received: (qmail 8271 invoked by uid 0); 8 Jul 2010 15:46:58 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 8 Jul 2010 15:46:58 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:thread-index:Content-Language:X-Identified-User; b=C7U7HMIcP4x/N42IZPNuuYhKmJOi7Nv0MCCrLEOAI8GPN5PdGTpNLMpX04M/OMFg7Fvd1YDRU/K4XnaClXP6oM3VG2GWqR072UKF7Iz4O5PvLe9hWuuNjyHOJfXXbCFi; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OWtJS-0002zJ-93; Thu, 08 Jul 2010 09:46:58 -0600 From: "Richard Shockey" To: "'Dan Wing'" , "'Paul Kyzivat'" References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> <2a2201cb1e5a$85b5df90$91219eb0$@com> In-Reply-To: <2a2201cb1e5a$85b5df90$91219eb0$@com> Date: Thu, 8 Jul 2010 11:46:55 -0400 Message-ID: <00f401cb1eb4$cbb98230$632c8690$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcscaX8dN4iSVSfAR6+wCu3OeaBQegABPUEwAGgp2uAAKLVBgA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'DISPATCH' , 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 15:46:56 -0000 > > Paul of course I've read them, though the PVP document is uniquely > dense and gave me a headache. Security by ID Obscurity. > > My assertion still stands. In the absence of any linkage in the PVP to > the E164 numbering authorities and or databases any assertion about > verification and validation of a E.164 is in essence self validation. > The charter does NOT state that. My point is the proposed charter is badly > written and implies a trust model that does not exist. I guess your "no-SS7" hat doesn't fit anymore? RS> Well I have to swap it from time to time with my NO PRI hat. I'm still trying to kill it off SS7 if someone will let me put metadata in ENUM databases. :-) That trust model which "does not exist" is exactly the trust model that we all use, daily, whenever we dial the pizza joint across the street, the paint contractor with the spiffy one-page advertisement in the yellow pages, pay FedEx or the postal service to deliver a package, or pay a shipper to send a crate full of Champagne from France to some other country, or call the Sears & Roebuck catalog number give them our credit card and expect them to use a shipper (FedEx/postal service/UPS/DHL) to send us the product. RS> There is a reasonable trust model in the PSTN that relies on several factors ..first the regulatory structure that says "you will route e164 transactions by law if you are a licenced carrier" and access to the root numbering structures and databases which in North America are the LERG and the NPAC GTT etc. You can determine who is the responsible carrier of record for nearly any E.164 number out there. You just have real trouble determining who was issued that number. I agree that trust model is imperfect. But that trust model is what delivers almost all of the commerce and business in the world. To assert that this trust model "does not exist" is a false assertion. RS> You cannot authoritatively determine a binding between a phone number and a consumer (domain) without access to the databases. > You make a phone call if it answers and you hopefully get a caller ID > that > hasn't been spoofed then maybe you are OK and maybe you hope the TTL is > set > to some interval that doesn't cause number hijacking. But gee what > happens when the number is disconnected from the PSTN? Hummmm Similar disconnections (and resales) of telephone numbers happen, today, on the PSTN. I dial a restaurant (now out of business) which has taken over the same physical location (oh my gosh, Identity Thieves!) and paid to acquire the previous restaurant's phone number. Other, non-restaurant businesses do similar things. SBC bought the assets of AT&T including its brand name, doing something similar with the att.com domain itself and, I'm sure, with its 800 services. But the routing data aka the DPC's were updated to reflect those transactions. So, it's not as if querying SS7 would provide some magic sauce to prevent the problem. The problem is different, to be sure, just as IP addresses, domain names, physical (street) addresses, email addresses, telephone numbers, are not all quite exactly "the same". But each is considered an "identity" to a varying degree. > The use of the term validation and or verification here implies > authentication and my assertion is that any authentication of the > responsible domain for a E.164 number outside of the PSTN service > provider > or national numbering authority is not possible under the current > regulatory circumstances. Consequently the charter implies an > ability to develop a solution which we all know is impossible. I disagree. > Solution rewrite the charter to note that fact that this is, in fact, > "best efforts" only, "full disclosure" or "caveat emptor" to be > precise. Once I know someone owned an E.164 and I can, afterwards, do crypto to ensure I know I'm talking to the same entity -- that is *far* more reliable than what occurs, today, on the PSTN. The PSTN where phone numbers are bought and sold willy-nilly. RS> for the 352nd time you don't own E.164 numbers. They are not property by treaty. RS> Well this could go on forever. My point is still that the charter as written implies a service level and trust binding that unrealistic and what is proposed is essentially a "best efforts" service. Ok there is nothing wrong with that. TCP? The underlying DHT technology here has been demonstrated to work in the past but to imply that ViPR is some way cool new new thing I'm going to rely on just because it made a successful PSTN call with a ill determined TTL binding .. please. From fluffy@cisco.com Thu Jul 8 13:34:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBC03A6937 for ; Thu, 8 Jul 2010 13:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.153 X-Spam-Level: X-Spam-Status: No, score=-110.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVoiReY0wwMV for ; Thu, 8 Jul 2010 13:34:12 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id CC99F3A6830 for ; Thu, 8 Jul 2010 13:34:11 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,560,1272844800"; d="scan'208";a="266392325" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-2.cisco.com with ESMTP; 08 Jul 2010 20:34:15 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o68KYEab017520; Thu, 8 Jul 2010 20:34:14 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <022f01cb1eb4$2f9f59b0$8ede0d10$@com> Date: Thu, 8 Jul 2010 14:34:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com> <022f01cb1eb4$2f9f59b0$8ede0d10$@com> To: Dan Wing X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 20:34:15 -0000 Seems reasonable. I think B2BUA is reasonable well defined. Care to put = on your fire proof suit and propose a definition of what an SBC is? On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >> -----Original Message----- >> From: Tom Taylor [mailto:tom111.taylor@bell.net] >> Sent: Thursday, July 08, 2010 5:50 AM >> To: Dan Wing >> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>=20 >> = http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-03 >> has just been submitted. >=20 > Splendid. I refer to the media latching in that document frequently. >=20 > Myself, I would be happier if IETF could find it possible to include > the acronym-that-must-not-be-spoken (SBC) in SBC-related=20 > specifications -- no matter if an SBC working group is formed or=20 > not. Calling them 'middleboxes' is too vague to be useful, much > like "gateway" is too vague (a gateway to the PSTN? a router?) =20 > Call a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an=20 > SBC an SBC. >=20 > -d >=20 >=20 >> Dan Wing wrote: >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >> On >>>> Behalf Of Peter Musgrave >>>> Sent: Thursday, July 01, 2010 12:30 PM >>>> To: WORLEY, Dale R (Dale) >>>> Cc: DISPATCH list >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>=20 >>>> I concur. >>>>=20 >>>> There is some useful background in RFC5853 and perhaps >>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 >>>>=20 >>>> And then some things which died on the vine such as: >>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>> and perhaps some others? >>>=20 >>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes- >> 02 died. >>>=20 >>> -d >> ... >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From pkyzivat@cisco.com Thu Jul 8 13:45:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8975C3A6830 for ; Thu, 8 Jul 2010 13:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0ZiCESOA8It for ; Thu, 8 Jul 2010 13:45:10 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id EF9FD3A67D0 for ; Thu, 8 Jul 2010 13:45:09 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,560,1272844800"; d="scan'208";a="130171791" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 08 Jul 2010 20:45:14 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o68KjE3j017278; Thu, 8 Jul 2010 20:45:14 GMT Message-ID: <4C3638D8.2090106@cisco.com> Date: Thu, 08 Jul 2010 16:45:12 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Cullen Jennings References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com> <022f01cb1eb4$2f9f59b0$8ede0d10$@com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 20:45:11 -0000 Cullen Jennings wrote: > Seems reasonable. I think B2BUA is reasonable well defined. Care to put on your fire proof suit and propose a definition of what an SBC is? "An SBC is a B2BUA that acts in a proxy-like role but that may modify sip messages and associated media in ways that a proxy may not." The above is half serious and half tongue-in-cheek. Thanks, Paul From dwing@cisco.com Thu Jul 8 14:35:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE1AC3A698D for ; Thu, 8 Jul 2010 14:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7ccrpTSSPXq for ; Thu, 8 Jul 2010 14:34:28 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 1EEE73A6984 for ; Thu, 8 Jul 2010 14:31:45 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,560,1272844800"; d="scan'208";a="342269694" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 08 Jul 2010 21:31:24 +0000 Received: from dwingWS ([10.21.73.141]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o68LVOdw014063; Thu, 8 Jul 2010 21:31:24 GMT From: "Dan Wing" To: "'Cullen Jennings'" References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com> <022f01cb1eb4$2f9f59b0$8ede0d10$@com> In-Reply-To: Date: Thu, 8 Jul 2010 14:31:24 -0700 Message-ID: <04ac01cb1ee4$ea7712c0$bf653840$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acse3O5PhGOGTs3hSSWKY1e9QniWigAB9OVw Content-Language: en-us Cc: 'DISPATCH list' Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 21:35:32 -0000 X-List-Received-Date: Thu, 08 Jul 2010 21:35:32 -0000 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Thursday, July 08, 2010 1:34 PM > To: Dan Wing > Cc: DISPATCH list > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > > Seems reasonable. I think B2BUA is reasonable well defined. Care to put > on your fire proof suit and propose a definition of what an SBC is? SBC: a B2BUA that also terminates and originates media from user agents or media from an adjacent SBC. -d > > On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: > > >> -----Original Message----- > >> From: Tom Taylor [mailto:tom111.taylor@bell.net] > >> Sent: Thursday, July 08, 2010 5:50 AM > >> To: Dan Wing > >> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' > >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >> > >> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes- > 03 > >> has just been submitted. > > > > Splendid. I refer to the media latching in that document frequently. > > > > Myself, I would be happier if IETF could find it possible to include > > the acronym-that-must-not-be-spoken (SBC) in SBC-related > > specifications -- no matter if an SBC working group is formed or > > not. Calling them 'middleboxes' is too vague to be useful, much > > like "gateway" is too vague (a gateway to the PSTN? a router?) > > Call a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an > > SBC an SBC. > > > > -d > > > > > >> Dan Wing wrote: > >>>> -----Original Message----- > >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > >> On > >>>> Behalf Of Peter Musgrave > >>>> Sent: Thursday, July 01, 2010 12:30 PM > >>>> To: WORLEY, Dale R (Dale) > >>>> Cc: DISPATCH list > >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >>>> > >>>> I concur. > >>>> > >>>> There is some useful background in RFC5853 and perhaps > >>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 > >>>> > >>>> And then some things which died on the vine such as: > >>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 > >>>> and perhaps some others? > >>> > >>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- > middleboxes- > >> 02 died. > >>> > >>> -d > >> ... > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > From maltarai@cisco.com Thu Jul 8 15:26:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2AA13A6822 for ; Thu, 8 Jul 2010 15:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNNUwt66Qie0 for ; Thu, 8 Jul 2010 15:26:50 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0AE003A681F for ; Thu, 8 Jul 2010 15:26:49 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABvtNUytJV2a/2dsb2JhbACgM3GnAppohSUEg3mGdg X-IronPort-AV: E=Sophos;i="4.53,561,1272844800"; d="scan'208";a="130223602" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 08 Jul 2010 22:26:54 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o68MQr3V008088 for ; Thu, 8 Jul 2010 22:26:53 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Jul 2010 17:26:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Jul 2010 17:26:52 -0500 Message-ID: <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com> In-Reply-To: <04ac01cb1ee4$ea7712c0$bf653840$@com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: Acse3O5PhGOGTs3hSSWKY1e9QniWigAB9OVwAAHpG2A= References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> From: "Mohammad Al-Taraireh (maltarai)" To: "Dan Wing (dwing)" , "Cullen Jennings (fluffy)" X-OriginalArrivalTime: 08 Jul 2010 22:26:54.0087 (UTC) FILETIME=[AB0A1170:01CB1EEC] Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 22:26:52 -0000 Doesn't the B2BUA term also implies media origination, and termination capabilities ? It seems that the B2BUA term is already overloaded to include SBC.=20 Mo=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Dan Wing (dwing) Sent: Thursday, July 08, 2010 5:31 PM To: Cullen Jennings (fluffy) Cc: 'DISPATCH list' Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Thursday, July 08, 2010 1:34 PM > To: Dan Wing > Cc: DISPATCH list > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >=20 >=20 > Seems reasonable. I think B2BUA is reasonable well defined. Care to=20 > put on your fire proof suit and propose a definition of what an SBC is? SBC: a B2BUA that also terminates and originates media from user=20 agents or media from an adjacent SBC. -d >=20 > On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >=20 > >> -----Original Message----- > >> From: Tom Taylor [mailto:tom111.taylor@bell.net] > >> Sent: Thursday, July 08, 2010 5:50 AM > >> To: Dan Wing > >> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' > >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >> > >> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes > >> - > 03 > >> has just been submitted. > > > > Splendid. I refer to the media latching in that document frequently. > > > > Myself, I would be happier if IETF could find it possible to include > > the acronym-that-must-not-be-spoken (SBC) in SBC-related=20 > > specifications -- no matter if an SBC working group is formed or=20 > > not. Calling them 'middleboxes' is too vague to be useful, much=20 > > like "gateway" is too vague (a gateway to the PSTN? a router?) Call > > a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC an=20 > > SBC. > > > > -d > > > > > >> Dan Wing wrote: > >>>> -----Original Message----- > >>>> From: dispatch-bounces@ietf.org=20 > >>>> [mailto:dispatch-bounces@ietf.org] > >> On > >>>> Behalf Of Peter Musgrave > >>>> Sent: Thursday, July 01, 2010 12:30 PM > >>>> To: WORLEY, Dale R (Dale) > >>>> Cc: DISPATCH list > >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >>>> > >>>> I concur. > >>>> > >>>> There is some useful background in RFC5853 and perhaps=20 > >>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 > >>>> > >>>> And then some things which died on the vine such as: > >>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 > >>>> and perhaps some others? > >>> > >>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- > middleboxes- > >> 02 died. > >>> > >>> -d > >> ... > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Thu Jul 8 17:10:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 052C93A68FB for ; Thu, 8 Jul 2010 17:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.434 X-Spam-Level: X-Spam-Status: No, score=-10.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TZZ8x7MJRDp for ; Thu, 8 Jul 2010 17:10:10 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 47C413A67AF for ; Thu, 8 Jul 2010 17:10:09 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,561,1272844800"; d="scan'208";a="130223976" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 09 Jul 2010 00:10:13 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o690ADYL021263; Fri, 9 Jul 2010 00:10:13 GMT Message-ID: <4C3668F4.1080807@cisco.com> Date: Thu, 08 Jul 2010 20:10:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Mohammad Al-Taraireh (maltarai)" References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com> In-Reply-To: <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 00:10:12 -0000 Mohammad Al-Taraireh (maltarai) wrote: > Doesn't the B2BUA term also implies media origination, and termination > capabilities ? It seems that the B2BUA term is already overloaded to > include SBC. The term "B2BUA" is distinguished by the minimality of its definition and the corresponding broadness of applicability. It neither implies nor forbids media processing. The term SBC, as typically used, is somewhat narrower in scope that B2BUA, but is still incredibly broad. I certainly know of things that consider themselves to be SBCs that (at least sometimes) don't terminate media. And certainly there are B2BUAs that *do* terminate media that you would not want to call an SBC. (E.g. a conference focus and mixer.) Thanks, Paul > Mo > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Dan Wing (dwing) > Sent: Thursday, July 08, 2010 5:31 PM > To: Cullen Jennings (fluffy) > Cc: 'DISPATCH list' > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Thursday, July 08, 2010 1:34 PM >> To: Dan Wing >> Cc: DISPATCH list >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >> >> >> Seems reasonable. I think B2BUA is reasonable well defined. Care to >> put on your fire proof suit and propose a definition of what an SBC > is? > > SBC: a B2BUA that also terminates and originates media from user > agents or media from an adjacent SBC. > > -d > > >> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >> >>>> -----Original Message----- >>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>> Sent: Thursday, July 08, 2010 5:50 AM >>>> To: Dan Wing >>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>> >>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes >>>> - >> 03 >>>> has just been submitted. >>> Splendid. I refer to the media latching in that document > frequently. >>> Myself, I would be happier if IETF could find it possible to include > >>> the acronym-that-must-not-be-spoken (SBC) in SBC-related >>> specifications -- no matter if an SBC working group is formed or >>> not. Calling them 'middleboxes' is too vague to be useful, much >>> like "gateway" is too vague (a gateway to the PSTN? a router?) Call > >>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC an >>> SBC. >>> >>> -d >>> >>> >>>> Dan Wing wrote: >>>>>> -----Original Message----- >>>>>> From: dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] >>>> On >>>>>> Behalf Of Peter Musgrave >>>>>> Sent: Thursday, July 01, 2010 12:30 PM >>>>>> To: WORLEY, Dale R (Dale) >>>>>> Cc: DISPATCH list >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>> >>>>>> I concur. >>>>>> >>>>>> There is some useful background in RFC5853 and perhaps >>>>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 >>>>>> >>>>>> And then some things which died on the vine such as: >>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>>>> and perhaps some others? >>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >> middleboxes- >>>> 02 died. >>>>> -d >>>> ... >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> > > > _______________________________________________ > 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 dwing@cisco.com Thu Jul 8 17:29:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 964363A6990 for ; Thu, 8 Jul 2010 17:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.469 X-Spam-Level: X-Spam-Status: No, score=-10.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9ZlTyon0Xr8 for ; Thu, 8 Jul 2010 17:29:41 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 6E7163A698C for ; Thu, 8 Jul 2010 17:29:41 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,561,1272844800"; d="scan'208";a="229836529" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 09 Jul 2010 00:29:46 +0000 Received: from dwingWS ([10.21.73.141]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o690Tju2024097; Fri, 9 Jul 2010 00:29:45 GMT From: "Dan Wing" To: "'Mohammad Al-Taraireh \(maltarai\)'" , "'Cullen Jennings \(fluffy\)'" References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com> In-Reply-To: <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com> Date: Thu, 8 Jul 2010 17:29:45 -0700 Message-ID: <058301cb1efd$d502a2b0$7f07e810$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acse3O5PhGOGTs3hSSWKY1e9QniWigAB9OVwAAHpG2AABBmoUA== Content-Language: en-us Cc: 'DISPATCH list' Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 00:29:42 -0000 > Doesn't the B2BUA term also implies media origination, and termination > capabilities ? But then we need a new term for a device that does not touch media, but does more than a SIP proxy (SIP proxy as defined by http://tools.ietf.org/html/rfc3261#section-16). http://tools.ietf.org/html/rfc3261#section-6 already defines B2BUA, and does not say it initiates a (media) 'session', nor does it say a SIP UAC or UAS initiates a 'session'. -d > It seems that the B2BUA term is already overloaded to > include SBC. > > Mo > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Dan Wing (dwing) > Sent: Thursday, July 08, 2010 5:31 PM > To: Cullen Jennings (fluffy) > Cc: 'DISPATCH list' > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Thursday, July 08, 2010 1:34 PM > > To: Dan Wing > > Cc: DISPATCH list > > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > > > > > Seems reasonable. I think B2BUA is reasonable well defined. Care to > > put on your fire proof suit and propose a definition of what an SBC > is? > > SBC: a B2BUA that also terminates and originates media from user > agents or media from an adjacent SBC. > > -d > > > > > > On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: > > > > >> -----Original Message----- > > >> From: Tom Taylor [mailto:tom111.taylor@bell.net] > > >> Sent: Thursday, July 08, 2010 5:50 AM > > >> To: Dan Wing > > >> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' > > >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > >> > > >> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- > middleboxes > > >> - > > 03 > > >> has just been submitted. > > > > > > Splendid. I refer to the media latching in that document > frequently. > > > > > > Myself, I would be happier if IETF could find it possible to > include > > > > the acronym-that-must-not-be-spoken (SBC) in SBC-related > > > specifications -- no matter if an SBC working group is formed or > > > not. Calling them 'middleboxes' is too vague to be useful, much > > > like "gateway" is too vague (a gateway to the PSTN? a router?) > Call > > > > a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC an > > > SBC. > > > > > > -d > > > > > > > > >> Dan Wing wrote: > > >>>> -----Original Message----- > > >>>> From: dispatch-bounces@ietf.org > > >>>> [mailto:dispatch-bounces@ietf.org] > > >> On > > >>>> Behalf Of Peter Musgrave > > >>>> Sent: Thursday, July 01, 2010 12:30 PM > > >>>> To: WORLEY, Dale R (Dale) > > >>>> Cc: DISPATCH list > > >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > >>>> > > >>>> I concur. > > >>>> > > >>>> There is some useful background in RFC5853 and perhaps > > >>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru- > 00 > > >>>> > > >>>> And then some things which died on the vine such as: > > >>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 > > >>>> and perhaps some others? > > >>> > > >>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- > > middleboxes- > > >> 02 died. > > >>> > > >>> -d > > >> ... > > > > > > _______________________________________________ > > > dispatch mailing list > > > dispatch@ietf.org > > > https://www.ietf.org/mailman/listinfo/dispatch > > > > > > Cullen Jennings > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From dwing@cisco.com Thu Jul 8 17:32:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEC5C3A698C for ; Thu, 8 Jul 2010 17:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.481 X-Spam-Level: X-Spam-Status: No, score=-10.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eju5KPuHBlA for ; Thu, 8 Jul 2010 17:32:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 41B163A659A for ; Thu, 8 Jul 2010 17:32:24 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,561,1272844800"; d="scan'208";a="342312914" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2010 00:32:28 +0000 Received: from dwingWS ([10.21.73.141]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o690WSjT025754; Fri, 9 Jul 2010 00:32:28 GMT From: "Dan Wing" To: "'Paul Kyzivat'" , "'Mohammad Al-Taraireh \(maltarai\)'" References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com> <4C3668F4.1080807@cisco.com> In-Reply-To: <4C3668F4.1080807@cisco.com> Date: Thu, 8 Jul 2010 17:32:28 -0700 Message-ID: <058401cb1efe$360fe950$a22fbbf0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acse+xuqF/NsUf7oS2SuDDLcptg6mAAAtFUQ Content-Language: en-us Cc: 'DISPATCH list' Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 00:32:28 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, July 08, 2010 5:10 PM > To: Mohammad Al-Taraireh (maltarai) > Cc: Dan Wing (dwing); Cullen Jennings (fluffy); DISPATCH list > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > > > Mohammad Al-Taraireh (maltarai) wrote: > > Doesn't the B2BUA term also implies media origination, and > termination > > capabilities ? It seems that the B2BUA term is already overloaded to > > include SBC. > > The term "B2BUA" is distinguished by the minimality of its definition > and the corresponding broadness of applicability. It neither implies > nor > forbids media processing. > > The term SBC, as typically used, is somewhat narrower in scope that > B2BUA, but is still incredibly broad. I certainly know of things that > consider themselves to be SBCs that (at least sometimes) don't > terminate > media. > > And certainly there are B2BUAs that *do* terminate media that you would > not want to call an SBC. (E.g. a conference focus and mixer.) Putting on my BEHAVE hat, what we did in BEHAVE with problems like this was invent new terms that are not already overloaded by marketing, product feature checklists, and so on. This resulted in some awkward phrases for BEHAVE, such as 'endpoint independent filtering', but it's pretty accurate phrasing that doesn't get everyone wrapped around the axle of terminology. -d > Thanks, > Paul > > > Mo > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Dan Wing (dwing) > > Sent: Thursday, July 08, 2010 5:31 PM > > To: Cullen Jennings (fluffy) > > Cc: 'DISPATCH list' > > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > > >> -----Original Message----- > >> From: Cullen Jennings [mailto:fluffy@cisco.com] > >> Sent: Thursday, July 08, 2010 1:34 PM > >> To: Dan Wing > >> Cc: DISPATCH list > >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >> > >> > >> Seems reasonable. I think B2BUA is reasonable well defined. Care to > >> put on your fire proof suit and propose a definition of what an SBC > > is? > > > > SBC: a B2BUA that also terminates and originates media from user > > agents or media from an adjacent SBC. > > > > -d > > > > > >> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: > >> > >>>> -----Original Message----- > >>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] > >>>> Sent: Thursday, July 08, 2010 5:50 AM > >>>> To: Dan Wing > >>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' > >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >>>> > >>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- > middleboxes > >>>> - > >> 03 > >>>> has just been submitted. > >>> Splendid. I refer to the media latching in that document > > frequently. > >>> Myself, I would be happier if IETF could find it possible to > include > > > >>> the acronym-that-must-not-be-spoken (SBC) in SBC-related > >>> specifications -- no matter if an SBC working group is formed or > >>> not. Calling them 'middleboxes' is too vague to be useful, much > >>> like "gateway" is too vague (a gateway to the PSTN? a router?) > Call > > > >>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC an > >>> SBC. > >>> > >>> -d > >>> > >>> > >>>> Dan Wing wrote: > >>>>>> -----Original Message----- > >>>>>> From: dispatch-bounces@ietf.org > >>>>>> [mailto:dispatch-bounces@ietf.org] > >>>> On > >>>>>> Behalf Of Peter Musgrave > >>>>>> Sent: Thursday, July 01, 2010 12:30 PM > >>>>>> To: WORLEY, Dale R (Dale) > >>>>>> Cc: DISPATCH list > >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >>>>>> > >>>>>> I concur. > >>>>>> > >>>>>> There is some useful background in RFC5853 and perhaps > >>>>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru- > 00 > >>>>>> > >>>>>> And then some things which died on the vine such as: > >>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 > >>>>>> and perhaps some others? > >>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- > >> middleboxes- > >>>> 02 died. > >>>>> -d > >>>> ... > >>> _______________________________________________ > >>> dispatch mailing list > >>> dispatch@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dispatch > >> > >> Cullen Jennings > >> For corporate legal information go to: > >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >> > > > > > > _______________________________________________ > > 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 gao.yang2@zte.com.cn Thu Jul 8 17:42:01 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72B2B3A68F5 for ; Thu, 8 Jul 2010 17:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.192 X-Spam-Level: X-Spam-Status: No, score=-97.192 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6etowD9lnilF for ; Thu, 8 Jul 2010 17:41:59 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 092243A67C2 for ; Thu, 8 Jul 2010 17:41:58 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 55234992332426; Fri, 9 Jul 2010 08:41:21 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 97491.4585513114; Fri, 9 Jul 2010 08:34:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o690fjAU036143; Fri, 9 Jul 2010 08:41:49 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com> To: "Mohammad Al-Taraireh (maltarai)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 9 Jul 2010 08:38:09 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-09 08:41:46, Serialize complete at 2010-07-09 08:41:46 Content-Type: multipart/alternative; boundary="=_alternative 0003C0DB4825775B_=" X-MAIL: mse2.zte.com.cn o690fjAU036143 Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 00:42:01 -0000 This is a multipart message in MIME format. --=_alternative 0003C0DB4825775B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QnkgY2xhc3NpZmljYXRpb24sIEIyQlVBIGJlaGF2aW5nIFNCQyBiZWxvbmdzIHRvIHRoZSBzZXQg b2YgQjJCVUEsIHRoZSANCnJldmVyc2UgaXMgbm90IHRydWUuDQoNClNvLCB0ZXJtIG9mIEIyQlVB IGl0c2VsZiB3b3VsZCBub3QgaGF2ZSB0byBoYXZlIG1lZGlhIG9yaWdpbmF0aW9uLCBhbmQgDQp0 ZXJtaW5hdGlvbiBjYXBhYmlsaXRpZXMuDQoNClRoYW5rcywNCg0KR2FvIA0KDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3 MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRl LmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNCiJNb2hh bW1hZCBBbC1UYXJhaXJlaCAobWFsdGFyYWkpIiA8bWFsdGFyYWlAY2lzY28uY29tPiANCreivP7I yzogIGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTAtMDctMDkgMDY6MjYNCg0KytW8/sjL DQoiRGFuIFdpbmcgKGR3aW5nKSIgPGR3aW5nQGNpc2NvLmNvbT4sICJDdWxsZW4gSmVubmluZ3Mg KGZsdWZmeSkiIA0KPGZsdWZmeUBjaXNjby5jb20+DQqzrcvNDQpESVNQQVRDSCBsaXN0IDxkaXNw YXRjaEBpZXRmLm9yZz4NCtb3zOINClJlOiBbZGlzcGF0Y2hdIFNob3VsZCBJRVRGIGhhdmUgYSBC RUhBVkUgV0cgZm9yIFNCQ3M/DQoNCg0KDQoNCg0KDQoNCkRvZXNuJ3QgdGhlIEIyQlVBIHRlcm0g YWxzbyBpbXBsaWVzIG1lZGlhIG9yaWdpbmF0aW9uLCBhbmQgdGVybWluYXRpb24NCmNhcGFiaWxp dGllcyA/IEl0IHNlZW1zIHRoYXQgdGhlIEIyQlVBIHRlcm0gaXMgYWxyZWFkeSBvdmVybG9hZGVk IHRvDQppbmNsdWRlIFNCQy4gDQoNCk1vIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNA aWV0Zi5vcmddIE9uDQpCZWhhbGYgT2YgRGFuIFdpbmcgKGR3aW5nKQ0KU2VudDogVGh1cnNkYXks IEp1bHkgMDgsIDIwMTAgNTozMSBQTQ0KVG86IEN1bGxlbiBKZW5uaW5ncyAoZmx1ZmZ5KQ0KQ2M6 ICdESVNQQVRDSCBsaXN0Jw0KU3ViamVjdDogUmU6IFtkaXNwYXRjaF0gU2hvdWxkIElFVEYgaGF2 ZSBhIEJFSEFWRSBXRyBmb3IgU0JDcz8NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBDdWxsZW4gSmVubmluZ3MgW21haWx0bzpmbHVmZnlAY2lzY28uY29tXQ0KPiBTZW50 OiBUaHVyc2RheSwgSnVseSAwOCwgMjAxMCAxOjM0IFBNDQo+IFRvOiBEYW4gV2luZw0KPiBDYzog RElTUEFUQ0ggbGlzdA0KPiBTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBTaG91bGQgSUVURiBoYXZl IGEgQkVIQVZFIFdHIGZvciBTQkNzPw0KPiANCj4gDQo+IFNlZW1zIHJlYXNvbmFibGUuIEkgdGhp bmsgQjJCVUEgaXMgcmVhc29uYWJsZSB3ZWxsIGRlZmluZWQuIENhcmUgdG8gDQo+IHB1dCBvbiB5 b3VyIGZpcmUgcHJvb2Ygc3VpdCBhbmQgcHJvcG9zZSBhIGRlZmluaXRpb24gb2Ygd2hhdCBhbiBT QkMNCmlzPw0KDQogIFNCQzogIGEgQjJCVUEgdGhhdCBhbHNvIHRlcm1pbmF0ZXMgYW5kIG9yaWdp bmF0ZXMgbWVkaWEgZnJvbSB1c2VyIA0KICAgICAgICBhZ2VudHMgb3IgbWVkaWEgZnJvbSBhbiBh ZGphY2VudCBTQkMuDQoNCi1kDQoNCg0KPiANCj4gT24gSnVsIDgsIDIwMTAsIGF0IDk6NDIgQU0s IERhbiBXaW5nIHdyb3RlOg0KPiANCj4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g Pj4gRnJvbTogVG9tIFRheWxvciBbbWFpbHRvOnRvbTExMS50YXlsb3JAYmVsbC5uZXRdDQo+ID4+ IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDA4LCAyMDEwIDU6NTAgQU0NCj4gPj4gVG86IERhbiBXaW5n DQo+ID4+IENjOiAnUGV0ZXIgTXVzZ3JhdmUnOyAnV09STEVZLCBEYWxlIFIgKERhbGUpJzsgJ0RJ U1BBVENIIGxpc3QnDQo+ID4+IFN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIFNob3VsZCBJRVRGIGhh dmUgYSBCRUhBVkUgV0cgZm9yIFNCQ3M/DQo+ID4+DQo+ID4+IGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtbW11c2ljLW1lZGlhLXBhdGgtbWlkZGxlYm94ZXMNCj4gPj4gLQ0K PiAwMw0KPiA+PiBoYXMganVzdCBiZWVuIHN1Ym1pdHRlZC4NCj4gPg0KPiA+IFNwbGVuZGlkLiAg SSByZWZlciB0byB0aGUgbWVkaWEgbGF0Y2hpbmcgaW4gdGhhdCBkb2N1bWVudA0KZnJlcXVlbnRs eS4NCj4gPg0KPiA+IE15c2VsZiwgSSB3b3VsZCBiZSBoYXBwaWVyIGlmIElFVEYgY291bGQgZmlu ZCBpdCBwb3NzaWJsZSB0byBpbmNsdWRlDQoNCj4gPiB0aGUgYWNyb255bS10aGF0LW11c3Qtbm90 LWJlLXNwb2tlbiAoU0JDKSBpbiBTQkMtcmVsYXRlZCANCj4gPiBzcGVjaWZpY2F0aW9ucyAtLSBu byBtYXR0ZXIgaWYgYW4gU0JDIHdvcmtpbmcgZ3JvdXAgaXMgZm9ybWVkIG9yIA0KPiA+IG5vdC4g IENhbGxpbmcgdGhlbSAnbWlkZGxlYm94ZXMnIGlzIHRvbyB2YWd1ZSB0byBiZSB1c2VmdWwsIG11 Y2ggDQo+ID4gbGlrZSAiZ2F0ZXdheSIgaXMgdG9vIHZhZ3VlIChhIGdhdGV3YXkgdG8gdGhlIFBT VE4/ICBhIHJvdXRlcj8pIENhbGwNCg0KPiA+IGEgTkFUIGEgTkFULCBhIGZpcmV3YWxsIGEgZmly ZXdhbGwsIGEgQjJCVUEgYSBCMkJVQSwgYW5kIGFuIFNCQyBhbiANCj4gPiBTQkMuDQo+ID4NCj4g PiAtZA0KPiA+DQo+ID4NCj4gPj4gRGFuIFdpbmcgd3JvdGU6DQo+ID4+Pj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gPj4+PiBGcm9tOiBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIA0K PiA+Pj4+IFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10NCj4gPj4gT24NCj4gPj4+ PiBCZWhhbGYgT2YgUGV0ZXIgTXVzZ3JhdmUNCj4gPj4+PiBTZW50OiBUaHVyc2RheSwgSnVseSAw MSwgMjAxMCAxMjozMCBQTQ0KPiA+Pj4+IFRvOiBXT1JMRVksIERhbGUgUiAoRGFsZSkNCj4gPj4+ PiBDYzogRElTUEFUQ0ggbGlzdA0KPiA+Pj4+IFN1YmplY3Q6IFJlOiBbZGlzcGF0Y2hdIFNob3Vs ZCBJRVRGIGhhdmUgYSBCRUhBVkUgV0cgZm9yIFNCQ3M/DQo+ID4+Pj4NCj4gPj4+PiBJIGNvbmN1 ci4NCj4gPj4+Pg0KPiA+Pj4+IFRoZXJlIGlzIHNvbWUgdXNlZnVsIGJhY2tncm91bmQgaW4gUkZD NTg1MyBhbmQgcGVyaGFwcyANCj4gPj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC13b3JsZXktc2lwY29yZS1iMmJ1YS1wYXNzdGhydS0wMA0KPiA+Pj4+DQo+ID4+Pj4gQW5kIHRo ZW4gc29tZSB0aGluZ3Mgd2hpY2ggZGllZCBvbiB0aGUgdmluZSBzdWNoIGFzOg0KPiA+Pj4+IGh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1hcmpvdS1zaXBwaW5nLWIyYnVhLTAxDQo+ ID4+Pj4gYW5kIHBlcmhhcHMgc29tZSBvdGhlcnM/DQo+ID4+Pg0KPiA+Pj4gaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtbWVkaWEtcGF0aC0NCj4gbWlkZGxlYm94 ZXMtDQo+ID4+IDAyIGRpZWQuDQo+ID4+Pg0KPiA+Pj4gLWQNCj4gPj4gLi4uDQo+ID4NCj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IGRpc3Bh dGNoIG1haWxpbmcgbGlzdA0KPiA+IGRpc3BhdGNoQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaA0KPiANCj4gDQo+IEN1bGxlbiBKZW5u aW5ncw0KPiBGb3IgY29ycG9yYXRlIGxlZ2FsIGluZm9ybWF0aW9uIGdvIHRvOg0KPiBodHRwOi8v d3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVnYWwvY3JpL2luZGV4Lmh0 bWwNCj4gDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCmRpc3BhdGNoIG1haWxpbmcgbGlzdA0KZGlzcGF0Y2hAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGlzcGF0Y2gNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCmRpc3Bh dGNoQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3Bh dGNoDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUg c2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRl bnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBz ZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2Yg dGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0 cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBh ZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNl IG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3Nl ZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRo aXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBB bnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0003C0DB4825775B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJ5IGNsYXNzaWZpY2F0aW9uLCBC MkJVQSBiZWhhdmluZyBTQkMNCmJlbG9uZ3MgdG8gdGhlIHNldCBvZiBCMkJVQSwgdGhlIHJldmVy c2UgaXMgbm90IHRydWUuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5TbywgdGVybSBvZiBCMkJVQSBpdHNlbGYgd291bGQgbm90IGhhdmUNCnRvIGhhdmUg PC9mb250Pjx0dD48Zm9udCBzaXplPTI+bWVkaWEgb3JpZ2luYXRpb24sIGFuZCB0ZXJtaW5hdGlv biBjYXBhYmlsaXRpZXMuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPkdhbyA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAm bmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0K IFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcy QHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9u dD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mcXVvdDtN b2hhbW1hZCBBbC1UYXJhaXJlaA0KKG1hbHRhcmFpKSZxdW90OyAmbHQ7bWFsdGFyYWlAY2lzY28u Y29tJmd0OzwvYj4gPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63 orz+yMs6ICZuYnNwO2Rpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC0wNy0wOSAwNjoyNjwvZm9udD4NCjx0ZCB3aWR0 aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtEYW4gV2luZyAo ZHdpbmcpJnF1b3Q7ICZsdDtkd2luZ0BjaXNjby5jb20mZ3Q7LA0KJnF1b3Q7Q3VsbGVuIEplbm5p bmdzIChmbHVmZnkpJnF1b3Q7ICZsdDtmbHVmZnlAY2lzY28uY29tJmd0OzwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+RElTUEFUQ0ggbGlzdCAmbHQ7ZGlzcGF0Y2hAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj5SZTogW2Rpc3BhdGNoXSBTaG91bGQgSUVURiBoYXZlIGEgQkVIQVZFDQpXRyBmb3Ig U0JDcz88L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPjxicj4NCkRvZXNuJ3QgdGhlIEIyQlVBIHRlcm0gYWxzbyBpbXBsaWVzIG1lZGlhIG9y aWdpbmF0aW9uLCBhbmQgdGVybWluYXRpb248YnI+DQpjYXBhYmlsaXRpZXMgPyBJdCBzZWVtcyB0 aGF0IHRoZSBCMkJVQSB0ZXJtIGlzIGFscmVhZHkgb3ZlcmxvYWRlZCB0bzxicj4NCmluY2x1ZGUg U0JDLiA8YnI+DQo8YnI+DQpNbyA8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCkZyb206IGRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpkaXNwYXRjaC1i b3VuY2VzQGlldGYub3JnXSBPbjxicj4NCkJlaGFsZiBPZiBEYW4gV2luZyAoZHdpbmcpPGJyPg0K U2VudDogVGh1cnNkYXksIEp1bHkgMDgsIDIwMTAgNTozMSBQTTxicj4NClRvOiBDdWxsZW4gSmVu bmluZ3MgKGZsdWZmeSk8YnI+DQpDYzogJ0RJU1BBVENIIGxpc3QnPGJyPg0KU3ViamVjdDogUmU6 IFtkaXNwYXRjaF0gU2hvdWxkIElFVEYgaGF2ZSBhIEJFSEFWRSBXRyBmb3IgU0JDcz88YnI+DQo8 YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBDdWxs ZW4gSmVubmluZ3MgW21haWx0bzpmbHVmZnlAY2lzY28uY29tXTxicj4NCiZndDsgU2VudDogVGh1 cnNkYXksIEp1bHkgMDgsIDIwMTAgMTozNCBQTTxicj4NCiZndDsgVG86IERhbiBXaW5nPGJyPg0K Jmd0OyBDYzogRElTUEFUQ0ggbGlzdDxicj4NCiZndDsgU3ViamVjdDogUmU6IFtkaXNwYXRjaF0g U2hvdWxkIElFVEYgaGF2ZSBhIEJFSEFWRSBXRyBmb3IgU0JDcz88YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyBTZWVtcyByZWFzb25hYmxlLiBJIHRoaW5rIEIyQlVBIGlzIHJlYXNvbmFi bGUgd2VsbCBkZWZpbmVkLiBDYXJlIHRvDQo8YnI+DQomZ3Q7IHB1dCBvbiB5b3VyIGZpcmUgcHJv b2Ygc3VpdCBhbmQgcHJvcG9zZSBhIGRlZmluaXRpb24gb2Ygd2hhdCBhbiBTQkM8YnI+DQppcz88 YnI+DQo8YnI+DQogJm5ic3A7U0JDOiAmbmJzcDthIEIyQlVBIHRoYXQgYWxzbyB0ZXJtaW5hdGVz IGFuZCBvcmlnaW5hdGVzIG1lZGlhIGZyb20NCnVzZXIgPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO2FnZW50cyBvciBtZWRpYSBmcm9tIGFuIGFkamFjZW50IFNCQy48YnI+DQo8YnI+ DQotZDxicj4NCjxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBKdWwgOCwgMjAxMCwgYXQg OTo0MiBBTSwgRGFuIFdpbmcgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBGcm9tOiBUb20gVGF5 bG9yIFttYWlsdG86dG9tMTExLnRheWxvckBiZWxsLm5ldF08YnI+DQomZ3Q7ICZndDsmZ3Q7IFNl bnQ6IFRodXJzZGF5LCBKdWx5IDA4LCAyMDEwIDU6NTAgQU08YnI+DQomZ3Q7ICZndDsmZ3Q7IFRv OiBEYW4gV2luZzxicj4NCiZndDsgJmd0OyZndDsgQ2M6ICdQZXRlciBNdXNncmF2ZSc7ICdXT1JM RVksIERhbGUgUiAoRGFsZSknOyAnRElTUEFUQ0gNCmxpc3QnPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBT dWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBTaG91bGQgSUVURiBoYXZlIGEgQkVIQVZFIFdHIGZvcg0K U0JDcz88YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1tdXNpYy1tZWRpYS1wYXRoLW1pZGRsZWJveGVzPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyAtPGJyPg0KJmd0OyAwMzxicj4NCiZndDsgJmd0OyZndDsgaGFzIGp1 c3QgYmVlbiBzdWJtaXR0ZWQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFNwbGVuZGlk LiAmbmJzcDtJIHJlZmVyIHRvIHRoZSBtZWRpYSBsYXRjaGluZyBpbiB0aGF0IGRvY3VtZW50PGJy Pg0KZnJlcXVlbnRseS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgTXlzZWxmLCBJIHdv dWxkIGJlIGhhcHBpZXIgaWYgSUVURiBjb3VsZCBmaW5kIGl0IHBvc3NpYmxlIHRvDQppbmNsdWRl PGJyPg0KPGJyPg0KJmd0OyAmZ3Q7IHRoZSBhY3JvbnltLXRoYXQtbXVzdC1ub3QtYmUtc3Bva2Vu IChTQkMpIGluIFNCQy1yZWxhdGVkIDxicj4NCiZndDsgJmd0OyBzcGVjaWZpY2F0aW9ucyAtLSBu byBtYXR0ZXIgaWYgYW4gU0JDIHdvcmtpbmcgZ3JvdXAgaXMgZm9ybWVkDQpvciA8YnI+DQomZ3Q7 ICZndDsgbm90LiAmbmJzcDtDYWxsaW5nIHRoZW0gJ21pZGRsZWJveGVzJyBpcyB0b28gdmFndWUg dG8gYmUgdXNlZnVsLA0KbXVjaCA8YnI+DQomZ3Q7ICZndDsgbGlrZSAmcXVvdDtnYXRld2F5JnF1 b3Q7IGlzIHRvbyB2YWd1ZSAoYSBnYXRld2F5IHRvIHRoZSBQU1ROPw0KJm5ic3A7YSByb3V0ZXI/ KSBDYWxsPGJyPg0KPGJyPg0KJmd0OyAmZ3Q7IGEgTkFUIGEgTkFULCBhIGZpcmV3YWxsIGEgZmly ZXdhbGwsIGEgQjJCVUEgYSBCMkJVQSwgYW5kIGFuIFNCQw0KYW4gPGJyPg0KJmd0OyAmZ3Q7IFNC Qy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgLWQ8YnI+DQomZ3Q7ICZndDs8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IERhbiBXaW5nIHdyb3RlOjxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7Jmd0OyBGcm9tOiBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnIDxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jmd0OyBbbWFpbHRvOmRpc3BhdGNoLWJvdW5jZXNAaWV0Zi5vcmddPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyBPbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBCZWhhbGYgT2YgUGV0ZXIg TXVzZ3JhdmU8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgU2VudDogVGh1cnNkYXksIEp1bHkg MDEsIDIwMTAgMTI6MzAgUE08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgVG86IFdPUkxFWSwg RGFsZSBSIChEYWxlKTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBDYzogRElTUEFUQ0ggbGlz dDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW2Rpc3BhdGNoXSBTaG91 bGQgSUVURiBoYXZlIGEgQkVIQVZFDQpXRyBmb3IgU0JDcz88YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgSSBjb25jdXIuPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZXJlIGlzIHNvbWUgdXNl ZnVsIGJhY2tncm91bmQgaW4gUkZDNTg1MyBhbmQgcGVyaGFwcw0KPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdvcmxleS1zaXBjb3Jl LWIyYnVhLXBhc3N0aHJ1LTAwPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsmZ3Q7IEFuZCB0aGVuIHNvbWUgdGhpbmdzIHdoaWNoIGRpZWQgb24gdGhlIHZp bmUgc3VjaA0KYXM6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LW1hcmpvdS1zaXBwaW5nLWIyYnVhLTAxPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsmZ3Q7IGFuZCBwZXJoYXBzIHNvbWUgb3RoZXJzPzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1tbXVzaWMtbWVkaWEtcGF0aC08YnI+DQomZ3Q7IG1pZGRsZWJveGVzLTxicj4NCiZndDsg Jmd0OyZndDsgMDIgZGllZC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7IC1kPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAuLi48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7ICZndDsgZGlzcGF0Y2ggbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmZ3Q7IGRpc3BhdGNo QGlldGYub3JnPGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZGlzcGF0Y2g8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBDdWxsZW4gSmVu bmluZ3M8YnI+DQomZ3Q7IEZvciBjb3Jwb3JhdGUgbGVnYWwgaW5mb3JtYXRpb24gZ28gdG86PGJy Pg0KJmd0OyBodHRwOi8vd3d3LmNpc2NvLmNvbS93ZWIvYWJvdXQvZG9pbmdfYnVzaW5lc3MvbGVn YWwvY3JpL2luZGV4Lmh0bWw8YnI+DQomZ3Q7IDxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KZGlzcGF0Y2ggbWFpbGlu ZyBsaXN0PGJyPg0KZGlzcGF0Y2hAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpkaXNwYXRjaCBtYWlsaW5nIGxpc3Q8YnI+DQpkaXNw YXRjaEBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZGlzcGF0Y2g8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZu YnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7 aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5i c3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2Vu ZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5p Y2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25h bWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50 YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRl ZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5i c3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJz cDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJz cDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtp bnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5i c3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3 aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZu YnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7 ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhw cmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3Nl Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNw O21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3Zp cnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0m bmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0003C0DB4825775B_=-- From tme@americafree.tv Thu Jul 8 18:44:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E623A6B38 for ; Thu, 8 Jul 2010 18:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.388 X-Spam-Level: X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L09107GYaC-2 for ; Thu, 8 Jul 2010 18:44:18 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id ADE293A6781 for ; Thu, 8 Jul 2010 18:44:17 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id B24AA7DC371E; Thu, 8 Jul 2010 21:44:21 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Paul Kyzivat In-Reply-To: <4C3668F4.1080807@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 8 Jul 2010 21:44:21 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com> <4C3668F4.1080807@cisco.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 01:44:20 -0000 On Jul 8, 2010, at 8:10 PM, Paul Kyzivat wrote: > > > Mohammad Al-Taraireh (maltarai) wrote: >> Doesn't the B2BUA term also implies media origination, and >> termination >> capabilities ? It seems that the B2BUA term is already overloaded to >> include SBC. > > The term "B2BUA" is distinguished by the minimality of its > definition and the corresponding broadness of applicability. It > neither implies nor forbids media processing. > > The term SBC, as typically used, is somewhat narrower in scope that > B2BUA, but is still incredibly broad. I certainly know of things > that consider themselves to be SBCs that (at least sometimes) don't > terminate media. > > And certainly there are B2BUAs that *do* terminate media that you > would not want to call an SBC. (E.g. a conference focus and mixer.) As I said, this area is a mess. Maybe the first task is to come up with a new name with a tight description. Marshall > > Thanks, > Paul > >> Mo -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Dan Wing (dwing) >> Sent: Thursday, July 08, 2010 5:31 PM >> To: Cullen Jennings (fluffy) >> Cc: 'DISPATCH list' >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>> -----Original Message----- >>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>> Sent: Thursday, July 08, 2010 1:34 PM >>> To: Dan Wing >>> Cc: DISPATCH list >>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>> >>> >>> Seems reasonable. I think B2BUA is reasonable well defined. Care >>> to put on your fire proof suit and propose a definition of what an >>> SBC >> is? >> SBC: a B2BUA that also terminates and originates media from >> user agents or media from an adjacent SBC. >> -d >>> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >>> >>>>> -----Original Message----- >>>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>>> Sent: Thursday, July 08, 2010 5:50 AM >>>>> To: Dan Wing >>>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' >>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >>>>> middleboxes >>>>> - >>> 03 >>>>> has just been submitted. >>>> Splendid. I refer to the media latching in that document >> frequently. >>>> Myself, I would be happier if IETF could find it possible to >>>> include >>>> the acronym-that-must-not-be-spoken (SBC) in SBC-related >>>> specifications -- no matter if an SBC working group is formed or >>>> not. Calling them 'middleboxes' is too vague to be useful, much >>>> like "gateway" is too vague (a gateway to the PSTN? a router?) >>>> Call >>>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC >>>> an SBC. >>>> >>>> -d >>>> >>>> >>>>> Dan Wing wrote: >>>>>>> -----Original Message----- >>>>>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org >>>>>>> ] >>>>> On >>>>>>> Behalf Of Peter Musgrave >>>>>>> Sent: Thursday, July 01, 2010 12:30 PM >>>>>>> To: WORLEY, Dale R (Dale) >>>>>>> Cc: DISPATCH list >>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>> >>>>>>> I concur. >>>>>>> >>>>>>> There is some useful background in RFC5853 and perhaps http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 >>>>>>> >>>>>>> And then some things which died on the vine such as: >>>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>>>>> and perhaps some others? >>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >>> middleboxes- >>>>> 02 died. >>>>>> -d >>>>> ... >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> >>> Cullen Jennings >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>> >> _______________________________________________ >> 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 fluffy@cisco.com Thu Jul 8 19:59:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 987A93A6782 for ; Thu, 8 Jul 2010 19:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.395 X-Spam-Level: X-Spam-Status: No, score=-110.395 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqsD2p3Kh3+G for ; Thu, 8 Jul 2010 19:59:24 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7085B3A63CB for ; Thu, 8 Jul 2010 19:59:24 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,561,1272844800"; d="scan'208";a="342338911" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2010 02:59:29 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o692xR00013742; Fri, 9 Jul 2010 02:59:28 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4C3668F4.1080807@cisco.com> Date: Thu, 8 Jul 2010 20:59:27 -0600 Content-Transfer-Encoding: 7bit Message-Id: <95B9D028-569E-4638-929A-E802FEC2E209@cisco.com> References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com> <4C3668F4.1080807@cisco.com> To: "Paul Kyzivat (pkyzivat)" , Hadriel Kaplan X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 02:59:25 -0000 I look forward to Hadriel's take on all this. On Jul 8, 2010, at 6:10 PM, Paul Kyzivat (pkyzivat) wrote: > > > Mohammad Al-Taraireh (maltarai) wrote: > > Doesn't the B2BUA term also implies media origination, and termination > > capabilities ? It seems that the B2BUA term is already overloaded to > > include SBC. > > The term "B2BUA" is distinguished by the minimality of its definition > and the corresponding broadness of applicability. It neither implies nor > forbids media processing. > > The term SBC, as typically used, is somewhat narrower in scope that > B2BUA, but is still incredibly broad. I certainly know of things that > consider themselves to be SBCs that (at least sometimes) don't terminate > media. > > And certainly there are B2BUAs that *do* terminate media that you would > not want to call an SBC. (E.g. a conference focus and mixer.) > > Thanks, > Paul > > > Mo > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Dan Wing (dwing) > > Sent: Thursday, July 08, 2010 5:31 PM > > To: Cullen Jennings (fluffy) > > Cc: 'DISPATCH list' > > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > > >> -----Original Message----- > >> From: Cullen Jennings [mailto:fluffy@cisco.com] > >> Sent: Thursday, July 08, 2010 1:34 PM > >> To: Dan Wing > >> Cc: DISPATCH list > >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >> > >> > >> Seems reasonable. I think B2BUA is reasonable well defined. Care to > >> put on your fire proof suit and propose a definition of what an SBC > > is? > > > > SBC: a B2BUA that also terminates and originates media from user > > agents or media from an adjacent SBC. > > > > -d > > > > > >> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: > >> > >>>> -----Original Message----- > >>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] > >>>> Sent: Thursday, July 08, 2010 5:50 AM > >>>> To: Dan Wing > >>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' > >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >>>> > >>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes > >>>> - > >> 03 > >>>> has just been submitted. > >>> Splendid. I refer to the media latching in that document > > frequently. > >>> Myself, I would be happier if IETF could find it possible to include > > > >>> the acronym-that-must-not-be-spoken (SBC) in SBC-related > >>> specifications -- no matter if an SBC working group is formed or > >>> not. Calling them 'middleboxes' is too vague to be useful, much > >>> like "gateway" is too vague (a gateway to the PSTN? a router?) Call > > > >>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC an > >>> SBC. > >>> > >>> -d > >>> > >>> > >>>> Dan Wing wrote: > >>>>>> -----Original Message----- > >>>>>> From: dispatch-bounces@ietf.org > >>>>>> [mailto:dispatch-bounces@ietf.org] > >>>> On > >>>>>> Behalf Of Peter Musgrave > >>>>>> Sent: Thursday, July 01, 2010 12:30 PM > >>>>>> To: WORLEY, Dale R (Dale) > >>>>>> Cc: DISPATCH list > >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >>>>>> > >>>>>> I concur. > >>>>>> > >>>>>> There is some useful background in RFC5853 and perhaps > >>>>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 > >>>>>> > >>>>>> And then some things which died on the vine such as: > >>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 > >>>>>> and perhaps some others? > >>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- > >> middleboxes- > >>>> 02 died. > >>>>> -d > >>>> ... > >>> _______________________________________________ > >>> dispatch mailing list > >>> dispatch@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dispatch > >> > >> Cullen Jennings > >> For corporate legal information go to: > >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >> > > > > > > _______________________________________________ > > 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 > > > Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Thu Jul 8 20:35:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C90A93A6B65; Thu, 8 Jul 2010 20:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.413 X-Spam-Level: X-Spam-Status: No, score=-110.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvyTNnb7EEIk; Thu, 8 Jul 2010 20:35:05 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C72943A688C; Thu, 8 Jul 2010 20:35:05 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIc1NkyrR7Ht/2dsb2JhbACgNnGlHJpVhSUEg3mESQ X-IronPort-AV: E=Sophos;i="4.53,562,1272844800"; d="scan'208";a="223881106" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 09 Jul 2010 03:35:10 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o693Z2Wu019250; Fri, 9 Jul 2010 03:35:03 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Thu, 8 Jul 2010 21:35:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0010F1C2-2436-474D-BC1C-05AFC8A9E4C5@cisco.com> References: <4C28F980.3040702@ericsson.com> To: Alan Johnston X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list , IESG IESG , IETF-Discussion list Subject: Re: [dispatch] WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 03:35:06 -0000 On Jul 3, 2010, at 7:33 AM, Alan Johnston wrote: > Many of us have worked hard on this approach over many years, and you = have been involved in this at every step of the way, in both SIPPING and = DISPATCH. For you to just try to block even the formation of a working = group to address this at this eleventh hour is just not right. For better or worse, the AD's voice do strongly impact others thinking = on the many subjects at IETF. As an individual contributor, my review in = IETF LC pretty much my current thoughts on it. However, if I had sent = that same review when I was an AD this charter would have been very = unlikely to get a fair shake at moving forward so I just would not have = sent that email while I was AD. The ADs often can't express their own = opinions because and instead have to just try and measure community = consensus and go with that even if it does not match what they think is = best. Really this is the first chance I've had to express an opinion on = this where I was not one of the RAI AD.=20 There discussion that has happened since my initial review has made me = wish I had said a bit more about SIP-T in my first email. I'm not really = proposing that someone should have to implement all of ISUP processing = and SIP-T just to pass around the UUI field but from a thought = experiment point of view, this does not sound like it is going to = provide anything that we would not get if we did implement SIP-T to pass = this data. It seems this will have all the limitations of SIP-T combined = with the interoperability limitations of UUI in ISDN. I want to be = clear, I'm not trying to stop us from doing some work that helps = supports uses cases such as the one Laura sent to the list. I just don't = see this charter as leading to any improvement in interoperability. If = we agree that in theory we could more or less do this with SIP-T thought = that is not a practical path from an implementation point of view, then = I can see a path of some middle ground. If we don't agree on that then = we probably need to think about what we need to add to the charter = regardless of if I agree with or not that high lights the additional = part of this problem that makes it so SIP-T can't solve it.=20 The other things that has happened in this discussion is that I was = assuming that the proponents of this felt that proxies needed to modify = the data. =46rom the email that came out it's became clear that not = everyone believed that. If there was consensus on changing this such = that UUI information is not meant for proxies, then I can start to see = ways to rewrite the charter to have it reflect what I think people want = to do. If the consensus is proxies need to look at this, I have a hard = time seeing how it is not involved in call control.=20 From mperumal@cisco.com Thu Jul 8 22:00:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CC33A6B8C for ; Thu, 8 Jul 2010 22:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.557 X-Spam-Level: X-Spam-Status: No, score=-9.557 tagged_above=-999 required=5 tests=[AWL=1.042, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZirgmQ7RNXyO for ; Thu, 8 Jul 2010 22:00:52 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 71FBB3A6B87 for ; Thu, 8 Jul 2010 22:00:52 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGRKNkxAaHte/2dsb2JhbACgNXGlDZpShScEg3eHAA X-IronPort-AV: E=Sophos;i="4.53,562,1272844800"; d="scan'208";a="229856265" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-3.cisco.com with ESMTP; 09 Jul 2010 05:00:49 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o694xrhc015841; Fri, 9 Jul 2010 05:00:48 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Jul 2010 10:30:39 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Jul 2010 10:30:32 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020319A665@XMB-BGL-414.cisco.com> In-Reply-To: <95B9D028-569E-4638-929A-E802FEC2E209@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: AcsfEsUNpzCEMYYPTdqJLPucd4nt3gADUlSg References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com><4C3668F4.1080807@cisco.com> <95B9D028-569E-4638-929A-E802FEC2E209@cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Cullen Jennings (fluffy)" , "Paul Kyzivat (pkyzivat)" , "Hadriel Kaplan" X-OriginalArrivalTime: 09 Jul 2010 05:00:39.0128 (UTC) FILETIME=[ACA93D80:01CB1F23] Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 05:00:53 -0000 If we go by their name and RFC-5853, then SBCs are B2BUAs that are deployed at the border between two networks where network policies are typically enforce. They typically terminate and re-originate both signaling and media and perform the following type of functions: 1. Perimeter defense like access control, topology hiding, denial of service (DoS) detection and prevention. 2. Functionality not available in the endpoints like NAT and firewall traversal, protocol interworking/repair. 3. Traffic management including media monitoring/reporting. 4. Media encryption/decryption at the edge of the network where media is carried unencrypted in the inner network. 5. Enforcing Quality of Service (QoS) like DSCP marking and queueing. The problem that needs to be solved is, how to let them perform these functions that are considered critical for enterprises and service providers, in a more predictable way paying attention to end-to-end communication, feature interoperability and ease of troubleshooting -- Hadriel's "session-id" is one leap in the troubleshooting direction. Muthu=20 |-----Original Message----- |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf |Of Cullen Jennings (fluffy) |Sent: Friday, July 09, 2010 8:29 AM |To: Paul Kyzivat (pkyzivat); Hadriel Kaplan |Cc: DISPATCH list |Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? | | |I look forward to Hadriel's take on all this. | | |On Jul 8, 2010, at 6:10 PM, Paul Kyzivat (pkyzivat) wrote: | |> |> |> Mohammad Al-Taraireh (maltarai) wrote: |> > Doesn't the B2BUA term also implies media origination, and termination |> > capabilities ? It seems that the B2BUA term is already overloaded to |> > include SBC. |> |> The term "B2BUA" is distinguished by the minimality of its definition |> and the corresponding broadness of applicability. It neither implies nor |> forbids media processing. |> |> The term SBC, as typically used, is somewhat narrower in scope that |> B2BUA, but is still incredibly broad. I certainly know of things that |> consider themselves to be SBCs that (at least sometimes) don't terminate |> media. |> |> And certainly there are B2BUAs that *do* terminate media that you would |> not want to call an SBC. (E.g. a conference focus and mixer.) |> |> Thanks, |> Paul |> |> > Mo |> > |> > -----Original Message----- |> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On |> > Behalf Of Dan Wing (dwing) |> > Sent: Thursday, July 08, 2010 5:31 PM |> > To: Cullen Jennings (fluffy) |> > Cc: 'DISPATCH list' |> > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? |> > |> >> -----Original Message----- |> >> From: Cullen Jennings [mailto:fluffy@cisco.com] |> >> Sent: Thursday, July 08, 2010 1:34 PM |> >> To: Dan Wing |> >> Cc: DISPATCH list |> >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? |> >> |> >> |> >> Seems reasonable. I think B2BUA is reasonable well defined. Care to |> >> put on your fire proof suit and propose a definition of what an SBC |> > is? |> > |> > SBC: a B2BUA that also terminates and originates media from user |> > agents or media from an adjacent SBC. |> > |> > -d |> > |> > |> >> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: |> >> |> >>>> -----Original Message----- |> >>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] |> >>>> Sent: Thursday, July 08, 2010 5:50 AM |> >>>> To: Dan Wing |> >>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' |> >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? |> >>>> |> >>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes |> >>>> - |> >> 03 |> >>>> has just been submitted. |> >>> Splendid. I refer to the media latching in that document |> > frequently. |> >>> Myself, I would be happier if IETF could find it possible to include |> > |> >>> the acronym-that-must-not-be-spoken (SBC) in SBC-related |> >>> specifications -- no matter if an SBC working group is formed or |> >>> not. Calling them 'middleboxes' is too vague to be useful, much |> >>> like "gateway" is too vague (a gateway to the PSTN? a router?) Call |> > |> >>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC an |> >>> SBC. |> >>> |> >>> -d |> >>> |> >>> |> >>>> Dan Wing wrote: |> >>>>>> -----Original Message----- |> >>>>>> From: dispatch-bounces@ietf.org |> >>>>>> [mailto:dispatch-bounces@ietf.org] |> >>>> On |> >>>>>> Behalf Of Peter Musgrave |> >>>>>> Sent: Thursday, July 01, 2010 12:30 PM |> >>>>>> To: WORLEY, Dale R (Dale) |> >>>>>> Cc: DISPATCH list |> >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? |> >>>>>> |> >>>>>> I concur. |> >>>>>> |> >>>>>> There is some useful background in RFC5853 and perhaps |> >>>>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 |> >>>>>> |> >>>>>> And then some things which died on the vine such as: |> >>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 |> >>>>>> and perhaps some others? |> >>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- |> >> middleboxes- |> >>>> 02 died. |> >>>>> -d |> >>>> ... |> >>> _______________________________________________ |> >>> dispatch mailing list |> >>> dispatch@ietf.org |> >>> https://www.ietf.org/mailman/listinfo/dispatch |> >> |> >> Cullen Jennings |> >> For corporate legal information go to: |> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html |> >> |> > |> > |> > _______________________________________________ |> > 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 |> > |> | | |Cullen Jennings |For corporate legal information go to: |http://www.cisco.com/web/about/doing_business/legal/cri/index.html | | | |_______________________________________________ |dispatch mailing list |dispatch@ietf.org |https://www.ietf.org/mailman/listinfo/dispatch From john.elwell@siemens-enterprise.com Fri Jul 9 02:09:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA90F3A6B96 for ; Fri, 9 Jul 2010 02:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Co0NVC5aP5pQ for ; Fri, 9 Jul 2010 02:09:10 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 694543A68E9 for ; Fri, 9 Jul 2010 02:09:10 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-803336 for dispatch@ietf.org; Fri, 9 Jul 2010 11:09:13 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id E6AF81EB82AB for ; Fri, 9 Jul 2010 11:09:13 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 9 Jul 2010 11:09:13 +0200 From: "Elwell, John" To: "dispatch@ietf.org" Date: Fri, 9 Jul 2010 11:09:12 +0200 Thread-Topic: I-D Action:draft-jennings-dispatch-npa-00.txt Thread-Index: AcscW1Vp4itLsCnzRKSnrdZzlBc09AC6XItQ Message-ID: References: <20100705160001.9CA5A3A6890@core3.amsl.com> In-Reply-To: <20100705160001.9CA5A3A6890@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] I-D Action:draft-jennings-dispatch-npa-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 09:09:12 -0000 Thanks, Cullen, for producing this draft. I would certainly be interested i= n trying to find a solution that avoids establishing a new registry. Some i= nitial thoughts: 1.1 Simple Single TLD. This would presumably involve reserving PANxxx (wher= e xxx is a digit string of a certain length or range of lengths), and would= be a problem if any such value has already been taken. 2.2 Multiple TLD. This again would be problematic if domain name is already= taken. Also the first digit would be able to identify a maximum of 10 TLDs= , and would not cover all possibly country TLDs, for example. 2.3 Encoded URI. This is attractive, as it could be resolved locally, witho= ut any DNS query. However, it would result in very long digit strings for d= omain names above about 8-10 characters. 2.4 Compressed encoded URI. I would need to see an example - I am not convi= nced it could reduce the problem with 2.3 significantly. John =20 > -----Original Message----- > From: i-d-announce-bounces@ietf.org=20 > [mailto:i-d-announce-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: 05 July 2010 17:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-jennings-dispatch-npa-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. >=20 > Title : Numeric Provider Alias (NPA) > Author(s) : C. Jennings > Filename : draft-jennings-dispatch-npa-00.txt > Pages : 3 > Date : 2010-07-05 >=20 > This draft proposes a modification to > draft-lawrence-dispatch-sipforum-provider-alias (PAN). The PAN draft > proposes a mechanism for a phone to take a short numeric identifier > that identifies a phone service provider and look it up in DNS to > find the address of the configuration server for that service > provider. >=20 > The problem with PAN is that it requires a specific organization, > sipforum.org, to become a registrar for the PAN. This will add > signifiant cost to obtaining them as the expected quantity of PAN is > low. This draft proposes a minor modification to the PAN draft. > Instead of using the sipforum as a new registrar, why not just use > the registrars that already exist for DNS names. This ensure a long > term stable unique allocation of PAN with the advantages of not > having the IETF allocating a monopoly to one particular organization. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jennings-dispatch-npa-00.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > = From john.elwell@siemens-enterprise.com Fri Jul 9 04:07:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1909E3A68AF for ; Fri, 9 Jul 2010 04:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulFhgsuL1WkA for ; Fri, 9 Jul 2010 04:07:26 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 50E013A67ED for ; Fri, 9 Jul 2010 04:07:26 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-804118; Fri, 9 Jul 2010 13:07:30 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 259CC1EB82AE; Fri, 9 Jul 2010 13:07:30 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 9 Jul 2010 13:07:30 +0200 From: "Elwell, John" To: Dan Wing , 'Paul Kyzivat' , "'Mohammad Al-Taraireh (maltarai)'" Date: Fri, 9 Jul 2010 13:07:28 +0200 Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: Acse+xuqF/NsUf7oS2SuDDLcptg6mAAAtFUQABYYbCA= Message-ID: References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com> <4C3668F4.1080807@cisco.com> <058401cb1efe$360fe950$a22fbbf0$@com> In-Reply-To: <058401cb1efe$360fe950$a22fbbf0$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: 'DISPATCH list' Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 11:07:28 -0000 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Dan Wing > Sent: 09 July 2010 01:32 > To: 'Paul Kyzivat'; 'Mohammad Al-Taraireh (maltarai)' > Cc: 'DISPATCH list' > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >=20 >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Thursday, July 08, 2010 5:10 PM > > To: Mohammad Al-Taraireh (maltarai) > > Cc: Dan Wing (dwing); Cullen Jennings (fluffy); DISPATCH list > > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >=20 > >=20 > >=20 > > Mohammad Al-Taraireh (maltarai) wrote: > > > Doesn't the B2BUA term also implies media origination, and > > termination > > > capabilities ? It seems that the B2BUA term is already=20 > overloaded to > > > include SBC. > >=20 > > The term "B2BUA" is distinguished by the minimality of its=20 > definition > > and the corresponding broadness of applicability. It neither implies > > nor > > forbids media processing. > >=20 > > The term SBC, as typically used, is somewhat narrower in scope that > > B2BUA, but is still incredibly broad. I certainly know of=20 > things that > > consider themselves to be SBCs that (at least sometimes) don't > > terminate > > media. > >=20 > > And certainly there are B2BUAs that *do* terminate media=20 > that you would > > not want to call an SBC. (E.g. a conference focus and mixer.) >=20 > Putting on my BEHAVE hat, what we did in BEHAVE with problems=20 > like this > was invent new terms that are not already overloaded by marketing, > product feature checklists, and so on. >=20 > This resulted in some awkward phrases for BEHAVE, such as 'endpoint > independent filtering', but it's pretty accurate phrasing that doesn't > get everyone wrapped around the axle of terminology. [JRE] Yes, for example, B2BUAs can pass contact URIs and dialog identifiers= transparently or map them, and I could imagine terms for these two types o= f behaviour would be useful. As already noted, B2BUAs can handle media or n= ot handle media, and again we might benefit from having a couple of terms. = Perhaps the BEHAVE-like activity should be on B2BUAs in general, rather tha= n SBCs. John >=20 > -d >=20 >=20 > > Thanks, > > Paul > >=20 > > > Mo > > > > > > -----Original Message----- > > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > > > Behalf Of Dan Wing (dwing) > > > Sent: Thursday, July 08, 2010 5:31 PM > > > To: Cullen Jennings (fluffy) > > > Cc: 'DISPATCH list' > > > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > > > > >> -----Original Message----- > > >> From: Cullen Jennings [mailto:fluffy@cisco.com] > > >> Sent: Thursday, July 08, 2010 1:34 PM > > >> To: Dan Wing > > >> Cc: DISPATCH list > > >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > >> > > >> > > >> Seems reasonable. I think B2BUA is reasonable well=20 > defined. Care to > > >> put on your fire proof suit and propose a definition of=20 > what an SBC > > > is? > > > > > > SBC: a B2BUA that also terminates and originates media=20 > from user > > > agents or media from an adjacent SBC. > > > > > > -d > > > > > > > > >> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: > > >> > > >>>> -----Original Message----- > > >>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] > > >>>> Sent: Thursday, July 08, 2010 5:50 AM > > >>>> To: Dan Wing > > >>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' > > >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > >>>> > > >>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- > > middleboxes > > >>>> - > > >> 03 > > >>>> has just been submitted. > > >>> Splendid. I refer to the media latching in that document > > > frequently. > > >>> Myself, I would be happier if IETF could find it possible to > > include > > > > > >>> the acronym-that-must-not-be-spoken (SBC) in SBC-related > > >>> specifications -- no matter if an SBC working group is formed or > > >>> not. Calling them 'middleboxes' is too vague to be useful, much > > >>> like "gateway" is too vague (a gateway to the PSTN? a router?) > > Call > > > > > >>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA,=20 > and an SBC an > > >>> SBC. > > >>> > > >>> -d > > >>> > > >>> > > >>>> Dan Wing wrote: > > >>>>>> -----Original Message----- > > >>>>>> From: dispatch-bounces@ietf.org > > >>>>>> [mailto:dispatch-bounces@ietf.org] > > >>>> On > > >>>>>> Behalf Of Peter Musgrave > > >>>>>> Sent: Thursday, July 01, 2010 12:30 PM > > >>>>>> To: WORLEY, Dale R (Dale) > > >>>>>> Cc: DISPATCH list > > >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG=20 > for SBCs? > > >>>>>> > > >>>>>> I concur. > > >>>>>> > > >>>>>> There is some useful background in RFC5853 and perhaps > > >>>>>>=20 > http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru- > > 00 > > >>>>>> > > >>>>>> And then some things which died on the vine such as: > > >>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 > > >>>>>> and perhaps some others? > > >>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- > > >> middleboxes- > > >>>> 02 died. > > >>>>> -d > > >>>> ... > > >>> _______________________________________________ > > >>> dispatch mailing list > > >>> dispatch@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/dispatch > > >> > > >> Cullen Jennings > > >> For corporate legal information go to: > > >>=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > >> > > > > > > > > > _______________________________________________ > > > 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From john.elwell@siemens-enterprise.com Fri Jul 9 05:46:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 259023A69BF for ; Fri, 9 Jul 2010 05:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1wbDl2DHMjx for ; Fri, 9 Jul 2010 05:46:24 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id BE5873A6A40 for ; Fri, 9 Jul 2010 05:46:23 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-805571; Fri, 9 Jul 2010 14:46:27 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 6F58F23F0278; Fri, 9 Jul 2010 14:46:27 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 9 Jul 2010 14:46:27 +0200 From: "Elwell, John" To: "Allyn Romanow (allyn)" , Peter Musgrave , "Cullen Jennings (fluffy)" Date: Fri, 9 Jul 2010 14:46:25 +0200 Thread-Topic: [dispatch] Charter for Telepresence multi-streams - thirdversion Thread-Index: Acseiryr60tGjzjjT8CwGZPLCc3fsgAHi8FwAC7kShA= Message-ID: References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com><9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C333D2@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01D04F23@xmb-sjc-221.amer.cisco.com> In-Reply-To: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01D04F23@xmb-sjc-221.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH list , "Botzko, Stephen" Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 12:46:26 -0000 I agree it is important to make any enhancements to SIP/SDP backwards compa= tible with existing SIP/SDP in a way that can achieve meaningful interop wi= th standard video using SIP. This must be within scope. John =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Allyn Romanow (allyn) > Sent: 08 July 2010 15:24 > To: Peter Musgrave; Cullen Jennings (fluffy) > Cc: DISPATCH list; Botzko, Stephen > Subject: Re: [dispatch] Charter for Telepresence=20 > multi-streams - thirdversion >=20 > Hi Peter, > Thanks for your comments. > =20 > In answer to your questions - yes, I believe that interop=20 > with standard video SIP is in scope. And yes display stream=20 > is from a document camera - we can change to be consistent. > =20 > Allyn >=20 >=20 > ________________________________ >=20 > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 > Sent: Thursday, July 08, 2010 3:46 AM > To: Cullen Jennings (fluffy) > Cc: Allyn Romanow (allyn); DISPATCH list; Botzko, Stephen > Subject: Re: [dispatch] Charter for Telepresence=20 > multi-streams - thirdversion > =09 > =09 >=20 > Hi Allyn/Stephen, >=20 > =09 > =09 >=20 > I read through these. I think they do a good job of=20 > establishing scope and raising issues and as a bonus they are=20 > very easy to read. >=20 > =09 > =09 >=20 > Is there a need to talk about interop with standard=20 > video SIP gear? If I use a TP suite to call a desktop SIP=20 > client or a 1080p video conferencing terminal is there=20 > anything about how that should behave that is worth defining=20 > under this work or is that viewed as out of scope?=20 >=20 > =09 > =09 >=20 > As for draft-romanow-dispatch-telepresence-use-cases-00.txt >=20 > =09 > =09 >=20 > 1. (nit) >=20 > "This draft ..." paragraph has a number of A's sprinkled=20 > in (typos?) >=20 > =09 > =09 >=20 > 3. "We describe...display stream" I assume display stream=20 > is a stream from a document camera (as distinct from video=20 > stream being from a participant camera?). This term does not=20 > match the words used in the previous paragraph. >=20 > =09 > =09 >=20 > Thanks,=20 >=20 > =09 > =09 >=20 > Peter Musgrave >=20 >=20 >=20 > On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings=20 > wrote: > =09 >=20 >=20 > Theses look great - I hope people on the list=20 > take some time to read them. > =09 >=20 > On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote: > =09 > > Hi Cullen, > > > > We just put out a problem statement draft - > >=20 > http://tools.ietf.org/html/draft-romanow-dispatch-telepresence > -prob-stat > > ement-00. The document is not complete, but=20 > we feel it is a solid > > beginning. It does address the example you=20 > mention. The use case doc > > also describes this case in some detail. > >=20 > http://tools.ietf.org/html/draft-romanow-dispatch-telepresence > -use-cases > > -00 > > > > > > Do you not feel that the problem statement=20 > draft can serve as a good > > basis for discussion of problems? > > > > Thanks, > > Allyn > > > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Cullen Jennings (fluffy) > > Sent: Wednesday, July 07, 2010 9:41 AM > > To: DISPATCH list > > Subject: Re: [dispatch] Charter for=20 > Telepresence multi-streams - > > thirdversion > > > > > > I'm wondering if we could get a thread going=20 > about what are some of the > > specific problems we need to solve then=20 > dispatch theses problems to > > appropriate WGs. > > > > For example one problem is when a session=20 > involves two video session on > > multiple screens how does one signal which=20 > stream is displayed on the > > right and left screen. > > > > I think having a list of specific problems=20 > would help get this moving > > faster. > > > > Cullen > > > > > > On Jul 4, 2010, at 10:14 PM, Allyn Romanow=20 > (allyn) wrote: > > > >> Folks, > >> This makes the change discussed replacing=20 > the text in the third > > paragraph under the Charter section with the=20 > text suggested on the list. > >> It also changes title from "... Description=20 > of Work" to "...Charter" > >> > >> There weren't any further changes suggested. > >> > >> Thanks, > >> Allyn > >> > >> > >> > >> > >> Multi-streams for Telepresence Charter > >> > >> > >> > >> Background > >> One branch of video conferencing has evolved=20 > that is focused on > > immersive "being there" experience. Referred=20 > to in various ways such as > > virtual conferencing, telepresence or media=20 > spaces, early systems were > > mainly research projects or business systems=20 > with limited deployments. > > In recent years telepresence systems have=20 > seen considerable market > > success. Following the model of early=20 > systems, the first wave of > > commercial systems have been typically=20 > located in specially designed > > single-purpose rooms with multiple relatively=20 > large displays permitting > > life size image reproduction, multiple=20 > cameras, encoders, decoders and > > microphones. These systems have several=20 > important characteristics that > > are different from more traditional video=20 > conferencing systems. > >> > >> The first difference concerns controlling=20 > the visual viewpoint in > > order to improve participant nonverbal=20 > communication. These systems > > preserve essential group meeting=20 > characteristics such as eye contact, > > group gestures, seating order and spatial=20 > audio by carefully > > orchestrating the miking and camera angles at=20 > each of the sites . This > > is distinct from the more traditional=20 > approach where the geometric > > relationship between media streams is not=20 > used to preserve inter-stream > > communication aspects such as eye contact and=20 > group dynamics. > >> > >> A second difference is manipulation of the=20 > environment to improve > > immersion. With telepresence systems,=20 > cinematographic aspects of the > > local environment reproduction are carefully=20 > planned including color, > > table shape, seating and lighting so that=20 > when combined with large high > > quality displays, a strong sense of a "trompe=20 > l'oeil" or "being there" > > immersive experience is created. Typical=20 > video conference systems do > > not include these considerations. > >> > >> As telepresence video systems have become=20 > successful in the market, > > manufacturers have started exploring delivery=20 > of the nonverbal > > communication and immersive values of=20 > telepresence via smaller, less > > expensive and more flexible video=20 > conferencing systems for a variety of > > venues, such as individual offices, homes and=20 > kiosks. These are also > > telepresence systems, since the audio and=20 > video quality is high enough > > to allow clear image reproduction for=20 > nonverbal communication, they are > > able to send and receive multiple media=20 > streams, and large coordinated > > multi image displays are available for=20 > immersive installations. As the > > industry develops, the line between=20 > telepresence and video conferencing > > may become blurred as nonverbal communication=20 > and immersive > > installations become broadly available. > >> > >> Problem > >> Although telepresence systems are based on=20 > open standards such as RTP, > > SIP, H.264, H.323 suite, they cannot easily=20 > interoperate with each other > > without operator assistance and expensive=20 > additional equipment that > > translates from one vendor to another. It=20 > would be like having to make > > sure all parties are on the same equipment=20 > (and network) when making a > > telephone call. A major factor in the=20 > inability of Telepresence systems > > to work with each other is that there is no=20 > standard description of the > > multiple streams that comprise the media flows. > >> > >> For example, in a multiple screen=20 > conference, the video and audio > > streams sent from remote participants must be=20 > understood by receivers so > > that they can be presented in a coherent and=20 > life-like manner. This > > includes the ability to present the remote=20 > participants at their true > > size for their apparent distance, while=20 > maintaining correct eye contact, > > gesticular cues, and simultaneously providing=20 > a spatial audio sound > > stage consistent with the video presentation.=20 > The receiving device that > > decides how to display the incoming=20 > information needs to understand a > > number of variables such as the spatial=20 > position of the speaker, the > > field of view of the cameras, the camera=20 > zoom, which media stream is > > related to each of the displays, etc. > >> > >> Charter > >> The Telepresence Multi-Streams work item in=20 > DISPATCH is chartered to > > define and specify for SIP-based systems the=20 > content of media > > multi-stream messages and the way these will=20 > be transported. > >> > >> This work will provide a standard for the=20 > exchange of media semantic > > information that will foster interoperable=20 > end stations and conference > > bridges. It will specify variables that=20 > describe the semantics of the > > media streams and the recommended behavior to=20 > achieve interoperability. > >> > >> > >> This requires considering current widely=20 > deployed use cases, as well > > as cases that are expected to be implemented=20 > using the protocol > > framework produced by this work item. The=20 > methodology for describing > > the variables must allow extensibility of the=20 > variables, since > > telepresence is still a young technology and=20 > may have use cases that are > > not currently considered." > >> > >> > >> The work item will identify use cases,=20 > define requirements, and define > > a method for describing and transporting=20 > information about multiple > > media streams, including a specification of=20 > variables required to > > support the use cases. This work item will=20 > consider the reuse of > > existing IETF protocols and produce an=20 > architecture/protocol framework > > document describing the protocols required to=20 > be implemented to support > > this functionality. The document will=20 > identify any enhancements > > required to existing protocols as well as=20 > describing new protocol(s) for > > interoperable multi-streams negotiation that=20 > may be required. > >> > >> Relevant work to be drawn upon has been done=20 > in XCON, MMUSIC, AVT, and > > FECframe. > >> > >> > >> Scope > >> The scope includes both systems that provide=20 > a fully immersive > > experience, and systems that interwork with=20 > them and therefore need to > > understand the same multiple stream semantics. > >> > >> > >> The focus of this work is on audio and video=20 > multiple streams. Other > > media types may be considered, however=20 > development of methodologies for > > them is not within the scope of this work. > >> > >> Interoperation with standards compliant=20 > systems is required, such as > > SIP-based video conferencing systems. =20 > However, backwards compatibility > > with existing non-standards compliant=20 > telepresence systems is not > > required. > >> > >> > >> > >> The group will produce > >> - Requirements and use cases > >> > >> - Architectural Framework describing the=20 > protocols required to be > > implemented to support this functionality and=20 > identifying existing > > protocol enhancements and new protocol=20 > functionality required > >> > >> - Specification of a new protocol to support=20 > telepresence > > multi-streams [if required] > >> > >> Goals and Milestones > >> Nov 2010 > >> > >> Use Cases and Requirements to IESG as=20 > Informational RFC > >> Nov 2010 > >> March 2011 > >> Problem Statement to IESG as Informational RFC > >> Architecture to IESG as Informational RFC > >> March 2011 > >> Revise Charter [IF new protocol is not required] > >> Nov 2011 > >> Submit protocol draft to IESG as Proposed=20 > Standard RFC > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > > > Cullen Jennings > > For corporate legal information go to: > >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > =09 > =09 > Cullen Jennings > For corporate legal information go to: > =09 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > =09 > =09 > =09 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > =09 >=20 >=20 > = From brett@broadsoft.com Fri Jul 9 05:56:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 477483A6A76 for ; Fri, 9 Jul 2010 05:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7uj7+2axqvI for ; Fri, 9 Jul 2010 05:56:04 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 2F3B23A6A75 for ; Fri, 9 Jul 2010 05:56:04 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Fri, 9 Jul 2010 05:56:09 -0700 From: Brett Tate To: 'DISPATCH list' Date: Fri, 9 Jul 2010 05:54:50 -0700 Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: Acse+xuqF/NsUf7oS2SuDDLcptg6mAAAtFUQABYYbCAAAXeLcA== Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A01DE01F8EE@EXMBXCLUS01.citservers.local> References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com> <4C3668F4.1080807@cisco.com> <058401cb1efe$360fe950$a22fbbf0$@com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 12:56:05 -0000 > Perhaps the BEHAVE-like activity should be=20 > on B2BUAs in general, rather than SBCs. As has been mentioned, there are a variety of B2BUA types. If the activity= is to apply to B2BUAs in general, the activity would need to recognize tha= t the following types of B2BUA (or their services) exist and would remain. = Thus B2BUAs desiring to act mostly like proxies could benefit from the act= ivity; however others because of configuration or otherwise might not be ab= le to fully comply. Some B2BUAs or their services intentionally attempt to restrict/control end= -to-end functionality. Ironically one reason may even be to improve intero= perability. Some B2BUAs or their services (such as discussed within RFC 3323) intention= ally attempt to hide the correlation of the two call halves. There are some B2BUAs (such as conference servers and gateways) that typica= lly may not consider themselves to be B2BUAs even though they are connectin= g the call halves directly or indirectly through using other devices/protoc= ols. From pkyzivat@cisco.com Fri Jul 9 06:18:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3CFE3A6A68 for ; Fri, 9 Jul 2010 06:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.372 X-Spam-Level: X-Spam-Status: No, score=-10.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oJo6toQcp9P for ; Fri, 9 Jul 2010 06:18:35 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E793A3A67E3 for ; Fri, 9 Jul 2010 06:18:34 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAO+9NkxAZnwN/2dsb2JhbACgQnGjVJpjglUQgkIEiEmJaA X-IronPort-AV: E=Sophos;i="4.53,563,1272844800"; d="scan'208";a="130422138" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 09 Jul 2010 13:18:39 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o69DIdfH007199; Fri, 9 Jul 2010 13:18:39 GMT Message-ID: <4C3721A6.8070507@cisco.com> Date: Fri, 09 Jul 2010 09:18:30 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brett Tate References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com> <4C3668F4.1080807@cisco.com> <058401cb1efe$360fe950$a22fbbf0$@com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DE01F8EE@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A01DE01F8EE@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'DISPATCH list' Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 13:18:37 -0000 Perhaps it would be worthwhile to begin creating a taxonomy of the more interesting sorts of B2BUAs. This wouldn't have been possible at the time 3261 was published. But by now there is a lot of experience and it seems there are a number of common forms evolving independently. (Who will be the Linnaeus of B2BUAs?) Then there might be a basis for further standardization of some of those when it seems useful/necessary in order to promote interoperability. Thanks, Paul Brett Tate wrote: >> Perhaps the BEHAVE-like activity should be >> on B2BUAs in general, rather than SBCs. > > As has been mentioned, there are a variety of B2BUA types. If the activity is to apply to B2BUAs in general, the activity would need to recognize that the following types of B2BUA (or their services) exist and would remain. Thus B2BUAs desiring to act mostly like proxies could benefit from the activity; however others because of configuration or otherwise might not be able to fully comply. > > Some B2BUAs or their services intentionally attempt to restrict/control end-to-end functionality. Ironically one reason may even be to improve interoperability. > > Some B2BUAs or their services (such as discussed within RFC 3323) intentionally attempt to hide the correlation of the two call halves. > > There are some B2BUAs (such as conference servers and gateways) that typically may not consider themselves to be B2BUAs even though they are connecting the call halves directly or indirectly through using other devices/protocols. > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From laura.liess.dt@googlemail.com Fri Jul 9 07:39:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7ACEB3A6A9A; Fri, 9 Jul 2010 07:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.862 X-Spam-Level: X-Spam-Status: No, score=-0.862 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcmgLS9qtxsm; Fri, 9 Jul 2010 07:39:04 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id C69273A69BF; Fri, 9 Jul 2010 07:39:02 -0700 (PDT) Received: by wyb40 with SMTP id 40so1694652wyb.31 for ; Fri, 09 Jul 2010 07:39:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=tChIfMGQTP/acsm4Z5YeWHUQU3c3U2cc5WFdUe8nq0g=; b=lC/H/4LFy3jCD7dTlvY7ZBRRErWNMG2G4OvzqkVHP9aWNltKWUWTXaqhCHm5pdQ8F6 591OVdQA5eMPDWsnrJgFrOEHKyacsgrwymmTvKU+j7FnvKFw+CYUOKNmDU3+avp3Tuj9 /e7duRDjuJvQ+NPyvjg4upFRhxXJDck4WkOE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=VVd8NEOMBAtjqHnSGJwRZ9uz87T4e5o3yQg0f9kFjz1OwcGsz2yTv0//gJ1WHtgvdH 5JpLJqkNEY9+XcgYtE9a+RnZDuYAWNpoIbxa73RT2CeiNhcMK6BsiZt9nX1OAKJ/4qZW lpOhkcWkIeIot/AnTcqb+UHs/m7KQX6C6/vgE= MIME-Version: 1.0 Received: by 10.216.167.80 with SMTP id h58mr4190497wel.49.1278686342953; Fri, 09 Jul 2010 07:39:02 -0700 (PDT) Received: by 10.216.139.99 with HTTP; Fri, 9 Jul 2010 07:39:02 -0700 (PDT) In-Reply-To: <2A1051E9-99DC-458C-B96B-0BE7FB4CD4C1@cisco.com> References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> <4C2A2C19.1030906@cisco.com> <4C2AE94C.4020707@ericsson.com> <617DF0128820F9458AC39149A627EE6C01A66BC2A7@MBX.dialogic.com> <4C2B8ACE.3050301@cisco.com> <2A1051E9-99DC-458C-B96B-0BE7FB4CD4C1@cisco.com> Date: Fri, 9 Jul 2010 16:39:02 +0200 Message-ID: From: Laura Liess To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , James Rafferty , Roland Jesske , "ietf@ietf.org" Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 14:39:06 -0000 Cullen, > This example is excellent - thank you for providing it. I think it is pre= tty representative of other examples I have seen and I am in favor of havin= g solutions to use cases such as this - I'm just not seeing why this charte= r is the appropriate way to do it. > > Given we are talking about transferring some information between UA in a = single providers network, Laura: As I wrote in a previous e-mail, we also have enterprise customers which already bought this feature from us for the PSTN. We don't know how they use it, but we need to give them the same feature for SIP. > PS - I doing my best to avoid the debate on if the CSCF are proxies or B2= BUA, I view things that need to understand and even change SIP bodies as B2= BUA but regardless, I think we can both agree that CSCF can and do look at = bodies such as SDP and would work with what I proposed above. Laura: In IMS we have different kinds of CSCFs. In principle, all of them can be either proxy or some kind of B2BUA. In the DT IMS, the CSCF doing SIP-routing and filtering based on user profile, is a proxy. (Other CSCFs, e.g. those at the network border, are B2BUAs, but they can not do the filtering.) Is it so easy to instruct a proxy to inspect the body and eventually throw away a part of it? And should one do that? Thanks Laura 2010/7/7 Cullen Jennings : > > This example is excellent - thank you for providing it. I think it is pre= tty representative of other examples I have seen and I am in favor of havin= g solutions to use cases such as this - I'm just not seeing why this charte= r is the appropriate way to do it. > > Given we are talking about transferring some information between UA in a = single providers network, and this information would likely be stripped by = an SBC at the edge of the network, and that different operators may use the= same code points for different things, this all seems like something that = might just be better carried in one of the existing SIP extensibility mecha= nisms such as media-type out of the vendor tree. > > Cullen > > PS - I doing my best to avoid the debate on if the CSCF are proxies or B2= BUA, I view things that need to understand and even change SIP bodies as B2= BUA but regardless, I think we can both agree that CSCF can and do look at = bodies such as SDP and would work with what I proposed above. > > > On Jul 1, 2010, at 6:53 AM, Laura Liess wrote: > >> In the PSTN, =A0we use the UUI field to transmit information between the >> Intelligent Network (IN) system and call center agents for the >> directory enquires service. Everybody in Germany who wants to ask for >> the phone number of another person dials DT's directory enquires >> service and is connected to a call center agent who tells him the >> number he wants to know. Additionaly, only if the caller is a DT >> customer, the call center agent offers to connect him to this number, >> so the caller does not need to dial. For everybode else, he does not. >> So the call center agent needs to get the information whether or not >> the caller is a DT customer. This is done by routing every directory >> enquires call to the IN system first. The IN system checks the caller >> number and inserts the information about whether or not the caller is >> a DT-customer in the UUI field which is transmited via INAP, ISUP and >> DSS1 to the call center agent's end device.The call center agent gets >> a display about this. During the PSTN-migration to SIP, we will have >> cases where the call center and the IN system are connected to >> different networks, one to PSTN and the other to SIP. =A0Also, we may >> have applications as above on pure SIP application servers. >> >>> Can you shed some light on *how* this is used, given the lack of any >>> standards on the content/formatting of this information? >> >> The application is DT-specific and needs a DT specification to be >> supported by the IN system and the call center, but the container to >> transport the information must be supported by both ends and by the >> network nodes. >> >>> Or is this only used between a caller and a callee that have somehow >>> obtained contextual information that they both support this feature *an= d* a >>> particular encoding? >> >> At least within the DT network, UUI is used between application >> servers or application servers and "special" end devices as call >> centers. As far as I know, UUI is currently not part of the DT normal >> telephony package. Many years ago, it was, but people misused it. >> >> We plan to use the "Johnston uui draft" for the scenario described >> above and we see the need for the proposed WG. >> >> Thanks a lot >> Laura >> >> >> Laura >> >> >> >> >> >> >> >> >> 2010/6/30 Paul Kyzivat : >>> James, >>> >>> Can you shed some light on *how* this is used, given the lack of any >>> standards on the content/formatting of this information? >>> >>> Do you use content=3Disdn-uui and some particular Q.931 protocol discri= minator >>> for which there are formatting standards? >>> >>> Or is this only used between a caller and a callee that have somehow >>> obtained contextual information that they both support this feature *an= d* a >>> particular encoding? >>> >>> =A0 =A0 =A0 =A0Thanks, >>> =A0 =A0 =A0 =A0Paul >>> >>> James Rafferty wrote: >>>> >>>> Hi, >>>> My company has had the experience of deploying the pre-standard versio= n of >>>> this PSTN to SIP UUI mechanism during the past 2 years. >>>> As noted in the draft charter, UUI information is widely used on the P= STN >>>> for applications such as offering input data into call centers and the= n >>>> preserving that data as calls get transferred. >>>> Since many contact centers are now built using SIP, but still have PST= N >>>> subscribers (via SS7 ISUP or ISDN PRI), there is a need to be able to >>>> interwork the user to user information from the PSTN side into SIP. = =A0In our >>>> experience, the "Johnston uui draft" has accomplished this and we have >>>> several customers that find this interworking to be valuable. =A0We al= so noted >>>> improvements from early drafts into the later ones in areas such as ma= king >>>> better use of the ITU-T protocol discriminator, thus enabling better >>>> interoperability from the PSTN side into SIP. >>>> The major deficiency of the current draft is its non-standard status. >>>> Functionally, we and our customers find this mechanism to be very usef= ul and >>>> I'd very much like the IETF to charter the a UUI work group to standar= dize >>>> such a mechanism. >>>> James =A0-----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>>> Behalf Of Gonzalo Camarillo >>>> Sent: Wednesday, June 30, 2010 2:51 AM >>>> To: Paul Kyzivat >>>> Cc: dispatch@ietf.org; DRAGE, Keith (Keith); ietf@ietf.org >>>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP >>>> (cuss) >>>> >>>> Hi, >>>> >>>> please keep both the IETF and the DISPATCH mailing lists in the >>>> recipients list in this discussion. >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >>>> >>>> On 29/06/2010 8:23 PM, Paul Kyzivat wrote: >>>>> >>>>> DRAGE, Keith (Keith) wrote: >>>>>> >>>>>> The UUI information is NOT ISUP. It is a transparent envelope to the >>>>>> entire ISDN, so it is not part of an ISDN protocol and therefore not= part of >>>>>> an ISUP protocol. When carried by ISUP the envelope is bundled up in= another >>>>>> envelope with other information that ISUP carries transparently. >>>>>> >>>>>> So I believe, and have said repeatedly in the past, that references = to >>>>>> SIP-T are irrelevant in this case. >>>>>> >>>>>> The problem we do have though is that are legacy usages of this >>>>>> information. In particular applications in PBXs carry it between the= mselves >>>>>> in ISDN call establishment. The information itself is not standardis= ed. If >>>>>> you want to migrate a PBX from DSS1 to SIP, then you have to take th= is >>>>>> information into account. The desire is not for a WG group to standa= rdise >>>>>> this existing usage (which in my view would be a complete non-starte= r), but >>>>>> to allow the transfer of the existing information when migrated to a= SIP >>>>>> environment. The information transferred does not form part of SIP, = and >>>>>> should not be standardised as part of SIP. >>>>> >>>>> How many different mechanisms do we have to construct for the purpose= of >>>>> tunneling stuff over SIP? >>>>> >>>>> Its especially bad if the stuff is neither standardized nor negotiate= d. >>>>> It then just provides more opportunity for non-interoperability. >>>>> >>>>> It had been my impression that this content was standardized by ITU. >>>>> If nobody can bother to standardize it, then it hardly seems worth >>>>> working on. >>>>> >>>>> =A0 =A0 =A0 =A0Thanks, >>>>> =A0 =A0 =A0 =A0Paul >>>>> >>>>>> regards >>>>>> >>>>>> Keith >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: dispatch-bounces@ietf.org >>>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of >>>>>>> bruno.chatras@orange-ftgroup.com >>>>>>> Sent: Tuesday, June 29, 2010 1:00 PM >>>>>>> To: Gonzalo.Camarillo@ericsson.com; dispatch@ietf.org >>>>>>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI >>>>>>> for SIP (cuss) >>>>>>> >>>>>>> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 >>>>>>> does state that SIP-T does not come into play when there is >>>>>>> no PSTN involved. >>>>>>> >>>>>>> At the end of clause 2 we can read the following: "4. =A0IP >>>>>>> origination - IP termination: This is a case for pure SIP. >>>>>>> SIP-T (either encapsulation or translation of ISUP) does not >>>>>>> come into play as there is no PSTN interworking." >>>>>>> >>>>>>> Besides, SIP-T would require encapsulating a full ISUP >>>>>>> message (e.g. IAM) while we are interested in just one >>>>>>> parameter of the message in the context of CUSS. This would I >>>>>>> believe be a more severe drawback if SIP-T were used for this purpo= se. >>>>>>> >>>>>>> Bruno >>>>>>> >>>>>>> >>>>>>>> -----Message d'origine----- >>>>>>>> De : dispatch-bounces@ietf.org >>>>>>>> [mailto:dispatch-bounces@ietf.org] De la part de Gonzalo Camarillo >>>>>>>> Envoy=E9 : mardi 29 juin 2010 13:03 =C0 : DISPATCH Objet : >>>>>>> >>>>>>> [dispatch] Fwd: >>>>>>>> >>>>>>>> Re: WG Review: Call Control UUI for SIP (cuss) >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> FYI: note the discussion below on the IETF general list. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Gonzalo >>>>>>>> >>>>>>>> -------- Original Message -------- >>>>>>>> Subject: Re: WG Review: Call Control UUI for SIP (cuss) >>>>>>>> Date: Mon, 28 Jun 2010 20:24:23 +0200 >>>>>>>> From: Cullen Jennings >>>>>>>> To: iesg@ietf.org >>>>>>>> CC: IETF Discussion Mailing List >>>>>>>> >>>>>>>> >>>>>>>> As far as I can tell, the WG says they wants to transfer some >>>>>>>> information to achieve cross vendor interoperability. >>>>>>>> However, what I believe the charter is actually going to do >>>>>>> >>>>>>> is exactly >>>>>>>> >>>>>>>> the opposite of that. When you get your head around what >>>>>>> >>>>>>> this charter >>>>>>>> >>>>>>>> is proposing, it is going to form a more or less opaque >>>>>>> >>>>>>> container for >>>>>>>> >>>>>>>> transporting proprietary information in a SIP header. It's hard to >>>>>>>> imagine how this will help interoperability. >>>>>>>> >>>>>>>> If we wanted to have interoperability, the charter would say what >>>>>>>> information needs to be transferred and have the WG define a way t= o >>>>>>>> get it between systems in an operable way. >>>>>>>> What the charter for this WG actually says they are going to do is >>>>>>>> make a special container for transfer proprietary information. >>>>>>>> There's not even willing to say what that proprietary >>>>>>> >>>>>>> information is >>>>>>>> >>>>>>>> used for other than things ISDN UUI which is a =A0non >>>>>>> >>>>>>> interoperable and >>>>>>>> >>>>>>>> fairly proprietary field in ISDN. >>>>>>>> Furthermore they have asserted that =A0existing containers >>>>>>> >>>>>>> such as SIP-T >>>>>>>> >>>>>>>> or SIP bodies can't be used for reasons that are hard to >>>>>>> >>>>>>> describe. (I >>>>>>>> >>>>>>>> reject the idea that because the call might not involved >>>>>>> >>>>>>> the PSTN, it >>>>>>>> >>>>>>>> can't use SIP-T). >>>>>>>> >>>>>>>> I think the folks that want to do this should get a much clear >>>>>>>> explanation of how this results in interoperability and why exist >>>>>>>> approach such as SIP-T will not work before this is chartered. >>>>>>>> >>>>>>>> I do think there is a need to standardize some important >>>>>>> >>>>>>> call control >>>>>>>> >>>>>>>> information used in call centers and related places. >>>>>>>> However, the "we need a standard container to exchange secret >>>>>>>> information WG" is a bad idea and violates the sprit of the >>>>>>> >>>>>>> SIP change >>>>>>>> >>>>>>>> process not to mention the mission of the IETF. >>>>>>>> >>>>>>>> In summary, I'm in favor of figuring out what the problems >>>>>>> >>>>>>> are people >>>>>>>> >>>>>>>> hope to solve with this WG and figuring out a way to write >>>>>>>> interoperable standards to achieve that. However, I think >>>>>>> >>>>>>> this charter >>>>>>>> >>>>>>>> should be rejected by the IESG and sent back to the drawing >>>>>>> >>>>>>> board. The >>>>>>>> >>>>>>>> RAI area has things of higher priority items to work on than a SIP >>>>>>>> header for transfer proprietary data. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote: >>>>>>>> >>>>>>>>> A new IETF working group has been proposed in the Real-time >>>>>>>>> Applications and Infrastructure Area. =A0The IESG has not >>>>>>>> >>>>>>>> made any determination as yet. >>>>>>>>> >>>>>>>>> The following draft charter was submitted, and is provided for >>>>>>>>> informational purposes only. Please send your comments to >>>>>>> >>>>>>> the IESG >>>>>>>>> >>>>>>>>> mailing list (iesg@ietf.org) by Tuesday, June 29, 2010. >>>>>>>>> >>>>>>>>> Call Control UUI for SIP =A0(cuss) >>>>>>>>> -------------------------------------------------- >>>>>>>>> Current Status: Proposed Working Group >>>>>>>>> >>>>>>>>> Last modified: 2010-06-21 >>>>>>>>> >>>>>>>>> Chair(s): >>>>>>>>> =A0TBD >>>>>>>>> >>>>>>>>> Real-time Applications and Infrastructure Area Director(s): >>>>>>>>> =A0Gonzalo Camarillo >>>>>>> >>>>>>> Robert Sparks >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Real-time Applications and Infrastructure Area Advisor: >>>>>>>>> =A0Gonzalo Camarillo >>>>>>>>> >>>>>>>>> Mailing Lists: TBD >>>>>>>>> >>>>>>>>> Description of Working Group: >>>>>>>>> >>>>>>>>> The Call Control UUI for SIP (CUSS) working group is chartered to >>>>>>>>> define a Session Initiation Protocol (SIP) mechanism for >>>>>>>> >>>>>>>> transporting >>>>>>>>> >>>>>>>>> call-control related user-to-user information (UUI) between User >>>>>>>>> Agents. >>>>>>>>> >>>>>>>>> The mechanism developed in this working group is >>>>>>> >>>>>>> applicable in the >>>>>>>>> >>>>>>>>> following situations: >>>>>>>>> >>>>>>>>> 1. The information is generated and consumed by an >>>>>>> >>>>>>> application using >>>>>>>>> >>>>>>>>> =A0SIP during session setup but the application is not necessaril= y >>>>>>>>> =A0even SIP aware. >>>>>>>>> 2. The behavior of SIP entities that support it is not >>>>>>> >>>>>>> significantly >>>>>>>>> >>>>>>>>> =A0changed (as discussed in Section 4 of RFC 5727). >>>>>>>>> 3. Generally only the User Agent Client (UAC) and User >>>>>>> >>>>>>> Agent Server >>>>>>>>> >>>>>>>>> =A0(UAS) are interested in the information. >>>>>>>>> 4. The information is expected to survive retargeting, >>>>>>> >>>>>>> redirection, >>>>>>>>> >>>>>>>>> =A0and transfers. >>>>>>>>> 5. SIP elements may need to apply policy about passing >>>>>>> >>>>>>> and screening >>>>>>>>> >>>>>>>>> =A0the information. >>>>>>>>> 6. Multi-vendor interoperability is important. >>>>>>>>> >>>>>>>>> This mechanism is not applicable in the following situations: >>>>>>>>> >>>>>>>>> 1. The behavior of SIP entities that support it is significantly >>>>>>>>> =A0changed (as discussed in Section 4 of RFC 5727). >>>>>>>>> 2. The information is generated and consumed at the SIP >>>>>>> >>>>>>> layer by SIP >>>>>>>>> >>>>>>>>> =A0elements. >>>>>>>>> 3. SIP elements besides the UAC and UAS might be interested in >>>>>>>>> =A0consuming (beyond applying policy) the information. >>>>>>>>> 4. There are specific privacy issues involved with the informatio= n >>>>>>>>> =A0being transported (e.g., geolocation or emergency-related >>>>>>>>> =A0information). >>>>>>>>> >>>>>>>>> User data of the mechanism will be clearly marked with the >>>>>>>>> application, encoding, semantics, and content type, >>>>>>>> >>>>>>>> allowing policy to >>>>>>>>> >>>>>>>>> be applied by UAs. =A0The working group will define the >>>>>>>> >>>>>>>> information that >>>>>>>>> >>>>>>>>> each application must specify to utilize the mechanism. >>>>>>>> >>>>>>>> This type of >>>>>>>>> >>>>>>>>> application-specific information will be specified in >>>>>>>> >>>>>>>> standards-track >>>>>>>>> >>>>>>>>> documents. >>>>>>>>> >>>>>>>>> One important application of this mechanism is interworking >>>>>>>> >>>>>>>> with the >>>>>>>>> >>>>>>>>> ISDN User to User Information Service. =A0This application >>>>>>> >>>>>>> defined by >>>>>>>>> >>>>>>>>> ITU-T Q.931 is extensively deployed in the PSTN today >>>>>>>> >>>>>>>> supporting such >>>>>>>>> >>>>>>>>> applications as contact centers, call centers, and automatic call >>>>>>>>> distributors (ACDs). =A0A major barrier to the movement of these >>>>>>>>> applications to SIP is the lack of a standard mechanism to >>>>>>>> >>>>>>>> transport >>>>>>>>> >>>>>>>>> this information in SIP. =A0For interworking with ISDN, minimal >>>>>>>>> information about the content of the UUI is available to >>>>>>>> >>>>>>>> the PSTN-SIP >>>>>>>>> >>>>>>>>> gateways. =A0In this case only, the content will just >>>>>>>> >>>>>>>> indicate ISDN UUI >>>>>>>>> >>>>>>>>> Service 1 interworking rather than the actual content. >>>>>>>>> >>>>>>>>> Call control UUI is user information conveyed between user agents >>>>>>>>> during call control operations. =A0As a result, the >>>>>>>> >>>>>>>> information must be >>>>>>>>> >>>>>>>>> conveyed with the INVITE transaction, and must survive proxy >>>>>>>>> retargeting, redirection, and transfers. =A0The mechanism >>>>>>>> >>>>>>>> must utilize a >>>>>>>>> >>>>>>>>> minimum of SIP extensions since it will need to be >>>>>>>> >>>>>>>> supported by many >>>>>>>>> >>>>>>>>> simple SIP user agents such as PSTN gateways. =A0The mechanism mu= st >>>>>>>>> interwork with the existing ISDN service but should also be >>>>>>>> >>>>>>>> extensible >>>>>>>>> >>>>>>>>> for use by other applications and non-ISDN protocols. >>>>>>>>> >>>>>>>>> Even though interworking with the PSTN is an important >>>>>>> >>>>>>> requirement, >>>>>>>>> >>>>>>>>> call control UUI can be exchanged between native SIP >>>>>>>> >>>>>>>> clients that do >>>>>>>>> >>>>>>>>> not have any ISUP support. Therefore, existing SIP-T >>>>>>>>> encapsulation-based approaches defined in RFC3372 do not meet the >>>>>>>>> requirements to transport this type of information. >>>>>>>>> >>>>>>>>> Mechanisms based on the SIP INFO method, RFC2976, will not be >>>>>>>>> considered by the working group since the UUI contents carry >>>>>>>>> information that must be conveyed during session setup at >>>>>>> >>>>>>> the user >>>>>>>>> >>>>>>>>> agent - the information must be conveyed with the INVITE >>>>>>>> >>>>>>>> transaction. >>>>>>>>> >>>>>>>>> The information must be passed with the session setup request >>>>>>>>> (INVITE), responses to that INVITE, or session >>>>>>> >>>>>>> termination requests. >>>>>>>>> >>>>>>>>> As a result, it is not possible to use INFO in these cases. >>>>>>>>> >>>>>>>>> The group will produce: >>>>>>>>> >>>>>>>>> - A problem statement and requirements document for >>>>>>>> >>>>>>>> implementing a SIP >>>>>>>>> >>>>>>>>> call control UUI mechanism >>>>>>>>> >>>>>>>>> - A specification of the SIP extension to best meet those >>>>>>>> >>>>>>>> requirements. >>>>>>>>> >>>>>>>>> Goals and Milestones >>>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>>> >>>>>>>>> Sep 10 - Problem statement and requirements document to IESG >>>>>>>>> (Informational) >>>>>>>>> Mar 11 - SIP call control UUI specification to IESG (PS) >>>>>>>>> _______________________________________________ >>>>>>>>> IETF-Announce mailing list >>>>>>>>> IETF-Announce@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/ietf-announce >>>>>>>> >>>>>>>> Cullen Jennings >>>>>>>> For corporate legal information go to: >>>>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > From pkyzivat@cisco.com Fri Jul 9 07:59:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2243A6A66; Fri, 9 Jul 2010 07:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.393 X-Spam-Level: X-Spam-Status: No, score=-10.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1d-kn5pE3p9C; Fri, 9 Jul 2010 07:59:31 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A76753A680F; Fri, 9 Jul 2010 07:59:31 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,564,1272844800"; d="scan'208";a="130482767" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Jul 2010 14:59:36 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o69Exas8018668; Fri, 9 Jul 2010 14:59:36 GMT Message-ID: <4C373953.3000402@cisco.com> Date: Fri, 09 Jul 2010 10:59:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Laura Liess References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> <4C2A2C19.1030906@cisco.com> <4C2AE94C.4020707@ericsson.com> <617DF0128820F9458AC39149A627EE6C01A66BC2A7@MBX.dialogic.com> <4C2B8ACE.3050301@cisco.com> <2A1051E9-99DC-458C-B96B-0BE7FB4CD4C1@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , James Rafferty , Roland Jesske , "ietf@ietf.org" Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 14:59:32 -0000 Laura Liess wrote: > Is it so easy to instruct a proxy to > inspect the body and eventually throw away a part of it? And should > one do that? While a proxy may inspect a body (if its not encrypted), by definition a proxy may not modify or remove a body. Thanks, Paul From christer.holmberg@ericsson.com Fri Jul 9 09:23:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F3CA3A69E3 for ; Fri, 9 Jul 2010 09:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0B7nrvQodm5 for ; Fri, 9 Jul 2010 09:23:11 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 4EEB53A67F9 for ; Fri, 9 Jul 2010 09:23:11 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-57-4c374cf3ef5f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 93.A9.10125.3FC473C4; Fri, 9 Jul 2010 18:23:15 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.94]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Fri, 9 Jul 2010 18:23:15 +0200 From: Christer Holmberg To: Paul Kyzivat , Brett Tate Date: Fri, 9 Jul 2010 18:23:14 +0200 Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: AcsfaVkRDw6gM+YeRNGs4NtRl8zAGAAGPtQc Message-ID: References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com> <4C3668F4.1080807@cisco.com> <058401cb1efe$360fe950$a22fbbf0$@com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DE01F8EE@EXMBXCLUS01.citservers.local>, <4C3721A6.8070507@cisco.com> In-Reply-To: <4C3721A6.8070507@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: 'DISPATCH list' Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 16:23:12 -0000 Hi, In my opinion the definitions of B2BUA and SBC are completely different. B2BUA is normallly used as a SIP term, and describes an entity which acts a= s a UA towards each direction. What happens to SIP information (header fiel= d values, SDP etc) passing the B2BUA varies. SBC is much more than SIP, and from a pure SIP perspective an SBC may in so= me cases even act as a normal SIP proxy, ie it does not touch the SIP infor= mation and does not do anything else "forbidden". Regards, Christer ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Pa= ul Kyzivat [pkyzivat@cisco.com] Sent: Friday, July 09, 2010 4:18 PM To: Brett Tate Cc: 'DISPATCH list' Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? Perhaps it would be worthwhile to begin creating a taxonomy of the more interesting sorts of B2BUAs. This wouldn't have been possible at the time 3261 was published. But by now there is a lot of experience and it seems there are a number of common forms evolving independently. (Who will be the Linnaeus of B2BUAs?) Then there might be a basis for further standardization of some of those when it seems useful/necessary in order to promote interoperability. Thanks, Paul Brett Tate wrote: >> Perhaps the BEHAVE-like activity should be >> on B2BUAs in general, rather than SBCs. > > As has been mentioned, there are a variety of B2BUA types. If the activi= ty is to apply to B2BUAs in general, the activity would need to recognize t= hat the following types of B2BUA (or their services) exist and would remain= . Thus B2BUAs desiring to act mostly like proxies could benefit from the a= ctivity; however others because of configuration or otherwise might not be = able to fully comply. > > Some B2BUAs or their services intentionally attempt to restrict/control e= nd-to-end functionality. Ironically one reason may even be to improve inte= roperability. > > Some B2BUAs or their services (such as discussed within RFC 3323) intenti= onally attempt to hide the correlation of the two call halves. > > There are some B2BUAs (such as conference servers and gateways) that typi= cally may not consider themselves to be B2BUAs even though they are connect= ing the call halves directly or indirectly through using other devices/prot= ocols. > > > _______________________________________________ > 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 christer.holmberg@ericsson.com Fri Jul 9 11:47:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21EDA3A6AB7 for ; Fri, 9 Jul 2010 11:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h5OT8EUVOwy0 for ; Fri, 9 Jul 2010 11:47:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id BE9853A63C9 for ; Fri, 9 Jul 2010 11:47:12 -0700 (PDT) X-AuditID: c1b4fb39-b7c39ae000000c17-85-4c376eb44f35 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0F.3E.03095.4BE673C4; Fri, 9 Jul 2010 20:47:16 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.94]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 9 Jul 2010 20:47:16 +0200 From: Christer Holmberg To: Paul Kyzivat , "Mohammad Al-Taraireh (maltarai)" Date: Fri, 9 Jul 2010 20:43:56 +0200 Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: Acse+x6HePYsIGebRkGv9hhtpmUqCwAm5Elq Message-ID: References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com> In-Reply-To: <4C3668F4.1080807@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 18:47:46 -0000 Hi, Rather than focus on node terminology, I think we should focus on the FUNCT= IONS they perform, and see whether something can do done in order to avoid = claimed interop problems etc, rather than arguing about whether the entity = that performs the function shall be called B2BUA, SBC, Application Server, = or something else... Regards, Christer ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Pa= ul Kyzivat [pkyzivat@cisco.com] Sent: Friday, July 09, 2010 3:10 AM To: Mohammad Al-Taraireh (maltarai) Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? Mohammad Al-Taraireh (maltarai) wrote: > Doesn't the B2BUA term also implies media origination, and termination > capabilities ? It seems that the B2BUA term is already overloaded to > include SBC. The term "B2BUA" is distinguished by the minimality of its definition and the corresponding broadness of applicability. It neither implies nor forbids media processing. The term SBC, as typically used, is somewhat narrower in scope that B2BUA, but is still incredibly broad. I certainly know of things that consider themselves to be SBCs that (at least sometimes) don't terminate media. And certainly there are B2BUAs that *do* terminate media that you would not want to call an SBC. (E.g. a conference focus and mixer.) Thanks, Paul > Mo > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Dan Wing (dwing) > Sent: Thursday, July 08, 2010 5:31 PM > To: Cullen Jennings (fluffy) > Cc: 'DISPATCH list' > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Thursday, July 08, 2010 1:34 PM >> To: Dan Wing >> Cc: DISPATCH list >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >> >> >> Seems reasonable. I think B2BUA is reasonable well defined. Care to >> put on your fire proof suit and propose a definition of what an SBC > is? > > SBC: a B2BUA that also terminates and originates media from user > agents or media from an adjacent SBC. > > -d > > >> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >> >>>> -----Original Message----- >>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>> Sent: Thursday, July 08, 2010 5:50 AM >>>> To: Dan Wing >>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>> >>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes >>>> - >> 03 >>>> has just been submitted. >>> Splendid. I refer to the media latching in that document > frequently. >>> Myself, I would be happier if IETF could find it possible to include > >>> the acronym-that-must-not-be-spoken (SBC) in SBC-related >>> specifications -- no matter if an SBC working group is formed or >>> not. Calling them 'middleboxes' is too vague to be useful, much >>> like "gateway" is too vague (a gateway to the PSTN? a router?) Call > >>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC an >>> SBC. >>> >>> -d >>> >>> >>>> Dan Wing wrote: >>>>>> -----Original Message----- >>>>>> From: dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] >>>> On >>>>>> Behalf Of Peter Musgrave >>>>>> Sent: Thursday, July 01, 2010 12:30 PM >>>>>> To: WORLEY, Dale R (Dale) >>>>>> Cc: DISPATCH list >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>> >>>>>> I concur. >>>>>> >>>>>> There is some useful background in RFC5853 and perhaps >>>>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 >>>>>> >>>>>> And then some things which died on the vine such as: >>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>>>> and perhaps some others? >>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >> middleboxes- >>>> 02 died. >>>>> -d >>>> ... >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> > > > _______________________________________________ > 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 fluffy@cisco.com Fri Jul 9 15:00:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D91A3A689C for ; Fri, 9 Jul 2010 15:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.453 X-Spam-Level: X-Spam-Status: No, score=-110.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMy7B55wh-yk for ; Fri, 9 Jul 2010 15:00:17 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id BF4A83A67B8 for ; Fri, 9 Jul 2010 15:00:17 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssHAIM4N0yrR7Ht/2dsb2JhbAAdoCpxo1maQIUnBIN5hFA X-IronPort-AV: E=Sophos;i="4.55,175,1278288000"; d="scan'208";a="156493137" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 09 Jul 2010 22:00:22 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o69M0LA8009603; Fri, 9 Jul 2010 22:00:22 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Fri, 9 Jul 2010 16:00:21 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <7872E6AE-BDE8-4A19-B3A3-02E6C9401C7A@cisco.com> References: <20100705160001.9CA5A3A6890@core3.amsl.com> To: "Elwell, John" X-Mailer: Apple Mail (2.1081) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-jennings-dispatch-npa-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 22:00:20 -0000 On Jul 9, 2010, at 3:09 AM, Elwell, John wrote: > 1.1 Simple Single TLD. This would presumably involve reserving PANxxx = (where xxx is a digit string of a certain length or range of lengths), = and would be a problem if any such value has already been taken. can you say a bit more about what you see as the problem - my thinking = is roughly the following. If 123 is already taken by someone else, then = it is taken - it does not matter if we use sipforum or .net as the = registry. Now if you are concerned that pan123.net might be taken for = some other use than the purpose of the PAN draft, then we could make the = string you prepend be pan-z9hG4bK and that problem more or less goes = away. You could argue that .net domains are so cheap that someone might = just go get all of them. This seems like a pretty unlikely attack but = that is why the xxx has a minimum length so the number they needed to = get was large. Also it may have a minimum length but it's not fixed = length so people can go to a domain with a longer string.=20 I'm just not really seeing how this is all that much different if we = have the domain that looks like 123.sipforum.net or a string that looks = like 123sipforum.net - the size of the address space is about the same = either way.=20 And I pretty much agree with your comments on the other the other ones - = we could probably find ways to solve some of theses but 2,3,4 are at = some level just optimization of 1 so if there is some fundamental = problem with 1, it probably impacts all of them. =20 From jdrosen@jdrosen.net Fri Jul 9 15:20:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 658383A67D0; Fri, 9 Jul 2010 15:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rUeM7OHEuQiy; Fri, 9 Jul 2010 15:20:19 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [173.205.124.201]) by core3.amsl.com (Postfix) with ESMTP id 01F783A67B8; Fri, 9 Jul 2010 15:20:19 -0700 (PDT) Received: from pool-173-63-40-38.nwrknj.fios.verizon.net ([173.63.40.38] helo=[192.168.1.8]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OXLv4-0001Cs-QO; Fri, 09 Jul 2010 18:19:42 -0400 Message-ID: <4C37A09E.5080102@jdrosen.net> Date: Fri, 09 Jul 2010 18:20:14 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Richard Shockey References: <001201cb1ade$4195f680$c4c1e380$@us> <009f01cb1bba$4c7bcd40$e57367c0$@us> <4C32199A.80809@cisco.com> <008d01cb1c72$9bdb96a0$d392c3e0$@us> <2a2201cb1e5a$85b5df90$91219eb0$@com> <00f401cb1eb4$cbb98230$632c8690$@us> In-Reply-To: <00f401cb1eb4$cbb98230$632c8690$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Cc: 'DISPATCH' , 'IETF-Discussion list' Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 22:20:20 -0000 Richard Shockey wrote: > RS> You cannot authoritatively determine a binding between a phone number > and a consumer (domain) without access to the databases. The point of ViPR is that the authoritative mapping as you've defined it just isn't necessary; a forward routability check is all that is really needed. Indeed, let us look at email for a moment. How does one know that "jdrosen@jdrosen.net" authoritatively maps to me? In reality the only authoritative source for this is the databases at jdrosen.net which contain credentials that are bound to me. However, those are inaccessible to the rest of the world. Instead, one can check if jdrosen@jdrosen.net routes to me by sending me an email with some kind of secret, and if I can prove I know that secret, you know that I'm jdrosen@jdrosen.net. This forward routability check is the foundation for vast amounts of web security and identity, and that same principle is applied here for phone numbers. Do you argue that we should stop using these forward email routing checks in the web? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From gonzalo.camarillo@ericsson.com Sat Jul 10 00:00:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CA5C3A67B5 for ; Sat, 10 Jul 2010 00:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.288 X-Spam-Level: X-Spam-Status: No, score=-105.288 tagged_above=-999 required=5 tests=[AWL=1.311, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CeGVLk1BxQQE for ; Sat, 10 Jul 2010 00:00:11 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 546193A6858 for ; Sat, 10 Jul 2010 00:00:11 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-de-4c381a7eeae6 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F0.8E.10125.E7A183C4; Sat, 10 Jul 2010 09:00:14 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Jul 2010 09:00:03 +0200 Received: from [131.160.126.198] ([131.160.126.198]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 10 Jul 2010 08:53:45 +0200 Message-ID: <4C3818F8.6010505@ericsson.com> Date: Sat, 10 Jul 2010 09:53:44 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2010 06:53:45.0610 (UTC) FILETIME=[A421F6A0:01CB1FFC] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] The LSD WG has been created to work on disaggregated media in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2010 07:00:12 -0000 Folks, the LSD WG has just been created. As you know, this WG came out of DISPATCH. Simon Pietro, in the cc:, is going to be chairing this WG: https://datatracker.ietf.org/wg/lsd/charter/ If you are interested in this work, subscribing to the LSD mailing list would be a good start. Cheers, Gonzalo From bernard_aboba@hotmail.com Sat Jul 10 14:21:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DF5B3A67FB for ; Sat, 10 Jul 2010 14:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.287 X-Spam-Level: X-Spam-Status: No, score=0.287 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kc8g2Vi4t3t for ; Sat, 10 Jul 2010 14:21:23 -0700 (PDT) Received: from blu0-omc4-s10.blu0.hotmail.com (blu0-omc4-s10.blu0.hotmail.com [65.55.111.149]) by core3.amsl.com (Postfix) with ESMTP id 879333A687A for ; Sat, 10 Jul 2010 14:21:23 -0700 (PDT) Received: from BLU137-DS13 ([65.55.111.136]) by blu0-omc4-s10.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Jul 2010 14:21:29 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Sat, 10 Jul 2010 14:22:12 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0508_01CB203B.4A7A27F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcsgdfZdPdkjw9+JSn+m5ITKqYBE6Q== Content-Language: en-us X-OriginalArrivalTime: 10 Jul 2010 21:21:29.0098 (UTC) FILETIME=[DC63C6A0:01CB2075] Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jul 2010 21:21:24 -0000 ------=_NextPart_000_0508_01CB203B.4A7A27F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jonathan said: "Do you argue that we should stop using these forward email routing checks in the web?" [BA] I don't think that the security of return reachability is the issue, so much as the scaling characteristics. In this case, more than one mapping between an E.164 number and an email-style URI can be asserted. While invalid mappings will presumably fail the test, the average number of tests that need to be performed is N/2. As N grows, the delay required to upgrade will grow linearly. In contrast, the Facetime approach (as I understand it) utilizes in-band communication that yields a delay that cannot be influenced by outside parties. ------=_NextPart_000_0508_01CB203B.4A7A27F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Jonathan said:

 

"Do you argue that we should stop using these forward email routing checks = in the web?"

 

[BA] I don't think that the security of return reachability is the issue, so = much as the scaling characteristics.

 

In this case, more than one mapping between an E.164 number and an = email-style URI can be asserted.

 

While invalid mappings will presumably fail the test, the average number of = tests that need to be performed is N/2. 

 

As N grows, the delay required to upgrade will grow = linearly.

 

In contrast, the Facetime approach (as I understand it) utilizes in-band communication that yields a delay that cannot be influenced by outside = parties.

------=_NextPart_000_0508_01CB203B.4A7A27F0-- From hgs@cs.columbia.edu Sat Jul 10 22:53:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39D9328C0D9 for ; Sat, 10 Jul 2010 22:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.099 X-Spam-Level: X-Spam-Status: No, score=-7.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qab6s4QU9W0y for ; Sat, 10 Jul 2010 22:52:22 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id 64FC628B23E for ; Sat, 10 Jul 2010 22:52:01 -0700 (PDT) Received: from [192.168.11.9] (85-23-27-240-Torikatu-TR1.suomi.net [85.23.27.240]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id o6B5pGEW016568 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 11 Jul 2010 01:51:18 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: <4C3818F8.6010505@ericsson.com> Date: Sun, 11 Jul 2010 01:51:16 -0400 Content-Transfer-Encoding: 7bit Message-Id: <5F6899ED-4F7C-41E4-9C09-EB77698326D0@cs.columbia.edu> References: <4C3818F8.6010505@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1081) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: DISPATCH Subject: Re: [dispatch] The LSD WG has been created to work on disaggregated media in SIP X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 05:53:23 -0000 On Jul 10, 2010, at 2:53 AM, Gonzalo Camarillo wrote: > Folks, > > the LSD WG has just been created. As you know, this WG came out of > DISPATCH. Simon Pietro, in the cc:, is going to be chairing this WG: > > https://datatracker.ietf.org/wg/lsd/charter/ > > If you are interested in this work, subscribing to the LSD mailing list > would be a good start. I'm sure it's going to be a mind-altering experience. From maltarai@cisco.com Sun Jul 11 09:52:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 085583A67F5 for ; Sun, 11 Jul 2010 09:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwTvYQ5ryJGu for ; Sun, 11 Jul 2010 09:52:52 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2310F3A6924 for ; Sun, 11 Jul 2010 09:52:52 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkFAFOTOUytJV2d/2dsb2JhbACBQ559caILmSqFJwSDe4Z/ X-IronPort-AV: E=Sophos;i="4.55,183,1278288000"; d="scan'208,217";a="131084587" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 11 Jul 2010 16:52:58 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o6BGqwlU013376; Sun, 11 Jul 2010 16:52:58 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Jul 2010 11:52:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2119.83ED80B0" Date: Sun, 11 Jul 2010 11:52:56 -0500 Message-ID: <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 3 Thread-Index: AcsgdfZdPdkjw9+JSn+m5ITKqYBE6QAouEHg References: From: "Mohammad Al-Taraireh (maltarai)" To: "Bernard Aboba" , X-OriginalArrivalTime: 11 Jul 2010 16:52:58.0497 (UTC) FILETIME=[8422E710:01CB2119] Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 16:52:54 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2119.83ED80B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bernard,=20 =20 I did not follow the scaling characteristics issue that you are bringing up. In general only enterprises that advertised ownership of the E.164 number will be validated against, not every E.164 number in the DHT.=20 Since the validation is not a part of call processing, some delay is acceptable.=20 =20 Mo A ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Saturday, July 10, 2010 5:22 PM To: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 3 =20 Jonathan said: =20 "Do you argue that we should stop using these forward email routing checks in the web?" =20 [BA] I don't think that the security of return reachability is the issue, so much as the scaling characteristics.=20 =20 In this case, more than one mapping between an E.164 number and an email-style URI can be asserted.=20 =20 While invalid mappings will presumably fail the test, the average number of tests that need to be performed is N/2. =20 =20 As N grows, the delay required to upgrade will grow linearly. =20 In contrast, the Facetime approach (as I understand it) utilizes in-band communication that yields a delay that cannot be influenced by outside parties.=20 ------_=_NextPart_001_01CB2119.83ED80B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Bernard,
 
I did not follow the scaling characteristics issue = that you=20 are bringing up. In general only enterprises = that advertised ownership=20 of  the E.164 number will be validated against, not every E.164 = number in=20 the DHT.
Since the validation is not a part of call = processing, some=20 delay is acceptable.
 
Mo A

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Saturday, July 10, 2010 5:22 PM
To:=20 dispatch@ietf.org
Subject: Re: [dispatch] VIPR - proposed = charter=20 version 3

 

Jonathan=20 said:

 

"Do=20 you argue that we should stop using these forward email routing checks = in the=20 web?"

 

[BA] I don't think = that the=20 security of return reachability is the issue, so much as the scaling=20 characteristics.

 

In=20 this case, more than one mapping between an E.164 number and an = email-style URI=20 can be asserted.

 

While invalid = mappings will=20 presumably fail the test, the average number of tests that need to be = performed=20 is N/2. 

 

As=20 N grows, the delay required to upgrade will grow = linearly.

 

In=20 contrast, the Facetime approach (as I understand it) utilizes in-band=20 communication that yields a delay that cannot be influenced by outside = parties.=20

------_=_NextPart_001_01CB2119.83ED80B0-- From bernard_aboba@hotmail.com Sun Jul 11 10:08:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE403A69E5 for ; Sun, 11 Jul 2010 10:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.165 X-Spam-Level: X-Spam-Status: No, score=0.165 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5NRDvLhQ1rW for ; Sun, 11 Jul 2010 10:08:01 -0700 (PDT) Received: from blu0-omc3-s35.blu0.hotmail.com (blu0-omc3-s35.blu0.hotmail.com [65.55.116.110]) by core3.amsl.com (Postfix) with ESMTP id EF9E03A69DD for ; Sun, 11 Jul 2010 10:08:00 -0700 (PDT) Received: from BLU137-W5 ([65.55.116.74]) by blu0-omc3-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Jul 2010 10:08:07 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_351cc191-ce3e-45dd-9cf4-6dd952cbdcae_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , Date: Sun, 11 Jul 2010 10:08:07 -0700 Importance: Normal In-Reply-To: <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jul 2010 17:08:07.0913 (UTC) FILETIME=[A230C590:01CB211B] Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 17:08:04 -0000 --_351cc191-ce3e-45dd-9cf4-6dd952cbdcae_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can't anyone advertise ownership of a given E.164 number=2C regardless of w= hether they actually own it or not? What happens if there are a large numb= er of bogus DHT entries? While the call to the original E.164 number won't= be delayed=2C won't there be additional processing required to figure out = what the valid mapping is? =20 Subject: RE: [dispatch] VIPR - proposed charter version 3 Date: Sun=2C 11 Jul 2010 11:52:56 -0500 From: maltarai@cisco.com To: bernard_aboba@hotmail.com=3B dispatch@ietf.org Bernard=2C=20 =20 I did not follow the scaling characteristics issue that you=20 are bringing up. In general only enterprises that advertised ownership=20 of the E.164 number will be validated against=2C not every E.164 number in= =20 the DHT.=20 Since the validation is not a part of call processing=2C some=20 delay is acceptable.=20 =20 Mo A From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Bernard=20 Aboba Sent: Saturday=2C July 10=2C 2010 5:22 PM To:=20 dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter=20 version 3 =20 Jonathan=20 said: =20 "Do=20 you argue that we should stop using these forward email routing checks in t= he=20 web?" =20 [BA] I don't think that the=20 security of return reachability is the issue=2C so much as the scaling=20 characteristics.=20 =20 In=20 this case=2C more than one mapping between an E.164 number and an email-sty= le URI=20 can be asserted.=20 =20 While invalid mappings will=20 presumably fail the test=2C the average number of tests that need to be per= formed=20 is N/2. =20 =20 As=20 N grows=2C the delay required to upgrade will grow linearly. =20 In=20 contrast=2C the Facetime approach (as I understand it) utilizes in-band=20 communication that yields a delay that cannot be influenced by outside part= ies.=20 = --_351cc191-ce3e-45dd-9cf4-6dd952cbdcae_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can't anyone advertise ownership of a given E.164 number=2C regardless of w= hether they actually own it or not? =3B What happens if there are a lar= ge number of bogus DHT entries? =3B While the call to the original E.16= 4 number won't be delayed=2C won't there be additional processing required = to figure out what the valid mapping is? =3B

Subject: RE: [dispatch] VIPR - proposed charter version 3
Date: Su= n=2C 11 Jul 2010 11:52:56 -0500
From: maltarai@cisco.com
To: bernard_= aboba@hotmail.com=3B dispatch@ietf.org

Bernard=2C
 =3B
I did not follow the scaling c= haracteristics issue that you=20 are bringing up. In general only enterprises that =3Badvertised =3B= ownership=20 of  =3Bthe E.164 number will be validated against=2C not every E.164 nu= mber in=20 the DHT.
Since the validation is not a = part of call processing=2C some=20 delay is acceptable.
 =3B
Mo A

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Saturday=2C July 10=2C 2010 5:22 PM
To:=20 dispatch@ietf.org
Subject: Re: [dispatch] VIPR - proposed charter= =20 version 3

 =3B

Jonathan=20 said:

 =3B

"Do=20 you argue that we should stop using these forward email routing checks in t= he=20 web?"

 =3B

[BA] I don't think that the=20 security of return reachability is the issue=2C so much as the scaling=20 characteristics.

 =3B

In=20 this case=2C more than one mapping between an E.164 number and an email-sty= le URI=20 can be asserted.

 =3B

While invalid mappings will=20 presumably fail the test=2C the average number of tests that need to be per= formed=20 is N/2. =3B

 =3B

As=20 N grows=2C the delay required to upgrade will grow linearly.

 =3B

In=20 contrast=2C the Facetime approach (as I understand it) utilizes in-band=20 communication that yields a delay that cannot be influenced by outside part= ies.=20

= --_351cc191-ce3e-45dd-9cf4-6dd952cbdcae_-- From maltarai@cisco.com Sun Jul 11 14:49:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19B5D3A686C for ; Sun, 11 Jul 2010 14:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sG51ojOw5wlP for ; Sun, 11 Jul 2010 14:49:26 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8EA563A6845 for ; Sun, 11 Jul 2010 14:49:25 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAN/ZOUytJV2Z/2dsb2JhbACBQpIMjHFxoVGZMIUnBIN7hn8 X-IronPort-AV: E=Sophos;i="4.55,184,1278288000"; d="scan'208,217";a="131107384" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-1.cisco.com with ESMTP; 11 Jul 2010 21:49:31 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o6BLnVtx007511; Sun, 11 Jul 2010 21:49:31 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Jul 2010 16:49:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2142.F164A850" Date: Sun, 11 Jul 2010 16:49:26 -0500 Message-ID: <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 3 Thread-Index: AcshG6MmP/pTmA3aRbWGtycyZPsZHQAJb3WA References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> From: "Mohammad Al-Taraireh (maltarai)" To: "Bernard Aboba" , X-OriginalArrivalTime: 11 Jul 2010 21:49:31.0470 (UTC) FILETIME=[F1931EE0:01CB2142] Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Jul 2010 21:49:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2142.F164A850 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 That is correct, however, the protocol, or even the implementation needs to be designed to handle such cases, no point of implementing a system that spend all of its processing power trying to validate a number. There are different ways to handle something like this, for example the application could potentially stop the validation, and just mark that E.164 as "Dirty" and not try to validate it again without an administrator intervention. I am sure there are many ways to handle something like this, of course at a cost of this E.164 won't be learned as proposed in the protocol today, but I guess this is why we need this to be something the IETF adopt, and carry forward. =20 Thanks, =20 Mo A ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Sunday, July 11, 2010 1:08 PM To: Mohammad Al-Taraireh (maltarai); dispatch@ietf.org Subject: RE: [dispatch] VIPR - proposed charter version 3 Can't anyone advertise ownership of a given E.164 number, regardless of whether they actually own it or not? What happens if there are a large number of bogus DHT entries? While the call to the original E.164 number won't be delayed, won't there be additional processing required to figure out what the valid mapping is? =20 ________________________________ Subject: RE: [dispatch] VIPR - proposed charter version 3 Date: Sun, 11 Jul 2010 11:52:56 -0500 From: maltarai@cisco.com To: bernard_aboba@hotmail.com; dispatch@ietf.org Bernard,=20 =20 I did not follow the scaling characteristics issue that you are bringing up. In general only enterprises that advertised ownership of the E.164 number will be validated against, not every E.164 number in the DHT.=20 Since the validation is not a part of call processing, some delay is acceptable.=20 =20 Mo A ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Saturday, July 10, 2010 5:22 PM To: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 3 =20 Jonathan said: =20 "Do you argue that we should stop using these forward email routing checks in the web?" =20 [BA] I don't think that the security of return reachability is the issue, so much as the scaling characteristics.=20 =20 In this case, more than one mapping between an E.164 number and an email-style URI can be asserted.=20 =20 While invalid mappings will presumably fail the test, the average number of tests that need to be performed is N/2. =20 =20 As N grows, the delay required to upgrade will grow linearly. =20 In contrast, the Facetime approach (as I understand it) utilizes in-band communication that yields a delay that cannot be influenced by outside parties.=20 ------_=_NextPart_001_01CB2142.F164A850 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
That is correct, however, the protocol, or even = the=20 implementation needs to be designed to handle such cases, no point = of=20 implementing a system that spend all of its processing power trying to = validate=20 a number. There are different ways to handle something like this, = for=20 example the application could potentially stop the validation, and just = mark=20 that E.164 as "Dirty" and not try to validate it again without an=20 administrator intervention. I am sure there are many ways to = handle=20 something like this, of course at a cost of this E.164 won't be learned = as=20 proposed in the protocol today, but I guess this is why we need this to = be=20 something the IETF adopt, and carry forward.
 
Thanks,
 
Mo A

From: Bernard Aboba = [mailto:bernard_aboba@hotmail.com]=20
Sent: Sunday, July 11, 2010 1:08 PM
To: Mohammad=20 Al-Taraireh (maltarai); dispatch@ietf.org
Subject: RE: = [dispatch] VIPR=20 - proposed charter version 3

Can't anyone advertise ownership of a given E.164 number, = regardless=20 of whether they actually own it or not?  What happens if there are = a large=20 number of bogus DHT entries?  While the call to the original E.164 = number=20 won't be delayed, won't there be additional processing required to = figure out=20 what the valid mapping is? 

Subject: RE: [dispatch] VIPR - proposed charter version 3
Date: Sun, = 11 Jul=20 2010 11:52:56 -0500
From: maltarai@cisco.com
To:=20 bernard_aboba@hotmail.com; dispatch@ietf.org

Bernard,
 
I did not follow the scaling characteristics issue that you = are=20 bringing up. In general only enterprises = that advertised ownership of=20  the E.164 number will be validated against, not every E.164 number = in the=20 DHT.
Since the validation is not a part of call processing, some = delay is=20 acceptable.
 
Mo A

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Saturday, July 10, 2010 5:22 PM
To:=20 dispatch@ietf.org
Subject: Re: [dispatch] VIPR - proposed = charter=20 version 3

 

Jonathan = said:

 

"Do you argue that = we should=20 stop using these forward email routing checks in the web?"

 

[BA] I don't think = that the=20 security of return reachability is the issue, so much as the scaling=20 characteristics.

 

In this case, more = than one=20 mapping between an E.164 number and an email-style URI can be asserted.=20

 

While invalid = mappings will=20 presumably fail the test, the average number of tests that need to be = performed=20 is N/2. 

 

As N grows, the = delay=20 required to upgrade will grow linearly.

 

In contrast, the = Facetime=20 approach (as I understand it) utilizes in-band communication that yields = a delay=20 that cannot be influenced by outside parties. =

------_=_NextPart_001_01CB2142.F164A850-- From john.elwell@siemens-enterprise.com Sun Jul 11 23:18:46 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B873A3A6A30 for ; Sun, 11 Jul 2010 23:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knUMbejkPD2b for ; Sun, 11 Jul 2010 23:18:45 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C709C3A67C2 for ; Sun, 11 Jul 2010 23:18:44 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-816896; Mon, 12 Jul 2010 08:18:47 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 5310E23F0278; Mon, 12 Jul 2010 08:18:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 12 Jul 2010 08:18:47 +0200 From: "Elwell, John" To: Cullen Jennings Date: Mon, 12 Jul 2010 08:18:44 +0200 Thread-Topic: [dispatch] I-D Action:draft-jennings-dispatch-npa-00.txt Thread-Index: AcsfsiJfwUbW39JfRlWAl8ml8b5IEwB12s4w Message-ID: References: <20100705160001.9CA5A3A6890@core3.amsl.com> <7872E6AE-BDE8-4A19-B3A3-02E6C9401C7A@cisco.com> In-Reply-To: <7872E6AE-BDE8-4A19-B3A3-02E6C9401C7A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-jennings-dispatch-npa-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 06:18:46 -0000 Cullen, My concern with the first option was simply that a small number of PANxxx v= alues might already be taken for other purposes. But I agree this could be = mitigated by using a more obscure fixed string than simply "PAN" and by hav= ing a reasonable minimal length for xxx. So probably the first option is th= e best. John > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 09 July 2010 23:00 > To: Elwell, John > Cc: dispatch@ietf.org > Subject: Re: [dispatch] I-D Action:draft-jennings-dispatch-npa-00.txt >=20 >=20 > On Jul 9, 2010, at 3:09 AM, Elwell, John wrote: >=20 > > 1.1 Simple Single TLD. This would presumably involve=20 > reserving PANxxx (where xxx is a digit string of a certain=20 > length or range of lengths), and would be a problem if any=20 > such value has already been taken. >=20 >=20 > can you say a bit more about what you see as the problem - my=20 > thinking is roughly the following. If 123 is already taken by=20 > someone else, then it is taken - it does not matter if we use=20 > sipforum or .net as the registry. Now if you are concerned=20 > that pan123.net might be taken for some other use than the=20 > purpose of the PAN draft, then we could make the string you=20 > prepend be pan-z9hG4bK and that problem more or less goes=20 > away. You could argue that .net domains are so cheap that=20 > someone might just go get all of them. This seems like a=20 > pretty unlikely attack but that is why the xxx has a minimum=20 > length so the number they needed to get was large. Also it=20 > may have a minimum length but it's not fixed length so people=20 > can go to a domain with a longer string.=20 >=20 > I'm just not really seeing how this is all that much=20 > different if we have the domain that looks like=20 > 123.sipforum.net or a string that looks like 123sipforum.net=20 > - the size of the address space is about the same either way.=20 >=20 > And I pretty much agree with your comments on the other the=20 > other ones - we could probably find ways to solve some of=20 > theses but 2,3,4 are at some level just optimization of 1 so=20 > if there is some fundamental problem with 1, it probably=20 > impacts all of them. =20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > = From richard@shockey.us Mon Jul 12 06:34:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756C23A67DB for ; Mon, 12 Jul 2010 06:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=0.689, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kv-SQ7xy0WFj for ; Mon, 12 Jul 2010 06:34:37 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 8B42D3A6891 for ; Mon, 12 Jul 2010 06:34:37 -0700 (PDT) Received: (qmail 29079 invoked by uid 0); 12 Jul 2010 13:34:45 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 12 Jul 2010 13:34:45 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=Gkd4DICBmLc1ltwt5ZdPq4hSZzecMYxwy1ovYNg+a0324GEB+f6iC+pyjPBXyGFoA7x7Oe2xriW/o/9+Ra5RWgIEQupGq7K1YI9XPQ/SSGYM+9wXWJl9WdFVn/Wo92rl; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OYJ9g-0006kX-T3; Mon, 12 Jul 2010 07:34:45 -0600 From: "Richard Shockey" To: "'Mohammad Al-Taraireh \(maltarai\)'" , "'Bernard Aboba'" , References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com> In-Reply-To: <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com> Date: Mon, 12 Jul 2010 09:34:44 -0400 Message-ID: <002f01cb21c6$fdc3f430$f94bdc90$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01CB21A5.76B25430" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcshG6MmP/pTmA3aRbWGtycyZPsZHQAJb3WAACElcRA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 13:34:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0030_01CB21A5.76B25430 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Well again given these facts and several others the charter has to be substantially rewritten for it to stand a reasonable chance of approval. Though the exception cases will make for interesting reading in the security considerations, should the discussion go that far. Well I'll love to see how you will prevent someone from falsely asserting "ownership" of +1 202 456 1414 or what would happen if some did. From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mohammad Al-Taraireh (maltarai) Sent: Sunday, July 11, 2010 5:49 PM To: Bernard Aboba; dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 3 That is correct, however, the protocol, or even the implementation needs to be designed to handle such cases, no point of implementing a system that spend all of its processing power trying to validate a number. There are different ways to handle something like this, for example the application could potentially stop the validation, and just mark that E.164 as "Dirty" and not try to validate it again without an administrator intervention. I am sure there are many ways to handle something like this, of course at a cost of this E.164 won't be learned as proposed in the protocol today, but I guess this is why we need this to be something the IETF adopt, and carry forward. Thanks, Mo A _____ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Sunday, July 11, 2010 1:08 PM To: Mohammad Al-Taraireh (maltarai); dispatch@ietf.org Subject: RE: [dispatch] VIPR - proposed charter version 3 Can't anyone advertise ownership of a given E.164 number, regardless of whether they actually own it or not? What happens if there are a large number of bogus DHT entries? While the call to the original E.164 number won't be delayed, won't there be additional processing required to figure out what the valid mapping is? _____ Subject: RE: [dispatch] VIPR - proposed charter version 3 Date: Sun, 11 Jul 2010 11:52:56 -0500 From: maltarai@cisco.com To: bernard_aboba@hotmail.com; dispatch@ietf.org Bernard, I did not follow the scaling characteristics issue that you are bringing up. In general only enterprises that advertised ownership of the E.164 number will be validated against, not every E.164 number in the DHT. Since the validation is not a part of call processing, some delay is acceptable. Mo A _____ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Saturday, July 10, 2010 5:22 PM To: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 3 Jonathan said: "Do you argue that we should stop using these forward email routing checks in the web?" [BA] I don't think that the security of return reachability is the issue, so much as the scaling characteristics. In this case, more than one mapping between an E.164 number and an email-style URI can be asserted. While invalid mappings will presumably fail the test, the average number of tests that need to be performed is N/2. As N grows, the delay required to upgrade will grow linearly. In contrast, the Facetime approach (as I understand it) utilizes in-band communication that yields a delay that cannot be influenced by outside parties. ------=_NextPart_000_0030_01CB21A5.76B25430 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well again given these facts and several others the = charter has to be substantially rewritten for it to stand a reasonable chance of = approval. Though the exception cases will make for interesting reading in the = security considerations, should the discussion go that far.

 

Well I’ll love to see how you will prevent someone = from falsely asserting “ownership” of +1 202 456 1414 or what would = happen if some did.

 

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Mohammad Al-Taraireh (maltarai)
Sent: Sunday, July 11, 2010 5:49 PM
To: Bernard Aboba; dispatch@ietf.org
Subject: Re: [dispatch] VIPR - proposed charter version = 3

 

 =

That is correct, however, the protocol, or even = the implementation needs to be designed to handle such cases, no point = of implementing a system that spend all of its processing power trying to = validate a number. There are different ways to handle something like this, = for example the application could potentially stop the validation, and just = mark that E.164 as "Dirty" and not try to validate it again = without an administrator intervention. I am sure there are many ways = to handle something like this, of course at a cost of this E.164 won't be = learned as proposed in the protocol today, but I guess this is why we need this = to be something the IETF adopt, and carry forward.

 =

Thanks,=

 =

Mo A=

 =

From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Sunday, July 11, 2010 1:08 PM
To: Mohammad Al-Taraireh (maltarai); dispatch@ietf.org
Subject: RE: [dispatch] VIPR - proposed charter version = 3=

Can't anyone advertise ownership of = a given E.164 number, regardless of whether they actually own it or not?  = What happens if there are a large number of bogus DHT entries?  While = the call to the original E.164 number won't be delayed, won't there be additional processing required to figure out what the valid mapping is?  =

Subject: RE: [dispatch] VIPR - = proposed charter version 3
Date: Sun, 11 Jul 2010 11:52:56 -0500
From: maltarai@cisco.com
To: bernard_aboba@hotmail.com; dispatch@ietf.org

Bernard, = =

 =

I did not follow the = scaling characteristics issue that you are bringing up. In general only = enterprises that advertised ownership of  the E.164 number will be = validated against, not every E.164 number in the DHT. =

Since the validation = is not a part of call processing, some delay is acceptable. =

 =

Mo = A=

 =

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Saturday, July 10, 2010 5:22 PM
To: dispatch@ietf.org
Subject: Re: [dispatch] VIPR - proposed charter version = 3=

 =

Jonathan said:=

 =

"Do you argue that we should stop using these forward email routing checks = in the web?"=

 =

[BA] I don't think that the security of return reachability is the issue, so = much as the scaling characteristics.

 =

In this case, more than one mapping between an E.164 number and an = email-style URI can be asserted. =

 =

While invalid mappings will presumably fail the test, the average number of = tests that need to be performed is N/2. 

 =

As N grows, the delay required to upgrade will grow linearly.=

 =

In contrast, the Facetime approach (as I understand it) utilizes in-band communication that yields a delay that cannot be influenced by outside = parties. =

------=_NextPart_000_0030_01CB21A5.76B25430-- From bernard_aboba@hotmail.com Mon Jul 12 07:09:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4891B3A681E for ; Mon, 12 Jul 2010 07:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.135 X-Spam-Level: X-Spam-Status: No, score=-0.135 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtTRzp6CN5eV for ; Mon, 12 Jul 2010 07:09:32 -0700 (PDT) Received: from blu0-omc3-s19.blu0.hotmail.com (blu0-omc3-s19.blu0.hotmail.com [65.55.116.94]) by core3.amsl.com (Postfix) with ESMTP id 633343A67B4 for ; Mon, 12 Jul 2010 07:09:32 -0700 (PDT) Received: from BLU137-W32 ([65.55.116.74]) by blu0-omc3-s19.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 07:09:40 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_bc3597e8-5711-4a9a-8e27-777590bf239f_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , , Date: Mon, 12 Jul 2010 07:09:40 -0700 Importance: Normal In-Reply-To: <002f01cb21c6$fdc3f430$f94bdc90$@us> References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jul 2010 14:09:40.0031 (UTC) FILETIME=[DE3564F0:01CB21CB] Subject: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 14:09:33 -0000 --_bc3597e8-5711-4a9a-8e27-777590bf239f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It strikes me that there are a number of closely related problems here: a. One problem is the need to be able to "upgrade" an audio call in progres= s in order to provide for additional media=2C even if the call had been com= pleted over the PSTN so that there was no SDP offer/answer negotiation betw= een the end-points. This is the problem that Facetime solves=2C for exampl= e.=20 b. Another problem is the need for a public ENUM replacement. =20 In the process of solving problem a=2C we might also need to solve problem = b=2C but that depends on the approach that is taken=3B not all potential s= olutions to problem a will also have to solve problem b.=20 Currently the charter is focused on problem b. If the real goal is to solv= e problem a=2C then this charter is not very helpful.=20 = --_bc3597e8-5711-4a9a-8e27-777590bf239f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It strikes me that there are a number of closely related problems here:
=
a. One problem is the need to be able to "upgrade" an audio call in pro= gress in order to provide for additional media=2C even if the call had been= completed over the PSTN so that there was no SDP offer/answer negotiation = between the end-points. =3B This is the problem that Facetime solves=2C= for example.

b. Another problem is the need for a public ENUM repl= acement. =3B

In the process of solving problem a=2C we might al= so need to solve problem b=2C but that depends on the approach that is take= n=3B =3B not all potential solutions to problem a will also have to sol= ve problem b.

Currently the charter is focused on problem b. = =3B If the real goal is to solve problem a=2C then this charter is not very= helpful. =
= --_bc3597e8-5711-4a9a-8e27-777590bf239f_-- From maltarai@cisco.com Mon Jul 12 07:19:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7700C3A6927 for ; Mon, 12 Jul 2010 07:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FVw+ZqMyI8N for ; Mon, 12 Jul 2010 07:18:53 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 651CF3A68E9 for ; Mon, 12 Jul 2010 07:18:52 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFALrAOkytJV2a/2dsb2JhbACBQ5IJjHJxpDeaQ4J6gi0Eg3uGfw X-IronPort-AV: E=Sophos;i="4.55,188,1278288000"; d="scan'208,217";a="131349087" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2010 14:18:56 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o6CEIuB5006439; Mon, 12 Jul 2010 14:18:56 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 09:18:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB21CD.299C7270" Date: Mon, 12 Jul 2010 09:18:53 -0500 Message-ID: <04CA7DCC63584C4D8967FF818D80965B01BB89DA@XMB-RCD-113.cisco.com> In-Reply-To: <002f01cb21c6$fdc3f430$f94bdc90$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 3 Thread-Index: AcshG6MmP/pTmA3aRbWGtycyZPsZHQAJb3WAACElcRAAAWxl8A== References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com> <002f01cb21c6$fdc3f430$f94bdc90$@us> From: "Mohammad Al-Taraireh (maltarai)" To: "Richard Shockey" , "Bernard Aboba" , X-OriginalArrivalTime: 12 Jul 2010 14:18:56.0151 (UTC) FILETIME=[29AE9270:01CB21CD] Subject: Re: [dispatch] VIPR - proposed charter version 3 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 14:19:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB21CD.299C7270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the current model you can not prevent anyone from falsely claiming the "ownership" of a specific number, however, that does not mean the validation will happen just because someone claim ownership, the validation process to learn a specific route is dependant on the PSTN call that must take place to that number before the validation even is triggered.=20 =20 I can not remember why the protocol suggested to publish the +E.164 representation in the DHT before hand, versus publish in the DHT the VCR record (hash value of the (E.164+startTime+StopTime with some delta of time to allow of some error margin in timing sync) of the pstn call. This way validation will only happen to the node in the DHT that claim knowledge of the pstn call.=20 =20 Mo A =20 =20 ________________________________ From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: Monday, July 12, 2010 9:35 AM To: Mohammad Al-Taraireh (maltarai); 'Bernard Aboba'; dispatch@ietf.org Subject: RE: [dispatch] VIPR - proposed charter version 3 Well again given these facts and several others the charter has to be substantially rewritten for it to stand a reasonable chance of approval. Though the exception cases will make for interesting reading in the security considerations, should the discussion go that far. =20 Well I'll love to see how you will prevent someone from falsely asserting "ownership" of +1 202 456 1414 or what would happen if some did. =20 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mohammad Al-Taraireh (maltarai) Sent: Sunday, July 11, 2010 5:49 PM To: Bernard Aboba; dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 3 =20 =20 That is correct, however, the protocol, or even the implementation needs to be designed to handle such cases, no point of implementing a system that spend all of its processing power trying to validate a number. There are different ways to handle something like this, for example the application could potentially stop the validation, and just mark that E.164 as "Dirty" and not try to validate it again without an administrator intervention. I am sure there are many ways to handle something like this, of course at a cost of this E.164 won't be learned as proposed in the protocol today, but I guess this is why we need this to be something the IETF adopt, and carry forward. =20 Thanks, =20 Mo A =20 ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Sunday, July 11, 2010 1:08 PM To: Mohammad Al-Taraireh (maltarai); dispatch@ietf.org Subject: RE: [dispatch] VIPR - proposed charter version 3 Can't anyone advertise ownership of a given E.164 number, regardless of whether they actually own it or not? What happens if there are a large number of bogus DHT entries? While the call to the original E.164 number won't be delayed, won't there be additional processing required to figure out what the valid mapping is? =20 ________________________________ Subject: RE: [dispatch] VIPR - proposed charter version 3 Date: Sun, 11 Jul 2010 11:52:56 -0500 From: maltarai@cisco.com To: bernard_aboba@hotmail.com; dispatch@ietf.org Bernard,=20 =20 I did not follow the scaling characteristics issue that you are bringing up. In general only enterprises that advertised ownership of the E.164 number will be validated against, not every E.164 number in the DHT.=20 Since the validation is not a part of call processing, some delay is acceptable.=20 =20 Mo A =20 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Saturday, July 10, 2010 5:22 PM To: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 3 =20 Jonathan said: =20 "Do you argue that we should stop using these forward email routing checks in the web?" =20 [BA] I don't think that the security of return reachability is the issue, so much as the scaling characteristics.=20 =20 In this case, more than one mapping between an E.164 number and an email-style URI can be asserted.=20 =20 While invalid mappings will presumably fail the test, the average number of tests that need to be performed is N/2. =20 =20 As N grows, the delay required to upgrade will grow linearly. =20 In contrast, the Facetime approach (as I understand it) utilizes in-band communication that yields a delay that cannot be influenced by outside parties.=20 ------_=_NextPart_001_01CB21CD.299C7270 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In the current model you can not prevent anyone = from falsely=20 claiming the "ownership" of a specific number, however, that does = not mean=20 the validation will happen just because someone claim ownership, the = validation=20 process to learn a specific route is dependant on the PSTN call that = must take=20 place to that number before the validation even is triggered.=20
 
I can not remember why the protocol suggested to = publish the=20 +E.164 representation in the DHT before hand, versus publish in the = DHT the=20 VCR record (hash value of the (E.164+startTime+StopTime with some delta = of time=20 to allow of some error margin in timing sync) of the pstn call. This way = validation will only happen to the node in the DHT that claim knowledge = of the=20 pstn call.
 
Mo A
 
 

From: Richard Shockey=20 [mailto:richard@shockey.us]
Sent: Monday, July 12, 2010 9:35=20 AM
To: Mohammad Al-Taraireh (maltarai); 'Bernard Aboba';=20 dispatch@ietf.org
Subject: RE: [dispatch] VIPR - proposed = charter=20 version 3

Well=20 again given these facts and several others the charter has to be = substantially=20 rewritten for it to stand a reasonable chance of approval. Though the = exception=20 cases will make for interesting reading in the security considerations, = should=20 the discussion go that far.

 

Well=20 I’ll love to see how you will prevent someone from falsely = asserting “ownership”=20 of +1 202 456 1414 or what would happen if some = did.

 

From:=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of=20 Mohammad Al-Taraireh (maltarai)
Sent: Sunday, July 11, = 2010 5:49=20 PM
To: Bernard Aboba; dispatch@ietf.org
Subject: Re: = [dispatch] VIPR - proposed charter version = 3

 

 

That is=20 correct, however, the protocol, or even the implementation = needs to be=20 designed to handle such cases, no point of implementing a system = that spend=20 all of its processing power trying to validate a number. There are=20 different ways to handle something like this, for example the = application could=20 potentially stop the validation, and just mark that E.164 as "Dirty" and = not try=20 to validate it again without an administrator intervention. I = am sure=20 there are many ways to handle something like this, of course at a = cost of=20 this E.164 won't be learned as proposed in the protocol today, but I = guess this=20 is why we need this to be something the IETF adopt, and carry=20 forward.

 

Thanks,

 

Mo=20 A

 

From: Bernard = Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: Sunday, July 11, = 2010 1:08=20 PM
To: Mohammad Al-Taraireh (maltarai);=20 dispatch@ietf.org
Subject: RE: [dispatch] VIPR - proposed = charter=20 version 3

Can't = anyone=20 advertise ownership of a given E.164 number, regardless of whether they = actually=20 own it or not?  What happens if there are a large number of bogus = DHT=20 entries?  While the call to the original E.164 number won't be = delayed,=20 won't there be additional processing required to figure out what the = valid=20 mapping is? 

Subject: = RE:=20 [dispatch] VIPR - proposed charter version 3
Date: Sun, 11 Jul 2010 = 11:52:56=20 -0500
From: maltarai@cisco.com
To: bernard_aboba@hotmail.com;=20 dispatch@ietf.org

Bernard,=20

 

I did=20 not follow the scaling characteristics issue that you are bringing up. = In=20 general only enterprises that advertised ownership of =  the E.164=20 number will be validated against, not every E.164 number in the DHT.=20

Since=20 the validation is not a part of call processing, some delay is = acceptable.=20

 

Mo=20 A

 

From:=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of=20 Bernard Aboba
Sent: Saturday, July 10, 2010 5:22 = PM
To:=20 dispatch@ietf.org
Subject: Re: [dispatch] VIPR - proposed = charter=20 version 3

 

Jonathan = said:

 

"Do=20 you argue that we should stop using these forward email routing checks = in the=20 web?"

 

[BA] I don't think = that the=20 security of return reachability is the issue, so much as the scaling=20 characteristics.

 

In=20 this case, more than one mapping between an E.164 number and an = email-style URI=20 can be asserted.

 

While invalid = mappings will=20 presumably fail the test, the average number of tests that need to be = performed=20 is N/2. 

 

As=20 N grows, the delay required to upgrade will grow linearly.

 

In=20 contrast, the Facetime approach (as I understand it) utilizes in-band=20 communication that yields a delay that cannot be influenced by outside = parties.=20

------_=_NextPart_001_01CB21CD.299C7270-- From laura.liess.dt@googlemail.com Mon Jul 12 08:37:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210143A6B67 for ; Mon, 12 Jul 2010 08:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qmlAkUmRO4LB for ; Mon, 12 Jul 2010 08:37:07 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B3B443A6B54 for ; Mon, 12 Jul 2010 08:35:06 -0700 (PDT) Received: by wwi17 with SMTP id 17so116649wwi.13 for ; Mon, 12 Jul 2010 08:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IRo3FAfcFzbabf0wag/cdVpvymKt01tmnA7CRFu6nD0=; b=MEsiF7BXgmpVqdqee1jWLF+rk6Ml6pYcIbvE9SYjqJ4NUWWbJzgec9KrKUVz1lztub P8zH16RIi9w8tlReAKGXtTaVfJmh2IEnHDmMrQ29+BDi8GmBScAfnHoZkF6pb3LSYpqa FXdb7+52CsHEf4TFiy8pzVSSWQVh8WbrlqzUk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NtZUBdciQHMqo7J4QzKwItKvX20t8DgPylbI5ZRS/0AcXg8pSiUIhFO5udLGlDaV8W uEK+QgQqn0tFXzOnHhqQyFMEe2mxBAC0OT/mKQbqkdr7htzUzd1hmocZ3cErlxhTnd9u 0VQYU0PuvDWLNO2uaKm5NAuZvQYHL8VHaaDMg= MIME-Version: 1.0 Received: by 10.227.132.139 with SMTP id b11mr12702402wbt.158.1278948801632; Mon, 12 Jul 2010 08:33:21 -0700 (PDT) Received: by 10.216.139.99 with HTTP; Mon, 12 Jul 2010 08:33:21 -0700 (PDT) In-Reply-To: <4C373953.3000402@cisco.com> References: <4C29D2E4.5080203@ericsson.com> <9ECCF01B52E7AB408A7EB85352642141019FA694@ftrdmel0.rd.francetelecom.fr> <4C2A2C19.1030906@cisco.com> <4C2AE94C.4020707@ericsson.com> <617DF0128820F9458AC39149A627EE6C01A66BC2A7@MBX.dialogic.com> <4C2B8ACE.3050301@cisco.com> <2A1051E9-99DC-458C-B96B-0BE7FB4CD4C1@cisco.com> <4C373953.3000402@cisco.com> Date: Mon, 12 Jul 2010 17:33:21 +0200 Message-ID: From: Laura Liess To: Paul Kyzivat , Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" , James Rafferty , Roland Jesske Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 15:37:08 -0000 Paul, Cullen, 2010/7/9 Paul Kyzivat : > > > Laura Liess wrote: > >> Is it so easy to instruct a proxy to >> inspect the body and eventually throw away a part of it? And should >> one do that? > > While a proxy may inspect a body (if its not encrypted), > by definition a proxy may not modify or remove a body. This was my opinion, too. This is how we specified our S-CSCF to behave. But I was a little confused .... On the other side, I can understand Cullen's position and that he is worried that people will use it for everything. In our network, we try to use UUI only when necessary, not for every piece of information we need to transport between different application servers. For most of these cases we use the body. If we would allow UUI, would it help to put a strong recommendation in the draft that people should not use UUI when there is no need that proxies remove the piece of information from the message? I think most people will follow it. Thanks a lot Laura > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > From maltarai@cisco.com Mon Jul 12 08:37:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A74D3A6B69 for ; Mon, 12 Jul 2010 08:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+hTKgqDmhGI for ; Mon, 12 Jul 2010 08:37:09 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C44603A6B4A for ; Mon, 12 Jul 2010 08:35:54 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAHvTOkytJV2c/2dsb2JhbACBQ5IJjHRxpRiaTIUnBIN7hn8 X-IronPort-AV: E=Sophos;i="4.55,188,1278288000"; d="scan'208,217";a="131383551" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2010 15:34:48 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o6CFYmvZ002629; Mon, 12 Jul 2010 15:34:48 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 10:34:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB21D7.C294B990" Date: Mon, 12 Jul 2010 10:34:42 -0500 Message-ID: <04CA7DCC63584C4D8967FF818D80965B01BB8ABC@XMB-RCD-113.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VIPR - proposed charter version 4 Thread-Index: Acshy9+O861u/OjSS7SBx6qmu99gZQABJUGg References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> From: "Mohammad Al-Taraireh (maltarai)" To: "Bernard Aboba" , , X-OriginalArrivalTime: 12 Jul 2010 15:34:48.0019 (UTC) FILETIME=[C2CE8230:01CB21D7] Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 15:37:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB21D7.C294B990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see inline: ________________________________ From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Monday, July 12, 2010 10:10 AM To: richard@shockey.us; Mohammad Al-Taraireh (maltarai); dispatch@ietf.org Subject: VIPR - proposed charter version 4 It strikes me that there are a number of closely related problems here: a. One problem is the need to be able to "upgrade" an audio call in progress in order to provide for additional media, even if the call had been completed over the PSTN so that there was no SDP offer/answer negotiation between the end-points. This is the problem that Facetime solves, for example. =20 =20 Mo A>> The only way I see this issue related to ViPR, is to have a capability in the validation protocol to allow learning the route to happen fast enough during an active call, to allow the escalation to other media types. I don't think the protocol as it is today preclude this from working this way. It is up to the SIP UA to be able to use the learn route during the active session to a specific DID to change the media type, and the session. This is of course already supported in SIP, and SDP.=20 =20 In fact we will need something standardized like "ViPR" to get Facetime like functionality to work with for none vender specific devices/implementation.=20 b. Another problem is the need for a public ENUM replacement. =20 In the process of solving problem a, we might also need to solve problem b, but that depends on the approach that is taken; not all potential solutions to problem a will also have to solve problem b. =20 =20 Mo>> As the charter written today, ViPR is not intended to replace ENUM. It surely can work without it, but can also work if ENUM is in use (numbers that are not in ENUM, can use ViPR).=20 =20 MoA=20 Currently the charter is focused on problem b. If the real goal is to solve problem a, then this charter is not very helpful.=20 ------_=_NextPart_001_01CB21D7.C294B990 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please see inline:

From: Bernard Aboba = [mailto:bernard_aboba@hotmail.com]=20
Sent: Monday, July 12, 2010 10:10 AM
To:=20 richard@shockey.us; Mohammad Al-Taraireh (maltarai);=20 dispatch@ietf.org
Subject: VIPR - proposed charter version=20 4

It strikes me that there are a number of closely related problems=20 here:

a. One problem is the need to be able to "upgrade" an audio = call in=20 progress in order to provide for additional media, even if the call had = been=20 completed over the PSTN so that there was no SDP offer/answer = negotiation=20 between the end-points.  This is the problem that Facetime solves, = for=20 example.  
 
Mo=20 A>> The only way I see this issue related to ViPR, is to have = a=20 capability in the validation protocol to allow learning the route=20 to happen fast enough during an active call, to allow the=20 escalation to other media types. I don't think the protocol as it = is today=20 preclude this from working this way. It is up to the SIP UA to be able = to use=20 the learn route during the active session to a specific DID to = change the=20 media type, and the session. This is of course already supported in SIP, = and=20 SDP.
 
In fact we=20 will need something standardized like "ViPR" to get Facetime like = functionality=20 to work with for none vender=20 specific devices/implementation. 

b. = Another=20 problem is the need for a public ENUM replacement. 

In the = process=20 of solving problem a, we might also need to solve problem b, but that = depends on=20 the approach that is taken;  not all potential solutions to problem = a will=20 also have to solve problem b.  
 
Mo>> As=20 the charter written today, ViPR is not intended to replace ENUM. It = surely can=20 work without it, but can also work if ENUM is in use (numbers that = are not=20 in ENUM, can use ViPR). 
 
MoA 

Currently the charter is = focused on=20 problem b.  If the real goal is to solve problem a, then this = charter is=20 not very helpful.
------_=_NextPart_001_01CB21D7.C294B990-- From richard@shockey.us Mon Jul 12 09:03:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 086F23A699D for ; Mon, 12 Jul 2010 09:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.849 X-Spam-Level: X-Spam-Status: No, score=-0.849 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCA-uc3cpaD9 for ; Mon, 12 Jul 2010 09:03:28 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 953903A68AF for ; Mon, 12 Jul 2010 09:03:27 -0700 (PDT) Received: (qmail 5618 invoked by uid 0); 12 Jul 2010 16:03:35 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 12 Jul 2010 16:03:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=MBKQ5Bo06SlMzTGmJa7/DhfthVxIIPhVyywp3WZvQRyGI7I/LVok6cFp+kRBh50bY/BcbqKdPX6lgyUZCZuKjuA3Eyxb34frjWLf/pYPeK6tKe7XS1y8WGFQzY3fqvXk; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OYLTi-000495-Jx; Mon, 12 Jul 2010 10:03:35 -0600 From: "Richard Shockey" To: "'Mohammad Al-Taraireh \(maltarai\)'" , "'Bernard Aboba'" , References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <04CA7DCC63584C4D8967FF818D80965B01BB8ABC@XMB-RCD-113.cisco.com> In-Reply-To: <04CA7DCC63584C4D8967FF818D80965B01BB8ABC@XMB-RCD-113.cisco.com> Date: Mon, 12 Jul 2010 12:03:33 -0400 Message-ID: <012001cb21db$c83f7ef0$58be7cd0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0121_01CB21BA.412DDEF0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acshy9+O861u/OjSS7SBx6qmu99gZQABJUGgAAJt8dA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 16:03:35 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0121_01CB21BA.412DDEF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In line as well. a. One problem is the need to be able to "upgrade" an audio call in progress in order to provide for additional media, even if the call had been completed over the PSTN so that there was no SDP offer/answer negotiation between the end-points. This is the problem that Facetime solves, for example. Mo A>> The only way I see this issue related to ViPR, is to have a capability in the validation protocol to allow learning the route to happen fast enough during an active call, to allow the escalation to other media types. I don't think the protocol as it is today preclude this from working this way. It is up to the SIP UA to be able to use the learn route during the active session to a specific DID to change the media type, and the session. This is of course already supported in SIP, and SDP. In fact we will need something standardized like "ViPR" to get Facetime like functionality to work with for none vender specific devices/implementation. b. Another problem is the need for a public ENUM replacement. In the process of solving problem a, we might also need to solve problem b, but that depends on the approach that is taken; not all potential solutions to problem a will also have to solve problem b. Mo>> As the charter written today, ViPR is not intended to replace ENUM. It surely can work without it, but can also work if ENUM is in use (numbers that are not in ENUM, can use ViPR). RS> Lets just make it clear that if you are talking about "public" ENUM aka the RFC 3761 in the e164.arpa tree you are not replacing anything since it functionally does not exist except in a very few countries. However ENUM does work quite well and has substantial deployments where the centralized or distributed private DNS trees are controlled by the service providers who ARE in a position to validate and authenticate the TN's under their control. Of course it would be useful to admit the subtext of this entire discussion is enabling PSTN service provider bypass. A more useful WG name for this activity would be "bypass" or 'X-TPC" for "The Phone Company" and have Mr. Arlington Hewes as honorary co-chair. ------=_NextPart_000_0121_01CB21BA.412DDEF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In line as well.

 

a. One problem is the need to be able to "upgrade" an audio call = in progress in order to provide for additional media, even if the call had = been completed over the PSTN so that there was no SDP offer/answer = negotiation between the end-points.  This is the problem that Facetime solves, = for example.  =

 =

Mo A>> The only way I see this issue related to = ViPR, is to have a capability in the validation protocol to allow learning = the route to happen fast enough during an active call, to allow = the escalation to other media types. I don't think the protocol as it = is today preclude this from working this way. It is up to the SIP UA to be able = to use the learn route during the active session to a specific DID to = change the media type, and the session. This is of course already supported in SIP, = and SDP. =

 =

In fact we will need something standardized like = "ViPR" to get Facetime like functionality to work with for none vender specific devices/implementation. 

b. Another problem is the need for a public ENUM replacement. 

In the process of solving problem a, we might also need to solve problem = b, but that depends on the approach that is taken;  not all potential = solutions to problem a will also have to solve problem b. &n= bsp;=

 =

Mo>> As the charter written today, ViPR is not = intended to replace ENUM. It surely can work without it, but can also work if ENUM is in use (numbers that are not in ENUM, can use ViPR). 

 

 

RS> Lets just make it clear that if you are talking = about “public” ENUM aka the RFC 3761 in the e164.arpa tree you are not replacing = anything since it functionally does not exist except in a very few countries. = However ENUM does work quite well and has substantial deployments where the = centralized or distributed private DNS trees are controlled by the service providers = who ARE in a position to validate and authenticate the TN’s under their = control.  

Of course it would be useful to admit = the subtext of this entire discussion is enabling PSTN service provider = bypass.   A more useful WG name for this activity would be “bypass” or = ‘X-TPC”  for “The Phone Company”  and have Mr. Arlington Hewes = as honorary co-chair.

 

------=_NextPart_000_0121_01CB21BA.412DDEF0-- From maltarai@cisco.com Mon Jul 12 09:51:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B25F3A6A1C for ; Mon, 12 Jul 2010 09:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtgSHgNsC6ak for ; Mon, 12 Jul 2010 09:51:34 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id BC7CC3A69D8 for ; Mon, 12 Jul 2010 09:51:33 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8FAA7lOkytJV2Y/2dsb2JhbACBQ559caU5mliCVRCCQgSDe4Z/hzs X-IronPort-AV: E=Sophos;i="4.55,189,1278288000"; d="scan'208,217";a="131405639" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2010 16:32:07 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o6CGW7pM017217; Mon, 12 Jul 2010 16:32:07 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 11:32:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB21DF.C49F29F0" Date: Mon, 12 Jul 2010 11:32:04 -0500 Message-ID: <04CA7DCC63584C4D8967FF818D80965B01BB8B10@XMB-RCD-113.cisco.com> In-Reply-To: <012001cb21db$c83f7ef0$58be7cd0$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VIPR - proposed charter version 4 Thread-Index: Acshy9+O861u/OjSS7SBx6qmu99gZQABJUGgAAJt8dAAAUMc8A== References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <04CA7DCC63584C4D8967FF818D80965B01BB8ABC@XMB-RCD-113.cisco.com> <012001cb21db$c83f7ef0$58be7cd0$@us> From: "Mohammad Al-Taraireh (maltarai)" To: "Richard Shockey" , "Bernard Aboba" , X-OriginalArrivalTime: 12 Jul 2010 16:32:07.0318 (UTC) FILETIME=[C4C9E360:01CB21DF] Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 16:51:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB21DF.C49F29F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 The genuine intent behind ViPR is not to bypass the Service Providers, In my opinion the Service Providers have vested interest in this as well, and can leverage ViPR to work for them (front end numbers they own with ViPR) to offer enhanced services.=20 =20 My .2 c :-).=20 =20 Thanks, =20 Mo A ________________________________ From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: Monday, July 12, 2010 12:04 PM To: Mohammad Al-Taraireh (maltarai); 'Bernard Aboba'; dispatch@ietf.org Subject: RE: VIPR - proposed charter version 4 In line as well. =20 a. One problem is the need to be able to "upgrade" an audio call in progress in order to provide for additional media, even if the call had been completed over the PSTN so that there was no SDP offer/answer negotiation between the end-points. This is the problem that Facetime solves, for example. =20 =20 Mo A>> The only way I see this issue related to ViPR, is to have a capability in the validation protocol to allow learning the route to happen fast enough during an active call, to allow the escalation to other media types. I don't think the protocol as it is today preclude this from working this way. It is up to the SIP UA to be able to use the learn route during the active session to a specific DID to change the media type, and the session. This is of course already supported in SIP, and SDP.=20 =20 In fact we will need something standardized like "ViPR" to get Facetime like functionality to work with for none vender specific devices/implementation.=20 b. Another problem is the need for a public ENUM replacement. =20 In the process of solving problem a, we might also need to solve problem b, but that depends on the approach that is taken; not all potential solutions to problem a will also have to solve problem b. =20 =20 Mo>> As the charter written today, ViPR is not intended to replace ENUM. It surely can work without it, but can also work if ENUM is in use (numbers that are not in ENUM, can use ViPR).=20 =20 =20 RS> Lets just make it clear that if you are talking about "public" ENUM aka the RFC 3761 in the e164.arpa tree you are not replacing anything since it functionally does not exist except in a very few countries. However ENUM does work quite well and has substantial deployments where the centralized or distributed private DNS trees are controlled by the service providers who ARE in a position to validate and authenticate the TN's under their control. =20 Of course it would be useful to admit the subtext of this entire discussion is enabling PSTN service provider bypass. A more useful WG name for this activity would be "bypass" or 'X-TPC" for "The Phone Company" and have Mr. Arlington Hewes as honorary co-chair. =20 ------_=_NextPart_001_01CB21DF.C49F29F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
The genuine intent behind ViPR is=20 not  to bypass the Service Providers, In my opinion=20 the Service Providers have vested interest in this as well, = and can=20 leverage ViPR to work for them (front end numbers they own with ViPR) to = offer=20 enhanced services.
 
My .2 c :-).
 
Thanks,
 
Mo A

From: Richard Shockey=20 [mailto:richard@shockey.us]
Sent: Monday, July 12, 2010 12:04 = PM
To: Mohammad Al-Taraireh (maltarai); 'Bernard Aboba';=20 dispatch@ietf.org
Subject: RE: VIPR - proposed charter version = 4

In=20 line as well.

 

a. One = problem is=20 the need to be able to "upgrade" an audio call in progress in order to = provide=20 for additional media, even if the call had been completed over the PSTN = so that=20 there was no SDP offer/answer negotiation between the end-points.  = This is=20 the problem that Facetime solves, for example.  

 

Mo=20 A>> The only way I see this issue related to ViPR, is to have = a=20 capability in the validation protocol to allow learning the route=20 to happen fast enough during an active call, to allow the=20 escalation to other media types. I don't think the protocol as it = is today=20 preclude this from working this way. It is up to the SIP UA to be able = to use=20 the learn route during the active session to a specific DID to = change the=20 media type, and the session. This is of course already supported in SIP, = and=20 SDP.

 

In fact=20 we will need something standardized like "ViPR" to get Facetime like=20 functionality to work with for none vender=20 specific devices/implementation. 

b.=20 Another problem is the need for a public ENUM replacement.  =

In the=20 process of solving problem a, we might also need to solve problem b, but = that=20 depends on the approach that is taken;  not all potential solutions = to=20 problem a will also have to solve problem b.  

 

Mo>>=20 As the charter written today, ViPR is not intended to replace ENUM. It = surely=20 can work without it, but can also work if ENUM is in use = (numbers that are=20 not in ENUM, can use ViPR). 

 

 

RS>=20 Lets just make it clear that if you are talking about = “public” ENUM aka the RFC=20 3761 in the e164.arpa tree you are not replacing anything since it = functionally=20 does not exist except in a very few countries. However ENUM does work = quite well=20 and has substantial deployments where the centralized or distributed = private DNS=20 trees are controlled by the service providers who ARE in a position to = validate=20 and authenticate the TN’s under their control. =  

Of=20 course it would be useful to admit the subtext of this entire discussion = is=20 enabling PSTN service provider bypass.   A more useful WG name = for=20 this activity would be “bypass” or ‘X-TPC”  = for “The Phone Company”=20  and have Mr. Arlington Hewes as honorary co-chair.

 

------_=_NextPart_001_01CB21DF.C49F29F0-- From bernard_aboba@hotmail.com Mon Jul 12 09:57:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 004AE3A6A1C for ; Mon, 12 Jul 2010 09:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.105 X-Spam-Level: X-Spam-Status: No, score=-1.105 tagged_above=-999 required=5 tests=[AWL=1.493, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4phM8vlbxZb for ; Mon, 12 Jul 2010 09:57:51 -0700 (PDT) Received: from blu0-omc3-s30.blu0.hotmail.com (blu0-omc3-s30.blu0.hotmail.com [65.55.116.105]) by core3.amsl.com (Postfix) with ESMTP id 1A5E23A693F for ; Mon, 12 Jul 2010 09:57:51 -0700 (PDT) Received: from BLU137-W37 ([65.55.116.74]) by blu0-omc3-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 09:57:58 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_d790648f-a8dd-4376-aa82-10b2796a3817_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , , Date: Mon, 12 Jul 2010 09:57:58 -0700 Importance: Normal In-Reply-To: <012001cb21db$c83f7ef0$58be7cd0$@us> References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <04CA7DCC63584C4D8967FF818D80965B01BB8ABC@XMB-RCD-113.cisco.com>, <012001cb21db$c83f7ef0$58be7cd0$@us> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jul 2010 16:57:58.0740 (UTC) FILETIME=[61821940:01CB21E3] Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 16:57:52 -0000 --_d790648f-a8dd-4376-aa82-10b2796a3817_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >In fact we will need something standardized like "ViPR" to get Facetime like functionality to work with for non-vendor >specific devices/implementation.=20 That's what I'm not clear about. As I understand it=2C Facetime does not u= tilize an E.164 to email-style URI translation mechanism anything like VIPR= -- and as a result=2C the scaling characteristics are quite different.=20 >Of course it would be useful to admit the subtext of this entire discussion is enabling PSTN service provider bypass.= A more useful WG >name for this activity would be =93bypass=94 or =91X-TPC=94= =20 for =93The Phone Company=94 and have Mr. Arlington Hewes as honorary co-chair.I agree with you that there is a subtext here=2C and that it's imp= ortant to understand what it is. However=2C I'm not sure that this subtext= is actually "toll bypass".=20 My understanding is that VIPR was not created to solve the toll bypass prob= lem=2C but rather in order enable the completion of a video call over IP wh= en the endpoint identifier is an E.164 number. That is not really the sam= e as "toll bypass".=20 =20 = --_d790648f-a8dd-4376-aa82-10b2796a3817_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

>=3BIn fact we will need somethin= g standardized like "ViPR" to get Facetime like functionality to work with =3Bfor non-vendor >=3Bspecific =3Bdevices/implementation. =3B

That's what I'm not clear about. =3B As I understand it=2C Facetime doe= s not utilize an E.164 to email-style URI translation mechanism anything li= ke VIPR -- and as a result=2C the scaling characteristics are quite differe= nt.

>=3BOf course it would be useful to admit the subtext of this entire discussion is enabling PSTN service provider bypass.=  =3B =3BA more useful WG >=3Bname for this activity would be =93bypass=94 or =91X-T= PC=94 =3B for =93The Phone Company=94  =3Band have Mr. Arlington Hewes as honorar= y co-chair.

I agree with you that there is a subtext here=2C and t= hat it's important to understand what it is. =3B However=2C I'm not sur= e that this subtext is actually "toll bypass".

My understanding is = that VIPR was not created to solve the toll bypass problem=2C but rather in= order enable the completion of a video call over IP when the endpoint iden= tifier is an E.164 number. =3B =3B That is not really the same as "= toll bypass".

 =3B

= --_d790648f-a8dd-4376-aa82-10b2796a3817_-- From stephen.botzko@gmail.com Mon Jul 12 10:01:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511663A6B90 for ; Mon, 12 Jul 2010 10:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nF7QE7iKbPWQ for ; Mon, 12 Jul 2010 10:01:50 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id C97EC3A6B7B for ; Mon, 12 Jul 2010 10:01:49 -0700 (PDT) Received: by wwi17 with SMTP id 17so198138wwi.13 for ; Mon, 12 Jul 2010 10:01:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ep/vtWReNHtVrYvyryn5P2hwvU7Pu2scDEMFiogqeMY=; b=QZUfNMKgy8DxdTblEbmf3HESdQMGWUF4Rnk+MGf74iHbA7SkA5cKjgHOHQY3G1IolN T1i5SjS09G5hVy4hwkcUQB8iRsTtE5IWYcAjPdkea/tNJeyCNFkuNA5vbJdWgLDiouKm PfpAPQGkiD7C+DzSG1IL8P+IpbP6/LEmehqlY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ulscQxcXmUkggSYckemqthztbnRf6gYQXeMERUkPXyGXo3EXISkcyEF70Wni/cbO2W 0piGRh4hpfjdMr8SRPvNOKuULO4N0ubgSZWqzrheQ+MSg8vKZ7btSAFC0HEAzAMvzmY7 3yk/lUunMrqZ+wTovwk9WxhQvzYH9tb4i5tlA= MIME-Version: 1.0 Received: by 10.216.158.136 with SMTP id q8mr8908357wek.101.1278954112865; Mon, 12 Jul 2010 10:01:52 -0700 (PDT) Received: by 10.216.80.81 with HTTP; Mon, 12 Jul 2010 10:01:52 -0700 (PDT) In-Reply-To: References: <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com> <002f01cb21c6$fdc3f430$f94bdc90$@us> <04CA7DCC63584C4D8967FF818D80965B01BB8ABC@XMB-RCD-113.cisco.com> <012001cb21db$c83f7ef0$58be7cd0$@us> Date: Mon, 12 Jul 2010 13:01:52 -0400 Message-ID: From: stephen botzko To: Bernard Aboba Content-Type: multipart/alternative; boundary=0016367fb3af94d6f3048b33b525 Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 17:01:51 -0000 --0016367fb3af94d6f3048b33b525 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>> My understanding is that VIPR was not created to solve the toll bypass problem, but rather in order enable the completion of a video call over IP when the endpoint identifier is an E.164 number. >>> That would be a very useful thing! Stephen Botzko On Mon, Jul 12, 2010 at 12:57 PM, Bernard Aboba wrote: > >In fact we will need something standardized like "ViPR" to get Facetim= e > like functionality to work with for non-vendor > >specific devices/implementation. > > That's what I'm not clear about. As I understand it, Facetime does not > utilize an E.164 to email-style URI translation mechanism anything like V= IPR > -- and as a result, the scaling characteristics are quite different. > >Of course it would be useful to admit the subtext of this entire > discussion is enabling PSTN service provider bypass. A more useful WG > >name for this activity would be =93bypass=94 or =91X-TPC=94 for =93The = Phone > Company=94 and have Mr. Arlington Hewes as honorary co-chair. > I agree with you that there is a subtext here, and that it's important to > understand what it is. However, I'm not sure that this subtext is actual= ly > "toll bypass". > > My understanding is that VIPR was not created to solve the toll bypass > problem, but rather in order enable the completion of a video call over I= P > when the endpoint identifier is an E.164 number. That is not really the > same as "toll bypass". > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --0016367fb3af94d6f3048b33b525 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>>
=A0=A0 My understanding is that VIPR was not created to sol= ve the toll bypass=20 problem, but rather in order enable the completion of a video call over=20 IP when the endpoint identifier is an E.164 number.
>>>
That= would be a very useful thing!

Stephen Botzko

On Mon, Jul 12, 2010 at 12:57 PM, Bernard Aboba <bernard_aboba@hotmail.c= om> wrote:

>In fact we will need s= omething standardized like "ViPR" to get Facetime like functionality to work with=A0for non-vendor >specific=A0devices/implementation.=A0

That's what I'm not clear about.=A0 As I understand it, Facetime do= es not utilize an E.164 to email-style URI translation mechanism anything l= ike VIPR -- and as a result, the scaling characteristics are quite differen= t.

>Of course it would be useful to ad= mit the subtext of this entire discussion is enabling PSTN service provider bypass.= =A0=A0A more useful WG >name for this activity would be =93bypass=94 or =91X-TPC= =94=A0 for =93The Phone Company=94 =A0and have Mr. Arlington Hewes as honorary co-chair.

I agree with you that there is a subtext here, a= nd that it's important to understand what it is.=A0 However, I'm no= t sure that this subtext is actually "toll bypass".

My un= derstanding is that VIPR was not created to solve the toll bypass problem, = but rather in order enable the completion of a video call over IP when the = endpoint identifier is an E.164 number.=A0=A0 That is not really the same a= s "toll bypass".

=A0


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


--0016367fb3af94d6f3048b33b525-- From bernard_aboba@hotmail.com Mon Jul 12 10:11:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23D373A69BD for ; Mon, 12 Jul 2010 10:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[AWL=1.400, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3X6TV1CN28LF for ; Mon, 12 Jul 2010 10:11:00 -0700 (PDT) Received: from blu0-omc3-s18.blu0.hotmail.com (blu0-omc3-s18.blu0.hotmail.com [65.55.116.93]) by core3.amsl.com (Postfix) with ESMTP id 3137A3A6974 for ; Mon, 12 Jul 2010 10:11:00 -0700 (PDT) Received: from BLU137-W4 ([65.55.116.74]) by blu0-omc3-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 10:11:07 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_fb26b819-aae0-46db-adda-e33bcaa34179_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Mon, 12 Jul 2010 10:11:07 -0700 Importance: Normal In-Reply-To: References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com>, , <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us>, , <04CA7DCC63584C4D8967FF818D80965B01BB8ABC@XMB-RCD-113.cisco.com>, <012001cb21db$c83f7ef0$58be7cd0$@us>, , MIME-Version: 1.0 X-OriginalArrivalTime: 12 Jul 2010 17:11:07.0745 (UTC) FILETIME=[37CAB510:01CB21E5] Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 17:11:02 -0000 --_fb26b819-aae0-46db-adda-e33bcaa34179_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Indeed=2C that would be a very useful thing -- but unfortunately=2C that is= not what this charter is focused on! Date: Mon=2C 12 Jul 2010 13:01:52 -0400 Subject: Re: [dispatch] VIPR - proposed charter version 4 From: stephen.botzko@gmail.com To: bernard_aboba@hotmail.com CC: richard@shockey.us=3B maltarai@cisco.com=3B dispatch@ietf.org >>> My understanding is that VIPR was not created to solve the toll bypass=20 problem=2C but rather in order enable the completion of a video call over=20 IP when the endpoint identifier is an E.164 number. >>> That would be a very useful thing! Stephen Botzko On Mon=2C Jul 12=2C 2010 at 12:57 PM=2C Bernard Aboba wrote: >In fact we will need something standardized like "ViPR" to get Facetime like functionality to work with for non-vendor >specific devices/implementation.=20 That's what I'm not clear about. As I understand it=2C Facetime does not u= tilize an E.164 to email-style URI translation mechanism anything like VIPR= -- and as a result=2C the scaling characteristics are quite different.=20 >Of course it would be useful to admit the subtext of this entire discussion is enabling PSTN service provider bypass.= A more useful WG >name for this activity would be =93bypass=94 or =91X-TPC=94= =20 for =93The Phone Company=94 and have Mr. Arlington Hewes as honorary co-chair.I agree with you that there is a subtext here=2C and that it's imp= ortant to understand what it is. However=2C I'm not sure that this subtext= is actually "toll bypass".=20 My understanding is that VIPR was not created to solve the toll bypass prob= lem=2C but rather in order enable the completion of a video call over IP wh= en the endpoint identifier is an E.164 number. That is not really the sam= e as "toll bypass".=20 =20 =20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch = --_fb26b819-aae0-46db-adda-e33bcaa34179_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Indeed=2C that would be a very useful thing -- but unfortunately=2C that is= not what this charter is focused on!

Date: = Mon=2C 12 Jul 2010 13:01:52 -0400
Subject: Re: [dispatch] VIPR - propose= d charter version 4
From: stephen.botzko@gmail.com
To: bernard_aboba@= hotmail.com
CC: richard@shockey.us=3B maltarai@cisco.com=3B dispatch@iet= f.org

>=3B>=3B>=3B
 =3B =3B My understanding is tha= t VIPR was not created to solve the toll bypass=20 problem=2C but rather in order enable the completion of a video call over=20 IP when the endpoint identifier is an E.164 number.
>=3B>=3B>=3BThat would be a very useful thing!

Stephen Botzko

On Mon=2C Jul 12=2C 2010 at 12:57 PM=2C Bernard Aboba = <=3Bbernar= d_aboba@hotmail.com>=3B wrote:
>=3BIn fact we will nee= d something standardized like "ViPR" to get Facetime like functionality to work with =3Bfor non-vendor >=3Bspecific =3Bdevices/implementation. =3B

That's what I'm not clear about. =3B As I understand it=2C Facetime doe= s not utilize an E.164 to email-style URI translation mechanism anything li= ke VIPR -- and as a result=2C the scaling characteristics are quite differe= nt.

>=3BOf course it would = be useful to admit the subtext of this entire discussion is enabling PSTN service provider bypass.=  =3B =3BA more useful WG >=3Bname for this activity would be =93bypass=94 or =91X-T= PC=94 =3B for =93The Phone Company=94  =3Band have Mr. Arlington Hewes as honorar= y co-chair.

I agree with you that there is a subtext here=2C= and that it's important to understand what it is. =3B However=2C I'm n= ot sure that this subtext is actually "toll bypass".

My understandi= ng is that VIPR was not created to solve the toll bypass problem=2C but rat= her in order enable the completion of a video call over IP when the endpoin= t identifier is an E.164 number. =3B =3B That is not really the sam= e as "toll bypass".

 =3B<= /span>

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


= --_fb26b819-aae0-46db-adda-e33bcaa34179_-- From richard@shockey.us Mon Jul 12 10:18:58 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DACD43A6979 for ; Mon, 12 Jul 2010 10:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.606 X-Spam-Level: X-Spam-Status: No, score=-1.606 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgNZl-fAEaw6 for ; Mon, 12 Jul 2010 10:18:53 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 4E9FC3A684E for ; Mon, 12 Jul 2010 10:18:53 -0700 (PDT) Received: (qmail 19118 invoked by uid 0); 12 Jul 2010 17:19:01 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 12 Jul 2010 17:19:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=nl3RwdULGu31NRd9u+nHxsqo/r6u8c6y3iifnkSRqpMCoIjfUJtSMmFdKCKxp4s+43xwaoyroNqI7AyJHk/659QKpDMjqBXsgg/Pbt/5xsLSTavlsStS5Tkx7feUcz7b; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OYMei-0002lq-Sy; Mon, 12 Jul 2010 11:19:01 -0600 From: "Richard Shockey" To: "'Bernard Aboba'" , , References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <04CA7DCC63584C4D8967FF818D80965B01BB8ABC@XMB-RCD-113.cisco.com>, <012001cb21db$c83f7ef0$58be7cd0$@us> In-Reply-To: Date: Mon, 12 Jul 2010 13:19:00 -0400 Message-ID: <020a01cb21e6$5219d350$f64d79f0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020B_01CB21C4.CB083350" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acsh42GphUsQ2JgWQX+3NO0fMOMRcAAALBmQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 17:18:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_020B_01CB21C4.CB083350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit You points are at the center of what is the problem with the existing charter. Lack of clarity. Which is why it is still "challenging" in its current form. All proposed IETF charters need to state clearly, "This is the problem we (the proposed WG) are trying to solve" and that problem needs to be narrowly scoped. VIPR IMHO, as the ID's currently read, looks like toll bypass pure and simple. If, as you wisely point out the actual technical goal, is establishment of a communication session where the endpoint is a E.164 number WITHOUT the intervention of centralized carrier controlled/public databases (Carrier vs Public ENUM) then it is clear its closer to a FaceTime interface. Either way still session establishment without the intervention of the service provider controlling the underlying E.164 namespace. From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] Sent: Monday, July 12, 2010 12:58 PM To: richard@shockey.us; maltarai@cisco.com; dispatch@ietf.org Subject: RE: VIPR - proposed charter version 4 >In fact we will need something standardized like "ViPR" to get Facetime like functionality to work with for non-vendor >specific devices/implementation. That's what I'm not clear about. As I understand it, Facetime does not utilize an E.164 to email-style URI translation mechanism anything like VIPR -- and as a result, the scaling characteristics are quite different. >Of course it would be useful to admit the subtext of this entire discussion is enabling PSTN service provider bypass. A more useful WG >name for this activity would be "bypass" or 'X-TPC" for "The Phone Company" and have Mr. Arlington Hewes as honorary co-chair. I agree with you that there is a subtext here, and that it's important to understand what it is. However, I'm not sure that this subtext is actually "toll bypass". My understanding is that VIPR was not created to solve the toll bypass problem, but rather in order enable the completion of a video call over IP when the endpoint identifier is an E.164 number. That is not really the same as "toll bypass". ------=_NextPart_000_020B_01CB21C4.CB083350 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You points are at the center of what is the problem with = the existing charter. Lack of clarity. Which is why it is still = “challenging” in its current form.

 

All proposed IETF charters need to state clearly, =  “This is the problem we (the proposed WG)  are trying to solve” and = that problem needs to be narrowly scoped.

 

VIPR IMHO, as the ID’s currently read, looks like = toll bypass pure and simple.

 

If, as you wisely point out the actual technical goal, is establishment of a communication session where the endpoint is a E.164 = number WITHOUT the intervention of centralized carrier controlled/public = databases (Carrier vs Public ENUM) then it is clear its closer to a FaceTime interface. =

 

Either way still session establishment without the = intervention of the service provider controlling the underlying E.164 = namespace.

 

 

From:= Bernard = Aboba [mailto:bernard_aboba@hotmail.com]
Sent: Monday, July 12, 2010 12:58 PM
To: richard@shockey.us; maltarai@cisco.com; dispatch@ietf.org
Subject: RE: VIPR - proposed charter version = 4

 

>In fact we will need something standardized like "ViPR" to get Facetime like functionality to work = with for non-vendor >specific devices/implementation. 

That's what I'm not clear about.  As I understand it, Facetime does = not utilize an E.164 to email-style URI translation mechanism anything like = VIPR -- and as a result, the scaling characteristics are quite different. =

>Of course it would be useful to = admit the subtext of this entire discussion is enabling PSTN service provider = bypass.   A more useful WG >name for this activity would be “bypass” or ‘X-TPC”  for “The Phone Company”  and have Mr. Arlington Hewes as honorary = co-chair.

I agree with you that there is a = subtext here, and that it's important to understand what it is.  However, = I'm not sure that this subtext is actually "toll bypass".

My understanding is that VIPR was not created to solve the toll bypass = problem, but rather in order enable the completion of a video call over IP when = the endpoint identifier is an E.164 number.   That is not really = the same as "toll bypass".

 =

------=_NextPart_000_020B_01CB21C4.CB083350-- From maltarai@cisco.com Mon Jul 12 10:19:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61A713A69D7 for ; Mon, 12 Jul 2010 10:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Uq1WgC-GOup for ; Mon, 12 Jul 2010 10:19:18 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 016A53A684E for ; Mon, 12 Jul 2010 10:19:09 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAOrqOkytJV2b/2dsb2JhbACBQ5F6jHRxpUKaXIJVFII+BIN7hn+Gcw X-IronPort-AV: E=Sophos;i="4.55,189,1278288000"; d="scan'208,217";a="131423416" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2010 17:18:38 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o6CHIcx9007878; Mon, 12 Jul 2010 17:18:38 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 12:18:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB21E6.4480B210" Date: Mon, 12 Jul 2010 12:18:35 -0500 Message-ID: <04CA7DCC63584C4D8967FF818D80965B01BB8B66@XMB-RCD-113.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 4 Thread-Index: Acsh5T03GBPbEI7KRBysXJpbn4+SkgAAE5JA References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com>, , <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us>, , <04CA7DCC63584C4D8967FF818D80965B01BB8ABC@XMB-RCD-113.cisco.com>, <012001cb21db$c83f7ef0$58be7cd0$@us>, , From: "Mohammad Al-Taraireh (maltarai)" To: "Bernard Aboba" , X-OriginalArrivalTime: 12 Jul 2010 17:18:38.0953 (UTC) FILETIME=[44BB9590:01CB21E6] Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 17:19:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB21E6.4480B210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 At the end of the day ViPR will unlock all the features potential that the communicating devices can support, and limited by the PSTN today, Video, wideband codec support, VCard, Callback, ... the list goes on. ViPR is really just a framework to get you the correct mapping between the a number that you already dialed over the PSTN to a SIP route that is globally reachable.=20 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Monday, July 12, 2010 1:11 PM To: stephen.botzko@gmail.com Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 Indeed, that would be a very useful thing -- but unfortunately, that is not what this charter is focused on! ________________________________ Date: Mon, 12 Jul 2010 13:01:52 -0400 Subject: Re: [dispatch] VIPR - proposed charter version 4 From: stephen.botzko@gmail.com To: bernard_aboba@hotmail.com CC: richard@shockey.us; maltarai@cisco.com; dispatch@ietf.org >>> My understanding is that VIPR was not created to solve the toll bypass problem, but rather in order enable the completion of a video call over IP when the endpoint identifier is an E.164 number. >>> That would be a very useful thing! Stephen Botzko On Mon, Jul 12, 2010 at 12:57 PM, Bernard Aboba wrote: =09 >In fact we will need something standardized like "ViPR" to get Facetime like functionality to work with for non-vendor >specific devices/implementation.=20 =09 That's what I'm not clear about. As I understand it, Facetime does not utilize an E.164 to email-style URI translation mechanism anything like VIPR -- and as a result, the scaling characteristics are quite different.=20 =09 =09 >Of course it would be useful to admit the subtext of this entire discussion is enabling PSTN service provider bypass. A more useful WG >name for this activity would be "bypass" or 'X-TPC" for "The Phone Company" and have Mr. Arlington Hewes as honorary co-chair. I agree with you that there is a subtext here, and that it's important to understand what it is. However, I'm not sure that this subtext is actually "toll bypass".=20 =09 My understanding is that VIPR was not created to solve the toll bypass problem, but rather in order enable the completion of a video call over IP when the endpoint identifier is an E.164 number. That is not really the same as "toll bypass".=20 =09 =20 =09 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =09 =09 ------_=_NextPart_001_01CB21E6.4480B210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
At the end of the day ViPR will unlock all the features = potential=20 that the communicating devices can support, and limited by the PSTN = today,=20 Video, wideband codec support, VCard, Callback, ... the list goes on. = ViPR is=20 really just a framework to get you the correct mapping between the a = number that=20 you already dialed over the PSTN to a SIP route that is globally = reachable.=20

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Bernard=20 Aboba
Sent: Monday, July 12, 2010 1:11 PM
To:=20 stephen.botzko@gmail.com
Cc: = dispatch@ietf.org
Subject: Re:=20 [dispatch] VIPR - proposed charter version 4

Indeed, that would be a very useful thing -- but = unfortunately, that=20 is not what this charter is focused on!

Date: Mon, 12 Jul 2010 13:01:52 -0400
Subject: Re: [dispatch] VIPR - = proposed=20 charter version 4
From: stephen.botzko@gmail.com
To:=20 bernard_aboba@hotmail.com
CC: richard@shockey.us; maltarai@cisco.com; = dispatch@ietf.org

>>>
   My understanding = is that=20 VIPR was not created to solve the toll bypass problem, but rather in = order=20 enable the completion of a video call over IP when the endpoint = identifier is an=20 E.164 number.
>>>
That would be a very useful=20 thing!

Stephen Botzko

On Mon, Jul 12, 2010 at 12:57 PM, Bernard = Aboba <bernard_aboba@hotmail.com&g= t;=20 wrote:
>In fact we will = need=20 something standardized like "ViPR" to get Facetime like functionality = to work=20 with for non-vendor = >specific devices/implementation. 

That's what I'm not clear = about. =20 As I understand it, Facetime does not utilize an E.164 to email-style = URI=20 translation mechanism anything like VIPR -- and as a result, the = scaling=20 characteristics are quite different.

>Of=20 course it would be useful to admit the subtext of this entire = discussion is=20 enabling PSTN service provider bypass.   A more useful WG = >name=20 for this activity would be “bypass” or = ‘X-TPC”  for “The Phone Company”=20  and have Mr. Arlington Hewes as honorary = co-chair.

I=20 agree with you that there is a subtext here, and that it's important = to=20 understand what it is.  However, I'm not sure that this subtext = is=20 actually "toll bypass".

My understanding is that VIPR was not = created=20 to solve the toll bypass problem, but rather in order enable the = completion of=20 a video call over IP when the endpoint identifier is an E.164=20 number.   That is not really the same as "toll bypass".=20

 

____________________________= ___________________
dispatch=20 mailing list
dispatch@ietf.org
https://www.ietf.= org/mailman/listinfo/dispatch


------_=_NextPart_001_01CB21E6.4480B210-- From maltarai@cisco.com Mon Jul 12 10:59:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D50383A6BA4 for ; Mon, 12 Jul 2010 10:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vamiZRy8lUoT for ; Mon, 12 Jul 2010 10:59:31 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8B8423A6B6B for ; Mon, 12 Jul 2010 10:59:30 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAHf1OkytJV2b/2dsb2JhbACBQ5ICjHRxpUOaaoJVFII+BIN7hn+Gcw X-IronPort-AV: E=Sophos;i="4.55,189,1278288000"; d="scan'208,217";a="131438460" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2010 17:59:37 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o6CHxbmr024482; Mon, 12 Jul 2010 17:59:37 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 12:59:37 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB21EB.FE2E6BD0" Date: Mon, 12 Jul 2010 12:59:35 -0500 Message-ID: <04CA7DCC63584C4D8967FF818D80965B01BB8BA6@XMB-RCD-113.cisco.com> In-Reply-To: <020a01cb21e6$5219d350$f64d79f0$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: VIPR - proposed charter version 4 Thread-Index: Acsh42GphUsQ2JgWQX+3NO0fMOMRcAAALBmQAAHmRLA= References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <04CA7DCC63584C4D8967FF818D80965B01BB8ABC@XMB-RCD-113.cisco.com>, <012001cb21db$c83f7ef0$58be7cd0$@us> <020a01cb21e6$5219d350$f64d79f0$@us> From: "Mohammad Al-Taraireh (maltarai)" To: "Richard Shockey" , "Bernard Aboba" , X-OriginalArrivalTime: 12 Jul 2010 17:59:37.0871 (UTC) FILETIME=[FE5CB1F0:01CB21EB] Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 17:59:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB21EB.FE2E6BD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Point well taken, I am not sure who is responsible of updating the charter, but may be we can help clarify some of the ambiguity, and narrow the scope.=20 =20 Mo A ________________________________ From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: Monday, July 12, 2010 1:19 PM To: 'Bernard Aboba'; Mohammad Al-Taraireh (maltarai); dispatch@ietf.org Subject: RE: VIPR - proposed charter version 4 You points are at the center of what is the problem with the existing charter. Lack of clarity. Which is why it is still "challenging" in its current form. =20 All proposed IETF charters need to state clearly, "This is the problem we (the proposed WG) are trying to solve" and that problem needs to be narrowly scoped. =20 VIPR IMHO, as the ID's currently read, looks like toll bypass pure and simple.=20 =20 If, as you wisely point out the actual technical goal, is establishment of a communication session where the endpoint is a E.164 number WITHOUT the intervention of centralized carrier controlled/public databases (Carrier vs Public ENUM) then it is clear its closer to a FaceTime interface.=20 =20 Either way still session establishment without the intervention of the service provider controlling the underlying E.164 namespace. =20 =20 From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 Sent: Monday, July 12, 2010 12:58 PM To: richard@shockey.us; maltarai@cisco.com; dispatch@ietf.org Subject: RE: VIPR - proposed charter version 4 =20 >In fact we will need something standardized like "ViPR" to get Facetime like functionality to work with for non-vendor >specific devices/implementation.=20 That's what I'm not clear about. As I understand it, Facetime does not utilize an E.164 to email-style URI translation mechanism anything like VIPR -- and as a result, the scaling characteristics are quite different.=20 >Of course it would be useful to admit the subtext of this entire discussion is enabling PSTN service provider bypass. A more useful WG >name for this activity would be "bypass" or 'X-TPC" for "The Phone Company" and have Mr. Arlington Hewes as honorary co-chair. I agree with you that there is a subtext here, and that it's important to understand what it is. However, I'm not sure that this subtext is actually "toll bypass".=20 My understanding is that VIPR was not created to solve the toll bypass problem, but rather in order enable the completion of a video call over IP when the endpoint identifier is an E.164 number. That is not really the same as "toll bypass".=20 =20 ------_=_NextPart_001_01CB21EB.FE2E6BD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Point well taken, I am not sure who is responsible = of updating=20 the charter, but may be we can help clarify some of the ambiguity, and = narrow=20 the scope.
 
Mo A

From: Richard Shockey=20 [mailto:richard@shockey.us]
Sent: Monday, July 12, 2010 1:19=20 PM
To: 'Bernard Aboba'; Mohammad Al-Taraireh (maltarai);=20 dispatch@ietf.org
Subject: RE: VIPR - proposed charter version = 4

You=20 points are at the center of what is the problem with the existing = charter. Lack=20 of clarity. Which is why it is still “challenging” in its = current=20 form.

 

All=20 proposed IETF charters need to state clearly,  “This is the = problem we (the=20 proposed WG)  are trying to solve” and that problem needs to = be narrowly=20 scoped.

 

VIPR=20 IMHO, as the ID’s currently read, looks like toll bypass pure and = simple.=20

 

If,=20 as you wisely point out the actual technical goal, is establishment of a = communication session where the endpoint is a E.164 number WITHOUT the=20 intervention of centralized carrier controlled/public databases (Carrier = vs=20 Public ENUM) then it is clear its closer to a FaceTime interface.=20

 

Either=20 way still session establishment without the intervention of the service = provider=20 controlling the underlying E.164 namespace.

 

 

From: Bernard = Aboba=20 [mailto:bernard_aboba@hotmail.com]
Sent: Monday, July 12, = 2010 12:58=20 PM
To: richard@shockey.us; maltarai@cisco.com;=20 dispatch@ietf.org
Subject: RE: VIPR - proposed charter version = 4

 

>In=20 fact we will need something standardized like "ViPR" to get Facetime = like=20 functionality to work with for non-vendor=20 >specific devices/implementation. 

That's=20 what I'm not clear about.  As I understand it, Facetime does not = utilize an=20 E.164 to email-style URI translation mechanism anything like VIPR -- and = as a=20 result, the scaling characteristics are quite different. =

>Of=20 course it would be useful to admit the subtext of this entire discussion = is=20 enabling PSTN service provider bypass.   A more useful WG = >name for=20 this activity would be “bypass” or ‘X-TPC”  = for “The Phone Company”=20  and have Mr. Arlington Hewes as honorary co-chair.

I agree = with you=20 that there is a subtext here, and that it's important to understand what = it=20 is.  However, I'm not sure that this subtext is actually "toll = bypass".=20

My understanding is that VIPR was not created to solve the toll = bypass=20 problem, but rather in order enable the completion of a video call over = IP when=20 the endpoint identifier is an E.164 number.   That is not = really the=20 same as "toll bypass".

 

------_=_NextPart_001_01CB21EB.FE2E6BD0-- From richard@shockey.us Mon Jul 12 11:53:57 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D4513A68A7 for ; Mon, 12 Jul 2010 11:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.637 X-Spam-Level: X-Spam-Status: No, score=-1.637 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B138mqABFtnH for ; Mon, 12 Jul 2010 11:53:48 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id AA9703A6B6E for ; Mon, 12 Jul 2010 11:53:48 -0700 (PDT) Received: (qmail 3384 invoked by uid 0); 12 Jul 2010 18:53:56 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 12 Jul 2010 18:53:56 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=ih3k3vNxxCAxxjf7Lx/P4Ulkhhi6dZsBolTzUCflWDzLzXgv+zeuqGcubudzQJgbgLpir1TE2y6D1ZM4pZvvPkSSN50qo4XE4unyEgf8n6VnOXmwnTIof0fBPVQGvRo0; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OYO8a-0005i9-3o; Mon, 12 Jul 2010 12:53:56 -0600 From: "Richard Shockey" To: "'Mohammad Al-Taraireh \(maltarai\)'" , "'Bernard Aboba'" , References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com>, , <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us>, , <04CA7DCC63584C4D8967FF818D80965B01BB8ABC@XMB-RCD-113.cisco.com>, <012001cb21db$c83f7ef0$58be7cd0$@us>, , <04CA7DCC63584C4D8967FF818D80965B01BB8B66@XMB-RCD-113.cisco.com> In-Reply-To: <04CA7DCC63584C4D8967FF818D80965B01BB8B66@XMB-RCD-113.cisco.com> Date: Mon, 12 Jul 2010 14:53:55 -0400 Message-ID: <02f901cb21f3$94b1c940$be155bc0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02FA_01CB21D2.0DA02940" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acsh5T03GBPbEI7KRBysXJpbn4+SkgAAE5JAAAL0dhA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 18:53:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_02FA_01CB21D2.0DA02940 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Well not to be too argumentative. J but I suggest that SIP has a number of things to overcome before nirvana is achieved. First you may be looking at this from a enterprise perspective but the SIP CUA Configuration issues need to be solved first. You still cant go to Best Buy or Dixons or any consumer electronics store and buy a SIP device that can easily plugged in and configured to a service provider network or a PBX or that matter. (below) I submit that its consumers that have been driving this round of technology adoption. That is what the SIP Forum was focusing on with the UA Config profile but there is still no common data model to support the specification irrespective of what domain is used to connect to the service provider. The features you describe could easily be supported by private centralized databases managed in carrier networks if, if and that is a very big if, the service providers could finally agree on the business model and structure of those databases. I doubt ViPR would work there either. Carrier CDB's are already in use for certain applications such as MMS and all IP SMS routing in North America and could easily be extended to any URI or G-SPN identifier for any defined application. The GSM-A has already defined how that might look for all GSM operators. The problem is not technical its political. Trust me on that.. J This draft proposes a modification to draft-lawrence-dispatch-sipforum-provider-alias (PAN). The PAN draft proposes a mechanism for a phone to take a short numeric identifier that identifies a phone service provider and look it up in DNS to find the address of the configuration server for that service provider. The problem with PAN is that it requires a specific organization, sipforum.org, to become a registrar for the PAN. This will add signifiant cost to obtaining them as the expected quantity of PAN is low. This draft proposes a minor modification to the PAN draft. Instead of using the sipforum as a new registrar, why not just use the registrars that already exist for DNS names. This ensure a long term stable unique allocation of PAN with the advantages of not having the IETF allocating a monopoly to one particular organization. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jennings-dispatch-npa-00.txt From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mohammad Al-Taraireh (maltarai) Sent: Monday, July 12, 2010 1:19 PM To: Bernard Aboba; stephen.botzko@gmail.com Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 At the end of the day ViPR will unlock all the features potential that the communicating devices can support, and limited by the PSTN today, Video, wideband codec support, VCard, Callback, ... the list goes on. ViPR is really just a framework to get you the correct mapping between the a number that you already dialed over the PSTN to a SIP route that is globally reachable. _____ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Monday, July 12, 2010 1:11 PM To: stephen.botzko@gmail.com Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 Indeed, that would be a very useful thing -- but unfortunately, that is not what this charter is focused on! _____ Date: Mon, 12 Jul 2010 13:01:52 -0400 Subject: Re: [dispatch] VIPR - proposed charter version 4 From: stephen.botzko@gmail.com To: bernard_aboba@hotmail.com CC: richard@shockey.us; maltarai@cisco.com; dispatch@ietf.org >>> My understanding is that VIPR was not created to solve the toll bypass problem, but rather in order enable the completion of a video call over IP when the endpoint identifier is an E.164 number. >>> That would be a very useful thing! Stephen Botzko On Mon, Jul 12, 2010 at 12:57 PM, Bernard Aboba wrote: >In fact we will need something standardized like "ViPR" to get Facetime like functionality to work with for non-vendor >specific devices/implementation. That's what I'm not clear about. As I understand it, Facetime does not utilize an E.164 to email-style URI translation mechanism anything like VIPR -- and as a result, the scaling characteristics are quite different. >Of course it would be useful to admit the subtext of this entire discussion is enabling PSTN service provider bypass. A more useful WG >name for this activity would be "bypass" or 'X-TPC" for "The Phone Company" and have Mr. Arlington Hewes as honorary co-chair. I agree with you that there is a subtext here, and that it's important to understand what it is. However, I'm not sure that this subtext is actually "toll bypass". My understanding is that VIPR was not created to solve the toll bypass problem, but rather in order enable the completion of a video call over IP when the endpoint identifier is an E.164 number. That is not really the same as "toll bypass". _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_02FA_01CB21D2.0DA02940 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well not to be too argumentative. J  but I = suggest that SIP has a number of things to overcome before nirvana is achieved. =

 

First you may be looking at this from a enterprise = perspective but the SIP CUA Configuration issues need to be solved first. You still = cant go to Best Buy or Dixons or any consumer electronics store and buy a SIP = device that can easily plugged in and configured to a service provider network = or a PBX or that matter. (below)  I submit that its consumers that have = been driving this round of technology adoption.

 

That is what the SIP Forum was focusing on with the UA = Config profile but there is still no common data model to support the = specification irrespective of what domain is used to connect to the service = provider.

 

The features you describe could easily be supported by = private centralized databases managed in carrier networks if, if and that is a = very big if, the service providers could finally agree on the business model and structure of those databases. I doubt ViPR would work there either. = Carrier CDB’s  are already in use for certain applications such as MMS and all IP = SMS routing in North America and could easily be extended to any URI or G-SPN = identifier for any defined application.  The GSM-A has already defined how = that might look for all GSM operators.

 

The problem is not technical its political. =   Trust me on that.. J

 

 

This draft proposes a modification = to

draft-lawrence-dispatch-sipforum-provider-alias (PAN).  The PAN draft proposes a mechanism for a phone to take a = short numeric identifier that identifies a phone service provider and look it = up in DNS to find the address of the configuration server for that service = provider.

 

The problem with PAN is that it requires a = specific organization, sipforum.org, to become a registrar for the PAN.  = This will add signifiant cost to obtaining them as the expected quantity of PAN is low.  This draft proposes a minor modification to the PAN = draft.

Instead of using the sipforum as a new = registrar, why not just use the registrars that already exist for DNS names.  This = ensure a long term stable unique allocation of PAN with the advantages of not = having the IETF allocating a monopoly to one particular = organization.

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-jennings-dispatch-npa-00= .txt

 

 

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Mohammad Al-Taraireh (maltarai)
Sent: Monday, July 12, 2010 1:19 PM
To: Bernard Aboba; stephen.botzko@gmail.com
Cc: dispatch@ietf.org
Subject: Re: [dispatch] VIPR - proposed charter version = 4

 

 =

At the end of the day ViPR will unlock all the features = potential that the communicating devices can support, and limited by the PSTN = today, Video, wideband codec support, VCard, Callback, ... the list goes on. = ViPR is really just a framework to get you the correct mapping between the a = number that you already dialed over the PSTN to a SIP route that is globally = reachable. =

 =

From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Monday, July 12, 2010 1:11 PM
To: stephen.botzko@gmail.com
Cc: dispatch@ietf.org
Subject: Re: [dispatch] VIPR - proposed charter version = 4=

Indeed, that would be a very useful = thing -- but unfortunately, that is not what this charter is focused = on!

Date: Mon, 12 Jul 2010 13:01:52 = -0400
Subject: Re: [dispatch] VIPR - proposed charter version 4
From: stephen.botzko@gmail.com
To: bernard_aboba@hotmail.com
CC: richard@shockey.us; maltarai@cisco.com; dispatch@ietf.org

>>>
   My understanding is that VIPR was not created to solve the = toll bypass problem, but rather in order enable the completion of a video = call over IP when the endpoint identifier is an E.164 number.
>>>
That would be a very useful thing!

Stephen Botzko

On Mon, Jul 12, 2010 at 12:57 PM, Bernard Aboba <bernard_aboba@hotmail.com&g= t; wrote:

>In fact we will need something standardized like "ViPR" to get Facetime like = functionality to work with for non-vendor = >specific devices/implementation. 

That's what I'm not clear about.  As I understand it, Facetime does = not utilize an E.164 to email-style URI translation mechanism anything like = VIPR -- and as a result, the scaling characteristics are quite different. =

>Of course it would be useful to = admit the subtext of this entire discussion is enabling PSTN service provider = bypass.   A more useful WG >name for this activity would be “bypass” or ‘X-TPC”  for “The Phone Company”  and have Mr. Arlington Hewes as honorary = co-chair.

I agree with you that there is a subtext here, and that it's important to understand what it is.  However, I'm not sure that this subtext is actually "toll bypass".

My understanding is that VIPR was not created to solve the toll bypass = problem, but rather in order enable the completion of a video call over IP when = the endpoint identifier is an E.164 number.   That is not really = the same as "toll bypass".

 =


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

 =

------=_NextPart_000_02FA_01CB21D2.0DA02940-- From maltarai@cisco.com Mon Jul 12 16:18:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48A33A6807 for ; Mon, 12 Jul 2010 16:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlXAF0rSb-Sk for ; Mon, 12 Jul 2010 16:18:00 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 276503A6804 for ; Mon, 12 Jul 2010 16:18:00 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAEs/O0ytJV2d/2dsb2JhbACBQ5IEjHJxpDubAYJVFII+BIN7hn+Gcw X-IronPort-AV: E=Sophos;i="4.55,191,1278288000"; d="scan'208,217";a="131555256" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 12 Jul 2010 23:18:07 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o6CNI78X023536; Mon, 12 Jul 2010 23:18:07 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 18:18:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2218.7C891470" Date: Mon, 12 Jul 2010 18:18:05 -0500 Message-ID: <04CA7DCC63584C4D8967FF818D80965B01BB8D85@XMB-RCD-113.cisco.com> In-Reply-To: <02f901cb21f3$94b1c940$be155bc0$@us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 4 Thread-Index: Acsh5T03GBPbEI7KRBysXJpbn4+SkgAAE5JAAAL0dhAACW8c4A== References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com>, , <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us>, , <04CA7DCC63584C4D8967FF818D80965B01BB8ABC@XMB-RCD-113.cisco.com>, <012001cb21db$c83f7ef0$58be7cd0$@us>, , <04CA7DCC63584C4D8967FF818D80965B01BB8B66@XMB-RCD-113.cisco.com> <02f901cb21f3$94b1c940$be155bc0$@us> From: "Mohammad Al-Taraireh (maltarai)" To: "Richard Shockey" , "Bernard Aboba" , X-OriginalArrivalTime: 12 Jul 2010 23:18:07.0166 (UTC) FILETIME=[7C63B5E0:01CB2218] Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 23:18:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2218.7C891470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see inline: ________________________________ From: Richard Shockey [mailto:richard@shockey.us]=20 Sent: Monday, July 12, 2010 2:54 PM To: Mohammad Al-Taraireh (maltarai); 'Bernard Aboba'; stephen.botzko@gmail.com Cc: dispatch@ietf.org Subject: RE: [dispatch] VIPR - proposed charter version 4 Well not to be too argumentative. J but I suggest that SIP has a number of things to overcome before nirvana is achieved. =20 =20 Mo>> No argument there :-)=20 =20 First you may be looking at this from a enterprise perspective but the SIP CUA Configuration issues need to be solved first. You still cant go to Best Buy or Dixons or any consumer electronics store and buy a SIP device that can easily plugged in and configured to a service provider network or a PBX or that matter. (below) I submit that its consumers that have been driving this round of technology adoption. =20 =20 Mo>> Vonage (may be not the best example) has something that you can pick up from Wal-Mart, connect to your internet, and you have service. So I can see devices that support ViPR fall in that category at some point. =20 =20 That is what the SIP Forum was focusing on with the UA Config profile but there is still no common data model to support the specification irrespective of what domain is used to connect to the service provider.=20 =20 Mo>> That is one of the advantages of ViPR model, you only need to care on how to configure your system nothing else. It is dynamic, no one need to know how the other devices are configured. =20 =20 The features you describe could easily be supported by private centralized databases managed in carrier networks if, if and that is a very big if, the service providers could finally agree on the business model and structure of those databases. I doubt ViPR would work there either. Carrier CDB's are already in use for certain applications such as MMS and all IP SMS routing in North America and could easily be extended to any URI or G-SPN identifier for any defined application. The GSM-A has already defined how that might look for all GSM operators. =20 Mo>> And that is another problem that ViPR solves, if the SP don't want to play, the end users (enterprises, small pbx, or end devices) can still use it, without the need to manage a centralized DB.=20 =20 The problem is not technical its political. Trust me on that.. J =20 Mo>> :-) no comment on the above. =20 =20 =20 This draft proposes a modification to draft-lawrence-dispatch-sipforum-provider-alias (PAN). The PAN draft proposes a mechanism for a phone to take a short numeric identifier that identifies a phone service provider and look it up in DNS to find the address of the configuration server for that service provider. =20 The problem with PAN is that it requires a specific organization, sipforum.org, to become a registrar for the PAN. This will add signifiant cost to obtaining them as the expected quantity of PAN is low. This draft proposes a minor modification to the PAN draft. Instead of using the sipforum as a new registrar, why not just use the registrars that already exist for DNS names. This ensure a long term stable unique allocation of PAN with the advantages of not having the IETF allocating a monopoly to one particular organization. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-jennings-dispatch-npa-00.txt=20 =20 Mo>> I am yet to read this above, but again this seems to involve yet another managed DB with some specific mapping.=20 =20 Thanks, =20 Mo A=20 =20 =20 From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mohammad Al-Taraireh (maltarai) Sent: Monday, July 12, 2010 1:19 PM To: Bernard Aboba; stephen.botzko@gmail.com Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 =20 =20 At the end of the day ViPR will unlock all the features potential that the communicating devices can support, and limited by the PSTN today, Video, wideband codec support, VCard, Callback, ... the list goes on. ViPR is really just a framework to get you the correct mapping between the a number that you already dialed over the PSTN to a SIP route that is globally reachable.=20 =20 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Monday, July 12, 2010 1:11 PM To: stephen.botzko@gmail.com Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 Indeed, that would be a very useful thing -- but unfortunately, that is not what this charter is focused on! ________________________________ Date: Mon, 12 Jul 2010 13:01:52 -0400 Subject: Re: [dispatch] VIPR - proposed charter version 4 From: stephen.botzko@gmail.com To: bernard_aboba@hotmail.com CC: richard@shockey.us; maltarai@cisco.com; dispatch@ietf.org >>> My understanding is that VIPR was not created to solve the toll bypass problem, but rather in order enable the completion of a video call over IP when the endpoint identifier is an E.164 number. >>> That would be a very useful thing! Stephen Botzko On Mon, Jul 12, 2010 at 12:57 PM, Bernard Aboba wrote: >In fact we will need something standardized like "ViPR" to get Facetime like functionality to work with for non-vendor >specific devices/implementation.=20 That's what I'm not clear about. As I understand it, Facetime does not utilize an E.164 to email-style URI translation mechanism anything like VIPR -- and as a result, the scaling characteristics are quite different.=20 >Of course it would be useful to admit the subtext of this entire discussion is enabling PSTN service provider bypass. A more useful WG >name for this activity would be "bypass" or 'X-TPC" for "The Phone Company" and have Mr. Arlington Hewes as honorary co-chair. I agree with you that there is a subtext here, and that it's important to understand what it is. However, I'm not sure that this subtext is actually "toll bypass".=20 My understanding is that VIPR was not created to solve the toll bypass problem, but rather in order enable the completion of a video call over IP when the endpoint identifier is an E.164 number. That is not really the same as "toll bypass".=20 =20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch =20 ------_=_NextPart_001_01CB2218.7C891470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please see  inline:

From: Richard Shockey=20 [mailto:richard@shockey.us]
Sent: Monday, July 12, 2010 2:54=20 PM
To: Mohammad Al-Taraireh (maltarai); 'Bernard Aboba';=20 stephen.botzko@gmail.com
Cc: = dispatch@ietf.org
Subject: RE:=20 [dispatch] VIPR - proposed charter version 4

Well=20 not to be too argumentative. J =20 but I suggest that SIP has a number of things to overcome before nirvana = is=20 achieved.  

 

Mo>> No=20 argument there :-) 

 

First=20 you may be looking at this from a enterprise perspective but the SIP CUA = Configuration issues need to be solved first. You still cant go to Best = Buy or=20 Dixons or any consumer electronics store and buy a SIP device that can = easily=20 plugged in and configured to a service provider network or a PBX or that = matter.=20 (below)  I submit that its consumers that have been driving this = round of=20 technology adoption.  

 

Mo>> Vonage (may be not the best example) =  has=20 something that you can pick up from Wal-Mart, connect to your=20 internet, and you have service. So I can see devices that support ViPR = fall in=20 that category at some point.  

 

That=20 is what the SIP Forum was focusing on with the UA Config profile but = there is=20 still no common data model to support the specification irrespective of = what=20 domain is used to connect to the service provider. 

 

Mo>> That=20 is one of the advantages of ViPR model, you only need to = care on=20 how to configure your system nothing else. It is dynamic, no one = need to=20 know how the other devices are configured.=20  

 

The=20 features you describe could easily be supported by private centralized = databases=20 managed in carrier networks if, if and that is a very big if, the = service=20 providers could finally agree on the business model and structure of = those=20 databases. I doubt ViPR would work there either. Carrier CDB’s =  are already=20 in use for certain applications such as MMS and all IP SMS routing in = North=20 America and could easily be extended to any URI or G-SPN identifier for = any=20 defined application.  The GSM-A has already defined how that might = look for=20 all GSM operators. 

 

Mo>> And=20 that is another problem that ViPR solves, if the SP don't want to = play, the=20 end users (enterprises, small pbx, or end devices) can still use = it,=20 without the need to manage a centralized DB.

 

The=20 problem is not technical its political.   Trust me on that..=20 J  

Mo>> :-) no=20 comment on the above.  

 

 

This draft proposes a modification = to

draft-lawrence-dispatch-sipforum-provider-alias=20 (PAN).  The PAN draft proposes a mechanism for a phone to take a = short=20 numeric identifier that identifies a phone service provider and look it = up in=20 DNS to find the address of the configuration server for that service=20 provider.

 

The problem with PAN is that it requires a = specific=20 organization, sipforum.org, to become a registrar for the PAN.  = This will=20 add signifiant cost to obtaining them as the expected quantity of PAN is = low.  This draft proposes a minor modification to the PAN=20 draft.

Instead of using the sipforum as a new = registrar, why not=20 just use the registrars that already exist for DNS names.  This = ensure a=20 long term stable unique allocation of PAN with the advantages of not = having the=20 IETF allocating a monopoly to one particular = organization.

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-jennings-dispatch-npa-00= .txt 

 

Mo>> I am yet to read this above, but again this = seems to=20 involve yet another managed DB with some specific=20 mapping. 

 

Thanks,

 

Mo A 

 

 

From:=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of=20 Mohammad Al-Taraireh (maltarai)
Sent: Monday, July 12, = 2010 1:19=20 PM
To: Bernard Aboba; stephen.botzko@gmail.com
Cc:=20 dispatch@ietf.org
Subject: Re: [dispatch] VIPR - proposed = charter=20 version 4

 

 

At the=20 end of the day ViPR will unlock all the features potential that the=20 communicating devices can support, and limited by the PSTN today, Video, = wideband codec support, VCard, Callback, ... the list goes on. ViPR is = really=20 just a framework to get you the correct mapping between the a number = that you=20 already dialed over the PSTN to a SIP route that is globally reachable.=20

 

From:=20 dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of=20 Bernard Aboba
Sent: Monday, July 12, 2010 1:11 = PM
To:=20 stephen.botzko@gmail.com
Cc: = dispatch@ietf.org
Subject: Re:=20 [dispatch] VIPR - proposed charter version 4

Indeed, = that would=20 be a very useful thing -- but unfortunately, that is not what this = charter is=20 focused on!

Date: = Mon, 12 Jul=20 2010 13:01:52 -0400
Subject: Re: [dispatch] VIPR - proposed charter = version=20 4
From: stephen.botzko@gmail.com
To: = bernard_aboba@hotmail.com
CC:=20 richard@shockey.us; maltarai@cisco.com;=20 dispatch@ietf.org

>>>
   My understanding = is that=20 VIPR was not created to solve the toll bypass problem, but rather in = order=20 enable the completion of a video call over IP when the endpoint = identifier is an=20 E.164 number.
>>>
That would be a very useful=20 thing!

Stephen Botzko

On Mon, = Jul 12,=20 2010 at 12:57 PM, Bernard Aboba <bernard_aboba@hotmail.com&g= t;=20 wrote:

>In=20 fact we will need something standardized like "ViPR" to get Facetime = like=20 functionality to work with for non-vendor=20 >specific devices/implementation. 

That's=20 what I'm not clear about.  As I understand it, Facetime does not = utilize an=20 E.164 to email-style URI translation mechanism anything like VIPR -- and = as a=20 result, the scaling characteristics are quite different. =

>Of=20 course it would be useful to admit the subtext of this entire discussion = is=20 enabling PSTN service provider bypass.   A more useful WG = >name for=20 this activity would be “bypass” or ‘X-TPC”  = for “The Phone Company”=20  and have Mr. Arlington Hewes as honorary co-chair.

I agree = with you=20 that there is a subtext here, and that it's important to understand what = it=20 is.  However, I'm not sure that this subtext is actually "toll = bypass".=20

My understanding is that VIPR was not created to solve the toll = bypass=20 problem, but rather in order enable the completion of a video call over = IP when=20 the endpoint identifier is an E.164 number.   That is not = really the=20 same as "toll bypass".

 


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

 

------_=_NextPart_001_01CB2218.7C891470-- From lconroy@insensate.co.uk Tue Jul 13 04:47:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1E83A6A1F for ; Tue, 13 Jul 2010 04:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.083 X-Spam-Level: X-Spam-Status: No, score=0.083 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzDg5kjIPcxI for ; Tue, 13 Jul 2010 04:47:54 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id ECAD33A657C for ; Tue, 13 Jul 2010 04:47:53 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id A10842EC2D2 for ; Tue, 13 Jul 2010 12:48:01 +0100 (BST) From: Lawrence Conroy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 13 Jul 2010 12:48:01 +0100 Message-Id: <14D9549E-1114-4F40-9DFB-4C334318F552@insensate.co.uk> To: DISPATCH Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [dispatch] ViPR -- Technical question X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 11:47:55 -0000 Hi Folks, as Richard said in another thread, the overall concept and charter is = not technical, it's political/operational. However, I DO have a question on the toolset that may be used: - PVP does seem to assume that caller and callee agree on start and stop = times for calls over the PSTN. Given the "dead air" I get when calling someone (which can be a large = number of *seconds* for mobile terminated calls), how are these entities supposed to agree = on start and stop times? For SIP -- OK, this is do-able, for SS#7 it MAY be do-able, but for = general PSTN calls? This problem is mentioned in detail in 6.2.1, which lists the = restrictions. However, the assumption there seems to be the rounding differences will = be in milliseconds, and this is not the experience of a vary majority of = end users (or even enterprises). Also, many PBXs have call clearing = supervision that is "less than ideal", so you may get call end = differences that differ by a LOT. I must be missing something here, but at first blush, this looks like it = won't work except in very limited situations as the timestamps at either = end will not line up anything like exactly. Setting Tr to 1 second is = not going to cut it. So ... is this whole idea really based on quite a limited applicability? all the best, Lawrence From peter.musgrave@magorcorp.com Tue Jul 13 05:20:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2A1D3A67AC for ; Tue, 13 Jul 2010 05:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[AWL=-1.013, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9W71ROsaU7YN for ; Tue, 13 Jul 2010 05:20:21 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 1BC753A686E for ; Tue, 13 Jul 2010 05:20:21 -0700 (PDT) Received: by gxk3 with SMTP id 3so3498587gxk.31 for ; Tue, 13 Jul 2010 05:20:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.250.194 with SMTP id mp2mr9253794qcb.27.1279023625682; Tue, 13 Jul 2010 05:20:25 -0700 (PDT) Received: by 10.229.220.10 with HTTP; Tue, 13 Jul 2010 05:20:25 -0700 (PDT) Date: Tue, 13 Jul 2010 08:20:25 -0400 Message-ID: From: Peter Musgrave To: dispatch mailing list , Mary Barnes Content-Type: multipart/alternative; boundary=00163646d7c8de6ffc048b43e47b Subject: [dispatch] ViPR Charter V4- a suggestion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 12:20:31 -0000 --00163646d7c8de6ffc048b43e47b Content-Type: text/plain; charset=ISO-8859-1 Hi all, Here is a suggestion about changing the charter language which has been labeled 'political' to one which is more mechanistic. How do people feel about the paragraph below in place of the first two paras of the V4 charter (reproduced below). I think it needs more polish - but the idea is to not raise the issues of domains and ownership. A secure call to a SIP endpoint requires a knowledge of the endpoints URI and a shared secret. Each of these requirements has been an obstacle to widespread generic SIP calling. SIP URIs are not generally published or easily discoverable and there is no general mechanism for setting up security credentials in wide-spread use. Many SIP devices are also reachable by a PSTN number through a PSTN-SIP gateway. This allows SIP devices to both make and receive PSTN calls. The ViPR WG will develop a peer-to-peer mechanism which allows SIP endpoints to assert a relationship with PSTN numbers. Other SIP endpoints in the P2P overlay can determine if their calling destinations have an entity asserting a relationship with the target PSTN number and then use an initial PSTN call to confirm/re-confim the relationship. Issues relating to whether the first PSTN call is an isolated call or can be escalated to a direct, secure peer-to-peer SIP call will be investigated by the working group. Subsequent calls within some reasonable time scale can then be made directly using SIP. Peter Musgrave Existing first two paragraphs: There are two globally deployed address spaces for communications used by more than a billion people daily - phone numbers and DNS rooted address such as web servers and email addresses. The inter-domain signaling design of SIP is primarily designed for email style addresses yet a large percentage of SIP deployments mostly use phone numbers for identifying users, thus DNS lookups are not sufficient. Other approaches such as public ENUM are not sufficient due to lack of widespread deployment for non-technical reasons - i.e., the involvement of government and service provider administrative entities needing to approve and populate the registries. Private federations have been established to workaround the issue, however, that solution is not scalable. The goal of this working group is to enable inter-domain communications over the the Internet, using protocols such as SIP, while still allowing people to use phone numbers to identify the person with whom they wish to communicate. The VIPR WG will develop a peer to peer based approach to finding domains that claim to be responsible for a given phone number to mitigate the involvement of centralized entities to avoid some of the issues encountered by past attempts to support SIP inter-domain communications. Validation protocols will be developed to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. In this context, "responsible" means an administrative domain, which is at least one of the domains, to which a PSTN call to this phone number would be routed. Once the domain responsible for the phone number is found, existing protocols, such as SIP, can be used for inter-domain communications. --00163646d7c8de6ffc048b43e47b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,=A0

Here is a suggestion about changin= g the charter language which has been labeled 'political' to one wh= ich is more mechanistic.=A0

How do people feel abo= ut the paragraph below in place of the first two paras of the V4 charter (r= eproduced below). I think it needs more polish - but the idea is to not rai= se the issues of domains and ownership.=A0


A secure call to a SIP endpoint requires= a knowledge of the endpoints URI and a shared secret. Each of these requir= ements has been an obstacle to widespread generic SIP calling. SIP URIs are= not generally published or easily discoverable and there is no general mec= hanism for setting up security credentials in wide-spread use. Many SIP dev= ices are also reachable by a PSTN number through a PSTN-SIP gateway. This a= llows SIP devices to both make and receive PSTN calls. The ViPR WG will dev= elop a peer-to-peer mechanism which allows SIP endpoints to assert a relati= onship with PSTN numbers. Other SIP endpoints in the P2P overlay can determ= ine if their calling destinations have an entity asserting a relationship w= ith the target PSTN number and then use an initial PSTN call to confirm/re-= confim the relationship. Issues relating to whether the first PSTN call is = an isolated call or can be escalated to a direct, secure peer-to-peer SIP c= all will be investigated by the working group. Subsequent calls within some= reasonable time scale can then be made directly using SIP.=A0


Peter Musgrave


<= div>Existing first two paragraphs:
There are two globally deployed address spaces fo=
r communications used
by more than a billion people daily - phone numbers and DNS rooted
address such as web servers and email addresses. The inter-domain
signaling design of SIP is primarily designed for email style addresses
yet a large percentage of SIP deployments mostly use phone numbers for
identifying users, thus DNS lookups are not sufficient. Other approaches
such as public ENUM are not sufficient due to lack of widespread
deployment for non-technical reasons - i.e., the involvement of
government and service provider administrative entities needing to
approve and populate the registries.  Private federations have been
established to workaround the issue, however, that solution is not
scalable. The goal of this working group is to enable inter-domain
communications over the the Internet, using protocols such as SIP,
while still allowing people to use phone numbers to identify the person
with whom they wish to communicate.

The VIPR WG will develop a peer to peer based approach to finding
domains that claim to be responsible for a given phone number
to mitigate the involvement of centralized entities to avoid some of
the issues encountered by past attempts to support SIP inter-domain
communications. Validation protocols will be developed to ensure a
reasonable likelihood that a given domain actually is responsible for
the phone number. In this context, "responsible" means an
administrative domain, which is at least one of the domains, to which
a PSTN call to this phone number would be routed. Once the domain
responsible for the phone number is found, existing protocols, such
as SIP, can be used for inter-domain communications.
--00163646d7c8de6ffc048b43e47b-- From maltarai@cisco.com Tue Jul 13 07:40:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B947E3A6848 for ; Tue, 13 Jul 2010 07:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXqrftjdCxyc for ; Tue, 13 Jul 2010 07:40:02 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E599B3A6803 for ; Tue, 13 Jul 2010 07:40:01 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANsXPEytJV2d/2dsb2JhbACfZXGkT5ppgl6CSQSDfYcB X-IronPort-AV: E=Sophos;i="4.55,195,1278288000"; d="scan'208,217";a="131834359" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2010 14:40:10 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o6DEeAlr006757; Tue, 13 Jul 2010 14:40:10 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 09:40:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2299.4B5D3830" Date: Tue, 13 Jul 2010 09:40:08 -0500 Message-ID: <04CA7DCC63584C4D8967FF818D80965B01BB8F15@XMB-RCD-113.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] ViPR Charter V4- a suggestion Thread-Index: AcsihdJ7c2oIJ738QL2neCQejCUm1wAERubw References: From: "Mohammad Al-Taraireh (maltarai)" To: "Peter Musgrave" , "dispatch mailing list" , "Mary Barnes" X-OriginalArrivalTime: 13 Jul 2010 14:40:10.0247 (UTC) FILETIME=[4B83F170:01CB2299] Subject: Re: [dispatch] ViPR Charter V4- a suggestion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 14:40:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2299.4B5D3830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Excellent now we are getting some where :-). I think that is a good start.=20 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Musgrave Sent: Tuesday, July 13, 2010 8:20 AM To: dispatch mailing list; Mary Barnes Subject: [dispatch] ViPR Charter V4- a suggestion Hi all,=20 Here is a suggestion about changing the charter language which has been labeled 'political' to one which is more mechanistic.=20 How do people feel about the paragraph below in place of the first two paras of the V4 charter (reproduced below). I think it needs more polish - but the idea is to not raise the issues of domains and ownership.=20 A secure call to a SIP endpoint requires a knowledge of the endpoints URI and a shared secret. Each of these requirements has been an obstacle to widespread generic SIP calling. SIP URIs are not generally published or easily discoverable and there is no general mechanism for setting up security credentials in wide-spread use. Many SIP devices are also reachable by a PSTN number through a PSTN-SIP gateway. This allows SIP devices to both make and receive PSTN calls. The ViPR WG will develop a peer-to-peer mechanism which allows SIP endpoints to assert a relationship with PSTN numbers. Other SIP endpoints in the P2P overlay can determine if their calling destinations have an entity asserting a relationship with the target PSTN number and then use an initial PSTN call to confirm/re-confim the relationship. Issues relating to whether the first PSTN call is an isolated call or can be escalated to a direct, secure peer-to-peer SIP call will be investigated by the working group. Subsequent calls within some reasonable time scale can then be made directly using SIP.=20 Peter Musgrave Existing first two paragraphs: There are two globally deployed address spaces for communications used by more than a billion people daily - phone numbers and DNS rooted address such as web servers and email addresses. The inter-domain signaling design of SIP is primarily designed for email style addresses yet a large percentage of SIP deployments mostly use phone numbers for identifying users, thus DNS lookups are not sufficient. Other approaches such as public ENUM are not sufficient due to lack of widespread deployment for non-technical reasons - i.e., the involvement of government and service provider administrative entities needing to approve and populate the registries. Private federations have been established to workaround the issue, however, that solution is not scalable. The goal of this working group is to enable inter-domain communications over the the Internet, using protocols such as SIP, while still allowing people to use phone numbers to identify the person with whom they wish to communicate. The VIPR WG will develop a peer to peer based approach to finding domains that claim to be responsible for a given phone number to mitigate the involvement of centralized entities to avoid some of the issues encountered by past attempts to support SIP inter-domain communications. Validation protocols will be developed to ensure a reasonable likelihood that a given domain actually is responsible for the phone number. In this context, "responsible" means an administrative domain, which is at least one of the domains, to which a PSTN call to this phone number would be routed. Once the domain responsible for the phone number is found, existing protocols, such as SIP, can be used for inter-domain communications. ------_=_NextPart_001_01CB2299.4B5D3830 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Excellent now we are getting some where :-). I = think that is a=20 good start.

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter=20 Musgrave
Sent: Tuesday, July 13, 2010 8:20 AM
To: = dispatch=20 mailing list; Mary Barnes
Subject: [dispatch] ViPR Charter V4- = a=20 suggestion

Hi all, 

Here is a suggestion about changing the charter language which has = been=20 labeled 'political' to one which is more mechanistic. 

How do people feel about the paragraph below in place of the first = two=20 paras of the V4 charter (reproduced below). I think it needs more polish = - but=20 the idea is to not raise the issues of domains and = ownership. 


A secure call to a SIP endpoint requires a knowledge of the = endpoints URI=20 and a shared secret. Each of these requirements has been an obstacle to=20 widespread generic SIP calling. SIP URIs are not generally published or = easily=20 discoverable and there is no general mechanism for setting up security=20 credentials in wide-spread use. Many SIP devices are also reachable by a = PSTN=20 number through a PSTN-SIP gateway. This allows SIP devices to both make = and=20 receive PSTN calls. The ViPR WG will develop a peer-to-peer mechanism = which=20 allows SIP endpoints to assert a relationship with PSTN numbers. Other = SIP=20 endpoints in the P2P overlay can determine if their calling destinations = have an=20 entity asserting a relationship with the target PSTN number and then use = an=20 initial PSTN call to confirm/re-confim the relationship. Issues relating = to=20 whether the first PSTN call is an isolated call or can be escalated to a = direct,=20 secure peer-to-peer SIP call will be investigated by the working group.=20 Subsequent calls within some reasonable time scale can then be made = directly=20 using SIP. 


Peter Musgrave


Existing first two paragraphs:
There =
are two globally deployed address spaces for communications used
by more than a billion people daily - phone numbers and DNS rooted
address such as web servers and email addresses. The inter-domain
signaling design of SIP is primarily designed for email style addresses
yet a large percentage of SIP deployments mostly use phone numbers for
identifying users, thus DNS lookups are not sufficient. Other approaches
such as public ENUM are not sufficient due to lack of widespread
deployment for non-technical reasons - i.e., the involvement of
government and service provider administrative entities needing to
approve and populate the registries.  Private federations have been
established to workaround the issue, however, that solution is not
scalable. The goal of this working group is to enable inter-domain
communications over the the Internet, using protocols such as SIP,
while still allowing people to use phone numbers to identify the person
with whom they wish to communicate.

The VIPR WG will develop a peer to peer based approach to finding
domains that claim to be responsible for a given phone number
to mitigate the involvement of centralized entities to avoid some of
the issues encountered by past attempts to support SIP inter-domain
communications. Validation protocols will be developed to ensure a
reasonable likelihood that a given domain actually is responsible for
the phone number. In this context, "responsible" means an
administrative domain, which is at least one of the domains, to which
a PSTN call to this phone number would be routed. Once the domain
responsible for the phone number is found, existing protocols, such
as SIP, can be used for inter-domain =
communications.
------_=_NextPart_001_01CB2299.4B5D3830-- From HKaplan@acmepacket.com Tue Jul 13 09:37:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 394E73A696F for ; Tue, 13 Jul 2010 09:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLJ470kDFZMV for ; Tue, 13 Jul 2010 09:37:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 076BF3A6848 for ; Tue, 13 Jul 2010 09:37:40 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 13 Jul 2010 12:37:44 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 13 Jul 2010 12:37:44 -0400 From: Hadriel Kaplan To: "dispatch@ietf.org" Date: Tue, 13 Jul 2010 12:37:41 -0400 Thread-Topic: Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsiqbaMfHyiLn9KSoGceaY0EYk4fw== Message-ID: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> 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_430FC6BDED356B4C8498F634416644A91FE8964124mail_" MIME-Version: 1.0 Subject: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 16:37:42 -0000 --_000_430FC6BDED356B4C8498F634416644A91FE8964124mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Howdy, I submitted an updated version of the session-id draft, for consideration a= s a solution for the (hopefully) new WG for such purpose. The major changes are: 1) Reverted the generation of the session-id value to be a defined 128-b= it hash mechanism, as it was prior to version 1, based on feedback that hav= ing it be a known algorithm allows a monitoring system with the same privat= e key to generate the value itself for matching purposes. 2) Added a section on transfer handling, for REFER and INVITE-with-Repla= ces, such that a transferred call uses the same session-id. This section i= s just a beginning strawman and will need more thought. A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A Session Identifier for the Session Initiation Pro= tocol (SIP) Author(s) : H. Kaplan Filename : draft-kaplan-dispatch-session-id-02.txt Pages : 13 Date : 2010-07-12 There is a need for having a globally unique session identifier for the sam= e SIP session, which can be consistently maintained across Proxies, B2BUAs = and other SIP middle-boxes, for the purpose of Troubleshooting. This draft= proposes a new SIP header to carry such a value: Session-ID. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id-02.txt --_000_430FC6BDED356B4C8498F634416644A91FE8964124mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Howdy,

I submitted an updated version of the session-id draft, for consideration as a solution for the (hopefully) new WG for such purpose.

 

The major changes are:=

1)    Reverted the generatio= n of the session-id value to be a defined 128-bit hash mechanism, as it was prio= r to version 1, based on feedback that having it be a known algorithm allows a monitoring system with the same private key to generate the value itself fo= r matching purposes.

2)    Added a section on tra= nsfer handling, for REFER and INVITE-with-Replaces, such that a transferred call uses the s= ame session-id.  This section is just a beginning strawman and will need m= ore thought.

 

 

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

 

   &nbs= p;  Title           : A Session Identifier for the Session Initiation Protocol (SIP)=

   &nbs= p;  Author(s)       : H. Kaplan

   &nbs= p;  Filename        : draft-kaplan-dispatch-session-id-02.txt

   &nbs= p;  Pages           : 13

   &nbs= p;  Date          &n= bsp; : 2010-07-12

 

There is a need for ha= ving a globally unique session identifier for the same SIP session, which can be consistently maintained across Proxies, B2BUAs and other SIP middle-boxes, = for the purpose of Troubleshooting.  This draft proposes a new SIP header = to carry such a value: Session-ID.

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session= -id-02.txt

 

 

--_000_430FC6BDED356B4C8498F634416644A91FE8964124mail_-- From vkg@bell-labs.com Tue Jul 13 11:23:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 436403A6B4B; Tue, 13 Jul 2010 11:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bnr5XT5bbOim; Tue, 13 Jul 2010 11:22:59 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id 132233A6B2E; Tue, 13 Jul 2010 11:22:58 -0700 (PDT) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o6DIN6Ds004581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jul 2010 13:23:06 -0500 (CDT) Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id o6DIN666021983; Tue, 13 Jul 2010 13:23:06 -0500 (CDT) Message-ID: <4C3CAF6E.50003@bell-labs.com> Date: Tue, 13 Jul 2010 13:24:46 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Mailman-Approved-At: Tue, 13 Jul 2010 11:50:25 -0700 Cc: "sip-clf@ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 18:23:00 -0000 On 07/13/2010 11:37 AM, Hadriel Kaplan wrote: > There is a need for having a globally unique session identifier for the > same SIP session, which can be consistently maintained across Proxies, > B2BUAs and other SIP middle-boxes, for the purpose of Troubleshooting. > This draft proposes a new SIP header to carry such a value: Session-ID. > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id-02.txt Hadriel: I know are aware of this, but to point this work out to the broader audience in the sipclf WG ... another use of the Session-ID header can conceivably include the end-to-end tracing of sessions that cross administrative domains. We have talked about this in the sipclf WG. Session-ID can appear as one of the extension headers in the SIP CLF record. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} Web: http://ect.bell-labs.com/who/vkg/ From HKaplan@acmepacket.com Tue Jul 13 12:07:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E883A6B2E; Tue, 13 Jul 2010 12:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaN2PjA8WFCg; Tue, 13 Jul 2010 12:07:31 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8C6163A69C5; Tue, 13 Jul 2010 12:07:31 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 13 Jul 2010 15:07:39 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 13 Jul 2010 15:07:39 -0400 From: Hadriel Kaplan To: "Vijay K. Gurbani" Date: Tue, 13 Jul 2010 15:07:38 -0400 Thread-Topic: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsiuHrfEhRElMUBRAyLNtNAT0EmGQABdqvQ Message-ID: <430FC6BDED356B4C8498F634416644A91FE89641AD@mail> References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> <4C3CAF6E.50003@bell-labs.com> In-Reply-To: <4C3CAF6E.50003@bell-labs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip-clf@ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 19:07:32 -0000 Yup, and we have it indicated as one of the recorded fields in the Ipfix-ba= sed sipclf I-D, in the draft-niccolini-sipclf-ipfix-03. (though of course t= hat's just a strawman list of fields right now anyway) -hadriel > -----Original Message----- > From: Vijay K. Gurbani [mailto:vkg@bell-labs.com] > Sent: Tuesday, July 13, 2010 2:25 PM > To: Hadriel Kaplan > Cc: dispatch@ietf.org; sip-clf@ietf.org > Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 >=20 > On 07/13/2010 11:37 AM, Hadriel Kaplan wrote: > > There is a need for having a globally unique session identifier for the > > same SIP session, which can be consistently maintained across Proxies, > > B2BUAs and other SIP middle-boxes, for the purpose of Troubleshooting. > > This draft proposes a new SIP header to carry such a value: Session-ID. >=20 > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id- > 02.txt >=20 > Hadriel: I know are aware of this, but to point this work > out to the broader audience in the sipclf WG ... another use of > the Session-ID header can conceivably include the end-to-end > tracing of sessions that cross administrative domains. We have > talked about this in the sipclf WG. >=20 > Session-ID can appear as one of the extension headers in the > SIP CLF record. >=20 > Thanks, >=20 > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org} > Web: http://ect.bell-labs.com/who/vkg/ From gonzalo.camarillo@ericsson.com Tue Jul 13 23:53:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE083A67C2 for ; Tue, 13 Jul 2010 23:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.308 X-Spam-Level: X-Spam-Status: No, score=-105.308 tagged_above=-999 required=5 tests=[AWL=0.941, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgKL2Yonjoju for ; Tue, 13 Jul 2010 23:53:21 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 834C23A67F7 for ; Tue, 13 Jul 2010 23:53:20 -0700 (PDT) X-AuditID: c1b4fb24-b7c56ae000001038-16-4c3d5ee84b2f Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 84.6E.04152.8EE5D3C4; Wed, 14 Jul 2010 08:53:28 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jul 2010 08:53:28 +0200 Received: from [131.160.126.225] ([131.160.126.225]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jul 2010 08:53:27 +0200 Message-ID: <4C3D5EE7.2000305@ericsson.com> Date: Wed, 14 Jul 2010 09:53:27 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2010 06:53:27.0867 (UTC) FILETIME=[433598B0:01CB2321] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] The SALUD WG has been created to work on alerting URNs X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 06:53:22 -0000 Folks, the SALUD WG has just been created. As you know, this WG came out of DISPATCH. Dale, in the cc:, is going to be chairing this WG: https://datatracker.ietf.org/wg/salud/charter/ If you are interested in this work, subscribing to the SALUD mailing list would be a good start. Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Wed Jul 14 08:10:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F6973A67B4; Wed, 14 Jul 2010 08:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.577 X-Spam-Level: X-Spam-Status: No, score=-105.577 tagged_above=-999 required=5 tests=[AWL=0.672, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmyVAr58NPhx; Wed, 14 Jul 2010 08:10:41 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 7E1E23A67AF; Wed, 14 Jul 2010 08:10:40 -0700 (PDT) X-AuditID: c1b4fb24-b7c56ae000001038-1e-4c3dd37985fd Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 37.78.04152.973DD3C4; Wed, 14 Jul 2010 17:10:49 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jul 2010 17:10:49 +0200 Received: from [131.160.126.225] ([131.160.126.225]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jul 2010 17:10:48 +0200 Message-ID: <4C3DD378.9020401@ericsson.com> Date: Wed, 14 Jul 2010 18:10:48 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Cullen Jennings References: <4C28F980.3040702@ericsson.com> <0010F1C2-2436-474D-BC1C-05AFC8A9E4C5@cisco.com> In-Reply-To: <0010F1C2-2436-474D-BC1C-05AFC8A9E4C5@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2010 15:10:48.0942 (UTC) FILETIME=[BDE048E0:01CB2366] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list , IESG IESG , IETF-Discussion list Subject: Re: [dispatch] WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 15:10:42 -0000 Hi, thanks for your comments on the charter proposal. Per the comments received, we will modify bullet 5 as follows so that it is clearer: OLD: 5. SIP elements may need to apply policy about passing and screening the information. NEW: 5. SIP elements may need to apply policy about passing and filtering UUI. The included application, encoding, semantics, and content information will allow endpoint or intermediary SIP elements to allow or block UUI based on the type and originator, not based on the actual UUI data, which may be end-to-end encrypted by the application. Further discussions on this topic should happen on the mailing list of this WG. Cheers, Gonzalo From gcamaril@gmail.com Wed Jul 14 01:26:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5FAC3A6855; Wed, 14 Jul 2010 01:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToXaf3kun3qS; Wed, 14 Jul 2010 01:26:33 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 80AE13A69CB; Wed, 14 Jul 2010 01:26:21 -0700 (PDT) X-AuditID: c1b4fb24-b7c56ae000001038-f8-4c3d7498ffa0 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Mail Security) with SMTP id 04.7B.04152.8947D3C4; Wed, 14 Jul 2010 10:26:00 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jul 2010 10:26:00 +0200 Received: from [131.160.126.225] ([131.160.126.225]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Jul 2010 10:25:58 +0200 Message-ID: <4C3D7496.8020905@gmail.com> Date: Wed, 14 Jul 2010 11:25:58 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Cullen Jennings References: <4C28F980.3040702@ericsson.com> <0010F1C2-2436-474D-BC1C-05AFC8A9E4C5@cisco.com> In-Reply-To: <0010F1C2-2436-474D-BC1C-05AFC8A9E4C5@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2010 08:25:59.0633 (UTC) FILETIME=[3051DC10:01CB232E] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Wed, 14 Jul 2010 08:49:42 -0700 Cc: DISPATCH list , IESG IESG , IETF-Discussion list Subject: Re: [dispatch] WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 08:26:34 -0000 Hi, thanks for your comments on the charter proposal. Per the comments received, we will modify bullet 5 as follows so that it is clearer: OLD: 5. SIP elements may need to apply policy about passing and screening the information. NEW: 5. SIP elements may need to apply policy about passing and filtering UUI. The included application, encoding, semantics, and content information will allow endpoint or intermediary SIP elements to allow or block UUI based on the type and originator, not based on the actual UUI data, which may be end-to-end encrypted by the application. Further discussions on this topic should happen on the mailing list of this WG. Cheers, Gonzalo From D.Malas@cablelabs.com Wed Jul 14 15:44:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02DCD3A6895 for ; Wed, 14 Jul 2010 15:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bz4fDh0EDp-W for ; Wed, 14 Jul 2010 15:44:52 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id ACD953A684D for ; Wed, 14 Jul 2010 15:44:52 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o6EMj1N9010153 for ; Wed, 14 Jul 2010 16:45:01 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Wed, 14 Jul 2010 16:45:01 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Wed, 14 Jul 2010 16:45:02 -0600 From: Daryl Malas To: DISPATCH list Date: Wed, 14 Jul 2010 16:45:01 -0600 Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: Acse+x6HePYsIGebRkGv9hhtpmUqCwAm5ElqAQNK4IA= Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg> References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 22:44:54 -0000 All, Many if not all of the functions of an SBC have already been defined in one= way or another. An SBC is a "jack-of-all-trades" platform. I think this = is a slippery slope to try and define, and is a quagmire the IETF should st= ray from. In some cases, SBCs are not even deployed on the edge of network= s. I agree that a B2BUA is different, but it could be considered a function of= the SBC. B2BUA's were created with the intention of breaking up the end-t= o-end environment, so creating rules to define allowances for the end-to-en= d environment will be challenging at best. Regards, Daryl -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Christer Holmberg Sent: Friday, July 09, 2010 12:44 PM To: Paul Kyzivat; Mohammad Al-Taraireh (maltarai) Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? Hi, Rather than focus on node terminology, I think we should focus on the FUNCT= IONS they perform, and see whether something can do done in order to avoid = claimed interop problems etc, rather than arguing about whether the entity = that performs the function shall be called B2BUA, SBC, Application Server, = or something else... Regards, Christer ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Pa= ul Kyzivat [pkyzivat@cisco.com] Sent: Friday, July 09, 2010 3:10 AM To: Mohammad Al-Taraireh (maltarai) Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? Mohammad Al-Taraireh (maltarai) wrote: > Doesn't the B2BUA term also implies media origination, and termination=20 > capabilities ? It seems that the B2BUA term is already overloaded to=20 > include SBC. The term "B2BUA" is distinguished by the minimality of its definition and t= he corresponding broadness of applicability. It neither implies nor forbids= media processing. The term SBC, as typically used, is somewhat narrower in scope that B2BUA, = but is still incredibly broad. I certainly know of things that consider the= mselves to be SBCs that (at least sometimes) don't terminate media. And certainly there are B2BUAs that *do* terminate media that you would not= want to call an SBC. (E.g. a conference focus and mixer.) Thanks, Paul > Mo > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of Dan Wing (dwing) > Sent: Thursday, July 08, 2010 5:31 PM > To: Cullen Jennings (fluffy) > Cc: 'DISPATCH list' > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com] >> Sent: Thursday, July 08, 2010 1:34 PM >> To: Dan Wing >> Cc: DISPATCH list >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >> >> >> Seems reasonable. I think B2BUA is reasonable well defined. Care to=20 >> put on your fire proof suit and propose a definition of what an SBC > is? > > SBC: a B2BUA that also terminates and originates media from user > agents or media from an adjacent SBC. > > -d > > >> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >> >>>> -----Original Message----- >>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>> Sent: Thursday, July 08, 2010 5:50 AM >>>> To: Dan Wing >>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>> >>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes >>>> - >> 03 >>>> has just been submitted. >>> Splendid. I refer to the media latching in that document > frequently. >>> Myself, I would be happier if IETF could find it possible to include > >>> the acronym-that-must-not-be-spoken (SBC) in SBC-related=20 >>> specifications -- no matter if an SBC working group is formed or=20 >>> not. Calling them 'middleboxes' is too vague to be useful, much=20 >>> like "gateway" is too vague (a gateway to the PSTN? a router?) Call > >>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC an=20 >>> SBC. >>> >>> -d >>> >>> >>>> Dan Wing wrote: >>>>>> -----Original Message----- >>>>>> From: dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] >>>> On >>>>>> Behalf Of Peter Musgrave >>>>>> Sent: Thursday, July 01, 2010 12:30 PM >>>>>> To: WORLEY, Dale R (Dale) >>>>>> Cc: DISPATCH list >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>> >>>>>> I concur. >>>>>> >>>>>> There is some useful background in RFC5853 and perhaps=20 >>>>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 >>>>>> >>>>>> And then some things which died on the vine such as: >>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>>>> and perhaps some others? >>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >> middleboxes- >>>> 02 died. >>>>> -d >>>> ... >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >> >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> > > > _______________________________________________ > 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 From pkyzivat@cisco.com Wed Jul 14 15:53:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6679B3A684D for ; Wed, 14 Jul 2010 15:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.432 X-Spam-Level: X-Spam-Status: No, score=-10.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZDRQLitEGrk for ; Wed, 14 Jul 2010 15:53:27 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 004EF3A6814 for ; Wed, 14 Jul 2010 15:53:26 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD3cPUxAZnwM/2dsb2JhbACfdHGlTJpkhSQEiFA X-IronPort-AV: E=Sophos;i="4.55,204,1278288000"; d="scan'208";a="132505539" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 14 Jul 2010 22:53:36 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6EMraRG020137; Wed, 14 Jul 2010 22:53:36 GMT Message-ID: <4C3E3FF6.1050003@cisco.com> Date: Wed, 14 Jul 2010 18:53:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Daryl Malas References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com> <114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg> In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jul 2010 22:53:28 -0000 I won't comment on the rest of this right now, but its not right to describe a B2BUA as a function of an SBC. Rather, an SBC is a particular sort of B2BUA. There are *many* sorts of B2BUA that have nothing in common with an SBC. Its actually this sort of disagreement that would benefit from beginning a taxonomy of B2BUAs. Thanks, Paul Daryl Malas wrote: > All, > > Many if not all of the functions of an SBC have already been defined in one way or another. An SBC is a "jack-of-all-trades" platform. I think this is a slippery slope to try and define, and is a quagmire the IETF should stray from. In some cases, SBCs are not even deployed on the edge of networks. > > I agree that a B2BUA is different, but it could be considered a function of the SBC. B2BUA's were created with the intention of breaking up the end-to-end environment, so creating rules to define allowances for the end-to-end environment will be challenging at best. > > Regards, > > Daryl > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Friday, July 09, 2010 12:44 PM > To: Paul Kyzivat; Mohammad Al-Taraireh (maltarai) > Cc: DISPATCH list > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > Hi, > > Rather than focus on node terminology, I think we should focus on the FUNCTIONS they perform, and see whether something can do done in order to avoid claimed interop problems etc, rather than arguing about whether the entity that performs the function shall be called B2BUA, SBC, Application Server, or something else... > > Regards, > > Christer > > > > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > Sent: Friday, July 09, 2010 3:10 AM > To: Mohammad Al-Taraireh (maltarai) > Cc: DISPATCH list > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > Mohammad Al-Taraireh (maltarai) wrote: >> Doesn't the B2BUA term also implies media origination, and termination >> capabilities ? It seems that the B2BUA term is already overloaded to >> include SBC. > > The term "B2BUA" is distinguished by the minimality of its definition and the corresponding broadness of applicability. It neither implies nor forbids media processing. > > The term SBC, as typically used, is somewhat narrower in scope that B2BUA, but is still incredibly broad. I certainly know of things that consider themselves to be SBCs that (at least sometimes) don't terminate media. > > And certainly there are B2BUAs that *do* terminate media that you would not want to call an SBC. (E.g. a conference focus and mixer.) > > Thanks, > Paul > >> Mo >> >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Dan Wing (dwing) >> Sent: Thursday, July 08, 2010 5:31 PM >> To: Cullen Jennings (fluffy) >> Cc: 'DISPATCH list' >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >> >>> -----Original Message----- >>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>> Sent: Thursday, July 08, 2010 1:34 PM >>> To: Dan Wing >>> Cc: DISPATCH list >>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>> >>> >>> Seems reasonable. I think B2BUA is reasonable well defined. Care to >>> put on your fire proof suit and propose a definition of what an SBC >> is? >> >> SBC: a B2BUA that also terminates and originates media from user >> agents or media from an adjacent SBC. >> >> -d >> >> >>> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >>> >>>>> -----Original Message----- >>>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>>> Sent: Thursday, July 08, 2010 5:50 AM >>>>> To: Dan Wing >>>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' >>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes >>>>> - >>> 03 >>>>> has just been submitted. >>>> Splendid. I refer to the media latching in that document >> frequently. >>>> Myself, I would be happier if IETF could find it possible to include >>>> the acronym-that-must-not-be-spoken (SBC) in SBC-related >>>> specifications -- no matter if an SBC working group is formed or >>>> not. Calling them 'middleboxes' is too vague to be useful, much >>>> like "gateway" is too vague (a gateway to the PSTN? a router?) Call >>>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC an >>>> SBC. >>>> >>>> -d >>>> >>>> >>>>> Dan Wing wrote: >>>>>>> -----Original Message----- >>>>>>> From: dispatch-bounces@ietf.org >>>>>>> [mailto:dispatch-bounces@ietf.org] >>>>> On >>>>>>> Behalf Of Peter Musgrave >>>>>>> Sent: Thursday, July 01, 2010 12:30 PM >>>>>>> To: WORLEY, Dale R (Dale) >>>>>>> Cc: DISPATCH list >>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>> >>>>>>> I concur. >>>>>>> >>>>>>> There is some useful background in RFC5853 and perhaps >>>>>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 >>>>>>> >>>>>>> And then some things which died on the vine such as: >>>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>>>>> and perhaps some others? >>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >>> middleboxes- >>>>> 02 died. >>>>>> -d >>>>> ... >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>> Cullen Jennings >>> For corporate legal information go to: >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>> >> >> _______________________________________________ >> 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From tme@americafree.tv Wed Jul 14 17:05:30 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE3FD3A687F for ; Wed, 14 Jul 2010 17:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbrvJrPW1Xcd for ; Wed, 14 Jul 2010 17:05:27 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 9BEBD3A6807 for ; Wed, 14 Jul 2010 17:05:27 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id F07EA7F43529; Wed, 14 Jul 2010 20:05:36 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Paul Kyzivat In-Reply-To: <4C3E3FF6.1050003@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 14 Jul 2010 20:05:32 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com> <114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg> <4C3E3FF6.1050003@cisco.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 00:05:30 -0000 Should we arrange a (true) Bar BOF (AKA DrinkTime) for this topic in Maastricht ? Marshall On Jul 14, 2010, at 6:53 PM, Paul Kyzivat wrote: > I won't comment on the rest of this right now, > but its not right to describe a B2BUA as a function of an SBC. > Rather, an SBC is a particular sort of B2BUA. > There are *many* sorts of B2BUA that have nothing in common with an > SBC. > > Its actually this sort of disagreement that would benefit from > beginning a taxonomy of B2BUAs. > > Thanks, > Paul > > Daryl Malas wrote: >> All, >> Many if not all of the functions of an SBC have already been >> defined in one way or another. An SBC is a "jack-of-all-trades" >> platform. I think this is a slippery slope to try and define, and >> is a quagmire the IETF should stray from. In some cases, SBCs are >> not even deployed on the edge of networks. >> I agree that a B2BUA is different, but it could be considered a >> function of the SBC. B2BUA's were created with the intention of >> breaking up the end-to-end environment, so creating rules to define >> allowances for the end-to-end environment will be challenging at >> best. >> Regards, >> Daryl >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >> On Behalf Of Christer Holmberg >> Sent: Friday, July 09, 2010 12:44 PM >> To: Paul Kyzivat; Mohammad Al-Taraireh (maltarai) >> Cc: DISPATCH list >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >> Hi, >> Rather than focus on node terminology, I think we should focus on >> the FUNCTIONS they perform, and see whether something can do done >> in order to avoid claimed interop problems etc, rather than arguing >> about whether the entity that performs the function shall be called >> B2BUA, SBC, Application Server, or something else... >> Regards, >> Christer >> ________________________________________ >> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On >> Behalf Of Paul Kyzivat [pkyzivat@cisco.com] >> Sent: Friday, July 09, 2010 3:10 AM >> To: Mohammad Al-Taraireh (maltarai) >> Cc: DISPATCH list >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >> Mohammad Al-Taraireh (maltarai) wrote: >>> Doesn't the B2BUA term also implies media origination, and >>> termination capabilities ? It seems that the B2BUA term is already >>> overloaded to include SBC. >> The term "B2BUA" is distinguished by the minimality of its >> definition and the corresponding broadness of applicability. It >> neither implies nor forbids media processing. >> The term SBC, as typically used, is somewhat narrower in scope that >> B2BUA, but is still incredibly broad. I certainly know of things >> that consider themselves to be SBCs that (at least sometimes) don't >> terminate media. >> And certainly there are B2BUAs that *do* terminate media that you >> would not want to call an SBC. (E.g. a conference focus and mixer.) >> Thanks, >> Paul >>> Mo >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >>> On Behalf Of Dan Wing (dwing) >>> Sent: Thursday, July 08, 2010 5:31 PM >>> To: Cullen Jennings (fluffy) >>> Cc: 'DISPATCH list' >>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>> >>>> -----Original Message----- >>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>> Sent: Thursday, July 08, 2010 1:34 PM >>>> To: Dan Wing >>>> Cc: DISPATCH list >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>> >>>> >>>> Seems reasonable. I think B2BUA is reasonable well defined. Care >>>> to put on your fire proof suit and propose a definition of what >>>> an SBC >>> is? >>> >>> SBC: a B2BUA that also terminates and originates media from user >>> agents or media from an adjacent SBC. >>> >>> -d >>> >>> >>>> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >>>> >>>>>> -----Original Message----- >>>>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>>>> Sent: Thursday, July 08, 2010 5:50 AM >>>>>> To: Dan Wing >>>>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes >>>>>> - >>>> 03 >>>>>> has just been submitted. >>>>> Splendid. I refer to the media latching in that document >>> frequently. >>>>> Myself, I would be happier if IETF could find it possible to >>>>> include >>>>> the acronym-that-must-not-be-spoken (SBC) in SBC-related >>>>> specifications -- no matter if an SBC working group is formed or >>>>> not. Calling them 'middleboxes' is too vague to be useful, much >>>>> like "gateway" is too vague (a gateway to the PSTN? a router?) >>>>> Call >>>>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC >>>>> an SBC. >>>>> >>>>> -d >>>>> >>>>> >>>>>> Dan Wing wrote: >>>>>>>> -----Original Message----- >>>>>>>> From: dispatch-bounces@ietf.org >>>>>>>> [mailto:dispatch-bounces@ietf.org] >>>>>> On >>>>>>>> Behalf Of Peter Musgrave >>>>>>>> Sent: Thursday, July 01, 2010 12:30 PM >>>>>>>> To: WORLEY, Dale R (Dale) >>>>>>>> Cc: DISPATCH list >>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>>> >>>>>>>> I concur. >>>>>>>> >>>>>>>> There is some useful background in RFC5853 and perhaps http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 >>>>>>>> >>>>>>>> And then some things which died on the vine such as: >>>>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>>>>>> and perhaps some others? >>>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >>>> middleboxes- >>>>>> 02 died. >>>>>>> -d >>>>>> ... >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> Cullen Jennings >>>> For corporate legal information go to: >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>> >>> >>> _______________________________________________ >>> 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 >> _______________________________________________ >> 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@cisco.com Wed Jul 14 17:20:57 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E9E3A69BC for ; Wed, 14 Jul 2010 17:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.437 X-Spam-Level: X-Spam-Status: No, score=-10.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SYRPufxPYu0 for ; Wed, 14 Jul 2010 17:20:55 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7D1D33A6859 for ; Wed, 14 Jul 2010 17:20:55 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIfxPUxAZnwM/2dsb2JhbACfdHGlQZpghSQEiFA X-IronPort-AV: E=Sophos;i="4.55,204,1278288000"; d="scan'208";a="132501284" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2010 00:21:05 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6F0L5JZ015683; Thu, 15 Jul 2010 00:21:05 GMT Message-ID: <4C3E5485.3000907@cisco.com> Date: Wed, 14 Jul 2010 20:21:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Marshall Eubanks References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com> <114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg> <4C3E3FF6.1050003@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 00:20:57 -0000 Marshall Eubanks wrote: > Should we arrange a (true) Bar BOF (AKA DrinkTime) for this topic in > Maastricht ? I'm open to that, unless I run into conflicts. (I'm too busy and unmotivated to do any organization of it.) Thanks, Paul > Marshall > > On Jul 14, 2010, at 6:53 PM, Paul Kyzivat wrote: > >> I won't comment on the rest of this right now, >> but its not right to describe a B2BUA as a function of an SBC. >> Rather, an SBC is a particular sort of B2BUA. >> There are *many* sorts of B2BUA that have nothing in common with an SBC. >> >> Its actually this sort of disagreement that would benefit from >> beginning a taxonomy of B2BUAs. >> >> Thanks, >> Paul >> >> Daryl Malas wrote: >>> All, >>> Many if not all of the functions of an SBC have already been defined >>> in one way or another. An SBC is a "jack-of-all-trades" platform. I >>> think this is a slippery slope to try and define, and is a quagmire >>> the IETF should stray from. In some cases, SBCs are not even >>> deployed on the edge of networks. >>> I agree that a B2BUA is different, but it could be considered a >>> function of the SBC. B2BUA's were created with the intention of >>> breaking up the end-to-end environment, so creating rules to define >>> allowances for the end-to-end environment will be challenging at best. >>> Regards, >>> Daryl >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Christer Holmberg >>> Sent: Friday, July 09, 2010 12:44 PM >>> To: Paul Kyzivat; Mohammad Al-Taraireh (maltarai) >>> Cc: DISPATCH list >>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>> Hi, >>> Rather than focus on node terminology, I think we should focus on the >>> FUNCTIONS they perform, and see whether something can do done in >>> order to avoid claimed interop problems etc, rather than arguing >>> about whether the entity that performs the function shall be called >>> B2BUA, SBC, Application Server, or something else... >>> Regards, >>> Christer >>> ________________________________________ >>> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf >>> Of Paul Kyzivat [pkyzivat@cisco.com] >>> Sent: Friday, July 09, 2010 3:10 AM >>> To: Mohammad Al-Taraireh (maltarai) >>> Cc: DISPATCH list >>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>> Mohammad Al-Taraireh (maltarai) wrote: >>>> Doesn't the B2BUA term also implies media origination, and >>>> termination capabilities ? It seems that the B2BUA term is already >>>> overloaded to include SBC. >>> The term "B2BUA" is distinguished by the minimality of its definition >>> and the corresponding broadness of applicability. It neither implies >>> nor forbids media processing. >>> The term SBC, as typically used, is somewhat narrower in scope that >>> B2BUA, but is still incredibly broad. I certainly know of things that >>> consider themselves to be SBCs that (at least sometimes) don't >>> terminate media. >>> And certainly there are B2BUAs that *do* terminate media that you >>> would not want to call an SBC. (E.g. a conference focus and mixer.) >>> Thanks, >>> Paul >>>> Mo >>>> >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >>>> On Behalf Of Dan Wing (dwing) >>>> Sent: Thursday, July 08, 2010 5:31 PM >>>> To: Cullen Jennings (fluffy) >>>> Cc: 'DISPATCH list' >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>> >>>>> -----Original Message----- >>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>> Sent: Thursday, July 08, 2010 1:34 PM >>>>> To: Dan Wing >>>>> Cc: DISPATCH list >>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>> >>>>> >>>>> Seems reasonable. I think B2BUA is reasonable well defined. Care to >>>>> put on your fire proof suit and propose a definition of what an SBC >>>> is? >>>> >>>> SBC: a B2BUA that also terminates and originates media from user >>>> agents or media from an adjacent SBC. >>>> >>>> -d >>>> >>>> >>>>> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >>>>> >>>>>>> -----Original Message----- >>>>>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>>>>> Sent: Thursday, July 08, 2010 5:50 AM >>>>>>> To: Dan Wing >>>>>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' >>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>> >>>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes >>>>>>> - >>>>> 03 >>>>>>> has just been submitted. >>>>>> Splendid. I refer to the media latching in that document >>>> frequently. >>>>>> Myself, I would be happier if IETF could find it possible to include >>>>>> the acronym-that-must-not-be-spoken (SBC) in SBC-related >>>>>> specifications -- no matter if an SBC working group is formed or >>>>>> not. Calling them 'middleboxes' is too vague to be useful, much >>>>>> like "gateway" is too vague (a gateway to the PSTN? a router?) Call >>>>>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an SBC an >>>>>> SBC. >>>>>> >>>>>> -d >>>>>> >>>>>> >>>>>>> Dan Wing wrote: >>>>>>>>> -----Original Message----- >>>>>>>>> From: dispatch-bounces@ietf.org >>>>>>>>> [mailto:dispatch-bounces@ietf.org] >>>>>>> On >>>>>>>>> Behalf Of Peter Musgrave >>>>>>>>> Sent: Thursday, July 01, 2010 12:30 PM >>>>>>>>> To: WORLEY, Dale R (Dale) >>>>>>>>> Cc: DISPATCH list >>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>>>> >>>>>>>>> I concur. >>>>>>>>> >>>>>>>>> There is some useful background in RFC5853 and perhaps >>>>>>>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 >>>>>>>>> >>>>>>>>> And then some things which died on the vine such as: >>>>>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>>>>>>> and perhaps some others? >>>>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >>>>> middleboxes- >>>>>>> 02 died. >>>>>>>> -d >>>>>>> ... >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> Cullen Jennings >>>>> For corporate legal information go to: >>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>> _______________________________________________ >>> 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 sunseawq@huawei.com Wed Jul 14 19:03:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E10173A69C3 for ; Wed, 14 Jul 2010 19:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Hy7INPb97ui for ; Wed, 14 Jul 2010 19:03:25 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 4F4B33A6883 for ; Wed, 14 Jul 2010 19:03:20 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5K000WDTPG3T@szxga03-in.huawei.com> for dispatch@ietf.org; Thu, 15 Jul 2010 10:03:16 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5K00IS2TPGEV@szxga03-in.huawei.com> for dispatch@ietf.org; Thu, 15 Jul 2010 10:03:16 +0800 (CST) Received: from w53375 ([10.138.84.35]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5K00HY7TPF9P@szxml06-in.huawei.com> for dispatch@ietf.org; Thu, 15 Jul 2010 10:03:16 +0800 (CST) Date: Thu, 15 Jul 2010 10:03:15 +0800 From: Qin Wu To: dispatch@ietf.org Message-id: <038601cb23c1$e367c4c0$23548a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Outlook Express 6.00.2900.3598 Content-type: multipart/mixed; boundary="Boundary_(ID_hWRHUBrDXHUQhiTM3KJXIQ)" X-Priority: 3 X-MSMail-priority: Normal Subject: [dispatch] Fw: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 02:03:26 -0000 This is a multi-part message in MIME format. --Boundary_(ID_hWRHUBrDXHUQhiTM3KJXIQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi, folks: The new version of draft-wu-http-streaming-optimization is available at: http://www.ietf.org/internet-drafts/draft-wu-http-streaming-optimization-ps-00.txt Currently, this draft is at the very early stage and primarily a problem statement identifying goals and issues, discussing possible use cases and sketching a possible direction for HTTP streaming support. Please drop your comments and share your opinons on this topic if you like or not. Regards! -Qin ----- Original Message ----- From: To: Sent: Monday, July 05, 2010 4:00 PM Subject: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : HTTP streaming optimization Problem Statement > Author(s) : W. Wu > Filename : draft-wu-http-streaming-optimization-ps-00.txt > Pages : 19 > Date : 2010-07-05 > > HTTP Streaming allows breaking the live contents or stored contents > into several chunks/fragments and supplying them in order to the > client. Several issues regarding control over the delivery of data > with real-time property using HTTP have been raised. Also various > issues arise when we consider offering the video quality requirements > to streaming video over Internet. This document describes these > issues. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-wu-http-streaming-optimization-ps-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > 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 > --Boundary_(ID_hWRHUBrDXHUQhiTM3KJXIQ) Content-type: text/plain; name=draft-wu-http-streaming-optimization-ps-00.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=draft-wu-http-streaming-optimization-ps-00.txt Content-Type: text/plain Content-ID: <2010-07-05005140.I-D@ietf.org> --Boundary_(ID_hWRHUBrDXHUQhiTM3KJXIQ)-- From ranjit@motorola.com Thu Jul 15 03:36:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96C6B3A69DC for ; Thu, 15 Jul 2010 03:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id im-bxjYWQ1JN for ; Thu, 15 Jul 2010 03:36:39 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 3766A3A69FE for ; Thu, 15 Jul 2010 03:36:39 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-12.tower-119.messagelabs.com!1279190204!50813891!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 20408 invoked from network); 15 Jul 2010 10:36:45 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-12.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jul 2010 10:36:45 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o6FAaiPS010958 for ; Thu, 15 Jul 2010 03:36:44 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o6FAaiuh004596 for ; Thu, 15 Jul 2010 05:36:44 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o6FAagDN004591 for ; Thu, 15 Jul 2010 05:36:43 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Jul 2010 18:36:20 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A854E68@ZMY16EXM66.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 Thread-Index: Acr47qak1f1bouTnR4uPpSUzCH37JgrGbTOA References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> <4BF53641.3070105@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> <4BF5563F.8090508@cisco.com> <4BF56106.4010806@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A554ADB@ZMY16EXM66.ds.mot.com> From: "Avasarala Ranjit-A20990" To: "Mary Barnes" X-CFilter-Loop: Reflected Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 10:36:41 -0000 Hi Mary, John and Paul After further thought, we feel that since the CDIV service is already = standardized in 3GPP specifications 24.604 (Section 4.10.1.1) and hence = there is no need for explicitly stating the requirements of a CDIV = service again in a separate I-D or document.=20 Also regarding any existing mechanisms, we feel there is/are no existing = mechansim(s) for getting notifications of a particular call diversion = service for a particular subscriber other than subscribing to the Call = Diversion Notification Information Event package which is already = proposed in 3GPP spec 24.604. Now as per 3GPP's directive, we need to formally standardize the event = package in IETF and hence the draft. So please let us know how we can take this draft forward to a meaningful = conclusion. Thanks Regards Ranjit -----Original Message----- From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 Sent: Friday, May 21, 2010 7:35 PM To: Avasarala Ranjit-A20990 Cc: john.elwell@siemens-enterprise.com; pkyzivat@cisco.com; DISPATCH Subject: Re: [dispatch] FW: New Version = Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 Ranjit, John's suggestion is the right approach - that's really the only way = this work is going to get traction within DISPATCH. Regards, Mary DISPATCH WG co-chair On Fri, May 21, 2010 at 3:04 AM, Elwell, John = wrote: > Ranjit, > > What I would like to see are: > - statement of requirements (for both barring and diversion); > - survey of solution space, with pros and cons (e.g., event package(s) = > as so far described versus other approaches); > - in case of event package, pros and cons of combining diversion and = barring into a single event package. > > Getting these fundamental principles established is more important = than working on details of an event package. > > John > >> -----Original Message----- >> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] >> Sent: 21 May 2010 08:00 >> To: Paul Kyzivat; Elwell, John >> Cc: dispatch@ietf.org; R.Jesske@telekom.de >> Subject: RE: [dispatch] FW: New Version=20 >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >> Hi Paul >> >> So what is the consensus? Come up with a requirements I-D and then=20 >> continue on the event package? >> >> Thanks >> >> >> Regards >> Ranjit >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, May 20, 2010 9:49 PM >> To: Elwell, John >> Cc: Avasarala Ranjit-A20990; dispatch@ietf.org; R.Jesske@telekom.de >> Subject: Re: [dispatch] FW: New Version=20 >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >> >> >> Elwell, John wrote: >> > I too think this work is potentially interesting beyond >> IMS, and would >> find it more attractive to combine requirements and have a single=20 >> event package. >> > >> > Of course, there are other ways of achieving this. There could be=20 >> > an >> HTTP resource that allows me to inspect recent calls that have been=20 >> subject to automatic call handling, e.g., by being diverted or = barred. >> Then I could use >> https://datatracker.ietf.org/doc/draft-roach-sip-http-subscribe/ to=20 >> be notified of changes to that resource. No SIP standardisation = required. >> It would be interesting to know whether this would solve = requirements. >> >> I guess this is fundamentally about automatic call handling. >> Seems like it might be in the scope of BLISS, except I gather BLISS=20 >> is winding down. >> >> =A0 =A0 =A0 Thanks, >> =A0 =A0 =A0 Paul >> >> > John >> > >> >> -----Original Message----- >> >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >> Sent: 20 May 2010 16:33 >> >> To: Avasarala Ranjit-A20990 >> >> Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de >> >> Subject: Re: [dispatch] FW: New Version >> >> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >> >> >> >> >> >> >> Avasarala Ranjit-A20990 wrote: >> >>> Hi Paul >> >>> >> >>> No I am not asking for a new WG. I wanted directions to >> >> take this I-D >> >>> forward. Like should we merge it with CDIV one as John Elwell was = >> >>> suggesting or keep this separate - which I think is better. >> >> Well, with the new operating rules for RAI and DISPATCH, >> if you want >> >> this to be worked on by some WG, then we either have to >> find one to >> >> recharter to do the work, or else we have to spin up >> another. I don't >> >> >> see any obvious existing one to take on the work. >> >> >> >> I *do* think this work is potentially interesting beyond IMS. >> >> A new WG >> >> is a *possibility* if the work can be framed in a way that people=20 >> >> want to work on. IMO that will mean first defining the >> requirements, >> >> without presuming the mechanism. And combining the >> requirements for >> >> CDIV and barring would probably make it more attractive. >> >> >> >> =A0 =A0Thanks, >> >> =A0 =A0Paul >> >> >> >>> Regards >> >>> Ranjit >> >>> >> >>> -----Original Message----- >> >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> >>> Sent: Thursday, May 20, 2010 6:47 PM >> >>> To: Avasarala Ranjit-A20990 >> >>> Cc: Elwell, John; dispatch@ietf.org; R.Jesske@telekom.de >> >>> Subject: Re: [dispatch] FW: New Version >> >>> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >>> >> >>> >> >>> >> >>> Avasarala Ranjit-A20990 wrote: >> >>>> Hi >> >>>> >> >>>> So is the consensus to proceed forward? >> >>> Proceed forward in what way? Are you asking for a new WG? >> >>> >> >>> =A0 Thanks, >> >>> =A0 Paul >> >>> >> >>>> Regards >> >>>> Ranjit >> >>>> >> >>>> -----Original Message----- >> >>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> >>>> Sent: Thursday, May 20, 2010 12:15 PM >> >>>> To: Avasarala Ranjit-A20990; dispatch@ietf.org >> >>>> Cc: R.Jesske@telekom.de >> >>>> Subject: RE: [dispatch] FW: New Version >> >>>> >> >> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >>>> Sorry, I thought I had already responded, but clearly not. >> >>>> >> >>>> I am still of the opinion that there is sufficient synergy >> >> between the >> >>>> two event packages that they can be combined into a single event = >> >>>> package. This would have the benefit of being able to have >> >> a single >> >>>> subscription to get all information relating to automatic >> >> handling of >> >>>> incoming calls, rather than being forced to subscribe >> >> twice. If you >> >>>> only want information about diverted calls, or only >> >> information about >> >>>> barred calls, you could filter accordingly. If you want >> different >> >>>> filtering criteria, or different subscription times for >> >> the two, there >> >>>> is nothing to stop you having two separate subscriptions. But we = >> >>>> should not penalise the simple case by forcing two >> >> subscriptions where >> >>>> one would do. >> >>>> >> >>>> John >> >>>> >> >>>>> -----Original Message----- >> >>>>> From: Avasarala Ranjit-A20990 [mailto:ranjit@motorola.com] >> >>>>> Sent: 20 May 2010 05:33 >> >>>>> To: Elwell, John; dispatch@ietf.org >> >>>>> Cc: R.Jesske@telekom.de >> >>>>> Subject: RE: [dispatch] FW: New Version >> >>>>> >> >> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >>>>> Hi All >> >>>>> >> >>>>> Any further comments on this I-D and suggestions for next = steps? >> >>>>> >> >>>>> Thanks >> >>>>> >> >>>>> >> >>>>> Regards >> >>>>> Ranjit >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: dispatch-bounces@ietf.org >> >> [mailto:dispatch-bounces@ietf.org] On >> >>>>> Behalf Of Avasarala Ranjit-A20990 >> >>>>> Sent: Friday, May 14, 2010 11:49 AM >> >>>>> To: Elwell, John; dispatch@ietf.org >> >>>>> Subject: Re: [dispatch] FW: New Version >> >>>>> >> >> >> Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >> >>>>> Hi John >> >>>>> >> >>>>> This I-D on communication barring notification talks >> >> about an event >> >>>>> package for reporting the notification information of >> >> communication >> >>>>> barrings (call blocking) that happen in the network on >> >> behalf of the >> >>>>> users. >> >>>>> >> >>>>> For e.g if Alice sets a call blocking rule that all calls >> >> from Bob >> >>>>> need to be blocked, then the network blocks all calls from Bob=20 >> >>>>> towards Alice. >> >>>>> So here >> >>>>> The notification information will include the details >> of the call >> >>>>> block >> >>>>> - i.e (1) the identity of caller (Bob) (2) time of block >> >> (2) reason >> >>>>> for block, etc >> >>>>> >> >>>>> Yes I agree with you that there is synergy between this >> >> I-D and the >> >>>>> one on CDIV, since both of them deal with reporting of >> >> events that >> >>>>> occur in the network. While CDIV deals with communication >> >> diversion, >> >>>>> this one deals with ICB service. Though both the event >> >> packages are >> >>>>> similar in terms of subscriptions and format, their >> execution and >> >>>>> user preference may vary. So they need to be looked at >> differently >> >> >>>>> and standardized seperately. >> >>>>> >> >>>>> >> >>>>> Regards >> >>>>> Ranjit >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> >>>>> Sent: Thursday, May 13, 2010 6:25 PM >> >>>>> To: Avasarala Ranjit-A20990; dispatch@ietf.org >> >>>>> Cc: T Satyanarayana-A12694 >> >>>>> Subject: RE: [dispatch] FW: New Version Notification=20 >> >>>>> fordraft-avasarala-dispatch-comm-barring-notification-00 >> >>>>> >> >>>>> Ranjit, >> >>>>> >> >>>>> It is not entirely clear to me what the notifications >> report. For >> >>>>> example, in 6.7, it says "Typically, it will send >> >>>>> =A0 =A0one when a communication barring is enacted on behalf of = the >> >>> user." >> >>>>> What is meant by "enacted" here? Is it when some entity, >> >> on behalf of >> >>>>> the user, perhaps through some web page, establishes a >> >> communication >> >>>>> barring rule? Or is it when an inbound communication >> >> arrives and is >> >>>>> processed in accordance with some pre-existing >> >> communication barring >> >>>>> rule? I thought at first it was the former, but I am >> >> tending towards >> >>>>> thinking it is the latter. Some clarification would be useful. >> >>>>> >> >>>>> Assuming it is the latter, there is obviously some synergy with = >> >>>>> draft-avasarala-dispatch-comm-div-notification. Both deal with=20 >> >>>>> reporting inbound communications that have been subject >> >> to some rule, >> >>>>> the rule being conditional on certain criteria such as >> caller ID. >> >>>>> Where the conditions are met for a given call to be >> subject to a >> >>>>> given >> >>>>> rule, a notification in accordance with one or the other event=20 >> >>>>> package will be triggered. I fail to see the reason for having >> >> two separate >> >>>>> event packages, since this means two separate >> specifications, two >> >>>>> different subscriptions, two different formats, etc.. >> >>>>> >> >>>>> John >> >>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: dispatch-bounces@ietf.org=20 >> >>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala=20 >> >>>>>> Ranjit-A20990 >> >>>>>> Sent: 13 May 2010 11:28 >> >>>>>> To: dispatch@ietf.org >> >>>>>> Cc: T Satyanarayana-A12694 >> >>>>>> Subject: [dispatch] FW: New Version Notification for=20 >> >>>>>> draft-avasarala-dispatch-comm-barring-notification-00 >> >>>>>> >> >>>>>> Hi all >> >>>>>> >> >>>>>> I have submitted a new I-D on communication barring >> notification >> >>>>>> information based on the following >> >>>>>> >> >>>>>> Section 8.2.10 Communication Barring - ICB enhancement >> >> of dynamic >> >>>>>> blocking of incoming communications of 3GPP TS 22.173 >> >>>>>> >> >>>>>> Section 4.5.2.6.1 Actions for ICB at the terminating AS >> >> of 3GPP TS >> >>>>>> 24.611 >> >>>>>> >> >>>>>> The draft can be accessed from: >> >>>>>> http://www.ietf.org/id/draft-avasarala-dispatch-comm-barring-n >> >>>>>> otificatio >> >>>>>> n-00.txt >> >>>>>> >> >>>>>> Please review and comment. >> >>>>>> >> >>>>>> Thanks >> >>>>>> >> >>>>>> >> >>>>>> Regards >> >>>>>> Ranjit >> >>>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >> >>>>>> Sent: Thursday, May 13, 2010 3:47 PM >> >>>>>> To: Avasarala Ranjit-A20990 >> >>>>>> Cc: r.jesske@telekom.de >> >>>>>> Subject: New Version Notification for=20 >> >>>>>> draft-avasarala-dispatch-comm-barring-notification-00 >> >>>>>> >> >>>>>> >> >>>>>> A new version of I-D, >> >>>>>> >> >> draft-avasarala-dispatch-comm-barring-notification-00.txt has been >> >>>>>> successfully submitted by Ranjit Avasarala and posted to >> >> the IETF >> >>>>>> repository. >> >>>>>> >> >>>>>> Filename: >> >> draft-avasarala-dispatch-comm-barring-notification >> >>>>>> Revision: =A0 =A0 =A0 00 >> >>>>>> Title: =A0 =A0 =A0 =A0 =A0A Session Initiation Protocol (SIP) = Event=20 >> >>>>>> Package for Communication Barring Notification Information in >> support of the >> >>>>>> Dynamic Incoming Communication Barring (ICB) >> Notification service >> >>>>>> Creation_date: =A02010-05-13 >> >>>>>> WG ID: =A0 =A0 =A0 =A0 =A0Independent Submission >> >>>>>> Number_of_pages: 22 >> >>>>>> >> >>>>>> Abstract: >> >>>>>> 3GPP is defining the protocol specification for the >> >> Communication >> >>>>>> Barring (CB) service using IP Multimedia (IM) Core >> Network (CN) >> >>>>>> subsystem supplementary service and more particularly >> >> the dynamic >> >>>>>> incoming communication barring service. =A0As part of dynamic >> >>>>> incoming >> >>>>>> communication barring (ICB) service, a SIP based Event package = >> >>>>>> framework is used for notifying users about >> >> communication barrings >> >>>>>> (dynamic and rule based) of their incoming communication >> >> sessions. >> >>>>>> This document proposes a new SIP event package for allowing >> >>>>> users to >> >>>>>> subscribe to and receive such notifications. =A0Users can >> >>>>> further define >> >>>>> >> >>>>>> filters to control the rate and content of such notifications. >> >>>>>> The proposed event package is applicable to the ICB >> >> supplementary >> >>>>>> service in IMS and may not be applicable to the >> general internet. >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> The IETF Secretariat. >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> 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 > From partr@cisco.com Thu Jul 15 04:55:02 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214983A695D for ; Thu, 15 Jul 2010 04:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.156 X-Spam-Level: X-Spam-Status: No, score=-9.156 tagged_above=-999 required=5 tests=[AWL=1.443, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M6Xb18QYM6vx for ; Thu, 15 Jul 2010 04:54:59 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B88053A67B5 for ; Thu, 15 Jul 2010 04:54:59 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGqUPkxAaHte/2dsb2JhbACfZ3GjAJp+hSQEg3yHCA X-IronPort-AV: E=Sophos;i="4.55,207,1278288000"; d="scan'208";a="267635883" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2010 11:55:07 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6FBt6Q8013169; Thu, 15 Jul 2010 11:55:06 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Jul 2010 17:25:06 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Jul 2010 17:25:04 +0530 Message-ID: In-Reply-To: <4C3E5485.3000907@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: Acsjs6IYWVjOk3zrTvalvTvT1/PW7wAYLVRQ References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com> <114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com> <4C3E5485.3000907@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , "Marshall Eubanks" X-OriginalArrivalTime: 15 Jul 2010 11:55:06.0736 (UTC) FILETIME=[91639700:01CB2414] Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 11:55:02 -0000 I love to join in this topic=20 Thanks Partha -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Thursday, July 15, 2010 5:51 AM To: Marshall Eubanks Cc: DISPATCH list; Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? Marshall Eubanks wrote: > Should we arrange a (true) Bar BOF (AKA DrinkTime) for this topic in=20 > Maastricht ? I'm open to that, unless I run into conflicts. (I'm too busy and unmotivated to do any organization of it.) Thanks, Paul > Marshall >=20 > On Jul 14, 2010, at 6:53 PM, Paul Kyzivat wrote: >=20 >> I won't comment on the rest of this right now, but its not right to=20 >> describe a B2BUA as a function of an SBC. >> Rather, an SBC is a particular sort of B2BUA. >> There are *many* sorts of B2BUA that have nothing in common with an SBC. >> >> Its actually this sort of disagreement that would benefit from=20 >> beginning a taxonomy of B2BUAs. >> >> Thanks, >> Paul >> >> Daryl Malas wrote: >>> All, >>> Many if not all of the functions of an SBC have already been defined >>> in one way or another. An SBC is a "jack-of-all-trades" platform. =20 >>> I think this is a slippery slope to try and define, and is a=20 >>> quagmire the IETF should stray from. In some cases, SBCs are not=20 >>> even deployed on the edge of networks. >>> I agree that a B2BUA is different, but it could be considered a=20 >>> function of the SBC. B2BUA's were created with the intention of=20 >>> breaking up the end-to-end environment, so creating rules to define=20 >>> allowances for the end-to-end environment will be challenging at best. >>> Regards, >>> Daryl >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org]=20 >>> On Behalf Of Christer Holmberg >>> Sent: Friday, July 09, 2010 12:44 PM >>> To: Paul Kyzivat; Mohammad Al-Taraireh (maltarai) >>> Cc: DISPATCH list >>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>> Hi, >>> Rather than focus on node terminology, I think we should focus on=20 >>> the FUNCTIONS they perform, and see whether something can do done in >>> order to avoid claimed interop problems etc, rather than arguing=20 >>> about whether the entity that performs the function shall be called=20 >>> B2BUA, SBC, Application Server, or something else... >>> Regards, >>> Christer >>> ________________________________________ >>> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On=20 >>> Behalf Of Paul Kyzivat [pkyzivat@cisco.com] >>> Sent: Friday, July 09, 2010 3:10 AM >>> To: Mohammad Al-Taraireh (maltarai) >>> Cc: DISPATCH list >>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>> Mohammad Al-Taraireh (maltarai) wrote: >>>> Doesn't the B2BUA term also implies media origination, and=20 >>>> termination capabilities ? It seems that the B2BUA term is already=20 >>>> overloaded to include SBC. >>> The term "B2BUA" is distinguished by the minimality of its=20 >>> definition and the corresponding broadness of applicability. It=20 >>> neither implies nor forbids media processing. >>> The term SBC, as typically used, is somewhat narrower in scope that=20 >>> B2BUA, but is still incredibly broad. I certainly know of things=20 >>> that consider themselves to be SBCs that (at least sometimes) don't=20 >>> terminate media. >>> And certainly there are B2BUAs that *do* terminate media that you=20 >>> would not want to call an SBC. (E.g. a conference focus and mixer.) >>> Thanks, >>> Paul >>>> Mo >>>> >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >>>> On Behalf Of Dan Wing (dwing) >>>> Sent: Thursday, July 08, 2010 5:31 PM >>>> To: Cullen Jennings (fluffy) >>>> Cc: 'DISPATCH list' >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>> >>>>> -----Original Message----- >>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>> Sent: Thursday, July 08, 2010 1:34 PM >>>>> To: Dan Wing >>>>> Cc: DISPATCH list >>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>> >>>>> >>>>> Seems reasonable. I think B2BUA is reasonable well defined. Care=20 >>>>> to put on your fire proof suit and propose a definition of what an >>>>> SBC >>>> is? >>>> >>>> SBC: a B2BUA that also terminates and originates media from user >>>> agents or media from an adjacent SBC. >>>> >>>> -d >>>> >>>> >>>>> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >>>>> >>>>>>> -----Original Message----- >>>>>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>>>>> Sent: Thursday, July 08, 2010 5:50 AM >>>>>>> To: Dan Wing >>>>>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' >>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>> >>>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middlebo >>>>>>> xes >>>>>>> - >>>>> 03 >>>>>>> has just been submitted. >>>>>> Splendid. I refer to the media latching in that document >>>> frequently. >>>>>> Myself, I would be happier if IETF could find it possible to=20 >>>>>> include the acronym-that-must-not-be-spoken (SBC) in SBC-related=20 >>>>>> specifications -- no matter if an SBC working group is formed or=20 >>>>>> not. Calling them 'middleboxes' is too vague to be useful, much=20 >>>>>> like "gateway" is too vague (a gateway to the PSTN? a router?)=20 >>>>>> Call a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an=20 >>>>>> SBC an SBC. >>>>>> >>>>>> -d >>>>>> >>>>>> >>>>>>> Dan Wing wrote: >>>>>>>>> -----Original Message----- >>>>>>>>> From: dispatch-bounces@ietf.org=20 >>>>>>>>> [mailto:dispatch-bounces@ietf.org] >>>>>>> On >>>>>>>>> Behalf Of Peter Musgrave >>>>>>>>> Sent: Thursday, July 01, 2010 12:30 PM >>>>>>>>> To: WORLEY, Dale R (Dale) >>>>>>>>> Cc: DISPATCH list >>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>>>> >>>>>>>>> I concur. >>>>>>>>> >>>>>>>>> There is some useful background in RFC5853 and perhaps=20 >>>>>>>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru >>>>>>>>> -00 >>>>>>>>> >>>>>>>>> And then some things which died on the vine such as: >>>>>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>>>>>>> and perhaps some others? >>>>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >>>>> middleboxes- >>>>>>> 02 died. >>>>>>>> -d >>>>>>> ... >>>>>> _______________________________________________ >>>>>> dispatch mailing list >>>>>> dispatch@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> Cullen Jennings >>>>> For corporate legal information go to: >>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>> _______________________________________________ >>> 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 >=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From john.elwell@siemens-enterprise.com Thu Jul 15 06:57:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 915453A694E for ; Thu, 15 Jul 2010 06:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBzBHMedtjwF for ; Thu, 15 Jul 2010 06:57:40 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 9C1A13A6919 for ; Thu, 15 Jul 2010 06:57:39 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-865480; Thu, 15 Jul 2010 15:57:48 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 296251EB82AB; Thu, 15 Jul 2010 15:57:48 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 15 Jul 2010 15:57:46 +0200 From: "Elwell, John" To: Marshall Eubanks , Paul Kyzivat Date: Thu, 15 Jul 2010 15:57:45 +0200 Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: AcsjsXl5SEdMKI+NRF2OWs4L6gDYJAAdCr7A Message-ID: References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com> <114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg> <4C3E3FF6.1050003@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 13:57:41 -0000 I would try to join if there is no conflict. John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Marshall Eubanks > Sent: 15 July 2010 01:06 > To: Paul Kyzivat > Cc: DISPATCH list; Daryl Malas > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >=20 > Should we arrange a (true) Bar BOF (AKA DrinkTime) for this topic in =20 > Maastricht ? >=20 > Marshall >=20 > On Jul 14, 2010, at 6:53 PM, Paul Kyzivat wrote: >=20 > > I won't comment on the rest of this right now, > > but its not right to describe a B2BUA as a function of an SBC. > > Rather, an SBC is a particular sort of B2BUA. > > There are *many* sorts of B2BUA that have nothing in common=20 > with an =20 > > SBC. > > > > Its actually this sort of disagreement that would benefit from =20 > > beginning a taxonomy of B2BUAs. > > > > Thanks, > > Paul > > > > Daryl Malas wrote: > >> All, > >> Many if not all of the functions of an SBC have already been =20 > >> defined in one way or another. An SBC is a "jack-of-all-trades" =20 > >> platform. I think this is a slippery slope to try and=20 > define, and =20 > >> is a quagmire the IETF should stray from. In some cases,=20 > SBCs are =20 > >> not even deployed on the edge of networks. > >> I agree that a B2BUA is different, but it could be considered a =20 > >> function of the SBC. B2BUA's were created with the intention of =20 > >> breaking up the end-to-end environment, so creating rules=20 > to define =20 > >> allowances for the end-to-end environment will be challenging at =20 > >> best. > >> Regards, > >> Daryl > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] =20 > >> On Behalf Of Christer Holmberg > >> Sent: Friday, July 09, 2010 12:44 PM > >> To: Paul Kyzivat; Mohammad Al-Taraireh (maltarai) > >> Cc: DISPATCH list > >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >> Hi, > >> Rather than focus on node terminology, I think we should focus on =20 > >> the FUNCTIONS they perform, and see whether something can do done =20 > >> in order to avoid claimed interop problems etc, rather=20 > than arguing =20 > >> about whether the entity that performs the function shall=20 > be called =20 > >> B2BUA, SBC, Application Server, or something else... > >> Regards, > >> Christer > >> ________________________________________ > >> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On =20 > >> Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > >> Sent: Friday, July 09, 2010 3:10 AM > >> To: Mohammad Al-Taraireh (maltarai) > >> Cc: DISPATCH list > >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >> Mohammad Al-Taraireh (maltarai) wrote: > >>> Doesn't the B2BUA term also implies media origination, and =20 > >>> termination capabilities ? It seems that the B2BUA term=20 > is already =20 > >>> overloaded to include SBC. > >> The term "B2BUA" is distinguished by the minimality of its =20 > >> definition and the corresponding broadness of applicability. It =20 > >> neither implies nor forbids media processing. > >> The term SBC, as typically used, is somewhat narrower in=20 > scope that =20 > >> B2BUA, but is still incredibly broad. I certainly know of things =20 > >> that consider themselves to be SBCs that (at least=20 > sometimes) don't =20 > >> terminate media. > >> And certainly there are B2BUAs that *do* terminate media that you =20 > >> would not want to call an SBC. (E.g. a conference focus and mixer.) > >> Thanks, > >> Paul > >>> Mo > >>> > >>> -----Original Message----- > >>> From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] =20 > >>> On Behalf Of Dan Wing (dwing) > >>> Sent: Thursday, July 08, 2010 5:31 PM > >>> To: Cullen Jennings (fluffy) > >>> Cc: 'DISPATCH list' > >>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >>> > >>>> -----Original Message----- > >>>> From: Cullen Jennings [mailto:fluffy@cisco.com] > >>>> Sent: Thursday, July 08, 2010 1:34 PM > >>>> To: Dan Wing > >>>> Cc: DISPATCH list > >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >>>> > >>>> > >>>> Seems reasonable. I think B2BUA is reasonable well=20 > defined. Care =20 > >>>> to put on your fire proof suit and propose a definition of what =20 > >>>> an SBC > >>> is? > >>> > >>> SBC: a B2BUA that also terminates and originates media from user > >>> agents or media from an adjacent SBC. > >>> > >>> -d > >>> > >>> > >>>> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: > >>>> > >>>>>> -----Original Message----- > >>>>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] > >>>>>> Sent: Thursday, July 08, 2010 5:50 AM > >>>>>> To: Dan Wing > >>>>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' > >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >>>>>> > >>>>>>=20 > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes > >>>>>> - > >>>> 03 > >>>>>> has just been submitted. > >>>>> Splendid. I refer to the media latching in that document > >>> frequently. > >>>>> Myself, I would be happier if IETF could find it possible to =20 > >>>>> include > >>>>> the acronym-that-must-not-be-spoken (SBC) in SBC-related =20 > >>>>> specifications -- no matter if an SBC working group is=20 > formed or =20 > >>>>> not. Calling them 'middleboxes' is too vague to be=20 > useful, much =20 > >>>>> like "gateway" is too vague (a gateway to the PSTN? a=20 > router?) =20 > >>>>> Call > >>>>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA,=20 > and an SBC =20 > >>>>> an SBC. > >>>>> > >>>>> -d > >>>>> > >>>>> > >>>>>> Dan Wing wrote: > >>>>>>>> -----Original Message----- > >>>>>>>> From: dispatch-bounces@ietf.org > >>>>>>>> [mailto:dispatch-bounces@ietf.org] > >>>>>> On > >>>>>>>> Behalf Of Peter Musgrave > >>>>>>>> Sent: Thursday, July 01, 2010 12:30 PM > >>>>>>>> To: WORLEY, Dale R (Dale) > >>>>>>>> Cc: DISPATCH list > >>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG=20 > for SBCs? > >>>>>>>> > >>>>>>>> I concur. > >>>>>>>> > >>>>>>>> There is some useful background in RFC5853 and=20 > perhaps=20 > http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 > >>>>>>>> > >>>>>>>> And then some things which died on the vine such as: > >>>>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 > >>>>>>>> and perhaps some others? > >>>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- > >>>> middleboxes- > >>>>>> 02 died. > >>>>>>> -d > >>>>>> ... > >>>>> _______________________________________________ > >>>>> dispatch mailing list > >>>>> dispatch@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/dispatch > >>>> Cullen Jennings > >>>> For corporate legal information go to: > >>>>=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >>>> > >>> > >>> _______________________________________________ > >>> 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 > >> _______________________________________________ > >> 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From fluffy@cisco.com Thu Jul 15 07:05:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8F313A6986; Thu, 15 Jul 2010 07:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.418 X-Spam-Level: X-Spam-Status: No, score=-110.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xphmOv-Y7wfN; Thu, 15 Jul 2010 07:05:54 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 085633A686E; Thu, 15 Jul 2010 07:05:52 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC+yPkyrR7Hu/2dsb2JhbACfaXGjGZsGhSQEg36EUg X-IronPort-AV: E=Sophos;i="4.55,208,1278288000"; d="scan'208";a="344212652" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2010 14:06:02 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6FE61wF014000; Thu, 15 Jul 2010 14:06:01 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4C3D7496.8020905@gmail.com> Date: Thu, 15 Jul 2010 08:06:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <71EA364F-6D56-45B3-BB9C-9C9AE1E1266C@cisco.com> References: <4C28F980.3040702@ericsson.com> <0010F1C2-2436-474D-BC1C-05AFC8A9E4C5@cisco.com> <4C3D7496.8020905@gmail.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list , IESG IESG , IETF-Discussion list Subject: Re: [dispatch] WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 14:05:56 -0000 I don't think this resolves the issue. The issue is if this information = is used for a call control. Basically do proxies need to be able to look = at this to make decision about what they are going to do. We at least = need a Yes/No answer to this question from the proponents of this work = and the charter to make that clear.=20 On Jul 14, 2010, at 2:25 AM, Gonzalo Camarillo wrote: > Hi, >=20 > thanks for your comments on the charter proposal. Per the comments > received, we will modify bullet 5 as follows so that it is clearer: >=20 > OLD: > 5. SIP elements may need to apply policy about passing and screening > the information. >=20 > NEW: > 5. SIP elements may need to apply policy about passing and filtering > UUI. The included application, encoding, semantics, and content > information will allow endpoint or intermediary SIP elements to > allow or block UUI based on the type and originator, not based on > the actual UUI data, which may be end-to-end encrypted by the > application. >=20 > Further discussions on this topic should happen on the mailing list of > this WG. >=20 > Cheers, >=20 > Gonzalo > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From gonzalo.camarillo@ericsson.com Thu Jul 15 07:31:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E379A3A680C; Thu, 15 Jul 2010 07:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.837 X-Spam-Level: X-Spam-Status: No, score=-103.837 tagged_above=-999 required=5 tests=[AWL=-1.238, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRTPsEnl7bWq; Thu, 15 Jul 2010 07:31:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 1289C3A6A1E; Thu, 15 Jul 2010 07:31:53 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-bf-4c3f1be33bd2 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5F.41.06895.3EB1F3C4; Thu, 15 Jul 2010 16:32:03 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jul 2010 16:32:03 +0200 Received: from [131.160.126.225] ([131.160.126.225]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jul 2010 16:32:02 +0200 Message-ID: <4C3F1BE2.5060102@ericsson.com> Date: Thu, 15 Jul 2010 17:32:02 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Cullen Jennings References: <4C28F980.3040702@ericsson.com> <0010F1C2-2436-474D-BC1C-05AFC8A9E4C5@cisco.com> <4C3D7496.8020905@gmail.com> <71EA364F-6D56-45B3-BB9C-9C9AE1E1266C@cisco.com> In-Reply-To: <71EA364F-6D56-45B3-BB9C-9C9AE1E1266C@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2010 14:32:02.0726 (UTC) FILETIME=[7DC1A460:01CB242A] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list , IESG IESG , IETF-Discussion list Subject: Re: [dispatch] WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 14:31:59 -0000 Hi Cullen, the charter already says that the information "may be end-to-end encrypted by the application". Therefore, proxies will not make any decision (related or unrelated to call control) based on its contents because the contents may simply not be available to the proxy. Do you want the charter to be even more explicit about this? Thanks, Gonzalo On 15/07/2010 5:06 PM, Cullen Jennings wrote: > > I don't think this resolves the issue. The issue is if this information is used for a call control. Basically do proxies need to be able to look at this to make decision about what they are going to do. We at least need a Yes/No answer to this question from the proponents of this work and the charter to make that clear. > > > On Jul 14, 2010, at 2:25 AM, Gonzalo Camarillo wrote: > >> Hi, >> >> thanks for your comments on the charter proposal. Per the comments >> received, we will modify bullet 5 as follows so that it is clearer: >> >> OLD: >> 5. SIP elements may need to apply policy about passing and screening >> the information. >> >> NEW: >> 5. SIP elements may need to apply policy about passing and filtering >> UUI. The included application, encoding, semantics, and content >> information will allow endpoint or intermediary SIP elements to >> allow or block UUI based on the type and originator, not based on >> the actual UUI data, which may be end-to-end encrypted by the >> application. >> >> Further discussions on this topic should happen on the mailing list of >> this WG. >> >> Cheers, >> >> Gonzalo >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > From D.Malas@cablelabs.com Thu Jul 15 07:57:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA35A3A69E9 for ; Thu, 15 Jul 2010 07:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pGI9i4x7A2eg for ; Thu, 15 Jul 2010 07:57:12 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 7CC743A68E8 for ; Thu, 15 Jul 2010 07:57:12 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o6FEvFg3013674; Thu, 15 Jul 2010 08:57:15 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 15 Jul 2010 08:57:14 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 15 Jul 2010 08:57:15 -0600 From: Daryl Malas To: "'Marshall Eubanks'" , Paul Kyzivat Date: Thu, 15 Jul 2010 08:57:14 -0600 Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: AcsjsXVXVaO3a0eARA2wO2503rYB4wAfHdGQ Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01419B2529@srvxchg> References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com> <114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg> <4C3E3FF6.1050003@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 14:57:14 -0000 I would try and join the discussion. --Daryl=20 -----Original Message----- From: Marshall Eubanks [mailto:tme@americafree.tv]=20 Sent: Wednesday, July 14, 2010 6:06 PM To: Paul Kyzivat Cc: Daryl Malas; DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? Should we arrange a (true) Bar BOF (AKA DrinkTime) for this topic in Maastr= icht ? Marshall On Jul 14, 2010, at 6:53 PM, Paul Kyzivat wrote: > I won't comment on the rest of this right now, but its not right to=20 > describe a B2BUA as a function of an SBC. > Rather, an SBC is a particular sort of B2BUA. > There are *many* sorts of B2BUA that have nothing in common with an=20 > SBC. > > Its actually this sort of disagreement that would benefit from=20 > beginning a taxonomy of B2BUAs. > > Thanks, > Paul > > Daryl Malas wrote: >> All, >> Many if not all of the functions of an SBC have already been defined=20 >> in one way or another. An SBC is a "jack-of-all-trades" >> platform. I think this is a slippery slope to try and define, and is=20 >> a quagmire the IETF should stray from. In some cases, SBCs are not=20 >> even deployed on the edge of networks. >> I agree that a B2BUA is different, but it could be considered a=20 >> function of the SBC. B2BUA's were created with the intention of=20 >> breaking up the end-to-end environment, so creating rules to define=20 >> allowances for the end-to-end environment will be challenging at=20 >> best. >> Regards, >> Daryl >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >> On Behalf Of Christer Holmberg >> Sent: Friday, July 09, 2010 12:44 PM >> To: Paul Kyzivat; Mohammad Al-Taraireh (maltarai) >> Cc: DISPATCH list >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >> Hi, >> Rather than focus on node terminology, I think we should focus on the=20 >> FUNCTIONS they perform, and see whether something can do done in=20 >> order to avoid claimed interop problems etc, rather than arguing=20 >> about whether the entity that performs the function shall be called=20 >> B2BUA, SBC, Application Server, or something else... >> Regards, >> Christer >> ________________________________________ >> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf=20 >> Of Paul Kyzivat [pkyzivat@cisco.com] >> Sent: Friday, July 09, 2010 3:10 AM >> To: Mohammad Al-Taraireh (maltarai) >> Cc: DISPATCH list >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >> Mohammad Al-Taraireh (maltarai) wrote: >>> Doesn't the B2BUA term also implies media origination, and=20 >>> termination capabilities ? It seems that the B2BUA term is already=20 >>> overloaded to include SBC. >> The term "B2BUA" is distinguished by the minimality of its definition=20 >> and the corresponding broadness of applicability. It neither implies=20 >> nor forbids media processing. >> The term SBC, as typically used, is somewhat narrower in scope that=20 >> B2BUA, but is still incredibly broad. I certainly know of things that=20 >> consider themselves to be SBCs that (at least sometimes) don't=20 >> terminate media. >> And certainly there are B2BUAs that *do* terminate media that you=20 >> would not want to call an SBC. (E.g. a conference focus and mixer.) >> Thanks, >> Paul >>> Mo >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] >>> On Behalf Of Dan Wing (dwing) >>> Sent: Thursday, July 08, 2010 5:31 PM >>> To: Cullen Jennings (fluffy) >>> Cc: 'DISPATCH list' >>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>> >>>> -----Original Message----- >>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>> Sent: Thursday, July 08, 2010 1:34 PM >>>> To: Dan Wing >>>> Cc: DISPATCH list >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>> >>>> >>>> Seems reasonable. I think B2BUA is reasonable well defined. Care to=20 >>>> put on your fire proof suit and propose a definition of what an SBC >>> is? >>> >>> SBC: a B2BUA that also terminates and originates media from user >>> agents or media from an adjacent SBC. >>> >>> -d >>> >>> >>>> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >>>> >>>>>> -----Original Message----- >>>>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>>>> Sent: Thursday, July 08, 2010 5:50 AM >>>>>> To: Dan Wing >>>>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>> >>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middlebox >>>>>> es >>>>>> - >>>> 03 >>>>>> has just been submitted. >>>>> Splendid. I refer to the media latching in that document >>> frequently. >>>>> Myself, I would be happier if IETF could find it possible to=20 >>>>> include the acronym-that-must-not-be-spoken (SBC) in SBC-related=20 >>>>> specifications -- no matter if an SBC working group is formed or=20 >>>>> not. Calling them 'middleboxes' is too vague to be useful, much=20 >>>>> like "gateway" is too vague (a gateway to the PSTN? a router?)=20 >>>>> Call a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, and an=20 >>>>> SBC an SBC. >>>>> >>>>> -d >>>>> >>>>> >>>>>> Dan Wing wrote: >>>>>>>> -----Original Message----- >>>>>>>> From: dispatch-bounces@ietf.org=20 >>>>>>>> [mailto:dispatch-bounces@ietf.org] >>>>>> On >>>>>>>> Behalf Of Peter Musgrave >>>>>>>> Sent: Thursday, July 01, 2010 12:30 PM >>>>>>>> To: WORLEY, Dale R (Dale) >>>>>>>> Cc: DISPATCH list >>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>>> >>>>>>>> I concur. >>>>>>>> >>>>>>>> There is some useful background in RFC5853 and perhaps=20 >>>>>>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru- >>>>>>>> 00 >>>>>>>> >>>>>>>> And then some things which died on the vine such as: >>>>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>>>>>> and perhaps some others? >>>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >>>> middleboxes- >>>>>> 02 died. >>>>>>> -d >>>>>> ... >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> Cullen Jennings >>>> For corporate legal information go to: >>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>> >>> >>> _______________________________________________ >>> 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 >> _______________________________________________ >> 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 tme@americafree.tv Thu Jul 15 08:03:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7C953A69C8 for ; Thu, 15 Jul 2010 08:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKjAJW7RuWUs for ; Thu, 15 Jul 2010 08:03:32 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 940003A69D1 for ; Thu, 15 Jul 2010 08:03:32 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 4168C7F7442A; Thu, 15 Jul 2010 11:03:43 -0400 (EDT) Message-Id: <7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> From: Marshall Eubanks To: "Elwell, John" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 15 Jul 2010 11:03:42 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com> <114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg> <4C3E3FF6.1050003@cisco.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 15:03:35 -0000 OK, here are the options I see There is an informal Bar BOF list http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 Wednesday Lunch, thursday Lunch or Thursday before plenary are taken. I would suggest Monday night Wednesday after plenary Thursday after plenary Friday Lunch I would prefer Monday night, but these all WFM. Please let me know what you think. Regards Marshall On Jul 15, 2010, at 9:57 AM, Elwell, John wrote: > I would try to join if there is no conflict. > > John > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Marshall Eubanks >> Sent: 15 July 2010 01:06 >> To: Paul Kyzivat >> Cc: DISPATCH list; Daryl Malas >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >> >> Should we arrange a (true) Bar BOF (AKA DrinkTime) for this topic in >> Maastricht ? >> >> Marshall >> >> On Jul 14, 2010, at 6:53 PM, Paul Kyzivat wrote: >> >>> I won't comment on the rest of this right now, >>> but its not right to describe a B2BUA as a function of an SBC. >>> Rather, an SBC is a particular sort of B2BUA. >>> There are *many* sorts of B2BUA that have nothing in common >> with an >>> SBC. >>> >>> Its actually this sort of disagreement that would benefit from >>> beginning a taxonomy of B2BUAs. >>> >>> Thanks, >>> Paul >>> >>> Daryl Malas wrote: >>>> All, >>>> Many if not all of the functions of an SBC have already been >>>> defined in one way or another. An SBC is a "jack-of-all-trades" >>>> platform. I think this is a slippery slope to try and >> define, and >>>> is a quagmire the IETF should stray from. In some cases, >> SBCs are >>>> not even deployed on the edge of networks. >>>> I agree that a B2BUA is different, but it could be considered a >>>> function of the SBC. B2BUA's were created with the intention of >>>> breaking up the end-to-end environment, so creating rules >> to define >>>> allowances for the end-to-end environment will be challenging at >>>> best. >>>> Regards, >>>> Daryl >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] >>>> On Behalf Of Christer Holmberg >>>> Sent: Friday, July 09, 2010 12:44 PM >>>> To: Paul Kyzivat; Mohammad Al-Taraireh (maltarai) >>>> Cc: DISPATCH list >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>> Hi, >>>> Rather than focus on node terminology, I think we should focus on >>>> the FUNCTIONS they perform, and see whether something can do done >>>> in order to avoid claimed interop problems etc, rather >> than arguing >>>> about whether the entity that performs the function shall >> be called >>>> B2BUA, SBC, Application Server, or something else... >>>> Regards, >>>> Christer >>>> ________________________________________ >>>> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On >>>> Behalf Of Paul Kyzivat [pkyzivat@cisco.com] >>>> Sent: Friday, July 09, 2010 3:10 AM >>>> To: Mohammad Al-Taraireh (maltarai) >>>> Cc: DISPATCH list >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>> Mohammad Al-Taraireh (maltarai) wrote: >>>>> Doesn't the B2BUA term also implies media origination, and >>>>> termination capabilities ? It seems that the B2BUA term >> is already >>>>> overloaded to include SBC. >>>> The term "B2BUA" is distinguished by the minimality of its >>>> definition and the corresponding broadness of applicability. It >>>> neither implies nor forbids media processing. >>>> The term SBC, as typically used, is somewhat narrower in >> scope that >>>> B2BUA, but is still incredibly broad. I certainly know of things >>>> that consider themselves to be SBCs that (at least >> sometimes) don't >>>> terminate media. >>>> And certainly there are B2BUAs that *do* terminate media that you >>>> would not want to call an SBC. (E.g. a conference focus and mixer.) >>>> Thanks, >>>> Paul >>>>> Mo >>>>> >>>>> -----Original Message----- >>>>> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] >>>>> On Behalf Of Dan Wing (dwing) >>>>> Sent: Thursday, July 08, 2010 5:31 PM >>>>> To: Cullen Jennings (fluffy) >>>>> Cc: 'DISPATCH list' >>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>> >>>>>> -----Original Message----- >>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>> Sent: Thursday, July 08, 2010 1:34 PM >>>>>> To: Dan Wing >>>>>> Cc: DISPATCH list >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>> >>>>>> >>>>>> Seems reasonable. I think B2BUA is reasonable well >> defined. Care >>>>>> to put on your fire proof suit and propose a definition of what >>>>>> an SBC >>>>> is? >>>>> >>>>> SBC: a B2BUA that also terminates and originates media from user >>>>> agents or media from an adjacent SBC. >>>>> >>>>> -d >>>>> >>>>> >>>>>> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>>>>>> Sent: Thursday, July 08, 2010 5:50 AM >>>>>>>> To: Dan Wing >>>>>>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' >>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>>> >>>>>>>> >> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes >>>>>>>> - >>>>>> 03 >>>>>>>> has just been submitted. >>>>>>> Splendid. I refer to the media latching in that document >>>>> frequently. >>>>>>> Myself, I would be happier if IETF could find it possible to >>>>>>> include >>>>>>> the acronym-that-must-not-be-spoken (SBC) in SBC-related >>>>>>> specifications -- no matter if an SBC working group is >> formed or >>>>>>> not. Calling them 'middleboxes' is too vague to be >> useful, much >>>>>>> like "gateway" is too vague (a gateway to the PSTN? a >> router?) >>>>>>> Call >>>>>>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, >> and an SBC >>>>>>> an SBC. >>>>>>> >>>>>>> -d >>>>>>> >>>>>>> >>>>>>>> Dan Wing wrote: >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: dispatch-bounces@ietf.org >>>>>>>>>> [mailto:dispatch-bounces@ietf.org] >>>>>>>> On >>>>>>>>>> Behalf Of Peter Musgrave >>>>>>>>>> Sent: Thursday, July 01, 2010 12:30 PM >>>>>>>>>> To: WORLEY, Dale R (Dale) >>>>>>>>>> Cc: DISPATCH list >>>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG >> for SBCs? >>>>>>>>>> >>>>>>>>>> I concur. >>>>>>>>>> >>>>>>>>>> There is some useful background in RFC5853 and >> perhaps >> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 >>>>>>>>>> >>>>>>>>>> And then some things which died on the vine such as: >>>>>>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>>>>>>>> and perhaps some others? >>>>>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >>>>>> middleboxes- >>>>>>>> 02 died. >>>>>>>>> -d >>>>>>>> ... >>>>>>> _______________________________________________ >>>>>>> dispatch mailing list >>>>>>> dispatch@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>> Cullen Jennings >>>>>> For corporate legal information go to: >>>>>> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> _______________________________________________ >>>> 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 D.Malas@cablelabs.com Thu Jul 15 08:25:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1DF3A67E2 for ; Thu, 15 Jul 2010 08:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWJj92Tz4ZNB for ; Thu, 15 Jul 2010 08:25:31 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id A62053A6AC8 for ; Thu, 15 Jul 2010 08:25:31 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o6FFPSvq017415; Thu, 15 Jul 2010 09:25:28 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Thu, 15 Jul 2010 09:25:28 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Thu, 15 Jul 2010 09:25:28 -0600 From: Daryl Malas To: "'Marshall Eubanks'" , "Elwell, John" Date: Thu, 15 Jul 2010 09:25:27 -0600 Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: AcskLu1SQpx2H0jkRomsqXpO8K3SawAAv46A Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01419B252A@srvxchg> References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com> <114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg> <4C3E3FF6.1050003@cisco.com> <7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> In-Reply-To: <7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 15:25:33 -0000 I would prefer Monday night or Friday Lunch. Regards, Daryl=20 -----Original Message----- From: Marshall Eubanks [mailto:tme@americafree.tv]=20 Sent: Thursday, July 15, 2010 9:04 AM To: Elwell, John Cc: Paul Kyzivat; DISPATCH list; Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? OK, here are the options I see There is an informal Bar BOF list http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 Wednesday Lunch, thursday Lunch or Thursday before plenary are taken. I would suggest Monday night Wednesday after plenary Thursday after plenary Friday Lunch I would prefer Monday night, but these all WFM. Please let me know what you= think. Regards Marshall On Jul 15, 2010, at 9:57 AM, Elwell, John wrote: > I would try to join if there is no conflict. > > John > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Marshall Eubanks >> Sent: 15 July 2010 01:06 >> To: Paul Kyzivat >> Cc: DISPATCH list; Daryl Malas >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >> >> Should we arrange a (true) Bar BOF (AKA DrinkTime) for this topic in=20 >> Maastricht ? >> >> Marshall >> >> On Jul 14, 2010, at 6:53 PM, Paul Kyzivat wrote: >> >>> I won't comment on the rest of this right now, but its not right to=20 >>> describe a B2BUA as a function of an SBC. >>> Rather, an SBC is a particular sort of B2BUA. >>> There are *many* sorts of B2BUA that have nothing in common >> with an >>> SBC. >>> >>> Its actually this sort of disagreement that would benefit from=20 >>> beginning a taxonomy of B2BUAs. >>> >>> Thanks, >>> Paul >>> >>> Daryl Malas wrote: >>>> All, >>>> Many if not all of the functions of an SBC have already been=20 >>>> defined in one way or another. An SBC is a "jack-of-all-trades" >>>> platform. I think this is a slippery slope to try and >> define, and >>>> is a quagmire the IETF should stray from. In some cases, >> SBCs are >>>> not even deployed on the edge of networks. >>>> I agree that a B2BUA is different, but it could be considered a=20 >>>> function of the SBC. B2BUA's were created with the intention of=20 >>>> breaking up the end-to-end environment, so creating rules >> to define >>>> allowances for the end-to-end environment will be challenging at=20 >>>> best. >>>> Regards, >>>> Daryl >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] >>>> On Behalf Of Christer Holmberg >>>> Sent: Friday, July 09, 2010 12:44 PM >>>> To: Paul Kyzivat; Mohammad Al-Taraireh (maltarai) >>>> Cc: DISPATCH list >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>> Hi, >>>> Rather than focus on node terminology, I think we should focus on=20 >>>> the FUNCTIONS they perform, and see whether something can do done=20 >>>> in order to avoid claimed interop problems etc, rather >> than arguing >>>> about whether the entity that performs the function shall >> be called >>>> B2BUA, SBC, Application Server, or something else... >>>> Regards, >>>> Christer >>>> ________________________________________ >>>> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On=20 >>>> Behalf Of Paul Kyzivat [pkyzivat@cisco.com] >>>> Sent: Friday, July 09, 2010 3:10 AM >>>> To: Mohammad Al-Taraireh (maltarai) >>>> Cc: DISPATCH list >>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>> Mohammad Al-Taraireh (maltarai) wrote: >>>>> Doesn't the B2BUA term also implies media origination, and=20 >>>>> termination capabilities ? It seems that the B2BUA term >> is already >>>>> overloaded to include SBC. >>>> The term "B2BUA" is distinguished by the minimality of its=20 >>>> definition and the corresponding broadness of applicability. It=20 >>>> neither implies nor forbids media processing. >>>> The term SBC, as typically used, is somewhat narrower in >> scope that >>>> B2BUA, but is still incredibly broad. I certainly know of things=20 >>>> that consider themselves to be SBCs that (at least >> sometimes) don't >>>> terminate media. >>>> And certainly there are B2BUAs that *do* terminate media that you=20 >>>> would not want to call an SBC. (E.g. a conference focus and mixer.) >>>> Thanks, >>>> Paul >>>>> Mo >>>>> >>>>> -----Original Message----- >>>>> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] >>>>> On Behalf Of Dan Wing (dwing) >>>>> Sent: Thursday, July 08, 2010 5:31 PM >>>>> To: Cullen Jennings (fluffy) >>>>> Cc: 'DISPATCH list' >>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>> >>>>>> -----Original Message----- >>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>> Sent: Thursday, July 08, 2010 1:34 PM >>>>>> To: Dan Wing >>>>>> Cc: DISPATCH list >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>> >>>>>> >>>>>> Seems reasonable. I think B2BUA is reasonable well >> defined. Care >>>>>> to put on your fire proof suit and propose a definition of what=20 >>>>>> an SBC >>>>> is? >>>>> >>>>> SBC: a B2BUA that also terminates and originates media from user >>>>> agents or media from an adjacent SBC. >>>>> >>>>> -d >>>>> >>>>> >>>>>> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>>>>>> Sent: Thursday, July 08, 2010 5:50 AM >>>>>>>> To: Dan Wing >>>>>>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' >>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>>> >>>>>>>> >> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes >>>>>>>> - >>>>>> 03 >>>>>>>> has just been submitted. >>>>>>> Splendid. I refer to the media latching in that document >>>>> frequently. >>>>>>> Myself, I would be happier if IETF could find it possible to=20 >>>>>>> include the acronym-that-must-not-be-spoken (SBC) in SBC-related=20 >>>>>>> specifications -- no matter if an SBC working group is >> formed or >>>>>>> not. Calling them 'middleboxes' is too vague to be >> useful, much >>>>>>> like "gateway" is too vague (a gateway to the PSTN? a >> router?) >>>>>>> Call >>>>>>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, >> and an SBC >>>>>>> an SBC. >>>>>>> >>>>>>> -d >>>>>>> >>>>>>> >>>>>>>> Dan Wing wrote: >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: dispatch-bounces@ietf.org=20 >>>>>>>>>> [mailto:dispatch-bounces@ietf.org] >>>>>>>> On >>>>>>>>>> Behalf Of Peter Musgrave >>>>>>>>>> Sent: Thursday, July 01, 2010 12:30 PM >>>>>>>>>> To: WORLEY, Dale R (Dale) >>>>>>>>>> Cc: DISPATCH list >>>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG >> for SBCs? >>>>>>>>>> >>>>>>>>>> I concur. >>>>>>>>>> >>>>>>>>>> There is some useful background in RFC5853 and >> perhaps >> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 >>>>>>>>>> >>>>>>>>>> And then some things which died on the vine such as: >>>>>>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>>>>>>>> and perhaps some others? >>>>>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >>>>>> middleboxes- >>>>>>>> 02 died. >>>>>>>>> -d >>>>>>>> ... >>>>>>> _______________________________________________ >>>>>>> dispatch mailing list >>>>>>> dispatch@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>> Cullen Jennings >>>>>> For corporate legal information go to: >>>>>> >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> _______________________________________________ >>>> 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 adam@nostrum.com Thu Jul 15 08:27:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7CE43A6ACA for ; Thu, 15 Jul 2010 08:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CspgK5srAp7 for ; Thu, 15 Jul 2010 08:27:28 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 4A4713A6B11 for ; Thu, 15 Jul 2010 08:27:27 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6FFRUXI008517 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Jul 2010 10:27:30 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C3F28E2.3000102@nostrum.com> Date: Thu, 15 Jul 2010 10:27:30 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> <4BF53641.3070105@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> <4BF5563F.8090508@cisco.com> <4BF56106.4010806@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A554ADB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A854E68@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A854E68@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: DISPATCH Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 15:27:29 -0000 On 7/15/10 5:36 AM, Avasarala Ranjit-A20990 wrote: > After further thought, we feel that since the CDIV service is already standardized in 3GPP specifications 24.604 (Section 4.10.1.1) and hence there is no need for explicitly stating the requirements of a CDIV service again in a separate I-D or document. The problem is that section 4.10.1.1 of 24.604 isn't a statement of requirements. It's a high-level sketch of a solution to an unstated set of requirements. And section 4.10.2 of that same document is presumptuous enough to even define an XML Schema for use in this solution. In 3GPP language, you've jumped into stage 2 and stage 3 design without the stage 1 analysis. In the past, what has worked well for extensions to IETF protocols is when 3GPP does the stage 1 work, and then collaborates with the IETF to define a solution that satisfies both parties. I agree with John, Paul, and Mary -- if this work is to proceed, it really needs to back up to base principles: *what* are you trying to accomplish, not *how* do you want to accomplish it? The distinction is that the answer is to "what are you trying to accomplish" is phrased in terms of use cases ("a user receives real-time information about the calls he has missed"), not behavior ("the reason for diversion is delivered in a element"). > Also regarding any existing mechanisms, we feel there is/are no existing mechansim(s) for getting notifications of a particular call diversion service for a particular subscriber I think you misread John's proposal. He didn't ask for you to consider other existing solutions -- he asked you to talk about the potential solution space. Some of the feedback you've already received covers some of this space (e.g. information is published using HTTP, and users discover changes using draft-roach-sip-http-subscribe). > Now as per 3GPP's directive, we need to formally standardize the event package in IETF and hence the draft. If you want people to help you work on your event package -- as that is presumably why you're bringing it to DISPATCH -- then you need to bring us a problem to work on, not a complete solution to publish. > So please let us know how we can take this draft forward to a meaningful conclusion. I think you've been told several times already. What I'm inferring from your asking again is that you don't like the answer. I'm afraid there's not much that can be done about that. /a From keith.drage@alcatel-lucent.com Thu Jul 15 08:31:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F7583A6A7C; Thu, 15 Jul 2010 08:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.129 X-Spam-Level: X-Spam-Status: No, score=-4.129 tagged_above=-999 required=5 tests=[AWL=2.120, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4-Lwxi54L3M; Thu, 15 Jul 2010 08:31:33 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 7D7313A6AAD; Thu, 15 Jul 2010 08:31:32 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6FFVd50031833 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 15 Jul 2010 17:31:40 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 15 Jul 2010 17:31:39 +0200 From: "DRAGE, Keith (Keith)" To: Cullen Jennings , Gonzalo Camarillo Date: Thu, 15 Jul 2010 17:31:39 +0200 Thread-Topic: [dispatch] WG Review: Call Control UUI for SIP (cuss) Thread-Index: AcskJwQ62AMUW7QnQ6C5gSykgn3XKAAC0q5A Message-ID: References: <4C28F980.3040702@ericsson.com> <0010F1C2-2436-474D-BC1C-05AFC8A9E4C5@cisco.com> <4C3D7496.8020905@gmail.com> <71EA364F-6D56-45B3-BB9C-9C9AE1E1266C@cisco.com> In-Reply-To: <71EA364F-6D56-45B3-BB9C-9C9AE1E1266C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: DISPATCH list , IESG IESG , IETF-Discussion list Subject: Re: [dispatch] WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 15:31:36 -0000 At least from my perspective (which is from supporting the capabilities of = the ISDN User-to-User service) the answer is No. This is information above = the SIP layer in an application, and to look at the contents, one must come= out above the SIP layer into that application.=20 It could be conditional that the SIP message itself is not processed if the= information is not there, and the SIP request therefore rejected, but this= has nothing to do with the contents. And personally, I do not believe that= bit will every happen at a proxy, but will be at the recipient UA. regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: Thursday, July 15, 2010 3:06 PM > To: Gonzalo Camarillo > Cc: DISPATCH list; IESG IESG; IETF-Discussion list > Subject: Re: [dispatch] WG Review: Call Control UUI for SIP (cuss) >=20 >=20 > I don't think this resolves the issue. The issue is if this=20 > information is used for a call control. Basically do proxies=20 > need to be able to look at this to make decision about what=20 > they are going to do. We at least need a Yes/No answer to=20 > this question from the proponents of this work and the=20 > charter to make that clear.=20 >=20 >=20 > On Jul 14, 2010, at 2:25 AM, Gonzalo Camarillo wrote: >=20 > > Hi, > >=20 > > thanks for your comments on the charter proposal. Per the comments=20 > > received, we will modify bullet 5 as follows so that it is clearer: > >=20 > > OLD: > > 5. SIP elements may need to apply policy about passing and screening > > the information. > >=20 > > NEW: > > 5. SIP elements may need to apply policy about passing and filtering > > UUI. The included application, encoding, semantics, and content > > information will allow endpoint or intermediary SIP elements to > > allow or block UUI based on the type and originator, not based on > > the actual UUI data, which may be end-to-end encrypted by the > > application. > >=20 > > Further discussions on this topic should happen on the=20 > mailing list of=20 > > this WG. > >=20 > > Cheers, > >=20 > > Gonzalo > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From pkyzivat@cisco.com Thu Jul 15 10:02:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 167723A69C0 for ; Thu, 15 Jul 2010 10:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.45 X-Spam-Level: X-Spam-Status: No, score=-10.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCmy9NfloGFI for ; Thu, 15 Jul 2010 10:02:03 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 186733A685C for ; Thu, 15 Jul 2010 10:02:03 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAObbPkxAZnwM/2dsb2JhbACfZHGkKJsNhSQEiFA X-IronPort-AV: E=Sophos;i="4.55,209,1278288000"; d="scan'208";a="132823658" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2010 17:02:03 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6FH23fM023113; Thu, 15 Jul 2010 17:02:03 GMT Message-ID: <4C3F3F09.2010806@cisco.com> Date: Thu, 15 Jul 2010 13:02:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Marshall Eubanks References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com> <114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg> <4C3E3FF6.1050003@cisco.com> <7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> In-Reply-To: <7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 17:02:04 -0000 Marshall Eubanks wrote: > OK, here are the options I see > > There is an informal Bar BOF list > > http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 > > Wednesday Lunch, thursday Lunch or Thursday before plenary are taken. > > I would suggest > > Monday night > Wednesday after plenary > Thursday after plenary > Friday Lunch > > I would prefer Monday night, but these all WFM. Please let me know what > you think. Thurs aft plenary seems to be taken by E2MD. The others work for me at the moment. Paul From fluffy@cisco.com Thu Jul 15 10:27:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D602B3A691D; Thu, 15 Jul 2010 10:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.428 X-Spam-Level: X-Spam-Status: No, score=-110.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zCWUtNS+JFM; Thu, 15 Jul 2010 10:27:23 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id B6F353A681E; Thu, 15 Jul 2010 10:27:23 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMThPkyrR7Hu/2dsb2JhbACfZHGkQpsJhSQEg36EUg X-IronPort-AV: E=Sophos;i="4.55,209,1278288000"; d="scan'208";a="267714921" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2010 17:27:34 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6FHRXV2023154; Thu, 15 Jul 2010 17:27:33 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA071B8FE3@gaalpa1msgusr7e.ugd.att.com> Date: Thu, 15 Jul 2010 11:27:32 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <6B686782-AE50-4DF4-B09E-DF8A770DF184@cisco.com> References: <4C28F980.3040702@ericsson.com> <0010F1C2-2436-474D-BC1C-05AFC8A9E4C5@cisco.com><4C3D7496.8020905@gmail.com> <71EA364F-6D56-45B3-BB9C-9C9AE1E1266C@cisco.com> <14C85D6CCBE92743AF33663BF5D24EBA071B8FE3@gaalpa1msgusr7e.ugd.att.com> To: "DOLLY, MARTIN C (ATTLABS)" X-Mailer: Apple Mail (2.1081) Cc: DISPATCH list , IETF-Discussion list , IESG IESG , Gonzalo Camarillo Subject: Re: [dispatch] WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 17:27:25 -0000 OK - that removes a large part of the issues I raised. Let me see if I = can propose some text that we could all agree on. Cullen PS - Just to be clear these emails are all in my individual contributor = role. That was clear when it was IETF LC comment but given this is all = cross posted to dispatch, just wanted to be clear. On Jul 15, 2010, at 8:07 AM, DOLLY, MARTIN C (ATTLABS) wrote: > Cullen the answer to your question is No. >=20 > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf = Of > Cullen Jennings > Sent: Thursday, July 15, 2010 10:06 AM > To: Gonzalo Camarillo > Cc: DISPATCH list; IESG IESG; IETF-Discussion list > Subject: Re: WG Review: Call Control UUI for SIP (cuss) >=20 >=20 > I don't think this resolves the issue. The issue is if this = information > is used for a call control. Basically do proxies need to be able to = look > at this to make decision about what they are going to do. We at least > need a Yes/No answer to this question from the proponents of this work > and the charter to make that clear.=20 >=20 >=20 > On Jul 14, 2010, at 2:25 AM, Gonzalo Camarillo wrote: >=20 >> Hi, >>=20 >> thanks for your comments on the charter proposal. Per the comments >> received, we will modify bullet 5 as follows so that it is clearer: >>=20 >> OLD: >> 5. SIP elements may need to apply policy about passing and screening >> the information. >>=20 >> NEW: >> 5. SIP elements may need to apply policy about passing and filtering >> UUI. The included application, encoding, semantics, and content >> information will allow endpoint or intermediary SIP elements to >> allow or block UUI based on the type and originator, not based on >> the actual UUI data, which may be end-to-end encrypted by the >> application. >>=20 >> Further discussions on this topic should happen on the mailing list = of >> this WG. >>=20 >> Cheers, >>=20 >> Gonzalo >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From dworley@avaya.com Thu Jul 15 10:42:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80B633A6B44; Thu, 15 Jul 2010 10:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ItBgHV3DOyc; Thu, 15 Jul 2010 10:42:23 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 7E6A83A6A68; Thu, 15 Jul 2010 10:42:23 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,209,1278302400"; d="scan'208";a="228042454" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Jul 2010 13:42:34 -0400 X-IronPort-AV: E=Sophos;i="4.55,209,1278302400"; d="scan'208";a="492037241" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 15 Jul 2010 13:42:33 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.161]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 15 Jul 2010 13:42:33 -0400 From: "WORLEY, Dale R (Dale)" To: Cullen Jennings , Gonzalo Camarillo Date: Thu, 15 Jul 2010 13:40:35 -0400 Thread-Topic: WG Review: Call Control UUI for SIP (cuss) Thread-Index: AcskJubCPZh5hVQqSOqC2oSZjXlHwAAHe2ih Message-ID: References: <4C28F980.3040702@ericsson.com> <0010F1C2-2436-474D-BC1C-05AFC8A9E4C5@cisco.com> <4C3D7496.8020905@gmail.com>, <71EA364F-6D56-45B3-BB9C-9C9AE1E1266C@cisco.com> In-Reply-To: <71EA364F-6D56-45B3-BB9C-9C9AE1E1266C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH list , IESG IESG , IETF-Discussion list Subject: Re: [dispatch] WG Review: Call Control UUI for SIP (cuss) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 17:42:24 -0000 ________________________________________ From: ietf-bounces@ietf.org [ietf-bounces@ietf.org] On Behalf Of Cullen Jen= nings [fluffy@cisco.com] I don't think this resolves the issue. The issue is if this information is = used for a call control. Basically do proxies need to be able to look at th= is to make decision about what they are going to do. We at least need a Yes= /No answer to this question from the proponents of this work and the charte= r to make that clear. _______________________________________________ >From the discussion, it seems that proxies will not make call control decis= ions based on the *contents* of UUI, but they may make call control decisio= ns (specifically, rejection) based on the *presence* of UUI. So whether th= e anser is Yes or No depends on exactly how you phrase the question. Dale From ranjit@motorola.com Thu Jul 15 11:11:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7C1E3A692B for ; Thu, 15 Jul 2010 11:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ww1UhqM0Uia for ; Thu, 15 Jul 2010 11:11:22 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 1CAA43A6824 for ; Thu, 15 Jul 2010 11:11:21 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1279217491!44505369!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 11554 invoked from network); 15 Jul 2010 18:11:32 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Jul 2010 18:11:32 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o6FIBQFL018440 for ; Thu, 15 Jul 2010 11:11:31 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id o6FIBQFG021605 for ; Thu, 15 Jul 2010 13:11:26 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id o6FIBOjY021594 for ; Thu, 15 Jul 2010 13:11:25 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 02:10:59 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A854F03@ZMY16EXM66.ds.mot.com> In-Reply-To: <4C3F28E2.3000102@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-avasarala-dispatch-comm-div-notification-05 Thread-Index: AcskMkYtga8xd6LZRcGIK0UWLSCPMAAFIQYg References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> <4BF53641.3070105@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> <4BF5563F.8090508@cisco.com> <4BF56106.4010806@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A554ADB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A854E68@ZMY16EXM66.ds.mot.com> <4C3F28E2.3000102@nostrum.com> From: "Avasarala Ranjit-A20990" To: "Adam Roach" X-CFilter-Loop: Reflected Cc: DISPATCH Subject: Re: [dispatch] draft-avasarala-dispatch-comm-div-notification-05 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jul 2010 18:11:24 -0000 Hi Adam No Adam we have not jumped into Stage 3 without stage 1 analysis. In Stage 1 spec 22.173 Section 8.2.7.2 Communication Diversion Notification Enhancements talks of specific enhancements required for the Communication Diversion Notification and lists the parameters that could be part of the notification information. It also further talks about the trigger for initiating communication diversion notification information messages towards the subscriber. It finally lists all the elements that can be part of the Communication Diversion Notification Information. =20 So the section 8.2.7.2 of 22.173 should qualify to mention "what" we are trying to accomplish and the spec 24.604 describes the CDIVN service in detail and also proposes the required XML schema for the CDIVN XML package.=20 So as mentioned in section 8.2.7.1, the problem is a need for a mechanism for the subscribers to be notified of communication diversions. So in addition to the regular CFX services, as a service provider option, the subscribers are also provided with an option to subscribe to communication diversion notification service that will help them to receive notifications of their call diversions. Thanks Regards Ranjit -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Thursday, July 15, 2010 8:58 PM To: Avasarala Ranjit-A20990 Cc: Mary Barnes; DISPATCH Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 On 7/15/10 5:36 AM, Avasarala Ranjit-A20990 wrote: > After further thought, we feel that since the CDIV service is already standardized in 3GPP specifications 24.604 (Section 4.10.1.1) and hence there is no need for explicitly stating the requirements of a CDIV service again in a separate I-D or document. The problem is that section 4.10.1.1 of 24.604 isn't a statement of requirements. It's a high-level sketch of a solution to an unstated set of requirements. And section 4.10.2 of that same document is presumptuous enough to even define an XML Schema for use in this solution. In 3GPP language, you've jumped into stage 2 and stage 3 design without the stage 1 analysis. In the past, what has worked well for extensions to IETF protocols is when 3GPP does the stage 1 work, and then collaborates with the IETF to define a solution that satisfies both parties. I agree with John, Paul, and Mary -- if this work is to proceed, it really needs to back up to base principles: *what* are you trying to accomplish, not *how* do you want to accomplish it? The distinction is that the answer is to "what are you trying to accomplish" is phrased in terms of use cases ("a user receives real-time information about the calls he has missed"), not behavior ("the reason for diversion is delivered in a element"). > Also regarding any existing mechanisms, we feel there is/are no=20 > existing mechansim(s) for getting notifications of a particular call=20 > diversion service for a particular subscriber I think you misread John's proposal. He didn't ask for you to consider other existing solutions -- he asked you to talk about the potential solution space. Some of the feedback you've already received covers some of this space (e.g. information is published using HTTP, and users discover changes using draft-roach-sip-http-subscribe). > Now as per 3GPP's directive, we need to formally standardize the event package in IETF and hence the draft. If you want people to help you work on your event package -- as that is presumably why you're bringing it to DISPATCH -- then you need to bring us a problem to work on, not a complete solution to publish. > So please let us know how we can take this draft forward to a meaningful conclusion. I think you've been told several times already. What I'm inferring from your asking again is that you don't like the answer. I'm afraid there's not much that can be done about that. /a From partr@cisco.com Thu Jul 15 23:00:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07FE03A6844 for ; Thu, 15 Jul 2010 23:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.878 X-Spam-Level: X-Spam-Status: No, score=-9.878 tagged_above=-999 required=5 tests=[AWL=0.721, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tp71zfCpIBnK for ; Thu, 15 Jul 2010 23:00:50 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id E94BC3A6863 for ; Thu, 15 Jul 2010 23:00:49 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALaSP0xAaHte/2dsb2JhbACfa3GkD5pVhSQEg3yHCA X-IronPort-AV: E=Sophos;i="4.55,213,1278288000"; d="scan'208";a="227216391" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 16 Jul 2010 06:00:57 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6G60GTZ004967; Fri, 16 Jul 2010 06:00:56 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Jul 2010 11:30:47 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Jul 2010 11:30:24 +0530 Message-ID: In-Reply-To: <4C3F3F09.2010806@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: AcskP31PQpRnUp3RRJ+yQgy4gy37NAAbKXPA References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com><04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> <4C3F3F09.2010806@cisco.com> From: "Parthasarathi R (partr)" To: "Paul Kyzivat (pkyzivat)" , "Marshall Eubanks" X-OriginalArrivalTime: 16 Jul 2010 06:00:47.0444 (UTC) FILETIME=[3C46D140:01CB24AC] Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 06:00:54 -0000 +1=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Thursday, July 15, 2010 10:32 PM To: Marshall Eubanks Cc: DISPATCH list; Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? Marshall Eubanks wrote: > OK, here are the options I see >=20 > There is an informal Bar BOF list >=20 > http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 >=20 > Wednesday Lunch, thursday Lunch or Thursday before plenary are taken. >=20 > I would suggest >=20 > Monday night > Wednesday after plenary > Thursday after plenary > Friday Lunch >=20 > I would prefer Monday night, but these all WFM. Please let me know=20 > what you think. Thurs aft plenary seems to be taken by E2MD. The others work for me at the moment. Paul _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From gao.yang2@zte.com.cn Thu Jul 15 23:56:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C5423A68C5 for ; Thu, 15 Jul 2010 23:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.743 X-Spam-Level: X-Spam-Status: No, score=-97.743 tagged_above=-999 required=5 tests=[AWL=-0.119, BAYES_40=-0.185, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_74=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7tzHFk-woDN for ; Thu, 15 Jul 2010 23:56:46 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 86DB63A6843 for ; Thu, 15 Jul 2010 23:56:45 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 23121992332426; Fri, 16 Jul 2010 14:55:51 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 32441.2776214488; Fri, 16 Jul 2010 14:49:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6G6uPVG043155; Fri, 16 Jul 2010 14:56:25 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: DISPATCH list , Hadriel Kaplan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 16 Jul 2010 14:52:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-16 14:56:14, Serialize complete at 2010-07-16 14:56:14 Content-Type: multipart/alternative; boundary="=_alternative 0026091048257762_=" X-MAIL: mse2.zte.com.cn o6G6uPVG043155 Subject: [dispatch] Investigation about supporting Lawful interception's X1(Target Setting): X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 06:56:47 -0000 This is a multipart message in MIME format. --=_alternative 0026091048257762_= Content-Type: text/plain; charset="US-ASCII" Hi Hadriel & other SBC vendors, Firstly, I'd like to explain that only handover interfaces(H1/H2/H3) are national law specific, internal architecture and interface for network(such as IMS/NGN) should be allowed to be defined by IETF(such as RFC3924 Architecture for Lawful Intercept). Recent, I paid attention to IMS/NGN's lawful interception interworking. And I found that some SBCs do not support Lawful interception's X1(Target Setting). Then, we usually need to deploy another network element(such as P-CSCF of IMS) to do the control/triggering work for SBC, but the control/triggering interface is private interface(Infact, 3GPP/ETSI has no standard for LI relating SBC). I'd like to know how your equipment handle this issue? And you can use the naming in this figure(from RFC3924 Architecture for Lawful Intercept) as reference. Thanks, Gao +--------------------+ +-----+ | LI Administration | HI1(a) | | | Function |<--------------| | +--------------------+ | | | | | | MD Provisioning | | | Interface(b) | LEA | v | | +-----------+ +--------------------+ | | | |<---(c)----| | | | | IRI IAP |--IRI(e)-->| Mediation |----HI2(g)--->| | | | | Device (MD) | | | +-----------+ | |----HI3(h)--->| | +--------------------+ +-----+ | ^ Intercept | | Intercepted Request(d) | | Content(f) | | v | +--------------------+ User | Content | User ------->| IAP |--------> Content +--------------------+ Content =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0026091048257762_= Content-Type: text/html; charset="US-ASCII"
Hi Hadriel & other SBC vendors,

Firstly, I'd like to explain that only handover interfaces(H1/H2/H3) are national law specific, internal architecture and interface for network(such as IMS/NGN) should be allowed to be defined by IETF(such as RFC3924 Architecture for Lawful Intercept).

Recent, I paid attention to IMS/NGN's lawful interception interworking. And I found that some SBCs do not support Lawful interception's X1(Target Setting). Then, we usually need to deploy another network element(such as P-CSCF of IMS) to do the control/triggering work for SBC, but the control/triggering interface is private interface(Infact, 3GPP/ETSI has no standard for LI relating SBC).

I'd like to know how your equipment handle this issue? And you can use the naming in this figure(from RFC3924 Architecture for Lawful Intercept) as reference.

Thanks,

Gao


                       +--------------------+               +-----+
                          |  LI Administration |     HI1(a)    |     |
                          |      Function      |<--------------|     |
                          +--------------------+               |     |
                                 |                             |     |
                                 | MD Provisioning             |     |
                                 | Interface(b)                | LEA |
                                 v                             |     |
   +-----------+           +--------------------+              |     |
   |           |<---(c)----|                    |              |     |
   |  IRI IAP  |--IRI(e)-->|      Mediation     |----HI2(g)--->|     |
   |           |           |      Device (MD)   |              |     |
   +-----------+           |                    |----HI3(h)--->|     |
                           +--------------------+              +-----+
                                |         ^
                      Intercept |         | Intercepted
                     Request(d) |         | Content(f)
                                |         |
                                v         |
                              +--------------------+
                        User  |       Content      |  User
                      ------->|         IAP        |-------->
                      Content +--------------------+  Content


===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0026091048257762_=-- From gonzalo.camarillo@ericsson.com Fri Jul 16 04:11:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27F703A6987 for ; Fri, 16 Jul 2010 04:11:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.752 X-Spam-Level: X-Spam-Status: No, score=-105.752 tagged_above=-999 required=5 tests=[AWL=0.847, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGT17lRPEfI4 for ; Fri, 16 Jul 2010 04:11:32 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 7D5533A69B1 for ; Fri, 16 Jul 2010 04:11:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-4f-4c403e6f8475 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C2.16.10125.F6E304C4; Fri, 16 Jul 2010 13:11:43 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 13:11:27 +0200 Received: from [131.160.126.225] ([131.160.126.225]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 13:11:27 +0200 Message-ID: <4C403E5E.3010405@ericsson.com> Date: Fri, 16 Jul 2010 14:11:26 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Muthu ArulMozhi Perumal (mperumal)" References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2010 11:11:27.0584 (UTC) FILETIME=[A2AA7600:01CB24D7] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 11:11:34 -0000 Hi, the purpose of RFC 5853 was to identify functions that are currently performed by SBCs and cause some type of problem. It was expected that recommendations on how to perform those functions in a better way were going to follow. The parallelism with BEHAVE is clear. BEHAVE identified functions performed by NATs (filtering and mapping) and recommended how they should be performed to minimize problems related to those functions. So, for example, if we find that the way current SBCs perform media management causes problems, specifying how to properly implement that particular function would make sense. In addition to clarifying how to implement individual functions, it has been suggested to come up with a taxonomy for SBCs. If people could elaborate on the usefulness of such an exercise, that would be great. For example, SBC type 1 could be defined as performing media management and NAT binding maintenance while SBC type 2 could be defined as performing media management and topology hiding. Do people think that grouping individual functions in bundles to form a taxonomy be useful? Thanks, Gonzalo On 01/07/2010 8:27 PM, Muthu ArulMozhi Perumal (mperumal) wrote: > In the past few years there has been a proliferation of Session Border > Controller (SBC) deployments in SIP networks mainly because the > development of SIP protocol specifications hasn't been able to keep in > pace with industry and operator requirements. The common functions they > perform and the architectural issues they introduce are described in > RFC-5853. > > > > Due to lack of well defined guidelines and best current practices many > SBC implementations break end-to-end features and introduce problems > that are difficult to troubleshoot, many a times because of poor > implementations rather than to meet any specific requirements. For > example, when they do media processing they assume everything coming on > the media channel is RTP, don't do even basic RTP header validations as > recommended in RFC-3550, try to decode STUN and DTLS packets as RTP > corrupting them and making them useless. > > > > I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to > the one for NATs, to set guidelines and identify best current practices > to encourage better SBC implementations, interoperability and ease of > troubleshooting, rather than just keeping quiet and letting them go out > of control. > > > > Comments? > > > > Muthu > From pkyzivat@cisco.com Fri Jul 16 07:52:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBC973A6915 for ; Fri, 16 Jul 2010 07:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4gp7J6KBzBq for ; Fri, 16 Jul 2010 07:52:49 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B30753A686C for ; Fri, 16 Jul 2010 07:52:49 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,215,1278288000"; d="scan'208";a="133253859" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Jul 2010 14:53:01 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6GEr1YP006408; Fri, 16 Jul 2010 14:53:01 GMT Message-ID: <4C40724C.4010109@cisco.com> Date: Fri, 16 Jul 2010 10:53:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gonzalo Camarillo References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <4C403E5E.3010405@ericsson.com> In-Reply-To: <4C403E5E.3010405@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 14:52:51 -0000 You can blame me for the recommendation about a taxonomy. But I'm talking about a taxonomy of B2BUAs, not of SBCs. In terms of scope the B3BUA:SBC relationship is analogous to the Animal:Hominid relationship. I don't yet know if it is a task worth doing. But IMO the primary value it would bring is simply in making it easier for people to talk to one another about these things and have some confidence that they were talking about the same thing. In my experience many people seem to think that all B2BUAs are similar to whatever one kind they have had experience with. Thanks, Paul Gonzalo Camarillo wrote: > Hi, > > the purpose of RFC 5853 was to identify functions that are currently > performed by SBCs and cause some type of problem. It was expected that > recommendations on how to perform those functions in a better way were > going to follow. > > The parallelism with BEHAVE is clear. BEHAVE identified functions > performed by NATs (filtering and mapping) and recommended how they > should be performed to minimize problems related to those functions. > > So, for example, if we find that the way current SBCs perform media > management causes problems, specifying how to properly implement that > particular function would make sense. > > In addition to clarifying how to implement individual functions, it has > been suggested to come up with a taxonomy for SBCs. If people could > elaborate on the usefulness of such an exercise, that would be great. > For example, SBC type 1 could be defined as performing media management > and NAT binding maintenance while SBC type 2 could be defined as > performing media management and topology hiding. Do people think that > grouping individual functions in bundles to form a taxonomy be useful? > > Thanks, > > Gonzalo > > > > > On 01/07/2010 8:27 PM, Muthu ArulMozhi Perumal (mperumal) wrote: >> In the past few years there has been a proliferation of Session Border >> Controller (SBC) deployments in SIP networks mainly because the >> development of SIP protocol specifications hasn't been able to keep in >> pace with industry and operator requirements. The common functions they >> perform and the architectural issues they introduce are described in >> RFC-5853. >> >> >> >> Due to lack of well defined guidelines and best current practices many >> SBC implementations break end-to-end features and introduce problems >> that are difficult to troubleshoot, many a times because of poor >> implementations rather than to meet any specific requirements. For >> example, when they do media processing they assume everything coming on >> the media channel is RTP, don't do even basic RTP header validations as >> recommended in RFC-3550, try to decode STUN and DTLS packets as RTP >> corrupting them and making them useless. >> >> >> >> I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to >> the one for NATs, to set guidelines and identify best current practices >> to encourage better SBC implementations, interoperability and ease of >> troubleshooting, rather than just keeping quiet and letting them go out >> of control. >> >> >> >> Comments? >> >> >> >> Muthu >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From HKaplan@acmepacket.com Fri Jul 16 08:16:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3326B3A680C for ; Fri, 16 Jul 2010 08:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_74=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujv5IIR2LUol for ; Fri, 16 Jul 2010 08:16:09 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 34F173A69FF for ; Fri, 16 Jul 2010 08:16:09 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 16 Jul 2010 11:16:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 16 Jul 2010 11:15:53 -0400 From: Hadriel Kaplan To: "gao.yang2@zte.com.cn" , DISPATCH list Date: Fri, 16 Jul 2010 11:15:53 -0400 Thread-Topic: [dispatch] Investigation about supporting Lawful interception's X1(Target Setting): Thread-Index: AcsktDda8gqoDtpkRsGA/m54hluMzQAQ39WQ Message-ID: <430FC6BDED356B4C8498F634416644A921187F7245@mail> 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: multipart/alternative; boundary="_000_430FC6BDED356B4C8498F634416644A921187F7245mail_" MIME-Version: 1.0 Subject: Re: [dispatch] Investigation about supporting Lawful interception's X1(Target Setting): X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 15:16:16 -0000 --_000_430FC6BDED356B4C8498F634416644A921187F7245mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Gao, The IETF does not define or work on Lawful Intercept protocols (partly beca= use they're national-law specific). RFC 3924 was only an informational, an= d maybe even only an individual document published by the RFC Editor, not a= n IETF document (see the IESG note in the RFC). It's confusing because tec= hnically the RFC Editor is not part of the IETF, and the IETF is just one p= articular user/customer/client of the RFC Editor - the IETF asks the RFC Ed= itor to publish documents, but so can others. Regardless, your question is probably better directed to the SIP Implemento= rs list (sip-implementors@lists.cs.columbia.edu) or even better: to individual people at the respective= SBC vendors, and not DISPATCH, since it isn't really germane to DISPATCH. = (As for my employer's SBC's, they do support the X1 interface if you have = the right software version) -hadriel ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of gao.yang2@zte.com.cn Sent: Friday, July 16, 2010 2:52 AM To: DISPATCH list; Hadriel Kaplan Subject: [dispatch] Investigation about supporting Lawful interception's X1= (Target Setting): Hi Hadriel & other SBC vendors, Firstly, I'd like to explain that only handover interfaces(H1/H2/H3) are na= tional law specific, internal architecture and interface for network(such a= s IMS/NGN) should be allowed to be defined by IETF(such as RFC3924 Architec= ture for Lawful Intercept). Recent, I paid attention to IMS/NGN's lawful interception interworking. And= I found that some SBCs do not support Lawful interception's X1(Target Sett= ing). Then, we usually need to deploy another network element(such as P-CSC= F of IMS) to do the control/triggering work for SBC, but the control/trigge= ring interface is private interface(Infact, 3GPP/ETSI has no standard for L= I relating SBC). I'd like to know how your equipment handle this issue? And you can use the = naming in this figure(from RFC3924 Architecture for Lawful Intercept) as re= ference. Thanks, Gao +--------------------+ +-----+ | LI Administration | HI1(a) | | | Function |<--------------| | +--------------------+ | | | | | | MD Provisioning | | | Interface(b) | LEA | v | | +-----------+ +--------------------+ | | | |<---(c)----| | | | | IRI IAP |--IRI(e)-->| Mediation |----HI2(g)--->| | | | | Device (MD) | | | +-----------+ | |----HI3(h)--->| | +--------------------+ +-----+ | ^ Intercept | | Intercepted Request(d) | | Content(f) | | v | +--------------------+ User | Content | User ------->| IAP |--------> Content +--------------------+ Content =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --_000_430FC6BDED356B4C8498F634416644A921187F7245mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey Gao,

The IETF does not define or work on La= wful Intercept protocols (partly because they’re national-law specific).  RFC 3924 was only an informatio= nal, and maybe even only an individual document published by the RFC Editor, not= an IETF document (see the IESG note in the RFC).  It’s confusing because technically the RFC Editor is not part of the IETF, and the IETF is just one particular user/customer/client of the RFC Editor – the IETF asks the RFC Editor to publish documents, but so can others.

 

Regardless, your question is probably better directed to the SIP Implementors list (sip-implementors@lis= ts.cs.columbia.edu) or even better: to individual people at the respective SBC vendors, and not DISPATCH, since it isn’t really germane to DISPATCH.  (As for my employer’s SBC’s, they do support the X1 interface if you have = the right software version)

 

-hadriel

 

From: dispatch= -bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On B= ehalf Of gao.yang2@zte.com.cn
Sent: Friday, July 16, 2010 = 2:52 AM
To: DISPATCH list; Hadriel Kaplan
Subject: [dispatch] Investig= ation about supporting Lawful interception's X1(Target Setting):

 


Hi Hadriel & other SBC vendors, <= br>
Firstly, I'd like to explain that only handover interfaces(H1/H2/H3) are national la= w specific, internal architecture and interface for network(such as IMS/NGN) = should be allowed to be defined by IETF(such as RFC3924 Architecture for Lawful Intercept).

Recent, I paid attention to IMS/NGN's lawful interception interworking. And I found that some SBCs do not support Lawful interception's X1(Target Setting). The= n, we usually need to deploy another network element(such as P-CSCF of IMS) to= do the control/triggering work for SBC, but the control/triggering interface i= s private interface(Infact, 3GPP/ETSI has no standard for LI relating SBC). <= /span>

I'd like to know how your equipment handle this issue? And you can use the nami= ng in this figure(from RFC3924 Architecture for Lawful Intercept) as reference= .

Thanks,

Gao


                       +--------------------+             &nbs= p; +-----+
                       = ;   |  LI Administration |     HI1(a)    | &nbs= p;   |
                       = ;   |      Function      |<------------= --|     |
                       = ;   +--------------------+             &nb= sp; |     |
                       = ;          |           &nbs= p;                 |     |
                       = ;          | MD Provisioning       &n= bsp;     |     |
                       = ;          | Interface(b)        = ;        | LEA |
                       = ;          v           &nbs= p;                 |     |
   +-----------+           +-------------------= -+              |     |
   |           |<---(c)----|                    |     &nbs= p;        |     |
   |  IRI IAP  |--IRI(e)-->|      Mediation     |----HI2(g)--->|     |
   |           |         &n= bsp; |      Device (MD)   |         &nbs= p;    |     |
   +-----------+           |     &nbs= p;              |----HI3(h)--->|     |
                       = ;    +--------------------+           &nbs= p;  +-----+
                       = ;         |         ^ <= br>                       Inter= cept |         | Intercepted
                     Reques= t(d) |         | Content(f)
                       = ;         |         | <= br>                        = ;         v         | <= br>                        = ;       +--------------------+
                       = ; User  |       Content      |  User<= /span>
                      ------->|         IAP        |-------->
                      Conte= nt +--------------------+  Content


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<=
o:p> 
------------=
--------------------------------------------
= 
ZTE Inf=
ormation Security Notice: The information containe=
d in this mail is solely property of&nbs=
p;the sender's organization. This mail communicati=
on is confidential. Recipients named above ar=
e obligated to maintain secrecy and are =
not permitted to disclose the contents of&nbs=
p;this communication to others.
This em=
ail and any files transmitted with it ar=
e confidential and intended solely for the&nb=
sp;use of the individual or entity to wh=
om they are addressed. If you have recei=
ved this email in error please notify th=
e originator of the message. Any views e=
xpressed in this message are those of th=
e individual sender.
This me=
ssage has been scanned for viruses and S=
pam by ZTE Anti-Spam system.
--_000_430FC6BDED356B4C8498F634416644A921187F7245mail_-- From gonzalo.camarillo@ericsson.com Fri Jul 16 08:24:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BDAD3A680C for ; Fri, 16 Jul 2010 08:24:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.551 X-Spam-Level: X-Spam-Status: No, score=-104.551 tagged_above=-999 required=5 tests=[AWL=-0.366, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvCzAwjvszvE for ; Fri, 16 Jul 2010 08:24:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 53AA83A67CC for ; Fri, 16 Jul 2010 08:24:54 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-79-4c4079d1953a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 3F.10.10125.1D9704C4; Fri, 16 Jul 2010 17:25:05 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 17:24:34 +0200 Received: from [131.160.126.225] ([131.160.126.225]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 16 Jul 2010 17:24:34 +0200 Message-ID: <4C4079B0.2010406@ericsson.com> Date: Fri, 16 Jul 2010 18:24:32 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2010 15:24:34.0347 (UTC) FILETIME=[FEAE97B0:01CB24FA] X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Renaming a WG: LSD -> SPLICES X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 15:24:55 -0000 Folks, I used to think that naming a WG was a fairly trivial task... now I know better :o) to be clear, we are talking about the WG that will work on disaggregated media in SIP. Originally, the acronym proposed for the WG was DISMANTLE. However, it was pointed out that DISMANTLE is longer than 8 characters. Even though there are WGs with acronyms that are longer than 8 characters, such acronyms cause database-related problems. So, we were asked to change it. The second acronym that was proposed was LSD. However, it seems there already was a WG called exactly like that, which concluded a few years ago. Reusing the acronym of an old WG caused some database problems as well. So, we were asked to change it again. The third alternative was LSDTRIP. However, at that point, an IESG member stated that he did not really like drug-related acronyms. So, we were asked to change it once more. As the fourth alternative we thought of ELUSIVE (loosELy-coUpled SIp deVicEs), which is defined as "hard to identify" in the dictionary. This WG has indeed been hard to identify so far. However, we finally decided to call it as follows: splices looSely-couPLed sIp deviCES To splice is defined as: 1 a : to unite (as two ropes) by interweaving the strands b : to unite (as lengths of magnetic tape) by overlapping and securing together two ends 2 : to unite, link, or insert as if by splicing 3 : to combine or insert (as genes) by genetic engineering This is actually what the WG will work on. They will take different media streams and combine them into a session. So, the acronym is very appropriate. >From now on, I hope DISPATCH not only produces acceptable charters, but also acceptable acronyms the first time around ;o) Cheers, Gonzalo From mary.ietf.barnes@gmail.com Fri Jul 16 10:10:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E1843A68DD for ; Fri, 16 Jul 2010 10:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeAtwu0IHcVC for ; Fri, 16 Jul 2010 10:10:34 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 099DE3A68DC for ; Fri, 16 Jul 2010 10:10:33 -0700 (PDT) Received: by gxk1 with SMTP id 1so1175245gxk.31 for ; Fri, 16 Jul 2010 10:10:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=avU6uemj31kqT9oHUwYV4mJP/5tYxbc6ObDF9ySXcCQ=; b=oU2oQlfH9Re19pOPECqwDB6IzZmba6wc6hF97jnOOgmEia0Ls9xRThDwIdqJ1VpqqD 8UoDVWCEHg+eH8KNfmr+uAs7PNDnrf7LMBN4Wm1RR/cQ3SzLg+2sDUoyH/geVwcXrkz+ yCN8D2JrqnVzMttBZZQIfpQJBX6WXE7XRpz2g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=uaJbrbl3SLXZUQAAvsiS9+jdzqnE324JWzU0RFvpgJMe5m1vmjjjXM+t3XAILboxJU fCYUsMR9irsT7zplOuSPGmMGQDe0Ewcc949sKygDyfljnuUFNmNo5ziDvR8dipmBiT67 rwSUPDrBy9g+E0jqvSqcUjK+7lv1BYRwLkbjk= MIME-Version: 1.0 Received: by 10.90.79.13 with SMTP id c13mr1060542agb.127.1279300241510; Fri, 16 Jul 2010 10:10:41 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Fri, 16 Jul 2010 10:10:41 -0700 (PDT) Date: Fri, 16 Jul 2010 12:10:41 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Cc: "Botzko, Stephen" , rai-ads@tools.ietf.org Subject: [dispatch] Doodle poll: Telepresence adhoc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 17:10:35 -0000 Hi, An adhoc for the telepresence work has been suggested for IETF-78. The agenda would be something like the following (depending, of course, upon the discussion during the WG session): 1) Debrief - DISPATCH session (10 min) 2) Next Steps (45 minutes): a) Additional use cases to consider (and volunteers to provide details) ? b) Refining problem statement document c) Starting requirements document d) Architectural Framework document - is it time to start that? 3) Plans going forward - discuss regular calls, mailing list setup, etc. (10 min) 4) AOB (discuss potential technical issues, etc.) as time allows (10 min) Please respond to the doodle poll if you have an interest in and would like to contribute to this proposed work item (i.e., willing to be part of a design team): http://www.doodle.com/h968u6tgehyt9ffg The links to charter proposal and related documents are in the DISPATCH WG agenda: http://www.ietf.org/proceedings/78/agenda/dispatch.html PLEASE respond by COB on Monday, July 19th, so that we can work on getting a meeting room for the selected time. Thanks, Mary DISPATCH WG co-chair From Even.roni@huawei.com Fri Jul 16 10:27:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5D033A6A0C for ; Fri, 16 Jul 2010 10:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UNeAN90FCw4g for ; Fri, 16 Jul 2010 10:27:36 -0700 (PDT) Received: from szxga05-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 6550C3A68DC for ; Fri, 16 Jul 2010 10:27:36 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5N00KH2V6BXS@szxga05-in.huawei.com> for dispatch@ietf.org; Sat, 17 Jul 2010 01:27:47 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L5N00MEHV6AHU@szxga05-in.huawei.com> for dispatch@ietf.org; Sat, 17 Jul 2010 01:27:47 +0800 (CST) Received: from windows8d787f9 (bzq-79-176-26-238.red.bezeqint.net [79.176.26.238]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L5N00GKCV65VQ@szxml02-in.huawei.com>; Sat, 17 Jul 2010 01:27:46 +0800 (CST) Date: Fri, 16 Jul 2010 20:26:56 +0300 From: Roni Even In-reply-to: To: 'Mary Barnes' , 'DISPATCH' Message-id: <017501cb250c$1b172cd0$51458670$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcslCdpx+MscxkzATuCviJFOti0GxQAAbD9g References: Cc: rai-ads@tools.ietf.org, "'Botzko, Stephen'" Subject: Re: [dispatch] Doodle poll: Telepresence adhoc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 17:27:38 -0000 Mary, The doodle is coming with a weird time zone and I am not sure what are the proposed options Roni > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Mary Barnes > Sent: Friday, July 16, 2010 8:11 PM > To: DISPATCH > Cc: Botzko, Stephen; rai-ads@tools.ietf.org > Subject: [dispatch] Doodle poll: Telepresence adhoc > > Hi, > > An adhoc for the telepresence work has been suggested for IETF-78. > > The agenda would be something like the following (depending, of > course, upon the discussion during the WG session): > > 1) Debrief - DISPATCH session (10 min) > > 2) Next Steps (45 minutes): > a) Additional use cases to consider (and volunteers to provide details) > ? > b) Refining problem statement document > c) Starting requirements document > d) Architectural Framework document - is it time to start that? > > 3) Plans going forward - discuss regular calls, mailing list setup, > etc. (10 min) > > 4) AOB (discuss potential technical issues, etc.) as time allows (10 > min) > > > Please respond to the doodle poll if you have an interest in and would > like to contribute to this proposed work item (i.e., willing to be > part of a design team): > http://www.doodle.com/h968u6tgehyt9ffg > > The links to charter proposal and related documents are in the > DISPATCH WG agenda: > http://www.ietf.org/proceedings/78/agenda/dispatch.html > > PLEASE respond by COB on Monday, July 19th, so that we can work on > getting a meeting room for the selected time. > > Thanks, > Mary > DISPATCH WG co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Fri Jul 16 10:37:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96FD73A685C for ; Fri, 16 Jul 2010 10:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6LeN5XenuTd for ; Fri, 16 Jul 2010 10:37:50 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 658C63A6839 for ; Fri, 16 Jul 2010 10:37:50 -0700 (PDT) Received: by iwn38 with SMTP id 38so2517428iwn.31 for ; Fri, 16 Jul 2010 10:38:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=h4IK0dUjzw8fyj7k/UvzHveQ+7gu3YyW01nCmKkpeOA=; b=Og+q5mRbbJ49A6TSnq3KryhCyYV2seIuMFVn83ypW3H41ivAFFpVEoKqMZKePcCv/H v9JdkusyjorPWOuLY8fp0SDMxsoFSRZW2Jf6IrPonQzJoeXfGWppN0uRCWLHnxyVFWNZ OWNnpkFnLXQyJXhJD5wcv3qwhtpwzjfYLsuvI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=LdPomR1nQjA+G6CA6YvalJx6XCjjOAp7dpDLqOSOzNnshAQssP03CxhEVcM8IVRCcd glEPMY7ASwSFbjG4Aq53BqbuqewCDV61+S82Vbd6SXLOh8EdmfR878GBRPf8xFBkZQ11 hifBOm1ypc2EvwBNM670kOBIMAOvvUXyragiE= MIME-Version: 1.0 Received: by 10.231.172.205 with SMTP id m13mr1249658ibz.35.1279301881892; Fri, 16 Jul 2010 10:38:01 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Fri, 16 Jul 2010 10:38:01 -0700 (PDT) In-Reply-To: <017501cb250c$1b172cd0$51458670$%roni@huawei.com> References: <017501cb250c$1b172cd0$51458670$%roni@huawei.com> Date: Fri, 16 Jul 2010 12:38:01 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rai-ads@tools.ietf.org, DISPATCH , "Botzko, Stephen" Subject: Re: [dispatch] Doodle poll: Telepresence adhoc X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jul 2010 17:37:51 -0000 Sorry, I goofed...out of habit I put the times in central timezone which is silly since we'll be in Europe. I'll redo ... On Fri, Jul 16, 2010 at 12:26 PM, Roni Even wrote: > Mary, > The doodle is coming with a weird time zone and I am not sure what are th= e > proposed options > > Roni > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Mary Barnes >> Sent: Friday, July 16, 2010 8:11 PM >> To: DISPATCH >> Cc: Botzko, Stephen; rai-ads@tools.ietf.org >> Subject: [dispatch] Doodle poll: Telepresence adhoc >> >> Hi, >> >> An adhoc for the telepresence work has been suggested for IETF-78. >> >> The agenda would be something like the following (depending, of >> course, upon the discussion during the WG session): >> >> 1) Debrief - DISPATCH session (10 min) >> >> 2) =A0Next Steps (45 minutes): >> a) Additional use cases to consider (and volunteers to provide details) >> ? >> b) Refining problem statement document >> c) Starting requirements document >> d) Architectural Framework document - is it time to start that? >> >> 3) Plans going forward - discuss regular calls, mailing list setup, >> etc. (10 min) >> >> 4) AOB (discuss potential technical issues, etc.) as time allows (10 >> min) >> >> >> Please respond to the doodle poll if you have an interest in and would >> like to contribute to this proposed work item (i.e., willing to be >> part of a design team): >> http://www.doodle.com/h968u6tgehyt9ffg >> >> The links to charter proposal and related documents are in the >> DISPATCH WG agenda: >> http://www.ietf.org/proceedings/78/agenda/dispatch.html >> >> PLEASE respond by COB on Monday, July 19th, so that we can work on >> getting a meeting room for the selected time. >> >> Thanks, >> Mary >> DISPATCH WG co-chair >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > From gonzalo.camarillo@ericsson.com Sat Jul 17 00:00:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFF0A3A6831 for ; Sat, 17 Jul 2010 00:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.741 X-Spam-Level: X-Spam-Status: No, score=-105.741 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLtuDui0hFGZ for ; Sat, 17 Jul 2010 00:00:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 2B3573A6359 for ; Sat, 17 Jul 2010 00:00:53 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-8e-4c41553114e0 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2F.54.10125.135514C4; Sat, 17 Jul 2010 09:01:05 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 17 Jul 2010 09:01:04 +0200 Received: from [131.160.126.225] ([131.160.126.225]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sat, 17 Jul 2010 09:01:04 +0200 Message-ID: <4C415530.7060407@ericsson.com> Date: Sat, 17 Jul 2010 10:01:04 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Paul Kyzivat References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <4C403E5E.3010405@ericsson.com> <4C40724C.4010109@cisco.com> In-Reply-To: <4C40724C.4010109@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2010 07:01:04.0699 (UTC) FILETIME=[D2BDE0B0:01CB257D] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jul 2010 07:00:55 -0000 Hi Paul, yes, coming up with common terminology may be useful in order to have more effective and efficient communications. Cheers, Gonzalo On 16/07/2010 5:53 PM, Paul Kyzivat wrote: > You can blame me for the recommendation about a taxonomy. > But I'm talking about a taxonomy of B2BUAs, not of SBCs. > > In terms of scope the B3BUA:SBC relationship is analogous to the > Animal:Hominid relationship. > > I don't yet know if it is a task worth doing. But IMO the primary value > it would bring is simply in making it easier for people to talk to one > another about these things and have some confidence that they were > talking about the same thing. > > In my experience many people seem to think that all B2BUAs are similar > to whatever one kind they have had experience with. > > Thanks, > Paul > > Gonzalo Camarillo wrote: >> Hi, >> >> the purpose of RFC 5853 was to identify functions that are currently >> performed by SBCs and cause some type of problem. It was expected that >> recommendations on how to perform those functions in a better way were >> going to follow. >> >> The parallelism with BEHAVE is clear. BEHAVE identified functions >> performed by NATs (filtering and mapping) and recommended how they >> should be performed to minimize problems related to those functions. >> >> So, for example, if we find that the way current SBCs perform media >> management causes problems, specifying how to properly implement that >> particular function would make sense. >> >> In addition to clarifying how to implement individual functions, it has >> been suggested to come up with a taxonomy for SBCs. If people could >> elaborate on the usefulness of such an exercise, that would be great. >> For example, SBC type 1 could be defined as performing media management >> and NAT binding maintenance while SBC type 2 could be defined as >> performing media management and topology hiding. Do people think that >> grouping individual functions in bundles to form a taxonomy be useful? >> >> Thanks, >> >> Gonzalo >> >> >> >> >> On 01/07/2010 8:27 PM, Muthu ArulMozhi Perumal (mperumal) wrote: >>> In the past few years there has been a proliferation of Session Border >>> Controller (SBC) deployments in SIP networks mainly because the >>> development of SIP protocol specifications hasn't been able to keep in >>> pace with industry and operator requirements. The common functions they >>> perform and the architectural issues they introduce are described in >>> RFC-5853. >>> >>> >>> >>> Due to lack of well defined guidelines and best current practices many >>> SBC implementations break end-to-end features and introduce problems >>> that are difficult to troubleshoot, many a times because of poor >>> implementations rather than to meet any specific requirements. For >>> example, when they do media processing they assume everything coming on >>> the media channel is RTP, don't do even basic RTP header validations as >>> recommended in RFC-3550, try to decode STUN and DTLS packets as RTP >>> corrupting them and making them useless. >>> >>> >>> >>> I am wondering whether IETF should have a BEHAVE WG for SBCs, similar to >>> the one for NATs, to set guidelines and identify best current practices >>> to encourage better SBC implementations, interoperability and ease of >>> troubleshooting, rather than just keeping quiet and letting them go out >>> of control. >>> >>> >>> >>> Comments? >>> >>> >>> >>> Muthu >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> From fluffy@cisco.com Sun Jul 18 08:50:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47D5C3A6982 for ; Sun, 18 Jul 2010 08:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.445 X-Spam-Level: X-Spam-Status: No, score=-110.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA7B+YgL4liB for ; Sun, 18 Jul 2010 08:50:05 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id EC5F73A6A59 for ; Sun, 18 Jul 2010 08:50:04 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,223,1278288000"; d="scan'208";a="560890040" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 18 Jul 2010 15:50:18 +0000 Received: from sjc-vpn5-1880.cisco.com (sjc-vpn5-1880.cisco.com [10.21.95.88]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6IFoIBE016665; Sun, 18 Jul 2010 15:50:18 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Sun, 18 Jul 2010 08:50:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> To: Bernard Aboba X-Mailer: Apple Mail (2.1081) Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 15:50:07 -0000 Bernard, obviously a large percentage of the work done in RAI is to = allow rich communications over the internet and for the most part the = existing work today from AVT, MMUSIC, SIP and so on already solves your = point (a) below. However one of the hard problems is how to go from an = phone number to an internet address. This WG is focused on that problem.=20= Yes, one of the benefits of this is that when combined with other large = parts of RAI work, it would help solve (a) but it's also useful for = thing other than adding video to a PSTN call. Superficially, the final = information delivered by VIPR is very similar to the information public = ENUM provides. They both go from a phone number to internet address. = They both can be used by many protocols including SIP but there's = nothing about just doing upgrade from voice to video - that is basically = an consequence of SIP running over the internet, not something that VIPR = does. However EBUM and VIPR are very different with regards to the the = source of information provided, the implementation complexity, and the = incentives for deployment. I can easily imagine a PBX that first did a = dip in some private ENUM, then public ENUM presuming it called a country = with some support for public ENUM, then if nothing had be found, to VIPR = before falling back to route a call over the PSTN. So in this regards it = is hardly a replacement for ENUM.=20 On Jul 12, 2010, at 7:09 , Bernard Aboba wrote: > It strikes me that there are a number of closely related problems = here: >=20 > a. One problem is the need to be able to "upgrade" an audio call in = progress in order to provide for additional media, even if the call had = been completed over the PSTN so that there was no SDP offer/answer = negotiation between the end-points. This is the problem that Facetime = solves, for example.=20 Irrelevant side point but, Really? I was under the impression that if = Facetime started a call over the PSTN it would not upgrade it to video.=20= >=20 > b. Another problem is the need for a public ENUM replacement. =20 >=20 > In the process of solving problem a, we might also need to solve = problem b, but that depends on the approach that is taken; not all = potential solutions to problem a will also have to solve problem b.=20 >=20 > Currently the charter is focused on problem b. If the real goal is to = solve problem a, then this charter is not very helpful. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From adam@nostrum.com Sun Jul 18 09:07:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 342423A68FC for ; Sun, 18 Jul 2010 09:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 093VjhfQ4Jgm for ; Sun, 18 Jul 2010 09:07:03 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D74573A6809 for ; Sun, 18 Jul 2010 09:07:02 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6IG7DoS068484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Jul 2010 11:07:14 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C4326B1.7020408@nostrum.com> Date: Sun, 18 Jul 2010 11:07:13 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Cullen Jennings References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.233 is authenticated by a trusted mechanism) Cc: Bernard Aboba , dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 16:07:04 -0000 On 7/18/10 10:50, Jul 18, Cullen Jennings wrote: > On Jul 12, 2010, at 7:09 , Bernard Aboba wrote: >> One problem is the need to be able to "upgrade" an audio call in progress in order to provide for additional media, even if the call had been completed over the PSTN so that there was no SDP offer/answer negotiation between the end-points. This is the problem that Facetime solves, for example. > Irrelevant side point but, Really? Yes, really. /a From fluffy@cisco.com Sun Jul 18 09:14:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8AC83A6948 for ; Sun, 18 Jul 2010 09:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.227 X-Spam-Level: X-Spam-Status: No, score=-110.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aqt28fueZDWY for ; Sun, 18 Jul 2010 09:14:21 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 60B523A680C for ; Sun, 18 Jul 2010 09:14:21 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ/FQkyrRN+K/2dsb2JhbACfcHGkQplhgl2CSASEAIRX X-IronPort-AV: E=Sophos;i="4.55,223,1278288000"; d="scan'208";a="160181450" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 18 Jul 2010 16:14:34 +0000 Received: from sjc-vpn5-1880.cisco.com (sjc-vpn5-1880.cisco.com [10.21.95.88]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6IGEb2k014952; Sun, 18 Jul 2010 16:14:37 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Sun, 18 Jul 2010 09:14:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6AE150DC-4721-4FD6-A2B0-E7441A2ADB8D@cisco.com> References: To: Peter Musgrave X-Mailer: Apple Mail (2.1081) Cc: dispatch mailing list Subject: Re: [dispatch] ViPR Charter V4- a suggestion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 16:14:22 -0000 There's some good parts in this that perhaps we can figure out how to = use but I don't think we should make this change exactly as proposed.=20 If there are political parts of the current proposal, I'm glad to make = them more politically correct or whatever it is people want to fix them = but I'm not understanding the reasons for removing theses two = paragraphs. Is it the mention of public ENUM you are concerned about? It = would be easy to rephrase that.=20 I'm not at keen on the replacement paragraph - the big reasons why is = for people who have not been following this list or deeply involved with = RAI, it removed the whole big picture motivation of why we want this WG = or what the problem is. More details inline.=20 On Jul 13, 2010, at 5:20 , Peter Musgrave wrote: > Hi all,=20 >=20 > Here is a suggestion about changing the charter language which has = been labeled 'political' to one which is more mechanistic.=20 >=20 > How do people feel about the paragraph below in place of the first two = paras of the V4 charter (reproduced below). I think it needs more polish = - but the idea is to not raise the issues of domains and ownership.=20 >=20 >=20 > A secure call to a SIP endpoint requires a knowledge of the endpoints = URI and a shared secret.=20 I know what you meant by the above sentence but recognize that it is = very easy to endless argue about many of the words in that. What is a = secure call? Is is possible to do without a shared secret? What and when = is the knowledge required? all of this does not matter much to the work = at hand but a sentence like that would cause a very long thread on the = ietf@ietf mailing list. > Each of these requirements has been an obstacle to widespread generic = SIP calling. SIP URIs are not generally published or easily discoverable = and there is no general mechanism for setting up security credentials in = wide-spread use. Again above is arguable not true. You should ask Microsoft about the = number of people using SIP URI - it's impressive. The lack of URI is not = really the problem - if it were everyone would have a SIP URI that was = the same as their email address and we would be done.=20 > Many SIP devices are also reachable by a PSTN number through a = PSTN-SIP gateway. This allows SIP devices to both make and receive PSTN = calls. The ViPR WG will develop a peer-to-peer mechanism which allows = SIP endpoints to assert a relationship with PSTN numbers. Other SIP = endpoints in the P2P overlay can determine if their calling destinations = have an entity asserting a relationship with the target PSTN number and = then use an initial PSTN call to confirm/re-confim the relationship. The above 2 sentence seem good and I like them. And I like the term = "relationship" as a possible replacement for "responsible". This seems = like it helps fix parts of the second paragraph but does not get at any = of the motivation in the first para. It would still need to introduce = the validation concepts for the later paragraphs to make sense and I = think it would need to specify the nature of the term "relationship" = along the lines of "means an administrative domain, which is at least = one of the domains, to which a PSTN call to this phone number would be = routed." > Issues relating to whether the first PSTN call is an isolated call or = can be escalated to a direct, secure peer-to-peer SIP call will be = investigated by the working group. Subsequent calls within some = reasonable time scale can then be made directly using SIP.=20 Not sure I really knows what that means given some of validation = approaches that are possible.=20 >=20 >=20 > Peter Musgrave >=20 Cullen in my individual contributor role >=20 > Existing first two paragraphs: > There are two globally deployed address spaces for communications used > by more than a billion people daily - phone numbers and DNS rooted > address such as web servers and email addresses. The inter-domain > signaling design of SIP is primarily designed for email style = addresses > yet a large percentage of SIP deployments mostly use phone numbers for > identifying users, thus DNS lookups are not sufficient. Other = approaches > such as public ENUM are not sufficient due to lack of widespread > deployment for non-technical reasons - i.e., the involvement of > government and service provider administrative entities needing to > approve and populate the registries. Private federations have been > established to workaround the issue, however, that solution is not > scalable. The goal of this working group is to enable inter-domain > communications over the the Internet, using protocols such as SIP, > while still allowing people to use phone numbers to identify the = person > with whom they wish to communicate. >=20 > The VIPR WG will develop a peer to peer based approach to finding > domains that claim to be responsible for a given phone number > to mitigate the involvement of centralized entities to avoid some of > the issues encountered by past attempts to support SIP inter-domain > communications. Validation protocols will be developed to ensure a > reasonable likelihood that a given domain actually is responsible for > the phone number. In this context, "responsible" means an > administrative domain, which is at least one of the domains, to which > a PSTN call to this phone number would be routed. Once the domain > responsible for the phone number is found, existing protocols, such > as SIP, can be used for inter-domain communications. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@cisco.com Sun Jul 18 09:24:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11DA23A687D for ; Sun, 18 Jul 2010 09:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2QV-7Kt2Ngo for ; Sun, 18 Jul 2010 09:24:22 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 43DC53A6908 for ; Sun, 18 Jul 2010 09:24:22 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPfHQkxAaMHG/2dsb2JhbACfb3GkSZljhSUEhACEVw X-IronPort-AV: E=Sophos;i="4.55,223,1278288000"; d="scan'208";a="160182301" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 18 Jul 2010 16:24:35 +0000 Received: from sjc-vpn5-1880.cisco.com (sjc-vpn5-1880.cisco.com [10.21.95.88]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6IGOUau014348; Sun, 18 Jul 2010 16:24:31 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Sun, 18 Jul 2010 09:24:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20100705160001.9CA5A3A6890@core3.amsl.com> <7872E6AE-BDE8-4A19-B3A3-02E6C9401C7A@cisco.com> To: "Elwell, John" X-Mailer: Apple Mail (2.1081) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-jennings-dispatch-npa-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 16:24:24 -0000 Thought on number of digits and what uniqueness string? I was thinking = the min number of digits should be about 5. I did not have any = particularly good reason for that number other than it was low enough to = be easy to enter even on a single button device and large enough that = registering all of them seemed very unlikely. Obviously more than 5 = digits is allowed, that would just be the min.=20 On the uniqueness string, I imagine we could just run some tests of any = strings people propose and see how many are registered in DNS already.=20= On Jul 11, 2010, at 23:18 , Elwell, John wrote: > Cullen, >=20 > My concern with the first option was simply that a small number of = PANxxx values might already be taken for other purposes. But I agree = this could be mitigated by using a more obscure fixed string than simply = "PAN" and by having a reasonable minimal length for xxx. So probably the = first option is the best. >=20 > John >=20 >=20 >> -----Original Message----- >> From: Cullen Jennings [mailto:fluffy@cisco.com]=20 >> Sent: 09 July 2010 23:00 >> To: Elwell, John >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] I-D Action:draft-jennings-dispatch-npa-00.txt >>=20 >>=20 >> On Jul 9, 2010, at 3:09 AM, Elwell, John wrote: >>=20 >>> 1.1 Simple Single TLD. This would presumably involve=20 >> reserving PANxxx (where xxx is a digit string of a certain=20 >> length or range of lengths), and would be a problem if any=20 >> such value has already been taken. >>=20 >>=20 >> can you say a bit more about what you see as the problem - my=20 >> thinking is roughly the following. If 123 is already taken by=20 >> someone else, then it is taken - it does not matter if we use=20 >> sipforum or .net as the registry. Now if you are concerned=20 >> that pan123.net might be taken for some other use than the=20 >> purpose of the PAN draft, then we could make the string you=20 >> prepend be pan-z9hG4bK and that problem more or less goes=20 >> away. You could argue that .net domains are so cheap that=20 >> someone might just go get all of them. This seems like a=20 >> pretty unlikely attack but that is why the xxx has a minimum=20 >> length so the number they needed to get was large. Also it=20 >> may have a minimum length but it's not fixed length so people=20 >> can go to a domain with a longer string.=20 >>=20 >> I'm just not really seeing how this is all that much=20 >> different if we have the domain that looks like=20 >> 123.sipforum.net or a string that looks like 123sipforum.net=20 >> - the size of the address space is about the same either way.=20 >>=20 >> And I pretty much agree with your comments on the other the=20 >> other ones - we could probably find ways to solve some of=20 >> theses but 2,3,4 are at some level just optimization of 1 so=20 >> if there is some fundamental problem with 1, it probably=20 >> impacts all of them. =20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From peter.musgrave@magorcorp.com Sun Jul 18 09:57:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7ADF3A6890 for ; Sun, 18 Jul 2010 09:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 tagged_above=-999 required=5 tests=[AWL=0.379, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpkIsILh8C3w for ; Sun, 18 Jul 2010 09:57:20 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 15D1F3A687D for ; Sun, 18 Jul 2010 09:57:19 -0700 (PDT) Received: by qwe5 with SMTP id 5so1575808qwe.31 for ; Sun, 18 Jul 2010 09:57:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.27.210 with SMTP id j18mr3067616qac.164.1279472252998; Sun, 18 Jul 2010 09:57:32 -0700 (PDT) Received: by 10.229.20.198 with HTTP; Sun, 18 Jul 2010 09:57:32 -0700 (PDT) In-Reply-To: <6AE150DC-4721-4FD6-A2B0-E7441A2ADB8D@cisco.com> References: <6AE150DC-4721-4FD6-A2B0-E7441A2ADB8D@cisco.com> Date: Sun, 18 Jul 2010 12:57:32 -0400 Message-ID: From: Peter Musgrave To: Cullen Jennings Content-Type: multipart/alternative; boundary=00c09f89985c23d8d9048bac592d Cc: dispatch mailing list Subject: Re: [dispatch] ViPR Charter V4- a suggestion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 16:57:22 -0000 --00c09f89985c23d8d9048bac592d Content-Type: text/plain; charset=ISO-8859-1 HI Cullen, I don't have strong feelings about what I proposed - I was simply probing to see if there was middle ground which avoided the tangle the list seemed to get into over the issue of asserting ownership of a PSTN number. That notion appeared to trigger a severe immune response in some. The kernal is the part you seemed to find ok (the notion of asserting a relationship with a PSTN number) - so maybe we can keep that. I agree the preamble on publishing SIP URIs and secure calls is a quagmire and I am happy to avoid it. I think the main issue in the V4 first two paragraphs is the sentence: "The VIPR WG will develop a peer to peer based approach to finding domains that claim to be responsible for a given phone number to mitigate the involvement of centralized entities to avoid some of the issues encountered by past attempts to support SIP inter-domain communications." This notion of 'responsibility' appears (to me) to have been the source of angst. Perhaps it would suffice to use the 'assert a relationship' notion here. Re-reading the rest I don't find anything else I object to (but then I was ok with the original text anyway). Cheers, Peter Musgrave On Sun, Jul 18, 2010 at 12:14 PM, Cullen Jennings wrote: > > There's some good parts in this that perhaps we can figure out how to use > but I don't think we should make this change exactly as proposed. > > If there are political parts of the current proposal, I'm glad to make > them more politically correct or whatever it is people want to fix them but > I'm not understanding the reasons for removing theses two paragraphs. Is it > the mention of public ENUM you are concerned about? It would be easy to > rephrase that. > > I'm not at keen on the replacement paragraph - the big reasons why is for > people who have not been following this list or deeply involved with RAI, it > removed the whole big picture motivation of why we want this WG or what the > problem is. More details inline. > > > On Jul 13, 2010, at 5:20 , Peter Musgrave wrote: > > > Hi all, > > > > Here is a suggestion about changing the charter language which has been > labeled 'political' to one which is more mechanistic. > > > > How do people feel about the paragraph below in place of the first two > paras of the V4 charter (reproduced below). I think it needs more polish - > but the idea is to not raise the issues of domains and ownership. > > > > > > A secure call to a SIP endpoint requires a knowledge of the endpoints URI > and a shared secret. > > I know what you meant by the above sentence but recognize that it is very > easy to endless argue about many of the words in that. What is a secure > call? Is is possible to do without a shared secret? What and when is the > knowledge required? all of this does not matter much to the work at hand but > a sentence like that would cause a very long thread on the ietf@ietfmailing list. > > > Each of these requirements has been an obstacle to widespread generic SIP > calling. SIP URIs are not generally published or easily discoverable and > there is no general mechanism for setting up security credentials in > wide-spread use. > > Again above is arguable not true. You should ask Microsoft about the > number of people using SIP URI - it's impressive. The lack of URI is not > really the problem - if it were everyone would have a SIP URI that was the > same as their email address and we would be done. > > > Many SIP devices are also reachable by a PSTN number through a PSTN-SIP > gateway. This allows SIP devices to both make and receive PSTN calls. The > ViPR WG will develop a peer-to-peer mechanism which allows SIP endpoints to > assert a relationship with PSTN numbers. Other SIP endpoints in the P2P > overlay can determine if their calling destinations have an entity asserting > a relationship with the target PSTN number and then use an initial PSTN call > to confirm/re-confim the relationship. > > The above 2 sentence seem good and I like them. And I like the term > "relationship" as a possible replacement for "responsible". This seems like > it helps fix parts of the second paragraph but does not get at any of the > motivation in the first para. It would still need to introduce the > validation concepts for the later paragraphs to make sense and I think it > would need to specify the nature of the term "relationship" along the lines > of "means an administrative domain, which is at least one of the domains, to > which a PSTN call to this phone number would be routed." > > > Issues relating to whether the first PSTN call is an isolated call or can > be escalated to a direct, secure peer-to-peer SIP call will be investigated > by the working group. Subsequent calls within some reasonable time scale can > then be made directly using SIP. > > Not sure I really knows what that means given some of validation approaches > that are possible. > > > > > > > Peter Musgrave > > > > Cullen in my individual contributor role > > > > > Existing first two paragraphs: > > There are two globally deployed address spaces for communications used > > by more than a billion people daily - phone numbers and DNS rooted > > address such as web servers and email addresses. The inter-domain > > signaling design of SIP is primarily designed for email style addresses > > yet a large percentage of SIP deployments mostly use phone numbers for > > identifying users, thus DNS lookups are not sufficient. Other approaches > > such as public ENUM are not sufficient due to lack of widespread > > deployment for non-technical reasons - i.e., the involvement of > > government and service provider administrative entities needing to > > approve and populate the registries. Private federations have been > > established to workaround the issue, however, that solution is not > > scalable. The goal of this working group is to enable inter-domain > > communications over the the Internet, using protocols such as SIP, > > while still allowing people to use phone numbers to identify the person > > with whom they wish to communicate. > > > > The VIPR WG will develop a peer to peer based approach to finding > > domains that claim to be responsible for a given phone number > > to mitigate the involvement of centralized entities to avoid some of > > the issues encountered by past attempts to support SIP inter-domain > > communications. Validation protocols will be developed to ensure a > > reasonable likelihood that a given domain actually is responsible for > > the phone number. In this context, "responsible" means an > > administrative domain, which is at least one of the domains, to which > > a PSTN call to this phone number would be routed. Once the domain > > responsible for the phone number is found, existing protocols, such > > as SIP, can be used for inter-domain communications. > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > --00c09f89985c23d8d9048bac592d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable HI Cullen,=A0

I don't have strong feelings about wha= t I proposed - I was simply probing to see if there was middle ground which= avoided the tangle the list seemed to get into over the issue of asserting= ownership of a PSTN number. That notion appeared to trigger a severe immun= e response in some. The kernal is the part you seemed to find ok (the notio= n of asserting a relationship with a PSTN number) - so maybe we can keep th= at.=A0

I agree the preamble on publishing SIP URIs and secure = calls is a quagmire and I am happy to avoid it.=A0

I think the main issue in the V4 first two paragraphs is the sentence:
"The VIP= R WG will develop a peer to peer based approach to finding
domains that claim to be responsible for a given phone number
to mitigate the involvement of centralized entities to avoid some of
the issues encountered by past attempts to support SIP inter-domain
communications."
This notion of 'responsibility&#= 39; appears (to me) to have been the source of angst. Perhaps it would suff= ice to use the 'assert a relationship' notion here.=A0

Re-reading the rest I don't find anything else I object = to (but then I was ok with the original text anyway).=A0

Cheers,=A0

Peter Musgrave




On Sun, Jul 18, 2010= at 12:14 PM, Cullen Jennings <fluffy@cisco.com> wrote:

There's some good parts in this that perhaps we can figure out how to u= se but I don't think we should make this change exactly as proposed.
If there are political parts of the current proposal, =A0I'm glad to ma= ke them more politically correct or whatever it is people want to fix them = but I'm not understanding the reasons for removing theses two paragraph= s. Is it the mention of public ENUM you are concerned about? It would be ea= sy to rephrase that.

I'm not at keen on the replacement paragraph - the big reasons why is f= or people who have not been following this list or deeply involved with RAI= , it removed the whole big picture motivation of why we want this WG or wha= t the problem is. More details inline.


On Jul 13, 2010, at 5:20 , Peter Musgrave wrote:

> Hi all,
>
> Here is a suggestion about changing the charter language which has bee= n labeled 'political' to one which is more mechanistic.
>
> How do people feel about the paragraph below in place of the first two= paras of the V4 charter (reproduced below). I think it needs more polish -= but the idea is to not raise the issues of domains and ownership.
>
>
> A secure call to a SIP endpoint requires a knowledge of the endpoints = URI and a shared secret.

I know what you meant by the above sentence but recognize that it is = very easy to endless argue about many of the words in that. What is a secur= e call? Is is possible to do without a shared secret? What and when is the = knowledge required? all of this does not matter much to the work at hand bu= t a sentence like that would cause a very long thread on the ietf@ietf mail= ing list.

> Each of these requirements has been an obstacle to widespread generic = SIP calling. SIP URIs are not generally published or easily discoverable an= d there is no general mechanism for setting up security credentials in wide= -spread use.

Again above =A0is arguable not true. You should ask Microsoft about t= he number of people using SIP URI - it's impressive. The lack of URI is= not really the problem - if it were everyone would have a SIP URI that was= the same as their email address and we would be done.

> Many SIP devices are also reachable by a PSTN number through a PSTN-SI= P gateway. This allows SIP devices to both make and receive PSTN calls. The= ViPR WG will develop a peer-to-peer mechanism which allows SIP endpoints t= o assert a relationship with PSTN numbers. Other SIP endpoints in the P2P o= verlay can determine if their calling destinations have an entity asserting= a relationship with the target PSTN number and then use an initial PSTN ca= ll to confirm/re-confim the relationship.

The above 2 sentence seem good and I like them. And I like the term &= quot;relationship" as a possible replacement for "responsible&quo= t;. =A0This seems like it helps fix parts of the second paragraph but does = not get at any of the motivation in the first para. It would still need to = introduce the validation concepts for the later paragraphs to make sense an= d I think it would need to specify the nature of the term "relationshi= p" along the lines of "means an administrative domain, which is a= t least one of the domains, to which a PSTN call to this phone number would= be routed."

> Issues relating to whether the first PSTN call is an isolated call or = can be escalated to a direct, secure peer-to-peer SIP call will be investig= ated by the working group. Subsequent calls within some reasonable time sca= le can then be made directly using SIP.

Not sure I really knows what that means given some of validation appr= oaches that are possible.

>
>
> Peter Musgrave
>

Cullen in my individual contributor role

>
> Existing first two paragraphs:
> There are two globally deployed address spaces for communications used=
> by more than a billion people daily - phone numbers and DNS rooted
> address such as web servers and email addresses. The inter-domain
> signaling design of SIP is primarily designed for email style addresse= s
> yet a large percentage of SIP deployments mostly use phone numbers for=
> identifying users, thus DNS lookups are not sufficient. Other approach= es
> such as public ENUM are not sufficient due to lack of widespread
> deployment for non-technical reasons - i.e., the involvement of
> government and service provider administrative entities needing to
> approve and populate the registries. =A0Private federations have been<= br> > established to workaround the issue, however, that solution is not
> scalable. The goal of this working group is to enable inter-domain
> communications over the the Internet, using protocols such as SIP,
> while still allowing people to use phone numbers to identify the perso= n
> with whom they wish to communicate.
>
> The VIPR WG will develop a peer to peer based approach to finding
> domains that claim to be responsible for a given phone number
> to mitigate the involvement of centralized entities to avoid some of > the issues encountered by past attempts to support SIP inter-domain > communications. Validation protocols will be developed to ensure a
> reasonable likelihood that a given domain actually is responsible for<= br> > the phone number. In this context, "responsible" means an > administrative domain, which is at least one of the domains, to which<= br> > a PSTN call to this phone number would be routed. Once the domain
> responsible for the phone number is found, existing protocols, such > as SIP, can be used for inter-domain communications.
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch



--00c09f89985c23d8d9048bac592d-- From tme@americafree.tv Sun Jul 18 10:57:45 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BEE83A68F3 for ; Sun, 18 Jul 2010 10:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.728 X-Spam-Level: X-Spam-Status: No, score=-100.728 tagged_above=-999 required=5 tests=[AWL=-1.543, BAYES_40=-0.185, J_BACKHAIR_31=1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcaAqIYyQRnP for ; Sun, 18 Jul 2010 10:57:43 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 970AA3A6768 for ; Sun, 18 Jul 2010 10:57:43 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id D4CE38002076; Sun, 18 Jul 2010 13:57:56 -0400 (EDT) Message-Id: <3ED874FC-A488-4EB6-88C0-C702067710F8@americafree.tv> From: Marshall Eubanks To: stephen botzko In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 18 Jul 2010 13:57:56 -0400 References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C333D2@xmb-sjc-221.amer.cisco.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list , "Botzko, Stephen" Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 17:57:45 -0000 On Jul 8, 2010, at 10:20 AM, stephen botzko wrote: > Hi Peter > > Thanks for the feedback. > > I agree that interop with standard video SIP gear will clearly be a =20= > requirement. Since people are finding the drafts unclear on that =20 > point, we should clarify them. > > As far as Marshall's comment on H.323 goes, if the telepresence =20 > systems interoperate with normal SIP video endpoints, then they will =20= > also interoperate with normal SIP<->H.323 gateways. (=46rom a discussion with Bob Dixon on the Megaco list.) I must say I am not convinced - if a crucial part of Telepresence =20 interoperability is the conveying of meta-data in a recognized fashion =20= (i.e., what the room layout is, how people are placed in the room, =20 etc., etc.), and that is not part of the current standards, then how =20 in the world will that information get across the normal SIP<->H.323 =20 gateways to a H.323 telepresence unit ? Regards Marshall > > Stephen Botzko > > On Thu, Jul 8, 2010 at 6:45 AM, Peter Musgrave = > wrote: > Hi Allyn/Stephen, > > I read through these. I think they do a good job of establishing =20 > scope and raising issues and as a bonus they are very easy to read. > > Is there a need to talk about interop with standard video SIP gear? =20= > If I use a TP suite to call a desktop SIP client or a 1080p video =20 > conferencing terminal is there anything about how that should behave =20= > that is worth defining under this work or is that viewed as out of =20 > scope? > > As for draft-romanow-dispatch-telepresence-use-cases-00.txt > > 1. (nit) > "This draft =85" paragraph has a number of A's sprinkled in (typos?) > > 3. "We describe=85display stream" I assume display stream is a stream =20= > from a document camera (as distinct from video stream being from a =20 > participant camera?). This term does not match the words used in the =20= > previous paragraph. > > Thanks, > > Peter Musgrave > > > On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings =20 > wrote: > > Theses look great - I hope people on the list take some time to read =20= > them. > > On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote: > > > Hi Cullen, > > > > We just put out a problem statement draft - > > = http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-prob-stat > > ement-00. The document is not complete, but we feel it is a solid > > beginning. It does address the example you mention. The use case =20= > doc > > also describes this case in some detail. > > = http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases > > -00 > > > > > > Do you not feel that the problem statement draft can serve as a good > > basis for discussion of problems? > > > > Thanks, > > Allyn > > > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] =20= > On > > Behalf Of Cullen Jennings (fluffy) > > Sent: Wednesday, July 07, 2010 9:41 AM > > To: DISPATCH list > > Subject: Re: [dispatch] Charter for Telepresence multi-streams - > > thirdversion > > > > > > I'm wondering if we could get a thread going about what are some =20 > of the > > specific problems we need to solve then dispatch theses problems =20= > to > > appropriate WGs. > > > > For example one problem is when a session involves two video =20 > session on > > multiple screens how does one signal which stream is displayed on =20= > the > > right and left screen. > > > > I think having a list of specific problems would help get this =20 > moving > > faster. > > > > Cullen > > > > > > On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote: > > > >> Folks, > >> This makes the change discussed replacing the text in the third > > paragraph under the Charter section with the text suggested on the =20= > list. > >> It also changes title from "... Description of Work" to =20 > "...Charter" > >> > >> There weren't any further changes suggested. > >> > >> Thanks, > >> Allyn > >> > >> > >> > >> > >> Multi-streams for Telepresence Charter > >> > >> > >> > >> Background > >> One branch of video conferencing has evolved that is focused on > > immersive "being there" experience. Referred to in various ways =20 > such as > > virtual conferencing, telepresence or media spaces, early systems =20= > were > > mainly research projects or business systems with limited =20 > deployments. > > In recent years telepresence systems have seen considerable market > > success. Following the model of early systems, the first wave of > > commercial systems have been typically located in specially designed > > single-purpose rooms with multiple relatively large displays =20 > permitting > > life size image reproduction, multiple cameras, encoders, decoders =20= > and > > microphones. These systems have several important characteristics =20= > that > > are different from more traditional video conferencing systems. > >> > >> The first difference concerns controlling the visual viewpoint in > > order to improve participant nonverbal communication. These systems > > preserve essential group meeting characteristics such as eye =20 > contact, > > group gestures, seating order and spatial audio by carefully > > orchestrating the miking and camera angles at each of the sites . =20= > This > > is distinct from the more traditional approach where the geometric > > relationship between media streams is not used to preserve inter-=20 > stream > > communication aspects such as eye contact and group dynamics. > >> > >> A second difference is manipulation of the environment to improve > > immersion. With telepresence systems, cinematographic aspects of =20= > the > > local environment reproduction are carefully planned including =20 > color, > > table shape, seating and lighting so that when combined with large =20= > high > > quality displays, a strong sense of a "trompe l'oeil" or "being =20 > there" > > immersive experience is created. Typical video conference systems =20= > do > > not include these considerations. > >> > >> As telepresence video systems have become successful in the market, > > manufacturers have started exploring delivery of the nonverbal > > communication and immersive values of telepresence via smaller, less > > expensive and more flexible video conferencing systems for a =20 > variety of > > venues, such as individual offices, homes and kiosks. These are also > > telepresence systems, since the audio and video quality is high =20 > enough > > to allow clear image reproduction for nonverbal communication, =20 > they are > > able to send and receive multiple media streams, and large =20 > coordinated > > multi image displays are available for immersive installations. =20= > As the > > industry develops, the line between telepresence and video =20 > conferencing > > may become blurred as nonverbal communication and immersive > > installations become broadly available. > >> > >> Problem > >> Although telepresence systems are based on open standards such as =20= > RTP, > > SIP, H.264, H.323 suite, they cannot easily interoperate with each =20= > other > > without operator assistance and expensive additional equipment that > > translates from one vendor to another. It would be like having to =20= > make > > sure all parties are on the same equipment (and network) when =20 > making a > > telephone call. A major factor in the inability of Telepresence =20 > systems > > to work with each other is that there is no standard description =20 > of the > > multiple streams that comprise the media flows. > >> > >> For example, in a multiple screen conference, the video and audio > > streams sent from remote participants must be understood by =20 > receivers so > > that they can be presented in a coherent and life-like manner. This > > includes the ability to present the remote participants at their =20 > true > > size for their apparent distance, while maintaining correct eye =20 > contact, > > gesticular cues, and simultaneously providing a spatial audio sound > > stage consistent with the video presentation. The receiving =20 > device that > > decides how to display the incoming information needs to =20 > understand a > > number of variables such as the spatial position of the speaker, the > > field of view of the cameras, the camera zoom, which media stream is > > related to each of the displays, etc. > >> > >> Charter > >> The Telepresence Multi-Streams work item in DISPATCH is chartered =20= > to > > define and specify for SIP-based systems the content of media > > multi-stream messages and the way these will be transported. > >> > >> This work will provide a standard for the exchange of media =20 > semantic > > information that will foster interoperable end stations and =20 > conference > > bridges. It will specify variables that describe the semantics of =20= > the > > media streams and the recommended behavior to achieve =20 > interoperability. > >> > >> > >> This requires considering current widely deployed use cases, as =20 > well > > as cases that are expected to be implemented using the protocol > > framework produced by this work item. The methodology for =20 > describing > > the variables must allow extensibility of the variables, since > > telepresence is still a young technology and may have use cases =20 > that are > > not currently considered." > >> > >> > >> The work item will identify use cases, define requirements, and =20 > define > > a method for describing and transporting information about multiple > > media streams, including a specification of variables required to > > support the use cases. This work item will consider the reuse of > > existing IETF protocols and produce an architecture/protocol =20 > framework > > document describing the protocols required to be implemented to =20 > support > > this functionality. The document will identify any enhancements > > required to existing protocols as well as describing new =20 > protocol(s) for > > interoperable multi-streams negotiation that may be required. > >> > >> Relevant work to be drawn upon has been done in XCON, MMUSIC, =20 > AVT, and > > FECframe. > >> > >> > >> Scope > >> The scope includes both systems that provide a fully immersive > > experience, and systems that interwork with them and therefore =20 > need to > > understand the same multiple stream semantics. > >> > >> > >> The focus of this work is on audio and video multiple streams. =20 > Other > > media types may be considered, however development of =20 > methodologies for > > them is not within the scope of this work. > >> > >> Interoperation with standards compliant systems is required, such =20= > as > > SIP-based video conferencing systems. However, backwards =20 > compatibility > > with existing non-standards compliant telepresence systems is not > > required. > >> > >> > >> > >> The group will produce > >> - Requirements and use cases > >> > >> - Architectural Framework describing the protocols required to be > > implemented to support this functionality and identifying existing > > protocol enhancements and new protocol functionality required > >> > >> - Specification of a new protocol to support telepresence > > multi-streams [if required] > >> > >> Goals and Milestones > >> Nov 2010 > >> > >> Use Cases and Requirements to IESG as Informational RFC > >> Nov 2010 > >> March 2011 > >> Problem Statement to IESG as Informational RFC > >> Architecture to IESG as Informational RFC > >> March 2011 > >> Revise Charter [IF new protocol is not required] > >> Nov 2011 > >> Submit protocol draft to IESG as Proposed Standard RFC > >> > >> _______________________________________________ > >> dispatch mailing list > >> dispatch@ietf.org > >> https://www.ietf.org/mailman/listinfo/dispatch > > > > > > Cullen Jennings > > For corporate legal information go to: > > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > _______________________________________________ > 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 richard@shockey.us Sun Jul 18 11:11:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 450093A6925 for ; Sun, 18 Jul 2010 11:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.69 X-Spam-Level: X-Spam-Status: No, score=-0.69 tagged_above=-999 required=5 tests=[AWL=-0.505, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J99-FXc2zIlY for ; Sun, 18 Jul 2010 11:11:21 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 87B303A693F for ; Sun, 18 Jul 2010 11:11:21 -0700 (PDT) Received: (qmail 14421 invoked by uid 0); 18 Jul 2010 17:12:15 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 18 Jul 2010 17:12:14 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=MxlZZ+LA93S14szznzPFjmCpldBPk3Moyv4IPeySvlL1S/hjbS/7Tdx2hDHpCLNs3IgqTL/74dqsYfnQN7KBnEF0DM6J90DJijS178Ckxa6+cgqWcNpRndLhDybmvfDG; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OaYKs-00054Y-Lb; Sun, 18 Jul 2010 12:11:35 -0600 From: "Richard Shockey" To: "'Adam Roach'" , "'Cullen Jennings'" References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <4C4326B1.7020408@nostrum.com> In-Reply-To: <4C4326B1.7020408@nostrum.com> Date: Sun, 18 Jul 2010 14:11:32 -0400 Message-ID: <000001cb26a4$a81e4840$f85ad8c0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acsmk0zBKxXnrSQLSG2bqd2KJq9HNQADgfyg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'Bernard Aboba' , dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 18:11:23 -0000 Yes, absolutely positively unquestionably. The FaceTime mechanism is rather clever and is certainly one way to solve the real problem of the E.164 trust binding in session (re)establishment. If you can make a PSTN call .. its works. From the user experience perspective (Apples obsession) its nearly flawless. Apple did a very nice job. If Steve and company finally decide to publish what they have done they will have a lot of friends. For my 547th rant. People want to use phone numbers. SIP addressing, for better or worse, is now and forever will be bound in large measure to phone numbers and phone numbers and the PSTN are controlled by service providers. I wish RAI would take a longer look at E164 integration both from the prospective of the end user as ViPR does but also the needs of the service providers. The common goal here is accelerating the deployment of SIP. Both are logical approaches, but it doesn't help when a simple proposal such as E2MD to extend ENUM databases in public and private networks for simple metadata runs into a stone wall of resistance. Its why there is a strong political odor here. -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Adam Roach Sent: Sunday, July 18, 2010 12:07 PM To: Cullen Jennings Cc: Bernard Aboba; dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 On 7/18/10 10:50, Jul 18, Cullen Jennings wrote: > On Jul 12, 2010, at 7:09 , Bernard Aboba wrote: >> One problem is the need to be able to "upgrade" an audio call in progress in order to provide for additional media, even if the call had been completed over the PSTN so that there was no SDP offer/answer negotiation between the end-points. This is the problem that Facetime solves, for example. > Irrelevant side point but, Really? Yes, really. /a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From stephen.botzko@gmail.com Sun Jul 18 11:12:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 288A03A6925 for ; Sun, 18 Jul 2010 11:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=-0.994, BAYES_05=-1.11, HTML_MESSAGE=0.001, J_BACKHAIR_31=1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4lIWCM1pCXj for ; Sun, 18 Jul 2010 11:11:55 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id A117A3A693B for ; Sun, 18 Jul 2010 11:11:52 -0700 (PDT) Received: by wyb40 with SMTP id 40so3975088wyb.31 for ; Sun, 18 Jul 2010 11:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=QCuJyujF1wxHxP3BfgJEAh3J6J7qZIqPwuuJRv/6l+4=; b=ksZ6y8kyQ+UByDx1fFNUYpu4bLHSfZfhyg4OwuRdZgYE2NhZuPIwCF2uc8YVv/O/JC Gm0K67cJkIlJZGSE9Q0zQxuoSAIWOg3h2LWppqf3Lhv8Z2cWvmVSrLOGnD1P63GxzRRR 3LkAqiIGtlb/10MTvhDLFoqyGLo6AY38/YoA0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=fmY6ThWAGnNGNziLDd12kUMdexuqevM4WSc50z+RsE92Q+V3CjOzhsZd6hvUX/A+2k JVpcH4vW2mWxaIaS9iFwif9KS1tLehbqLaS0zDt2loiMN6H52fqMmOWEJ3m2djmryvxv EJqvKccqIci661Gg4Dt/E0Xx8XNbLRaWvg7xE= MIME-Version: 1.0 Received: by 10.227.136.2 with SMTP id p2mr3090000wbt.215.1279476720716; Sun, 18 Jul 2010 11:12:00 -0700 (PDT) Received: by 10.216.80.81 with HTTP; Sun, 18 Jul 2010 11:12:00 -0700 (PDT) In-Reply-To: <3ED874FC-A488-4EB6-88C0-C702067710F8@americafree.tv> References: <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C32C1C@xmb-sjc-221.amer.cisco.com> <9AC2C4348FD86B4BB1F8FA9C5E3A5EDC01C333D2@xmb-sjc-221.amer.cisco.com> <3ED874FC-A488-4EB6-88C0-C702067710F8@americafree.tv> Date: Sun, 18 Jul 2010 14:12:00 -0400 Message-ID: From: stephen botzko To: Marshall Eubanks Content-Type: multipart/alternative; boundary=0016e648d3d66fcb4f048bad6375 Cc: DISPATCH list Subject: Re: [dispatch] Charter for Telepresence multi-streams - thirdversion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 18:12:05 -0000 --0016e648d3d66fcb4f048bad6375 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Marshall When the IETF and the ITU-T *both* standardize multistreaming telepresence, then we can meaningfully talk about how H.323<->SIP gateways perserve the information. I think the interoperability burden for multiscreen will be on the SDO that gets there last. In the meantime, normal SIP<->H.323 gateways (single screen) will have to do. And I think it is all one can commit to today. Stephen Botzko On Sun, Jul 18, 2010 at 1:57 PM, Marshall Eubanks wrote= : > > On Jul 8, 2010, at 10:20 AM, stephen botzko wrote: > > Hi Peter >> >> Thanks for the feedback. >> >> I agree that interop with standard video SIP gear will clearly be a >> requirement. Since people are finding the drafts unclear on that point,= we >> should clarify them. >> >> As far as Marshall's comment on H.323 goes, if the telepresence systems >> interoperate with normal SIP video endpoints, then they will also >> interoperate with normal SIP<->H.323 gateways. >> > > (From a discussion with Bob Dixon on the Megaco list.) > > I must say I am not convinced - if a crucial part of Telepresence > interoperability is the conveying of meta-data in a recognized fashion > (i.e., what the room layout is, how people are placed in the room, etc., > etc.), and that is not part of the current standards, then how in the wor= ld > will that information get across the normal SIP<->H.323 gateways to a H.3= 23 > telepresence unit ? > > Regards > Marshall > > > > > >> Stephen Botzko >> >> On Thu, Jul 8, 2010 at 6:45 AM, Peter Musgrave < >> peter.musgrave@magorcorp.com> wrote: >> Hi Allyn/Stephen, >> >> I read through these. I think they do a good job of establishing scope a= nd >> raising issues and as a bonus they are very easy to read. >> >> Is there a need to talk about interop with standard video SIP gear? If I >> use a TP suite to call a desktop SIP client or a 1080p video conferencin= g >> terminal is there anything about how that should behave that is worth >> defining under this work or is that viewed as out of scope? >> >> As for draft-romanow-dispatch-telepresence-use-cases-00.txt >> >> 1. (nit) >> "This draft =85" paragraph has a number of A's sprinkled in (typos?) >> >> 3. "We describe=85display stream" I assume display stream is a stream fr= om a >> document camera (as distinct from video stream being from a participant >> camera?). This term does not match the words used in the previous paragr= aph. >> >> Thanks, >> >> Peter Musgrave >> >> >> On Thu, Jul 8, 2010 at 2:46 AM, Cullen Jennings wrote= : >> >> Theses look great - I hope people on the list take some time to read the= m. >> >> On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote: >> >> > Hi Cullen, >> > >> > We just put out a problem statement draft - >> > >> http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-prob-stat >> > ement-00. The document is not complete, but we feel it is a solid >> > beginning. It does address the example you mention. The use case doc >> > also describes this case in some detail. >> > >> http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-use-cases >> > -00 >> > >> > >> > Do you not feel that the problem statement draft can serve as a good >> > basis for discussion of problems? >> > >> > Thanks, >> > Allyn >> > >> > >> > -----Original Message----- >> > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> > Behalf Of Cullen Jennings (fluffy) >> > Sent: Wednesday, July 07, 2010 9:41 AM >> > To: DISPATCH list >> > Subject: Re: [dispatch] Charter for Telepresence multi-streams - >> > thirdversion >> > >> > >> > I'm wondering if we could get a thread going about what are some of th= e >> > specific problems we need to solve then dispatch theses problems to >> > appropriate WGs. >> > >> > For example one problem is when a session involves two video session o= n >> > multiple screens how does one signal which stream is displayed on the >> > right and left screen. >> > >> > I think having a list of specific problems would help get this moving >> > faster. >> > >> > Cullen >> > >> > >> > On Jul 4, 2010, at 10:14 PM, Allyn Romanow (allyn) wrote: >> > >> >> Folks, >> >> This makes the change discussed replacing the text in the third >> > paragraph under the Charter section with the text suggested on the lis= t. >> >> It also changes title from "... Description of Work" to "...Charter" >> >> >> >> There weren't any further changes suggested. >> >> >> >> Thanks, >> >> Allyn >> >> >> >> >> >> >> >> >> >> Multi-streams for Telepresence Charter >> >> >> >> >> >> >> >> Background >> >> One branch of video conferencing has evolved that is focused on >> > immersive "being there" experience. Referred to in various ways such = as >> > virtual conferencing, telepresence or media spaces, early systems were >> > mainly research projects or business systems with limited deployments. >> > In recent years telepresence systems have seen considerable market >> > success. Following the model of early systems, the first wave of >> > commercial systems have been typically located in specially designed >> > single-purpose rooms with multiple relatively large displays permittin= g >> > life size image reproduction, multiple cameras, encoders, decoders and >> > microphones. These systems have several important characteristics tha= t >> > are different from more traditional video conferencing systems. >> >> >> >> The first difference concerns controlling the visual viewpoint in >> > order to improve participant nonverbal communication. These systems >> > preserve essential group meeting characteristics such as eye contact, >> > group gestures, seating order and spatial audio by carefully >> > orchestrating the miking and camera angles at each of the sites . This >> > is distinct from the more traditional approach where the geometric >> > relationship between media streams is not used to preserve inter-strea= m >> > communication aspects such as eye contact and group dynamics. >> >> >> >> A second difference is manipulation of the environment to improve >> > immersion. With telepresence systems, cinematographic aspects of the >> > local environment reproduction are carefully planned including color, >> > table shape, seating and lighting so that when combined with large hig= h >> > quality displays, a strong sense of a "trompe l'oeil" or "being there" >> > immersive experience is created. Typical video conference systems do >> > not include these considerations. >> >> >> >> As telepresence video systems have become successful in the market, >> > manufacturers have started exploring delivery of the nonverbal >> > communication and immersive values of telepresence via smaller, less >> > expensive and more flexible video conferencing systems for a variety o= f >> > venues, such as individual offices, homes and kiosks. These are also >> > telepresence systems, since the audio and video quality is high enough >> > to allow clear image reproduction for nonverbal communication, they ar= e >> > able to send and receive multiple media streams, and large coordinated >> > multi image displays are available for immersive installations. As t= he >> > industry develops, the line between telepresence and video conferencin= g >> > may become blurred as nonverbal communication and immersive >> > installations become broadly available. >> >> >> >> Problem >> >> Although telepresence systems are based on open standards such as RTP= , >> > SIP, H.264, H.323 suite, they cannot easily interoperate with each oth= er >> > without operator assistance and expensive additional equipment that >> > translates from one vendor to another. It would be like having to make >> > sure all parties are on the same equipment (and network) when making a >> > telephone call. A major factor in the inability of Telepresence syste= ms >> > to work with each other is that there is no standard description of th= e >> > multiple streams that comprise the media flows. >> >> >> >> For example, in a multiple screen conference, the video and audio >> > streams sent from remote participants must be understood by receivers = so >> > that they can be presented in a coherent and life-like manner. This >> > includes the ability to present the remote participants at their true >> > size for their apparent distance, while maintaining correct eye contac= t, >> > gesticular cues, and simultaneously providing a spatial audio sound >> > stage consistent with the video presentation. The receiving device th= at >> > decides how to display the incoming information needs to understand a >> > number of variables such as the spatial position of the speaker, the >> > field of view of the cameras, the camera zoom, which media stream is >> > related to each of the displays, etc. >> >> >> >> Charter >> >> The Telepresence Multi-Streams work item in DISPATCH is chartered to >> > define and specify for SIP-based systems the content of media >> > multi-stream messages and the way these will be transported. >> >> >> >> This work will provide a standard for the exchange of media semantic >> > information that will foster interoperable end stations and conference >> > bridges. It will specify variables that describe the semantics of the >> > media streams and the recommended behavior to achieve interoperability= . >> >> >> >> >> >> This requires considering current widely deployed use cases, as well >> > as cases that are expected to be implemented using the protocol >> > framework produced by this work item. The methodology for describing >> > the variables must allow extensibility of the variables, since >> > telepresence is still a young technology and may have use cases that a= re >> > not currently considered." >> >> >> >> >> >> The work item will identify use cases, define requirements, and defin= e >> > a method for describing and transporting information about multiple >> > media streams, including a specification of variables required to >> > support the use cases. This work item will consider the reuse of >> > existing IETF protocols and produce an architecture/protocol framework >> > document describing the protocols required to be implemented to suppor= t >> > this functionality. The document will identify any enhancements >> > required to existing protocols as well as describing new protocol(s) f= or >> > interoperable multi-streams negotiation that may be required. >> >> >> >> Relevant work to be drawn upon has been done in XCON, MMUSIC, AVT, an= d >> > FECframe. >> >> >> >> >> >> Scope >> >> The scope includes both systems that provide a fully immersive >> > experience, and systems that interwork with them and therefore need to >> > understand the same multiple stream semantics. >> >> >> >> >> >> The focus of this work is on audio and video multiple streams. Other >> > media types may be considered, however development of methodologies fo= r >> > them is not within the scope of this work. >> >> >> >> Interoperation with standards compliant systems is required, such as >> > SIP-based video conferencing systems. However, backwards compatibilit= y >> > with existing non-standards compliant telepresence systems is not >> > required. >> >> >> >> >> >> >> >> The group will produce >> >> - Requirements and use cases >> >> >> >> - Architectural Framework describing the protocols required to be >> > implemented to support this functionality and identifying existing >> > protocol enhancements and new protocol functionality required >> >> >> >> - Specification of a new protocol to support telepresence >> > multi-streams [if required] >> >> >> >> Goals and Milestones >> >> Nov 2010 >> >> >> >> Use Cases and Requirements to IESG as Informational RFC >> >> Nov 2010 >> >> March 2011 >> >> Problem Statement to IESG as Informational RFC >> >> Architecture to IESG as Informational RFC >> >> March 2011 >> >> Revise Charter [IF new protocol is not required] >> >> Nov 2011 >> >> Submit protocol draft to IESG as Proposed Standard RFC >> >> >> >> _______________________________________________ >> >> dispatch mailing list >> >> dispatch@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dispatch >> > >> > >> > Cullen Jennings >> > For corporate legal information go to: >> > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> > >> > >> > >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> >> >> Cullen Jennings >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> >> >> _______________________________________________ >> 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 >> > > --0016e648d3d66fcb4f048bad6375 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Marshall
=A0
When=A0the IETF and the ITU-T both standardize multistreaming t= elepresence, then we can meaningfully talk about how H.323<->SIP gate= ways=A0perserve the information. I think the interoperability burden for mu= ltiscreen will be on the SDO that gets there last.
=A0
In the meantime, normal SIP<->H.323 gateways (single screen) wil= l have to do.=A0 And I think it is all one can commit to today.
=A0
Stephen Botzko

On Sun, Jul 18, 2010 at 1:57 PM, Marshall Eubank= s <tme@americafr= ee.tv> wrote:

On Jul 8, 2010, at 10:20 AM, stephen botzko wrote:
Hi Peter

Thanks for the f= eedback.

I agree that interop with standard video SIP gear will clea= rly be a requirement. =A0Since people are finding the drafts unclear on tha= t point, we should clarify them.

As far as Marshall's comment on H.323 goes, if the telepresence sys= tems interoperate with normal SIP video endpoints, then they will also inte= roperate with normal SIP<->H.323 gateways.

(From a discussion with Bob Dixon on the Megaco list.)

I must say I = am not convinced - if a crucial part of Telepresence interoperability is th= e conveying of meta-data in a recognized fashion (i.e., what the room layou= t is, how people are placed in the room, etc., etc.), and that is not part = of the current standards, then how in the world will that information get a= cross the normal SIP<->H.323 gateways to a H.323 telepresence unit ?<= br>
Regards
Marshall=20





Stephen Botzko

On Thu= , Jul 8, 2010 at 6:45 AM, Peter Musgrave <peter.musgrave@magorcorp.com> wr= ote:
Hi Allyn/Stephen,

I read through these. I think they do a good job o= f establishing scope and raising issues and as a bonus they are very easy t= o read.

Is there a need to talk about interop with standard video SI= P gear? If I use a TP suite to call a desktop SIP client or a 1080p video c= onferencing terminal is there anything about how that should behave that is= worth defining under this work or is that viewed as out of scope?

As for draft-romanow-dispatch-telepresence-use-cases-00.txt

1. (= nit)
"This draft =85" paragraph has a number of A's sprink= led in (typos?)

3. "We describe=85display stream" I assume= display stream is a stream from a document camera (as distinct from video = stream being from a participant camera?). This term does not match the word= s used in the previous paragraph.

Thanks,

Peter Musgrave


On Thu, Jul 8, 2010 at 2:46 AM= , Cullen Jennings <fluffy@cisco.com> wrote:

Theses look great - I hope people o= n the list take some time to read them.

On Jul 7, 2010, at 1:40 PM, Allyn Romanow (allyn) wrote:

> Hi= Cullen,
>
> We just put out a problem statement draft -
>= ; http://tools.ietf.org/html/draft-romanow-disp= atch-telepresence-prob-stat
> ement-00. The document is not complete, but we feel it is a solid
&= gt; beginning. =A0It does address the example you mention. The use case doc=
> also describes this case in some detail.
> http://tools.ietf.org/html/draft-romanow-dispatch-telepresence-= use-cases
> -00
>
>
> Do you not feel that the problem statement= draft can serve as a good
> basis for discussion of problems?
>= ;
> Thanks,
> Allyn
>
>
> -----Original Messa= ge-----
> From: d= ispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On
> Behalf O= f Cullen Jennings (fluffy)
> Sent: Wednesday, July 07, 2010 9:41 AM
> To: DISPATCH list
&g= t; Subject: Re: [dispatch] Charter for Telepresence multi-streams -
>= thirdversion
>
>
> I'm wondering if we could get a t= hread going about what are some of the
> specific problems we =A0need to solve =A0then dispatch theses problems= to
> appropriate WGs.
>
> For example one problem is whe= n a session involves two video session on
> multiple screens how does= one signal which stream is displayed on the
> right and left screen.
>
> I think having a list of specif= ic problems would help get this moving
> faster.
>
> Cull= en
>
>
> On Jul 4, 2010, at 10:14 PM, Allyn Romanow (ally= n) wrote:
>
>> Folks,
>> This makes the change discussed replaci= ng the text in the third
> paragraph under the Charter section with t= he text suggested on the list.
>> It also changes title from "= ;... Description of Work" to "...Charter"
>>
>> There weren't any further changes suggested.
&g= t;>
>> Thanks,
>> Allyn
>>
>>
>= ;>
>>
>> Multi-streams for Telepresence Charter
>>
>>
>>
>> Background
>> One bra= nch of video conferencing has evolved that is focused on
> immersive = "being there" experience. =A0Referred to in various ways such as<= br> > virtual conferencing, telepresence or media spaces, early systems were=
> mainly research projects or business systems with limited deployme= nts.
> In recent years telepresence systems have seen considerable ma= rket
> success. =A0Following the model of early systems, the first wave of> commercial systems have been typically located in specially designed<= br>> single-purpose rooms with multiple relatively large displays permit= ting
> life size image reproduction, multiple cameras, encoders, decoders and=
> microphones. =A0These systems have several important characteristi= cs that
> are different from more traditional video conferencing syst= ems.
>>
>> The first difference concerns controlling the visual v= iewpoint in
> order to improve participant nonverbal communication. T= hese systems
> preserve essential group meeting characteristics such = as eye contact,
> group gestures, seating order and spatial audio by carefully
> o= rchestrating the miking and camera angles at each of the sites . This
&g= t; is distinct from the more traditional approach where the geometric
> relationship between media streams is not used to preserve inter-strea= m
> communication aspects such as eye contact and group dynamics.
= >>
>> A second difference is manipulation of the environment= to improve
> immersion. =A0With telepresence systems, cinematographic aspects of th= e
> local environment reproduction are carefully planned including co= lor,
> table shape, seating and lighting so that when combined with l= arge high
> quality displays, a strong sense of a "trompe l'oeil" or= "being there"
> immersive experience is created. =A0Typica= l video conference systems do
> not include these considerations.
>>
>> As telepresence video systems have become successful i= n the market,
> manufacturers have started exploring delivery of the = nonverbal
> communication and immersive values of telepresence via sm= aller, less
> expensive and more flexible video conferencing systems for a variety o= f
> venues, such as individual offices, homes and kiosks. These are a= lso
> telepresence systems, since the audio and video quality is high= enough
> to allow clear image reproduction for nonverbal communication, they ar= e
> able to send and receive multiple media streams, and large coordi= nated
> multi image displays are available for immersive installation= s. =A0 As the
> industry develops, the line between telepresence and video conferencin= g
> may become blurred as nonverbal communication and immersive
&g= t; installations become broadly available.
>>
>> Problem<= br> >> Although telepresence systems are based on open standards such as = RTP,
> SIP, H.264, H.323 suite, they cannot easily interoperate with = each other
> without operator assistance and expensive additional equ= ipment that
> translates from one vendor to another. It would be like having to make=
> sure all parties are on the same equipment (and network) when maki= ng a
> telephone call. =A0A major factor in the inability of Telepres= ence systems
> to work with each other is that there is no standard description of th= e
> multiple streams that comprise the media flows.
>>
&g= t;> For example, in a multiple screen conference, the video and audio > streams sent from remote participants must be understood by receivers = so
> that they can be presented in a coherent and life-like manner. T= his
> includes the ability to present the remote participants at thei= r true
> size for their apparent distance, while maintaining correct eye contac= t,
> gesticular cues, and simultaneously providing a spatial audio so= und
> stage consistent with the video presentation. =A0The receiving = device that
> decides how to display the incoming information needs to understand a<= br>> number of variables such as the spatial position of the speaker, th= e
> field of view of the cameras, the camera zoom, which media stream= is
> related to each of the displays, etc.
>>
>> Charter<= br>>> The Telepresence Multi-Streams work item in DISPATCH is charter= ed to
> define and specify for SIP-based systems the content of media=
> multi-stream messages and the way these will be transported.
>&g= t;
>> This work will provide a standard for the exchange of media = semantic
> information that will foster interoperable end stations an= d conference
> bridges. It will specify =A0variables that describe the semantics of t= he
> media streams and the recommended behavior to achieve interopera= bility.
>>
>>
>> This requires considering curre= nt widely deployed use cases, as well
> as cases that are expected to be implemented using the protocol
>= ; framework produced by this work item. =A0The methodology for describing> the variables must allow extensibility of the variables, since
> telepresence is still a young technology and may have use cases that a= re
> not currently considered."
>>
>>
>&= gt; The work item will identify use cases, define requirements, and define<= br> > a method for describing and transporting information about multiple> media streams, including a specification of variables required to
= > support the use cases. This work item will consider the reuse of
> existing IETF protocols and produce an architecture/protocol framework=
> document describing the protocols required to be implemented to su= pport
> this functionality. =A0The document will identify any enhance= ments
> required to existing protocols as well as describing new protocol(s) f= or
> interoperable multi-streams negotiation that may be required.>>
>> Relevant work to be drawn upon has been done in XCON,= MMUSIC, AVT, and
> FECframe.
>>
>>
>> Scope
>> The sc= ope includes both systems that provide a fully immersive
> experience= , and systems that interwork with them and therefore need to
> unders= tand the same multiple stream semantics.
>>
>>
>> The focus of this work is on audio and vid= eo multiple streams. =A0Other
> media types may be considered, howeve= r development of methodologies for
> them is not within the scope of = this work.
>>
>> Interoperation with standards compliant systems is req= uired, such as
> SIP-based video conferencing systems. =A0However, ba= ckwards compatibility
> with existing non-standards compliant telepre= sence systems is not
> required.
>>
>>
>>
>> The group wi= ll produce
>> - Requirements and use cases
>>
>>= - Architectural Framework describing the protocols required to be
> = implemented to support this functionality and identifying existing
> protocol enhancements and new protocol functionality required
>&= gt;
>> - Specification of a new protocol to support telepresence> multi-streams [if required]
>>
>> Goals and Milest= ones
>> Nov 2010
>>
>> Use Cases and Requirements to IES= G as Informational RFC
>> Nov 2010
>> March 2011
>&= gt; Problem Statement to IESG as Informational RFC
>> Architecture= to IESG as Informational RFC
>> March 2011
>> Revise Charter [IF new protocol is not requ= ired]
>> Nov 2011
>> Submit protocol draft to IESG as Pro= posed Standard RFC
>>
>> ________________________________= _______________
>> dispatch mailing list
>> dispatch@ietf.org
>> https://www.ietf= .org/mailman/listinfo/dispatch
>
>
> Cullen Jennings
> For corporate legal informatio= n go to:
> http://www.cisco.com/web/about/doing= _business/legal/cri/index.html
>
>
>
> ______________________________________________= _
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/ma= ilman/listinfo/dispatch


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/ind= ex.html



_______________________________________________
dispatch mai= ling list
dispatc= h@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch


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


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


--0016e648d3d66fcb4f048bad6375-- From bernard_aboba@hotmail.com Sun Jul 18 13:23:40 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1F33A6976 for ; Sun, 18 Jul 2010 13:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.026 X-Spam-Level: X-Spam-Status: No, score=-0.026 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHSuq+D36ixX for ; Sun, 18 Jul 2010 13:23:39 -0700 (PDT) Received: from blu0-omc4-s2.blu0.hotmail.com (blu0-omc4-s2.blu0.hotmail.com [65.55.111.141]) by core3.amsl.com (Postfix) with ESMTP id 87FDF3A67CF for ; Sun, 18 Jul 2010 13:23:39 -0700 (PDT) Received: from BLU137-W33 ([65.55.111.135]) by blu0-omc4-s2.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Jul 2010 13:23:53 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_3b0fe099-4627-4cf4-a6d8-1589b3d1017d_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Sun, 18 Jul 2010 13:23:52 -0700 Importance: Normal In-Reply-To: References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> , MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jul 2010 20:23:53.0187 (UTC) FILETIME=[23CF9B30:01CB26B7] Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 20:23:40 -0000 --_3b0fe099-4627-4cf4-a6d8-1589b3d1017d_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > a. One problem is the need to be able to "upgrade" an audio call in progr= ess in order to provide for additional media=2C even if the call had been c= ompleted=20 > over the PSTN so that there was no SDP offer/answer negotiation between t= he end-points. This is the problem that Facetime solves=2C for example.=20 =20 Cullen Jennings said: "Bernard=2C obviously a large percentage of the work done in RAI is to allo= w rich communications over the internet and for the most part the existing = work today from AVT=2C MMUSIC=2C SIP and so on already solves your point (a= )" [BA] Problem a) was about upgrading of calls made over the PSTN=2C not the= Internet. Are you suggesting that SIP=2C SDP=2C etc. already provides a s= tandardized way to do *that*?=20 = --_3b0fe099-4627-4cf4-a6d8-1589b3d1017d_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B a. One problem is the need to be able to "upgrade" an audio call in = progress in order to provide for additional media=2C even if the call had b= een completed
>=3B over the PSTN so that there was no SDP offer/answe= r negotiation between the end-points. =3B This is the problem that Face= time solves=2C for example.
 =3B
Cullen Jennings said:

"B= ernard=2C obviously a large percentage of the work done in RAI is to allow = rich communications over the internet and for the most part the existing wo= rk today from AVT=2C MMUSIC=2C SIP and so on already solves your point (a)"=

[BA] Problem a) =3B was about upgrading of calls made over the = PSTN=2C not the Internet. =3B Are you suggesting that SIP=2C SDP=2C etc= . already provides a standardized way to do *that*?

= --_3b0fe099-4627-4cf4-a6d8-1589b3d1017d_-- From bernard_aboba@hotmail.com Sun Jul 18 13:36:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70ADA3A6976 for ; Sun, 18 Jul 2010 13:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0Lg+hidxPzy for ; Sun, 18 Jul 2010 13:36:23 -0700 (PDT) Received: from blu0-omc3-s22.blu0.hotmail.com (blu0-omc3-s22.blu0.hotmail.com [65.55.116.97]) by core3.amsl.com (Postfix) with ESMTP id C457F3A6988 for ; Sun, 18 Jul 2010 13:36:11 -0700 (PDT) Received: from BLU137-W2 ([65.55.116.74]) by blu0-omc3-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Jul 2010 13:35:47 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_620f18c8-7a5d-4c30-8a90-8cb4d39ec2b5_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , Date: Sun, 18 Jul 2010 13:35:47 -0700 Importance: Normal In-Reply-To: <000001cb26a4$a81e4840$f85ad8c0$@us> References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <4C4326B1.7020408@nostrum.com>,<000001cb26a4$a81e4840$f85ad8c0$@us> MIME-Version: 1.0 X-OriginalArrivalTime: 18 Jul 2010 20:35:47.0228 (UTC) FILETIME=[CD699DC0:01CB26B8] Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 20:36:34 -0000 --_620f18c8-7a5d-4c30-8a90-8cb4d39ec2b5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Richard Shockey said: "For my 547th rant. People want to use phone numbers." [BA] There are devices out there for which input of an email-style URI is difficult or impossible. Is the goal to: c. Enable individuals with those devices to reach someone with an email-sty= le URI=2C while only inputting only numbers? =20 d. Enable individuals with those devices to reach someone who has an E.164 number?=20 Problems c) and d) are not the same. For example=2C while problem d) may require translation of an E.164 number to an email-style URI=2C in problem c) we don't assume that the target endpoint is described with an E.164 number=2C just some set of numbers=2C so that a wider array of solutions=20 may be available=2C some of which do not require translation. = --_620f18c8-7a5d-4c30-8a90-8cb4d39ec2b5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Richard Shockey said:
"For my 547th rant. People want to use phone =
numbers."

[BA] There are devices out there for which input of an ema=
il-style URI is
difficult or impossible.  Is the goal to:

c. Enab=
le individuals with those devices to reach someone with an email-style
U=
RI=2C while only inputting only numbers?  

d. Enable individuals wit=
h those devices to reach someone who has an E.164
number? 

Proble=
ms c) and d) are not the same.  For example=2C while problem d) may
requ=
ire translation of an E.164 number to an email-style URI=2C in problem
c=
) we don't assume that the target endpoint is described with an E.164
nu=
mber=2C just some set of numbers=2C so that a wider array of solutions 
=
may be available=2C some of which do not require translation.
= = --_620f18c8-7a5d-4c30-8a90-8cb4d39ec2b5_-- From adam@nostrum.com Sun Jul 18 14:27:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 217A93A6848 for ; Sun, 18 Jul 2010 14:27:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLvk6KbsvnGE for ; Sun, 18 Jul 2010 14:27:52 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B9DE03A67D9 for ; Sun, 18 Jul 2010 14:27:51 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6ILS30B093621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Jul 2010 16:28:03 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C4371E3.1090802@nostrum.com> Date: Sun, 18 Jul 2010 16:28:03 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Richard Shockey References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <4C4326B1.7020408@nostrum.com> <000001cb26a4$a81e4840$f85ad8c0$@us> In-Reply-To: <000001cb26a4$a81e4840$f85ad8c0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.233 is authenticated by a trusted mechanism) Cc: 'Bernard Aboba' , dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 21:27:53 -0000 On 7/18/10 13:11, Jul 18, Richard Shockey wrote: > The FaceTime mechanism is rather clever and is certainly one way to solve > the real problem of the E.164 trust binding in session (re)establishment. If > you can make a PSTN call .. its works. From the user experience perspective > (Apples obsession) its nearly flawless. Apple did a very nice job. If Steve > and company finally decide to publish what they have done they will have a > lot of friends. Well, details are a bit sketchy, but preliminary analysis is that the whole system holds together only because Apple has things set up so that they retain an iron-gripped control over everything. Effectively, it would be like saying "the SIP E.164 number mapping problem has been solved! Just slap "@apple.com" after any E.164 number in the world, and you can be sure you're reaching the right person!" As far as I can tell, the binding from a phone number to a client cert (yes, they use mTLS for auth) is performed via some kind of SMS exchange (as users must have SMS service the first time they use FaceTime, but not for subsequent calls). My guess is that the phone sends a client cert fingerprint to Apple, and then Apple trusts that the cert indicated is 100% certain to correspond to the phone number that the SMS appears to have come from. I agree that it's clever, but it doesn't work unless it's all under the tight control of a single entity. It also is completely dependent on being able to send an SMS from the associated E.164 number (which limits it to mobile phones). /a From lconroy@insensate.co.uk Sun Jul 18 14:55:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93CF63A6988 for ; Sun, 18 Jul 2010 14:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.284 X-Spam-Level: X-Spam-Status: No, score=-0.284 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-wsDg0C7VGo for ; Sun, 18 Jul 2010 14:55:03 -0700 (PDT) Received: from insensate.co.uk (ghost.insensate.co.uk [213.152.49.121]) by core3.amsl.com (Postfix) with ESMTP id 856803A685B for ; Sun, 18 Jul 2010 14:55:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by insensate.co.uk (Postfix) with ESMTP id 07BFB31A582; Sun, 18 Jul 2010 22:55:14 +0100 (BST) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Lawrence Conroy In-Reply-To: <6AE150DC-4721-4FD6-A2B0-E7441A2ADB8D@cisco.com> Date: Sun, 18 Jul 2010 22:55:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6AE150DC-4721-4FD6-A2B0-E7441A2ADB8D@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1081) Cc: dispatch mailing list Subject: Re: [dispatch] ViPR Charter V4- a suggestion X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 21:55:04 -0000 Hi Cullen, Peter, folks, MY strong immune reaction was to the first two paragraphs. - The first sentence of the first paragraph is OK. - First para, second sentence: ", thus DNS lookups are not sufficient". I have no idea what this means. On first look it doesn't follow, and = seems to be not true for at least some cases. Many/most SIP addresses I have *ever* used have been of the form = *@, and if the SIP proxy for domainpart recognises the digit string as a known userpart, what is = the problem? It works for me. DNS lookups work fine to get the server for the domainpart. - First paragraph, third sentence: I don't see how public ENUM is = "another approach"; another approach to what? The rest of the sentence discusses the administrative load for public = ENUM. Yes, it is hard to validate an E.164 number. Frankly, if that makes ENUM untenable, then use e164.org and be done = with it; that does have validation, but they only assume that one can = answer a phone and goto a web page; no further protocol sauce required. For a real alternative approach, there's always IMS (OK, that also = specifies use of ENUM, but it sure is different from RFC 2543). - First Paragraph, fourth sentence: To suggest that *all* ENUM-like = systems are not scalable seems odd without further justification. If this statement has any justification, why is it not in the charter = text? - First paragraph, final sentence: People use phone numbers already; I = sure use them with SIP (to my provider's B2BUA -- not exactly a SIP = service, so it works fine). So ... this Intro needs to spell out in a = lot more detail what's the gap that this proposed WG needs to fill. The "big picture" so far is a bit Bridget Riley. To continue: Given the text in the second paragraph, does this mean any one of my SIP = providers is a "domain responsible for a phone number", because I can = dial to that phone number via any of them? Whichever one I choose is an = intermediary from my perspective. It sure has a "relationship" with that = target phone number. The second paragraph third sentence (especially the = "...at least one of the domains, ...") needs a LOT of work before its = ready for prime time. And so to the third paragraph: Peter's comment on sharing a secret seems to be absolutely germane; it's = the only way you're going to avoid a central system as timings (if at = all realistic) and media fingerprinting are secrets shared between end = points (and your friendly local Carrier, and anyone else who's = listening, and anyone who processes either party's CDRs, and ...). = Without shared secret knowledge, why should an end point trust an = assertion from some random lawn mower man? I remain to be convinced that a reasonable administrative association = between a SIP domainpart and a PSTN number is feasible, at scale, on a = dynamic basis, particularly if the domainpart is intended to include any = intermediaries. Nothing yet mentioned in the charter looks like it would work; it does = look from later paragraphs like it envisages upgrades to a LOT of kit. It would very good to find such an (unencumbered) scheme that doesn't = require a lot of upgraded components, but this is a really hard problem. I'm not alone in being skeptical; those skeptics seem to include folk = who have suffered operational pain over a protracted period of life with = phone number/server validation. In short, just 'cos it's the Internet doesn't mean the problems go away. I await enlightenment @ Maastricht (or at least some beers). all the best, Lawrence On 18 Jul 2010, at 17:14, Cullen Jennings wrote: > There's some good parts in this that perhaps we can figure out how to = use but I don't think we should make this change exactly as proposed.=20 >=20 > If there are political parts of the current proposal, I'm glad to = make them more politically correct or whatever it is people want to fix = them but I'm not understanding the reasons for removing theses two = paragraphs. Is it the mention of public ENUM you are concerned about? It = would be easy to rephrase that.=20 >=20 > I'm not at keen on the replacement paragraph - the big reasons why is = for people who have not been following this list or deeply involved with = RAI, it removed the whole big picture motivation of why we want this WG = or what the problem is. More details inline.=20 From adam@nostrum.com Sun Jul 18 15:07:29 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1D3A3A698D for ; Sun, 18 Jul 2010 15:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANAKGRs0S7-Q for ; Sun, 18 Jul 2010 15:07:28 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id BE9B03A698F for ; Sun, 18 Jul 2010 15:07:27 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6IM6xUj096670 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Jul 2010 17:06:59 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C437B03.6070600@nostrum.com> Date: Sun, 18 Jul 2010 17:06:59 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Richard Shockey References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <4C4326B1.7020408@nostrum.com> <000001cb26a4$a81e4840$f85ad8c0$@us> In-Reply-To: <000001cb26a4$a81e4840$f85ad8c0$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.233 is authenticated by a trusted mechanism) Cc: 'Bernard Aboba' , dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 22:07:29 -0000 On 7/18/10 13:11, Jul 18, Richard Shockey wrote: > For my 547th rant. People want to use phone numbers. I forgot to mention -- if you're insisting on this as a maxim, then FaceTime might not be your best poster boy. http://www.boygeniusreport.com/2010/07/15/exclusive-apples-facetime-coming-to-ipod-touch-ipad-we-detail-how/ Phone numbers are useful to get to & from the PSTN. But, aside from that, they're a disposable relic in today's gadgets. I mean, really -- when is the last time you mashed 10 (or more) digits into your phone instead of selecting someone's name out of an address book? Why would you care what the identifier behind that address book entry looks like? There came a time where calling the operator and asking for "Dallas, Diamond Exchange, 3-6-5-5-2" became a bit quaint. And then it stopped working. You really think we'll never bridge the gap away from phone numbers? /a From bernard_aboba@hotmail.com Sun Jul 18 15:22:49 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF67A3A65A6 for ; Sun, 18 Jul 2010 15:22:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.261 X-Spam-Level: X-Spam-Status: No, score=-1.261 tagged_above=-999 required=5 tests=[AWL=1.338, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjKlf22No69g for ; Sun, 18 Jul 2010 15:22:49 -0700 (PDT) Received: from blu0-omc4-s9.blu0.hotmail.com (blu0-omc4-s9.blu0.hotmail.com [65.55.111.148]) by core3.amsl.com (Postfix) with ESMTP id DC4703A699A for ; Sun, 18 Jul 2010 15:22:48 -0700 (PDT) Received: from BLU137-DS14 ([65.55.111.135]) by blu0-omc4-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Jul 2010 15:23:02 -0700 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Adam Roach'" , "'Richard Shockey'" References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <4C4326B1.7020408@nostrum.com> <000001cb26a4$a81e4840$f85ad8c0$@us> <4C4371E3.1090802@nostrum.com> In-Reply-To: <4C4371E3.1090802@nostrum.com> Date: Sun, 18 Jul 2010 15:23:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsmwBurUfnLz7vgT5iPIatnzWWaGgABiQ/g Content-Language: en-us X-OriginalArrivalTime: 18 Jul 2010 22:23:02.0598 (UTC) FILETIME=[C9312660:01CB26C7] Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jul 2010 22:22:50 -0000 Adam Roach said: " As far as I can tell, the binding from a phone number to a client cert (yes, they use mTLS for auth) is performed via some kind of SMS exchange (as users must have SMS service the first time they use FaceTime, but not for subsequent calls). My guess is that the phone sends a client cert fingerprint to Apple, and then Apple trusts that the cert indicated is 100% certain to correspond to the phone number that the SMS appears to have come from." [BA] If we can assume the existence of an in-band channel for initial communication between the endpoints (whether that in-band channel is the PSTN, SMS, etc.) as well as a public/private key pair used to identify the end-point, then a number of mechanisms may be available to bind the endpoint identifiers to the public/private key pair. For example, the IETF has already developed techniques for demonstration of ownership of parameter resources (e.g. RFC 3971). From gao.yang2@zte.com.cn Sun Jul 18 23:09:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A535F3A69E5 for ; Sun, 18 Jul 2010 23:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.799 X-Spam-Level: X-Spam-Status: No, score=-96.799 tagged_above=-999 required=5 tests=[AWL=-1.023, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZjPhMWnKJGs for ; Sun, 18 Jul 2010 23:09:17 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id B9D643A69DF for ; Sun, 18 Jul 2010 23:09:15 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 3510992332426; Mon, 19 Jul 2010 14:08:38 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 38391.2776214488; Mon, 19 Jul 2010 14:01:35 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6J64p4G034557; Mon, 19 Jul 2010 14:04:51 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <430FC6BDED356B4C8498F634416644A921187F7245@mail> To: Hadriel Kaplan MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 19 Jul 2010 14:01:27 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-19 14:04:45, Serialize complete at 2010-07-19 14:04:45 Content-Type: multipart/alternative; boundary="=_alternative 0021506D48257765_=" X-MAIL: mse2.zte.com.cn o6J64p4G034557 Cc: DISPATCH list Subject: Re: [dispatch] Investigation about supporting Lawful interception's X1(Target Setting): X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 06:09:20 -0000 This is a multipart message in MIME format. --=_alternative 0021506D48257765_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGV5IEhhZHJpZWyjrA0KDQpUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UuIFNvbWUgY29tbWVudHMg aW5saW5lcy4NCg0KSGFkcmllbCBLYXBsYW4gPEhLYXBsYW5AYWNtZXBhY2tldC5jb20+INC009og MjAxMC0wNy0xNiAyMzoxNTo1MzoNCg0KPiBIZXkgR2FvLA0KPiBUaGUgSUVURiBkb2VzIG5vdCBk ZWZpbmUgb3Igd29yayBvbiBMYXdmdWwgSW50ZXJjZXB0IHByb3RvY29scyAocGFydGx5IA0KYmVj YXVzZQ0KPiB0aGV5oa9yZSBuYXRpb25hbC1sYXcgc3BlY2lmaWMpLiANCg0KWWVzLCB0aGF0J3Mg c3Bpcml0IG9mIElFVEYuIEJ1dCBJIHRoaW5rIG9ubHkgSGFuZG92ZXIgaW50ZXJmYWNlcyhIMS9I Mi9IMykgDQpzaG91bGQgYmUgdW5kZXIgdGhpcyByZXN0cmljdGlvbi4gQnV0IHRoaXMgaXMgYSBi aWcgcXVlc3Rpb24uIA0KQXMgeW91IGhhdmUgZ2l2ZSBtZSB1c2VmdWwgaW5mb3JtYXRpb24sIEkg dGhpbmsgSSBjYW4gZG8gdGhlIGludmVzdGlnYXRpb24gDQpieSB0aGUgd2F5IHlvdSByZWNvbW1l bmRlZC4NCg0KVGhhbmtzIGFnYWluLA0KDQpHYW8NCg0KPiBSRkMgMzkyNCB3YXMgb25seSBhbiBp bmZvcm1hdGlvbmFsLA0KPiBhbmQgbWF5YmUgZXZlbiBvbmx5IGFuIGluZGl2aWR1YWwgZG9jdW1l bnQgcHVibGlzaGVkIGJ5IHRoZSBSRkMgDQo+IEVkaXRvciwgbm90IGFuIElFVEYgZG9jdW1lbnQg KHNlZSB0aGUgSUVTRyBub3RlIGluIHRoZSBSRkMpLiAgSXShr3MgDQo+IGNvbmZ1c2luZyBiZWNh dXNlIHRlY2huaWNhbGx5IHRoZSBSRkMgRWRpdG9yIGlzIG5vdCBwYXJ0IG9mIHRoZSANCj4gSUVU RiwgYW5kIHRoZSBJRVRGIGlzIGp1c3Qgb25lIHBhcnRpY3VsYXIgdXNlci9jdXN0b21lci9jbGll bnQgb2YgDQo+IHRoZSBSRkMgRWRpdG9yIKhDIHRoZSBJRVRGIGFza3MgdGhlIFJGQyBFZGl0b3Ig dG8gcHVibGlzaCBkb2N1bWVudHMsIA0KPiBidXQgc28gY2FuIG90aGVycy4NCj4gDQo+IFJlZ2Fy ZGxlc3MsIHlvdXIgcXVlc3Rpb24gaXMgcHJvYmFibHkgYmV0dGVyIGRpcmVjdGVkIHRvIHRoZSBT SVAgDQo+IEltcGxlbWVudG9ycyBsaXN0IChzaXAtaW1wbGVtZW50b3JzQGxpc3RzLmNzLmNvbHVt YmlhLmVkdSkgb3IgZXZlbiANCj4gYmV0dGVyOiB0byBpbmRpdmlkdWFsIHBlb3BsZSBhdCB0aGUg cmVzcGVjdGl2ZSBTQkMgdmVuZG9ycywgYW5kIG5vdCANCj4gRElTUEFUQ0gsIHNpbmNlIGl0IGlz bqGvdCByZWFsbHkgZ2VybWFuZSB0byBESVNQQVRDSC4gIChBcyBmb3IgbXkgDQo+IGVtcGxveWVy oa9zIFNCQ6GvcywgdGhleSBkbyBzdXBwb3J0IHRoZSBYMSBpbnRlcmZhY2UgaWYgeW91IGhhdmUg dGhlIA0KPiByaWdodCBzb2Z0d2FyZSB2ZXJzaW9uKQ0KPiANCj4gLWhhZHJpZWwNCj4gDQoNCg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N ClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5p emF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVu dHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUg bm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0 aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRo IGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0 aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3Jp Z2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3Nh Z2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMg YmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVt Lg0K --=_alternative 0021506D48257765_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhleSBIYWRyaWVso6w8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgeW91 ciByZXNwb25zZS4gU29tZSBjb21tZW50cw0KaW5saW5lcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj5IYWRyaWVsIEthcGxhbiAmbHQ7SEthcGxhbkBhY21lcGFja2V0LmNvbSZn dDsg0LTT2g0KMjAxMC0wNy0xNiAyMzoxNTo1Mzo8YnI+DQo8YnI+DQomZ3Q7IEhleSBHYW8sPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IFRoZSBJRVRGIGRvZXMgbm90IGRl ZmluZSBvciB3b3JrIG9uIExhd2Z1bCBJbnRlcmNlcHQNCnByb3RvY29scyAocGFydGx5IGJlY2F1 c2U8YnI+DQomZ3Q7IHRoZXmhr3JlIG5hdGlvbmFsLWxhdyBzcGVjaWZpYykuICZuYnNwOzwvZm9u dD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+WWVzLCB0aGF0J3Mgc3Bpcml0IG9m IElFVEYuIEJ1dCBJIHRoaW5rIG9ubHkgSGFuZG92ZXINCmludGVyZmFjZXMoSDEvSDIvSDMpIHNo b3VsZCBiZSB1bmRlciB0aGlzIHJlc3RyaWN0aW9uLiBCdXQgdGhpcyBpcyBhIGJpZw0KcXVlc3Rp b24uIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+QXMgeW91IGhhdmUgZ2l2ZSBt ZSB1c2VmdWwgaW5mb3JtYXRpb24sIEkgdGhpbmsgSQ0KY2FuIGRvIHRoZSBpbnZlc3RpZ2F0aW9u IGJ5IHRoZSB3YXkgeW91IHJlY29tbWVuZGVkLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+VGhhbmtzIGFnYWluLDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+R2FvPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IFJGQyAzOTI0IHdhcyBvbmx5IGFuIGluZm9ybWF0aW9uYWwsPGJyPg0KJmd0OyBhbmQgbWF5YmUg ZXZlbiBvbmx5IGFuIGluZGl2aWR1YWwgZG9jdW1lbnQgcHVibGlzaGVkIGJ5IHRoZSBSRkMgPGJy Pg0KJmd0OyBFZGl0b3IsIG5vdCBhbiBJRVRGIGRvY3VtZW50IChzZWUgdGhlIElFU0cgbm90ZSBp biB0aGUgUkZDKS4gJm5ic3A7SXShr3MNCjxicj4NCiZndDsgY29uZnVzaW5nIGJlY2F1c2UgdGVj aG5pY2FsbHkgdGhlIFJGQyBFZGl0b3IgaXMgbm90IHBhcnQgb2YgdGhlIDxicj4NCiZndDsgSUVU RiwgYW5kIHRoZSBJRVRGIGlzIGp1c3Qgb25lIHBhcnRpY3VsYXIgdXNlci9jdXN0b21lci9jbGll bnQgb2YNCjxicj4NCiZndDsgdGhlIFJGQyBFZGl0b3IgqEMgdGhlIElFVEYgYXNrcyB0aGUgUkZD IEVkaXRvciB0byBwdWJsaXNoIGRvY3VtZW50cywNCjxicj4NCiZndDsgYnV0IHNvIGNhbiBvdGhl cnMuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBSZWdhcmRsZXNzLCB5b3VyIHF1ZXN0aW9u IGlzIHByb2JhYmx5IGJldHRlcg0KZGlyZWN0ZWQgdG8gdGhlIFNJUCA8YnI+DQomZ3Q7IEltcGxl bWVudG9ycyBsaXN0IChzaXAtaW1wbGVtZW50b3JzQGxpc3RzLmNzLmNvbHVtYmlhLmVkdSkgb3Ig ZXZlbg0KPGJyPg0KJmd0OyBiZXR0ZXI6IHRvIGluZGl2aWR1YWwgcGVvcGxlIGF0IHRoZSByZXNw ZWN0aXZlIFNCQyB2ZW5kb3JzLCBhbmQgbm90DQo8YnI+DQomZ3Q7IERJU1BBVENILCBzaW5jZSBp dCBpc26hr3QgcmVhbGx5IGdlcm1hbmUgdG8gRElTUEFUQ0guICZuYnNwOyhBcyBmb3INCm15IDxi cj4NCiZndDsgZW1wbG95ZXKhr3MgU0JDoa9zLCB0aGV5IGRvIHN1cHBvcnQgdGhlIFgxIGludGVy ZmFjZSBpZiB5b3UgaGF2ZQ0KdGhlIDxicj4NCiZndDsgcmlnaHQgc29mdHdhcmUgdmVyc2lvbik8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IC1oYWRyaWVsPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjxwcmU+DQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5i c3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtp bmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJz cDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5k ZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmlj YXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFt ZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRh aW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVk Jm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJz cDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNw O2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNw O3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2lu dGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJz cDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3do b20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5i c3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtl cnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJz cDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHBy ZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2Um bmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7 bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmly dXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZu YnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0021506D48257765_=-- From john.elwell@siemens-enterprise.com Sun Jul 18 23:20:39 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9DBC3A69F1 for ; Sun, 18 Jul 2010 23:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FsPNRqSsV0W for ; Sun, 18 Jul 2010 23:20:38 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 27F6D3A69E8 for ; Sun, 18 Jul 2010 23:20:37 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-889606; Mon, 19 Jul 2010 08:20:48 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id D937D1EB82AB; Mon, 19 Jul 2010 08:20:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 19 Jul 2010 08:20:47 +0200 From: "Elwell, John" To: Cullen Jennings Date: Mon, 19 Jul 2010 08:20:45 +0200 Thread-Topic: [dispatch] I-D Action:draft-jennings-dispatch-npa-00.txt Thread-Index: AcsmlbgYC571p0kvSQaHSXYvQAT3igAdMaFA Message-ID: References: <20100705160001.9CA5A3A6890@core3.amsl.com> <7872E6AE-BDE8-4A19-B3A3-02E6C9401C7A@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] I-D Action:draft-jennings-dispatch-npa-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 06:20:39 -0000 Sounds reasonable. John=20 > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Sent: 18 July 2010 17:24 > To: Elwell, John > Cc: dispatch@ietf.org > Subject: Re: [dispatch] I-D Action:draft-jennings-dispatch-npa-00.txt >=20 >=20 > Thought on number of digits and what uniqueness string? I was=20 > thinking the min number of digits should be about 5. I did=20 > not have any particularly good reason for that number other=20 > than it was low enough to be easy to enter even on a single=20 > button device and large enough that registering all of them=20 > seemed very unlikely. Obviously more than 5 digits is=20 > allowed, that would just be the min.=20 >=20 > On the uniqueness string, I imagine we could just run some=20 > tests of any strings people propose and see how many are=20 > registered in DNS already.=20 >=20 >=20 > On Jul 11, 2010, at 23:18 , Elwell, John wrote: >=20 > > Cullen, > >=20 > > My concern with the first option was simply that a small=20 > number of PANxxx values might already be taken for other=20 > purposes. But I agree this could be mitigated by using a more=20 > obscure fixed string than simply "PAN" and by having a=20 > reasonable minimal length for xxx. So probably the first=20 > option is the best. > >=20 > > John > >=20 > >=20 > >> -----Original Message----- > >> From: Cullen Jennings [mailto:fluffy@cisco.com]=20 > >> Sent: 09 July 2010 23:00 > >> To: Elwell, John > >> Cc: dispatch@ietf.org > >> Subject: Re: [dispatch] I-D=20 > Action:draft-jennings-dispatch-npa-00.txt > >>=20 > >>=20 > >> On Jul 9, 2010, at 3:09 AM, Elwell, John wrote: > >>=20 > >>> 1.1 Simple Single TLD. This would presumably involve=20 > >> reserving PANxxx (where xxx is a digit string of a certain=20 > >> length or range of lengths), and would be a problem if any=20 > >> such value has already been taken. > >>=20 > >>=20 > >> can you say a bit more about what you see as the problem - my=20 > >> thinking is roughly the following. If 123 is already taken by=20 > >> someone else, then it is taken - it does not matter if we use=20 > >> sipforum or .net as the registry. Now if you are concerned=20 > >> that pan123.net might be taken for some other use than the=20 > >> purpose of the PAN draft, then we could make the string you=20 > >> prepend be pan-z9hG4bK and that problem more or less goes=20 > >> away. You could argue that .net domains are so cheap that=20 > >> someone might just go get all of them. This seems like a=20 > >> pretty unlikely attack but that is why the xxx has a minimum=20 > >> length so the number they needed to get was large. Also it=20 > >> may have a minimum length but it's not fixed length so people=20 > >> can go to a domain with a longer string.=20 > >>=20 > >> I'm just not really seeing how this is all that much=20 > >> different if we have the domain that looks like=20 > >> 123.sipforum.net or a string that looks like 123sipforum.net=20 > >> - the size of the address space is about the same either way.=20 > >>=20 > >> And I pretty much agree with your comments on the other the=20 > >> other ones - we could probably find ways to solve some of=20 > >> theses but 2,3,4 are at some level just optimization of 1 so=20 > >> if there is some fundamental problem with 1, it probably=20 > >> impacts all of them. =20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 >=20 >=20 > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html >=20 >=20 > = From mlinsner@cisco.com Mon Jul 19 05:37:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 280633A676A for ; Mon, 19 Jul 2010 05:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19l8jgOFEfM3 for ; Mon, 19 Jul 2010 05:37:41 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1F81F3A67F4 for ; Mon, 19 Jul 2010 05:37:41 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMrjQ0xAZnwN/2dsb2JhbACfcXGmZpo2hSUEiFc X-IronPort-AV: E=Sophos;i="4.55,226,1278288000"; d="scan'208";a="134152220" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Jul 2010 12:37:55 +0000 Received: from [10.116.195.117] (rtp-mlinsner-8714.cisco.com [10.116.195.117]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6JCbs6I023053; Mon, 19 Jul 2010 12:37:54 GMT User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Mon, 19 Jul 2010 08:37:49 -0400 From: Marc Linsner To: Richard Shockey Message-ID: Thread-Topic: [dispatch] VIPR - proposed charter version 4 Thread-Index: Acsmk0zBKxXnrSQLSG2bqd2KJq9HNQADgfygACd3ZVE= In-Reply-To: <000001cb26a4$a81e4840$f85ad8c0$@us> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 12:37:42 -0000 Richard, On 7/18/10 2:11 PM, "Richard Shockey" wrote: > > For my 547th rant. People want to use phone numbers. [ML] My observation is this is a generational issue, it'll solve itself in due time. :^) > > SIP addressing, for better or worse, is now and forever will be bound in > large measure to phone numbers and phone numbers and the PSTN are controlled > by service providers. [ML] From an end-user perspective, I believe that as long as I pay *any* SP a monthly fee, the E.164 address belongs to me, in the US I can move it amongst SPs as I see fit. For this fee, I am allowed to assert that I own such address and I can advertise that I own it in any medium I want including yellow pages, business cards, newsprint, Internet, etc. It appears to me that Vipr is simply another medium where I advertise that I own such E.164 address. -Marc- From pp3129@att.com Mon Jul 19 05:50:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2263A6B04 for ; Mon, 19 Jul 2010 05:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNFFsdYrc3BY for ; Mon, 19 Jul 2010 05:50:34 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 446543A68B5 for ; Mon, 19 Jul 2010 05:50:34 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: pp3129@att.com X-Msg-Ref: server-3.tower-167.messagelabs.com!1279543847!25643312!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 27499 invoked from network); 19 Jul 2010 12:50:48 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Jul 2010 12:50:48 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o6JCoLwN028973; Mon, 19 Jul 2010 08:50:22 -0400 Received: from gaalpa1msgusr7a.ugd.att.com (gaalpa1msgusr7a.ugd.att.com [135.53.26.15]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o6JCoIl6028943; Mon, 19 Jul 2010 08:50:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Jul 2010 08:50:42 -0400 Message-ID: <35FE871E2B085542A35726420E29DA6B0460CECB@gaalpa1msgusr7a.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 4 Thread-Index: Acsmk0zBKxXnrSQLSG2bqd2KJq9HNQADgfygACd3ZVEAAFGWkA== References: <000001cb26a4$a81e4840$f85ad8c0$@us> From: "PFAUTZ, PENN L (ATTCORP)" To: "Marc Linsner" , "Richard Shockey" Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 12:50:35 -0000 Marc: I don't think the concern is about the number assignee advertising the number, but about being sure that *only* the number assignee, carrier of record, or other authorized party is advertising the number. Penn Pfautz -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Monday, July 19, 2010 8:38 AM To: Richard Shockey Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 Richard, On 7/18/10 2:11 PM, "Richard Shockey" wrote: >=20 > For my 547th rant. People want to use phone numbers. [ML] My observation is this is a generational issue, it'll solve itself in due time. :^) >=20 > SIP addressing, for better or worse, is now and forever will be bound in > large measure to phone numbers and phone numbers and the PSTN are controlled > by service providers. [ML] From an end-user perspective, I believe that as long as I pay *any* SP a monthly fee, the E.164 address belongs to me, in the US I can move it amongst SPs as I see fit. For this fee, I am allowed to assert that I own such address and I can advertise that I own it in any medium I want including yellow pages, business cards, newsprint, Internet, etc. It appears to me that Vipr is simply another medium where I advertise that I own such E.164 address. -Marc- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From mlinsner@cisco.com Mon Jul 19 06:27:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 760913A6829 for ; Mon, 19 Jul 2010 06:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJLsnm+dyBzX for ; Mon, 19 Jul 2010 06:27:27 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E35213A67C0 for ; Mon, 19 Jul 2010 06:27:25 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEfvQ0yrR7H+/2dsb2JhbACfcnGnOJo8hSUEiFc X-IronPort-AV: E=Sophos;i="4.55,226,1278288000"; d="scan'208";a="160490178" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 19 Jul 2010 13:27:40 +0000 Received: from [10.116.195.117] (rtp-mlinsner-8714.cisco.com [10.116.195.117]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6JDRciI015547; Mon, 19 Jul 2010 13:27:39 GMT User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Mon, 19 Jul 2010 09:27:31 -0400 From: Marc Linsner To: "PFAUTZ, PENN L (ATTCORP)" Message-ID: Thread-Topic: [dispatch] VIPR - proposed charter version 4 Thread-Index: Acsmk0zBKxXnrSQLSG2bqd2KJq9HNQADgfygACd3ZVEAAFGWkAABasQ3 In-Reply-To: <35FE871E2B085542A35726420E29DA6B0460CECB@gaalpa1msgusr7a.ugd.att.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 13:27:36 -0000 Penn, My interpretation (which stands a good chance of being wrong) of Vipr is that it's designed as an 'end-user' (lessee of the E.164) assertion mechanism, not designed for 'carrier of record' (PSTN SP) assertion. The vulnerabilities of the authentication mechanism will obviously need vetted in a work group setting. -Marc- On 7/19/10 8:50 AM, "PFAUTZ, PENN L (ATTCORP)" wrote: > Marc: > I don't think the concern is about the number assignee advertising the > number, but about being sure that *only* the number assignee, carrier of > record, or other authorized party is advertising the number. > > Penn Pfautz > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Marc Linsner > Sent: Monday, July 19, 2010 8:38 AM > To: Richard Shockey > Cc: dispatch@ietf.org > Subject: Re: [dispatch] VIPR - proposed charter version 4 > > Richard, > > > On 7/18/10 2:11 PM, "Richard Shockey" wrote: > >> >> For my 547th rant. People want to use phone numbers. > > [ML] My observation is this is a generational issue, it'll solve itself > in > due time. :^) > >> >> SIP addressing, for better or worse, is now and forever will be bound > in >> large measure to phone numbers and phone numbers and the PSTN are > controlled >> by service providers. > > [ML] From an end-user perspective, I believe that as long as I pay *any* > SP > a monthly fee, the E.164 address belongs to me, in the US I can move it > amongst SPs as I see fit. For this fee, I am allowed to assert that I > own > such address and I can advertise that I own it in any medium I want > including yellow pages, business cards, newsprint, Internet, etc. > > It appears to me that Vipr is simply another medium where I advertise > that I > own such E.164 address. > > -Marc- > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From maltarai@cisco.com Mon Jul 19 06:42:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7FDD3A6813 for ; Mon, 19 Jul 2010 06:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShAQ0HDKkcbY for ; Mon, 19 Jul 2010 06:42:09 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 369863A68A9 for ; Mon, 19 Jul 2010 06:42:09 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAfzQ0ytJV2Z/2dsb2JhbACfcnGnQJo+hSUEhACHCw X-IronPort-AV: E=Sophos;i="4.55,226,1278288000"; d="scan'208";a="134177053" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rtp-iport-2.cisco.com with ESMTP; 19 Jul 2010 13:42:23 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o6JDgMiv017238; Mon, 19 Jul 2010 13:42:22 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 08:42:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Jul 2010 08:42:24 -0500 Message-ID: <04CA7DCC63584C4D8967FF818D80965B01C4754E@XMB-RCD-113.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 4 Thread-Index: Acsmk0zBKxXnrSQLSG2bqd2KJq9HNQADgfygACd3ZVEAAFGWkAABasQ3AAATm6A= References: <35FE871E2B085542A35726420E29DA6B0460CECB@gaalpa1msgusr7a.ugd.att.com> From: "Mohammad Al-Taraireh (maltarai)" To: "Marc Linsner (mlinsner)" , "PFAUTZ, PENN L (ATTCORP)" X-OriginalArrivalTime: 19 Jul 2010 13:42:23.0033 (UTC) FILETIME=[375F9290:01CB2748] Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 13:42:10 -0000 ViPR already suggests at least one method of making that assertion, again this is not written in stone, and can be changed if there are better alternatives.=20 Putting all motivations aside for a moment, businesses, and people will continue to use E.164 number for a long time to come, and we will need something to bride the feature disparity between these to islands of communications.=20 The current drafts are the first cut at something that is huge, and I am sure there will be many enhancements to make things like switching from an active PSTN call to an Internet SIP call is a matter of SIP route availability and reachability, after the route is learned.=20 Mo A -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Marc Linsner (mlinsner) Sent: Monday, July 19, 2010 9:28 AM To: PFAUTZ, PENN L (ATTCORP) Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 Penn, My interpretation (which stands a good chance of being wrong) of Vipr is that it's designed as an 'end-user' (lessee of the E.164) assertion mechanism, not designed for 'carrier of record' (PSTN SP) assertion. The vulnerabilities of the authentication mechanism will obviously need vetted in a work group setting. -Marc- =20 On 7/19/10 8:50 AM, "PFAUTZ, PENN L (ATTCORP)" wrote: > Marc: > I don't think the concern is about the number assignee advertising the > number, but about being sure that *only* the number assignee, carrier=20 > of record, or other authorized party is advertising the number. >=20 > Penn Pfautz > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of Marc Linsner > Sent: Monday, July 19, 2010 8:38 AM > To: Richard Shockey > Cc: dispatch@ietf.org > Subject: Re: [dispatch] VIPR - proposed charter version 4 >=20 > Richard, >=20 >=20 > On 7/18/10 2:11 PM, "Richard Shockey" wrote: >=20 >>=20 >> For my 547th rant. People want to use phone numbers. >=20 > [ML] My observation is this is a generational issue, it'll solve=20 > itself in due time. :^) >=20 >>=20 >> SIP addressing, for better or worse, is now and forever will be bound > in >> large measure to phone numbers and phone numbers and the PSTN are > controlled >> by service providers. >=20 > [ML] From an end-user perspective, I believe that as long as I pay=20 > *any* SP a monthly fee, the E.164 address belongs to me, in the US I=20 > can move it amongst SPs as I see fit. For this fee, I am allowed to=20 > assert that I own such address and I can advertise that I own it in=20 > any medium I want including yellow pages, business cards, newsprint,=20 > Internet, etc. >=20 > It appears to me that Vipr is simply another medium where I advertise=20 > that I own such E.164 address. >=20 > -Marc- >=20 >=20 >=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 jdrosen@jdrosen.net Mon Jul 19 10:57:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EF753A67EF for ; Mon, 19 Jul 2010 10:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O+Y91onN1ZZy for ; Mon, 19 Jul 2010 10:57:41 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.114.155]) by core3.amsl.com (Postfix) with ESMTP id CFA3F3A67DB for ; Mon, 19 Jul 2010 10:57:40 -0700 (PDT) Received: from pool-173-63-40-38.nwrknj.fios.verizon.net ([173.63.40.38] helo=[192.168.1.8]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Oauas-0004im-42; Mon, 19 Jul 2010 13:57:34 -0400 Message-ID: <4C449224.2000101@jdrosen.net> Date: Mon, 19 Jul 2010 13:57:56 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <4C4326B1.7020408@nostrum.com> <000001cb26a4$a81e4840$f85ad8c0$@us> <4C437B03.6070600@nostrum.com> In-Reply-To: <4C437B03.6070600@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Cc: 'Bernard Aboba' , dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 17:57:42 -0000 Adam, The issue isn't that people type in phone numbers in a dialpad to make calls. No one does that anymore. The issue is that phone numbers are now embedded into the millions (billions?) of address book entries in phones of various sorts. They appear on business cards, and in email signatures, and so on. As such, enabling voip to drive off of phone numbers can substantially reduce the friction for getting to voip. Facetime is just another example of that same concept. -Jonathan R. Adam Roach wrote: > On 7/18/10 13:11, Jul 18, Richard Shockey wrote: >> For my 547th rant. People want to use phone numbers. > > I forgot to mention -- if you're insisting on this as a maxim, then > FaceTime might not be your best poster boy. > > http://www.boygeniusreport.com/2010/07/15/exclusive-apples-facetime-coming-to-ipod-touch-ipad-we-detail-how/ > > > Phone numbers are useful to get to & from the PSTN. > > But, aside from that, they're a disposable relic in today's gadgets. I > mean, really -- when is the last time you mashed 10 (or more) digits > into your phone instead of selecting someone's name out of an address > book? Why would you care what the identifier behind that address book > entry looks like? > > There came a time where calling the operator and asking for "Dallas, > Diamond Exchange, 3-6-5-5-2" became a bit quaint. And then it stopped > working. You really think we'll never bridge the gap away from phone > numbers? > > /a > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From jdrosen@jdrosen.net Mon Jul 19 11:00:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B772F3A67DB for ; Mon, 19 Jul 2010 11:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NCQ4z9Ad6hQ for ; Mon, 19 Jul 2010 11:00:54 -0700 (PDT) Received: from ecbiz71.inmotionhosting.com (ecbiz71.inmotionhosting.com [69.174.114.155]) by core3.amsl.com (Postfix) with ESMTP id 875343A67A1 for ; Mon, 19 Jul 2010 11:00:54 -0700 (PDT) Received: from pool-173-63-40-38.nwrknj.fios.verizon.net ([173.63.40.38] helo=[192.168.1.8]) by ecbiz71.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Oaue0-0007EY-7M; Mon, 19 Jul 2010 14:00:48 -0400 Message-ID: <4C4492E7.8060309@jdrosen.net> Date: Mon, 19 Jul 2010 14:01:11 -0400 From: Jonathan Rosenberg User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <4C4326B1.7020408@nostrum.com> <000001cb26a4$a81e4840$f85ad8c0$@us> <4C4371E3.1090802@nostrum.com> In-Reply-To: <4C4371E3.1090802@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ecbiz71.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jdrosen.net Cc: 'Bernard Aboba' , dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 18:00:55 -0000 Adam touches on a couple of points that are important about how vipr differs from Facetime. Both of them seek to drive voip off of phone numbers, however: 1. ViPR assumes a fully distributed solution, where there is no central authority for mapping numbers to domains 2. ViPR works with any endpoints that can make and receive PSTN calls, not just devices which can send and receive SMS If you remove both of these constraints, much simpler solutions are possible. -Jonathan R. Adam Roach wrote: > On 7/18/10 13:11, Jul 18, Richard Shockey wrote: >> The FaceTime mechanism is rather clever and is certainly one way to solve >> the real problem of the E.164 trust binding in session >> (re)establishment. If >> you can make a PSTN call .. its works. From the user experience >> perspective >> (Apples obsession) its nearly flawless. Apple did a very nice job. If >> Steve >> and company finally decide to publish what they have done they will >> have a >> lot of friends. > > Well, details are a bit sketchy, but preliminary analysis is that the > whole system holds together only because Apple has things set up so that > they retain an iron-gripped control over everything. > > Effectively, it would be like saying "the SIP E.164 number mapping > problem has been solved! Just slap "@apple.com" after any E.164 number > in the world, and you can be sure you're reaching the right person!" > > As far as I can tell, the binding from a phone number to a client cert > (yes, they use mTLS for auth) is performed via some kind of SMS exchange > (as users must have SMS service the first time they use FaceTime, but > not for subsequent calls). My guess is that the phone sends a client > cert fingerprint to Apple, and then Apple trusts that the cert indicated > is 100% certain to correspond to the phone number that the SMS appears > to have come from. > > I agree that it's clever, but it doesn't work unless it's all under the > tight control of a single entity. It also is completely dependent on > being able to send an SMS from the associated E.164 number (which limits > it to mobile phones). > > /a > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Chief Technology Strategist Mobile: +1 (732) 766-2496 Skype SkypeIn: +1 (408) 465-0361 jdrosen@skype.net http://www.skype.com jdrosen@jdrosen.net http://www.jdrosen.net From richard@shockey.us Mon Jul 19 13:27:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FAAC3A6863 for ; Mon, 19 Jul 2010 13:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8wGrUsgUV60 for ; Mon, 19 Jul 2010 13:27:15 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by core3.amsl.com (Postfix) with SMTP id 75CD73A6971 for ; Mon, 19 Jul 2010 13:27:15 -0700 (PDT) Received: (qmail 15903 invoked by uid 0); 19 Jul 2010 19:28:15 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy1.bluehost.com.bluehost.com with SMTP; 19 Jul 2010 19:28:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=jxZVWntNNhvvahpauNY8mDLxo9bVORQC97nA+xzo6UCTTNASrVwEIxQLyJEqXU5SUIQqsQKGxr/4OkYF9IT42tNcym06eiPnKqgWwCOYXR+WadZh2lSnisFeqmJRUd6D; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Oawvx-0003dy-QY; Mon, 19 Jul 2010 14:27:30 -0600 From: "Richard Shockey" To: "'Marc Linsner'" References: <000001cb26a4$a81e4840$f85ad8c0$@us> In-Reply-To: Date: Mon, 19 Jul 2010 16:27:28 -0400 Message-ID: <007a01cb2780$cf1be4c0$6d53ae40$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acsmk0zBKxXnrSQLSG2bqd2KJq9HNQADgfygACd3ZVEAEBgcEA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 20:27:16 -0000 On 7/18/10 2:11 PM, "Richard Shockey" wrote: > > For my 547th rant. People want to use phone numbers. [ML] My observation is this is a generational issue, it'll solve itself in due time. :^) Yea right. I've heard this argument for the last 10 years around the IETF and I'm sure I'll hear it for at least another 10. > > SIP addressing, for better or worse, is now and forever will be bound in > large measure to phone numbers and phone numbers and the PSTN are controlled > by service providers. [ML] From an end-user perspective, I believe that as long as I pay *any* SP a monthly fee, the E.164 address belongs to me, in the US I can move it amongst SPs as I see fit. For this fee, I am allowed to assert that I own such address and I can advertise that I own it in any medium I want including yellow pages, business cards, newsprint, Internet, etc. well no actually ..first E.164 numbers are not property and never have been and by international treaty they cannot be "owned" as such. Plus if you move out of a designated rate center in the US and in most jurisdictions your rights to a number vanish in the case of land lines and in mobile if you move and then change a carrier. In the US 7% of the population moves out of a designated rate center every year. It appears to me that Vipr is simply another medium where I advertise that I own such E.164 address. You "own" nothing and if you don't like it there is a little building in DC called the Portals that you can send a petition to. :-) -Marc- From richard@shockey.us Mon Jul 19 13:44:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B7973A6957 for ; Mon, 19 Jul 2010 13:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ej+w9v-8wmvT for ; Mon, 19 Jul 2010 13:43:59 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id EA8CB3A6809 for ; Mon, 19 Jul 2010 13:43:58 -0700 (PDT) Received: (qmail 14118 invoked by uid 0); 19 Jul 2010 20:44:13 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 19 Jul 2010 20:44:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=WtNhWPyiEWJLtQ50untK2bxgrW9fE7nB9IRHr6fP5SIcsG3YWsR+8pjID5lwgF+UsnwUOxgt7TmJ2WDoEAn7Qj2J1BvOW2kSHCbv3bXtpN1up0bR3hMp+MRmjwphH1yq; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OaxC9-0005Hc-B1; Mon, 19 Jul 2010 14:44:13 -0600 From: "Richard Shockey" To: "'Adam Roach'" References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <4C4326B1.7020408@nostrum.com> <000001cb26a4$a81e4840$f85ad8c0$@us> <4C437B03.6070600@nostrum.com> In-Reply-To: <4C437B03.6070600@nostrum.com> Date: Mon, 19 Jul 2010 16:44:11 -0400 Message-ID: <007b01cb2783$25391c90$6fab55b0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsmxaZCa4TQw0plRYa3j7aoAjI+bwAu6CgQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'Bernard Aboba' , dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 20:44:00 -0000 But, aside from that, they're a disposable relic in today's gadgets. I mean, really -- when is the last time you mashed 10 (or more) digits into your phone instead of selecting someone's name out of an address book? Yesterday as a matter of fact when I wanted to try a new pizza delivery shop and the day before yesterday when I wanted to schedule an appointment for a bid on some house painting. Why would you care what the identifier behind that address book entry looks like? There came a time where calling the operator and asking for "Dallas, Diamond Exchange, 3-6-5-5-2" became a bit quaint. And then it stopped working. You really think we'll never bridge the gap away from phone numbers? If empirical evidence is any guide, not in my lifetime. :-) Phone numbers are useful, easy to remember, linguistically neutral ( a big plus ) and have a internationally sanctioned trust system surrounding them that has worked for almost a century. And the growth in mobile phones numbers is pretty explosive in developing countries. We all hate fax too but that is not going away anytime soon either, contrary to the desire of most of the RAI community. Sure I don't manually dial a pad every time but certainly the first time when I enter the number. And since there are studies that most of us never call more than 25 people regularly that would support your thesis somewhat. /a From pkyzivat@cisco.com Mon Jul 19 13:50:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 981C33A687C for ; Mon, 19 Jul 2010 13:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8LldCaBD+8U for ; Mon, 19 Jul 2010 13:50:41 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 43FF93A659C for ; Mon, 19 Jul 2010 13:50:41 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,228,1278288000"; d="scan'208";a="134352447" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Jul 2010 20:50:55 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6JKotY4002046; Mon, 19 Jul 2010 20:50:55 GMT Message-ID: <4C44BAAF.7030202@cisco.com> Date: Mon, 19 Jul 2010 16:50:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Richard Shockey References: <000001cb26a4$a81e4840$f85ad8c0$@us> <007a01cb2780$cf1be4c0$6d53ae40$@us> In-Reply-To: <007a01cb2780$cf1be4c0$6d53ae40$@us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 20:50:42 -0000 Richard Shockey wrote: > > > On 7/18/10 2:11 PM, "Richard Shockey" wrote: > >> For my 547th rant. People want to use phone numbers. > > [ML] My observation is this is a generational issue, it'll solve itself in > due time. :^) > > > Yea right. I've heard this argument for the last 10 years around the > IETF and I'm sure I'll hear it for at least another 10. You will hear it until *your* generation retires. :-) Paul From rbarnes@bbn.com Mon Jul 19 13:59:23 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E74F33A6818 for ; Mon, 19 Jul 2010 13:59:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUimq8Ycm3xY for ; Mon, 19 Jul 2010 13:59:23 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E19B63A659C for ; Mon, 19 Jul 2010 13:59:22 -0700 (PDT) Received: from [192.1.255.159] (port=54628 helo=col-dhcp-192-1-255-159.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OaxR2-000CkU-O0; Mon, 19 Jul 2010 16:59:36 -0400 Message-Id: <8DC79B7A-582F-438F-818D-A1DAEE14D633@bbn.com> From: "Richard L. Barnes" To: "Richard Shockey" In-Reply-To: <007b01cb2783$25391c90$6fab55b0$@us> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Jul 2010 16:59:35 -0400 References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <4C4326B1.7020408@nostrum.com> <000001cb26a4$a81e4840$f85ad8c0$@us> <4C437B03.6070600@nostrum.com> <007b01cb2783$25391c90$6fab55b0$@us> X-Mailer: Apple Mail (2.936) Cc: 'Bernard Aboba' , dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 20:59:24 -0000 I'll grant that E.164 numbering has a widely-accepted trust system (although, if you didn't trust it, what alternative do you have?), but seems kind of irrelevant to the question at hand, namely, how to route SIP calls to the proper destination for an E.164 number. Clearly, the entities comprising that system haven't taken up the idea directly, as witnessed, e.g., by the failure of ENUM. Since those entities aren't collectively solving the problem (AFAIK), there's a need for an "out-of-band" solution. Which would seem to be the point of VIPR -- to use this thing that is already trusted to discover destinations for PSTN calls to also discover destinations for IP calls? (Without relying on support from the internals of the system itself.) On Jul 19, 2010, at 4:44 PM, Richard Shockey wrote: > > > But, aside from that, they're a disposable relic in today's gadgets. I > mean, really -- when is the last time you mashed 10 (or more) digits > into your phone instead of selecting someone's name out of an address > book? > > Yesterday as a matter of fact when I wanted to try a new pizza > delivery > shop and the day before yesterday when I wanted to schedule an > appointment > for a bid on some house painting. > > Why would you care what the identifier behind that address book > entry looks like? > > There came a time where calling the operator and asking for "Dallas, > Diamond Exchange, 3-6-5-5-2" became a bit quaint. And then it stopped > working. You really think we'll never bridge the gap away from phone > numbers? > > > If empirical evidence is any guide, not in my lifetime. :-) Phone > numbers are useful, easy to remember, linguistically neutral ( a big > plus ) > and have a internationally sanctioned trust system surrounding them > that has > worked for almost a century. And the growth in mobile phones numbers > is > pretty explosive in developing countries. We all hate fax too but > that is > not going away anytime soon either, contrary to the desire of most > of the > RAI community. > > Sure I don't manually dial a pad every time but certainly the first > time > when I enter the number. And since there are studies that most of us > never > call more than 25 people regularly that would support your thesis > somewhat. > > /a > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From richard@shockey.us Mon Jul 19 16:21:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07A523A6947 for ; Mon, 19 Jul 2010 16:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zye2O-lHhANh for ; Mon, 19 Jul 2010 16:21:06 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id A41C93A6B8E for ; Mon, 19 Jul 2010 16:21:06 -0700 (PDT) Received: (qmail 27808 invoked by uid 0); 19 Jul 2010 23:21:21 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 19 Jul 2010 23:21:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=ftc4DF/ZYycPp5Pxmj+1giZ/yMT1eEGqigRmFLTQyitvRmCCW2qWjakgSU/v9D3shrt6e7/jub5EZwnupXFTq+oXX+LyCYPidXPYJC8CgdN/o94R9oRVyuFjHx+lvOmU; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OazeD-0008N8-8p; Mon, 19 Jul 2010 17:21:21 -0600 From: "Richard Shockey" To: "'Richard L. Barnes'" References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <4C4326B1.7020408@nostrum.com> <000001cb26a4$a81e4840$f85ad8c0$@us> <4C437B03.6070600@nostrum.com> <007b01cb2783$25391c90$6fab55b0$@us> <8DC79B7A-582F-438F-818D-A1DAEE14D633@bbn.com> In-Reply-To: <8DC79B7A-582F-438F-818D-A1DAEE14D633@bbn.com> Date: Mon, 19 Jul 2010 19:21:19 -0400 Message-ID: <00a901cb2799$18af6ae0$4a0e40a0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsnhVFmdSCFe6JdRPKDx6lC3FLfMAADmgOg Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Cc: 'Bernard Aboba' , dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 23:21:08 -0000 Well since you want to keep the thread alive. :-) ENUM in e164.arpa has had its "challenges" for sure but to say RFC 3761 is a failure is simply not correct. As a number translation mechanism to replace SS7/TCAP in closed carrier IP SIP networks it works extremely well and is globally deployed. You just can't directly access those databases. That is your problem. You say ENUM is a failure, well email style SIP addressing for consumers or businesses is a total failure and no one in RAI will admit to that. SIP addressing is only relevant to internal SSP operations or PBX systems. The consumer doesn't know or care they phone numbers are still on 100% of business cards. Carriers, for some strange reason, do not like being bit pushers and are justifiably concerned about their major cash cow, voice/SMS using e164 addressing. So the problem here is everyone hates the PSTN and E.164 addressing but you propose to use exactly those mechanisms to facilitate toll bypass. Fine. I just want that understood. I'm a firm believer is "truth in WG charters". The economics of toll bypass is a business model issue which is not our collective concern but it needs to be clearly stated that this is the central proposition of this proposed WG as you propose it. I certainly agree that our global service provider friends have not been as responsive as they could be to new service delivery using E.164 addressing and I'm not going to even attempt to justify their behavior, though I will certainly grant they have had issues with CAPEX in recent years that has made it difficult to justify replacement of the outdated signaling mechanisms in their networks. I have never doubted for a moment that this WG will probably get chartered in some form or another. In fact I hope it does if for no other reason that perhaps our carrier friends will finally get off their collective posteriors and finally confront the reality that if they want to avoid being bit pushers they need to finally confront the underlying need for both new service delivery using E.164 addressing (FaceTime ?) and a reliable and truly trusted global number translation mechanism internal to their networks ..and that BTW won't be VIPR. -----Original Message----- From: Richard L. Barnes [mailto:rbarnes@bbn.com] Sent: Monday, July 19, 2010 5:00 PM To: Richard Shockey Cc: 'Adam Roach'; 'Bernard Aboba'; dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 I'll grant that E.164 numbering has a widely-accepted trust system (although, if you didn't trust it, what alternative do you have?), but seems kind of irrelevant to the question at hand, namely, how to route SIP calls to the proper destination for an E.164 number. Clearly, the entities comprising that system haven't taken up the idea directly, as witnessed, e.g., by the failure of ENUM. Since those entities aren't collectively solving the problem (AFAIK), there's a need for an "out-of-band" solution. Which would seem to be the point of VIPR -- to use this thing that is already trusted to discover destinations for PSTN calls to also discover destinations for IP calls? (Without relying on support from the internals of the system itself.) On Jul 19, 2010, at 4:44 PM, Richard Shockey wrote: > > > But, aside from that, they're a disposable relic in today's gadgets. I > mean, really -- when is the last time you mashed 10 (or more) digits > into your phone instead of selecting someone's name out of an address > book? > > Yesterday as a matter of fact when I wanted to try a new pizza > delivery > shop and the day before yesterday when I wanted to schedule an > appointment > for a bid on some house painting. > > Why would you care what the identifier behind that address book > entry looks like? > > There came a time where calling the operator and asking for "Dallas, > Diamond Exchange, 3-6-5-5-2" became a bit quaint. And then it stopped > working. You really think we'll never bridge the gap away from phone > numbers? > > > If empirical evidence is any guide, not in my lifetime. :-) Phone > numbers are useful, easy to remember, linguistically neutral ( a big > plus ) > and have a internationally sanctioned trust system surrounding them > that has > worked for almost a century. And the growth in mobile phones numbers > is > pretty explosive in developing countries. We all hate fax too but > that is > not going away anytime soon either, contrary to the desire of most > of the > RAI community. > > Sure I don't manually dial a pad every time but certainly the first > time > when I enter the number. And since there are studies that most of us > never > call more than 25 people regularly that would support your thesis > somewhat. > > /a > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@cisco.com Mon Jul 19 20:02:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46B603A6A0A for ; Mon, 19 Jul 2010 20:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.451 X-Spam-Level: X-Spam-Status: No, score=-110.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id waBcH3g4+Xbc for ; Mon, 19 Jul 2010 20:02:02 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id A61103A69B3 for ; Mon, 19 Jul 2010 20:02:02 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN+tREyrR7Ht/2dsb2JhbACfbnGoAZs1hSIEg3+EVw Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 20 Jul 2010 03:02:17 +0000 Received: from [10.21.78.23] ([10.21.78.23]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6K32HX7016946; Tue, 20 Jul 2010 03:02:17 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Mon, 19 Jul 2010 20:02:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <41CB5CBD-B800-4D6B-8659-AB119208F135@cisco.com> References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> , To: Bernard Aboba X-Mailer: Apple Mail (2.1081) Cc: dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 03:02:05 -0000 On Jul 18, 2010, at 13:23 , Bernard Aboba wrote: > > a. One problem is the need to be able to "upgrade" an audio call in = progress in order to provide for additional media, even if the call had = been completed=20 > > over the PSTN so that there was no SDP offer/answer negotiation = between the end-points. This is the problem that Facetime solves, for = example.=20 > =20 > Cullen Jennings said: >=20 > "Bernard, obviously a large percentage of the work done in RAI is to = allow rich communications over the internet and for the most part the = existing work today from AVT, MMUSIC, SIP and so on already solves your = point (a)" >=20 > [BA] Problem a) was about upgrading of calls made over the PSTN, not = the Internet. Are you suggesting that SIP, SDP, etc. already provides a = standardized way to do *that*?=20 >=20 sorry - I did not mean to claim that - I imagine we both agree there is = not a standardized way to upgrade a PSTN call to an internet call > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From peter.musgrave@magorcorp.com Tue Jul 20 03:18:40 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0552D3A68D9 for ; Tue, 20 Jul 2010 03:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.329 X-Spam-Level: X-Spam-Status: No, score=-1.329 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05HG5MJjh-Bz for ; Tue, 20 Jul 2010 03:18:39 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 1C6783A69DF for ; Tue, 20 Jul 2010 03:18:39 -0700 (PDT) Received: by vws13 with SMTP id 13so331812vws.31 for ; Tue, 20 Jul 2010 03:18:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.49.66 with SMTP id u2mr5466477qaf.250.1279621133534; Tue, 20 Jul 2010 03:18:53 -0700 (PDT) Received: by 10.229.20.198 with HTTP; Tue, 20 Jul 2010 03:18:53 -0700 (PDT) Date: Tue, 20 Jul 2010 06:18:53 -0400 Message-ID: From: Peter Musgrave To: Hadriel Kaplan , dispatch mailing list Content-Type: multipart/alternative; boundary=001485e98b361c9872048bcf0315 Subject: Re: [dispatch] draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 10:18:40 -0000 --001485e98b361c9872048bcf0315 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Hadriel, Overall I think the draft is in good shape. I think the work is useful (in fact it's already in my code). I have an observation about 5.3 Let me restate the example: Bob calls Alice (sessionID=3DAB) Bob calls Charlie (sessionID=3DBC) Bob REFERs Alice to Charlie (ReferTo: sessionID=3DBC) >From Alice's perspective the call to C is a continuation of the call to B - so I would have expected sessionID=3DAB for the new call. (From C's perspective it get s a new INVITE which replaces a previous one - but this is not as strong a connection in my mind as the call coupling at A). I think using the AB session ID in the Refer may have more value in following a REFER chain. 8 Examples: I think a REFER example would be valuable. Both a Refer-To URI example and an INVITE with Replaces example which makes concrete the case in 5.3. Nits: (Abstract) s/Troubleshooting/troubleshooting/ 3. I prefer "dialog-creating" to "out-of-dialog" (but I can live with out-of-dialog) Now to go and sip some Scotch=85. Peter Musgrave --001485e98b361c9872048bcf0315 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi Had= riel,=A0


Overal= l I think the draft is in good shape.=A0


I thin= k the work is useful (in fact it's already in my code).=A0


I have= an observation about 5.3

Let me= restate the example:

Bob ca= lls Alice (sessionID=3DAB)

Bob ca= lls Charlie (sessionID=3DBC)

Bob RE= FERs Alice to Charlie (ReferTo: sessionID=3DBC)


From A= lice's perspective the call to C is a continuation of the call to B - s= o I would have expected sessionID=3DAB for the new call. (From C's pers= pective it get s a new INVITE which replaces a previous one - but this is n= ot as strong a connection in my mind as the call coupling at A).=A0


I thin= k using the AB session ID in the Refer may have more value in following a R= EFER chain.=A0


8 Exam= ples:

I thin= k a REFER example would be valuable. Both a Refer-To URI example and an INV= ITE with Replaces example which makes concrete the case in 5.3.=A0


Nits:<= /p>

(Abstr= act) s/Troubleshooting/troubleshooting/

3. I p= refer "dialog-creating" to "out-of-dialog" (but I can l= ive with out-of-dialog)


Now to= go and sip some Scotch=85.


Peter = Musgrave


--001485e98b361c9872048bcf0315-- From ranjit@motorola.com Tue Jul 20 03:40:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3DCE3A6C47 for ; Tue, 20 Jul 2010 03:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYNXhmNMh1Yc for ; Tue, 20 Jul 2010 03:40:01 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 672073A68A0 for ; Tue, 20 Jul 2010 03:40:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-4.tower-128.messagelabs.com!1279622411!33649735!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 15638 invoked from network); 20 Jul 2010 10:40:12 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-4.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 20 Jul 2010 10:40:12 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o6KAeBgV027316 for ; Tue, 20 Jul 2010 03:40:11 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id o6KAeAhT008922 for ; Tue, 20 Jul 2010 05:40:10 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id o6KAe9w7008916 for ; Tue, 20 Jul 2010 05:40:10 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 18:39:47 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A855531@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A854F03@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] draft-avasarala-dispatch-comm-div-notification-05 Thread-Index: AcskMkYtga8xd6LZRcGIK0UWLSCPMAAFIQYgAOxDIvA= References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> <4BF53641.3070105@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> <4BF5563F.8090508@cisco.com> <4BF56106.4010806@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A554ADB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A854E68@ZMY16EXM66.ds.mot.com><4C3F28E2.3000102@nostrum.com> <750BBC72E178114F9DC4872EBFF29A5B0A854F03@ZMY16EXM66.ds.mot.com> From: "Avasarala Ranjit-A20990" To: "Avasarala Ranjit-A20990" , "Adam Roach" X-CFilter-Loop: Reflected Cc: DISPATCH Subject: Re: [dispatch] draft-avasarala-dispatch-comm-div-notification-05 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 10:40:05 -0000 Hi all Any comments??=20 Regards Ranjit -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala Ranjit-A20990 Sent: Thursday, July 15, 2010 11:41 PM To: Adam Roach Cc: DISPATCH Subject: Re: [dispatch] draft-avasarala-dispatch-comm-div-notification-05 Hi Adam No Adam we have not jumped into Stage 3 without stage 1 analysis. In Stage 1 spec 22.173 Section 8.2.7.2 Communication Diversion Notification Enhancements talks of specific enhancements required for the Communication Diversion Notification and lists the parameters that could be part of the notification information. It also further talks about the trigger for initiating communication diversion notification information messages towards the subscriber. It finally lists all the elements that can be part of the Communication Diversion Notification Information. =20 So the section 8.2.7.2 of 22.173 should qualify to mention "what" we are trying to accomplish and the spec 24.604 describes the CDIVN service in detail and also proposes the required XML schema for the CDIVN XML package.=20 So as mentioned in section 8.2.7.1, the problem is a need for a mechanism for the subscribers to be notified of communication diversions. So in addition to the regular CFX services, as a service provider option, the subscribers are also provided with an option to subscribe to communication diversion notification service that will help them to receive notifications of their call diversions. Thanks Regards Ranjit -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com] Sent: Thursday, July 15, 2010 8:58 PM To: Avasarala Ranjit-A20990 Cc: Mary Barnes; DISPATCH Subject: Re: [dispatch] FW: New Version Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 On 7/15/10 5:36 AM, Avasarala Ranjit-A20990 wrote: > After further thought, we feel that since the CDIV service is already standardized in 3GPP specifications 24.604 (Section 4.10.1.1) and hence there is no need for explicitly stating the requirements of a CDIV service again in a separate I-D or document. The problem is that section 4.10.1.1 of 24.604 isn't a statement of requirements. It's a high-level sketch of a solution to an unstated set of requirements. And section 4.10.2 of that same document is presumptuous enough to even define an XML Schema for use in this solution. In 3GPP language, you've jumped into stage 2 and stage 3 design without the stage 1 analysis. In the past, what has worked well for extensions to IETF protocols is when 3GPP does the stage 1 work, and then collaborates with the IETF to define a solution that satisfies both parties. I agree with John, Paul, and Mary -- if this work is to proceed, it really needs to back up to base principles: *what* are you trying to accomplish, not *how* do you want to accomplish it? The distinction is that the answer is to "what are you trying to accomplish" is phrased in terms of use cases ("a user receives real-time information about the calls he has missed"), not behavior ("the reason for diversion is delivered in a element"). > Also regarding any existing mechanisms, we feel there is/are no=20 > existing mechansim(s) for getting notifications of a particular call=20 > diversion service for a particular subscriber I think you misread John's proposal. He didn't ask for you to consider other existing solutions -- he asked you to talk about the potential solution space. Some of the feedback you've already received covers some of this space (e.g. information is published using HTTP, and users discover changes using draft-roach-sip-http-subscribe). > Now as per 3GPP's directive, we need to formally standardize the event package in IETF and hence the draft. If you want people to help you work on your event package -- as that is presumably why you're bringing it to DISPATCH -- then you need to bring us a problem to work on, not a complete solution to publish. > So please let us know how we can take this draft forward to a meaningful conclusion. I think you've been told several times already. What I'm inferring from your asking again is that you don't like the answer. I'm afraid there's not much that can be done about that. /a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From john.elwell@siemens-enterprise.com Tue Jul 20 05:38:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367583A67B3 for ; Tue, 20 Jul 2010 05:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.144 X-Spam-Level: X-Spam-Status: No, score=-2.144 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaXU-eTB3pYc for ; Tue, 20 Jul 2010 05:38:12 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id C56393A68F1 for ; Tue, 20 Jul 2010 05:37:51 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-907173; Tue, 20 Jul 2010 14:38:05 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 97C2623F028E; Tue, 20 Jul 2010 14:38:05 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 20 Jul 2010 14:38:05 +0200 From: "Elwell, John" To: Peter Musgrave , Hadriel Kaplan , dispatch mailing list Date: Tue, 20 Jul 2010 14:38:04 +0200 Thread-Topic: [dispatch] draft-kaplan-dispatch-session-id-02 Thread-Index: Acsn9PitydhklCxmTuyEViZu9zv/6AAEo8BQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 12:38:13 -0000 Peter, But what if we use Join rather than Replaces, to join rather than replace s= ession BC? There is certainly a strong argument that Alice's leg would be p= art of session ID BC, rather than AB, in this case. Any opinions whether we= should treat Join and Replaces the same or differently? John =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Musgrave > Sent: 20 July 2010 11:19 > To: Hadriel Kaplan; dispatch mailing list > Subject: Re: [dispatch] draft-kaplan-dispatch-session-id-02 >=20 > Hi Hadriel,=20 >=20 >=20 >=20 >=20 > Overall I think the draft is in good shape.=20 >=20 >=20 >=20 >=20 > I think the work is useful (in fact it's already in my code).=20 >=20 >=20 >=20 >=20 > I have an observation about 5.3 >=20 > Let me restate the example: >=20 > Bob calls Alice (sessionID=3DAB) >=20 > Bob calls Charlie (sessionID=3DBC) >=20 > Bob REFERs Alice to Charlie (ReferTo: sessionID=3DBC) >=20 >=20 >=20 >=20 > From Alice's perspective the call to C is a continuation of=20 > the call to B - so I would have expected sessionID=3DAB for the=20 > new call. (From C's perspective it get s a new INVITE which=20 > replaces a previous one - but this is not as strong a=20 > connection in my mind as the call coupling at A).=20 >=20 >=20 >=20 >=20 > I think using the AB session ID in the Refer may have more=20 > value in following a REFER chain.=20 >=20 >=20 >=20 >=20 > 8 Examples: >=20 > I think a REFER example would be valuable. Both a Refer-To=20 > URI example and an INVITE with Replaces example which makes=20 > concrete the case in 5.3.=20 >=20 >=20 >=20 >=20 > Nits: >=20 > (Abstract) s/Troubleshooting/troubleshooting/ >=20 > 3. I prefer "dialog-creating" to "out-of-dialog" (but I can=20 > live with out-of-dialog) >=20 >=20 >=20 >=20 > Now to go and sip some Scotch.... >=20 >=20 >=20 >=20 > Peter Musgrave >=20 >=20 >=20 >=20 > = From john.elwell@siemens-enterprise.com Tue Jul 20 05:53:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB7363A67F4 for ; Tue, 20 Jul 2010 05:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwsxjuvTzeGZ for ; Tue, 20 Jul 2010 05:53:49 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5830B3A6BE6 for ; Tue, 20 Jul 2010 05:53:49 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-907469; Tue, 20 Jul 2010 14:54:03 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id B24A51EB82AB; Tue, 20 Jul 2010 14:54:03 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 20 Jul 2010 14:54:03 +0200 From: "Elwell, John" To: Avasarala Ranjit-A20990 , Adam Roach Date: Tue, 20 Jul 2010 14:54:02 +0200 Thread-Topic: [dispatch] draft-avasarala-dispatch-comm-div-notification-05 Thread-Index: AcskMkYtga8xd6LZRcGIK0UWLSCPMAAFIQYgAOxDIvAABGU4AA== Message-ID: References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> <4BF53641.3070105@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> <4BF5563F.8090508@cisco.com> <4BF56106.4010806@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A554ADB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A854E68@ZMY16EXM66.ds.mot.com><4C3F28E2.3000102@nostrum.com> <750BBC72E178114F9DC4872EBFF29A5B0A854F03@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A855531@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A855531@ZMY16EXM66.ds.mot.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: DISPATCH Subject: Re: [dispatch] draft-avasarala-dispatch-comm-div-notification-05 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 12:53:51 -0000 Ranjit, It would help if the requirements were contributed to the IETF in the usual= manner. However, I managed to locate the section you referenced, and it se= ems that a specific SIP event package is not the only way that these requir= ements could be satisfied. The IETF needs to understand the requirements an= d determine what is the best solution, bearing in mind that others, not jus= t 3GPP, may find a solution to these requirements of value. John > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Avasarala=20 > Ranjit-A20990 > Sent: 20 July 2010 11:40 > To: Avasarala Ranjit-A20990; Adam Roach > Cc: DISPATCH > Subject: Re: [dispatch]=20 > draft-avasarala-dispatch-comm-div-notification-05 >=20 > Hi all >=20 > Any comments??=20 >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Avasarala Ranjit-A20990 > Sent: Thursday, July 15, 2010 11:41 PM > To: Adam Roach > Cc: DISPATCH > Subject: Re: [dispatch] > draft-avasarala-dispatch-comm-div-notification-05 >=20 > Hi Adam >=20 > No Adam we have not jumped into Stage 3 without stage 1 analysis. In > Stage 1 spec 22.173 Section 8.2.7.2 Communication Diversion=20 > Notification > Enhancements talks of specific enhancements required for the > Communication Diversion Notification and lists the parameters=20 > that could > be part of the notification information. It also further=20 > talks about the > trigger for initiating communication diversion notification=20 > information > messages towards the subscriber. It finally lists all the=20 > elements that > can be part of the Communication Diversion Notification Information. =20 >=20 > So the section 8.2.7.2 of 22.173 should qualify to mention=20 > "what" we are > trying to accomplish and the spec 24.604 describes the CDIVN=20 > service in > detail and also proposes the required XML schema for the CDIVN XML > package.=20 >=20 > So as mentioned in section 8.2.7.1, the problem is a need for a > mechanism for the subscribers to be notified of communication > diversions. So in addition to the regular CFX services, as a service > provider option, the subscribers are also provided with an option to > subscribe to communication diversion notification service=20 > that will help > them to receive notifications of their call diversions. >=20 > Thanks >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, July 15, 2010 8:58 PM > To: Avasarala Ranjit-A20990 > Cc: Mary Barnes; DISPATCH > Subject: Re: [dispatch] FW: New Version > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 >=20 >=20 > On 7/15/10 5:36 AM, Avasarala Ranjit-A20990 wrote: > > After further thought, we feel that since the CDIV service=20 > is already > standardized in 3GPP specifications 24.604 (Section 4.10.1.1)=20 > and hence > there is no need for explicitly stating the requirements of a CDIV > service again in a separate I-D or document. >=20 > The problem is that section 4.10.1.1 of 24.604 isn't a statement of > requirements. It's a high-level sketch of a solution to an=20 > unstated set > of requirements. And section 4.10.2 of that same document is > presumptuous enough to even define an XML Schema for use in this > solution. >=20 > In 3GPP language, you've jumped into stage 2 and stage 3=20 > design without > the stage 1 analysis. >=20 > In the past, what has worked well for extensions to IETF protocols is > when 3GPP does the stage 1 work, and then collaborates with=20 > the IETF to > define a solution that satisfies both parties. >=20 > I agree with John, Paul, and Mary -- if this work is to proceed, it > really needs to back up to base principles: *what* are you trying to > accomplish, not *how* do you want to accomplish it? The distinction is > that the answer is to "what are you trying to accomplish" is=20 > phrased in > terms of use cases ("a user receives real-time information about the > calls he has missed"), not behavior ("the reason for diversion is > delivered in a element"). >=20 > > Also regarding any existing mechanisms, we feel there is/are no=20 > > existing mechansim(s) for getting notifications of a=20 > particular call=20 > > diversion service for a particular subscriber >=20 > I think you misread John's proposal. He didn't ask for you to consider > other existing solutions -- he asked you to talk about the potential > solution space. Some of the feedback you've already received=20 > covers some > of this space (e.g. information is published using HTTP, and users > discover changes using draft-roach-sip-http-subscribe). >=20 > > Now as per 3GPP's directive, we need to formally=20 > standardize the event > package in IETF and hence the draft. >=20 > If you want people to help you work on your event package --=20 > as that is > presumably why you're bringing it to DISPATCH -- then you=20 > need to bring > us a problem to work on, not a complete solution to publish. >=20 > > So please let us know how we can take this draft forward to a > meaningful conclusion. >=20 > I think you've been told several times already. What I'm=20 > inferring from > your asking again is that you don't like the answer. I'm=20 > afraid there's > not much that can be done about that. >=20 > /a > _______________________________________________ > 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@cisco.com Tue Jul 20 06:03:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BB243A6AFF for ; Tue, 20 Jul 2010 06:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.497 X-Spam-Level: X-Spam-Status: No, score=-10.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQWRiTw1o7h9 for ; Tue, 20 Jul 2010 06:03:37 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3BAD53A6BC7 for ; Tue, 20 Jul 2010 06:03:35 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGQ7RUyrRN+K/2dsb2JhbACfb3GlF5srhTIEiFk Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 13:03:48 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6KD3mic002416; Tue, 20 Jul 2010 13:03:48 GMT Message-ID: <4C459EB4.3070703@cisco.com> Date: Tue, 20 Jul 2010 09:03:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> <4BF53641.3070105@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> <4BF5563F.8090508@cisco.com> <4BF56106.4010806@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A554ADB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A854E68@ZMY16EXM66.ds.mot.com><4C3F28E2.3000102@nostrum.com> <750BBC72E178114F9DC4872EBFF29A5B0A854F03@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A855531@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A855531@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH Subject: Re: [dispatch] draft-avasarala-dispatch-comm-div-notification-05 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 13:03:41 -0000 I've already said my piece more than once. I've nothing new to say. Thanks, Paul Avasarala Ranjit-A20990 wrote: > Hi all > > Any comments?? > > > Regards > Ranjit > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Avasarala Ranjit-A20990 > Sent: Thursday, July 15, 2010 11:41 PM > To: Adam Roach > Cc: DISPATCH > Subject: Re: [dispatch] > draft-avasarala-dispatch-comm-div-notification-05 > > Hi Adam > > No Adam we have not jumped into Stage 3 without stage 1 analysis. In > Stage 1 spec 22.173 Section 8.2.7.2 Communication Diversion Notification > Enhancements talks of specific enhancements required for the > Communication Diversion Notification and lists the parameters that could > be part of the notification information. It also further talks about the > trigger for initiating communication diversion notification information > messages towards the subscriber. It finally lists all the elements that > can be part of the Communication Diversion Notification Information. > > So the section 8.2.7.2 of 22.173 should qualify to mention "what" we are > trying to accomplish and the spec 24.604 describes the CDIVN service in > detail and also proposes the required XML schema for the CDIVN XML > package. > > So as mentioned in section 8.2.7.1, the problem is a need for a > mechanism for the subscribers to be notified of communication > diversions. So in addition to the regular CFX services, as a service > provider option, the subscribers are also provided with an option to > subscribe to communication diversion notification service that will help > them to receive notifications of their call diversions. > > Thanks > > Regards > Ranjit > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, July 15, 2010 8:58 PM > To: Avasarala Ranjit-A20990 > Cc: Mary Barnes; DISPATCH > Subject: Re: [dispatch] FW: New Version > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 > > > On 7/15/10 5:36 AM, Avasarala Ranjit-A20990 wrote: >> After further thought, we feel that since the CDIV service is already > standardized in 3GPP specifications 24.604 (Section 4.10.1.1) and hence > there is no need for explicitly stating the requirements of a CDIV > service again in a separate I-D or document. > > The problem is that section 4.10.1.1 of 24.604 isn't a statement of > requirements. It's a high-level sketch of a solution to an unstated set > of requirements. And section 4.10.2 of that same document is > presumptuous enough to even define an XML Schema for use in this > solution. > > In 3GPP language, you've jumped into stage 2 and stage 3 design without > the stage 1 analysis. > > In the past, what has worked well for extensions to IETF protocols is > when 3GPP does the stage 1 work, and then collaborates with the IETF to > define a solution that satisfies both parties. > > I agree with John, Paul, and Mary -- if this work is to proceed, it > really needs to back up to base principles: *what* are you trying to > accomplish, not *how* do you want to accomplish it? The distinction is > that the answer is to "what are you trying to accomplish" is phrased in > terms of use cases ("a user receives real-time information about the > calls he has missed"), not behavior ("the reason for diversion is > delivered in a element"). > >> Also regarding any existing mechanisms, we feel there is/are no >> existing mechansim(s) for getting notifications of a particular call >> diversion service for a particular subscriber > > I think you misread John's proposal. He didn't ask for you to consider > other existing solutions -- he asked you to talk about the potential > solution space. Some of the feedback you've already received covers some > of this space (e.g. information is published using HTTP, and users > discover changes using draft-roach-sip-http-subscribe). > >> Now as per 3GPP's directive, we need to formally standardize the event > package in IETF and hence the draft. > > If you want people to help you work on your event package -- as that is > presumably why you're bringing it to DISPATCH -- then you need to bring > us a problem to work on, not a complete solution to publish. > >> So please let us know how we can take this draft forward to a > meaningful conclusion. > > I think you've been told several times already. What I'm inferring from > your asking again is that you don't like the answer. I'm afraid there's > not much that can be done about that. > > /a > _______________________________________________ > 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.musgrave@magorcorp.com Tue Jul 20 06:15:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA2F3A6A03 for ; Tue, 20 Jul 2010 06:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.032 X-Spam-Level: X-Spam-Status: No, score=-1.032 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKHWVPEHZL5P for ; Tue, 20 Jul 2010 06:15:32 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id 76BBE3A6A47 for ; Tue, 20 Jul 2010 06:15:32 -0700 (PDT) Received: by pzk6 with SMTP id 6so2652283pzk.31 for ; Tue, 20 Jul 2010 06:15:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.233.10 with SMTP id f10mr9373205wfh.280.1279631747523; Tue, 20 Jul 2010 06:15:47 -0700 (PDT) Received: by 10.229.20.198 with HTTP; Tue, 20 Jul 2010 06:15:47 -0700 (PDT) In-Reply-To: References: Date: Tue, 20 Jul 2010 09:15:47 -0400 Message-ID: From: Peter Musgrave To: "Elwell, John" Content-Type: multipart/alternative; boundary=000e0cd2e054c1258d048bd17ba5 Cc: dispatch mailing list , Hadriel Kaplan Subject: Re: [dispatch] draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 13:15:34 -0000 --000e0cd2e054c1258d048bd17ba5 Content-Type: text/plain; charset=ISO-8859-1 Hi John, Based on quick re-read of RFC3911 I see two cases: 1) a Join in an INVITE generated due to a REFER 2) a Join in an INVITE in which the dialog info is conveyed out-of-band I think in (1) it's to some degree a matter of taste as to which sessionID is preferred. It depends on whether you're following logs at C or A. My opinion is that in the case of Join id=BC makes sense - but for a REFER without a Join I prefer AB. For (2) the session ID should match the dialog info and also presumably has to be conveyed out-of-band. Peter Musgrave On Tue, Jul 20, 2010 at 8:38 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Peter, > > But what if we use Join rather than Replaces, to join rather than replace > session BC? There is certainly a strong argument that Alice's leg would be > part of session ID BC, rather than AB, in this case. Any opinions whether we > should treat Join and Replaces the same or differently? > > John > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org > > [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Musgrave > > Sent: 20 July 2010 11:19 > > To: Hadriel Kaplan; dispatch mailing list > > Subject: Re: [dispatch] draft-kaplan-dispatch-session-id-02 > > > > Hi Hadriel, > > > > > > > > > > Overall I think the draft is in good shape. > > > > > > > > > > I think the work is useful (in fact it's already in my code). > > > > > > > > > > I have an observation about 5.3 > > > > Let me restate the example: > > > > Bob calls Alice (sessionID=AB) > > > > Bob calls Charlie (sessionID=BC) > > > > Bob REFERs Alice to Charlie (ReferTo: sessionID=BC) > > > > > > > > > > From Alice's perspective the call to C is a continuation of > > the call to B - so I would have expected sessionID=AB for the > > new call. (From C's perspective it get s a new INVITE which > > replaces a previous one - but this is not as strong a > > connection in my mind as the call coupling at A). > > > > > > > > > > I think using the AB session ID in the Refer may have more > > value in following a REFER chain. > > > > > > > > > > 8 Examples: > > > > I think a REFER example would be valuable. Both a Refer-To > > URI example and an INVITE with Replaces example which makes > > concrete the case in 5.3. > > > > > > > > > > Nits: > > > > (Abstract) s/Troubleshooting/troubleshooting/ > > > > 3. I prefer "dialog-creating" to "out-of-dialog" (but I can > > live with out-of-dialog) > > > > > > > > > > Now to go and sip some Scotch.... > > > > > > > > > > Peter Musgrave > > > > > > > > > > > --000e0cd2e054c1258d048bd17ba5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi John,=A0

Based on quick re-read of RFC3911 I see two = cases:
1) a Join in an INVITE generated due to a REFER
= 2) a Join in an INVITE in which the dialog info is conveyed out-of-band=A0<= /div>

I think in (1) it's to some degree a matter of tast= e as to which sessionID is preferred. It depends on whether you're foll= owing logs at C or A. My opinion is that in the case of Join id=3DBC makes = sense - but for a REFER without a Join I prefer AB.=A0

For (2) the session ID should match the dialog info and= also presumably has to be conveyed out-of-band.

P= eter Musgrave


On Tue, Jul 20, = 2010 at 8:38 AM, Elwell, John <john.elwell@siemens-enterprise.com> wrote:
Peter,

But what if we use Join rather than Replaces, to join rather than replace s= ession BC? There is certainly a strong argument that Alice's leg would = be part of session ID BC, rather than AB, in this case. Any opinions whethe= r we should treat Join and Replaces the same or differently?

John


> -----Original Message-----
> From: dispatch-bounces@ie= tf.org
> [mailto:dispatch-bounces@= ietf.org] On Behalf Of Peter Musgrave
> Sent: 20 July 2010 11:19
> To: Hadriel Kaplan; dispatch mailing list
> Subject: Re: [dispatch] draft-kaplan-dispatch-session-id-02
>
> Hi Hadriel,
>
>
>
>
> Overall I think the draft is in good shape.
>
>
>
>
> I think the work is useful (in fact it's already in my code).
>
>
>
>
> I have an observation about 5.3
>
> Let me restate the example:
>
> Bob calls Alice (sessionID=3DAB)
>
> Bob calls Charlie (sessionID=3DBC)
>
> Bob REFERs Alice to Charlie (ReferTo: sessionID=3DBC)
>
>
>
>
> From Alice's perspective the call to C is a continuation of
> the call to B - so I would have expected sessionID=3DAB for the
> new call. (From C's perspective it get s a new INVITE which
> replaces a previous one - but this is not as strong a
> connection in my mind as the call coupling at A).
>
>
>
>
> I think using the AB session ID in the Refer may have more
> value in following a REFER chain.
>
>
>
>
> 8 Examples:
>
> I think a REFER example would be valuable. Both a Refer-To
> URI example and an INVITE with Replaces example which makes
> concrete the case in 5.3.
>
>
>
>
> Nits:
>
> (Abstract) s/Troubleshooting/troubleshooting/
>
> 3. I prefer "dialog-creating" to "out-of-dialog" (= but I can
> live with out-of-dialog)
>
>
>
>
> Now to go and sip some Scotch....
>
>
>
>
> Peter Musgrave
>
>
>
>
>

--000e0cd2e054c1258d048bd17ba5-- From adam@nostrum.com Tue Jul 20 07:25:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AC9C3A67F8 for ; Tue, 20 Jul 2010 07:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A170al2arzVA for ; Tue, 20 Jul 2010 07:25:18 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id BBD693A6814 for ; Tue, 20 Jul 2010 07:25:17 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6KEPVba002908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2010 09:25:31 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C45B1D9.30705@nostrum.com> Date: Tue, 20 Jul 2010 09:25:29 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <750BBC72E178114F9DC4872EBFF29A5B0A4EBDBB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A554902@ZMY16EXM66.ds.mot.com> <4BF53641.3070105@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A5549B6@ZMY16EXM66.ds.mot.com> <4BF5563F.8090508@cisco.com> <4BF56106.4010806@cisco.com> <750BBC72E178114F9DC4872EBFF29A5B0A554ADB@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A854E68@ZMY16EXM66.ds.mot.com><4C3F28E2.3000102@nostrum.com> <750BBC72E178114F9DC4872EBFF29A5B0A854F03@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A855531@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A855531@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.233 is authenticated by a trusted mechanism) Cc: IETF Dispatch Subject: Re: [dispatch] draft-avasarala-dispatch-comm-div-notification-05 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 14:25:20 -0000 The only comment I have at this point is that I encourage you to go back and read more than the first two paragraphs of my previous response. /a On 7/20/10 05:39, Jul 20, Avasarala Ranjit-A20990 wrote: > Hi all > > Any comments?? > > > Regards > Ranjit > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Avasarala Ranjit-A20990 > Sent: Thursday, July 15, 2010 11:41 PM > To: Adam Roach > Cc: DISPATCH > Subject: Re: [dispatch] > draft-avasarala-dispatch-comm-div-notification-05 > > Hi Adam > > No Adam we have not jumped into Stage 3 without stage 1 analysis. In > Stage 1 spec 22.173 Section 8.2.7.2 Communication Diversion Notification > Enhancements talks of specific enhancements required for the > Communication Diversion Notification and lists the parameters that could > be part of the notification information. It also further talks about the > trigger for initiating communication diversion notification information > messages towards the subscriber. It finally lists all the elements that > can be part of the Communication Diversion Notification Information. > > So the section 8.2.7.2 of 22.173 should qualify to mention "what" we are > trying to accomplish and the spec 24.604 describes the CDIVN service in > detail and also proposes the required XML schema for the CDIVN XML > package. > > So as mentioned in section 8.2.7.1, the problem is a need for a > mechanism for the subscribers to be notified of communication > diversions. So in addition to the regular CFX services, as a service > provider option, the subscribers are also provided with an option to > subscribe to communication diversion notification service that will help > them to receive notifications of their call diversions. > > Thanks > > Regards > Ranjit > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, July 15, 2010 8:58 PM > To: Avasarala Ranjit-A20990 > Cc: Mary Barnes; DISPATCH > Subject: Re: [dispatch] FW: New Version > Notificationfordraft-avasarala-dispatch-comm-barring-notification-00 > > > On 7/15/10 5:36 AM, Avasarala Ranjit-A20990 wrote: >> After further thought, we feel that since the CDIV service is already > standardized in 3GPP specifications 24.604 (Section 4.10.1.1) and hence > there is no need for explicitly stating the requirements of a CDIV > service again in a separate I-D or document. > > The problem is that section 4.10.1.1 of 24.604 isn't a statement of > requirements. It's a high-level sketch of a solution to an unstated set > of requirements. And section 4.10.2 of that same document is > presumptuous enough to even define an XML Schema for use in this > solution. > > In 3GPP language, you've jumped into stage 2 and stage 3 design without > the stage 1 analysis. > > In the past, what has worked well for extensions to IETF protocols is > when 3GPP does the stage 1 work, and then collaborates with the IETF to > define a solution that satisfies both parties. > > I agree with John, Paul, and Mary -- if this work is to proceed, it > really needs to back up to base principles: *what* are you trying to > accomplish, not *how* do you want to accomplish it? The distinction is > that the answer is to "what are you trying to accomplish" is phrased in > terms of use cases ("a user receives real-time information about the > calls he has missed"), not behavior ("the reason for diversion is > delivered in a element"). > >> Also regarding any existing mechanisms, we feel there is/are no >> existing mechansim(s) for getting notifications of a particular call >> diversion service for a particular subscriber > I think you misread John's proposal. He didn't ask for you to consider > other existing solutions -- he asked you to talk about the potential > solution space. Some of the feedback you've already received covers some > of this space (e.g. information is published using HTTP, and users > discover changes using draft-roach-sip-http-subscribe). > >> Now as per 3GPP's directive, we need to formally standardize the event > package in IETF and hence the draft. > > If you want people to help you work on your event package -- as that is > presumably why you're bringing it to DISPATCH -- then you need to bring > us a problem to work on, not a complete solution to publish. > >> So please let us know how we can take this draft forward to a > meaningful conclusion. > > I think you've been told several times already. What I'm inferring from > your asking again is that you don't like the answer. I'm afraid there's > not much that can be done about that. > > /a > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Tue Jul 20 07:53:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 130803A69FA for ; Tue, 20 Jul 2010 07:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.2 X-Spam-Level: X-Spam-Status: No, score=-10.2 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxtJvxeth-N5 for ; Tue, 20 Jul 2010 07:53:08 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1ED6D3A69EF for ; Tue, 20 Jul 2010 07:53:08 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACtVRUxAaHte/2dsb2JhbACfbXGlXpsthTIEiFk Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 14:53:22 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KErK3U011539; Tue, 20 Jul 2010 14:53:20 GMT Message-ID: <4C45B862.4030004@cisco.com> Date: Tue, 20 Jul 2010 10:53:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Elwell, John" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dispatch mailing list , Hadriel Kaplan Subject: Re: [dispatch] draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 14:53:09 -0000 Elwell, John wrote: > Peter, > > But what if we use Join rather than Replaces, to join rather than replace session BC? There is certainly a strong argument that Alice's leg would be part of session ID BC, rather than AB, in this case. Any opinions whether we should treat Join and Replaces the same or differently? IMO there is no *right* answer to this - it all depends on your intended use of the session id. I think you have to recognize that a choice must be made, and doing so will bias the uses to which the id will be helpful. Thanks, Paul > John > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Peter Musgrave >> Sent: 20 July 2010 11:19 >> To: Hadriel Kaplan; dispatch mailing list >> Subject: Re: [dispatch] draft-kaplan-dispatch-session-id-02 >> >> Hi Hadriel, >> >> >> >> >> Overall I think the draft is in good shape. >> >> >> >> >> I think the work is useful (in fact it's already in my code). >> >> >> >> >> I have an observation about 5.3 >> >> Let me restate the example: >> >> Bob calls Alice (sessionID=AB) >> >> Bob calls Charlie (sessionID=BC) >> >> Bob REFERs Alice to Charlie (ReferTo: sessionID=BC) >> >> >> >> >> From Alice's perspective the call to C is a continuation of >> the call to B - so I would have expected sessionID=AB for the >> new call. (From C's perspective it get s a new INVITE which >> replaces a previous one - but this is not as strong a >> connection in my mind as the call coupling at A). >> >> >> >> >> I think using the AB session ID in the Refer may have more >> value in following a REFER chain. >> >> >> >> >> 8 Examples: >> >> I think a REFER example would be valuable. Both a Refer-To >> URI example and an INVITE with Replaces example which makes >> concrete the case in 5.3. >> >> >> >> >> Nits: >> >> (Abstract) s/Troubleshooting/troubleshooting/ >> >> 3. I prefer "dialog-creating" to "out-of-dialog" (but I can >> live with out-of-dialog) >> >> >> >> >> Now to go and sip some Scotch.... >> >> >> >> >> Peter Musgrave >> >> >> >> >> > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From adam@nostrum.com Tue Jul 20 07:54:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC01B3A6844 for ; Tue, 20 Jul 2010 07:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DunmX0HgKmH0 for ; Tue, 20 Jul 2010 07:54:11 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 46AED3A68AC for ; Tue, 20 Jul 2010 07:54:11 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6KEsMpt005332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2010 09:54:22 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C45B89F.9030808@nostrum.com> Date: Tue, 20 Jul 2010 09:54:23 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Jonathan Rosenberg References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <4C4326B1.7020408@nostrum.com> <000001cb26a4$a81e4840$f85ad8c0$@us> <4C437B03.6070600@nostrum.com> <4C449224.2000101@jdrosen.net> In-Reply-To: <4C449224.2000101@jdrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.233 is authenticated by a trusted mechanism) Cc: 'Bernard Aboba' , dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 14:54:12 -0000 On 7/19/10 12:57, Jul 19, Jonathan Rosenberg wrote: > The issue isn't that people type in phone numbers in a dialpad to make > calls. No one does that anymore. The issue is that phone numbers are > now embedded into the millions (billions?) of address book entries in > phones of various sorts. They appear on business cards, and in email > signatures, and so on. > > As such, enabling voip to drive off of phone numbers can substantially > reduce the friction for getting to voip. These arguments can be applied just as easily to email: if we could simply bind your phone number to your email address, then there's no need to put an email address on your business card, in your address book, etc. Email appears to have done just fine without that binding. The same goes for web sites. Think back to 1996. Wouldn't it have been cool to just type the phone number for Pizza Hut into your URL bar to get to their web site, instead of trying to figure out whether it's "www.pizzahut.com" or "www.pizza-hut.com" or "www.yum.com"? > -- > Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen Ah, yes. Thanks for reminding me. The other point I wanted to make is that most of these examples -- like signature blocks and phone book entries -- can be changed easily and for free. /a From maltarai@cisco.com Tue Jul 20 08:05:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 547F43A6B23 for ; Tue, 20 Jul 2010 08:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVuh1V8FGXlO for ; Tue, 20 Jul 2010 08:05:12 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 070853A6B14 for ; Tue, 20 Jul 2010 08:05:10 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH1YRUytJV2c/2dsb2JhbACfbXGlaJsxhTIEhACHDg Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rtp-iport-2.cisco.com with ESMTP; 20 Jul 2010 15:05:25 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id o6KF5PJo029998; Tue, 20 Jul 2010 15:05:25 GMT Received: from xmb-rcd-113.cisco.com ([72.163.62.155]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 10:05:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 20 Jul 2010 10:05:24 -0500 Message-ID: <04CA7DCC63584C4D8967FF818D80965B01CC6DC7@XMB-RCD-113.cisco.com> In-Reply-To: <4C45B89F.9030808@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] VIPR - proposed charter version 4 Thread-Index: AcsoG3rSZYecvusMRASkgnxUkkS7NQAAH4Cg References: , <04CA7DCC63584C4D8967FF818D80965B01BB8854@XMB-RCD-113.cisco.com> <04CA7DCC63584C4D8967FF818D80965B01BB8861@XMB-RCD-113.cisco.com>, <002f01cb21c6$fdc3f430$f94bdc90$@us> <4C4326B1.7020408@nostrum.com><000001cb26a4$a81e4840$f85ad8c0$@us><4C437B03.6070600@nostrum.com> <4C449224.2000101@jdrosen.net> <4C45B89F.9030808@nostrum.com> From: "Mohammad Al-Taraireh (maltarai)" To: "Adam Roach" , "Jonathan Rosenberg" X-OriginalArrivalTime: 20 Jul 2010 15:05:25.0453 (UTC) FILETIME=[FB8A47D0:01CB281C] Cc: Bernard Aboba , dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 15:05:13 -0000 =20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Adam Roach Sent: Tuesday, July 20, 2010 10:54 AM To: Jonathan Rosenberg Cc: 'Bernard Aboba'; dispatch@ietf.org Subject: Re: [dispatch] VIPR - proposed charter version 4 On 7/19/10 12:57, Jul 19, Jonathan Rosenberg wrote: > The issue isn't that people type in phone numbers in a dialpad to make > calls. No one does that anymore. The issue is that phone numbers are=20 > now embedded into the millions (billions?) of address book entries in=20 > phones of various sorts. They appear on business cards, and in email=20 > signatures, and so on. > > As such, enabling voip to drive off of phone numbers can substantially > reduce the friction for getting to voip. These arguments can be applied just as easily to email: if we could simply bind your phone number to your email address, then there's no need to put an email address on your business card, in your address book, etc. Email appears to have done just fine without that binding. The same goes for web sites. Think back to 1996. Wouldn't it have been cool to just type the phone number for Pizza Hut into your URL bar to get to their web site, instead of trying to figure out whether it's "www.pizzahut.com" or "www.pizza-hut.com" or "www.yum.com"? Mo>> Not exactly, I think you are missing the intent. When I dial a number most likely I want to talk to someone or leave a message, when I send an email or go to webpage my intent is not to talk to anyone. The intent behind SIP URIs, and phone numbers is in a high number of cases is to get connected. Mo > --=20 > Jonathan D. Rosenberg, Ph.D. SkypeID: jdrosen=20 Ah, yes. Thanks for reminding me. The other point I wanted to make is that most of these examples -- like signature blocks and phone book entries -- can be changed easily and for free. /a _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From HKaplan@acmepacket.com Tue Jul 20 10:39:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 728603A6AFD for ; Tue, 20 Jul 2010 10:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWrikVbC-gpP for ; Tue, 20 Jul 2010 10:39:37 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 14C4E3A6992 for ; Tue, 20 Jul 2010 10:39:36 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 20 Jul 2010 13:39:45 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 20 Jul 2010 13:39:45 -0400 From: Hadriel Kaplan To: Peter Musgrave , dispatch mailing list Date: Tue, 20 Jul 2010 13:39:06 -0400 Thread-Topic: draft-kaplan-dispatch-session-id-02 Thread-Index: Acsn9PVNoulhPMd+RWKJOlewa2WYGQAO0BgA Message-ID: <430FC6BDED356B4C8498F634416644A9258D7F3A25@mail> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 17:39:38 -0000 Hey Peter, Comments inline... > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > Sent: Tuesday, July 20, 2010 6:19 AM > To: Hadriel Kaplan; dispatch mailing list >=20 > I have an observation about 5.3 > Let me restate the example: > Bob calls Alice (sessionID=3DAB) > Bob calls Charlie (sessionID=3DBC) > Bob REFERs Alice to Charlie (ReferTo: sessionID=3DBC) >=20 > From Alice's perspective the call to C is a continuation of the call to B > - so I would have expected sessionID=3DAB for the new call. (From C's > perspective it get s a new INVITE which replaces a previous one - but thi= s > is not as strong a connection in my mind as the call coupling at A). >=20 > I think using the AB session ID in the Refer may have more value in > following a REFER chain. It's arguable either way I think, without any "right" way. What I tried to= do was make it such that it would be easier to "trace" the messages in log= s, to troubleshoot problems. So for the Bob-Alice leg, when Bob sends a RE= FER to Alice, the REFER's Session-ID header *is* AB, but the Refer-To URI h= as sessionID=3DBC; so that REFER message helps Alice figure out what the se= ssion-id trace is across the two dialogs in her logs. Charlie gets Session= -ID header of BC, so it's traced for him as well in his logs. In other wor= ds the logs on Alice and Charlie each individually trace the session-id mig= ration/move, without needing to see the other's logs. If the Refer-To used sessionID=3DAB, and Alice thus used Session-ID header = of AB in the INVITE w/replaces to Charlie, the logs on Alice would be clean= , but Charlie's would only correlate them using the Call-ID/tags - if those= match then all's well - but since the point is to troubleshoot when things= _don't_ work, then if they don't match nothing else in the message helps C= harlie figure out what went wrong. Make sense? Also, as a side note, the REFER from Bob to Alice doesn't actually move Bob= 's dialog to Alice (AB) - there's at least the implicit Subscription dialog= usage of that still alive. Whereas the INVITE w/replaces does replace the= BC dialog. So from that perspective it seemed right to me to make the new= Alice-Charlie dialog the replaced BC one. > 8 Examples: > I think a REFER example would be valuable. Both a Refer-To URI example an= d > an INVITE with Replaces example which makes concrete the case in 5.3. Definitely. I was thinking of doing it for this rev, but then I figured th= e odds of it changing would be high so I didn't want to have to redo the ex= ample until it settled down. (i.e., I'm lazy) -hadriel From peter.musgrave@magorcorp.com Tue Jul 20 11:09:19 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317643A6B70 for ; Tue, 20 Jul 2010 11:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.676 X-Spam-Level: X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmME0zHqk5By for ; Tue, 20 Jul 2010 11:09:18 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id D69133A6B47 for ; Tue, 20 Jul 2010 11:09:17 -0700 (PDT) Received: by gwj19 with SMTP id 19so3309808gwj.31 for ; Tue, 20 Jul 2010 11:09:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.96.160 with SMTP id h32mr5688561qan.269.1279649369791; Tue, 20 Jul 2010 11:09:29 -0700 (PDT) Received: by 10.229.20.198 with HTTP; Tue, 20 Jul 2010 11:09:29 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A9258D7F3A25@mail> References: <430FC6BDED356B4C8498F634416644A9258D7F3A25@mail> Date: Tue, 20 Jul 2010 14:09:29 -0400 Message-ID: From: Peter Musgrave To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=00c09f89957e1f9e72048bd59672 Cc: dispatch mailing list Subject: Re: [dispatch] draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 18:09:19 -0000 --00c09f89957e1f9e72048bd59672 Content-Type: text/plain; charset=ISO-8859-1 Hi Hadrial, I agree it's arguable - and since you're the one doing the work I'm happy to live with the way you see it. I see your point about the examples. My counter-point is I'm lazy too and since there were no examples I had to actually read the text closely. Perhaps all part of your nefarious plan thinly disguised as lazyness? Peter Musgrave On Tue, Jul 20, 2010 at 1:39 PM, Hadriel Kaplan wrote: > Hey Peter, > Comments inline... > > > -----Original Message----- > > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > > Sent: Tuesday, July 20, 2010 6:19 AM > > To: Hadriel Kaplan; dispatch mailing list > > > > I have an observation about 5.3 > > Let me restate the example: > > Bob calls Alice (sessionID=AB) > > Bob calls Charlie (sessionID=BC) > > Bob REFERs Alice to Charlie (ReferTo: sessionID=BC) > > > > From Alice's perspective the call to C is a continuation of the call to B > > - so I would have expected sessionID=AB for the new call. (From C's > > perspective it get s a new INVITE which replaces a previous one - but > this > > is not as strong a connection in my mind as the call coupling at A). > > > > I think using the AB session ID in the Refer may have more value in > > following a REFER chain. > > It's arguable either way I think, without any "right" way. What I tried to > do was make it such that it would be easier to "trace" the messages in logs, > to troubleshoot problems. So for the Bob-Alice leg, when Bob sends a REFER > to Alice, the REFER's Session-ID header *is* AB, but the Refer-To URI has > sessionID=BC; so that REFER message helps Alice figure out what the > session-id trace is across the two dialogs in her logs. Charlie gets > Session-ID header of BC, so it's traced for him as well in his logs. In > other words the logs on Alice and Charlie each individually trace the > session-id migration/move, without needing to see the other's logs. > > If the Refer-To used sessionID=AB, and Alice thus used Session-ID header of > AB in the INVITE w/replaces to Charlie, the logs on Alice would be clean, > but Charlie's would only correlate them using the Call-ID/tags - if those > match then all's well - but since the point is to troubleshoot when things > _don't_ work, then if they don't match nothing else in the message helps > Charlie figure out what went wrong. > > Make sense? > > Also, as a side note, the REFER from Bob to Alice doesn't actually move > Bob's dialog to Alice (AB) - there's at least the implicit Subscription > dialog usage of that still alive. Whereas the INVITE w/replaces does > replace the BC dialog. So from that perspective it seemed right to me to > make the new Alice-Charlie dialog the replaced BC one. > > > > 8 Examples: > > I think a REFER example would be valuable. Both a Refer-To URI example > and > > an INVITE with Replaces example which makes concrete the case in 5.3. > > Definitely. I was thinking of doing it for this rev, but then I figured > the odds of it changing would be high so I didn't want to have to redo the > example until it settled down. (i.e., I'm lazy) > > -hadriel > --00c09f89957e1f9e72048bd59672 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Hadrial,

I agree it's arguable - and since = you're the one doing the work I'm happy to live with the way you se= e it.=A0

I see your point about the examples. My counter= -point is I'm lazy too and since there were no examples I had to actual= ly read the text closely. Perhaps all part of your nefarious plan thinly di= sguised as lazyness?

Peter Musgrave

On Tue= , Jul 20, 2010 at 1:39 PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:=
Hey Peter,
Comments inline...

> -----Original Message-----
> From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]
> Sent: Tuesday, July 20, 2010 6:19 AM
> To: Hadriel Kaplan; dispatch mailing list
>
> I have an observation about 5.3
> Let me restate the example:
> Bob calls Alice (sessionID=3DAB)
> Bob calls Charlie (sessionID=3DBC)
> Bob REFERs Alice to Charlie (ReferTo: sessionID=3DBC)
>
> From Alice's perspective the call to C is a continuation of the ca= ll to B
> - so I would have expected sessionID=3DAB for the new call. (From C= 9;s
> perspective it get s a new INVITE which replaces a previous one - but = this
> is not as strong a connection in my mind as the call coupling at A). >
> I think using the AB session ID in the Refer may have more value in > following a REFER chain.

It's arguable either way I think, without any "right" w= ay. =A0What I tried to do was make it such that it would be easier to "= ;trace" the messages in logs, to troubleshoot problems. =A0So for the = Bob-Alice leg, when Bob sends a REFER to Alice, the REFER's Session-ID = header *is* AB, but the Refer-To URI has sessionID=3DBC; so that REFER mess= age helps Alice figure out what the session-id trace is across the two dial= ogs in her logs. =A0Charlie gets Session-ID header of BC, so it's trace= d for him as well in his logs. =A0In other words the logs on Alice and Char= lie each individually trace the session-id migration/move, without needing = to see the other's logs.

If the Refer-To used sessionID=3DAB, and Alice thus used Session-ID header = of AB in the INVITE w/replaces to Charlie, the logs on Alice would be clean= , but Charlie's would only correlate them using the Call-ID/tags - if t= hose match then all's well - but since the point is to troubleshoot whe= n things _don't_ work, then if they don't match nothing else in the= message helps Charlie figure out what went wrong.

Make sense?

Also, as a side note, the REFER from Bob to Alice doesn't actually move= Bob's dialog to Alice (AB) - there's at least the implicit Subscri= ption dialog usage of that still alive. =A0Whereas the INVITE w/replaces do= es replace the BC dialog. =A0So from that perspective it seemed right to me= to make the new Alice-Charlie dialog the replaced BC one.


> 8 Examples:
> I think a REFER example would be valuable. Both a Refer-To URI example= and
> an INVITE with Replaces example which makes concrete the case in 5.3.<= br>
Definitely. =A0I was thinking of doing it for this rev, but then I fi= gured the odds of it changing would be high so I didn't want to have to= redo the example until it settled down. =A0(i.e., I'm lazy)

-hadriel

--00c09f89957e1f9e72048bd59672-- From mperumal@cisco.com Tue Jul 20 11:09:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424383A67AC for ; Tue, 20 Jul 2010 11:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.581 X-Spam-Level: X-Spam-Status: No, score=-5.581 tagged_above=-999 required=5 tests=[AWL=-2.983, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uq9q4EtkvMfm for ; Tue, 20 Jul 2010 11:09:41 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id C50BC3A6B47 for ; Tue, 20 Jul 2010 11:09:39 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtwDAOmCRUxAaHtegWdsb2JhbACBQ54uFQEBFiIipVabMoJrgkcEg36HEA X-IronPort-AV: E=Sophos;i="4.55,233,1278288000"; d="scan'208,217";a="9183151" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ams-iport-2.cisco.com with ESMTP; 20 Jul 2010 17:26:38 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KI9qhx017145; Tue, 20 Jul 2010 18:09:52 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 23:39:51 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2836.BF4C0CD5" Date: Tue, 20 Jul 2010 23:39:49 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> In-Reply-To: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsiqbaMfHyiLn9KSoGceaY0EYk4fwFgwYww References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 20 Jul 2010 18:09:51.0912 (UTC) FILETIME=[BFA9EA80:01CB2836] Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 18:09:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2836.BF4C0CD5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hadriel, =20 I have a security related concern with session-id. One of the requirements in the draft is: =20 REQ2a: The identifier must not reveal any information related to any SIP device or domain identity, including IP Address, port, hostname, domain name, username, Address-of-Record, MAC address, IP address family, transport type, etc. =20 And then is says: =20 A B2BUA compliant with this document MUST copy the Session-ID header field it receives in requests as a UAS into the related requests it generates as a UAC; and any Session-ID field it receives in responses as a UAC into the correlated responses it generates as a UAS. =20 Now, how is a B2BUA, and a SBC in particular, going to verify that session-id isn't revealing any of these information unless it inspects the session-id header? What if an UA uses these 128-bits to encode any of these information to bypass the policies configured at an SBC? For example, an UA can stuff in up to 4 IPv4 addresses or an IPv6 address into the 128-bit session-id header value and get it intact across all SBC bypassing their address/topology hiding policies. =20 Worst, a SBC in the signaling path can strip off the incoming session-id, construct a new session-id, encoding some information into it in order to bypass the policies configured in upstream SBCs, and send it out. When it receives the response, it does the reverse and sends the original session-id back -- a kind of man-in-the-middle attack that none of the SIP elements can detect, unless someone captures the messages across both sides of this SBC. =20 I am not sure SBC vendors are going to be comfortable blindly trusting the sender and considering session-id as an opaque data. Unless we solve this problem they might be reluctant to support session-id. =20 Muthu ------_=_NextPart_001_01CB2836.BF4C0CD5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hadriel,

 

I have = a security related concern with session-id. One of the requirements in the = draft is:

 

   REQ2a: The identifier must not reveal any information related to = any

   SIP device or domain = identity, including IP Address, port, hostname,

   domain name, username, Address-of-Record, MAC address, IP address

   family, transport type, = etc.

 

And = then is says:

 

   A B2BUA compliant with this document MUST copy the Session-ID = header

   field it receives in = requests as a UAS into the related requests = it

   generates as a UAC; and any Session-ID field it receives in

   responses as a UAC into the correlated responses it generates as a

   UAS.

 

Now, = how is a B2BUA, and a SBC in particular, going to = verify that session-id isn't revealing any of these information unless it inspects = the session-id header? What if an UA uses these 128-bits to encode any of = these information to bypass the policies configured at an SBC? For example, an UA can = stuff in up to 4 IPv4 addresses or an IPv6 address into the 128-bit session-id header value and get it intact = across all SBC bypassing their address/topology hiding policies.

 

Worst, = a SBC in the signaling path can strip off the incoming session-id, construct a = new session-id, encoding some information into it in order to bypass the policies = configured in upstream SBCs, and send it out. When it = receives the response, it does the reverse and sends the original session-id back -- = a kind of man-in-the-middle attack that none of the SIP elements can detect, = unless someone captures the messages across both sides of this = SBC.

 

I am = not sure SBC vendors are going to be comfortable blindly trusting the sender and = considering session-id as an opaque data. Unless we solve this problem they might be = reluctant to support session-id.

 

Muthu

------_=_NextPart_001_01CB2836.BF4C0CD5-- From adam@nostrum.com Tue Jul 20 11:50:18 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8314F3A68E8 for ; Tue, 20 Jul 2010 11:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-N7YPOVdjaN for ; Tue, 20 Jul 2010 11:50:17 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 028E33A67DB for ; Tue, 20 Jul 2010 11:50:15 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6KIoKoj025253 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2010 13:50:20 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C45EFEC.5040508@nostrum.com> Date: Tue, 20 Jul 2010 13:50:20 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: "Muthu ArulMozhi Perumal (mperumal)" References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> Content-Type: multipart/alternative; boundary="------------000609000409010808070204" Received-SPF: pass (nostrum.com: 70.249.149.233 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 18:50:18 -0000 This is a multi-part message in MIME format. --------------000609000409010808070204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/20/10 13:09, Jul 20, Muthu ArulMozhi Perumal (mperumal) wrote: > > A B2BUA compliant with this document MUST copy the Session-ID header > > field it receives in requests as a UAS into the related requests it > > generates as a UAC; and any Session-ID field it receives in > > responses as a UAC into the correlated responses it generates as a > > UAS. > > Now, how is a B2BUA, and a SBC in particular, going to verify that > session-id isn't revealing any of these information unless it inspects > the session-id header? What if an UA uses these 128-bits to encode any > of these information to bypass the policies configured at an SBC? For > example, an UA can stuff in up to 4 IPv4 addresses or an IPv6 address > into the 128-bit session-id header value and get it intact across all > SBC bypassing their address/topology hiding policies. > They could also send in in the RTP as DTMF (which a colluding UA on the far end can trivially decode). Or, if you block DTMF, they could play this information out as text-to-speech in the audio stream; a colluding UA on the other end could run speech recognition on this audio to retrieve the information (numbers are very easy to pick out with speech recognition). Or, if you start looking for spoken digits at the beginning of the audio stream, they can steganographically encode the information in the RTP stream (using lost-audio-packet steganography) or even in the contents of the transmitted audio stream itself (yes, there are forms of steganography that survive compression and even transcoding). Basically, if the client is bound and determined to leak this information, it's going to do it. There's nothing an SBC can do about it. Until you actually prevent all communication from the caller to the callee, there will be holes. /a --------------000609000409010808070204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/20/10 13:09, Jul 20, Muthu ArulMozhi Perumal (mperumal) wrote:

 

   A B2BUA compliant with this document MUST copy the Session-ID header

   field it receives in requests as a UAS into the related requests it

   generates as a UAC; and any Session-ID field it receives in

   responses as a UAC into the correlated responses it generates as a

   UAS.

 

Now, how is a B2BUA, and a SBC in particular, going to verify that session-id isn't revealing any of these information unless it inspects the session-id header? What if an UA uses these 128-bits to encode any of these information to bypass the policies configured at an SBC? For example, an UA can stuff in up to 4 IPv4 addresses or an IPv6 address into the 128-bit session-id header value and get it intact across all SBC bypassing their address/topology hiding policies.


They could also send in in the RTP as DTMF (which a colluding UA on the far end can trivially decode). Or, if you block DTMF, they could play this information out as text-to-speech in the audio stream; a colluding UA on the other end could run speech recognition on this audio to retrieve the information (numbers are very easy to pick out with speech recognition). Or, if you start looking for spoken digits at the beginning of the audio stream, they can steganographically encode the information in the RTP stream (using lost-audio-packet steganography) or even in the contents of the transmitted audio stream itself (yes, there are forms of steganography that survive compression and even transcoding).

Basically, if the client is bound and determined to leak this information, it's going to do it. There's nothing an SBC can do about it. Until you actually prevent all communication from the caller to the callee, there will be holes.

/a
--------------000609000409010808070204-- From mperumal@cisco.com Tue Jul 20 12:01:19 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1EE13A6C78 for ; Tue, 20 Jul 2010 12:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.208 X-Spam-Level: X-Spam-Status: No, score=-9.208 tagged_above=-999 required=5 tests=[AWL=1.390, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTDk6sLtI1eE for ; Tue, 20 Jul 2010 12:01:18 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 189BE3A6C73 for ; Tue, 20 Jul 2010 12:01:06 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEuPRUxAaHte/2dsb2JhbACBRJ4vcaYWmyGFMgSDfocQ Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 19:01:20 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KJ1Jup025159; Tue, 20 Jul 2010 19:01:19 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Jul 2010 00:31:19 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB283D.EF78EFE8" Date: Wed, 21 Jul 2010 00:31:17 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020332AB1A@XMB-BGL-414.cisco.com> In-Reply-To: <4C45EFEC.5040508@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsoPIIvFnaoWu3eTZSEY4EAchjnzgAALn7w References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> <4C45EFEC.5040508@nostrum.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Adam Roach" X-OriginalArrivalTime: 20 Jul 2010 19:01:19.0383 (UTC) FILETIME=[EFF09A70:01CB283D] Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:01:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB283D.EF78EFE8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure, they could even fax/email it and a SBC can do nothing about it. However, if the information is leaked through a SIP header a SBC vendor would find it hard to digest -- a perception that I don't think can easily be changed. =20 Muthu=20 =20 From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Wednesday, July 21, 2010 12:20 AM To: Muthu ArulMozhi Perumal (mperumal) Cc: Hadriel Kaplan; dispatch@ietf.org Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 =20 On 7/20/10 13:09, Jul 20, Muthu ArulMozhi Perumal (mperumal) wrote:=20 =20 A B2BUA compliant with this document MUST copy the Session-ID header field it receives in requests as a UAS into the related requests it generates as a UAC; and any Session-ID field it receives in responses as a UAC into the correlated responses it generates as a UAS. =20 Now, how is a B2BUA, and a SBC in particular, going to verify that session-id isn't revealing any of these information unless it inspects the session-id header? What if an UA uses these 128-bits to encode any of these information to bypass the policies configured at an SBC? For example, an UA can stuff in up to 4 IPv4 addresses or an IPv6 address into the 128-bit session-id header value and get it intact across all SBC bypassing their address/topology hiding policies. They could also send in in the RTP as DTMF (which a colluding UA on the far end can trivially decode). Or, if you block DTMF, they could play this information out as text-to-speech in the audio stream; a colluding UA on the other end could run speech recognition on this audio to retrieve the information (numbers are very easy to pick out with speech recognition). Or, if you start looking for spoken digits at the beginning of the audio stream, they can steganographically encode the information in the RTP stream (using lost-audio-packet steganography) or even in the contents of the transmitted audio stream itself (yes, there are forms of steganography that survive compression and even transcoding). Basically, if the client is bound and determined to leak this information, it's going to do it. There's nothing an SBC can do about it. Until you actually prevent all communication from the caller to the callee, there will be holes. /a ------_=_NextPart_001_01CB283D.EF78EFE8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sure, they could even fax/email it and a SBC can do nothing about it. However, = if the information is leaked through a SIP header a SBC vendor would find it = hard to digest -- a perception that I don't think can easily be = changed.

 

Muthu

 

From: Adam Roach = [mailto:adam@nostrum.com]
Sent: Wednesday, July 21, 2010 12:20 AM
To: Muthu ArulMozhi Perumal (mperumal)
Cc: Hadriel Kaplan; dispatch@ietf.org
Subject: Re: [dispatch] Updated: = draft-kaplan-dispatch-session-id-02

 

On 7/20/10 13:09, Jul 20, Muthu ArulMozhi Perumal (mperumal) wrote: =

 

   A B2BUA compliant with this document MUST copy the Session-ID = header

   field it receives in requests as a UAS into the related requests = it

   generates as a UAC; and any Session-ID field it receives = in

   responses as a UAC into the correlated responses it generates as = a

   UAS.

 

Now, how is a B2BUA, and a SBC in particular, going to verify that session-id = isn't revealing any of these information unless it inspects the session-id = header? What if an UA uses these 128-bits to encode any of these information to = bypass the policies configured at an SBC? For example, an UA can stuff in up to = 4 IPv4 addresses or an IPv6 address into the 128-bit session-id header value = and get it intact across all SBC bypassing their address/topology hiding = policies.


They could also send in in the RTP as DTMF (which a colluding UA on the = far end can trivially decode). Or, if you block DTMF, they could play this = information out as text-to-speech in the audio stream; a colluding UA on the other = end could run speech recognition on this audio to retrieve the information = (numbers are very easy to pick out with speech recognition). Or, if you start = looking for spoken digits at the beginning of the audio stream, they can steganographically encode the information in the RTP stream (using lost-audio-packet steganography) or even in the contents of the = transmitted audio stream itself (yes, there are forms of steganography that survive = compression and even transcoding).

Basically, if the client is bound and determined to leak this = information, it's going to do it. There's nothing an SBC can do about it. Until you = actually prevent all communication from the caller to the callee, there will be = holes.

/a

------_=_NextPart_001_01CB283D.EF78EFE8-- From peter.musgrave@magorcorp.com Tue Jul 20 12:12:38 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3B373A687D for ; Tue, 20 Jul 2010 12:12:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.615 X-Spam-Level: X-Spam-Status: No, score=-1.615 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4Ve4OzjUeWf for ; Tue, 20 Jul 2010 12:12:36 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id F156F3A682A for ; Tue, 20 Jul 2010 12:12:35 -0700 (PDT) Received: by iwn38 with SMTP id 38so6552216iwn.31 for ; Tue, 20 Jul 2010 12:12:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.11.210 with SMTP id u18mr5968550qau.30.1279653171087; Tue, 20 Jul 2010 12:12:51 -0700 (PDT) Received: by 10.229.20.198 with HTTP; Tue, 20 Jul 2010 12:12:51 -0700 (PDT) In-Reply-To: <1D062974A4845E4D8A343C65380492020332AB1A@XMB-BGL-414.cisco.com> References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> <4C45EFEC.5040508@nostrum.com> <1D062974A4845E4D8A343C65380492020332AB1A@XMB-BGL-414.cisco.com> Date: Tue, 20 Jul 2010 15:12:51 -0400 Message-ID: From: Peter Musgrave To: "Muthu ArulMozhi Perumal (mperumal)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:12:39 -0000 Are there other headers an SBC would normally forward which could exploited in this way? I suspect in practice there are - although there is no requirement that an SBC forward headers if it wants to be very cautious about such things. In this case I suggest such an SBC would extend it's policy to Session-ID and simply not support it - or regenerate it and break the chain. Peter Musgrave On Tue, Jul 20, 2010 at 3:01 PM, Muthu ArulMozhi Perumal (mperumal) wrote: > Sure, they could even fax/email it and a SBC can do nothing about it. > However, if the information is leaked through a SIP header a SBC vendor > would find it hard to digest -- a perception that I don't think can easil= y > be changed. > > > > Muthu > > > > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Wednesday, July 21, 2010 12:20 AM > To: Muthu ArulMozhi Perumal (mperumal) > Cc: Hadriel Kaplan; dispatch@ietf.org > Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 > > > > On 7/20/10 13:09, Jul 20, Muthu ArulMozhi Perumal (mperumal) wrote: > > > > =A0=A0 A B2BUA compliant with this document MUST copy the Session-ID head= er > > =A0=A0 field it receives in requests as a UAS into the related requests i= t > > =A0=A0 generates as a UAC; and any Session-ID field it receives in > > =A0=A0 responses as a UAC into the correlated responses it generates as a > > =A0=A0 UAS. > > > > Now, how is a B2BUA, and a SBC in particular, going to verify that > session-id isn't revealing any of these information unless it inspects th= e > session-id header? What if an UA uses these 128-bits to encode any of the= se > information to bypass the policies configured at an SBC? For example, an = UA > can stuff in up to 4 IPv4 addresses or an IPv6 address into the 128-bit > session-id header value and get it intact across all SBC bypassing their > address/topology hiding policies. > > They could also send in in the RTP as DTMF (which a colluding UA on the f= ar > end can trivially decode). Or, if you block DTMF, they could play this > information out as text-to-speech in the audio stream; a colluding UA on = the > other end could run speech recognition on this audio to retrieve the > information (numbers are very easy to pick out with speech recognition). = Or, > if you start looking for spoken digits at the beginning of the audio stre= am, > they can steganographically encode the information in the RTP stream (usi= ng > lost-audio-packet steganography) or even in the contents of the transmitt= ed > audio stream itself (yes, there are forms of steganography that survive > compression and even transcoding). > > Basically, if the client is bound and determined to leak this information= , > it's going to do it. There's nothing an SBC can do about it. Until you > actually prevent all communication from the caller to the callee, there w= ill > be holes. > > /a > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > From HKaplan@acmepacket.com Tue Jul 20 12:18:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB0963A6B89 for ; Tue, 20 Jul 2010 12:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5-SeCIACDXJ for ; Tue, 20 Jul 2010 12:18:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E1AFF3A6BC9 for ; Tue, 20 Jul 2010 12:18:54 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 20 Jul 2010 15:19:10 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 20 Jul 2010 15:19:09 -0400 From: Hadriel Kaplan To: "Muthu ArulMozhi Perumal (mperumal)" , "dispatch@ietf.org" Date: Tue, 20 Jul 2010 15:18:46 -0400 Thread-Topic: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsiqbaMfHyiLn9KSoGceaY0EYk4fwFgwYwwAAQhZKA= Message-ID: <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 19:18:57 -0000 Hi Muthu, See section 9.2 of the draft, which has some text around some of the issues= you raised. As for the issue of a UA maliciously trying to pass through addressing in t= he session-id value, that's unavoidable and not a real issue I think. It's= unavoidable because there are multiple ways for a UA which is really inten= t on getting IP Addressing through an SBC to do so anyway, at least by enco= ding it in the media. But I also think it's not a real issue because in my= opinion generally SBC's hide the IP Addressing because people _want_ it hi= dden. Even the end-users generally want it hidden; if they don't, if they = want to learn IP Addresses of each other, nothing will stop them from just = telling each other what it is. (since it takes both sides to collude for it= to work anyway) But as the draft points out, if some vendor (including SBC vendors themselv= es) use this header for some nefarious purpose, then no RFC can prevent the= m from doing so; but what will happen is the word will get out and the SBC = vendors will be forced to remove/replace the header, negating its value to = all. I think/hope the need for a consistent value which crosses b2bua's for trou= bleshooting purposes will be useful enough to vendors, if even to help thei= r own TAC with debugging issues, that they leave it alone - or their custom= ers to tell them to anyway. -hadriel > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > Sent: Tuesday, July 20, 2010 2:10 PM >=20 > I have a security related concern with session-id. One of the requirement= s > in the draft is: > REQ2a: The identifier must not reveal any information related to any > SIP device or domain identity, including IP Address, port, hostname, > domain name, username, Address-of-Record, MAC address, IP address > family, transport type, etc. >=20 > And then is says: > A B2BUA compliant with this document MUST copy the Session-ID header > field it receives in requests as a UAS into the related requests it > generates as a UAC; and any Session-ID field it receives in > responses as a UAC into the correlated responses it generates as a > UAS. >=20 > Now, how is a B2BUA, and a SBC in particular, going to verify that > session-id isn't revealing any of these information unless it inspects th= e > session-id header? What if an UA uses these 128-bits to encode any of > these information to bypass the policies configured at an SBC? For exampl= e, > an UA can stuff in up to 4 IPv4 addresses or an IPv6 address into the 128= - > bit session-id header value and get it intact across all SBC bypassing > their address/topology hiding policies. >=20 > Worst, a SBC in the signaling path can strip off the incoming session-id, > construct a new session-id, encoding some information into it in order to > bypass the policies configured in upstream SBCs, and send it out. When it > receives the response, it does the reverse and sends the original session= - > id back -- a kind of man-in-the-middle attack that none of the SIP > elements can detect, unless someone captures the messages across both > sides of this SBC. >=20 > I am not sure SBC vendors are going to be comfortable blindly trusting th= e > sender and considering session-id as an opaque data. Unless we solve this > problem they might be reluctant to support session-id. From mperumal@cisco.com Tue Jul 20 13:33:11 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86173A67BD for ; Tue, 20 Jul 2010 13:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.363 X-Spam-Level: X-Spam-Status: No, score=-9.363 tagged_above=-999 required=5 tests=[AWL=1.236, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNZXaN-OhXeq for ; Tue, 20 Jul 2010 13:33:08 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 1DD023A6994 for ; Tue, 20 Jul 2010 13:33:02 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGOkRUxAaHte/2dsb2JhbACfc3GmY5sXgmuCRwSDfocQ Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 20:33:16 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KKXFDX009902; Tue, 20 Jul 2010 20:33:15 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Jul 2010 02:03:15 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jul 2010 02:03:12 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020332AB3A@XMB-BGL-414.cisco.com> In-Reply-To: <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsiqbaMfHyiLn9KSoGceaY0EYk4fwFgwYwwAAQhZKAAAgWLcA== References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 20 Jul 2010 20:33:15.0876 (UTC) FILETIME=[C806A240:01CB284A] Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 20:33:12 -0000 Hadriel, I agree with most of what you are saying. However, my questions is, do we want to just ignore it, acknowledging session-id as yet another header through which information can be leaked bypassing SBC policies, or develop a mechanism to equip a SBC with the ability to actually verify that the session-id was indeed constructed form the Call-ID and doesn't reveal anything else, boosting the confidence of SBC vendors. Once quick solution I can think of is, the UA generating a session-id could share a secret with its SBC. It can then encrypt the 128-bit pseudo-random key it generates for constructing the hash with this shared secret, and attach the encrypted value as a session-id header parameter. The SBC can then decrypt the key (using the shared secret), re-compute the hash of the incoming Call-ID, compare it with the session-id value to make sure it was indeed constructed as it should have been. Off course, it doesn't prevent a SBC in performing a man-in-the-middle kind of an attack, but might be worth exploring. So, if we do want to address it, we could add another requirement like this: REQ2c: It should be possible to verify that the identifier does not reveal=20 any information related to any SIP device or domain identity, including IP Address, port, hostname, domain name, username, Address-of-Record, MAC=20 address, IP address family, transport type, etc.=20 The WG can then break its head to see how to solve it -:) Muthu =20 |-----Original Message----- |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] |Sent: Wednesday, July 21, 2010 12:49 AM |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org |Subject: RE: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 | |Hi Muthu, |See section 9.2 of the draft, which has some text around some of the issues |you raised. | |As for the issue of a UA maliciously trying to pass through addressing in |the session-id value, that's unavoidable and not a real issue I think. It's |unavoidable because there are multiple ways for a UA which is really intent |on getting IP Addressing through an SBC to do so anyway, at least by |encoding it in the media. But I also think it's not a real issue because in |my opinion generally SBC's hide the IP Addressing because people _want_ it |hidden. Even the end-users generally want it hidden; if they don't, if they |want to learn IP Addresses of each other, nothing will stop them from just |telling each other what it is. (since it takes both sides to collude for it |to work anyway) | |But as the draft points out, if some vendor (including SBC vendors |themselves) use this header for some nefarious purpose, then no RFC can |prevent them from doing so; but what will happen is the word will get out |and the SBC vendors will be forced to remove/replace the header, negating |its value to all. | |I think/hope the need for a consistent value which crosses b2bua's for |troubleshooting purposes will be useful enough to vendors, if even to help |their own TAC with debugging issues, that they leave it alone - or their |customers to tell them to anyway. | |-hadriel | |> -----Original Message----- |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> Sent: Tuesday, July 20, 2010 2:10 PM |> |> I have a security related concern with session-id. One of the requirements |> in the draft is: |> REQ2a: The identifier must not reveal any information related to any |> SIP device or domain identity, including IP Address, port, hostname, |> domain name, username, Address-of-Record, MAC address, IP address |> family, transport type, etc. |> |> And then is says: |> A B2BUA compliant with this document MUST copy the Session-ID header |> field it receives in requests as a UAS into the related requests it |> generates as a UAC; and any Session-ID field it receives in |> responses as a UAC into the correlated responses it generates as a |> UAS. |> |> Now, how is a B2BUA, and a SBC in particular, going to verify that |> session-id isn't revealing any of these information unless it inspects the |> session-id header? What if an UA uses these 128-bits to encode any of |> these information to bypass the policies configured at an SBC? For |example, |> an UA can stuff in up to 4 IPv4 addresses or an IPv6 address into the 128- |> bit session-id header value and get it intact across all SBC bypassing |> their address/topology hiding policies. |> |> Worst, a SBC in the signaling path can strip off the incoming session-id, |> construct a new session-id, encoding some information into it in order to |> bypass the policies configured in upstream SBCs, and send it out. When it |> receives the response, it does the reverse and sends the original session- |> id back -- a kind of man-in-the-middle attack that none of the SIP |> elements can detect, unless someone captures the messages across both |> sides of this SBC. |> |> I am not sure SBC vendors are going to be comfortable blindly trusting the |> sender and considering session-id as an opaque data. Unless we solve this |> problem they might be reluctant to support session-id. From adam@nostrum.com Tue Jul 20 13:40:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3F53A67BD for ; Tue, 20 Jul 2010 13:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hn2yGl8nVpDR for ; Tue, 20 Jul 2010 13:40:10 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B980A3A65A5 for ; Tue, 20 Jul 2010 13:40:09 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6KKeFog042322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2010 15:40:16 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C4609B0.7000109@nostrum.com> Date: Tue, 20 Jul 2010 15:40:16 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: "Muthu ArulMozhi Perumal (mperumal)" References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> <1D062974A4845E4D8A343C65380492020332AB3A@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020332AB3A@XMB-BGL-414.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.233 is authenticated by a trusted mechanism) Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 20:40:14 -0000 No, this is ridiculous. There is no point to having a 4-foot-thick solid metal door that can withstand a nuclear blast next to a large, open window. Unless you're planning on locking down every other bit of information that can possibly go between user agents -- including the media -- this kind of requirement is paranoid overkill. /a On 7/20/10 15:33, Jul 20, Muthu ArulMozhi Perumal (mperumal) wrote: > Hadriel, > > I agree with most of what you are saying. However, my questions is, do > we want to just ignore it, acknowledging session-id as yet another > header through which information can be leaked bypassing SBC policies, > or develop a mechanism to equip a SBC with the ability to actually > verify that the session-id was indeed constructed form the Call-ID and > doesn't reveal anything else, boosting the confidence of SBC vendors. > > Once quick solution I can think of is, the UA generating a session-id > could share a secret with its SBC. It can then encrypt the 128-bit > pseudo-random key it generates for constructing the hash with this > shared secret, and attach the encrypted value as a session-id header > parameter. The SBC can then decrypt the key (using the shared secret), > re-compute the hash of the incoming Call-ID, compare it with the > session-id value to make sure it was indeed constructed as it should > have been. > > Off course, it doesn't prevent a SBC in performing a man-in-the-middle > kind of an attack, but might be worth exploring. > > So, if we do want to address it, we could add another requirement like > this: > > REQ2c: It should be possible to verify that the identifier does not > reveal > any information related to any SIP device or domain identity, > including > IP Address, port, hostname, domain name, username, Address-of-Record, > MAC > address, IP address family, transport type, etc. > > The WG can then break its head to see how to solve it -:) > > Muthu > > |-----Original Message----- > |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > |Sent: Wednesday, July 21, 2010 12:49 AM > |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org > |Subject: RE: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 > | > |Hi Muthu, > |See section 9.2 of the draft, which has some text around some of the > issues > |you raised. > | > |As for the issue of a UA maliciously trying to pass through addressing > in > |the session-id value, that's unavoidable and not a real issue I think. > It's > |unavoidable because there are multiple ways for a UA which is really > intent > |on getting IP Addressing through an SBC to do so anyway, at least by > |encoding it in the media. But I also think it's not a real issue > because in > |my opinion generally SBC's hide the IP Addressing because people _want_ > it > |hidden. Even the end-users generally want it hidden; if they don't, if > they > |want to learn IP Addresses of each other, nothing will stop them from > just > |telling each other what it is. (since it takes both sides to collude > for it > |to work anyway) > | > |But as the draft points out, if some vendor (including SBC vendors > |themselves) use this header for some nefarious purpose, then no RFC can > |prevent them from doing so; but what will happen is the word will get > out > |and the SBC vendors will be forced to remove/replace the header, > negating > |its value to all. > | > |I think/hope the need for a consistent value which crosses b2bua's for > |troubleshooting purposes will be useful enough to vendors, if even to > help > |their own TAC with debugging issues, that they leave it alone - or > their > |customers to tell them to anyway. > | > |-hadriel > | > |> -----Original Message----- > |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > |> Sent: Tuesday, July 20, 2010 2:10 PM > |> > |> I have a security related concern with session-id. One of the > requirements > |> in the draft is: > |> REQ2a: The identifier must not reveal any information related to > any > |> SIP device or domain identity, including IP Address, port, > hostname, > |> domain name, username, Address-of-Record, MAC address, IP address > |> family, transport type, etc. > |> > |> And then is says: > |> A B2BUA compliant with this document MUST copy the Session-ID > header > |> field it receives in requests as a UAS into the related requests > it > |> generates as a UAC; and any Session-ID field it receives in > |> responses as a UAC into the correlated responses it generates as a > |> UAS. > |> > |> Now, how is a B2BUA, and a SBC in particular, going to verify that > |> session-id isn't revealing any of these information unless it > inspects the > |> session-id header? What if an UA uses these 128-bits to encode any of > |> these information to bypass the policies configured at an SBC? For > |example, > |> an UA can stuff in up to 4 IPv4 addresses or an IPv6 address into the > 128- > |> bit session-id header value and get it intact across all SBC > bypassing > |> their address/topology hiding policies. > |> > |> Worst, a SBC in the signaling path can strip off the incoming > session-id, > |> construct a new session-id, encoding some information into it in > order to > |> bypass the policies configured in upstream SBCs, and send it out. > When it > |> receives the response, it does the reverse and sends the original > session- > |> id back -- a kind of man-in-the-middle attack that none of the SIP > |> elements can detect, unless someone captures the messages across both > |> sides of this SBC. > |> > |> I am not sure SBC vendors are going to be comfortable blindly > trusting the > |> sender and considering session-id as an opaque data. Unless we solve > this > |> problem they might be reluctant to support session-id. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From fluffy@cisco.com Tue Jul 20 14:25:58 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB30A3A68D5 for ; Tue, 20 Jul 2010 14:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.338 X-Spam-Level: X-Spam-Status: No, score=-110.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IwNQOBWy5xkg for ; Tue, 20 Jul 2010 14:25:58 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0F0E53A6863 for ; Tue, 20 Jul 2010 14:25:58 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An4IAM2xRUyrRN+K/2dsb2JhbAAen1hxplibE4UyBIQAhFk Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 21:26:01 +0000 Received: from dhcp-171-68-21-119.cisco.com (dhcp-171-68-21-119.cisco.com [171.68.21.119]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o6KLQ1i9003958 for ; Tue, 20 Jul 2010 21:26:01 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 20 Jul 2010 14:26:04 -0700 Message-Id: To: "dispatch@ietf.org list" Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [dispatch] test 1 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 21:25:58 -0000 please ignore From gao.yang2@zte.com.cn Tue Jul 20 19:16:09 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCD923A69AD for ; Tue, 20 Jul 2010 19:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.589 X-Spam-Level: X-Spam-Status: No, score=-97.589 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4oAflDQcGPi for ; Tue, 20 Jul 2010 19:16:07 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id D61A93A6A17 for ; Tue, 20 Jul 2010 19:16:06 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 3510992332426; Wed, 21 Jul 2010 10:15:14 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 83990.4777041583; Wed, 21 Jul 2010 10:16:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6L2FBsd057575; Wed, 21 Jul 2010 10:15:11 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <1D062974A4845E4D8A343C65380492020332AB3A@XMB-BGL-414.cisco.com> To: "Muthu ArulMozhi Perumal (mperumal)" , Adam Roach MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 21 Jul 2010 10:11:47 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-21 10:15:08, Serialize complete at 2010-07-21 10:15:08 Content-Type: multipart/alternative; boundary="=_alternative 000C4AE448257767_=" X-MAIL: mse2.zte.com.cn o6L2FBsd057575 Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 02:16:10 -0000 This is a multipart message in MIME format. --=_alternative 000C4AE448257767_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgTXV0aHUgYW5kIEFkYW0sDQoNCkkganVzdCByZWFkIHRoZSBhcmd1bWVudCBmcm9tIGJvdGgg b2YgeW91LiANCg0KSW4gZmFjdCwgYXMgd2Uga25vdywgU0JDIGNhbiBub3QgZ3VhcmFudGVlIGFi c29sdXRlIHNlY3VyaXR5IGJ5IEFkYW0ncyANCmFyZ3VtZW50LCBhcyB0aGUgdXNlcihVQUMvVUFT KSBjYW4gcGFzcyBpbmZvcm1hdGlvbiBpbiBtZWRpYSBwbGFuZSwgb3IgDQp1c2luZyBhIHByaXZh dGUgZW5jcnlwdGlvbiBmb3Igc2Vzc2lvbi1pZC9kaWFsb2ctaWQuIEFuZCB0aGUgU0JDcyBoYXZl IG5vIA0Kd2F5IHRvIGluc3BlY3QgaXQuDQoNCkFzIHdlIGtub3cgdGhhdCB3ZSBzaG91bGQgbm90 IGRvIG5vdGhpbmcgKGZvciBzZWN1cml0eSksIHdoaWxlIHdlIGNhbiBub3QgDQpkbyBldmVyeXRo aW5nIChmb3Igc2VjdXJpdHkpLiBTbywgSU1PLCBNdXRodSdzIGFyZ3VtZW50IGlzIGFsc28gbWVh bmluZ2Z1bCANCmZvciByZWxhdGl2ZSBzZWN1cml0eS4NCg0KQnV0IEkgYW0gbm90IGdvaW5nIHRv IGJlIHRoZSBwZWFjZW1ha2VyIGZvciB0aGlzIGFyZ3VtZW50IDopDQpBcyB3ZSBrbm93LCBzZXNz aW9uLWlkIGlzIHRyb3VibGVzaG9vdGluZy9kZWJ1Z2dpbmcgb3JpZW50ZWQuIFNvLCBpdCBpcyBh IA0KdG9vbCBsZXZlbCB0aGluZywgbm90IG5vcm1hdGl2ZSBsZXZlbCwgdGhhdCBpcyBvcHRpb25h bC4gQW5kIGFib3V0IFNCQywgaXQgDQpoYXMgaXQncyBsb2NhbCBwb2xpY3ksIHRoYXQgaXMgaXQg aGFzIHRoZSByaWdodCB0byBkZWNpZGUgc3VwcG9ydGluZyANCnNlc3Npb24taWQgb3IgYmxvY2tp bmcgaXQuIEFuZCBTQkMgY2FuIGV2ZW4gbWFrZSB0aGlzIGEgY29uZmlndXJhdGlvbiwgDQpzdWNo IGFzIGp1c3Qgc3VwcG9ydGluZyBzZXNzaW9uLWlkIGluIGRlYnVnZ2luZyBtb2RlLCBhbmQgYmxv Y2tpbmcgaXQgaW4gDQpyZWFsIGRlcGxveW1lbnQuDQoNCkZ1cnRoZXIsIEknZCBsaWtlIHRvIGJs b2NraW5nIHNlc3Npb24taWQgaW4gcmVhbCBkZXBsb3ltZW50IGZvciBzb21lIA0Kc3BlY2lhbCBr aW5kcyBvZiBCMkJVQSBlcXVpcG1lbnQsIHN1Y2ggYXMgM0dQUCdzIHJvdXRpbmdfQjJCVUFfQVMg YW5kIA0KdG9wb2xvZ3lfaGlkZGVuX29yaWVuZGVkX1NCQy4NCg0KVGhhbmtzLA0KDQpHYW8NCg0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBU ZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2Fv LnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoN Cg0KDQoiTXV0aHUgQXJ1bE1vemhpIFBlcnVtYWwgKG1wZXJ1bWFsKSIgPG1wZXJ1bWFsQGNpc2Nv LmNvbT4gDQq3orz+yMs6ICBkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnDQoyMDEwLTA3LTIxIDA0 OjMzDQoNCsrVvP7Iyw0KIkhhZHJpZWwgS2FwbGFuIiA8SEthcGxhbkBhY21lcGFja2V0LmNvbT4s IDxkaXNwYXRjaEBpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0KUmU6IFtkaXNwYXRjaF0gVXBkYXRl ZDogZHJhZnQta2FwbGFuLWRpc3BhdGNoLXNlc3Npb24taWQtMDINCg0KDQoNCg0KDQoNCkhhZHJp ZWwsDQoNCkkgYWdyZWUgd2l0aCBtb3N0IG9mIHdoYXQgeW91IGFyZSBzYXlpbmcuIEhvd2V2ZXIs IG15IHF1ZXN0aW9ucyBpcywgZG8NCndlIHdhbnQgdG8ganVzdCBpZ25vcmUgaXQsIGFja25vd2xl ZGdpbmcgc2Vzc2lvbi1pZCBhcyB5ZXQgYW5vdGhlcg0KaGVhZGVyIHRocm91Z2ggd2hpY2ggaW5m b3JtYXRpb24gY2FuIGJlIGxlYWtlZCBieXBhc3NpbmcgU0JDIHBvbGljaWVzLA0Kb3IgZGV2ZWxv cCBhIG1lY2hhbmlzbSB0byBlcXVpcCBhIFNCQyB3aXRoIHRoZSBhYmlsaXR5IHRvIGFjdHVhbGx5 DQp2ZXJpZnkgdGhhdCB0aGUgc2Vzc2lvbi1pZCB3YXMgaW5kZWVkIGNvbnN0cnVjdGVkIGZvcm0g dGhlIENhbGwtSUQgYW5kDQpkb2Vzbid0IHJldmVhbCBhbnl0aGluZyBlbHNlLCBib29zdGluZyB0 aGUgY29uZmlkZW5jZSBvZiBTQkMgdmVuZG9ycy4NCg0KT25jZSBxdWljayBzb2x1dGlvbiBJIGNh biB0aGluayBvZiBpcywgdGhlIFVBIGdlbmVyYXRpbmcgYSBzZXNzaW9uLWlkDQpjb3VsZCBzaGFy ZSBhIHNlY3JldCB3aXRoIGl0cyBTQkMuIEl0IGNhbiB0aGVuIGVuY3J5cHQgdGhlIDEyOC1iaXQN CnBzZXVkby1yYW5kb20ga2V5IGl0IGdlbmVyYXRlcyBmb3IgY29uc3RydWN0aW5nIHRoZSBoYXNo IHdpdGggdGhpcw0Kc2hhcmVkIHNlY3JldCwgYW5kIGF0dGFjaCB0aGUgZW5jcnlwdGVkIHZhbHVl IGFzIGEgc2Vzc2lvbi1pZCBoZWFkZXINCnBhcmFtZXRlci4gVGhlIFNCQyBjYW4gdGhlbiBkZWNy eXB0IHRoZSBrZXkgKHVzaW5nIHRoZSBzaGFyZWQgc2VjcmV0KSwNCnJlLWNvbXB1dGUgdGhlIGhh c2ggb2YgdGhlIGluY29taW5nIENhbGwtSUQsIGNvbXBhcmUgaXQgd2l0aCB0aGUNCnNlc3Npb24t aWQgdmFsdWUgdG8gbWFrZSBzdXJlIGl0IHdhcyBpbmRlZWQgY29uc3RydWN0ZWQgYXMgaXQgc2hv dWxkDQpoYXZlIGJlZW4uDQoNCk9mZiBjb3Vyc2UsIGl0IGRvZXNuJ3QgcHJldmVudCBhIFNCQyBp biBwZXJmb3JtaW5nIGEgbWFuLWluLXRoZS1taWRkbGUNCmtpbmQgb2YgYW4gYXR0YWNrLCBidXQg bWlnaHQgYmUgd29ydGggZXhwbG9yaW5nLg0KDQpTbywgaWYgd2UgZG8gd2FudCB0byBhZGRyZXNz IGl0LCB3ZSBjb3VsZCBhZGQgYW5vdGhlciByZXF1aXJlbWVudCBsaWtlDQp0aGlzOg0KDQogICBS RVEyYzogSXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIHZlcmlmeSB0aGF0IHRoZSBpZGVudGlmaWVy IGRvZXMgbm90DQpyZXZlYWwgDQogICBhbnkgaW5mb3JtYXRpb24gcmVsYXRlZCB0byBhbnkgU0lQ IGRldmljZSBvciBkb21haW4gaWRlbnRpdHksDQppbmNsdWRpbmcNCiAgIElQIEFkZHJlc3MsIHBv cnQsIGhvc3RuYW1lLCBkb21haW4gbmFtZSwgdXNlcm5hbWUsIEFkZHJlc3Mtb2YtUmVjb3JkLA0K TUFDIA0KICAgYWRkcmVzcywgSVAgYWRkcmVzcyBmYW1pbHksIHRyYW5zcG9ydCB0eXBlLCBldGMu IA0KDQpUaGUgV0cgY2FuIHRoZW4gYnJlYWsgaXRzIGhlYWQgdG8gc2VlIGhvdyB0byBzb2x2ZSBp dCAtOikNCg0KTXV0aHUNCiANCnwtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KfEZyb206IEhh ZHJpZWwgS2FwbGFuIFttYWlsdG86SEthcGxhbkBhY21lcGFja2V0LmNvbV0NCnxTZW50OiBXZWRu ZXNkYXksIEp1bHkgMjEsIDIwMTAgMTI6NDkgQU0NCnxUbzogTXV0aHUgQXJ1bE1vemhpIFBlcnVt YWwgKG1wZXJ1bWFsKTsgZGlzcGF0Y2hAaWV0Zi5vcmcNCnxTdWJqZWN0OiBSRTogW2Rpc3BhdGNo XSBVcGRhdGVkOiBkcmFmdC1rYXBsYW4tZGlzcGF0Y2gtc2Vzc2lvbi1pZC0wMg0KfA0KfEhpIE11 dGh1LA0KfFNlZSBzZWN0aW9uIDkuMiBvZiB0aGUgZHJhZnQsIHdoaWNoIGhhcyBzb21lIHRleHQg YXJvdW5kIHNvbWUgb2YgdGhlDQppc3N1ZXMNCnx5b3UgcmFpc2VkLg0KfA0KfEFzIGZvciB0aGUg aXNzdWUgb2YgYSBVQSBtYWxpY2lvdXNseSB0cnlpbmcgdG8gcGFzcyB0aHJvdWdoIGFkZHJlc3Np bmcNCmluDQp8dGhlIHNlc3Npb24taWQgdmFsdWUsIHRoYXQncyB1bmF2b2lkYWJsZSBhbmQgbm90 IGEgcmVhbCBpc3N1ZSBJIHRoaW5rLg0KSXQncw0KfHVuYXZvaWRhYmxlIGJlY2F1c2UgdGhlcmUg YXJlIG11bHRpcGxlIHdheXMgZm9yIGEgVUEgd2hpY2ggaXMgcmVhbGx5DQppbnRlbnQNCnxvbiBn ZXR0aW5nIElQIEFkZHJlc3NpbmcgdGhyb3VnaCBhbiBTQkMgdG8gZG8gc28gYW55d2F5LCBhdCBs ZWFzdCBieQ0KfGVuY29kaW5nIGl0IGluIHRoZSBtZWRpYS4gIEJ1dCBJIGFsc28gdGhpbmsgaXQn cyBub3QgYSByZWFsIGlzc3VlDQpiZWNhdXNlIGluDQp8bXkgb3BpbmlvbiBnZW5lcmFsbHkgU0JD J3MgaGlkZSB0aGUgSVAgQWRkcmVzc2luZyBiZWNhdXNlIHBlb3BsZSBfd2FudF8NCml0DQp8aGlk ZGVuLiAgRXZlbiB0aGUgZW5kLXVzZXJzIGdlbmVyYWxseSB3YW50IGl0IGhpZGRlbjsgaWYgdGhl eSBkb24ndCwgaWYNCnRoZXkNCnx3YW50IHRvIGxlYXJuIElQIEFkZHJlc3NlcyBvZiBlYWNoIG90 aGVyLCBub3RoaW5nIHdpbGwgc3RvcCB0aGVtIGZyb20NCmp1c3QNCnx0ZWxsaW5nIGVhY2ggb3Ro ZXIgd2hhdCBpdCBpcy4gKHNpbmNlIGl0IHRha2VzIGJvdGggc2lkZXMgdG8gY29sbHVkZQ0KZm9y IGl0DQp8dG8gd29yayBhbnl3YXkpDQp8DQp8QnV0IGFzIHRoZSBkcmFmdCBwb2ludHMgb3V0LCBp ZiBzb21lIHZlbmRvciAoaW5jbHVkaW5nIFNCQyB2ZW5kb3JzDQp8dGhlbXNlbHZlcykgdXNlIHRo aXMgaGVhZGVyIGZvciBzb21lIG5lZmFyaW91cyBwdXJwb3NlLCB0aGVuIG5vIFJGQyBjYW4NCnxw cmV2ZW50IHRoZW0gZnJvbSBkb2luZyBzbzsgYnV0IHdoYXQgd2lsbCBoYXBwZW4gaXMgdGhlIHdv cmQgd2lsbCBnZXQNCm91dA0KfGFuZCB0aGUgU0JDIHZlbmRvcnMgd2lsbCBiZSBmb3JjZWQgdG8g cmVtb3ZlL3JlcGxhY2UgdGhlIGhlYWRlciwNCm5lZ2F0aW5nDQp8aXRzIHZhbHVlIHRvIGFsbC4N CnwNCnxJIHRoaW5rL2hvcGUgdGhlIG5lZWQgZm9yIGEgY29uc2lzdGVudCB2YWx1ZSB3aGljaCBj cm9zc2VzIGIyYnVhJ3MgZm9yDQp8dHJvdWJsZXNob290aW5nIHB1cnBvc2VzIHdpbGwgYmUgdXNl ZnVsIGVub3VnaCB0byB2ZW5kb3JzLCBpZiBldmVuIHRvDQpoZWxwDQp8dGhlaXIgb3duIFRBQyB3 aXRoIGRlYnVnZ2luZyBpc3N1ZXMsIHRoYXQgdGhleSBsZWF2ZSBpdCBhbG9uZSAtIG9yDQp0aGVp cg0KfGN1c3RvbWVycyB0byB0ZWxsIHRoZW0gdG8gYW55d2F5Lg0KfA0KfC1oYWRyaWVsDQp8DQp8 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KfD4gRnJvbTogTXV0aHUgQXJ1bE1vemhpIFBl cnVtYWwgKG1wZXJ1bWFsKSBbbWFpbHRvOm1wZXJ1bWFsQGNpc2NvLmNvbV0NCnw+IFNlbnQ6IFR1 ZXNkYXksIEp1bHkgMjAsIDIwMTAgMjoxMCBQTQ0KfD4NCnw+IEkgaGF2ZSBhIHNlY3VyaXR5IHJl bGF0ZWQgY29uY2VybiB3aXRoIHNlc3Npb24taWQuIE9uZSBvZiB0aGUNCnJlcXVpcmVtZW50cw0K fD4gaW4gdGhlIGRyYWZ0IGlzOg0KfD4gICAgUkVRMmE6IFRoZSBpZGVudGlmaWVyIG11c3Qgbm90 IHJldmVhbCBhbnkgaW5mb3JtYXRpb24gcmVsYXRlZCB0bw0KYW55DQp8PiAgICBTSVAgZGV2aWNl IG9yIGRvbWFpbiBpZGVudGl0eSwgaW5jbHVkaW5nIElQIEFkZHJlc3MsIHBvcnQsDQpob3N0bmFt ZSwNCnw+ICAgIGRvbWFpbiBuYW1lLCB1c2VybmFtZSwgQWRkcmVzcy1vZi1SZWNvcmQsIE1BQyBh ZGRyZXNzLCBJUCBhZGRyZXNzDQp8PiAgICBmYW1pbHksIHRyYW5zcG9ydCB0eXBlLCBldGMuDQp8 Pg0KfD4gQW5kIHRoZW4gaXMgc2F5czoNCnw+ICAgIEEgQjJCVUEgY29tcGxpYW50IHdpdGggdGhp cyBkb2N1bWVudCBNVVNUIGNvcHkgdGhlIFNlc3Npb24tSUQNCmhlYWRlcg0KfD4gICAgZmllbGQg aXQgcmVjZWl2ZXMgaW4gcmVxdWVzdHMgYXMgYSBVQVMgaW50byB0aGUgcmVsYXRlZCByZXF1ZXN0 cw0KaXQNCnw+ICAgIGdlbmVyYXRlcyBhcyBhIFVBQzsgYW5kIGFueSBTZXNzaW9uLUlEIGZpZWxk IGl0IHJlY2VpdmVzIGluDQp8PiAgICByZXNwb25zZXMgYXMgYSBVQUMgaW50byB0aGUgY29ycmVs YXRlZCByZXNwb25zZXMgaXQgZ2VuZXJhdGVzIGFzIGENCnw+ICAgIFVBUy4NCnw+DQp8PiBOb3cs IGhvdyBpcyBhIEIyQlVBLCBhbmQgYSBTQkMgaW4gcGFydGljdWxhciwgZ29pbmcgdG8gdmVyaWZ5 IHRoYXQNCnw+IHNlc3Npb24taWQgaXNuJ3QgcmV2ZWFsaW5nIGFueSBvZiB0aGVzZSBpbmZvcm1h dGlvbiB1bmxlc3MgaXQNCmluc3BlY3RzIHRoZQ0KfD4gc2Vzc2lvbi1pZCBoZWFkZXI/IFdoYXQg aWYgYW4gVUEgdXNlcyB0aGVzZSAxMjgtYml0cyB0byBlbmNvZGUgYW55IG9mDQp8PiB0aGVzZSBp bmZvcm1hdGlvbiB0byBieXBhc3MgdGhlIHBvbGljaWVzIGNvbmZpZ3VyZWQgYXQgYW4gU0JDPyBG b3INCnxleGFtcGxlLA0KfD4gYW4gVUEgY2FuIHN0dWZmIGluIHVwIHRvIDQgSVB2NCBhZGRyZXNz ZXMgb3IgYW4gSVB2NiBhZGRyZXNzIGludG8gdGhlDQoxMjgtDQp8PiBiaXQgc2Vzc2lvbi1pZCBo ZWFkZXIgdmFsdWUgYW5kIGdldCBpdCBpbnRhY3QgYWNyb3NzIGFsbCBTQkMNCmJ5cGFzc2luZw0K fD4gdGhlaXIgYWRkcmVzcy90b3BvbG9neSBoaWRpbmcgcG9saWNpZXMuDQp8Pg0KfD4gV29yc3Qs IGEgU0JDIGluIHRoZSBzaWduYWxpbmcgcGF0aCBjYW4gc3RyaXAgb2ZmIHRoZSBpbmNvbWluZw0K c2Vzc2lvbi1pZCwNCnw+IGNvbnN0cnVjdCBhIG5ldyBzZXNzaW9uLWlkLCBlbmNvZGluZyBzb21l IGluZm9ybWF0aW9uIGludG8gaXQgaW4NCm9yZGVyIHRvDQp8PiBieXBhc3MgdGhlIHBvbGljaWVz IGNvbmZpZ3VyZWQgaW4gdXBzdHJlYW0gU0JDcywgYW5kIHNlbmQgaXQgb3V0Lg0KV2hlbiBpdA0K fD4gcmVjZWl2ZXMgdGhlIHJlc3BvbnNlLCBpdCBkb2VzIHRoZSByZXZlcnNlIGFuZCBzZW5kcyB0 aGUgb3JpZ2luYWwNCnNlc3Npb24tDQp8PiBpZCBiYWNrIC0tIGEga2luZCBvZiBtYW4taW4tdGhl LW1pZGRsZSBhdHRhY2sgdGhhdCBub25lIG9mIHRoZSBTSVANCnw+IGVsZW1lbnRzIGNhbiBkZXRl Y3QsIHVubGVzcyBzb21lb25lIGNhcHR1cmVzIHRoZSBtZXNzYWdlcyBhY3Jvc3MgYm90aA0KfD4g c2lkZXMgb2YgdGhpcyBTQkMuDQp8Pg0KfD4gSSBhbSBub3Qgc3VyZSBTQkMgdmVuZG9ycyBhcmUg Z29pbmcgdG8gYmUgY29tZm9ydGFibGUgYmxpbmRseQ0KdHJ1c3RpbmcgdGhlDQp8PiBzZW5kZXIg YW5kIGNvbnNpZGVyaW5nIHNlc3Npb24taWQgYXMgYW4gb3BhcXVlIGRhdGEuIFVubGVzcyB3ZSBz b2x2ZQ0KdGhpcw0KfD4gcHJvYmxlbSB0aGV5IG1pZ2h0IGJlIHJlbHVjdGFudCB0byBzdXBwb3J0 IHNlc3Npb24taWQuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCmRpc3BhdGNoQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQoNCg0KDQoNCg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJ bmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g dGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9u LiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFt ZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBl cm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRv IG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFy ZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5k aXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRv ciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJl IHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBz Y2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 000C4AE448257767_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIE11dGh1IGFuZCBBZGFtLDwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBqdXN0IHJl YWQgdGhlIGFyZ3VtZW50IGZyb20gYm90aCBvZg0KeW91LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkluIGZhY3QsIGFzIHdlIGtub3csIFNCQyBjYW4g bm90IGd1YXJhbnRlZQ0KYWJzb2x1dGUgc2VjdXJpdHkgYnkgQWRhbSdzIGFyZ3VtZW50LCBhcyB0 aGUgdXNlcihVQUMvVUFTKSBjYW4gcGFzcyBpbmZvcm1hdGlvbg0KaW4gbWVkaWEgcGxhbmUsIG9y IHVzaW5nIGEgcHJpdmF0ZSBlbmNyeXB0aW9uIGZvciBzZXNzaW9uLWlkL2RpYWxvZy1pZC4NCkFu ZCB0aGUgU0JDcyBoYXZlIG5vIHdheSB0byBpbnNwZWN0IGl0LjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXMgd2Uga25vdyB0aGF0IHdlIHNob3VsZCBu b3QgZG8gbm90aGluZw0KKGZvciBzZWN1cml0eSksIHdoaWxlIHdlIGNhbiBub3QgZG8gZXZlcnl0 aGluZyAoZm9yIHNlY3VyaXR5KS4gU28sIElNTywNCk11dGh1J3MgYXJndW1lbnQgaXMgYWxzbyBt ZWFuaW5nZnVsIGZvciByZWxhdGl2ZSBzZWN1cml0eS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkJ1dCBJIGFtIG5vdCBnb2luZyB0byBiZSB0aGUgcGVh Y2VtYWtlcg0KZm9yIHRoaXMgYXJndW1lbnQgOik8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPkFzIHdlIGtub3csIHNlc3Npb24taWQgaXMgdHJvdWJsZXNob290aW5n L2RlYnVnZ2luZw0Kb3JpZW50ZWQuIFNvLCBpdCBpcyBhIHRvb2wgbGV2ZWwgdGhpbmcsIG5vdCBu b3JtYXRpdmUgbGV2ZWwsIHRoYXQgaXMgb3B0aW9uYWwuDQpBbmQgYWJvdXQgU0JDLCBpdCBoYXMg aXQncyBsb2NhbCBwb2xpY3ksIHRoYXQgaXMgaXQgaGFzIHRoZSByaWdodCB0byBkZWNpZGUNCnN1 cHBvcnRpbmcgc2Vzc2lvbi1pZCBvciBibG9ja2luZyBpdC4gQW5kIFNCQyBjYW4gZXZlbiBtYWtl IHRoaXMgYSBjb25maWd1cmF0aW9uLA0Kc3VjaCBhcyBqdXN0IHN1cHBvcnRpbmcgc2Vzc2lvbi1p ZCBpbiBkZWJ1Z2dpbmcgbW9kZSwgYW5kIGJsb2NraW5nIGl0IGluDQpyZWFsIGRlcGxveW1lbnQu PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GdXJ0aGVy LCBJJ2QgbGlrZSB0byBibG9ja2luZyBzZXNzaW9uLWlkDQppbiByZWFsIGRlcGxveW1lbnQgZm9y IHNvbWUgc3BlY2lhbCBraW5kcyBvZiBCMkJVQSBlcXVpcG1lbnQsIHN1Y2ggYXMgM0dQUCdzDQpy b3V0aW5nX0IyQlVBX0FTIGFuZCB0b3BvbG9neV9oaWRkZW5fb3JpZW5kZWRfU0JDLjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRl bCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3 MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+PGI+JnF1b3Q7TXV0aHUgQXJ1bE1vemhpIFBlcnVtYWwNCihtcGVy dW1hbCkmcXVvdDsgJmx0O21wZXJ1bWFsQGNpc2NvLmNvbSZndDs8L2I+IDwvZm9udD4NCjxicj48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtkaXNwYXRjaC1ib3Vu Y2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIw MTAtMDctMjEgMDQ6MzM8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+JnF1b3Q7SGFkcmllbCBLYXBsYW4mcXVvdDsgJmx0O0hLYXBsYW5AYWNt ZXBhY2tldC5jb20mZ3Q7LA0KJmx0O2Rpc3BhdGNoQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtkaXNwYXRj aF0gVXBkYXRlZDogZHJhZnQta2FwbGFuLWRpc3BhdGNoLXNlc3Npb24taWQtMDI8L2ZvbnQ+PC90 YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+ DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkhhZHJpZWws PGJyPg0KPGJyPg0KSSBhZ3JlZSB3aXRoIG1vc3Qgb2Ygd2hhdCB5b3UgYXJlIHNheWluZy4gSG93 ZXZlciwgbXkgcXVlc3Rpb25zIGlzLCBkbzxicj4NCndlIHdhbnQgdG8ganVzdCBpZ25vcmUgaXQs IGFja25vd2xlZGdpbmcgc2Vzc2lvbi1pZCBhcyB5ZXQgYW5vdGhlcjxicj4NCmhlYWRlciB0aHJv dWdoIHdoaWNoIGluZm9ybWF0aW9uIGNhbiBiZSBsZWFrZWQgYnlwYXNzaW5nIFNCQyBwb2xpY2ll cyw8YnI+DQpvciBkZXZlbG9wIGEgbWVjaGFuaXNtIHRvIGVxdWlwIGEgU0JDIHdpdGggdGhlIGFi aWxpdHkgdG8gYWN0dWFsbHk8YnI+DQp2ZXJpZnkgdGhhdCB0aGUgc2Vzc2lvbi1pZCB3YXMgaW5k ZWVkIGNvbnN0cnVjdGVkIGZvcm0gdGhlIENhbGwtSUQgYW5kPGJyPg0KZG9lc24ndCByZXZlYWwg YW55dGhpbmcgZWxzZSwgYm9vc3RpbmcgdGhlIGNvbmZpZGVuY2Ugb2YgU0JDIHZlbmRvcnMuPGJy Pg0KPGJyPg0KT25jZSBxdWljayBzb2x1dGlvbiBJIGNhbiB0aGluayBvZiBpcywgdGhlIFVBIGdl bmVyYXRpbmcgYSBzZXNzaW9uLWlkPGJyPg0KY291bGQgc2hhcmUgYSBzZWNyZXQgd2l0aCBpdHMg U0JDLiBJdCBjYW4gdGhlbiBlbmNyeXB0IHRoZSAxMjgtYml0PGJyPg0KcHNldWRvLXJhbmRvbSBr ZXkgaXQgZ2VuZXJhdGVzIGZvciBjb25zdHJ1Y3RpbmcgdGhlIGhhc2ggd2l0aCB0aGlzPGJyPg0K c2hhcmVkIHNlY3JldCwgYW5kIGF0dGFjaCB0aGUgZW5jcnlwdGVkIHZhbHVlIGFzIGEgc2Vzc2lv bi1pZCBoZWFkZXI8YnI+DQpwYXJhbWV0ZXIuIFRoZSBTQkMgY2FuIHRoZW4gZGVjcnlwdCB0aGUg a2V5ICh1c2luZyB0aGUgc2hhcmVkIHNlY3JldCksPGJyPg0KcmUtY29tcHV0ZSB0aGUgaGFzaCBv ZiB0aGUgaW5jb21pbmcgQ2FsbC1JRCwgY29tcGFyZSBpdCB3aXRoIHRoZTxicj4NCnNlc3Npb24t aWQgdmFsdWUgdG8gbWFrZSBzdXJlIGl0IHdhcyBpbmRlZWQgY29uc3RydWN0ZWQgYXMgaXQgc2hv dWxkPGJyPg0KaGF2ZSBiZWVuLjxicj4NCjxicj4NCk9mZiBjb3Vyc2UsIGl0IGRvZXNuJ3QgcHJl dmVudCBhIFNCQyBpbiBwZXJmb3JtaW5nIGEgbWFuLWluLXRoZS1taWRkbGU8YnI+DQpraW5kIG9m IGFuIGF0dGFjaywgYnV0IG1pZ2h0IGJlIHdvcnRoIGV4cGxvcmluZy48YnI+DQo8YnI+DQpTbywg aWYgd2UgZG8gd2FudCB0byBhZGRyZXNzIGl0LCB3ZSBjb3VsZCBhZGQgYW5vdGhlciByZXF1aXJl bWVudCBsaWtlPGJyPg0KdGhpczo8YnI+DQo8YnI+DQogJm5ic3A7IFJFUTJjOiBJdCBzaG91bGQg YmUgcG9zc2libGUgdG8gdmVyaWZ5IHRoYXQgdGhlIGlkZW50aWZpZXIgZG9lcw0Kbm90PGJyPg0K cmV2ZWFsIDxicj4NCiAmbmJzcDsgYW55IGluZm9ybWF0aW9uIHJlbGF0ZWQgdG8gYW55IFNJUCBk ZXZpY2Ugb3IgZG9tYWluIGlkZW50aXR5LDxicj4NCmluY2x1ZGluZzxicj4NCiAmbmJzcDsgSVAg QWRkcmVzcywgcG9ydCwgaG9zdG5hbWUsIGRvbWFpbiBuYW1lLCB1c2VybmFtZSwgQWRkcmVzcy1v Zi1SZWNvcmQsPGJyPg0KTUFDIDxicj4NCiAmbmJzcDsgYWRkcmVzcywgSVAgYWRkcmVzcyBmYW1p bHksIHRyYW5zcG9ydCB0eXBlLCBldGMuIDxicj4NCjxicj4NClRoZSBXRyBjYW4gdGhlbiBicmVh ayBpdHMgaGVhZCB0byBzZWUgaG93IHRvIHNvbHZlIGl0IC06KTxicj4NCjxicj4NCk11dGh1PGJy Pg0KIDxicj4NCnwtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCnxGcm9tOiBIYWRyaWVs IEthcGxhbiBbbWFpbHRvOkhLYXBsYW5AYWNtZXBhY2tldC5jb21dPGJyPg0KfFNlbnQ6IFdlZG5l c2RheSwgSnVseSAyMSwgMjAxMCAxMjo0OSBBTTxicj4NCnxUbzogTXV0aHUgQXJ1bE1vemhpIFBl cnVtYWwgKG1wZXJ1bWFsKTsgZGlzcGF0Y2hAaWV0Zi5vcmc8YnI+DQp8U3ViamVjdDogUkU6IFtk aXNwYXRjaF0gVXBkYXRlZDogZHJhZnQta2FwbGFuLWRpc3BhdGNoLXNlc3Npb24taWQtMDI8YnI+ DQp8PGJyPg0KfEhpIE11dGh1LDxicj4NCnxTZWUgc2VjdGlvbiA5LjIgb2YgdGhlIGRyYWZ0LCB3 aGljaCBoYXMgc29tZSB0ZXh0IGFyb3VuZCBzb21lIG9mIHRoZTxicj4NCmlzc3Vlczxicj4NCnx5 b3UgcmFpc2VkLjxicj4NCnw8YnI+DQp8QXMgZm9yIHRoZSBpc3N1ZSBvZiBhIFVBIG1hbGljaW91 c2x5IHRyeWluZyB0byBwYXNzIHRocm91Z2ggYWRkcmVzc2luZzxicj4NCmluPGJyPg0KfHRoZSBz ZXNzaW9uLWlkIHZhbHVlLCB0aGF0J3MgdW5hdm9pZGFibGUgYW5kIG5vdCBhIHJlYWwgaXNzdWUg SSB0aGluay48YnI+DQpJdCdzPGJyPg0KfHVuYXZvaWRhYmxlIGJlY2F1c2UgdGhlcmUgYXJlIG11 bHRpcGxlIHdheXMgZm9yIGEgVUEgd2hpY2ggaXMgcmVhbGx5PGJyPg0KaW50ZW50PGJyPg0KfG9u IGdldHRpbmcgSVAgQWRkcmVzc2luZyB0aHJvdWdoIGFuIFNCQyB0byBkbyBzbyBhbnl3YXksIGF0 IGxlYXN0IGJ5PGJyPg0KfGVuY29kaW5nIGl0IGluIHRoZSBtZWRpYS4gJm5ic3A7QnV0IEkgYWxz byB0aGluayBpdCdzIG5vdCBhIHJlYWwgaXNzdWU8YnI+DQpiZWNhdXNlIGluPGJyPg0KfG15IG9w aW5pb24gZ2VuZXJhbGx5IFNCQydzIGhpZGUgdGhlIElQIEFkZHJlc3NpbmcgYmVjYXVzZSBwZW9w bGUgX3dhbnRfPGJyPg0KaXQ8YnI+DQp8aGlkZGVuLiAmbmJzcDtFdmVuIHRoZSBlbmQtdXNlcnMg Z2VuZXJhbGx5IHdhbnQgaXQgaGlkZGVuOyBpZiB0aGV5IGRvbid0LA0KaWY8YnI+DQp0aGV5PGJy Pg0KfHdhbnQgdG8gbGVhcm4gSVAgQWRkcmVzc2VzIG9mIGVhY2ggb3RoZXIsIG5vdGhpbmcgd2ls bCBzdG9wIHRoZW0gZnJvbTxicj4NCmp1c3Q8YnI+DQp8dGVsbGluZyBlYWNoIG90aGVyIHdoYXQg aXQgaXMuIChzaW5jZSBpdCB0YWtlcyBib3RoIHNpZGVzIHRvIGNvbGx1ZGU8YnI+DQpmb3IgaXQ8 YnI+DQp8dG8gd29yayBhbnl3YXkpPGJyPg0KfDxicj4NCnxCdXQgYXMgdGhlIGRyYWZ0IHBvaW50 cyBvdXQsIGlmIHNvbWUgdmVuZG9yIChpbmNsdWRpbmcgU0JDIHZlbmRvcnM8YnI+DQp8dGhlbXNl bHZlcykgdXNlIHRoaXMgaGVhZGVyIGZvciBzb21lIG5lZmFyaW91cyBwdXJwb3NlLCB0aGVuIG5v IFJGQyBjYW48YnI+DQp8cHJldmVudCB0aGVtIGZyb20gZG9pbmcgc287IGJ1dCB3aGF0IHdpbGwg aGFwcGVuIGlzIHRoZSB3b3JkIHdpbGwgZ2V0PGJyPg0Kb3V0PGJyPg0KfGFuZCB0aGUgU0JDIHZl bmRvcnMgd2lsbCBiZSBmb3JjZWQgdG8gcmVtb3ZlL3JlcGxhY2UgdGhlIGhlYWRlciw8YnI+DQpu ZWdhdGluZzxicj4NCnxpdHMgdmFsdWUgdG8gYWxsLjxicj4NCnw8YnI+DQp8SSB0aGluay9ob3Bl IHRoZSBuZWVkIGZvciBhIGNvbnNpc3RlbnQgdmFsdWUgd2hpY2ggY3Jvc3NlcyBiMmJ1YSdzIGZv cjxicj4NCnx0cm91Ymxlc2hvb3RpbmcgcHVycG9zZXMgd2lsbCBiZSB1c2VmdWwgZW5vdWdoIHRv IHZlbmRvcnMsIGlmIGV2ZW4gdG88YnI+DQpoZWxwPGJyPg0KfHRoZWlyIG93biBUQUMgd2l0aCBk ZWJ1Z2dpbmcgaXNzdWVzLCB0aGF0IHRoZXkgbGVhdmUgaXQgYWxvbmUgLSBvcjxicj4NCnRoZWly PGJyPg0KfGN1c3RvbWVycyB0byB0ZWxsIHRoZW0gdG8gYW55d2F5Ljxicj4NCnw8YnI+DQp8LWhh ZHJpZWw8YnI+DQp8PGJyPg0KfCZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQp8 Jmd0OyBGcm9tOiBNdXRodSBBcnVsTW96aGkgUGVydW1hbCAobXBlcnVtYWwpIFttYWlsdG86bXBl cnVtYWxAY2lzY28uY29tXTxicj4NCnwmZ3Q7IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMjAsIDIwMTAg MjoxMCBQTTxicj4NCnwmZ3Q7PGJyPg0KfCZndDsgSSBoYXZlIGEgc2VjdXJpdHkgcmVsYXRlZCBj b25jZXJuIHdpdGggc2Vzc2lvbi1pZC4gT25lIG9mIHRoZTxicj4NCnJlcXVpcmVtZW50czxicj4N CnwmZ3Q7IGluIHRoZSBkcmFmdCBpczo8YnI+DQp8Jmd0OyAmbmJzcDsgJm5ic3A7UkVRMmE6IFRo ZSBpZGVudGlmaWVyIG11c3Qgbm90IHJldmVhbCBhbnkgaW5mb3JtYXRpb24NCnJlbGF0ZWQgdG88 YnI+DQphbnk8YnI+DQp8Jmd0OyAmbmJzcDsgJm5ic3A7U0lQIGRldmljZSBvciBkb21haW4gaWRl bnRpdHksIGluY2x1ZGluZyBJUCBBZGRyZXNzLA0KcG9ydCw8YnI+DQpob3N0bmFtZSw8YnI+DQp8 Jmd0OyAmbmJzcDsgJm5ic3A7ZG9tYWluIG5hbWUsIHVzZXJuYW1lLCBBZGRyZXNzLW9mLVJlY29y ZCwgTUFDIGFkZHJlc3MsDQpJUCBhZGRyZXNzPGJyPg0KfCZndDsgJm5ic3A7ICZuYnNwO2ZhbWls eSwgdHJhbnNwb3J0IHR5cGUsIGV0Yy48YnI+DQp8Jmd0Ozxicj4NCnwmZ3Q7IEFuZCB0aGVuIGlz IHNheXM6PGJyPg0KfCZndDsgJm5ic3A7ICZuYnNwO0EgQjJCVUEgY29tcGxpYW50IHdpdGggdGhp cyBkb2N1bWVudCBNVVNUIGNvcHkgdGhlIFNlc3Npb24tSUQ8YnI+DQpoZWFkZXI8YnI+DQp8Jmd0 OyAmbmJzcDsgJm5ic3A7ZmllbGQgaXQgcmVjZWl2ZXMgaW4gcmVxdWVzdHMgYXMgYSBVQVMgaW50 byB0aGUgcmVsYXRlZA0KcmVxdWVzdHM8YnI+DQppdDxicj4NCnwmZ3Q7ICZuYnNwOyAmbmJzcDtn ZW5lcmF0ZXMgYXMgYSBVQUM7IGFuZCBhbnkgU2Vzc2lvbi1JRCBmaWVsZCBpdCByZWNlaXZlcw0K aW48YnI+DQp8Jmd0OyAmbmJzcDsgJm5ic3A7cmVzcG9uc2VzIGFzIGEgVUFDIGludG8gdGhlIGNv cnJlbGF0ZWQgcmVzcG9uc2VzIGl0DQpnZW5lcmF0ZXMgYXMgYTxicj4NCnwmZ3Q7ICZuYnNwOyAm bmJzcDtVQVMuPGJyPg0KfCZndDs8YnI+DQp8Jmd0OyBOb3csIGhvdyBpcyBhIEIyQlVBLCBhbmQg YSBTQkMgaW4gcGFydGljdWxhciwgZ29pbmcgdG8gdmVyaWZ5IHRoYXQ8YnI+DQp8Jmd0OyBzZXNz aW9uLWlkIGlzbid0IHJldmVhbGluZyBhbnkgb2YgdGhlc2UgaW5mb3JtYXRpb24gdW5sZXNzIGl0 PGJyPg0KaW5zcGVjdHMgdGhlPGJyPg0KfCZndDsgc2Vzc2lvbi1pZCBoZWFkZXI/IFdoYXQgaWYg YW4gVUEgdXNlcyB0aGVzZSAxMjgtYml0cyB0byBlbmNvZGUgYW55DQpvZjxicj4NCnwmZ3Q7IHRo ZXNlIGluZm9ybWF0aW9uIHRvIGJ5cGFzcyB0aGUgcG9saWNpZXMgY29uZmlndXJlZCBhdCBhbiBT QkM/IEZvcjxicj4NCnxleGFtcGxlLDxicj4NCnwmZ3Q7IGFuIFVBIGNhbiBzdHVmZiBpbiB1cCB0 byA0IElQdjQgYWRkcmVzc2VzIG9yIGFuIElQdjYgYWRkcmVzcyBpbnRvDQp0aGU8YnI+DQoxMjgt PGJyPg0KfCZndDsgYml0IHNlc3Npb24taWQgaGVhZGVyIHZhbHVlIGFuZCBnZXQgaXQgaW50YWN0 IGFjcm9zcyBhbGwgU0JDPGJyPg0KYnlwYXNzaW5nPGJyPg0KfCZndDsgdGhlaXIgYWRkcmVzcy90 b3BvbG9neSBoaWRpbmcgcG9saWNpZXMuPGJyPg0KfCZndDs8YnI+DQp8Jmd0OyBXb3JzdCwgYSBT QkMgaW4gdGhlIHNpZ25hbGluZyBwYXRoIGNhbiBzdHJpcCBvZmYgdGhlIGluY29taW5nPGJyPg0K c2Vzc2lvbi1pZCw8YnI+DQp8Jmd0OyBjb25zdHJ1Y3QgYSBuZXcgc2Vzc2lvbi1pZCwgZW5jb2Rp bmcgc29tZSBpbmZvcm1hdGlvbiBpbnRvIGl0IGluPGJyPg0Kb3JkZXIgdG88YnI+DQp8Jmd0OyBi eXBhc3MgdGhlIHBvbGljaWVzIGNvbmZpZ3VyZWQgaW4gdXBzdHJlYW0gU0JDcywgYW5kIHNlbmQg aXQgb3V0Ljxicj4NCldoZW4gaXQ8YnI+DQp8Jmd0OyByZWNlaXZlcyB0aGUgcmVzcG9uc2UsIGl0 IGRvZXMgdGhlIHJldmVyc2UgYW5kIHNlbmRzIHRoZSBvcmlnaW5hbDxicj4NCnNlc3Npb24tPGJy Pg0KfCZndDsgaWQgYmFjayAtLSBhIGtpbmQgb2YgbWFuLWluLXRoZS1taWRkbGUgYXR0YWNrIHRo YXQgbm9uZSBvZiB0aGUgU0lQPGJyPg0KfCZndDsgZWxlbWVudHMgY2FuIGRldGVjdCwgdW5sZXNz IHNvbWVvbmUgY2FwdHVyZXMgdGhlIG1lc3NhZ2VzIGFjcm9zcw0KYm90aDxicj4NCnwmZ3Q7IHNp ZGVzIG9mIHRoaXMgU0JDLjxicj4NCnwmZ3Q7PGJyPg0KfCZndDsgSSBhbSBub3Qgc3VyZSBTQkMg dmVuZG9ycyBhcmUgZ29pbmcgdG8gYmUgY29tZm9ydGFibGUgYmxpbmRseTxicj4NCnRydXN0aW5n IHRoZTxicj4NCnwmZ3Q7IHNlbmRlciBhbmQgY29uc2lkZXJpbmcgc2Vzc2lvbi1pZCBhcyBhbiBv cGFxdWUgZGF0YS4gVW5sZXNzIHdlIHNvbHZlPGJyPg0KdGhpczxicj4NCnwmZ3Q7IHByb2JsZW0g dGhleSBtaWdodCBiZSByZWx1Y3RhbnQgdG8gc3VwcG9ydCBzZXNzaW9uLWlkLjxicj4NCjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KZGlz cGF0Y2ggbWFpbGluZyBsaXN0PGJyPg0KZGlzcGF0Y2hAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoPGJyPg0KPGJyPg0KPC9mb250Pjwv dHQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5 Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5i c3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVy dHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNw O1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50 aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7 b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJz cDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7 dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5i c3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJz cDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7 Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3Im bmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtv ciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDth ZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0 aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5 Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4m bmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNw O21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZp ZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZu YnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNw O2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 000C4AE448257767_=-- From mperumal@cisco.com Tue Jul 20 23:36:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECFC83A6A5B for ; Tue, 20 Jul 2010 23:36:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.486 X-Spam-Level: X-Spam-Status: No, score=-9.486 tagged_above=-999 required=5 tests=[AWL=1.113, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fOvcL4rc7oD for ; Tue, 20 Jul 2010 23:36:16 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 853853A69E0 for ; Tue, 20 Jul 2010 23:36:16 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALcxRkxAaHte/2dsb2JhbACfcnGkEZsVgmuCRwSDfocR Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-3.cisco.com with ESMTP; 21 Jul 2010 06:36:31 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6L6aUaP007913; Wed, 21 Jul 2010 06:36:30 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Jul 2010 12:06:28 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jul 2010 12:06:25 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020332AC36@XMB-BGL-414.cisco.com> In-Reply-To: <4C4609B0.7000109@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsoS9v0ynt4N4d6Rwe2EqybIhxkcwAUK4lw References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> <1D062974A4845E4D8A343C65380492020332AB3A@XMB-BGL-414.cisco.com> <4C4609B0.7000109@nostrum.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Adam Roach" X-OriginalArrivalTime: 21 Jul 2010 06:36:28.0178 (UTC) FILETIME=[0C51A720:01CB289F] Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 06:36:18 -0000 The fact that there are many backdoors doesn't seem a good excuse for opening one more, especially when there is a possibility of building that 4-foot-thick solid metal door. Irrespective of whether we add this verifiability requirement or not, the fact that session-id can be extended using header parameters isn't going to stop someone from adding that capability -- if IETF doesn't do it, don't be surprised if 3GPP standardizes it -:) Muthu=20 |-----Original Message----- |From: Adam Roach [mailto:adam@nostrum.com] |Sent: Wednesday, July 21, 2010 2:10 AM |To: Muthu ArulMozhi Perumal (mperumal) |Cc: Hadriel Kaplan; dispatch@ietf.org |Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 | | | No, this is ridiculous. | |There is no point to having a 4-foot-thick solid metal door that can |withstand a nuclear blast next to a large, open window. Unless you're |planning on locking down every other bit of information that can |possibly go between user agents -- including the media -- this kind of |requirement is paranoid overkill. | |/a | |On 7/20/10 15:33, Jul 20, Muthu ArulMozhi Perumal (mperumal) wrote: |> Hadriel, |> |> I agree with most of what you are saying. However, my questions is, do |> we want to just ignore it, acknowledging session-id as yet another |> header through which information can be leaked bypassing SBC policies, |> or develop a mechanism to equip a SBC with the ability to actually |> verify that the session-id was indeed constructed form the Call-ID and |> doesn't reveal anything else, boosting the confidence of SBC vendors. |> |> Once quick solution I can think of is, the UA generating a session-id |> could share a secret with its SBC. It can then encrypt the 128-bit |> pseudo-random key it generates for constructing the hash with this |> shared secret, and attach the encrypted value as a session-id header |> parameter. The SBC can then decrypt the key (using the shared secret), |> re-compute the hash of the incoming Call-ID, compare it with the |> session-id value to make sure it was indeed constructed as it should |> have been. |> |> Off course, it doesn't prevent a SBC in performing a man-in-the-middle |> kind of an attack, but might be worth exploring. |> |> So, if we do want to address it, we could add another requirement like |> this: |> |> REQ2c: It should be possible to verify that the identifier does not |> reveal |> any information related to any SIP device or domain identity, |> including |> IP Address, port, hostname, domain name, username, Address-of-Record, |> MAC |> address, IP address family, transport type, etc. |> |> The WG can then break its head to see how to solve it -:) |> |> Muthu |> |> |-----Original Message----- |> |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] |> |Sent: Wednesday, July 21, 2010 12:49 AM |> |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org |> |Subject: RE: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 |> | |> |Hi Muthu, |> |See section 9.2 of the draft, which has some text around some of the |> issues |> |you raised. |> | |> |As for the issue of a UA maliciously trying to pass through addressing |> in |> |the session-id value, that's unavoidable and not a real issue I think. |> It's |> |unavoidable because there are multiple ways for a UA which is really |> intent |> |on getting IP Addressing through an SBC to do so anyway, at least by |> |encoding it in the media. But I also think it's not a real issue |> because in |> |my opinion generally SBC's hide the IP Addressing because people _want_ |> it |> |hidden. Even the end-users generally want it hidden; if they don't, if |> they |> |want to learn IP Addresses of each other, nothing will stop them from |> just |> |telling each other what it is. (since it takes both sides to collude |> for it |> |to work anyway) |> | |> |But as the draft points out, if some vendor (including SBC vendors |> |themselves) use this header for some nefarious purpose, then no RFC can |> |prevent them from doing so; but what will happen is the word will get |> out |> |and the SBC vendors will be forced to remove/replace the header, |> negating |> |its value to all. |> | |> |I think/hope the need for a consistent value which crosses b2bua's for |> |troubleshooting purposes will be useful enough to vendors, if even to |> help |> |their own TAC with debugging issues, that they leave it alone - or |> their |> |customers to tell them to anyway. |> | |> |-hadriel |> | |> |> -----Original Message----- |> |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> |> Sent: Tuesday, July 20, 2010 2:10 PM |> |> |> |> I have a security related concern with session-id. One of the |> requirements |> |> in the draft is: |> |> REQ2a: The identifier must not reveal any information related to |> any |> |> SIP device or domain identity, including IP Address, port, |> hostname, |> |> domain name, username, Address-of-Record, MAC address, IP address |> |> family, transport type, etc. |> |> |> |> And then is says: |> |> A B2BUA compliant with this document MUST copy the Session-ID |> header |> |> field it receives in requests as a UAS into the related requests |> it |> |> generates as a UAC; and any Session-ID field it receives in |> |> responses as a UAC into the correlated responses it generates as a |> |> UAS. |> |> |> |> Now, how is a B2BUA, and a SBC in particular, going to verify that |> |> session-id isn't revealing any of these information unless it |> inspects the |> |> session-id header? What if an UA uses these 128-bits to encode any of |> |> these information to bypass the policies configured at an SBC? For |> |example, |> |> an UA can stuff in up to 4 IPv4 addresses or an IPv6 address into the |> 128- |> |> bit session-id header value and get it intact across all SBC |> bypassing |> |> their address/topology hiding policies. |> |> |> |> Worst, a SBC in the signaling path can strip off the incoming |> session-id, |> |> construct a new session-id, encoding some information into it in |> order to |> |> bypass the policies configured in upstream SBCs, and send it out. |> When it |> |> receives the response, it does the reverse and sends the original |> session- |> |> id back -- a kind of man-in-the-middle attack that none of the SIP |> |> elements can detect, unless someone captures the messages across both |> |> sides of this SBC. |> |> |> |> I am not sure SBC vendors are going to be comfortable blindly |> trusting the |> |> sender and considering session-id as an opaque data. Unless we solve |> this |> |> problem they might be reluctant to support session-id. |> |> _______________________________________________ |> dispatch mailing list |> dispatch@ietf.org |> https://www.ietf.org/mailman/listinfo/dispatch From gao.yang2@zte.com.cn Wed Jul 21 01:08:48 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51EAD3A6B80 for ; Wed, 21 Jul 2010 01:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.285 X-Spam-Level: X-Spam-Status: No, score=-99.285 tagged_above=-999 required=5 tests=[AWL=2.553, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uAgQSkT3pxUn for ; Wed, 21 Jul 2010 01:08:47 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id CDBFD3A6B7D for ; Wed, 21 Jul 2010 01:08:46 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 20595992332426; Wed, 21 Jul 2010 16:08:10 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 83990.4777041583; Wed, 21 Jul 2010 16:08:59 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6L7vFWc053822; Wed, 21 Jul 2010 15:58:40 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <1D062974A4845E4D8A343C65380492020332AC36@XMB-BGL-414.cisco.com> To: "Muthu ArulMozhi Perumal (mperumal)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 21 Jul 2010 15:54:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-21 15:58:30, Serialize complete at 2010-07-21 15:58:30 Content-Type: multipart/alternative; boundary="=_alternative 002BB5C648257767_=" X-MAIL: mse2.zte.com.cn o6L7vFWc053822 Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 08:08:48 -0000 This is a multipart message in MIME format. --=_alternative 002BB5C648257767_= Content-Type: text/plain; charset="US-ASCII" Muthu, > Irrespective of whether we add this verifiability requirement or not, > the fact that session-id can be extended using header parameters isn't > going to stop someone from adding that capability -- if IETF doesn't do > it, don't be surprised if 3GPP standardizes it -:) +1 for this point. And this is a important and general issue for interworking of 3GPP's equipment and common SIP network. And as Hadriel has pointed out in the draft: Although the Session-ID concept is similar to the Call-ID, it is not used for message dialog-matching rules in RFC 3261, nor does it change the Call-ID usage, nor does it replace the Call-ID value. Instead this new header field provides an identifier for troubleshooting uses only. So, I guess if all of us can stick to this declaration, it would be OK. Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 002BB5C648257767_= Content-Type: text/html; charset="US-ASCII"
Muthu,

> Irrespective of whether we add this verifiability requirement or not,
> the fact that session-id can be extended using header parameters isn't
> going to stop someone from adding that capability -- if IETF doesn't do
> it, don't be surprised if 3GPP standardizes it -:)

+1 for this point.
And this is a important and general issue for interworking of 3GPP's equipment and common SIP network.

And as Hadriel has pointed out in the draft:
Although the Session-ID concept is similar to the Call-ID, it is not
   used for message dialog-matching rules in RFC 3261, nor does it
   change the Call-ID usage, nor does it replace the Call-ID value.  
   Instead this new header field provides an identifier for
   troubleshooting uses only.

So, I guess if all of us can stick to this declaration, it would be OK.

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 002BB5C648257767_=-- From john.elwell@siemens-enterprise.com Wed Jul 21 01:11:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ADE93A687A for ; Wed, 21 Jul 2010 01:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.021 X-Spam-Level: X-Spam-Status: No, score=-3.021 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKius6-yb8FY for ; Wed, 21 Jul 2010 01:11:39 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 774613A67BD for ; Wed, 21 Jul 2010 01:11:39 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-916957; Wed, 21 Jul 2010 10:11:54 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 5B1C61EB82AE; Wed, 21 Jul 2010 10:11:54 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 21 Jul 2010 10:11:54 +0200 From: "Elwell, John" To: "Muthu ArulMozhi Perumal (mperumal)" , Hadriel Kaplan , "dispatch@ietf.org" Date: Wed, 21 Jul 2010 10:11:52 +0200 Thread-Topic: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsiqbaMfHyiLn9KSoGceaY0EYk4fwFgwYwwAAQhZKAAAgWLcAAZma/g Message-ID: References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> <1D062974A4845E4D8A343C65380492020332AB3A@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020332AB3A@XMB-BGL-414.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 08:11:41 -0000 =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Muthu=20 > ArulMozhi Perumal (mperumal) > Sent: 20 July 2010 21:33 > To: Hadriel Kaplan; dispatch@ietf.org > Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 >=20 > Hadriel, >=20 > I agree with most of what you are saying. However, my questions is, do > we want to just ignore it, acknowledging session-id as yet another > header through which information can be leaked bypassing SBC policies, > or develop a mechanism to equip a SBC with the ability to actually > verify that the session-id was indeed constructed form the Call-ID and > doesn't reveal anything else, boosting the confidence of SBC vendors. >=20 > Once quick solution I can think of is, the UA generating a session-id > could share a secret with its SBC.=20 [JRE] Sharing a secret with "its SBC", whatever that might mean, might be p= ossible, but what about downstream SBCs? A SIP request can potentially trav= erse any number of SBCs. I agree with those who say this is a problem we don't need to solve, since = there are so many other ways a UA could deliberately convey sensitive infor= mation through an SBC. Just a brief discussion of the issue under Security = Considerations should suffice. John It can then encrypt the 128-bit > pseudo-random key it generates for constructing the hash with this > shared secret, and attach the encrypted value as a session-id header > parameter. The SBC can then decrypt the key (using the shared secret), > re-compute the hash of the incoming Call-ID, compare it with the > session-id value to make sure it was indeed constructed as it should > have been. >=20 > Off course, it doesn't prevent a SBC in performing a man-in-the-middle > kind of an attack, but might be worth exploring. >=20 > So, if we do want to address it, we could add another requirement like > this: >=20 > REQ2c: It should be possible to verify that the identifier does not > reveal=20 > any information related to any SIP device or domain identity, > including > IP Address, port, hostname, domain name, username,=20 > Address-of-Record, > MAC=20 > address, IP address family, transport type, etc.=20 >=20 > The WG can then break its head to see how to solve it -:) >=20 > Muthu > =20 > |-----Original Message----- > |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > |Sent: Wednesday, July 21, 2010 12:49 AM > |To: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org > |Subject: RE: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 > | > |Hi Muthu, > |See section 9.2 of the draft, which has some text around some of the > issues > |you raised. > | > |As for the issue of a UA maliciously trying to pass through=20 > addressing > in > |the session-id value, that's unavoidable and not a real=20 > issue I think. > It's > |unavoidable because there are multiple ways for a UA which is really > intent > |on getting IP Addressing through an SBC to do so anyway, at least by > |encoding it in the media. But I also think it's not a real issue > because in > |my opinion generally SBC's hide the IP Addressing because=20 > people _want_ > it > |hidden. Even the end-users generally want it hidden; if=20 > they don't, if > they > |want to learn IP Addresses of each other, nothing will stop them from > just > |telling each other what it is. (since it takes both sides to collude > for it > |to work anyway) > | > |But as the draft points out, if some vendor (including SBC vendors > |themselves) use this header for some nefarious purpose, then=20 > no RFC can > |prevent them from doing so; but what will happen is the word will get > out > |and the SBC vendors will be forced to remove/replace the header, > negating > |its value to all. > | > |I think/hope the need for a consistent value which crosses=20 > b2bua's for > |troubleshooting purposes will be useful enough to vendors, if even to > help > |their own TAC with debugging issues, that they leave it alone - or > their > |customers to tell them to anyway. > | > |-hadriel > | > |> -----Original Message----- > |> From: Muthu ArulMozhi Perumal (mperumal)=20 > [mailto:mperumal@cisco.com] > |> Sent: Tuesday, July 20, 2010 2:10 PM > |> > |> I have a security related concern with session-id. One of the > requirements > |> in the draft is: > |> REQ2a: The identifier must not reveal any information related to > any > |> SIP device or domain identity, including IP Address, port, > hostname, > |> domain name, username, Address-of-Record, MAC address,=20 > IP address > |> family, transport type, etc. > |> > |> And then is says: > |> A B2BUA compliant with this document MUST copy the Session-ID > header > |> field it receives in requests as a UAS into the related requests > it > |> generates as a UAC; and any Session-ID field it receives in > |> responses as a UAC into the correlated responses it=20 > generates as a > |> UAS. > |> > |> Now, how is a B2BUA, and a SBC in particular, going to verify that > |> session-id isn't revealing any of these information unless it > inspects the > |> session-id header? What if an UA uses these 128-bits to=20 > encode any of > |> these information to bypass the policies configured at an SBC? For > |example, > |> an UA can stuff in up to 4 IPv4 addresses or an IPv6=20 > address into the > 128- > |> bit session-id header value and get it intact across all SBC > bypassing > |> their address/topology hiding policies. > |> > |> Worst, a SBC in the signaling path can strip off the incoming > session-id, > |> construct a new session-id, encoding some information into it in > order to > |> bypass the policies configured in upstream SBCs, and send it out. > When it > |> receives the response, it does the reverse and sends the original > session- > |> id back -- a kind of man-in-the-middle attack that none of the SIP > |> elements can detect, unless someone captures the messages=20 > across both > |> sides of this SBC. > |> > |> I am not sure SBC vendors are going to be comfortable blindly > trusting the > |> sender and considering session-id as an opaque data.=20 > Unless we solve > this > |> problem they might be reluctant to support session-id. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From tme@americafree.tv Wed Jul 21 08:35:58 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 202943A681C for ; Wed, 21 Jul 2010 08:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqJeTctIo+Qq for ; Wed, 21 Jul 2010 08:35:56 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 271413A6359 for ; Wed, 21 Jul 2010 08:35:56 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 0783080B1573; Wed, 21 Jul 2010 11:36:11 -0400 (EDT) Message-Id: <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> From: Marshall Eubanks To: Marshall Eubanks In-Reply-To: <7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Jul 2010 11:36:11 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com> <27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com> <04ac01cb1ee4$ea7712c0$bf653840$@com> <04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com> <114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg> <4C3E3FF6.1050003@cisco.com> <7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 15:35:58 -0000 OK, here are the tabulations : On Jul 15, 2010, at 11:03 AM, Marshall Eubanks wrote: > OK, here are the options I see > > There is an informal Bar BOF list > > http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 > > Wednesday Lunch, thursday Lunch or Thursday before plenary are taken. > > I would suggest > Here are the respondents so far : TME - Marshall JE - John Elwell DM - Daryl Malas MB - Mary Barnes PK - Paul Kyzivat PR - Partr Monday night - TME prefer, JE prefer, DM prefer, MB prefer* Wednesday after plenary, JE Prefer, MB prefer Thursday after plenary - JE avoid, MB prefer, PK & PR avoid (E2MD collision) Friday Lunch - JE avoid DM prefer * after the meeting, not after dinner So, sifting through all of this, I come up with Monday night _before dinner_. Does that seen OK, or should I set up a proper doodle ? Regards Marshall > > I would prefer Monday night, but these all WFM. Please let me know > what you think. > > Regards > Marshall > > > On Jul 15, 2010, at 9:57 AM, Elwell, John wrote: > >> I would try to join if there is no conflict. >> >> John >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Marshall Eubanks >>> Sent: 15 July 2010 01:06 >>> To: Paul Kyzivat >>> Cc: DISPATCH list; Daryl Malas >>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>> >>> Should we arrange a (true) Bar BOF (AKA DrinkTime) for this topic in >>> Maastricht ? >>> >>> Marshall >>> >>> On Jul 14, 2010, at 6:53 PM, Paul Kyzivat wrote: >>> >>>> I won't comment on the rest of this right now, >>>> but its not right to describe a B2BUA as a function of an SBC. >>>> Rather, an SBC is a particular sort of B2BUA. >>>> There are *many* sorts of B2BUA that have nothing in common >>> with an >>>> SBC. >>>> >>>> Its actually this sort of disagreement that would benefit from >>>> beginning a taxonomy of B2BUAs. >>>> >>>> Thanks, >>>> Paul >>>> >>>> Daryl Malas wrote: >>>>> All, >>>>> Many if not all of the functions of an SBC have already been >>>>> defined in one way or another. An SBC is a "jack-of-all-trades" >>>>> platform. I think this is a slippery slope to try and >>> define, and >>>>> is a quagmire the IETF should stray from. In some cases, >>> SBCs are >>>>> not even deployed on the edge of networks. >>>>> I agree that a B2BUA is different, but it could be considered a >>>>> function of the SBC. B2BUA's were created with the intention of >>>>> breaking up the end-to-end environment, so creating rules >>> to define >>>>> allowances for the end-to-end environment will be challenging at >>>>> best. >>>>> Regards, >>>>> Daryl >>>>> -----Original Message----- >>>>> From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] >>>>> On Behalf Of Christer Holmberg >>>>> Sent: Friday, July 09, 2010 12:44 PM >>>>> To: Paul Kyzivat; Mohammad Al-Taraireh (maltarai) >>>>> Cc: DISPATCH list >>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>> Hi, >>>>> Rather than focus on node terminology, I think we should focus on >>>>> the FUNCTIONS they perform, and see whether something can do done >>>>> in order to avoid claimed interop problems etc, rather >>> than arguing >>>>> about whether the entity that performs the function shall >>> be called >>>>> B2BUA, SBC, Application Server, or something else... >>>>> Regards, >>>>> Christer >>>>> ________________________________________ >>>>> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On >>>>> Behalf Of Paul Kyzivat [pkyzivat@cisco.com] >>>>> Sent: Friday, July 09, 2010 3:10 AM >>>>> To: Mohammad Al-Taraireh (maltarai) >>>>> Cc: DISPATCH list >>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>> Mohammad Al-Taraireh (maltarai) wrote: >>>>>> Doesn't the B2BUA term also implies media origination, and >>>>>> termination capabilities ? It seems that the B2BUA term >>> is already >>>>>> overloaded to include SBC. >>>>> The term "B2BUA" is distinguished by the minimality of its >>>>> definition and the corresponding broadness of applicability. It >>>>> neither implies nor forbids media processing. >>>>> The term SBC, as typically used, is somewhat narrower in >>> scope that >>>>> B2BUA, but is still incredibly broad. I certainly know of things >>>>> that consider themselves to be SBCs that (at least >>> sometimes) don't >>>>> terminate media. >>>>> And certainly there are B2BUAs that *do* terminate media that you >>>>> would not want to call an SBC. (E.g. a conference focus and >>>>> mixer.) >>>>> Thanks, >>>>> Paul >>>>>> Mo >>>>>> >>>>>> -----Original Message----- >>>>>> From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] >>>>>> On Behalf Of Dan Wing (dwing) >>>>>> Sent: Thursday, July 08, 2010 5:31 PM >>>>>> To: Cullen Jennings (fluffy) >>>>>> Cc: 'DISPATCH list' >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>>> Sent: Thursday, July 08, 2010 1:34 PM >>>>>>> To: Dan Wing >>>>>>> Cc: DISPATCH list >>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>> >>>>>>> >>>>>>> Seems reasonable. I think B2BUA is reasonable well >>> defined. Care >>>>>>> to put on your fire proof suit and propose a definition of what >>>>>>> an SBC >>>>>> is? >>>>>> >>>>>> SBC: a B2BUA that also terminates and originates media from user >>>>>> agents or media from an adjacent SBC. >>>>>> >>>>>> -d >>>>>> >>>>>> >>>>>>> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>>>>>>> Sent: Thursday, July 08, 2010 5:50 AM >>>>>>>>> To: Dan Wing >>>>>>>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; 'DISPATCH list' >>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>>>> >>>>>>>>> >>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes >>>>>>>>> - >>>>>>> 03 >>>>>>>>> has just been submitted. >>>>>>>> Splendid. I refer to the media latching in that document >>>>>> frequently. >>>>>>>> Myself, I would be happier if IETF could find it possible to >>>>>>>> include >>>>>>>> the acronym-that-must-not-be-spoken (SBC) in SBC-related >>>>>>>> specifications -- no matter if an SBC working group is >>> formed or >>>>>>>> not. Calling them 'middleboxes' is too vague to be >>> useful, much >>>>>>>> like "gateway" is too vague (a gateway to the PSTN? a >>> router?) >>>>>>>> Call >>>>>>>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, >>> and an SBC >>>>>>>> an SBC. >>>>>>>> >>>>>>>> -d >>>>>>>> >>>>>>>> >>>>>>>>> Dan Wing wrote: >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: dispatch-bounces@ietf.org >>>>>>>>>>> [mailto:dispatch-bounces@ietf.org] >>>>>>>>> On >>>>>>>>>>> Behalf Of Peter Musgrave >>>>>>>>>>> Sent: Thursday, July 01, 2010 12:30 PM >>>>>>>>>>> To: WORLEY, Dale R (Dale) >>>>>>>>>>> Cc: DISPATCH list >>>>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG >>> for SBCs? >>>>>>>>>>> >>>>>>>>>>> I concur. >>>>>>>>>>> >>>>>>>>>>> There is some useful background in RFC5853 and >>> perhaps >>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 >>>>>>>>>>> >>>>>>>>>>> And then some things which died on the vine such as: >>>>>>>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>>>>>>>>> and perhaps some others? >>>>>>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >>>>>>> middleboxes- >>>>>>>>> 02 died. >>>>>>>>>> -d >>>>>>>>> ... >>>>>>>> _______________________________________________ >>>>>>>> dispatch mailing list >>>>>>>> dispatch@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>>> Cullen Jennings >>>>>>> For corporate legal information go to: >>>>>>> >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> _______________________________________________ >>>>> 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 > From dromasca@avaya.com Wed Jul 21 08:38:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 296E13A681C for ; Wed, 21 Jul 2010 08:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDFVv8Na+ZVi for ; Wed, 21 Jul 2010 08:38:52 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 57B363A6359 for ; Wed, 21 Jul 2010 08:38:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,239,1278302400"; d="scan'208";a="228940565" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 21 Jul 2010 11:39:08 -0400 X-IronPort-AV: E=Sophos;i="4.55,238,1278302400"; d="scan'208";a="493536012" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 21 Jul 2010 11:39:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Jul 2010 17:38:56 +0200 Message-ID: In-Reply-To: <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: Acso6ndK102EUzm5SO+WoMWxI1xuugAAEoMA References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com><04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> From: "Romascanu, Dan (Dan)" To: "Marshall Eubanks" Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 15:38:55 -0000 A proper Doodle would be better. I am also interested, and there may be other.=20 Dan =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Marshall Eubanks > Sent: Wednesday, July 21, 2010 6:36 PM > To: Marshall Eubanks > Cc: DISPATCH list; Daryl Malas > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >=20 > OK, here are the tabulations : >=20 > On Jul 15, 2010, at 11:03 AM, Marshall Eubanks wrote: >=20 > > OK, here are the options I see > > > > There is an informal Bar BOF list > > > > http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 > > > > Wednesday Lunch, thursday Lunch or Thursday before plenary=20 > are taken. > > > > I would suggest > > >=20 > Here are the respondents so far : >=20 > TME - Marshall > JE - John Elwell > DM - Daryl Malas > MB - Mary Barnes > PK - Paul Kyzivat > PR - Partr >=20 > Monday night - TME prefer, JE prefer, DM prefer, MB prefer*=20 > Wednesday after plenary, JE Prefer, MB prefer Thursday after=20 > plenary - JE avoid, MB prefer, PK & PR avoid (E2MD > collision) > Friday Lunch - JE avoid DM prefer >=20 > * after the meeting, not after dinner >=20 > So, sifting through all of this, I come up with Monday night=20 > _before dinner_. >=20 > Does that seen OK, or should I set up a proper doodle ? >=20 > Regards > Marshall >=20 >=20 >=20 > > > > I would prefer Monday night, but these all WFM. Please let me know=20 > > what you think. > > > > Regards > > Marshall > > > > > > On Jul 15, 2010, at 9:57 AM, Elwell, John wrote: > > > >> I would try to join if there is no conflict. > >> > >> John > >> > >>> -----Original Message----- > >>> From: dispatch-bounces@ietf.org > >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Marshall Eubanks > >>> Sent: 15 July 2010 01:06 > >>> To: Paul Kyzivat > >>> Cc: DISPATCH list; Daryl Malas > >>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >>> > >>> Should we arrange a (true) Bar BOF (AKA DrinkTime) for=20 > this topic in=20 > >>> Maastricht ? > >>> > >>> Marshall > >>> > >>> On Jul 14, 2010, at 6:53 PM, Paul Kyzivat wrote: > >>> > >>>> I won't comment on the rest of this right now, but its=20 > not right to=20 > >>>> describe a B2BUA as a function of an SBC. > >>>> Rather, an SBC is a particular sort of B2BUA. > >>>> There are *many* sorts of B2BUA that have nothing in common > >>> with an > >>>> SBC. > >>>> > >>>> Its actually this sort of disagreement that would benefit from=20 > >>>> beginning a taxonomy of B2BUAs. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> Daryl Malas wrote: > >>>>> All, > >>>>> Many if not all of the functions of an SBC have already been=20 > >>>>> defined in one way or another. An SBC is a "jack-of-all-trades" > >>>>> platform. I think this is a slippery slope to try and > >>> define, and > >>>>> is a quagmire the IETF should stray from. In some cases, > >>> SBCs are > >>>>> not even deployed on the edge of networks. > >>>>> I agree that a B2BUA is different, but it could be considered a=20 > >>>>> function of the SBC. B2BUA's were created with the=20 > intention of=20 > >>>>> breaking up the end-to-end environment, so creating rules > >>> to define > >>>>> allowances for the end-to-end environment will be=20 > challenging at=20 > >>>>> best. > >>>>> Regards, > >>>>> Daryl > >>>>> -----Original Message----- > >>>>> From: dispatch-bounces@ietf.org > >>> [mailto:dispatch-bounces@ietf.org] > >>>>> On Behalf Of Christer Holmberg > >>>>> Sent: Friday, July 09, 2010 12:44 PM > >>>>> To: Paul Kyzivat; Mohammad Al-Taraireh (maltarai) > >>>>> Cc: DISPATCH list > >>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >>>>> Hi, > >>>>> Rather than focus on node terminology, I think we=20 > should focus on=20 > >>>>> the FUNCTIONS they perform, and see whether something=20 > can do done=20 > >>>>> in order to avoid claimed interop problems etc, rather > >>> than arguing > >>>>> about whether the entity that performs the function shall > >>> be called > >>>>> B2BUA, SBC, Application Server, or something else... > >>>>> Regards, > >>>>> Christer > >>>>> ________________________________________ > >>>>> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On=20 > >>>>> Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > >>>>> Sent: Friday, July 09, 2010 3:10 AM > >>>>> To: Mohammad Al-Taraireh (maltarai) > >>>>> Cc: DISPATCH list > >>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >>>>> Mohammad Al-Taraireh (maltarai) wrote: > >>>>>> Doesn't the B2BUA term also implies media origination, and=20 > >>>>>> termination capabilities ? It seems that the B2BUA term > >>> is already > >>>>>> overloaded to include SBC. > >>>>> The term "B2BUA" is distinguished by the minimality of its=20 > >>>>> definition and the corresponding broadness of applicability. It=20 > >>>>> neither implies nor forbids media processing. > >>>>> The term SBC, as typically used, is somewhat narrower in > >>> scope that > >>>>> B2BUA, but is still incredibly broad. I certainly know=20 > of things=20 > >>>>> that consider themselves to be SBCs that (at least > >>> sometimes) don't > >>>>> terminate media. > >>>>> And certainly there are B2BUAs that *do* terminate=20 > media that you=20 > >>>>> would not want to call an SBC. (E.g. a conference focus and > >>>>> mixer.) > >>>>> Thanks, > >>>>> Paul > >>>>>> Mo > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: dispatch-bounces@ietf.org > >>> [mailto:dispatch-bounces@ietf.org] > >>>>>> On Behalf Of Dan Wing (dwing) > >>>>>> Sent: Thursday, July 08, 2010 5:31 PM > >>>>>> To: Cullen Jennings (fluffy) > >>>>>> Cc: 'DISPATCH list' > >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] > >>>>>>> Sent: Thursday, July 08, 2010 1:34 PM > >>>>>>> To: Dan Wing > >>>>>>> Cc: DISPATCH list > >>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > >>>>>>> > >>>>>>> > >>>>>>> Seems reasonable. I think B2BUA is reasonable well > >>> defined. Care > >>>>>>> to put on your fire proof suit and propose a=20 > definition of what=20 > >>>>>>> an SBC > >>>>>> is? > >>>>>> > >>>>>> SBC: a B2BUA that also terminates and originates=20 > media from user > >>>>>> agents or media from an adjacent SBC. > >>>>>> > >>>>>> -d > >>>>>> > >>>>>> > >>>>>>> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: > >>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] > >>>>>>>>> Sent: Thursday, July 08, 2010 5:50 AM > >>>>>>>>> To: Dan Wing > >>>>>>>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)';=20 > 'DISPATCH list' > >>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE=20 > WG for SBCs? > >>>>>>>>> > >>>>>>>>> > >>>=20 > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes > >>>>>>>>> - > >>>>>>> 03 > >>>>>>>>> has just been submitted. > >>>>>>>> Splendid. I refer to the media latching in that document > >>>>>> frequently. > >>>>>>>> Myself, I would be happier if IETF could find it possible to=20 > >>>>>>>> include the acronym-that-must-not-be-spoken (SBC) in=20 > >>>>>>>> SBC-related specifications -- no matter if an SBC=20 > working group=20 > >>>>>>>> is > >>> formed or > >>>>>>>> not. Calling them 'middleboxes' is too vague to be > >>> useful, much > >>>>>>>> like "gateway" is too vague (a gateway to the PSTN? a > >>> router?) > >>>>>>>> Call > >>>>>>>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, > >>> and an SBC > >>>>>>>> an SBC. > >>>>>>>> > >>>>>>>> -d > >>>>>>>> > >>>>>>>> > >>>>>>>>> Dan Wing wrote: > >>>>>>>>>>> -----Original Message----- > >>>>>>>>>>> From: dispatch-bounces@ietf.org=20 > >>>>>>>>>>> [mailto:dispatch-bounces@ietf.org] > >>>>>>>>> On > >>>>>>>>>>> Behalf Of Peter Musgrave > >>>>>>>>>>> Sent: Thursday, July 01, 2010 12:30 PM > >>>>>>>>>>> To: WORLEY, Dale R (Dale) > >>>>>>>>>>> Cc: DISPATCH list > >>>>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG > >>> for SBCs? > >>>>>>>>>>> > >>>>>>>>>>> I concur. > >>>>>>>>>>> > >>>>>>>>>>> There is some useful background in RFC5853 and > >>> perhaps > >>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 > >>>>>>>>>>> > >>>>>>>>>>> And then some things which died on the vine such as: > >>>>>>>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 > >>>>>>>>>>> and perhaps some others? > >>>>>>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- > >>>>>>> middleboxes- > >>>>>>>>> 02 died. > >>>>>>>>>> -d > >>>>>>>>> ... > >>>>>>>> _______________________________________________ > >>>>>>>> dispatch mailing list > >>>>>>>> dispatch@ietf.org > >>>>>>>> https://www.ietf.org/mailman/listinfo/dispatch > >>>>>>> Cullen Jennings > >>>>>>> For corporate legal information go to: > >>>>>>> > >>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html > >>>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > >>>>> _______________________________________________ > >>>>> 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 > > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 From tme@americafree.tv Wed Jul 21 08:54:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 213883A693D for ; Wed, 21 Jul 2010 08:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.445 X-Spam-Level: X-Spam-Status: No, score=-102.445 tagged_above=-999 required=5 tests=[AWL=0.154, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbPdtADa5E-w for ; Wed, 21 Jul 2010 08:54:15 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id A9C783A692C for ; Wed, 21 Jul 2010 08:54:14 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 0D21280B1F5A; Wed, 21 Jul 2010 11:54:31 -0400 (EDT) Message-Id: <15655197-E667-4A1F-BD12-1A1961081D7D@americafree.tv> From: Marshall Eubanks To: "Romascanu, Dan (Dan)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Jul 2010 11:54:30 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com><04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 15:54:17 -0000 On Jul 21, 2010, at 11:38 AM, Romascanu, Dan (Dan) wrote: > A proper Doodle would be better. I am also interested, and there may > be > other. > Ask, and ye shall receive. http://www.doodle.com/f5bniwsrsndr29y3 Please send this to other people / lists as you feel necessary. Notes : green = prefer this time yellow = could make this time if necessary red = cannot make this time I have separated the evening meeting possibilities into - Just after the end of the IETF (i.e., AT or BEFORE dinner - A little over 1 hour later (i.e., AFTER dinner) If you think 1 hour is not enough for dinner, but prefer the after dinner time, please vote for after dinner anyway and send a comment to this list. If we pick an after dinner time, we might adjust the actual rendezvous time. If you have another time, suggest it. Regards Marshall > Dan > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Marshall Eubanks >> Sent: Wednesday, July 21, 2010 6:36 PM >> To: Marshall Eubanks >> Cc: DISPATCH list; Daryl Malas >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >> >> OK, here are the tabulations : >> >> On Jul 15, 2010, at 11:03 AM, Marshall Eubanks wrote: >> >>> OK, here are the options I see >>> >>> There is an informal Bar BOF list >>> >>> http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 >>> >>> Wednesday Lunch, thursday Lunch or Thursday before plenary >> are taken. >>> >>> I would suggest >>> >> >> Here are the respondents so far : >> >> TME - Marshall >> JE - John Elwell >> DM - Daryl Malas >> MB - Mary Barnes >> PK - Paul Kyzivat >> PR - Partr >> >> Monday night - TME prefer, JE prefer, DM prefer, MB prefer* >> Wednesday after plenary, JE Prefer, MB prefer Thursday after >> plenary - JE avoid, MB prefer, PK & PR avoid (E2MD >> collision) >> Friday Lunch - JE avoid DM prefer >> >> * after the meeting, not after dinner >> >> So, sifting through all of this, I come up with Monday night >> _before dinner_. >> >> Does that seen OK, or should I set up a proper doodle ? >> >> Regards >> Marshall >> >> >> >>> >>> I would prefer Monday night, but these all WFM. Please let me know >>> what you think. >>> >>> Regards >>> Marshall >>> >>> >>> On Jul 15, 2010, at 9:57 AM, Elwell, John wrote: >>> >>>> I would try to join if there is no conflict. >>>> >>>> John >>>> >>>>> -----Original Message----- >>>>> From: dispatch-bounces@ietf.org >>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Marshall Eubanks >>>>> Sent: 15 July 2010 01:06 >>>>> To: Paul Kyzivat >>>>> Cc: DISPATCH list; Daryl Malas >>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>> >>>>> Should we arrange a (true) Bar BOF (AKA DrinkTime) for >> this topic in >>>>> Maastricht ? >>>>> >>>>> Marshall >>>>> >>>>> On Jul 14, 2010, at 6:53 PM, Paul Kyzivat wrote: >>>>> >>>>>> I won't comment on the rest of this right now, but its >> not right to >>>>>> describe a B2BUA as a function of an SBC. >>>>>> Rather, an SBC is a particular sort of B2BUA. >>>>>> There are *many* sorts of B2BUA that have nothing in common >>>>> with an >>>>>> SBC. >>>>>> >>>>>> Its actually this sort of disagreement that would benefit from >>>>>> beginning a taxonomy of B2BUAs. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> Daryl Malas wrote: >>>>>>> All, >>>>>>> Many if not all of the functions of an SBC have already been >>>>>>> defined in one way or another. An SBC is a "jack-of-all-trades" >>>>>>> platform. I think this is a slippery slope to try and >>>>> define, and >>>>>>> is a quagmire the IETF should stray from. In some cases, >>>>> SBCs are >>>>>>> not even deployed on the edge of networks. >>>>>>> I agree that a B2BUA is different, but it could be considered a >>>>>>> function of the SBC. B2BUA's were created with the >> intention of >>>>>>> breaking up the end-to-end environment, so creating rules >>>>> to define >>>>>>> allowances for the end-to-end environment will be >> challenging at >>>>>>> best. >>>>>>> Regards, >>>>>>> Daryl >>>>>>> -----Original Message----- >>>>>>> From: dispatch-bounces@ietf.org >>>>> [mailto:dispatch-bounces@ietf.org] >>>>>>> On Behalf Of Christer Holmberg >>>>>>> Sent: Friday, July 09, 2010 12:44 PM >>>>>>> To: Paul Kyzivat; Mohammad Al-Taraireh (maltarai) >>>>>>> Cc: DISPATCH list >>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>> Hi, >>>>>>> Rather than focus on node terminology, I think we >> should focus on >>>>>>> the FUNCTIONS they perform, and see whether something >> can do done >>>>>>> in order to avoid claimed interop problems etc, rather >>>>> than arguing >>>>>>> about whether the entity that performs the function shall >>>>> be called >>>>>>> B2BUA, SBC, Application Server, or something else... >>>>>>> Regards, >>>>>>> Christer >>>>>>> ________________________________________ >>>>>>> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On >>>>>>> Behalf Of Paul Kyzivat [pkyzivat@cisco.com] >>>>>>> Sent: Friday, July 09, 2010 3:10 AM >>>>>>> To: Mohammad Al-Taraireh (maltarai) >>>>>>> Cc: DISPATCH list >>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>> Mohammad Al-Taraireh (maltarai) wrote: >>>>>>>> Doesn't the B2BUA term also implies media origination, and >>>>>>>> termination capabilities ? It seems that the B2BUA term >>>>> is already >>>>>>>> overloaded to include SBC. >>>>>>> The term "B2BUA" is distinguished by the minimality of its >>>>>>> definition and the corresponding broadness of applicability. It >>>>>>> neither implies nor forbids media processing. >>>>>>> The term SBC, as typically used, is somewhat narrower in >>>>> scope that >>>>>>> B2BUA, but is still incredibly broad. I certainly know >> of things >>>>>>> that consider themselves to be SBCs that (at least >>>>> sometimes) don't >>>>>>> terminate media. >>>>>>> And certainly there are B2BUAs that *do* terminate >> media that you >>>>>>> would not want to call an SBC. (E.g. a conference focus and >>>>>>> mixer.) >>>>>>> Thanks, >>>>>>> Paul >>>>>>>> Mo >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: dispatch-bounces@ietf.org >>>>> [mailto:dispatch-bounces@ietf.org] >>>>>>>> On Behalf Of Dan Wing (dwing) >>>>>>>> Sent: Thursday, July 08, 2010 5:31 PM >>>>>>>> To: Cullen Jennings (fluffy) >>>>>>>> Cc: 'DISPATCH list' >>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>>>>> Sent: Thursday, July 08, 2010 1:34 PM >>>>>>>>> To: Dan Wing >>>>>>>>> Cc: DISPATCH list >>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>>>> >>>>>>>>> >>>>>>>>> Seems reasonable. I think B2BUA is reasonable well >>>>> defined. Care >>>>>>>>> to put on your fire proof suit and propose a >> definition of what >>>>>>>>> an SBC >>>>>>>> is? >>>>>>>> >>>>>>>> SBC: a B2BUA that also terminates and originates >> media from user >>>>>>>> agents or media from an adjacent SBC. >>>>>>>> >>>>>>>> -d >>>>>>>> >>>>>>>> >>>>>>>>> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >>>>>>>>> >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>>>>>>>>> Sent: Thursday, July 08, 2010 5:50 AM >>>>>>>>>>> To: Dan Wing >>>>>>>>>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; >> 'DISPATCH list' >>>>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE >> WG for SBCs? >>>>>>>>>>> >>>>>>>>>>> >>>>> >> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes >>>>>>>>>>> - >>>>>>>>> 03 >>>>>>>>>>> has just been submitted. >>>>>>>>>> Splendid. I refer to the media latching in that document >>>>>>>> frequently. >>>>>>>>>> Myself, I would be happier if IETF could find it possible to >>>>>>>>>> include the acronym-that-must-not-be-spoken (SBC) in >>>>>>>>>> SBC-related specifications -- no matter if an SBC >> working group >>>>>>>>>> is >>>>> formed or >>>>>>>>>> not. Calling them 'middleboxes' is too vague to be >>>>> useful, much >>>>>>>>>> like "gateway" is too vague (a gateway to the PSTN? a >>>>> router?) >>>>>>>>>> Call >>>>>>>>>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, >>>>> and an SBC >>>>>>>>>> an SBC. >>>>>>>>>> >>>>>>>>>> -d >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Dan Wing wrote: >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: dispatch-bounces@ietf.org >>>>>>>>>>>>> [mailto:dispatch-bounces@ietf.org] >>>>>>>>>>> On >>>>>>>>>>>>> Behalf Of Peter Musgrave >>>>>>>>>>>>> Sent: Thursday, July 01, 2010 12:30 PM >>>>>>>>>>>>> To: WORLEY, Dale R (Dale) >>>>>>>>>>>>> Cc: DISPATCH list >>>>>>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG >>>>> for SBCs? >>>>>>>>>>>>> >>>>>>>>>>>>> I concur. >>>>>>>>>>>>> >>>>>>>>>>>>> There is some useful background in RFC5853 and >>>>> perhaps >>>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 >>>>>>>>>>>>> >>>>>>>>>>>>> And then some things which died on the vine such as: >>>>>>>>>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>>>>>>>>>>> and perhaps some others? >>>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >>>>>>>>> middleboxes- >>>>>>>>>>> 02 died. >>>>>>>>>>>> -d >>>>>>>>>>> ... >>>>>>>>>> _______________________________________________ >>>>>>>>>> dispatch mailing list >>>>>>>>>> dispatch@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>>>>> Cullen Jennings >>>>>>>>> For corporate legal information go to: >>>>>>>>> >>>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>>> _______________________________________________ >>>>>>> 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 >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > From john.elwell@siemens-enterprise.com Wed Jul 21 13:35:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59DA83A6B84 for ; Wed, 21 Jul 2010 13:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.075 X-Spam-Level: X-Spam-Status: No, score=-3.075 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMoZvnVcv6yt for ; Wed, 21 Jul 2010 13:34:56 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 645033A6B90 for ; Wed, 21 Jul 2010 13:32:05 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-928709 for dispatch@ietf.org; Wed, 21 Jul 2010 22:31:57 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 4543B1EB82AB for ; Wed, 21 Jul 2010 22:31:57 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 21 Jul 2010 22:31:57 +0200 From: "Elwell, John" To: "dispatch@ietf.org" Date: Wed, 21 Jul 2010 22:31:54 +0200 Thread-Topic: Progressing draft-kaplan-dispatch-session-id-02 Thread-Index: AcspE8IojsL0rZY9SVCka0wqeYKvOg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Progressing draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 20:35:27 -0000 This draft is in good shape. I think is it close enough to core SIP work th= at it can be passed straight to SIPCORE for completion. John From tme@americafree.tv Thu Jul 22 05:53:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D69E3A67B5 for ; Thu, 22 Jul 2010 05:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uy9D+LBZesv for ; Thu, 22 Jul 2010 05:53:03 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 3DCBB3A67B8 for ; Thu, 22 Jul 2010 05:53:03 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 3057880D84A5; Thu, 22 Jul 2010 08:53:20 -0400 (EDT) Message-Id: <80A7E6A8-A0C2-4424-B967-56837EFE284D@americafree.tv> From: Marshall Eubanks To: Marshall Eubanks In-Reply-To: <15655197-E667-4A1F-BD12-1A1961081D7D@americafree.tv> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Jul 2010 08:53:19 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com><04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> <15655197-E667-4A1F-BD12-1A 1961081D7D@americafree.tv> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 12:53:05 -0000 On Jul 21, 2010, at 11:54 AM, Marshall Eubanks wrote: > > On Jul 21, 2010, at 11:38 AM, Romascanu, Dan (Dan) wrote: > >> A proper Doodle would be better. I am also interested, and there >> may be >> other. >> > > Ask, and ye shall receive. > > http://www.doodle.com/f5bniwsrsndr29y3 I intend to close this by the end of the day today (East Coast US time), so please doodle if you haven't already. So far, Monday evening is ahead. Regards Marshall > > Please send this to other people / lists as you feel necessary. > > Notes : > > green = prefer this time > yellow = could make this time if necessary > red = cannot make this time > > I have separated the evening meeting possibilities into > > - Just after the end of the IETF (i.e., AT or BEFORE dinner > - A little over 1 hour later (i.e., AFTER dinner) > > If you think 1 hour is not enough for dinner, but prefer the after > dinner time, please vote for after dinner anyway and send a comment > to this list. If we pick an after dinner time, we might adjust the > actual rendezvous time. > > If you have another time, suggest it. > > Regards > Marshall > > >> Dan >> >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Marshall Eubanks >>> Sent: Wednesday, July 21, 2010 6:36 PM >>> To: Marshall Eubanks >>> Cc: DISPATCH list; Daryl Malas >>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>> >>> OK, here are the tabulations : >>> >>> On Jul 15, 2010, at 11:03 AM, Marshall Eubanks wrote: >>> >>>> OK, here are the options I see >>>> >>>> There is an informal Bar BOF list >>>> >>>> http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 >>>> >>>> Wednesday Lunch, thursday Lunch or Thursday before plenary >>> are taken. >>>> >>>> I would suggest >>>> >>> >>> Here are the respondents so far : >>> >>> TME - Marshall >>> JE - John Elwell >>> DM - Daryl Malas >>> MB - Mary Barnes >>> PK - Paul Kyzivat >>> PR - Partr >>> >>> Monday night - TME prefer, JE prefer, DM prefer, MB prefer* >>> Wednesday after plenary, JE Prefer, MB prefer Thursday after >>> plenary - JE avoid, MB prefer, PK & PR avoid (E2MD >>> collision) >>> Friday Lunch - JE avoid DM prefer >>> >>> * after the meeting, not after dinner >>> >>> So, sifting through all of this, I come up with Monday night >>> _before dinner_. >>> >>> Does that seen OK, or should I set up a proper doodle ? >>> >>> Regards >>> Marshall >>> >>> >>> >>>> >>>> I would prefer Monday night, but these all WFM. Please let me know >>>> what you think. >>>> >>>> Regards >>>> Marshall >>>> >>>> >>>> On Jul 15, 2010, at 9:57 AM, Elwell, John wrote: >>>> >>>>> I would try to join if there is no conflict. >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Marshall Eubanks >>>>>> Sent: 15 July 2010 01:06 >>>>>> To: Paul Kyzivat >>>>>> Cc: DISPATCH list; Daryl Malas >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>> >>>>>> Should we arrange a (true) Bar BOF (AKA DrinkTime) for >>> this topic in >>>>>> Maastricht ? >>>>>> >>>>>> Marshall >>>>>> >>>>>> On Jul 14, 2010, at 6:53 PM, Paul Kyzivat wrote: >>>>>> >>>>>>> I won't comment on the rest of this right now, but its >>> not right to >>>>>>> describe a B2BUA as a function of an SBC. >>>>>>> Rather, an SBC is a particular sort of B2BUA. >>>>>>> There are *many* sorts of B2BUA that have nothing in common >>>>>> with an >>>>>>> SBC. >>>>>>> >>>>>>> Its actually this sort of disagreement that would benefit from >>>>>>> beginning a taxonomy of B2BUAs. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> Daryl Malas wrote: >>>>>>>> All, >>>>>>>> Many if not all of the functions of an SBC have already been >>>>>>>> defined in one way or another. An SBC is a "jack-of-all- >>>>>>>> trades" >>>>>>>> platform. I think this is a slippery slope to try and >>>>>> define, and >>>>>>>> is a quagmire the IETF should stray from. In some cases, >>>>>> SBCs are >>>>>>>> not even deployed on the edge of networks. >>>>>>>> I agree that a B2BUA is different, but it could be considered a >>>>>>>> function of the SBC. B2BUA's were created with the >>> intention of >>>>>>>> breaking up the end-to-end environment, so creating rules >>>>>> to define >>>>>>>> allowances for the end-to-end environment will be >>> challenging at >>>>>>>> best. >>>>>>>> Regards, >>>>>>>> Daryl >>>>>>>> -----Original Message----- >>>>>>>> From: dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] >>>>>>>> On Behalf Of Christer Holmberg >>>>>>>> Sent: Friday, July 09, 2010 12:44 PM >>>>>>>> To: Paul Kyzivat; Mohammad Al-Taraireh (maltarai) >>>>>>>> Cc: DISPATCH list >>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>>> Hi, >>>>>>>> Rather than focus on node terminology, I think we >>> should focus on >>>>>>>> the FUNCTIONS they perform, and see whether something >>> can do done >>>>>>>> in order to avoid claimed interop problems etc, rather >>>>>> than arguing >>>>>>>> about whether the entity that performs the function shall >>>>>> be called >>>>>>>> B2BUA, SBC, Application Server, or something else... >>>>>>>> Regards, >>>>>>>> Christer >>>>>>>> ________________________________________ >>>>>>>> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On >>>>>>>> Behalf Of Paul Kyzivat [pkyzivat@cisco.com] >>>>>>>> Sent: Friday, July 09, 2010 3:10 AM >>>>>>>> To: Mohammad Al-Taraireh (maltarai) >>>>>>>> Cc: DISPATCH list >>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>>> Mohammad Al-Taraireh (maltarai) wrote: >>>>>>>>> Doesn't the B2BUA term also implies media origination, and >>>>>>>>> termination capabilities ? It seems that the B2BUA term >>>>>> is already >>>>>>>>> overloaded to include SBC. >>>>>>>> The term "B2BUA" is distinguished by the minimality of its >>>>>>>> definition and the corresponding broadness of applicability. It >>>>>>>> neither implies nor forbids media processing. >>>>>>>> The term SBC, as typically used, is somewhat narrower in >>>>>> scope that >>>>>>>> B2BUA, but is still incredibly broad. I certainly know >>> of things >>>>>>>> that consider themselves to be SBCs that (at least >>>>>> sometimes) don't >>>>>>>> terminate media. >>>>>>>> And certainly there are B2BUAs that *do* terminate >>> media that you >>>>>>>> would not want to call an SBC. (E.g. a conference focus and >>>>>>>> mixer.) >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>>> Mo >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] >>>>>>>>> On Behalf Of Dan Wing (dwing) >>>>>>>>> Sent: Thursday, July 08, 2010 5:31 PM >>>>>>>>> To: Cullen Jennings (fluffy) >>>>>>>>> Cc: 'DISPATCH list' >>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>>>>>> Sent: Thursday, July 08, 2010 1:34 PM >>>>>>>>>> To: Dan Wing >>>>>>>>>> Cc: DISPATCH list >>>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for >>>>>>>>>> SBCs? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Seems reasonable. I think B2BUA is reasonable well >>>>>> defined. Care >>>>>>>>>> to put on your fire proof suit and propose a >>> definition of what >>>>>>>>>> an SBC >>>>>>>>> is? >>>>>>>>> >>>>>>>>> SBC: a B2BUA that also terminates and originates >>> media from user >>>>>>>>> agents or media from an adjacent SBC. >>>>>>>>> >>>>>>>>> -d >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>>>>>>>>>> Sent: Thursday, July 08, 2010 5:50 AM >>>>>>>>>>>> To: Dan Wing >>>>>>>>>>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; >>> 'DISPATCH list' >>>>>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE >>> WG for SBCs? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> >>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes >>>>>>>>>>>> - >>>>>>>>>> 03 >>>>>>>>>>>> has just been submitted. >>>>>>>>>>> Splendid. I refer to the media latching in that document >>>>>>>>> frequently. >>>>>>>>>>> Myself, I would be happier if IETF could find it possible to >>>>>>>>>>> include the acronym-that-must-not-be-spoken (SBC) in >>>>>>>>>>> SBC-related specifications -- no matter if an SBC >>> working group >>>>>>>>>>> is >>>>>> formed or >>>>>>>>>>> not. Calling them 'middleboxes' is too vague to be >>>>>> useful, much >>>>>>>>>>> like "gateway" is too vague (a gateway to the PSTN? a >>>>>> router?) >>>>>>>>>>> Call >>>>>>>>>>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, >>>>>> and an SBC >>>>>>>>>>> an SBC. >>>>>>>>>>> >>>>>>>>>>> -d >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Dan Wing wrote: >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: dispatch-bounces@ietf.org >>>>>>>>>>>>>> [mailto:dispatch-bounces@ietf.org] >>>>>>>>>>>> On >>>>>>>>>>>>>> Behalf Of Peter Musgrave >>>>>>>>>>>>>> Sent: Thursday, July 01, 2010 12:30 PM >>>>>>>>>>>>>> To: WORLEY, Dale R (Dale) >>>>>>>>>>>>>> Cc: DISPATCH list >>>>>>>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG >>>>>> for SBCs? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I concur. >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is some useful background in RFC5853 and >>>>>> perhaps >>>>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> And then some things which died on the vine such as: >>>>>>>>>>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>>>>>>>>>>>> and perhaps some others? >>>>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >>>>>>>>>> middleboxes- >>>>>>>>>>>> 02 died. >>>>>>>>>>>>> -d >>>>>>>>>>>> ... >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> dispatch mailing list >>>>>>>>>>> dispatch@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>>>>>> Cullen Jennings >>>>>>>>>> For corporate legal information go to: >>>>>>>>>> >>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>>> index.html >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>> >>> >>> _______________________________________________ >>> 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 tme@americafree.tv Thu Jul 22 08:12:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2758A3A6B0F for ; Thu, 22 Jul 2010 08:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eq72n7+-kVfC for ; Thu, 22 Jul 2010 08:12:04 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 283323A6BA7 for ; Thu, 22 Jul 2010 08:12:04 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 7CBE980DC920 for ; Thu, 22 Jul 2010 11:12:21 -0400 (EDT) Message-Id: From: Marshall Eubanks To: DISPATCH list Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Jul 2010 11:12:21 -0400 X-Mailer: Apple Mail (2.936) Subject: [dispatch] Possible bar bof on a global videoconferencing / telepresence directory ? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 15:12:06 -0000 Something that I have been giving a lot of thought to recently is how to establish a global directory for videoconferencing and telepresence, and whether this should be based on / derived from ENUM. So, I am wondering if - there are others here interested in this same topic and - whether or not we should get together briefly for a "bar bof" or an even more informal meeting in Maastricht. So, if this subject interests you, please respond to this email. If there is interest, I will set up a quick doodle. Regards Marshall From peter.musgrave@magorcorp.com Thu Jul 22 08:32:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DEDD3A6BCD for ; Thu, 22 Jul 2010 08:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=-0.271, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aPl7uoqZ2TiQ for ; Thu, 22 Jul 2010 08:32:08 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 549B03A6BBF for ; Thu, 22 Jul 2010 08:32:07 -0700 (PDT) Received: by fxm1 with SMTP id 1so4829121fxm.31 for ; Thu, 22 Jul 2010 08:32:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.68.3 with SMTP id q3mr1723043fga.75.1279812744189; Thu, 22 Jul 2010 08:32:24 -0700 (PDT) Received: by 10.229.20.198 with HTTP; Thu, 22 Jul 2010 08:32:24 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Jul 2010 11:32:24 -0400 Message-ID: From: Peter Musgrave To: Marshall Eubanks Content-Type: text/plain; charset=ISO-8859-1 Cc: DISPATCH list Subject: Re: [dispatch] Possible bar bof on a global videoconferencing / telepresence directory ? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 15:32:12 -0000 I'm interested. Peter Musgrave On Thu, Jul 22, 2010 at 11:12 AM, Marshall Eubanks wrote: > Something that I have been giving a lot of thought to recently is how to > establish a global directory for videoconferencing and telepresence, and > whether this should be based on / derived from ENUM. > > So, I am wondering if > > - there are others here interested in this same topic and > - whether or not we should get together briefly for a "bar bof" or an even > more informal meeting in Maastricht. > > So, if this subject interests you, please respond to this email. If there is > interest, I will set up a quick doodle. > > Regards > Marshall > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From pkyzivat@cisco.com Thu Jul 22 10:41:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 473EF3A6842 for ; Thu, 22 Jul 2010 10:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.532 X-Spam-Level: X-Spam-Status: No, score=-10.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOPultRInIJp for ; Thu, 22 Jul 2010 10:41:01 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id ACC7B3A6767 for ; Thu, 22 Jul 2010 10:41:00 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2010 17:41:17 +0000 Received: from [10.86.254.210] ([10.86.254.210]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6MHfHjQ000672; Thu, 22 Jul 2010 17:41:17 GMT Message-ID: <4C4882BE.3060402@cisco.com> Date: Thu, 22 Jul 2010 13:41:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 17:41:04 -0000 Hadriel, A somewhat related question for you on the draft: Is the algorithm described in the draft intended to be normative? AFAICT there is no *normative* language about the algorithm itself. Nor can I find much value in making it normative. The only stated reason for using a defined algorithm is so that two boxes can produce the same output from the same input. But when is that required? I think it may be needed when pairs (or more) of servers share responsibility for a given dialog. And in such cases it will almost always be the case that they are a matched set from the same vendor. I interpret the algorithm as an *example* of a suitable algorithm. Can we have some clarity on the normativeness of this? Thanks, Paul Hadriel Kaplan wrote: > Hi Muthu, > See section 9.2 of the draft, which has some text around some of the issues you raised. > > As for the issue of a UA maliciously trying to pass through addressing in the session-id value, that's unavoidable and not a real issue I think. It's unavoidable because there are multiple ways for a UA which is really intent on getting IP Addressing through an SBC to do so anyway, at least by encoding it in the media. But I also think it's not a real issue because in my opinion generally SBC's hide the IP Addressing because people _want_ it hidden. Even the end-users generally want it hidden; if they don't, if they want to learn IP Addresses of each other, nothing will stop them from just telling each other what it is. (since it takes both sides to collude for it to work anyway) > > But as the draft points out, if some vendor (including SBC vendors themselves) use this header for some nefarious purpose, then no RFC can prevent them from doing so; but what will happen is the word will get out and the SBC vendors will be forced to remove/replace the header, negating its value to all. > > I think/hope the need for a consistent value which crosses b2bua's for troubleshooting purposes will be useful enough to vendors, if even to help their own TAC with debugging issues, that they leave it alone - or their customers to tell them to anyway. > > -hadriel > > >> -----Original Message----- >> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] >> Sent: Tuesday, July 20, 2010 2:10 PM >> >> I have a security related concern with session-id. One of the requirements >> in the draft is: >> REQ2a: The identifier must not reveal any information related to any >> SIP device or domain identity, including IP Address, port, hostname, >> domain name, username, Address-of-Record, MAC address, IP address >> family, transport type, etc. >> >> And then is says: >> A B2BUA compliant with this document MUST copy the Session-ID header >> field it receives in requests as a UAS into the related requests it >> generates as a UAC; and any Session-ID field it receives in >> responses as a UAC into the correlated responses it generates as a >> UAS. >> >> Now, how is a B2BUA, and a SBC in particular, going to verify that >> session-id isn't revealing any of these information unless it inspects the >> session-id header? What if an UA uses these 128-bits to encode any of >> these information to bypass the policies configured at an SBC? For example, >> an UA can stuff in up to 4 IPv4 addresses or an IPv6 address into the 128- >> bit session-id header value and get it intact across all SBC bypassing >> their address/topology hiding policies. >> >> Worst, a SBC in the signaling path can strip off the incoming session-id, >> construct a new session-id, encoding some information into it in order to >> bypass the policies configured in upstream SBCs, and send it out. When it >> receives the response, it does the reverse and sends the original session- >> id back -- a kind of man-in-the-middle attack that none of the SIP >> elements can detect, unless someone captures the messages across both >> sides of this SBC. >> >> I am not sure SBC vendors are going to be comfortable blindly trusting the >> sender and considering session-id as an opaque data. Unless we solve this >> problem they might be reluctant to support session-id. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From partr@cisco.com Fri Jul 23 02:29:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88F393A6B2D for ; Fri, 23 Jul 2010 02:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.365 X-Spam-Level: X-Spam-Status: No, score=-8.365 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1YlNNYlphx6 for ; Fri, 23 Jul 2010 02:29:32 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4AA0C3A6B3B for ; Fri, 23 Jul 2010 02:29:32 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFALr9SExAaHte/2dsb2JhbACBRJ1KWHGlbpsIgm6CSASEA4cX Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-6.cisco.com with ESMTP; 23 Jul 2010 09:29:49 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6N9TgsQ001765; Fri, 23 Jul 2010 09:29:48 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 14:59:47 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2A49.979E0170" Date: Fri, 23 Jul 2010 14:59:47 +0530 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsiqbaMfHyiLn9KSoGceaY0EYk4fwHmuxFv References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> From: "Parthasarathi R (partr)" To: "Hadriel Kaplan" , X-OriginalArrivalTime: 23 Jul 2010 09:29:47.0907 (UTC) FILETIME=[97DDDD30:01CB2A49] Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 09:29:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2A49.979E0170 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Hadriel, =20 It is nice to have the mechanism by which one/some of the header(s) = pass(es) through B2BUA. This provides facility for end-to-end service to = work. But the current draft is proposed only for the "troubleshooting" = only. IMO, the scope of the draft *MUST* be increased to provide more = services. Some of the services comes to my mind are=20 =20 1) In SIP recording mechanism, B2BUA exist between Session Recording = Client (SRC) and Session Recording Server (SRS). It is better to have = the unique id like session id passed from SRC to SRS. =20 2) In Media antitrombone mechanism, the session id shall be used to = identify the loop for the same call. In the mentioned Antitrombone = scenario, the signalling is required to be looped and only media should = not be looped (SBC standard requirement). The trombone shall be = identified by SDP attributes and the service shall kick start. The SDP = attributes using trombone will not work in case B2BUA without media = handling (Media flowaround) in one dialog and B2BUA with media handling = (media topology hiding) in another dialog. To identify the trombone due = to B2BUA without media dialog is not possible without keep track of all = the endpoint IP addresses. In case session-id header exists in the = dialog, it will help to relate the dialog in B2BUA.=20 =20 There may be other requirements for passing the headers. It is better to = create the generic header mechanism or B2BUA guidelines instead of = service specific header standardization as it may leads to multiple = standards instead of one generic approach. =20 Regards Partha =20 ________________________________ From: dispatch-bounces@ietf.org on behalf of Hadriel Kaplan Sent: Tue 7/13/2010 10:07 PM To: dispatch@ietf.org Subject: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Howdy, I submitted an updated version of the session-id draft, for = consideration as a solution for the (hopefully) new WG for such purpose. =20 The major changes are: 1) Reverted the generation of the session-id value to be a defined = 128-bit hash mechanism, as it was prior to version 1, based on feedback = that having it be a known algorithm allows a monitoring system with the = same private key to generate the value itself for matching purposes. 2) Added a section on transfer handling, for REFER and = INVITE-with-Replaces, such that a transferred call uses the same = session-id. This section is just a beginning strawman and will need = more thought. =20 =20 A New Internet-Draft is available from the on-line Internet-Drafts = directories. =20 Title : A Session Identifier for the Session Initiation = Protocol (SIP) Author(s) : H. Kaplan Filename : draft-kaplan-dispatch-session-id-02.txt Pages : 13 Date : 2010-07-12 =20 There is a need for having a globally unique session identifier for the = same SIP session, which can be consistently maintained across Proxies, = B2BUAs and other SIP middle-boxes, for the purpose of Troubleshooting. = This draft proposes a new SIP header to carry such a value: Session-ID. =20 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id-02.t= xt =20 =20 ------_=_NextPart_001_01CB2A49.979E0170 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
=0A=

Hi = Hadriel,

=0A=

 

=0A=

It is nice to have the = mechanism by which one/some of the header(s) pass(es) through B2BUA. = This provides facility for end-to-end service to work. But the = current draft is proposed only for the "troubleshooting" only. IMO, the = scope of the draft *MUST* be increased to provide more services. Some of = the services comes to my mind are

=0A=

 

=0A=

1) In SIP = recording mechanism, B2BUA exist between Session Recording Client = (SRC) and Session Recording Server (SRS). It is better to have the = unique id like session id passed from SRC to SRS.

=0A=

 

=0A=

2) In Media = antitrombone mechanism, the session id shall be used to = identify the loop for the same call. In the mentioned Antitrombone = scenario, the signalling is required to be looped and only = media should not be looped (SBC standard requirement). The = trombone shall be identified by SDP attributes and the service = shall kick start. The SDP attributes using trombone will not work = in case B2BUA without media handling = (Media flowaround) in one dialog and B2BUA with = media handling (media topology hiding) in another = dialog. To identify the trombone due to B2BUA without = media dialog is not possible without keep track of all the endpoint = IP addresses. In case session-id header exists in the = dialog, it will help to relate the dialog in B2BUA. 

=0A=

 

=0A=

There may be other = requirements for passing the headers. It is better to create the generic = header mechanism or B2BUA guidelines instead of service specific header = standardization as it may leads to multiple standards instead of one = generic approach.

=0A=

 

=0A=

Regards

=0A=

Partha

=0A=

 

=0A=
=0A=
=0A=
From: = dispatch-bounces@ietf.org on behalf of Hadriel Kaplan
Sent: = Tue 7/13/2010 10:07 PM
To: = dispatch@ietf.org
Subject: [dispatch] Updated: = draft-kaplan-dispatch-session-id-02

=0A=
=0A=
=0A=

Howdy,

=0A=

I submitted an = updated version of the session-id draft, for consideration as a solution = for the (hopefully) new WG for such purpose.

=0A=

 

=0A=

The major changes = are:

=0A=

1)    Reverted the generation of the session-id value to be a = defined 128-bit hash mechanism, as it was prior to version 1, based on = feedback that having it be a known algorithm allows a monitoring system = with the same private key to generate the value itself for matching = purposes.

=0A=

2)    Added a section on transfer handling, for REFER and = INVITE-with-Replaces, such that a transferred call uses the same = session-id.  This section is just a beginning strawman and will = need more thought.

=0A=

 

=0A=

 

=0A=

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

=0A=

 

=0A=

      = Title           : A = Session Identifier for the Session Initiation Protocol = (SIP)

=0A=

      = Author(s)       : H. = Kaplan

=0A=

      = Filename        : = draft-kaplan-dispatch-session-id-02.txt

=0A=

      = Pages           : = 13

=0A=

      = Date            : = 2010-07-12

=0A=

 

=0A=

There is a need = for having a globally unique session identifier for the same SIP = session, which can be consistently maintained across Proxies, B2BUAs and = other SIP middle-boxes, for the purpose of Troubleshooting.  This = draft proposes a new SIP header to carry such a value: = Session-ID.

=0A=

 

=0A=

A URL for this = Internet-Draft is:

=0A=

http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-ses= sion-id-02.txt

=0A=

 

=0A=

 

------_=_NextPart_001_01CB2A49.979E0170-- From HKaplan@acmepacket.com Fri Jul 23 06:06:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D34D3A657C for ; Fri, 23 Jul 2010 06:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c81Q77Vs68s9 for ; Fri, 23 Jul 2010 06:06:40 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 665263A6992 for ; Fri, 23 Jul 2010 06:06:40 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 23 Jul 2010 09:06:58 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Jul 2010 09:06:37 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Fri, 23 Jul 2010 09:06:35 -0400 Thread-Topic: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcspxSddk3MRR128QYqpHH921ldcfQAoNUMQ Message-ID: <430FC6BDED356B4C8498F634416644A9258D7F403B@mail> References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> <4C4882BE.3060402@cisco.com> In-Reply-To: <4C4882BE.3060402@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 13:06:42 -0000 Hi Paul, The algorithm was intended to be normative, although I'm certainly open to = doing whatever the WG wants of course. The reason for it is not for b2bua server pairs, but rather for monitoring = equipment correlation, based on feedback from Laura Liess. Assume a call f= low like this: Alice B2BUA Bob | | | |INVITE_1 | | |--------->|INVITE_2 | | |-------->| | | | \ / \ / Monitor The monitor can see INVITE_1 and INVITE_2. Alice is a legacy UA, so the B2= BUA inserts Session-ID. If the session-id the B2BUA creates is based on th= e known algorithm, and if the monitor has the same key, then the monitor ca= n know that INVITE_2 is from INVITE_1 because it can create the same value = from INVITE_1. Since the monitor and B2BUA are probably not from the same company, the ide= a was to specify the algorithm in the draft and require its implementation.= But we could instead just specify it as the algorithm to use for such cas= es, but leave it up to implementations to decide if they want to support su= ch cases on their own. Like call it some named algorithm so vendors can sa= y whether they do it or not. -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Thursday, July 22, 2010 1:41 PM > To: Hadriel Kaplan >=20 > A somewhat related question for you on the draft: >=20 > Is the algorithm described in the draft intended to be normative? > AFAICT there is no *normative* language about the algorithm itself. > Nor can I find much value in making it normative. >=20 > The only stated reason for using a defined algorithm is so that two > boxes can produce the same output from the same input. But when is that > required? I think it may be needed when pairs (or more) of servers share > responsibility for a given dialog. And in such cases it will almost > always be the case that they are a matched set from the same vendor. >=20 > I interpret the algorithm as an *example* of a suitable algorithm. >=20 > Can we have some clarity on the normativeness of this? >=20 From pkyzivat@cisco.com Fri Jul 23 06:25:24 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60FDD3A685E for ; Fri, 23 Jul 2010 06:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ptw2MvGQEA5s for ; Fri, 23 Jul 2010 06:25:23 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0092F3A67EA for ; Fri, 23 Jul 2010 06:25:22 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 Jul 2010 13:25:41 +0000 Received: from [10.86.253.215] ([10.86.253.215]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6NDPewq009367; Fri, 23 Jul 2010 13:25:40 GMT Message-ID: <4C499854.6030105@cisco.com> Date: Fri, 23 Jul 2010 09:25:40 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> <4C4882BE.3060402@cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F403B@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A9258D7F403B@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 13:25:24 -0000 Hadriel, Hadriel Kaplan wrote: > Hi Paul, > The algorithm was intended to be normative, although I'm certainly open to doing whatever the WG wants of course. > > The reason for it is not for b2bua server pairs, but rather for monitoring equipment correlation, based on feedback from Laura Liess. Assume a call flow like this: Thanks for clarifying the purpose of specifying the algorithm. > Alice B2BUA Bob > | | | > |INVITE_1 | | > |--------->|INVITE_2 | > | |-------->| > | | | > \ / > \ / > Monitor > > The monitor can see INVITE_1 and INVITE_2. Alice is a legacy UA, so the B2BUA inserts Session-ID. If the session-id the B2BUA creates is based on the known algorithm, and if the monitor has the same key, then the monitor can know that INVITE_2 is from INVITE_1 because it can create the same value from INVITE_1. ISTM the above can be solved without standardizing anything. The first response to INVITE_1 will have the session id. At that point the Monitor will know the correlation. > Since the monitor and B2BUA are probably not from the same company, the idea was to specify the algorithm in the draft and require its implementation. But we could instead just specify it as the algorithm to use for such cases, but leave it up to implementations to decide if they want to support such cases on their own. Like call it some named algorithm so vendors can say whether they do it or not. Especially in cases like this I would think it to be logistically difficult to share the keys Note I'm not overly concerned about standardizing the algorithm if there is a good reason to do so. Thanks, Paul > -hadriel > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Thursday, July 22, 2010 1:41 PM >> To: Hadriel Kaplan >> >> A somewhat related question for you on the draft: >> >> Is the algorithm described in the draft intended to be normative? >> AFAICT there is no *normative* language about the algorithm itself. >> Nor can I find much value in making it normative. >> >> The only stated reason for using a defined algorithm is so that two >> boxes can produce the same output from the same input. But when is that >> required? I think it may be needed when pairs (or more) of servers share >> responsibility for a given dialog. And in such cases it will almost >> always be the case that they are a matched set from the same vendor. >> >> I interpret the algorithm as an *example* of a suitable algorithm. >> >> Can we have some clarity on the normativeness of this? >> > From HKaplan@acmepacket.com Fri Jul 23 06:57:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7B313A67F2 for ; Fri, 23 Jul 2010 06:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.333 X-Spam-Level: X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2kBg1oqChnk for ; Fri, 23 Jul 2010 06:57:04 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 90EC93A67B5 for ; Fri, 23 Jul 2010 06:57:04 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 23 Jul 2010 09:57:22 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Jul 2010 09:57:21 -0400 From: Hadriel Kaplan To: "Parthasarathi R (partr)" , "dispatch@ietf.org" Date: Fri, 23 Jul 2010 09:56:54 -0400 Thread-Topic: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsiqbaMfHyiLn9KSoGceaY0EYk4fwHmuxFvAAkRjcA= Message-ID: <430FC6BDED356B4C8498F634416644A9258D7F4051@mail> References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 13:57:05 -0000 Hi Partha, Comments inline... > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Friday, July 23, 2010 5:30 AM > To: Hadriel Kaplan; dispatch@ietf.org >=20 > It is nice to have the mechanism by which one/some of the header(s) > pass(es) through B2BUA. This provides facility for end-to-end service to > work. But the current draft is proposed only for the "troubleshooting" > only. IMO, the scope of the draft *MUST* be increased to provide more > services.=20 Why? What's wrong with having a header value whose sole purpose is for tro= ubleshooting? Do you think it's not enough purpose to make people support = it? > 1) In SIP recording mechanism, B2BUA exist between Session Recording > Client (SRC) and Session Recording Server (SRS). It is better to have the > unique id like session id passed from SRC to SRS. So far SIPREC has not defined a protocol mechanism in any draft, afaik. Th= ere're requirements and architecture drafts, but no reason so far as I can = tell that one would need to use session-id for anything new there. Can you= explain what it would be used for that call-id and tags would not? > 2) In Media antitrombone mechanism, the session id shall be used to > identify the loop for the same call. In the mentioned Antitrombone > scenario, the signalling is required to be looped and only media should > not be looped (SBC standard requirement). The trombone shall be identifie= d > by SDP attributes and the service shall kick start. The SDP attributes > using trombone will not work in case B2BUA without media handling (Media > flowaround) in one dialog and B2BUA with media handling (media topology > hiding) in another dialog. To identify the trombone due to B2BUA without > media dialog is not possible without keep track of all the endpoint IP > addresses. In case session-id header exists in the dialog, it will help t= o > relate the dialog in B2BUA. I know there are benefits to detecting when a call hairpins/loops, and ther= e's no debate a session-id could be used to detect that - in fact it used t= o be one of the reasons for session-id in the first versions of the draft b= ack when it was draft-kaplan-sip-session-id. But I removed that motivation= a while back, as it was effectively the same thing as monitoring correlati= on - the monitoring system just happens to be incorporated into the b2bua. = =20 BTW, in my experience using it for a media-trombone scenario as you describ= e won't work, because it only handles the case of the same SBC being traver= sed. We've had to use other techniques to make that scenario work. Unfort= unately the techniques vary depending on the vendor of the core equipment (= softswitch/pbx/S-CSCF), but the problem's been solved for years. > There may be other requirements for passing the headers. It is better to > create the generic header mechanism or B2BUA guidelines instead of servic= e > specific header standardization as it may leads to multiple standards > instead of one generic approach. I disagree. I don't think we'll be successful in getting B2BUA vendors (an= d their owners) to pass a generic header through unless they know its purpo= se. -hadriel From HKaplan@acmepacket.com Fri Jul 23 07:03:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1851E3A67EA for ; Fri, 23 Jul 2010 07:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmfpK04B2n+1 for ; Fri, 23 Jul 2010 07:03:02 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9612F3A67F2 for ; Fri, 23 Jul 2010 07:02:57 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 23 Jul 2010 10:03:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Jul 2010 10:03:14 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Fri, 23 Jul 2010 10:03:11 -0400 Thread-Topic: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsqapPVh+OK8YFpQXGnQnKGiHSQ5gABOsNg Message-ID: <430FC6BDED356B4C8498F634416644A9258D7F4054@mail> References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> <4C4882BE.3060402@cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F403B@mail> <4C499854.6030105@cisco.com> In-Reply-To: <4C499854.6030105@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 14:03:04 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, July 23, 2010 9:26 AM > To: Hadriel Kaplan >=20 > ISTM the above can be solved without standardizing anything. > The first response to INVITE_1 will have the session id. > At that point the Monitor will know the correlation. This feels like d=E9j=E0-vu, and I just found out why: I said the same thin= g back when this was discussed previously :) here: http://www.ietf.org/mail-archive/web/dispatch/current/msg01655.html And here's Laura's reply: http://www.ietf.org/mail-archive/web/dispatch/current/msg01668.html -hadriel From mperumal@cisco.com Fri Jul 23 07:23:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11F813A657C for ; Fri, 23 Jul 2010 07:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.587 X-Spam-Level: X-Spam-Status: No, score=-5.587 tagged_above=-999 required=5 tests=[AWL=-2.988, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wltvht4kSO6 for ; Fri, 23 Jul 2010 07:23:20 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 0DC223A685E for ; Fri, 23 Jul 2010 07:23:19 -0700 (PDT) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsEAN9CSUxAaHtegWdsb2JhbACfahUBARYiIqZ8mn6FNgSEA4cX X-IronPort-AV: E=Sophos;i="4.55,247,1278288000"; d="scan'208";a="9273227" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by ams-iport-2.cisco.com with ESMTP; 23 Jul 2010 13:40:08 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6NENKqn003032; Fri, 23 Jul 2010 14:23:35 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 19:53:20 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Jul 2010 19:52:40 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020332B298@XMB-BGL-414.cisco.com> In-Reply-To: <430FC6BDED356B4C8498F634416644A9258D7F4054@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsqapPVh+OK8YFpQXGnQnKGiHSQ5gABOsNgAABvVUA= References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail><1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> <4C4882BE.3060402@cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F403B@mail> <4C499854.6030105@cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F4054@mail> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Hadriel Kaplan" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 23 Jul 2010 14:23:20.0853 (UTC) FILETIME=[9A002450:01CB2A72] Cc: dispatch@ietf.org Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 14:23:21 -0000 Can't we include the key, the pseudo-random number generated by the = B2BUA, in a session-id header parameter so that the B2BUA doesn't have = to share anything with the monitor? It should still be computationally = infeasible to derive the original call-id from its hash, since neither = this call-id not the key is reused later for another hash. Muthu |-----Original Message----- |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] |Sent: Friday, July 23, 2010 7:33 PM |To: Paul Kyzivat (pkyzivat) |Cc: Muthu ArulMozhi Perumal (mperumal); dispatch@ietf.org |Subject: RE: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 | |> -----Original Message----- |> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] |> Sent: Friday, July 23, 2010 9:26 AM |> To: Hadriel Kaplan |> |> ISTM the above can be solved without standardizing anything. |> The first response to INVITE_1 will have the session id. |> At that point the Monitor will know the correlation. | |This feels like d=E9j=E0-vu, and I just found out why: I said the same = thing |back when this was discussed previously :) |here: |http://www.ietf.org/mail-archive/web/dispatch/current/msg01655.html | |And here's Laura's reply: |http://www.ietf.org/mail-archive/web/dispatch/current/msg01668.html | |-hadriel From pkyzivat@cisco.com Fri Jul 23 07:27:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D1153A6879 for ; Fri, 23 Jul 2010 07:27:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TagZS2UgoUEY for ; Fri, 23 Jul 2010 07:27:03 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 761B13A657C for ; Fri, 23 Jul 2010 07:27:03 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2010 14:27:21 +0000 Received: from [10.86.253.215] ([10.86.253.215]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6NERLLp025274; Fri, 23 Jul 2010 14:27:21 GMT Message-ID: <4C49A6C8.40603@cisco.com> Date: Fri, 23 Jul 2010 10:27:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Hadriel Kaplan References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> <1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> <4C4882BE.3060402@cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F403B@mail> <4C499854.6030105@cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F4054@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A9258D7F4054@mail> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 14:27:04 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Friday, July 23, 2010 9:26 AM >> To: Hadriel Kaplan >> >> ISTM the above can be solved without standardizing anything. >> The first response to INVITE_1 will have the session id. >> At that point the Monitor will know the correlation. > > This feels like déjà-vu, and I just found out why: I said the same thing back when this was discussed previously :) > here: > http://www.ietf.org/mail-archive/web/dispatch/current/msg01655.html > > And here's Laura's reply: > http://www.ietf.org/mail-archive/web/dispatch/current/msg01668.html Interesting. I guess its hard to appreciate this without more detail about the goal and techniques of monitoring. My immediate reaction is that if there is no response to the initial INVITE, then there is precious little to monitor and the whole thing is moot. I'm personally not finding this compelling. But certainly I'm not the last word on this. The most disturbing parts about this to me are the ones that are only implied. E.g. that key needs to provisionable and/or query-able in order for the use case to work. Thanks, Paul From HKaplan@acmepacket.com Fri Jul 23 07:38:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA04E3A68F9 for ; Fri, 23 Jul 2010 07:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4TYF3-HCZdk for ; Fri, 23 Jul 2010 07:38:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id ABFC73A67B5 for ; Fri, 23 Jul 2010 07:38:41 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 23 Jul 2010 10:38:57 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 23 Jul 2010 10:38:43 -0400 From: Hadriel Kaplan To: "Muthu ArulMozhi Perumal (mperumal)" , "Paul Kyzivat (pkyzivat)" Date: Fri, 23 Jul 2010 10:38:41 -0400 Thread-Topic: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsqapPVh+OK8YFpQXGnQnKGiHSQ5gABOsNgAABvVUAAAJWCQA== Message-ID: <430FC6BDED356B4C8498F634416644A9258D7F406A@mail> References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail><1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> <4C4882BE.3060402@cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F403B@mail> <4C499854.6030105@cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F4054@mail> <1D062974A4845E4D8A343C65380492020332B298@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020332B298@XMB-BGL-414.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 14:38:42 -0000 > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > Sent: Friday, July 23, 2010 10:23 AM > To: Hadriel Kaplan; Paul Kyzivat (pkyzivat) >=20 > Can't we include the key, the pseudo-random number generated by the B2BUA= , > in a session-id header parameter so that the B2BUA doesn't have to share > anything with the monitor? It should still be computationally infeasible > to derive the original call-id from its hash, since neither this call-id > not the key is reused later for another hash. That wouldn't fulfill Requirement 2b in the draft: "The identifier must not= reveal to the receiver of it that the Call-ID, tags, or any other SIP head= er or body portion have been changed by middle-boxes, with as high a probab= ility as possible." I think Laura's use-case isn't for some random monitor device introduced ad= -hoc - it's really for a permanent monitor probe. Such devices are current= ly deployed in lots of service providers. They're deployed on a permanent = basis, constantly monitoring SIP traffic. So the idea would be for the ope= rator to install the session-id key(s) on the probes or the probe-manager t= hrough an out-of-band method. In other words, the process of putting the k= ey in the monitor does not have to be elegant or defined, and isn't done ve= ry often. I will ping the monitoring vendors again and see if some of them can join t= his conversation, although it may be easier to get them to do it once we ge= t a WG for the concept... just so the mailing list they have to join will b= e more focused. -hadriel From tme@americafree.tv Fri Jul 23 09:03:49 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EF573A66B4 for ; Fri, 23 Jul 2010 09:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sta39bAR1VNo for ; Fri, 23 Jul 2010 09:03:47 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 707073A6826 for ; Fri, 23 Jul 2010 09:03:47 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 31A898115961; Fri, 23 Jul 2010 12:04:05 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Marshall Eubanks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Jul 2010 12:04:03 -0400 References: X-Mailer: Apple Mail (2.936) Cc: DISPATCH list Subject: Re: [dispatch] Possible bar bof on a global videoconferencing / telepresence directory ? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 16:03:49 -0000 Well, we got a little interest, so I set up a Doodle poll : http://www.doodle.com/424zcx6iqicfy8nz If you are interested, please select one or more times. As before, use green for prefer, yellow for OK, red for can't make it. Regards Marshall On Jul 22, 2010, at 11:12 AM, Marshall Eubanks wrote: > Something that I have been giving a lot of thought to recently is > how to establish a global directory for videoconferencing and > telepresence, and whether this should be based on / derived from ENUM. > > So, I am wondering if > > - there are others here interested in this same topic and > - whether or not we should get together briefly for a "bar bof" or > an even more informal meeting in Maastricht. > > So, if this subject interests you, please respond to this email. If > there is interest, I will set up a quick doodle. > > Regards > Marshall > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From Borilin@spiritdsp.com Fri Jul 23 09:35:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F20003A694C for ; Fri, 23 Jul 2010 09:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQPBGud-CZUT for ; Fri, 23 Jul 2010 09:35:05 -0700 (PDT) Received: from mail3.spiritdsp.com (mail3.spiritdsp.com [85.13.214.194]) by core3.amsl.com (Postfix) with ESMTP id 9A9F93A68DC for ; Fri, 23 Jul 2010 09:35:02 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritdsp.com (8.14.3/8.14.3) with ESMTP id o6NGZGq6047943; Fri, 23 Jul 2010 20:35:17 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Jul 2010 20:32:48 +0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <5A3D7E7076F5DF42990A8C164308F810BE0BCE@mail-srv.spiritcorp.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Possible bar bof on a global videoconferencing /telepresence directory ? Thread-Index: AcsqgMF/pU0EJO80S0yPKK8RBI3wUAAA2v6w References: From: "Slava Borilin" To: "Marshall Eubanks" X-Scanned-By: MIMEDefang 2.67 on 192.168.125.15 Cc: DISPATCH list Subject: Re: [dispatch] Possible bar bof on a global videoconferencing /telepresence directory ? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 16:35:07 -0000 Marshall, If you setup directory @ENUM, what about IP-based VCS? I believe the % of such VCS's will be higher every day. Moreover, most VCS networks are "closed enterprise networks" so far and won't participate in any directories/ Why don't we just keep SIP as basic identification for VCS? Or I am missing something? Regards, Slava Borilin PS: sorry won't be @IETF this time in person On Jul 22, 2010, at 11:12 AM, Marshall Eubanks wrote: > Something that I have been giving a lot of thought to recently is =20 > how to establish a global directory for videoconferencing and =20 > telepresence, and whether this should be based on / derived from ENUM. > > So, I am wondering if > > - there are others here interested in this same topic and > - whether or not we should get together briefly for a "bar bof" or =20 > an even more informal meeting in Maastricht. > > So, if this subject interests you, please respond to this email. If =20 > there is interest, I will set up a quick doodle. > > Regards > Marshall > > _______________________________________________ > 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 tme@americafree.tv Fri Jul 23 20:56:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7779E3A68F8 for ; Fri, 23 Jul 2010 20:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkGm+bs-6kgX for ; Fri, 23 Jul 2010 20:56:39 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 128DC3A6848 for ; Fri, 23 Jul 2010 20:56:39 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 188EA813D00D; Fri, 23 Jul 2010 23:56:52 -0400 (EDT) Message-Id: <57DF8E0E-A8AB-4734-A8EB-3C7F431CFBD3@americafree.tv> From: Marshall Eubanks To: "Slava Borilin" In-Reply-To: <5A3D7E7076F5DF42990A8C164308F810BE0BCE@mail-srv.spiritcorp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Jul 2010 23:56:44 -0400 References: <5A3D7E7076F5DF42990A8C164308F810BE0BCE@mail-srv.spiritcorp.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list Subject: Re: [dispatch] Possible bar bof on a global videoconferencing /telepresence directory ? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 03:56:41 -0000 On Jul 23, 2010, at 12:32 PM, Slava Borilin wrote: > Marshall, > > If you setup directory @ENUM, what about IP-based VCS? > I believe the % of such VCS's will be higher every day. True, but I predict that there will be E.164 numbered units for the rest of our lives. > Moreover, most VCS networks are "closed enterprise networks" so far > and > won't participate in any directories/ Partially true. Many of these closed enterprise networks come to service providers like Iformata to connect to other enterprises. They also typically have rooms that they would like to expose to the outside (for job or press interviews, say). I think any directory scheme should be hierarchical in trust and disclosure, so you could have internal and external directories. > > Why don't we just keep SIP as basic identification for VCS? > Or I am missing something? > How will we identify (say) VCS behind NATs ? What about ones that require a gatekeeper ? What about going from H.323 <-> SIP rooms through a MCU ? This is not trivial, which I brought the subject up, and why it would benefit from many eyes. Regards Marshall > Regards, > Slava Borilin > > PS: sorry won't be @IETF this time in person > > > On Jul 22, 2010, at 11:12 AM, Marshall Eubanks wrote: > >> Something that I have been giving a lot of thought to recently is >> how to establish a global directory for videoconferencing and >> telepresence, and whether this should be based on / derived from >> ENUM. >> >> So, I am wondering if >> >> - there are others here interested in this same topic and >> - whether or not we should get together briefly for a "bar bof" or >> an even more informal meeting in Maastricht. >> >> So, if this subject interests you, please respond to this email. If >> there is interest, I will set up a quick doodle. >> >> Regards >> Marshall >> >> _______________________________________________ >> 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 tme@americafree.tv Sat Jul 24 07:33:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3AE23A6A06 for ; Sat, 24 Jul 2010 07:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.49 X-Spam-Level: X-Spam-Status: No, score=-102.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YemA4Wy29Cp for ; Sat, 24 Jul 2010 07:33:43 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id ECAB83A69E6 for ; Sat, 24 Jul 2010 07:33:41 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 07BB18160751; Sat, 24 Jul 2010 10:33:57 -0400 (EDT) Message-Id: <1C6FD77A-A6C6-4897-B1CA-D2FC844522F1@americafree.tv> From: Marshall Eubanks To: Marshall Eubanks In-Reply-To: <15655197-E667-4A1F-BD12-1A1961081D7D@americafree.tv> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 24 Jul 2010 10:33:54 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com><04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> <15655197-E667-4A1F-BD12-1A 1961081D7D@americafree.tv> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 14:33:52 -0000 On Jul 21, 2010, at 11:54 AM, Marshall Eubanks wrote: > > On Jul 21, 2010, at 11:38 AM, Romascanu, Dan (Dan) wrote: > >> A proper Doodle would be better. I am also interested, and there >> may be >> other. >> > > Ask, and ye shall receive. > > http://www.doodle.com/f5bniwsrsndr29y3 > > Please send this to other people / lists as you feel necessary. Based on the doodle, and with Mary Barnes acceptance (as she will not be able to attend), I think that we should meet just after the last session on Monday. (See the Doodle site for the votes.) Do people want to make this a dinner meeting and, if so, in the MECC area or somewhere else ? Specific suggestions would be welcomed. Please send agenda items if there is anything specific you want to discuss, but I thought we would keep this fairly informal. Regards Marshall > > Notes : > > green = prefer this time > yellow = could make this time if necessary > red = cannot make this time > > I have separated the evening meeting possibilities into > > - Just after the end of the IETF (i.e., AT or BEFORE dinner > - A little over 1 hour later (i.e., AFTER dinner) > > If you think 1 hour is not enough for dinner, but prefer the after > dinner time, please vote for after dinner anyway and send a comment > to this list. If we pick an after dinner time, we might adjust the > actual rendezvous time. > > If you have another time, suggest it. > > Regards > Marshall > > >> Dan >> >> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org >>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Marshall Eubanks >>> Sent: Wednesday, July 21, 2010 6:36 PM >>> To: Marshall Eubanks >>> Cc: DISPATCH list; Daryl Malas >>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>> >>> OK, here are the tabulations : >>> >>> On Jul 15, 2010, at 11:03 AM, Marshall Eubanks wrote: >>> >>>> OK, here are the options I see >>>> >>>> There is an informal Bar BOF list >>>> >>>> http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 >>>> >>>> Wednesday Lunch, thursday Lunch or Thursday before plenary >>> are taken. >>>> >>>> I would suggest >>>> >>> >>> Here are the respondents so far : >>> >>> TME - Marshall >>> JE - John Elwell >>> DM - Daryl Malas >>> MB - Mary Barnes >>> PK - Paul Kyzivat >>> PR - Partr >>> >>> Monday night - TME prefer, JE prefer, DM prefer, MB prefer* >>> Wednesday after plenary, JE Prefer, MB prefer Thursday after >>> plenary - JE avoid, MB prefer, PK & PR avoid (E2MD >>> collision) >>> Friday Lunch - JE avoid DM prefer >>> >>> * after the meeting, not after dinner >>> >>> So, sifting through all of this, I come up with Monday night >>> _before dinner_. >>> >>> Does that seen OK, or should I set up a proper doodle ? >>> >>> Regards >>> Marshall >>> >>> >>> >>>> >>>> I would prefer Monday night, but these all WFM. Please let me know >>>> what you think. >>>> >>>> Regards >>>> Marshall >>>> >>>> >>>> On Jul 15, 2010, at 9:57 AM, Elwell, John wrote: >>>> >>>>> I would try to join if there is no conflict. >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Marshall Eubanks >>>>>> Sent: 15 July 2010 01:06 >>>>>> To: Paul Kyzivat >>>>>> Cc: DISPATCH list; Daryl Malas >>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>> >>>>>> Should we arrange a (true) Bar BOF (AKA DrinkTime) for >>> this topic in >>>>>> Maastricht ? >>>>>> >>>>>> Marshall >>>>>> >>>>>> On Jul 14, 2010, at 6:53 PM, Paul Kyzivat wrote: >>>>>> >>>>>>> I won't comment on the rest of this right now, but its >>> not right to >>>>>>> describe a B2BUA as a function of an SBC. >>>>>>> Rather, an SBC is a particular sort of B2BUA. >>>>>>> There are *many* sorts of B2BUA that have nothing in common >>>>>> with an >>>>>>> SBC. >>>>>>> >>>>>>> Its actually this sort of disagreement that would benefit from >>>>>>> beginning a taxonomy of B2BUAs. >>>>>>> >>>>>>> Thanks, >>>>>>> Paul >>>>>>> >>>>>>> Daryl Malas wrote: >>>>>>>> All, >>>>>>>> Many if not all of the functions of an SBC have already been >>>>>>>> defined in one way or another. An SBC is a "jack-of-all- >>>>>>>> trades" >>>>>>>> platform. I think this is a slippery slope to try and >>>>>> define, and >>>>>>>> is a quagmire the IETF should stray from. In some cases, >>>>>> SBCs are >>>>>>>> not even deployed on the edge of networks. >>>>>>>> I agree that a B2BUA is different, but it could be considered a >>>>>>>> function of the SBC. B2BUA's were created with the >>> intention of >>>>>>>> breaking up the end-to-end environment, so creating rules >>>>>> to define >>>>>>>> allowances for the end-to-end environment will be >>> challenging at >>>>>>>> best. >>>>>>>> Regards, >>>>>>>> Daryl >>>>>>>> -----Original Message----- >>>>>>>> From: dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] >>>>>>>> On Behalf Of Christer Holmberg >>>>>>>> Sent: Friday, July 09, 2010 12:44 PM >>>>>>>> To: Paul Kyzivat; Mohammad Al-Taraireh (maltarai) >>>>>>>> Cc: DISPATCH list >>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>>> Hi, >>>>>>>> Rather than focus on node terminology, I think we >>> should focus on >>>>>>>> the FUNCTIONS they perform, and see whether something >>> can do done >>>>>>>> in order to avoid claimed interop problems etc, rather >>>>>> than arguing >>>>>>>> about whether the entity that performs the function shall >>>>>> be called >>>>>>>> B2BUA, SBC, Application Server, or something else... >>>>>>>> Regards, >>>>>>>> Christer >>>>>>>> ________________________________________ >>>>>>>> From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On >>>>>>>> Behalf Of Paul Kyzivat [pkyzivat@cisco.com] >>>>>>>> Sent: Friday, July 09, 2010 3:10 AM >>>>>>>> To: Mohammad Al-Taraireh (maltarai) >>>>>>>> Cc: DISPATCH list >>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>>> Mohammad Al-Taraireh (maltarai) wrote: >>>>>>>>> Doesn't the B2BUA term also implies media origination, and >>>>>>>>> termination capabilities ? It seems that the B2BUA term >>>>>> is already >>>>>>>>> overloaded to include SBC. >>>>>>>> The term "B2BUA" is distinguished by the minimality of its >>>>>>>> definition and the corresponding broadness of applicability. It >>>>>>>> neither implies nor forbids media processing. >>>>>>>> The term SBC, as typically used, is somewhat narrower in >>>>>> scope that >>>>>>>> B2BUA, but is still incredibly broad. I certainly know >>> of things >>>>>>>> that consider themselves to be SBCs that (at least >>>>>> sometimes) don't >>>>>>>> terminate media. >>>>>>>> And certainly there are B2BUAs that *do* terminate >>> media that you >>>>>>>> would not want to call an SBC. (E.g. a conference focus and >>>>>>>> mixer.) >>>>>>>> Thanks, >>>>>>>> Paul >>>>>>>>> Mo >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: dispatch-bounces@ietf.org >>>>>> [mailto:dispatch-bounces@ietf.org] >>>>>>>>> On Behalf Of Dan Wing (dwing) >>>>>>>>> Sent: Thursday, July 08, 2010 5:31 PM >>>>>>>>> To: Cullen Jennings (fluffy) >>>>>>>>> Cc: 'DISPATCH list' >>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Cullen Jennings [mailto:fluffy@cisco.com] >>>>>>>>>> Sent: Thursday, July 08, 2010 1:34 PM >>>>>>>>>> To: Dan Wing >>>>>>>>>> Cc: DISPATCH list >>>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for >>>>>>>>>> SBCs? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Seems reasonable. I think B2BUA is reasonable well >>>>>> defined. Care >>>>>>>>>> to put on your fire proof suit and propose a >>> definition of what >>>>>>>>>> an SBC >>>>>>>>> is? >>>>>>>>> >>>>>>>>> SBC: a B2BUA that also terminates and originates >>> media from user >>>>>>>>> agents or media from an adjacent SBC. >>>>>>>>> >>>>>>>>> -d >>>>>>>>> >>>>>>>>> >>>>>>>>>> On Jul 8, 2010, at 9:42 AM, Dan Wing wrote: >>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Tom Taylor [mailto:tom111.taylor@bell.net] >>>>>>>>>>>> Sent: Thursday, July 08, 2010 5:50 AM >>>>>>>>>>>> To: Dan Wing >>>>>>>>>>>> Cc: 'Peter Musgrave'; 'WORLEY, Dale R (Dale)'; >>> 'DISPATCH list' >>>>>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE >>> WG for SBCs? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>> >>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes >>>>>>>>>>>> - >>>>>>>>>> 03 >>>>>>>>>>>> has just been submitted. >>>>>>>>>>> Splendid. I refer to the media latching in that document >>>>>>>>> frequently. >>>>>>>>>>> Myself, I would be happier if IETF could find it possible to >>>>>>>>>>> include the acronym-that-must-not-be-spoken (SBC) in >>>>>>>>>>> SBC-related specifications -- no matter if an SBC >>> working group >>>>>>>>>>> is >>>>>> formed or >>>>>>>>>>> not. Calling them 'middleboxes' is too vague to be >>>>>> useful, much >>>>>>>>>>> like "gateway" is too vague (a gateway to the PSTN? a >>>>>> router?) >>>>>>>>>>> Call >>>>>>>>>>> a NAT a NAT, a firewall a firewall, a B2BUA a B2BUA, >>>>>> and an SBC >>>>>>>>>>> an SBC. >>>>>>>>>>> >>>>>>>>>>> -d >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Dan Wing wrote: >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: dispatch-bounces@ietf.org >>>>>>>>>>>>>> [mailto:dispatch-bounces@ietf.org] >>>>>>>>>>>> On >>>>>>>>>>>>>> Behalf Of Peter Musgrave >>>>>>>>>>>>>> Sent: Thursday, July 01, 2010 12:30 PM >>>>>>>>>>>>>> To: WORLEY, Dale R (Dale) >>>>>>>>>>>>>> Cc: DISPATCH list >>>>>>>>>>>>>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG >>>>>> for SBCs? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I concur. >>>>>>>>>>>>>> >>>>>>>>>>>>>> There is some useful background in RFC5853 and >>>>>> perhaps >>>>>> http://tools.ietf.org/html/draft-worley-sipcore-b2bua-passthru-00 >>>>>>>>>>>>>> >>>>>>>>>>>>>> And then some things which died on the vine such as: >>>>>>>>>>>>>> http://tools.ietf.org/html/draft-marjou-sipping-b2bua-01 >>>>>>>>>>>>>> and perhaps some others? >>>>>>>>>>>>> http://tools.ietf.org/html/draft-ietf-mmusic-media-path- >>>>>>>>>> middleboxes- >>>>>>>>>>>> 02 died. >>>>>>>>>>>>> -d >>>>>>>>>>>> ... >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> dispatch mailing list >>>>>>>>>>> dispatch@ietf.org >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>>>>>> Cullen Jennings >>>>>>>>>> For corporate legal information go to: >>>>>>>>>> >>>>>> http://www.cisco.com/web/about/doing_business/legal/cri/ >>>>>> index.html >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>> >>> >>> _______________________________________________ >>> 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@cisco.com Sat Jul 24 08:43:22 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 778203A6894 for ; Sat, 24 Jul 2010 08:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.57 X-Spam-Level: X-Spam-Status: No, score=-10.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11HmjqFLTnvV for ; Sat, 24 Jul 2010 08:43:21 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 951203A688E for ; Sat, 24 Jul 2010 08:43:21 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB+nSkxAZnwM/2dsb2JhbACfZXGlGJoshTYEiGQ X-IronPort-AV: E=Sophos;i="4.55,253,1278288000"; d="scan'208";a="138645852" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Jul 2010 15:43:40 +0000 Received: from [10.61.85.225] (ams3-vpn-dhcp5602.cisco.com [10.61.85.225]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6OFhbRp010741; Sat, 24 Jul 2010 15:43:39 GMT Message-ID: <4C4B0A28.4040206@cisco.com> Date: Sat, 24 Jul 2010 11:43:36 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Marshall Eubanks References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com><04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> <15655197-E667-4A1F-BD12-1A 1961081D7D@americafree.tv> <1C6FD77A-A6C6-4897-B1CA-D2FC844522F1@americafree.tv> In-Reply-To: <1C6FD77A-A6C6-4897-B1CA-D2FC844522F1@americafree.tv> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 15:43:22 -0000 Marshall Eubanks wrote: > Based on the doodle, and with Mary Barnes acceptance (as she will not be > able to attend), I think that > we should meet just after the last session on Monday. (See the Doodle > site for the votes.) Any idea *where* to meet? Perhaps in the ietf registration table area? (Not having seen the facility yet, I don't know what else there is.) > Do people want to make this a dinner meeting and, if so, in the MECC > area or somewhere else ? Specific suggestions would be welcomed. If we are meeting at 7:50, then unless its for dinner there may not be any dinner. So dinner sounds good to me. I have no idea of where. I haven't done *any* homework on Mastricht. Thanks, Paul From vvenkatar@gmail.com Sat Jul 24 12:56:33 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7443A687F for ; Sat, 24 Jul 2010 12:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FUZZY_PRICES=1.304, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZ7fPbye7pcT for ; Sat, 24 Jul 2010 12:56:32 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id F1B873A6872 for ; Sat, 24 Jul 2010 12:56:31 -0700 (PDT) Received: by qyk8 with SMTP id 8so1009717qyk.10 for ; Sat, 24 Jul 2010 12:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=359UwDiKdn/1Z43PjweQXPF9EFEH2BWiDdchkkGl+wM=; b=G9pwuALMB9lZmjWZmNxsxnv+qNhS8egkkI9MU5KXaEQUj4K9uE/ndRibAfXlVjHZGG VFcqMLH9Y99d2IKS5vZk+9K4H6rqLm9NLffc5ILn0SYQ+ytzRC7SN2wcMCq3vVArgCZ4 rOOAX1rM5jVevqATP8Hp1jcJBTFFI3JqtHAG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f9tdOwhbeiu+2DJN+Nu0f6u4oabK12MicpsGWrwESCOyrjBAgP6dTePI801teT9DI3 iexsHZpC0dl/3CREB0YHeV5W/DEb8CdDaZuHb/d+UXG4hwz3LX+a4bedk+PVuT2T8YlJ 9zrjtqnQBcy/0ihTcu9hfaQkYuqF8zVWGENtM= MIME-Version: 1.0 Received: by 10.224.26.8 with SMTP id b8mr4185511qac.25.1280001410876; Sat, 24 Jul 2010 12:56:50 -0700 (PDT) Received: by 10.229.215.199 with HTTP; Sat, 24 Jul 2010 12:56:50 -0700 (PDT) In-Reply-To: References: Date: Sat, 24 Jul 2010 12:56:50 -0700 Message-ID: From: Venkatesh To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=000feaf1dc6a68476b048c278d3e Subject: Re: [dispatch] Possible bar bof on a global videoconferencing / telepresence directory ? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 19:56:33 -0000 --000feaf1dc6a68476b048c278d3e Content-Type: text/plain; charset=ISO-8859-1 Marshall: I am not sure I understand the problem this proposal is trying to solve. A "directory" in my opinion is a repository of data that provides various kinds of contact information of a person/organization. In this sense, it can provide things like name, street addresses, phone numbers, fax, email, Web URL and such. It can potentially be searched (or "looked up") to find specific person/organization whose name you know. I suspect this is NOT what you are calling as "directory". I suspect your notion of a directory is how do I "route" a request to the party who is being "addressed" in the request. This is akin to email (postal/telephone) infrastructure making a determination as to how to deliver the request received for the recipient. Assuming it is the latter you are talking about, there are a variety of techniques in place that potentially can provide satisfactory solutions to this problem depending upon how the recipient is identified. Typical solutions could be: 1. DNS SRV records if the identity of the recipient is a URL. 2. E.NUM (Public, Infrastructure, Private, or providers like Nuestar..) if the identity is expressed using the traditional E.164 address. 3. Potentially use ViPR like solutions that are being talked about in the dispatch mailing list. Would none of the above address your requirements? Venkatesh Something that I have been giving a lot of thought to recently is how to establish a global directory for videoconferencing and telepresence, and whether this should be based on / derived from ENUM. So, I am wondering if - there are others here interested in this same topic and - whether or not we should get together briefly for a "bar bof" or an even more informal meeting in Maastricht. So, if this subject interests you, please respond to this email. If there is interest, I will set up a quick doodle. Regards Marshall _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------ End of Forwarded Message --000feaf1dc6a68476b048c278d3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Marshall:

I am not sure I understand the problem this = proposal is trying to solve. A "directory" in my opinion is a rep= ository of data that provides various kinds of contact information of a per= son/organization. In this sense, it can provide things like name, street ad= dresses, phone numbers, fax, email, Web URL and such. It can potentially be= searched (or "looked up") to find specific person/organization w= hose name you know. I suspect this is NOT what you are calling as "dir= ectory". I suspect your notion of a directory is how do I "route&= quot; a request to the party who is being "addressed" in the requ= est. This is akin to email (postal/telephone) infrastructure making a deter= mination as to how to deliver the request received for the recipient. =A0 A= ssuming it is the latter you are talking about, there are a variety of tech= niques in place that potentially can provide satisfactory solutions to this= problem depending upon how the recipient is identified. =A0Typical solutio= ns could be:

1. DNS SRV = records if the identity of the recipient is a URL.
2. E.NUM (Public, Infrastructure, Private, or providers like Nuesta= r..) if the identity is expressed using the traditional E.164 address.
3. Potentially use ViPR like solutions that are = being talked about in the dispatch mailing list.

Would none of the above address = your requirements?

Venkatesh

Something that I have been giving a lot of thought to recently is how
to establish a global directory for videoconferencing and
telepresence, and whether this should be based on / derived from ENUM.

So, I am wondering if

- there are others here interested in this same topic and
- whether or not we should get together briefly for a "bar bof" o= r an
even more informal meeting in Maastricht.

So, if this subject interests you, please respond to this email. If
there is interest, I will set up a quick doodle.

Regards
Marshall

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

------ End of Forwarded Message


--000feaf1dc6a68476b048c278d3e-- From tme@americafree.tv Sat Jul 24 14:10:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FA893A67D1 for ; Sat, 24 Jul 2010 14:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bmFf0c3dB6H5 for ; Sat, 24 Jul 2010 14:10:54 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id F28AB3A683A for ; Sat, 24 Jul 2010 14:10:53 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id BD9E58170765; Sat, 24 Jul 2010 17:11:12 -0400 (EDT) Message-Id: <4FCE84E6-D98C-46A1-8505-E1C7578B14F4@americafree.tv> From: Marshall Eubanks To: Paul Kyzivat In-Reply-To: <4C4B0A28.4040206@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 24 Jul 2010 17:11:11 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com><04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> <15655197-E667-4A1F-BD12-1A 1961081D7D@americafree.tv> <1C6FD77A-A6C6-4897-B1CA-D2FC844522F1@americafree.tv> <4C4B0A28.4040206@cisco.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 21:10:55 -0000 How about this Lunch will be available from 11:00 to 15:00 Monday through Thursday in the Expo Foyer at the MECC, and 11:00 to 14:00 on Friday. The menu will vary throughout the week, but a sample of offered items is below: Marshall On Jul 24, 2010, at 11:43 AM, Paul Kyzivat wrote: > > > Marshall Eubanks wrote: > >> Based on the doodle, and with Mary Barnes acceptance (as she will >> not be able to attend), I think that >> we should meet just after the last session on Monday. (See the >> Doodle site for the votes.) > > Any idea *where* to meet? Perhaps in the ietf registration table area? > (Not having seen the facility yet, I don't know what else there is.) > >> Do people want to make this a dinner meeting and, if so, in the >> MECC area or somewhere else ? Specific suggestions would be welcomed. > > If we are meeting at 7:50, then unless its for dinner there may not > be any dinner. So dinner sounds good to me. > > I have no idea of where. I haven't done *any* homework on Mastricht. > > Thanks, > Paul > From tme@americafree.tv Sun Jul 25 18:48:49 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846173A6914 for ; Sun, 25 Jul 2010 18:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.494 X-Spam-Level: X-Spam-Status: No, score=-102.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDEWF6sqNJ1o for ; Sun, 25 Jul 2010 18:48:48 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 9C7503A695B for ; Sun, 25 Jul 2010 18:48:48 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 0E0ED81A363B; Sun, 25 Jul 2010 21:49:07 -0400 (EDT) Message-Id: <99AD8262-C872-4F9D-8DA9-CF4E562141E6@americafree.tv> From: Marshall Eubanks To: Marshall Eubanks In-Reply-To: <4FCE84E6-D98C-46A1-8505-E1C7578B14F4@americafree.tv> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 21:49:06 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com><04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> <15655197-E667-4A1F-BD12-1A 1961081D7D@americafree.tv> <1C6FD77A-A6C6-4897-B1CA-D2FC844522F1@americafree.tv> <4C4B0A28.4040206@cisco.com> <4FCE84E6-D98C-46A1-8505 -E1C7578B14F4@americafree.tv> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 01:48:49 -0000 Sorry - please disregard that, as this will NOT be a lunch meeting. This is a dinner meeting. I would suggest that we either - eat at the NH hotel or - take a taxi to the city center. Regards Marshall On Jul 24, 2010, at 5:11 PM, Marshall Eubanks wrote: > How about this > > Lunch will be available from 11:00 to 15:00 Monday through Thursday > in the > Expo Foyer at the MECC, and 11:00 to 14:00 on Friday. The menu will > vary > throughout the week, but a sample of offered items is below: > > Marshall > > On Jul 24, 2010, at 11:43 AM, Paul Kyzivat wrote: > >> >> >> Marshall Eubanks wrote: >> >>> Based on the doodle, and with Mary Barnes acceptance (as she will >>> not be able to attend), I think that >>> we should meet just after the last session on Monday. (See the >>> Doodle site for the votes.) >> >> Any idea *where* to meet? Perhaps in the ietf registration table >> area? >> (Not having seen the facility yet, I don't know what else there is.) >> >>> Do people want to make this a dinner meeting and, if so, in the >>> MECC area or somewhere else ? Specific suggestions would be >>> welcomed. >> >> If we are meeting at 7:50, then unless its for dinner there may not >> be any dinner. So dinner sounds good to me. >> >> I have no idea of where. I haven't done *any* homework on Mastricht. >> >> Thanks, >> Paul >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From tme@americafree.tv Sun Jul 25 19:25:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A5D73A6817 for ; Sun, 25 Jul 2010 19:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goZzl0oru6+D for ; Sun, 25 Jul 2010 19:25:40 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 6B4E93A67D4 for ; Sun, 25 Jul 2010 19:25:40 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 81DDB81A48A5; Sun, 25 Jul 2010 22:26:00 -0400 (EDT) Message-Id: <368EAE3E-191E-479B-B8B1-1D0874DFDA9F@americafree.tv> From: Marshall Eubanks To: Marshall Eubanks , bernie@ucom.ch In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 25 Jul 2010 22:25:59 -0400 References: X-Mailer: Apple Mail (2.936) Cc: DISPATCH list Subject: Re: [dispatch] Possible bar bof on a global videoconferencing / telepresence directory ? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 02:25:41 -0000 Based on the doodle, I think that this should be Thursday at lunch and (although I would love to hear any other suggestions) we probably should just get a lunch at the MECC. I have invited Bernie Hoeneisen, the ENUM chair. Regards Marshall On Jul 23, 2010, at 12:04 PM, Marshall Eubanks wrote: > Well, we got a little interest, so I set up a Doodle poll : > > http://www.doodle.com/424zcx6iqicfy8nz > > If you are interested, please select one or more times. As before, > use green for prefer, yellow for OK, red for can't make it. > > Regards > > Marshall > > On Jul 22, 2010, at 11:12 AM, Marshall Eubanks wrote: > >> Something that I have been giving a lot of thought to recently is >> how to establish a global directory for videoconferencing and >> telepresence, and whether this should be based on / derived from >> ENUM. >> >> So, I am wondering if >> >> - there are others here interested in this same topic and >> - whether or not we should get together briefly for a "bar bof" or >> an even more informal meeting in Maastricht. >> >> So, if this subject interests you, please respond to this email. If >> there is interest, I will set up a quick doodle. >> >> Regards >> Marshall >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > From gonzalo.camarillo@ericsson.com Sun Jul 25 23:53:04 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 102523A67F5 for ; Sun, 25 Jul 2010 23:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.83 X-Spam-Level: X-Spam-Status: No, score=-103.83 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oV1DXPzWPFDK for ; Sun, 25 Jul 2010 23:53:02 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D00773A67A4 for ; Sun, 25 Jul 2010 23:53:01 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-4b-4c4d30e1e544 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 67.55.06895.1E03D4C4; Mon, 26 Jul 2010 08:53:21 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 08:53:20 +0200 Received: from [131.160.126.137] ([131.160.126.137]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 08:53:20 +0200 Message-ID: <4C4D30E0.7000603@ericsson.com> Date: Mon, 26 Jul 2010 08:53:20 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Marshall Eubanks References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><022f01cb1eb4$2f9f59b0$8ede0d10$@com><04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> <15655197-E667-4A1F-BD12-1A 1961081D7D@americafree.tv> <1C6FD77A-A6C6-4897-B1CA-D2FC844522F1@americafree.tv> <4C4B0A28.4040206@cisco.com> <4FCE84E6-D98C-46A1-8505 -E1C7578B14F4@americafree.tv> <99AD8262-C872-4F9D-8DA9-CF4E562141E6@americafree.tv > In-Reply-To: <99AD8262-C872-4F9D-8DA9-CF4E562141E6@americafree.tv> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2010 06:53:20.0604 (UTC) FILETIME=[3BD659C0:01CB2C8F] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 06:53:04 -0000 Hi Marshall, the last session today ends at 19:40. Where and when exactly shall we meet? Thanks, Gonzalo On 26/07/2010 3:49 AM, Marshall Eubanks wrote: > Sorry - please disregard that, as this will NOT be a lunch meeting. > This is a dinner meeting. > > I would suggest that we either > > - eat at the NH hotel or > - take a taxi to the city center. > > Regards > Marshall > > On Jul 24, 2010, at 5:11 PM, Marshall Eubanks wrote: > >> How about this >> >> Lunch will be available from 11:00 to 15:00 Monday through Thursday >> in the >> Expo Foyer at the MECC, and 11:00 to 14:00 on Friday. The menu will >> vary >> throughout the week, but a sample of offered items is below: >> >> Marshall >> >> On Jul 24, 2010, at 11:43 AM, Paul Kyzivat wrote: >> >>> >>> >>> Marshall Eubanks wrote: >>> >>>> Based on the doodle, and with Mary Barnes acceptance (as she will >>>> not be able to attend), I think that >>>> we should meet just after the last session on Monday. (See the >>>> Doodle site for the votes.) >>> >>> Any idea *where* to meet? Perhaps in the ietf registration table >>> area? >>> (Not having seen the facility yet, I don't know what else there is.) >>> >>>> Do people want to make this a dinner meeting and, if so, in the >>>> MECC area or somewhere else ? Specific suggestions would be >>>> welcomed. >>> >>> If we are meeting at 7:50, then unless its for dinner there may not >>> be any dinner. So dinner sounds good to me. >>> >>> I have no idea of where. I haven't done *any* homework on Mastricht. >>> >>> 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 > From gonzalo.camarillo@ericsson.com Mon Jul 26 01:21:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70AC93A6881 for ; Mon, 26 Jul 2010 01:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.809 X-Spam-Level: X-Spam-Status: No, score=-105.809 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxZ94E33UnAv for ; Mon, 26 Jul 2010 01:21:58 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 1D9073A683A for ; Mon, 26 Jul 2010 01:21:57 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-f7-4c4d45ba069c Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B7.B7.10125.AB54D4C4; Mon, 26 Jul 2010 10:22:18 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 10:22:18 +0200 Received: from [131.160.126.137] ([131.160.126.137]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 10:22:17 +0200 Message-ID: <4C4D45B9.5040109@ericsson.com> Date: Mon, 26 Jul 2010 10:22:17 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "dispatch@ietf.org" References: <038601cb23c1$e367c4c0$23548a0a@china.huawei.com> In-Reply-To: <038601cb23c1$e367c4c0$23548a0a@china.huawei.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2010 08:22:17.0264 (UTC) FILETIME=[A8BC0B00:01CB2C9B] X-Brightmail-Tracker: AAAAAA== Subject: Re: [dispatch] Fw: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 08:21:59 -0000 Folks, there has been quite a lot of interest around HTTP-based streaming. While this topic relates to both the Applications and RAI areas, we have decided to discuss it in DISPATCH for the time being. We would appreciate comments both on the draft below and on the topic in general. Thanks, Gonzalo On 15/07/2010 4:03 AM, Qin Wu wrote: > Hi, folks: > The new version of draft-wu-http-streaming-optimization is available at: > http://www.ietf.org/internet-drafts/draft-wu-http-streaming-optimization-ps-00.txt > > Currently, this draft is at the very early stage and primarily a problem statement > identifying goals and issues, discussing possible use cases and sketching a possible direction > for HTTP streaming support. > > Please drop your comments and share your opinons on this topic if you like or not. > > Regards! > -Qin > ----- Original Message ----- > From: > To: > Sent: Monday, July 05, 2010 4:00 PM > Subject: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt > > >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : HTTP streaming optimization Problem Statement >> Author(s) : W. Wu >> Filename : draft-wu-http-streaming-optimization-ps-00.txt >> Pages : 19 >> Date : 2010-07-05 >> >> HTTP Streaming allows breaking the live contents or stored contents >> into several chunks/fragments and supplying them in order to the >> client. Several issues regarding control over the delivery of data >> with real-time property using HTTP have been raised. Also various >> issues arise when we consider offering the video quality requirements >> to streaming video over Internet. This document describes these >> issues. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-wu-http-streaming-optimization-ps-00.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> > > > -------------------------------------------------------------------------------- > > >> _______________________________________________ >> 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 D.Malas@cablelabs.com Mon Jul 26 01:53:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6EC83A69F0 for ; Mon, 26 Jul 2010 01:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHV+M2G373FD for ; Mon, 26 Jul 2010 01:53:13 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id 72CF53A6A17 for ; Mon, 26 Jul 2010 01:53:13 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o6Q8rWMj009026; Mon, 26 Jul 2010 02:53:32 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 26 Jul 2010 02:53:32 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 26 Jul 2010 02:53:33 -0600 From: Daryl Malas To: Hadriel Kaplan Date: Mon, 26 Jul 2010 02:53:30 -0600 Thread-Topic: Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsiqbaMfHyiLn9KSoGceaY0EYk4fwJ9Zt9A Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01421A4ADF@srvxchg> References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> 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_114DAD31379DFA438C0A2E39B3B8AF5D01421A4ADFsrvxchg_" MIME-Version: 1.0 X-Approved: ondar Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 08:53:14 -0000 --_000_114DAD31379DFA438C0A2E39B3B8AF5D01421A4ADFsrvxchg_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hadriel, I read through the draft, and I have a couple of questions. First, let me = say, I tried to read through all of the various questions and comments to s= ee if my questions are duplicative, but I may have missed something. Pleas= e just point me to an applicable thread if one already exists. Also, I am = fairly new in reading this issue, so bear with me if these questions seem r= ather naive. Questions: 1. Does it make more sense to modify or update call-id rather than define = a new session-id? 2. Does it make more sense to create a new session-id or tell middle devic= es not to mess with the call-id? 3. The draft implies that call-id does not work, but it does not provide a= ny good background as to all of those reasons except that "middle" devices = change it. Why do they change it, so that this option does not work? I think answering these questions in the draft will provide a better argume= nt for the session-id, assuming there is one. Regards, Daryl ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Hadriel Kaplan Sent: Tuesday, July 13, 2010 6:38 PM To: dispatch@ietf.org Subject: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Howdy, I submitted an updated version of the session-id draft, for consideration a= s a solution for the (hopefully) new WG for such purpose. The major changes are: 1) Reverted the generation of the session-id value to be a defined 128-b= it hash mechanism, as it was prior to version 1, based on feedback that hav= ing it be a known algorithm allows a monitoring system with the same privat= e key to generate the value itself for matching purposes. 2) Added a section on transfer handling, for REFER and INVITE-with-Repla= ces, such that a transferred call uses the same session-id. This section i= s just a beginning strawman and will need more thought. A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A Session Identifier for the Session Initiation Pro= tocol (SIP) Author(s) : H. Kaplan Filename : draft-kaplan-dispatch-session-id-02.txt Pages : 13 Date : 2010-07-12 There is a need for having a globally unique session identifier for the sam= e SIP session, which can be consistently maintained across Proxies, B2BUAs = and other SIP middle-boxes, for the purpose of Troubleshooting. This draft= proposes a new SIP header to carry such a value: Session-ID. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id-02.txt --_000_114DAD31379DFA438C0A2E39B3B8AF5D01421A4ADFsrvxchg_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hadriel,
 
I read through the draft, and I have a couple of= =20 questions.  First, let me say, I tried to read through all of the vari= ous=20 questions and comments to see if my questions are duplicative, but I may ha= ve=20 missed something.  Please just point me to an applicable thread if one= =20 already exists.  Also, I am fairly new in reading this issue, so bear = with=20 me if these questions seem rather naive.
 
Questions:
 
1.  Does it make more sense to modify or up= date=20 call-id rather than define a new session-id?
2.  Does it make more sense to create a new= =20 session-id or tell middle devices not to mess with the=20 call-id?
3.  The draft implies that call-id does not= work,=20 but it does not provide any good background as to all of those reasons exce= pt=20 that "middle" devices change it.  Why do they change it, so that this= =20 option does not work?
 
I think answering these questions in the draft w= ill=20 provide a better argument for the session-id, assuming there is=20 one.
 
Regards,

Daryl

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel=20 Kaplan
Sent: Tuesday, July 13, 2010 6:38 PM
To:=20 dispatch@ietf.org
Subject: [dispatch] Updated:=20 draft-kaplan-dispatch-session-id-02

Howdy,

I submitted an update= d=20 version of the session-id draft, for consideration as a solution for the=20 (hopefully) new WG for such purpose.

 

The major changes=20 are:

= 1)   =20 Reverted the generati= on of=20 the session-id value to be a defined 128-bit hash mechanism, as it was prio= r to=20 version 1, based on feedback that having it be a known algorithm allows a=20 monitoring system with the same private key to generate the value itself fo= r=20 matching purposes.

= 2)   =20 Added a section on tr= ansfer=20 handling, for REFER and INVITE-with-Replaces, such that a transferred call = uses=20 the same session-id.  This section is just a beginning strawman and wi= ll=20 need more thought.

 

 

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

 

   &nb= sp; =20 Title           : A Sessi= on=20 Identifier for the Session Initiation Protocol=20 (SIP)

   &nb= sp; =20 Author(s)       : H.=20 Kaplan

   &nb= sp; =20 Filename        :=20 draft-kaplan-dispatch-session-id-02.txt

   &nb= sp; =20 Pages           :=20 13

   &nb= sp; =20 Date            :=20 2010-07-12

 

There is a need for h= aving a=20 globally unique session identifier for the same SIP session, which can be=20 consistently maintained across Proxies, B2BUAs and other SIP middle-boxes, = for=20 the purpose of Troubleshooting.  This draft proposes a new SIP header = to=20 carry such a value: Session-ID.

 

A URL for this=20 Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session= -id-02.txt

 

 

--_000_114DAD31379DFA438C0A2E39B3B8AF5D01421A4ADFsrvxchg_-- From D.Malas@cablelabs.com Mon Jul 26 01:54:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 787933A69F0 for ; Mon, 26 Jul 2010 01:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.262 X-Spam-Level: X-Spam-Status: No, score=-0.262 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NDtYVeGTvnw for ; Mon, 26 Jul 2010 01:54:16 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by core3.amsl.com (Postfix) with ESMTP id E689C3A69D2 for ; Mon, 26 Jul 2010 01:54:15 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.4/8.14.4) with ESMTP id o6Q8sYIB009097; Mon, 26 Jul 2010 02:54:34 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com); Mon, 26 Jul 2010 02:54:34 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/303/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Mon, 26 Jul 2010 02:54:35 -0600 From: Daryl Malas To: Marshall Eubanks Date: Mon, 26 Jul 2010 02:54:32 -0600 Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: AcssZL55Wur3CD8KSZmXB/JgbJx5IQAO1BNg Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01421A4AE0@srvxchg> References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com><04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> <15655197-E667-4A1F-BD12-1A 1961081D7D@americafree.tv> <1C6FD77A-A6C6-4897-B1CA-D2FC844522F1@americafree.tv> <4C4B0A28.4040206@cisco.com> <4FCE84E6-D98C-46A1-8505 -E1C7578B14F4@americafree.tv> <99AD8262-C872-4F9D-8DA9-CF4E562141E6@americafree.tv> In-Reply-To: <99AD8262-C872-4F9D-8DA9-CF4E562141E6@americafree.tv> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 08:54:17 -0000 Marshall, I am pretty much just waiting for a decision to be made, and I will attempt= to meet up for discussion on this topic. Regards, Daryl=20 -----Original Message----- From: Marshall Eubanks [mailto:tme@americafree.tv]=20 Sent: Monday, July 26, 2010 3:49 AM To: Marshall Eubanks Cc: Paul Kyzivat; DISPATCH list; Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? Sorry - please disregard that, as this will NOT be a lunch meeting. =20 This is a dinner meeting. I would suggest that we either - eat at the NH hotel or - take a taxi to the city center. Regards Marshall On Jul 24, 2010, at 5:11 PM, Marshall Eubanks wrote: > How about this > > Lunch will be available from 11:00 to 15:00 Monday through Thursday in=20 > the Expo Foyer at the MECC, and 11:00 to 14:00 on Friday. The menu=20 > will vary throughout the week, but a sample of offered items is below: > > Marshall > > On Jul 24, 2010, at 11:43 AM, Paul Kyzivat wrote: > >> >> >> Marshall Eubanks wrote: >> >>> Based on the doodle, and with Mary Barnes acceptance (as she will=20 >>> not be able to attend), I think that we should meet just after the=20 >>> last session on Monday. (See the Doodle site for the votes.) >> >> Any idea *where* to meet? Perhaps in the ietf registration table=20 >> area? >> (Not having seen the facility yet, I don't know what else there is.) >> >>> Do people want to make this a dinner meeting and, if so, in the MECC=20 >>> area or somewhere else ? Specific suggestions would be welcomed. >> >> If we are meeting at 7:50, then unless its for dinner there may not=20 >> be any dinner. So dinner sounds good to me. >> >> I have no idea of where. I haven't done *any* homework on Mastricht. >> >> Thanks, >> Paul >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From dromasca@avaya.com Mon Jul 26 01:59:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 644B23A6AE6 for ; Mon, 26 Jul 2010 01:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.481 X-Spam-Level: X-Spam-Status: No, score=-2.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTZji9Qm2Q2g for ; Mon, 26 Jul 2010 01:59:32 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id A4EEB3A6ADA for ; Mon, 26 Jul 2010 01:59:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,260,1278302400"; d="scan'208";a="229599182" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 26 Jul 2010 04:59:53 -0400 X-IronPort-AV: E=Sophos;i="4.55,260,1278302400"; d="scan'208";a="485660571" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 26 Jul 2010 04:59:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Jul 2010 10:59:43 +0200 Message-ID: In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01421A4AE0@srvxchg> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Should IETF have a BEHAVE WG for SBCs? Thread-Index: AcssZL55Wur3CD8KSZmXB/JgbJx5IQAO1BNgAAAvKWA= References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com><04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv><02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv><15655197-E667-4A1F-BD12-1A 1961081D7D@americafree.tv><1C6FD77A-A6C6-4897-B1CA-D2FC844522F1@americafree.tv><4C4B0A28.4040206@cisco.com> <4FCE84E6-D98C-46A1-8505-E1C75 78B14F4@ americafree. tv><99AD8262-C872-4F9D-8DA9-CF4E562141E6@americafree.tv> <114DAD31379DFA438C0A2E39B3B8AF5D01421A4AE0@srvxchg> From: "Romascanu, Dan (Dan)" To: "Daryl Malas" , "Marshall Eubanks" Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 08:59:37 -0000 Sorry, I lost something in the chain. What day are we talking about?=20 Dan =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas > Sent: Monday, July 26, 2010 11:55 AM > To: Marshall Eubanks > Cc: DISPATCH list > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >=20 > Marshall, >=20 > I am pretty much just waiting for a decision to be made, and=20 > I will attempt to meet up for discussion on this topic. >=20 > Regards, >=20 > Daryl=20 >=20 > -----Original Message----- > From: Marshall Eubanks [mailto:tme@americafree.tv] > Sent: Monday, July 26, 2010 3:49 AM > To: Marshall Eubanks > Cc: Paul Kyzivat; DISPATCH list; Daryl Malas > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >=20 > Sorry - please disregard that, as this will NOT be a lunch meeting. =20 > This is a dinner meeting. >=20 > I would suggest that we either >=20 > - eat at the NH hotel or > - take a taxi to the city center. >=20 > Regards > Marshall >=20 > On Jul 24, 2010, at 5:11 PM, Marshall Eubanks wrote: >=20 > > How about this > > > > Lunch will be available from 11:00 to 15:00 Monday through=20 > Thursday in=20 > > the Expo Foyer at the MECC, and 11:00 to 14:00 on Friday. The menu=20 > > will vary throughout the week, but a sample of offered=20 > items is below: > > > > Marshall > > > > On Jul 24, 2010, at 11:43 AM, Paul Kyzivat wrote: > > > >> > >> > >> Marshall Eubanks wrote: > >> > >>> Based on the doodle, and with Mary Barnes acceptance (as she will=20 > >>> not be able to attend), I think that we should meet just=20 > after the=20 > >>> last session on Monday. (See the Doodle site for the votes.) > >> > >> Any idea *where* to meet? Perhaps in the ietf registration table=20 > >> area? > >> (Not having seen the facility yet, I don't know what else=20 > there is.) > >> > >>> Do people want to make this a dinner meeting and, if so,=20 > in the MECC=20 > >>> area or somewhere else ? Specific suggestions would be welcomed. > >> > >> If we are meeting at 7:50, then unless its for dinner=20 > there may not=20 > >> be any dinner. So dinner sounds good to me. > >> > >> I have no idea of where. I haven't done *any* homework on=20 > Mastricht. > >> > >> Thanks, > >> Paul > >> > > > > _______________________________________________ > > 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 >=20 From tme@americafree.tv Mon Jul 26 02:06:01 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333AE3A6ACB for ; Mon, 26 Jul 2010 02:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyXNucyXWlcB for ; Mon, 26 Jul 2010 02:06:00 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id F3B9B3A6A6D for ; Mon, 26 Jul 2010 02:05:59 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id E881481B0715; Mon, 26 Jul 2010 05:06:19 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Daryl Malas In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01421A4AE0@srvxchg> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 05:06:17 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com><04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> <15655197-E667-4A1F-BD12-1A 1961081D7D@americafree.tv> <1C6FD77A-A6C6-4897-B1CA-D2FC844522F1@americafree.tv> <4C4B0A28.4040206@cisco.com> <4FCE84E6-D98C-46A1-8505 -E1C7578B14F4@americafree.tv> <99AD8262-C872-4F9D-8DA9-CF4E562141E6@americafree.tv> <114DAD31379DFA438C0A2E39B3B8AF5D01421A4AE0@srvxchg> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 09:06:01 -0000 Let's meet at the giant white inflatable Tulip in front of registration (by the SIDN exhibit) at 1740 - 1750. My cell is + 1 703 501 4376, in case you need to call. Marshall On Jul 26, 2010, at 4:54 AM, Daryl Malas wrote: > Marshall, > > I am pretty much just waiting for a decision to be made, and I will > attempt to meet up for discussion on this topic. > > Regards, > > Daryl > > -----Original Message----- > From: Marshall Eubanks [mailto:tme@americafree.tv] > Sent: Monday, July 26, 2010 3:49 AM > To: Marshall Eubanks > Cc: Paul Kyzivat; DISPATCH list; Daryl Malas > Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? > > Sorry - please disregard that, as this will NOT be a lunch meeting. > This is a dinner meeting. > > I would suggest that we either > > - eat at the NH hotel or > - take a taxi to the city center. > > Regards > Marshall > > On Jul 24, 2010, at 5:11 PM, Marshall Eubanks wrote: > >> How about this >> >> Lunch will be available from 11:00 to 15:00 Monday through Thursday >> in >> the Expo Foyer at the MECC, and 11:00 to 14:00 on Friday. The menu >> will vary throughout the week, but a sample of offered items is >> below: >> >> Marshall >> >> On Jul 24, 2010, at 11:43 AM, Paul Kyzivat wrote: >> >>> >>> >>> Marshall Eubanks wrote: >>> >>>> Based on the doodle, and with Mary Barnes acceptance (as she will >>>> not be able to attend), I think that we should meet just after the >>>> last session on Monday. (See the Doodle site for the votes.) >>> >>> Any idea *where* to meet? Perhaps in the ietf registration table >>> area? >>> (Not having seen the facility yet, I don't know what else there is.) >>> >>>> Do people want to make this a dinner meeting and, if so, in the >>>> MECC >>>> area or somewhere else ? Specific suggestions would be welcomed. >>> >>> If we are meeting at 7:50, then unless its for dinner there may not >>> be any dinner. So dinner sounds good to me. >>> >>> I have no idea of where. I haven't done *any* homework on Mastricht. >>> >>> Thanks, >>> Paul >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > > From tme@americafree.tv Mon Jul 26 02:10:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506163A6AA6 for ; Mon, 26 Jul 2010 02:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgdYZjO99lED for ; Mon, 26 Jul 2010 02:10:10 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 034513A67E5 for ; Mon, 26 Jul 2010 02:10:09 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 5AF2681B0947; Mon, 26 Jul 2010 05:10:29 -0400 (EDT) Message-Id: From: Marshall Eubanks To: "Romascanu, Dan (Dan)" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 05:10:28 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><27fc01cb1e08$13467f70$39d37e50$@com><022f01cb1eb4$2f9f59b0$8ede0d10$@com><04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv><02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv><15655197-E667-4A1F-BD12-1A 1961081D7D@americafree.tv><1C6FD77A-A6C6-4897-B1CA-D2FC844522F1@americafree.tv><4C4B0A28.4040206@cisco.com> <4FCE84E6-D98C-46A1-8505-E1C75 78B14F4@ americafree. tv><99AD8262-C872-4F9D-8DA9-CF4E562141E6@americafree.tv> <114DAD31379DFA438C0A2E39B3B8AF5D01421A4AE0@srvxchg> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 09:10:15 -0000 Today, Monday, at the end of the regular sessions. At the giant white tulip at registration. Regards Marshall On Jul 26, 2010, at 4:59 AM, Romascanu, Dan (Dan) wrote: > Sorry, I lost something in the chain. What day are we talking about? > > Dan > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Daryl Malas >> Sent: Monday, July 26, 2010 11:55 AM >> To: Marshall Eubanks >> Cc: DISPATCH list >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >> >> Marshall, >> >> I am pretty much just waiting for a decision to be made, and >> I will attempt to meet up for discussion on this topic. >> >> Regards, >> >> Daryl >> >> -----Original Message----- >> From: Marshall Eubanks [mailto:tme@americafree.tv] >> Sent: Monday, July 26, 2010 3:49 AM >> To: Marshall Eubanks >> Cc: Paul Kyzivat; DISPATCH list; Daryl Malas >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >> >> Sorry - please disregard that, as this will NOT be a lunch meeting. >> This is a dinner meeting. >> >> I would suggest that we either >> >> - eat at the NH hotel or >> - take a taxi to the city center. >> >> Regards >> Marshall >> >> On Jul 24, 2010, at 5:11 PM, Marshall Eubanks wrote: >> >>> How about this >>> >>> Lunch will be available from 11:00 to 15:00 Monday through >> Thursday in >>> the Expo Foyer at the MECC, and 11:00 to 14:00 on Friday. The menu >>> will vary throughout the week, but a sample of offered >> items is below: >>> >>> Marshall >>> >>> On Jul 24, 2010, at 11:43 AM, Paul Kyzivat wrote: >>> >>>> >>>> >>>> Marshall Eubanks wrote: >>>> >>>>> Based on the doodle, and with Mary Barnes acceptance (as she will >>>>> not be able to attend), I think that we should meet just >> after the >>>>> last session on Monday. (See the Doodle site for the votes.) >>>> >>>> Any idea *where* to meet? Perhaps in the ietf registration table >>>> area? >>>> (Not having seen the facility yet, I don't know what else >> there is.) >>>> >>>>> Do people want to make this a dinner meeting and, if so, >> in the MECC >>>>> area or somewhere else ? Specific suggestions would be welcomed. >>>> >>>> If we are meeting at 7:50, then unless its for dinner >> there may not >>>> be any dinner. So dinner sounds good to me. >>>> >>>> I have no idea of where. I haven't done *any* homework on >> Mastricht. >>>> >>>> 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 >> > From pkyzivat@cisco.com Mon Jul 26 02:12:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144AE3A68B2 for ; Mon, 26 Jul 2010 02:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.572 X-Spam-Level: X-Spam-Status: No, score=-10.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCsZJYq7sEFG for ; Mon, 26 Jul 2010 02:12:01 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9D79A3A68E8 for ; Mon, 26 Jul 2010 02:12:00 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALbuTExAZnwN/2dsb2JhbACfYHGkR5oPgwiCLgSIZA X-IronPort-AV: E=Sophos;i="4.55,260,1278288000"; d="scan'208";a="139097385" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 26 Jul 2010 09:12:21 +0000 Received: from [10.55.87.237] (dhcp-10-55-87-237.cisco.com [10.55.87.237]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6Q9CK65024909; Mon, 26 Jul 2010 09:12:20 GMT Message-ID: <4C4D5176.9000608@cisco.com> Date: Mon, 26 Jul 2010 05:12:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Marshall Eubanks References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> <15655197-E667-4A1F-BD12-1A 1961081D7D@americafree.tv> <1C6FD77A-A6C6-4897-B1CA-D2FC844522F1@americafree.tv> <4C4B0A28.4040206@cisco.com> <4FCE84E6-D98C-46A1-8505 -E1C7578B14F4@americafree.tv> <99AD8262-C872-4F9D-8DA9-CF4E562141E6@americafree.tv> <114DAD31379DFA438C0A2E39B3B8AF5D01421A4AE0@srvxchg> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 09:12:03 -0000 Marshall Eubanks wrote: > Let's meet at the giant white inflatable Tulip in front of registration > (by the SIDN exhibit) at 1740 - 1750. > > My cell is + 1 703 501 4376, in case you need to call. Don't you mean 1940 - 1950 ??? > Marshall > > On Jul 26, 2010, at 4:54 AM, Daryl Malas wrote: > >> Marshall, >> >> I am pretty much just waiting for a decision to be made, and I will >> attempt to meet up for discussion on this topic. >> >> Regards, >> >> Daryl >> >> -----Original Message----- >> From: Marshall Eubanks [mailto:tme@americafree.tv] >> Sent: Monday, July 26, 2010 3:49 AM >> To: Marshall Eubanks >> Cc: Paul Kyzivat; DISPATCH list; Daryl Malas >> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >> >> Sorry - please disregard that, as this will NOT be a lunch meeting. >> This is a dinner meeting. >> >> I would suggest that we either >> >> - eat at the NH hotel or >> - take a taxi to the city center. >> >> Regards >> Marshall >> >> On Jul 24, 2010, at 5:11 PM, Marshall Eubanks wrote: >> >>> How about this >>> >>> Lunch will be available from 11:00 to 15:00 Monday through Thursday in >>> the Expo Foyer at the MECC, and 11:00 to 14:00 on Friday. The menu >>> will vary throughout the week, but a sample of offered items is below: >>> >>> Marshall >>> >>> On Jul 24, 2010, at 11:43 AM, Paul Kyzivat wrote: >>> >>>> >>>> >>>> Marshall Eubanks wrote: >>>> >>>>> Based on the doodle, and with Mary Barnes acceptance (as she will >>>>> not be able to attend), I think that we should meet just after the >>>>> last session on Monday. (See the Doodle site for the votes.) >>>> >>>> Any idea *where* to meet? Perhaps in the ietf registration table >>>> area? >>>> (Not having seen the facility yet, I don't know what else there is.) >>>> >>>>> Do people want to make this a dinner meeting and, if so, in the MECC >>>>> area or somewhere else ? Specific suggestions would be welcomed. >>>> >>>> If we are meeting at 7:50, then unless its for dinner there may not >>>> be any dinner. So dinner sounds good to me. >>>> >>>> I have no idea of where. I haven't done *any* homework on Mastricht. >>>> >>>> Thanks, >>>> Paul >>>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> > > From bernie@ietf.hoeneisen.ch Mon Jul 26 02:13:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 153AC3A6A49 for ; Mon, 26 Jul 2010 02:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.125 X-Spam-Level: X-Spam-Status: No, score=-3.125 tagged_above=-999 required=5 tests=[AWL=-0.526, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpthlmyUzDzt for ; Mon, 26 Jul 2010 02:13:18 -0700 (PDT) Received: from softronics.hoeneisen.ch (softronics.hoeneisen.ch [62.2.86.178]) by core3.amsl.com (Postfix) with ESMTP id 1AEE83A6A6F for ; Mon, 26 Jul 2010 02:13:18 -0700 (PDT) Received: from localhost ([127.0.0.1]) by softronics.hoeneisen.ch with esmtp (Exim 4.69) (envelope-from ) id 1OdJke-0003ss-OY; Mon, 26 Jul 2010 11:13:37 +0200 Date: Mon, 26 Jul 2010 11:13:36 +0200 (CEST) From: Bernie Hoeneisen X-X-Sender: bhoeneis@softronics.hoeneisen.ch To: Marshall Eubanks In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: bernie@ietf.hoeneisen.ch X-SA-Exim-Scanned: No (on softronics.hoeneisen.ch); SAEximRunCond expanded to false Cc: DISPATCH list Subject: Re: [dispatch] Possible bar bof on a global videoconferencing / telepresence directory ? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 09:13:21 -0000 While still working with Switch, the Swiss National Research and Education Network (NREN), I was actively involved in solving this problem for the NREN community. I proposed and implemented a system based on ENUM technology. As public user ENUM (e164.arpa) was not available in every country, we implemented a transitional solution using a privately maintained apex, i.e. nrenum.net. http://www.nrenum.net/ Lateron, the nrenum.net activity was shifted to Terena, as almost every European NRENs is a member of Terena. At that time most of the NRENs were using GDS (Global Dialing Scheme) to interconnect their Videoconferencing systems. As GDS did only support H.323 and was no longer maintained, ENUM was the natural solution to the problem. I'll try to attend the Bar-BoF, so we can talk more about this. cheers, Bernie -- http://ucom.ch/ Tech Consulting for Internet Standardization On Thu, 22 Jul 2010, Marshall Eubanks wrote: > Something that I have been giving a lot of thought to recently is how to > establish a global directory for videoconferencing and telepresence, and > whether this should be based on / derived from ENUM. > > So, I am wondering if > > - there are others here interested in this same topic and > - whether or not we should get together briefly for a "bar bof" or an even > more informal meeting in Maastricht. > > So, if this subject interests you, please respond to this email. If there is > interest, I will set up a quick doodle. > > Regards > Marshall > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From tme@americafree.tv Mon Jul 26 02:28:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7F443A69F0 for ; Mon, 26 Jul 2010 02:28:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwYlybK-Y+6Z for ; Mon, 26 Jul 2010 02:28:04 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 40C223A68B0 for ; Mon, 26 Jul 2010 02:28:04 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 8620481B124B; Mon, 26 Jul 2010 05:28:24 -0400 (EDT) Message-Id: <1B7408CD-7A04-432D-88AF-CCA25261519A@americafree.tv> From: Marshall Eubanks To: Bernie Hoeneisen In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 05:28:23 -0400 References: X-Mailer: Apple Mail (2.936) Cc: DISPATCH list Subject: Re: [dispatch] Possible bar bof on a global videoconferencing / telepresence directory ? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 09:28:05 -0000 On Jul 26, 2010, at 5:13 AM, Bernie Hoeneisen wrote: > While still working with Switch, the Swiss National Research and > Education Network (NREN), I was actively involved in solving this > problem for the NREN community. I proposed and implemented a system > based on ENUM technology. As public user ENUM (e164.arpa) was not > available in every country, we implemented a transitional solution > using a privately maintained apex, i.e. nrenum.net. > > http://www.nrenum.net/ > > Lateron, the nrenum.net activity was shifted to Terena, as almost > every European NRENs is a member of Terena. > > At that time most of the NRENs were using GDS (Global Dialing > Scheme) to interconnect their Videoconferencing systems. As GDS did > only support H.323 and was no longer maintained, ENUM was the > natural solution to the problem. > > I'll try to attend the Bar-BoF, so we can talk more about this. Of course, any permanent solution has to accommodate commercial requirements, but this sounds promising. Marshall > > cheers, > Bernie > > -- > > http://ucom.ch/ > Tech Consulting for Internet Standardization > > > > > On Thu, 22 Jul 2010, Marshall Eubanks wrote: > >> Something that I have been giving a lot of thought to recently is >> how to establish a global directory for videoconferencing and >> telepresence, and whether this should be based on / derived from >> ENUM. >> >> So, I am wondering if >> >> - there are others here interested in this same topic and >> - whether or not we should get together briefly for a "bar bof" or >> an even more informal meeting in Maastricht. >> >> So, if this subject interests you, please respond to this email. If >> there is interest, I will set up a quick doodle. >> >> Regards >> Marshall >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > From tme@americafree.tv Mon Jul 26 02:28:19 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710753A6A05 for ; Mon, 26 Jul 2010 02:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.501 X-Spam-Level: X-Spam-Status: No, score=-102.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqBIOgdXWfb2 for ; Mon, 26 Jul 2010 02:28:18 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 7DA0B3A68B0 for ; Mon, 26 Jul 2010 02:28:18 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id C0AC081B1261; Mon, 26 Jul 2010 05:28:38 -0400 (EDT) Message-Id: <22E022CD-4DDC-4274-90EB-8C3693CCEA7C@americafree.tv> From: Marshall Eubanks To: Paul Kyzivat In-Reply-To: <4C4D5176.9000608@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 05:28:38 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> <15655197-E667-4A1F-BD12-1A 1961081D7D@americafree.tv> <1C6FD77A-A6C6-4897-B1CA-D2FC844522F1@americafree.tv> <4C4B0A28.4040206@cisco.com> <4FCE84E6-D98C-46A1-8505 -E1C7578B14F4@americafree.tv> <99AD8262-C872-4F9D-8DA9-CF4E562141E6@americafree.tv> <114DAD31379DFA438C0A2E39B3B8AF5D01421A4AE0@srvxchg> <4C4D5176.90 00608@cisco.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 09:28:19 -0000 Yes On Jul 26, 2010, at 5:12 AM, Paul Kyzivat wrote: > > > Marshall Eubanks wrote: >> Let's meet at the giant white inflatable Tulip in front of >> registration (by the SIDN exhibit) at 1740 - 1750. >> My cell is + 1 703 501 4376, in case you need to call. > > Don't you mean 1940 - 1950 ??? > >> Marshall >> On Jul 26, 2010, at 4:54 AM, Daryl Malas wrote: >>> Marshall, >>> >>> I am pretty much just waiting for a decision to be made, and I >>> will attempt to meet up for discussion on this topic. >>> >>> Regards, >>> >>> Daryl >>> >>> -----Original Message----- >>> From: Marshall Eubanks [mailto:tme@americafree.tv] >>> Sent: Monday, July 26, 2010 3:49 AM >>> To: Marshall Eubanks >>> Cc: Paul Kyzivat; DISPATCH list; Daryl Malas >>> Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? >>> >>> Sorry - please disregard that, as this will NOT be a lunch meeting. >>> This is a dinner meeting. >>> >>> I would suggest that we either >>> >>> - eat at the NH hotel or >>> - take a taxi to the city center. >>> >>> Regards >>> Marshall >>> >>> On Jul 24, 2010, at 5:11 PM, Marshall Eubanks wrote: >>> >>>> How about this >>>> >>>> Lunch will be available from 11:00 to 15:00 Monday through >>>> Thursday in >>>> the Expo Foyer at the MECC, and 11:00 to 14:00 on Friday. The menu >>>> will vary throughout the week, but a sample of offered items is >>>> below: >>>> >>>> Marshall >>>> >>>> On Jul 24, 2010, at 11:43 AM, Paul Kyzivat wrote: >>>> >>>>> >>>>> >>>>> Marshall Eubanks wrote: >>>>> >>>>>> Based on the doodle, and with Mary Barnes acceptance (as she will >>>>>> not be able to attend), I think that we should meet just after >>>>>> the >>>>>> last session on Monday. (See the Doodle site for the votes.) >>>>> >>>>> Any idea *where* to meet? Perhaps in the ietf registration table >>>>> area? >>>>> (Not having seen the facility yet, I don't know what else there >>>>> is.) >>>>> >>>>>> Do people want to make this a dinner meeting and, if so, in the >>>>>> MECC >>>>>> area or somewhere else ? Specific suggestions would be welcomed. >>>>> >>>>> If we are meeting at 7:50, then unless its for dinner there may >>>>> not >>>>> be any dinner. So dinner sounds good to me. >>>>> >>>>> I have no idea of where. I haven't done *any* homework on >>>>> Mastricht. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> >>> > From HKaplan@acmepacket.com Mon Jul 26 02:56:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457923A67F1 for ; Mon, 26 Jul 2010 02:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHp89YGHVCpv for ; Mon, 26 Jul 2010 02:56:06 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 26ED63A67EE for ; Mon, 26 Jul 2010 02:56:05 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 26 Jul 2010 05:56:24 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 26 Jul 2010 05:56:25 -0400 From: Hadriel Kaplan To: Daryl Malas Date: Mon, 26 Jul 2010 05:56:23 -0400 Thread-Topic: Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsiqbaMfHyiLn9KSoGceaY0EYk4fwJ9Zt9AAAIbrBA= Message-ID: <430FC6BDED356B4C8498F634416644A9269400226A@mail> References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail> <114DAD31379DFA438C0A2E39B3B8AF5D01421A4ADF@srvxchg> In-Reply-To: <114DAD31379DFA438C0A2E39B3B8AF5D01421A4ADF@srvxchg> 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_430FC6BDED356B4C8498F634416644A9269400226Amail_" MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 09:56:13 -0000 --_000_430FC6BDED356B4C8498F634416644A9269400226Amail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Daryl, That's because we've been debating this since 2008, and that topic was disc= ussed back then. :) The argument was that a B2BUA has to change the Call-ID, per RFC 3261 and i= t being a UAC. I can't remember the technical reason it had to - I thought= it was for things like the dialog event-package, so when something subscri= bes to it on the B2BUA the B2BUA will know which dialog is actually being r= eferred to (there is at least a UAS and UAC dialog, and possibly multiple).= But some of us were talking about this last night and couldn't figure out= why just having unique From-tags wouldn't be sufficient (other than rfc254= 3 devices, which we can ignore for this case). But anyway, when I first presented this in 2008 and raised b2bua's not chan= ging the call-id, the feedback on the mic was that rfc3261 mandated it and = we shouldn't be mucking with that. -hadriel ________________________________ From: Daryl Malas [mailto:D.Malas@cablelabs.com] Sent: Monday, July 26, 2010 4:54 AM To: Hadriel Kaplan Cc: dispatch@ietf.org Subject: RE: Updated: draft-kaplan-dispatch-session-id-02 Hadriel, I read through the draft, and I have a couple of questions. First, let me = say, I tried to read through all of the various questions and comments to s= ee if my questions are duplicative, but I may have missed something. Pleas= e just point me to an applicable thread if one already exists. Also, I am = fairly new in reading this issue, so bear with me if these questions seem r= ather naive. Questions: 1. Does it make more sense to modify or update call-id rather than define = a new session-id? 2. Does it make more sense to create a new session-id or tell middle devic= es not to mess with the call-id? 3. The draft implies that call-id does not work, but it does not provide a= ny good background as to all of those reasons except that "middle" devices = change it. Why do they change it, so that this option does not work? I think answering these questions in the draft will provide a better argume= nt for the session-id, assuming there is one. Regards, Daryl ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Hadriel Kaplan Sent: Tuesday, July 13, 2010 6:38 PM To: dispatch@ietf.org Subject: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Howdy, I submitted an updated version of the session-id draft, for consideration a= s a solution for the (hopefully) new WG for such purpose. The major changes are: 1) Reverted the generation of the session-id value to be a defined 128-b= it hash mechanism, as it was prior to version 1, based on feedback that hav= ing it be a known algorithm allows a monitoring system with the same privat= e key to generate the value itself for matching purposes. 2) Added a section on transfer handling, for REFER and INVITE-with-Repla= ces, such that a transferred call uses the same session-id. This section i= s just a beginning strawman and will need more thought. A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A Session Identifier for the Session Initiation Pro= tocol (SIP) Author(s) : H. Kaplan Filename : draft-kaplan-dispatch-session-id-02.txt Pages : 13 Date : 2010-07-12 There is a need for having a globally unique session identifier for the sam= e SIP session, which can be consistently maintained across Proxies, B2BUAs = and other SIP middle-boxes, for the purpose of Troubleshooting. This draft= proposes a new SIP header to carry such a value: Session-ID. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id-02.txt --_000_430FC6BDED356B4C8498F634416644A9269400226Amail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Daryl,

That’s because we’ve been debating this since 2008, and that topic was discussed back then. J<= /font>

The argument was that a B2BUA has to change the Call-ID, per RFC 3261 and it being a UAC.  I can’t remember the technical reason it had to – I thought it was for things like the dialog event-package, so when something subscribes to it on the B2= BUA the B2BUA will know which dialog is actually being referred to (there is at least a UAS and UAC dialog, and possibly multiple).  But some of us we= re talking about this last night and couldn’t figure out why just having unique From-tags wouldn’t be sufficient (other than rfc2543 devices, which we can ignore for this case). 

 

But anyway, when I first presented thi= s in 2008 and raised b2bua’s not changing the call-id, the feedback on the= mic was that rfc3261 mandated it and we shouldn’t be mucking with that.

 

-hadriel

 

From: Daryl Malas [mailto:D.Malas@cablelabs.com] Sent: Monday, July 26, 2010 = 4:54 AM
To: Hadriel Kaplan
Cc: dispatch@ietf.org
Subject: RE: Updated: draft-kaplan-dispatch-session-id-02

 

Hadriel,

 

I read through the draft, and I have a couple of questions.  First, let me say, I tried to read through all o= f the various questions and comments to see if my questions are duplicative, = but I may have missed something.  Please just point me to an applicable th= read if one already exists.  Also, I am fairly new in reading this issue, s= o bear with me if these questions seem rather naive.=

 

Questions:

 

1.  Does it make more sense to mo= dify or update call-id rather than define a new session-id?

2.  Does it make more sense to cr= eate a new session-id or tell middle devices not to mess with the call-id?

3.  The draft implies that call-i= d does not work, but it does not provide any good background as to all of tho= se reasons except that "middle" devices change it.  Why do they change it, so that this option does not work?

 

I think answering these questions in t= he draft will provide a better argument for the session-id, assuming there is = one.

 

Regards,


Daryl

 

From:= dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan
Sent: Tuesday, July 13, 2010= 6:38 PM
To: dispatch@ietf.org
Subject: [dispatch] Updated: draft-kaplan-dispatch-session-id-02

Howdy,

I submitted an updated version of the session-id draft, for consideration as a solution for the (hopefully) new WG for such purpose.

 

The major changes are:<= /p>

1)    <= font size=3D2 face=3D"Courier New">Reverted the generation of the session-id value to be a defined 128-bit hash mechani= sm, as it was prior to version 1, based on feedback that having it be a known algorithm allows a monitoring system with the same private key to generate = the value itself for matching purposes.

2)    <= font size=3D2 face=3D"Courier New">Added a section on transfer handling, for REFER and INVITE-with-Replaces, such th= at a transferred call uses the same session-id.  This section is just a beginning strawman and will need more thought.

 

 

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

 

      Title           : A Sessi= on Identifier for the Session Initiation Protocol (SIP)

      Author(s)       : H. Kaplan=

      Filename        : draft-kaplan-dispatch-session-id-02.txt

      Pages           : 13=

      Date            : 2010-07-12

 

There is a need for having a globally unique ses= sion identifier for the same SIP session, which can be consistently maintained across Proxies, B2BUAs and other SIP middle-boxes, for the purpose of Troubleshooting.  This draft proposes a new SIP header to carry such a value: Session-ID.

 

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session= -id-02.txt

 

 

--_000_430FC6BDED356B4C8498F634416644A9269400226Amail_-- From mary.ietf.barnes@gmail.com Mon Jul 26 03:32:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD2433A6BA1 for ; Mon, 26 Jul 2010 03:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1IGD0LTLv+2 for ; Mon, 26 Jul 2010 03:32:08 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 0EB333A6BA7 for ; Mon, 26 Jul 2010 03:28:02 -0700 (PDT) Received: by yxj4 with SMTP id 4so4412727yxj.31 for ; Mon, 26 Jul 2010 03:28:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=3kSi4kMP8lKRnTupvR7qWVb8/GfDnnVcaVUuu/c2VhA=; b=lYceOydNgfF5IVVzQW3a1D8QtEDcU50Ij/VpTB1r1A9503czmJMEyOrEqcMlc+3MbI mX/n+xc1nKKwGYJm+et8wP1pROPzKpXMMmgzvPB8wQTAgQGx3GqlN1tgS0gYlqjJMWDu oVWfFF6Z5L6WDJJEgAM8+jXFi2t0hJxe7DSz0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=HJseJRK5P6qFSTqBlmIUmdlb3GsRcstqKbMe7LftP3uM/Qh/QKzIMmN9xtoD0kntG0 mBJjHafrYwdBPRLk295ObBHTRP45m8I3SbAMCVTpv70W20v78dRQJf8Cfjt9UCS9gNHW rHqa0/6xpocME2bdcLloii5zXslZyP5Xv7mj0= MIME-Version: 1.0 Received: by 10.150.58.20 with SMTP id g20mr8243474yba.188.1280140103711; Mon, 26 Jul 2010 03:28:23 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Mon, 26 Jul 2010 03:28:23 -0700 (PDT) Date: Mon, 26 Jul 2010 05:28:23 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=000e0cd3484624fc47048c47d84d Cc: "Botzko, Stephen" , rai-ads@tools.ietf.org Subject: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 10:32:13 -0000 --000e0cd3484624fc47048c47d84d Content-Type: text/plain; charset=ISO-8859-1 Hi folks, Tuesday lunchtime was the most popular timeslot for this adhoc. I will post the room information as soon as it's available. The plan is that folks would grab some lunch and bring that to the meeting room, so we can hopefully get started around 11:45. Thanks, Mary. On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes wrote: > Hi, > > An adhoc for the telepresence work has been suggested for IETF-78. > > The agenda would be something like the following (depending, of > course, upon the discussion during the WG session): > > 1) Debrief - DISPATCH session (10 min) > > 2) Next Steps (45 minutes): > a) Additional use cases to consider (and volunteers to provide details) ? > b) Refining problem statement document > c) Starting requirements document > d) Architectural Framework document - is it time to start that? > > 3) Plans going forward - discuss regular calls, mailing list setup, > etc. (10 min) > > 4) AOB (discuss potential technical issues, etc.) as time allows (10 min) > > > Please respond to the doodle poll if you have an interest in and would > like to contribute to this proposed work item (i.e., willing to be > part of a design team): > http://www.doodle.com/h968u6tgehyt9ffg > > The links to charter proposal and related documents are in the > DISPATCH WG agenda: > http://www.ietf.org/proceedings/78/agenda/dispatch.html > > PLEASE respond by COB on Monday, July 19th, so that we can work on > getting a meeting room for the selected time. > > Thanks, > Mary > DISPATCH WG co-chair > --000e0cd3484624fc47048c47d84d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

Tuesday lunchtime was the most popular timeslo= t for this adhoc. I will post the room information as soon as it's avai= lable. The plan is that folks would grab some lunch and bring that to the m= eeting room, so we can hopefully get started around 11:45.

Thanks,
Mary.=A0

On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes <<= a href=3D"mailto:mary.ietf.barnes@gmail.com">mary.ietf.barnes@gmail.com= > wrote:
Hi,

An adhoc for the telepresence work has been suggested for IETF-78.

The agenda would be something like the following (depending, of
course, upon the discussion during the WG session):

1) Debrief - DISPATCH session (10 min)

2) =A0Next Steps (45 minutes):
a) Additional use cases to consider (and volunteers to provide details) ? b) Refining problem statement document
c) Starting requirements document
d) Architectural Framework document - is it time to start that?

3) Plans going forward - discuss regular calls, mailing list setup,
etc. (10 min)

4) AOB (discuss potential technical issues, etc.) as time allows (10 min)

Please respond to the doodle poll if you have an interest in and would
like to contribute to this proposed work item (i.e., willing to be
part of a design team):
http:/= /www.doodle.com/h968u6tgehyt9ffg

The links to charter proposal and related documents are in the
DISPATCH WG agenda:
http://www.ietf.org/proceedings/78/agenda/dispatch.html

PLEASE respond by COB on Monday, July 19th, so that we can work on
getting a meeting room for the selected time.

Thanks,
Mary
DISPATCH WG co-chair

--000e0cd3484624fc47048c47d84d-- From mary.ietf.barnes@gmail.com Mon Jul 26 06:04:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8973B3A6934 for ; Mon, 26 Jul 2010 06:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.303 X-Spam-Level: X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5 tests=[AWL=-0.924, BAYES_00=-2.599, HTML_MESSAGE=0.001, TVD_SPACE_RATIO=2.219] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWxVF7USD9fl for ; Mon, 26 Jul 2010 06:04:46 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id C743A3A6907 for ; Mon, 26 Jul 2010 06:04:46 -0700 (PDT) Received: by gxk1 with SMTP id 1so1005525gxk.31 for ; Mon, 26 Jul 2010 06:05:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=4AMBlsw5FQElM8en8OAjFGH7jzbHlAJjx796rwgoyNk=; b=lVOuLVVUHbfqI5EZPgKRxyRbzNG+blaUv50vb+m+rM9f0f4+NBVggfM+UrY3tyz9nq G7T9SYy20X/NGuTmxpnOtVhjEtIUd6OGtUu2NBQ49ZCjQUQR5QWFJkWrcD/Vgb1lfZ3j 1Weu2uBBfEU/7ZwM8gMpyPFBXdAy4TzT3cTcs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=waFKL3wkJYi2VmzEO7x0AjPGM51sOjP0g15M0kzxjb6ck/9yxDbb9v7hHZJOVph8vp SFk8940iPevVvTW3tnC/FNHtNnz8wu13ptb4QvZtUKr7y129DNzgXWL+RVvYKvmE4WTb 6sd7JPxta+A+G79bfCNlpTusdT2jopSZ1tgPw= MIME-Version: 1.0 Received: by 10.90.81.7 with SMTP id e7mr5371252agb.110.1280149507671; Mon, 26 Jul 2010 06:05:07 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Mon, 26 Jul 2010 06:05:07 -0700 (PDT) Date: Mon, 26 Jul 2010 08:05:07 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=00163613a404aa07f1048c4a08f6 Subject: [dispatch] test X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 13:04:47 -0000 --00163613a404aa07f1048c4a08f6 Content-Type: text/plain; charset=ISO-8859-1 --00163613a404aa07f1048c4a08f6 Content-Type: text/html; charset=ISO-8859-1
--00163613a404aa07f1048c4a08f6-- From HKaplan@acmepacket.com Mon Jul 26 06:05:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBB6E3A6922 for ; Mon, 26 Jul 2010 06:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.051 X-Spam-Level: X-Spam-Status: No, score=-0.051 tagged_above=-999 required=5 tests=[AWL=-2.432, BAYES_05=-1.11, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MISSING_SUBJECT=1.762, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPYcj+mw1j95 for ; Mon, 26 Jul 2010 06:05:27 -0700 (PDT) Received: from ETMail2.acmepacket.com (host9.216.41.24.conversent.net [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id 014273A6907 for ; Mon, 26 Jul 2010 06:05:27 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 26 Jul 2010 09:05:46 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 26 Jul 2010 09:05:46 -0400 From: Hadriel Kaplan To: "dispatch@ietf.org" Date: Mon, 26 Jul 2010 09:05:47 -0400 Thread-Index: Acssw0NfNxwhMhmwQICFsB81YXc6OA== Message-ID: <430FC6BDED356B4C8498F634416644A926940022AC@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] (no subject) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 13:05:28 -0000 Howdy, During the upcoming DISPATCH f2f meeting I will be asking for a WG to handl= e the session-id stuff, with the following charter. The charter has been s= ent before on this list, but I'm repeating the notice again in hopes folks = have a chance to review it before the DISPATCH meeting.=20 -hadriel SIP Signaling-COmmunication Troubleshooting with Correlation Header (SIPSCO= TCH) Charter: ---------------------------------- The SIPSCOTCH working group is chartered to define a mechanism that allows = operators and monitoring equipment to correlate SIP messages and dialogs of= the same higher-level end-to-end "session" across multiple SIP device hops= for the same "message-flow", for the purpose of troubleshooting. In parti= cular, the mechanism must be able to allow such correlation across SIP B2BU= As of as many functional types as possible, such as Application Servers, So= ftswitches, PBXs, SBCs, etc. The definition of a higher-layer "session" of the same "message-flow" is no= t defined by SIP when it involves a B2BUA, and is difficult to normatively = define in practice. For the purposes of this WG charter's scope, two or mo= re dialogs of a B2BUA are correlated under any conditions where correlation= might aid troubleshooting, by identifying them as belonging to the same hi= gher-level session. Any solution documents from this working group may exp= and or constrain the scope of their mechanism's correlation, if the working= group so decides. Although other solutions may be possible, this working group will focus on = defining a new SIP Header field for such a purpose, similar to the Call-ID = header field, in order to provide a simple, easily deployable mechanism whi= ch can work across SIP domains. The SIP Call-ID header field value itself i= s not usable for such correlation, because many B2BUAs must create a new Ca= ll-ID value on their UAC "side" in order to function properly, and to compl= y with the rules of RFC 3261.=20 It should be noted that certain SIP B2BUAs perform a "topology-hiding" func= tion, as described in RFC 5853. The working group will take such functions= into account for the correlation mechanism, as well as provide guidance fo= r implementers of the mechanism to avoid triggering such a function for the= mechanism's header field value. Lastly, although in certain environments such a mechanism may be usable for= dialog correlation in SIP state machines, it is not the goal of this worki= ng group to address that usage. Goals and Milestones =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dec 2010 - New header specification to IESG (PS) [Sorry for duplicates if any - tried sending this multiple times, this is t= he third try] From HKaplan@acmepacket.com Mon Jul 26 06:06:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314E33A69E1 for ; Mon, 26 Jul 2010 06:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.592 X-Spam-Level: X-Spam-Status: No, score=-1.592 tagged_above=-999 required=5 tests=[AWL=-0.722, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuKKfV39F0kM for ; Mon, 26 Jul 2010 06:06:58 -0700 (PDT) Received: from ETMail2.acmepacket.com (host9.216.41.24.conversent.net [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id F11243A6902 for ; Mon, 26 Jul 2010 06:06:57 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 26 Jul 2010 09:07:18 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 26 Jul 2010 09:07:18 -0400 From: Hadriel Kaplan To: "dispatch@ietf.org" Date: Mon, 26 Jul 2010 09:07:19 -0400 Thread-Topic: Final charter for Session-ID (resend) Thread-Index: Acssw0NfNxwhMhmwQICFsB81YXc6OAAACAbw Message-ID: <430FC6BDED356B4C8498F634416644A926940022AE@mail> References: <430FC6BDED356B4C8498F634416644A926940022AC@mail> In-Reply-To: <430FC6BDED356B4C8498F634416644A926940022AC@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] Final charter for Session-ID (resend) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 13:06:59 -0000 Sorry, forgot subject line. > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Hadriel Kaplan > Sent: Monday, July 26, 2010 9:06 AM > To: dispatch@ietf.org > Subject: [dispatch] (no subject) >=20 > Howdy, > During the upcoming DISPATCH f2f meeting I will be asking for a WG to > handle the session-id stuff, with the following charter. The charter has > been sent before on this list, but I'm repeating the notice again in hope= s > folks have a chance to review it before the DISPATCH meeting. >=20 > -hadriel >=20 >=20 > SIP Signaling-COmmunication Troubleshooting with Correlation Header > (SIPSCOTCH) Charter: > ---------------------------------- > The SIPSCOTCH working group is chartered to define a mechanism that allow= s > operators and monitoring equipment to correlate SIP messages and dialogs > of the same higher-level end-to-end "session" across multiple SIP device > hops for the same "message-flow", for the purpose of troubleshooting. In > particular, the mechanism must be able to allow such correlation across > SIP B2BUAs of as many functional types as possible, such as Application > Servers, Softswitches, PBXs, SBCs, etc. >=20 > The definition of a higher-layer "session" of the same "message-flow" is > not defined by SIP when it involves a B2BUA, and is difficult to > normatively define in practice. For the purposes of this WG charter's > scope, two or more dialogs of a B2BUA are correlated under any conditions > where correlation might aid troubleshooting, by identifying them as > belonging to the same higher-level session. Any solution documents from > this working group may expand or constrain the scope of their mechanism's > correlation, if the working group so decides. >=20 > Although other solutions may be possible, this working group will focus o= n > defining a new SIP Header field for such a purpose, similar to the Call-I= D > header field, in order to provide a simple, easily deployable mechanism > which can work across SIP domains. The SIP Call-ID header field value > itself is not usable for such correlation, because many B2BUAs must creat= e > a new Call-ID value on their UAC "side" in order to function properly, an= d > to comply with the rules of RFC 3261. >=20 > It should be noted that certain SIP B2BUAs perform a "topology-hiding" > function, as described in RFC 5853. The working group will take such > functions into account for the correlation mechanism, as well as provide > guidance for implementers of the mechanism to avoid triggering such a > function for the mechanism's header field value. >=20 > Lastly, although in certain environments such a mechanism may be usable > for dialog correlation in SIP state machines, it is not the goal of this > working group to address that usage. >=20 > Goals and Milestones > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Dec 2010 - New header specification to IESG (PS) >=20 >=20 >=20 > [Sorry for duplicates if any - tried sending this multiple times, this is > the third try] >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From tme@americafree.tv Mon Jul 26 06:58:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC0FA3A6946 for ; Mon, 26 Jul 2010 06:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.502 X-Spam-Level: X-Spam-Status: No, score=-102.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lEv0NBEwe5Ij for ; Mon, 26 Jul 2010 06:58:12 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 9C3663A691D for ; Mon, 26 Jul 2010 06:58:12 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 1288381B96E5; Mon, 26 Jul 2010 09:58:32 -0400 (EDT) Message-Id: <8F615C49-E8C0-44F3-9B13-1D338C7A913C@americafree.tv> From: Marshall Eubanks To: Mary Barnes In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 09:58:31 -0400 References: X-Mailer: Apple Mail (2.936) Cc: rai-ads@tools.ietf.org, DISPATCH , "Botzko, Stephen" Subject: Re: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 13:58:14 -0000 Don't forget to post it here - http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 or send an email to Lars Marshall On Jul 26, 2010, at 6:28 AM, Mary Barnes wrote: > Hi folks, > > Tuesday lunchtime was the most popular timeslot for this adhoc. I > will post the room information as soon as it's available. The plan > is that folks would grab some lunch and bring that to the meeting > room, so we can hopefully get started around 11:45. > > Thanks, > Mary. > > On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes > wrote: > Hi, > > An adhoc for the telepresence work has been suggested for IETF-78. > > The agenda would be something like the following (depending, of > course, upon the discussion during the WG session): > > 1) Debrief - DISPATCH session (10 min) > > 2) Next Steps (45 minutes): > a) Additional use cases to consider (and volunteers to provide > details) ? > b) Refining problem statement document > c) Starting requirements document > d) Architectural Framework document - is it time to start that? > > 3) Plans going forward - discuss regular calls, mailing list setup, > etc. (10 min) > > 4) AOB (discuss potential technical issues, etc.) as time allows (10 > min) > > > Please respond to the doodle poll if you have an interest in and would > like to contribute to this proposed work item (i.e., willing to be > part of a design team): > http://www.doodle.com/h968u6tgehyt9ffg > > The links to charter proposal and related documents are in the > DISPATCH WG agenda: > http://www.ietf.org/proceedings/78/agenda/dispatch.html > > PLEASE respond by COB on Monday, July 19th, so that we can work on > getting a meeting room for the selected time. > > Thanks, > Mary > DISPATCH WG co-chair > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From gcamaril@gmail.com Mon Jul 26 06:59:30 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 668753A6C19 for ; Mon, 26 Jul 2010 06:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0nu9NfY94oX for ; Mon, 26 Jul 2010 06:59:25 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E26EC3A6946 for ; Mon, 26 Jul 2010 06:59:24 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-1a-4c4d94d1dc42 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 12.90.06895.1D49D4C4; Mon, 26 Jul 2010 15:59:45 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 15:59:45 +0200 Received: from [131.160.126.137] ([131.160.126.137]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 15:59:44 +0200 Message-ID: <4C4D94D0.9030006@gmail.com> Date: Mon, 26 Jul 2010 15:59:44 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Marshall Eubanks References: <8F615C49-E8C0-44F3-9B13-1D338C7A913C@americafree.tv> In-Reply-To: <8F615C49-E8C0-44F3-9B13-1D338C7A913C@americafree.tv> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2010 13:59:44.0806 (UTC) FILETIME=[CD35C460:01CB2CCA] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH , "Botzko, Stephen" , "rai-ads@tools.ietf.org" Subject: Re: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 13:59:30 -0000 Hi, yes, I sent an email to RAI before. Make sure you upload your bar bofs to that wiki. Cheers, Gonzalo On 26/07/2010 3:58 PM, Marshall Eubanks wrote: > Don't forget to post it here - > > http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 > > or send an email to Lars > > Marshall > > On Jul 26, 2010, at 6:28 AM, Mary Barnes wrote: > >> Hi folks, >> >> Tuesday lunchtime was the most popular timeslot for this adhoc. I >> will post the room information as soon as it's available. The plan >> is that folks would grab some lunch and bring that to the meeting >> room, so we can hopefully get started around 11:45. >> >> Thanks, >> Mary. >> >> On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes >> wrote: >> Hi, >> >> An adhoc for the telepresence work has been suggested for IETF-78. >> >> The agenda would be something like the following (depending, of >> course, upon the discussion during the WG session): >> >> 1) Debrief - DISPATCH session (10 min) >> >> 2) Next Steps (45 minutes): >> a) Additional use cases to consider (and volunteers to provide >> details) ? >> b) Refining problem statement document >> c) Starting requirements document >> d) Architectural Framework document - is it time to start that? >> >> 3) Plans going forward - discuss regular calls, mailing list setup, >> etc. (10 min) >> >> 4) AOB (discuss potential technical issues, etc.) as time allows (10 >> min) >> >> >> Please respond to the doodle poll if you have an interest in and would >> like to contribute to this proposed work item (i.e., willing to be >> part of a design team): >> http://www.doodle.com/h968u6tgehyt9ffg >> >> The links to charter proposal and related documents are in the >> DISPATCH WG agenda: >> http://www.ietf.org/proceedings/78/agenda/dispatch.html >> >> PLEASE respond by COB on Monday, July 19th, so that we can work on >> getting a meeting room for the selected time. >> >> Thanks, >> Mary >> DISPATCH WG co-chair >> >> _______________________________________________ >> 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 Mon Jul 26 07:01:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F5D13A691D for ; Mon, 26 Jul 2010 07:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50f8r+dgo0R0 for ; Mon, 26 Jul 2010 07:01:25 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 9BF5D3A69F8 for ; Mon, 26 Jul 2010 07:01:25 -0700 (PDT) Received: by pxi20 with SMTP id 20so60548pxi.31 for ; Mon, 26 Jul 2010 07:01:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=rpbJ3GmIz9UwYS1mBsbgLHTBwcrlbmh6dr3Bubn4wp0=; b=NvGoZNqHF1N0DBcNYVjV4JkYhKhP7WWej4sHvBGezVU3SNWRKTlQog7xDkSSqK/ErS 129XYmP5j7KGzmM1vjZziugRsS+Tt3LX5O0Lf87rsilTv9pKd1cjBNHKqWPwno4T8an8 Lo6eAxgByHDHeNYXcqc9TLE5SubfQ1Xclk+FA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=P4mmLJmZ8oivcuxd112c8i0frITMRzUTB/Kf9VVmr8OPSW7mhxVAQb7fJ5H1RAqzbv U2Ixl5Ydu8eOXgi5EZOxCFQp0td4VYe5r6Jk10Jvhhvtqvf2yWWw34MOZtpMKz/n961g lHrOcTTfih4sj2dSl07SpX8LT1fcgZAUpiU0g= MIME-Version: 1.0 Received: by 10.114.132.18 with SMTP id f18mr11575165wad.97.1280152903888; Mon, 26 Jul 2010 07:01:43 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Mon, 26 Jul 2010 07:01:43 -0700 (PDT) In-Reply-To: <4C4D94D0.9030006@gmail.com> References: <8F615C49-E8C0-44F3-9B13-1D338C7A913C@americafree.tv> <4C4D94D0.9030006@gmail.com> Date: Mon, 26 Jul 2010 09:01:43 -0500 Message-ID: From: Mary Barnes To: Gonzalo Camarillo Content-Type: multipart/alternative; boundary=0016e64cbe1818303f048c4ad307 Cc: "Botzko, Stephen" , DISPATCH , "rai-ads@tools.ietf.org" Subject: Re: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:01:27 -0000 --0016e64cbe1818303f048c4ad307 Content-Type: text/plain; charset=ISO-8859-1 This isn't a bar bof. It's an "official" DISPATCH WG adhoc, so I don't personally think it needs to be put on the bar bof list. Mary. On Mon, Jul 26, 2010 at 8:59 AM, Gonzalo Camarillo wrote: > Hi, > > yes, I sent an email to RAI before. Make sure you upload your bar bofs > to that wiki. > > Cheers, > > Gonzalo > > On 26/07/2010 3:58 PM, Marshall Eubanks wrote: > > Don't forget to post it here - > > > > http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 > > > > or send an email to Lars > > > > Marshall > > > > On Jul 26, 2010, at 6:28 AM, Mary Barnes wrote: > > > >> Hi folks, > >> > >> Tuesday lunchtime was the most popular timeslot for this adhoc. I > >> will post the room information as soon as it's available. The plan > >> is that folks would grab some lunch and bring that to the meeting > >> room, so we can hopefully get started around 11:45. > >> > >> Thanks, > >> Mary. > >> > >> On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes < > mary.ietf.barnes@gmail.com > >>> wrote: > >> Hi, > >> > >> An adhoc for the telepresence work has been suggested for IETF-78. > >> > >> The agenda would be something like the following (depending, of > >> course, upon the discussion during the WG session): > >> > >> 1) Debrief - DISPATCH session (10 min) > >> > >> 2) Next Steps (45 minutes): > >> a) Additional use cases to consider (and volunteers to provide > >> details) ? > >> b) Refining problem statement document > >> c) Starting requirements document > >> d) Architectural Framework document - is it time to start that? > >> > >> 3) Plans going forward - discuss regular calls, mailing list setup, > >> etc. (10 min) > >> > >> 4) AOB (discuss potential technical issues, etc.) as time allows (10 > >> min) > >> > >> > >> Please respond to the doodle poll if you have an interest in and would > >> like to contribute to this proposed work item (i.e., willing to be > >> part of a design team): > >> http://www.doodle.com/h968u6tgehyt9ffg > >> > >> The links to charter proposal and related documents are in the > >> DISPATCH WG agenda: > >> http://www.ietf.org/proceedings/78/agenda/dispatch.html > >> > >> PLEASE respond by COB on Monday, July 19th, so that we can work on > >> getting a meeting room for the selected time. > >> > >> Thanks, > >> Mary > >> DISPATCH WG co-chair > >> > >> _______________________________________________ > >> 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 > --0016e64cbe1818303f048c4ad307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This isn't a bar bof. It's an "official" DISPATCH WG adho= c, so I don't personally think it needs to be put on the bar bof list.<= div>
Mary.=A0

On Mon, Jul 2= 6, 2010 at 8:59 AM, Gonzalo Camarillo <gcamaril@gmail.com> wrote:
Hi,

yes, I sent an email to RAI before. Make sure you upload your bar bofs
to that wiki.

Cheers,

Gonzalo

On 26/07/2010 3:58 PM, Marshall Eubanks wrote:
> Don't forget to post it here -
>
> http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 >
> or send an email to Lars
>
> Marshall
>
> On Jul 26, 2010, at 6:28 AM, Mary Barnes wrote:
>
>> Hi folks,
>>
>> Tuesday lunchtime was the most popular timeslot for this adhoc. I<= br> >> will post the room information as soon as it's available. The = plan
>> is that folks would grab some lunch and bring that to the meeting<= br> >> room, so we can hopefully get started around 11:45.
>>
>> Thanks,
>> Mary.
>>
>> On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes <mary.ietf.barnes@gmail.com
>>> wrote:
>> Hi,
>>
>> An adhoc for the telepresence work has been suggested for IETF-78.=
>>
>> The agenda would be something like the following (depending, of >> course, upon the discussion during the WG session):
>>
>> 1) Debrief - DISPATCH session (10 min)
>>
>> 2) =A0Next Steps (45 minutes):
>> a) Additional use cases to consider (and volunteers to provide
>> details) ?
>> b) Refining problem statement document
>> c) Starting requirements document
>> d) Architectural Framework document - is it time to start that? >>
>> 3) Plans going forward - discuss regular calls, mailing list setup= ,
>> etc. (10 min)
>>
>> 4) AOB (discuss potential technical issues, etc.) as time allows (= 10
>> min)
>>
>>
>> Please respond to the doodle poll if you have an interest in and w= ould
>> like to contribute to this proposed work item (i.e., willing to be=
>> part of a design team):
>> http://www.doodle.com/h968u6tgehyt9ffg
>>
>> The links to charter proposal and related documents are in the
>> DISPATCH WG agenda:
>> http://www.ietf.org/proceedings/78/agenda/dispatch.html=
>>
>> PLEASE respond by COB on Monday, July 19th, so that we can work on=
>> getting a meeting room for the selected time.
>>
>> Thanks,
>> Mary
>> DISPATCH WG co-chair
>>
>> _______________________________________________
>> 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

--0016e64cbe1818303f048c4ad307-- From tme@americafree.tv Mon Jul 26 07:02:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D1A33A6901 for ; Mon, 26 Jul 2010 07:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxgJwdu8LRF4 for ; Mon, 26 Jul 2010 07:02:10 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id CD1203A6862 for ; Mon, 26 Jul 2010 07:02:09 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 4478A81B9919; Mon, 26 Jul 2010 10:02:30 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Mary Barnes In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 10:02:29 -0400 References: <8F615C49-E8C0-44F3-9B13-1D338C7A913C@americafree.tv> <4C4D94D0.9030006@gmail.com> X-Mailer: Apple Mail (2.936) Cc: "Botzko, Stephen" , DISPATCH , "rai-ads@tools.ietf.org" , Gonzalo Camarillo Subject: Re: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:02:16 -0000 Ah, thanks for the clarification. That means that the NOTE WELL will apply, and we need a scribe. Regards Marshall On Jul 26, 2010, at 10:01 AM, Mary Barnes wrote: > This isn't a bar bof. It's an "official" DISPATCH WG adhoc, so I > don't personally think it needs to be put on the bar bof list. > > Mary. > > On Mon, Jul 26, 2010 at 8:59 AM, Gonzalo Camarillo > wrote: > Hi, > > yes, I sent an email to RAI before. Make sure you upload your bar bofs > to that wiki. > > Cheers, > > Gonzalo > > On 26/07/2010 3:58 PM, Marshall Eubanks wrote: > > Don't forget to post it here - > > > > http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 > > > > or send an email to Lars > > > > Marshall > > > > On Jul 26, 2010, at 6:28 AM, Mary Barnes wrote: > > > >> Hi folks, > >> > >> Tuesday lunchtime was the most popular timeslot for this adhoc. I > >> will post the room information as soon as it's available. The plan > >> is that folks would grab some lunch and bring that to the meeting > >> room, so we can hopefully get started around 11:45. > >> > >> Thanks, > >> Mary. > >> > >> On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes >>> wrote: > >> Hi, > >> > >> An adhoc for the telepresence work has been suggested for IETF-78. > >> > >> The agenda would be something like the following (depending, of > >> course, upon the discussion during the WG session): > >> > >> 1) Debrief - DISPATCH session (10 min) > >> > >> 2) Next Steps (45 minutes): > >> a) Additional use cases to consider (and volunteers to provide > >> details) ? > >> b) Refining problem statement document > >> c) Starting requirements document > >> d) Architectural Framework document - is it time to start that? > >> > >> 3) Plans going forward - discuss regular calls, mailing list setup, > >> etc. (10 min) > >> > >> 4) AOB (discuss potential technical issues, etc.) as time allows > (10 > >> min) > >> > >> > >> Please respond to the doodle poll if you have an interest in and > would > >> like to contribute to this proposed work item (i.e., willing to be > >> part of a design team): > >> http://www.doodle.com/h968u6tgehyt9ffg > >> > >> The links to charter proposal and related documents are in the > >> DISPATCH WG agenda: > >> http://www.ietf.org/proceedings/78/agenda/dispatch.html > >> > >> PLEASE respond by COB on Monday, July 19th, so that we can work on > >> getting a meeting room for the selected time. > >> > >> Thanks, > >> Mary > >> DISPATCH WG co-chair > >> > >> _______________________________________________ > >> 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 venkatev@cisco.com Mon Jul 26 07:11:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 276A83A6BCD for ; Mon, 26 Jul 2010 07:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPXMGAe+D0jo for ; Mon, 26 Jul 2010 07:11:03 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 947DF3A6982 for ; Mon, 26 Jul 2010 07:11:03 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMs0TUyrR7Ht/2dsb2JhbACfZHGnZJo7hTYEhAiEXII6 X-IronPort-AV: E=Sophos;i="4.55,261,1278288000"; d="scan'208";a="230752147" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 26 Jul 2010 14:11:14 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6QEBEgv010875; Mon, 26 Jul 2010 14:11:14 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Jul 2010 07:11:14 -0700 Received: from 10.21.80.45 ([10.21.80.45]) by xmb-sjc-236.amer.cisco.com ([128.107.191.121]) with Microsoft Exchange Server HTTP-DAV ; Mon, 26 Jul 2010 14:11:14 +0000 User-Agent: Microsoft-Entourage/12.25.0.100505 Date: Mon, 26 Jul 2010 07:13:26 -0700 From: Venkatesh Venkataramanan To: Marshall Eubanks , Mary Barnes Message-ID: Thread-Topic: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 Thread-Index: AcsszLau0rR/gaYL/EqH4DvheM4wuA== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 26 Jul 2010 14:11:14.0597 (UTC) FILETIME=[685B8550:01CB2CCC] Cc: "rai-ads@tools.ietf.org" , DISPATCH , "Botzko, Stephen" , Gonzalo Camarillo Subject: Re: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:11:06 -0000 Marshall: I think the Telepresence adhoc Mary is talking about is the one related to multi-stream work that just got kicked off a few months ago. It is not the same as the Bar Bof that is related to setting up ENUM for Telepresence routing. Venkatesh On 7/26/10 7:02 AM, "Marshall Eubanks" wrote: > Ah, thanks for the clarification. That means that the NOTE WELL will > apply, and we need a scribe. > > Regards > Marshall > > On Jul 26, 2010, at 10:01 AM, Mary Barnes wrote: > >> This isn't a bar bof. It's an "official" DISPATCH WG adhoc, so I >> don't personally think it needs to be put on the bar bof list. >> >> Mary. >> >> On Mon, Jul 26, 2010 at 8:59 AM, Gonzalo Camarillo >> wrote: >> Hi, >> >> yes, I sent an email to RAI before. Make sure you upload your bar bofs >> to that wiki. >> >> Cheers, >> >> Gonzalo >> >> On 26/07/2010 3:58 PM, Marshall Eubanks wrote: >>> Don't forget to post it here - >>> >>> http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 >>> >>> or send an email to Lars >>> >>> Marshall >>> >>> On Jul 26, 2010, at 6:28 AM, Mary Barnes wrote: >>> >>>> Hi folks, >>>> >>>> Tuesday lunchtime was the most popular timeslot for this adhoc. I >>>> will post the room information as soon as it's available. The plan >>>> is that folks would grab some lunch and bring that to the meeting >>>> room, so we can hopefully get started around 11:45. >>>> >>>> Thanks, >>>> Mary. >>>> >>>> On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes >>>> wrote: >>>> Hi, >>>> >>>> An adhoc for the telepresence work has been suggested for IETF-78. >>>> >>>> The agenda would be something like the following (depending, of >>>> course, upon the discussion during the WG session): >>>> >>>> 1) Debrief - DISPATCH session (10 min) >>>> >>>> 2) Next Steps (45 minutes): >>>> a) Additional use cases to consider (and volunteers to provide >>>> details) ? >>>> b) Refining problem statement document >>>> c) Starting requirements document >>>> d) Architectural Framework document - is it time to start that? >>>> >>>> 3) Plans going forward - discuss regular calls, mailing list setup, >>>> etc. (10 min) >>>> >>>> 4) AOB (discuss potential technical issues, etc.) as time allows >> (10 >>>> min) >>>> >>>> >>>> Please respond to the doodle poll if you have an interest in and >> would >>>> like to contribute to this proposed work item (i.e., willing to be >>>> part of a design team): >>>> http://www.doodle.com/h968u6tgehyt9ffg >>>> >>>> The links to charter proposal and related documents are in the >>>> DISPATCH WG agenda: >>>> http://www.ietf.org/proceedings/78/agenda/dispatch.html >>>> >>>> PLEASE respond by COB on Monday, July 19th, so that we can work on >>>> getting a meeting room for the selected time. >>>> >>>> Thanks, >>>> Mary >>>> DISPATCH WG co-chair >>>> >>>> _______________________________________________ >>>> 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 hasnaa.moustafa@gmail.com Mon Jul 26 07:14:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81E1E3A6A06 for ; Mon, 26 Jul 2010 07:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emdFiR2a1wAK for ; Mon, 26 Jul 2010 07:14:32 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 286793A6908 for ; Mon, 26 Jul 2010 07:14:31 -0700 (PDT) Received: by wwf26 with SMTP id 26so2821101wwf.1 for ; Mon, 26 Jul 2010 07:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=LiFwTxcgv07x2tTLDCAbIRQMxeHTqP/tr+5b8HNN9qI=; b=gPGaHhatnTH/rFsMHc3KwnxocKEYGA1z+r1VBKeFPzBw/KLtnEP5PNkuGNsb8166Z7 Nc8IM3YQaMIWcSu3qKtyNqBNj813MmMjCUrHOOeZpg5WaFG6meF4WNXhiTH+4Wql9eQ8 0MwKBansnbMmof0u/Da11n1aLurO4HrMksN90= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=LBb/r7PUXtQJcftlUunLD5oF7Y5Atu88rzs5MdfdhRDfqv1Tr4ve7hSMX4uyN/88Te 9V0i4AZcWpELt/mpW1V2M6eLAZpLwXZ/jWQ9s/83sctAnfYnbWXeWpil+//9mb+rJ2Ap g4Rlj7T6oiFO1+/I+bSYqAn4nrIhQL7xGYq+s= MIME-Version: 1.0 Received: by 10.227.141.84 with SMTP id l20mr7423444wbu.119.1280153687421; Mon, 26 Jul 2010 07:14:47 -0700 (PDT) Received: by 10.216.230.32 with HTTP; Mon, 26 Jul 2010 07:14:47 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Jul 2010 16:14:47 +0200 Message-ID: From: Hasnaa Moustafa To: dispatch@ietf.org Content-Type: multipart/alternative; boundary=0016e65b5820cbf2a1048c4b018b Subject: Re: [dispatch] dispatch Digest, Vol 16, Issue 83 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:14:37 -0000 --0016e65b5820cbf2a1048c4b018b Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > It is understood from this message that the ad hoc meeting is on Tuesday, however the agenda shows that there is an adhoc meeting on Thursday (Thursday was not proposed in the doodle pool!). Please confirm ASAP the exact slot (to be able to plan our other meetings). Kind regards, Hassnaa > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 26 Jul 2010 05:28:23 -0500 > From: Mary Barnes > Subject: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 > To: DISPATCH > Cc: "Botzko, Stephen" , > rai-ads@tools.ietf.org > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Hi folks, > > Tuesday lunchtime was the most popular timeslot for this adhoc. I will post > the room information as soon as it's available. The plan is that folks > would > grab some lunch and bring that to the meeting room, so we can hopefully get > started around 11:45. > > Thanks, > Mary. > > On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes >wrote: > > > Hi, > > > > An adhoc for the telepresence work has been suggested for IETF-78. > > > > The agenda would be something like the following (depending, of > > course, upon the discussion during the WG session): > > > > 1) Debrief - DISPATCH session (10 min) > > > > 2) Next Steps (45 minutes): > > a) Additional use cases to consider (and volunteers to provide details) ? > > b) Refining problem statement document > > c) Starting requirements document > > d) Architectural Framework document - is it time to start that? > > > > 3) Plans going forward - discuss regular calls, mailing list setup, > > etc. (10 min) > > > > 4) AOB (discuss potential technical issues, etc.) as time allows (10 min) > > > > > > Please respond to the doodle poll if you have an interest in and would > > like to contribute to this proposed work item (i.e., willing to be > > part of a design team): > > http://www.doodle.com/h968u6tgehyt9ffg > > > > The links to charter proposal and related documents are in the > > DISPATCH WG agenda: > > http://www.ietf.org/proceedings/78/agenda/dispatch.html > > > > PLEASE respond by COB on Monday, July 19th, so that we can work on > > getting a meeting room for the selected time. > > > > Thanks, > > Mary > > DISPATCH WG co-chair > > > -------------- next part -------------- > --0016e65b5820cbf2a1048c4b018b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
It is=A0understood from this message that the ad hoc meeting is on Tue= sday, however the agenda shows that there is an adhoc meeting on Thursday (= Thursday was not proposed in the doodle pool!).
=A0
Please confirm ASAP the exact slot (to be able to plan our other meeti= ngs).
=A0
Kind regards,
Hassnaa
=A0

----------------------------= ------------------------------------------

Message: 1
Date: Mon, = 26 Jul 2010 05:28:23 -0500
From: Mary Barnes <mary.ie= tf.barnes@gmail.com>
Subject: [dispatch] Telepresence adhoc - Tue= sday, July 27, 2010
To: DISPATCH <dispatch@ietf.org>
Cc: "Botzko, Stephen" <Stephen.Botzko@polycom.com>,
=A0 =A0 =A0 =A0rai-ads@tools.ietf.org
Message-ID:
= =A0 =A0 =A0 =A0<AANLkTinSL=3DXYAiPMgbvSTeh-YaM=3D_QXwTM3DU4Vp5v3Z@mail.gmail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

Hi folks,=

Tuesday lunchtime was the most popular timeslot for this adhoc. I w= ill post
the room information as soon as it's available. The plan is= that folks would
grab some lunch and bring that to the meeting room, so we can hopefully get=
started around 11:45.

Thanks,
Mary.

On Fri, Jul 16, 20= 10 at 12:10 PM, Mary Barnes <mary.ietf.barnes@gmail.com>wrote:

> Hi,
>
> An adhoc for the telepresence work has been su= ggested for IETF-78.
>
> The agenda would be something like the= following (depending, of
> course, upon the discussion during the WG= session):
>
> 1) Debrief - DISPATCH session (10 min)
>
> 2) =A0N= ext Steps (45 minutes):
> a) Additional use cases to consider (and vo= lunteers to provide details) ?
> b) Refining problem statement docume= nt
> c) Starting requirements document
> d) Architectural Framework d= ocument - is it time to start that?
>
> 3) Plans going forward = - discuss regular calls, mailing list setup,
> etc. (10 min)
><= br> > 4) AOB (discuss potential technical issues, etc.) as time allows (10 m= in)
>
>
> Please respond to the doodle poll if you have a= n interest in and would
> like to contribute to this proposed work it= em (i.e., willing to be
> part of a design team):
> http://www.doodle.com/h968u6tgehyt9ffg>
> The links to charter proposal and related documents are in t= he
> DISPATCH WG agenda:
> http://www.ietf.org/proceedings= /78/agenda/dispatch.html
>
> PLEASE respond by COB on Monda= y, July 19th, so that we can work on
> getting a meeting room for the selected time.
>
> Thanks,<= br>> Mary
> DISPATCH WG co-chair
>
-------------- next pa= rt --------------
--0016e65b5820cbf2a1048c4b018b-- From mary.ietf.barnes@gmail.com Mon Jul 26 07:15:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02ECC3A6981 for ; Mon, 26 Jul 2010 07:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9C2dV76Gqq9a for ; Mon, 26 Jul 2010 07:15:49 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 81BFB3A6BB4 for ; Mon, 26 Jul 2010 07:15:47 -0700 (PDT) Received: by pxi20 with SMTP id 20so68677pxi.31 for ; Mon, 26 Jul 2010 07:16:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mw+weNnn9kaDYhtr3b+3T/QJZ8cjkwK4nYGJouJk+SE=; b=h4fbdnc7KXr4ZiYj6ESUA5omxTNnKdjU4hFGjeDhLjV2P2pjcumv2MxcuIINzvJZB7 waSq0XfsSJxsaYV/3RtZsn5tQsg2ErtbrbzAciYxOvtbEKamy3+1pKJTJMeezlVvtSZs Bix/4XiAifyxKmRhJZcPFNijofkhcNeHj4k4M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dpU0HxTCG++HQTGlrKRtXf4gihI5sC4CNGFDc5ybcJ020uhC6PZwUKxJv+OQeMOxCN 7kC7DnN5dNfgLTvK25YeoHPV97BL9Nu7rY/fGd/G250E6rU+MDw7G5tGDjHx0VT4Sibf AQatG1l9b4XNHMg3IYo1HSWrTAweF+PSgAg10= MIME-Version: 1.0 Received: by 10.142.229.13 with SMTP id b13mr9035349wfh.61.1280153768573; Mon, 26 Jul 2010 07:16:08 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Mon, 26 Jul 2010 07:16:08 -0700 (PDT) In-Reply-To: References: <8F615C49-E8C0-44F3-9B13-1D338C7A913C@americafree.tv> <4C4D94D0.9030006@gmail.com> Date: Mon, 26 Jul 2010 09:16:08 -0500 Message-ID: From: Mary Barnes To: Marshall Eubanks Content-Type: multipart/alternative; boundary=000e0cd32b5ca23d0b048c4b0611 Cc: "Botzko, Stephen" , DISPATCH , "rai-ads@tools.ietf.org" , Gonzalo Camarillo Subject: Re: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:15:51 -0000 --000e0cd32b5ca23d0b048c4b0611 Content-Type: text/plain; charset=ISO-8859-1 Yes. Thanks, Mary. On Mon, Jul 26, 2010 at 9:02 AM, Marshall Eubanks wrote: > Ah, thanks for the clarification. That means that the NOTE WELL will apply, > and we need a scribe. > > Regards > Marshall > > > On Jul 26, 2010, at 10:01 AM, Mary Barnes wrote: > > This isn't a bar bof. It's an "official" DISPATCH WG adhoc, so I don't >> personally think it needs to be put on the bar bof list. >> >> Mary. >> >> On Mon, Jul 26, 2010 at 8:59 AM, Gonzalo Camarillo >> wrote: >> Hi, >> >> yes, I sent an email to RAI before. Make sure you upload your bar bofs >> to that wiki. >> >> Cheers, >> >> Gonzalo >> >> On 26/07/2010 3:58 PM, Marshall Eubanks wrote: >> > Don't forget to post it here - >> > >> > http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 >> > >> > or send an email to Lars >> > >> > Marshall >> > >> > On Jul 26, 2010, at 6:28 AM, Mary Barnes wrote: >> > >> >> Hi folks, >> >> >> >> Tuesday lunchtime was the most popular timeslot for this adhoc. I >> >> will post the room information as soon as it's available. The plan >> >> is that folks would grab some lunch and bring that to the meeting >> >> room, so we can hopefully get started around 11:45. >> >> >> >> Thanks, >> >> Mary. >> >> >> >> On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes < >> mary.ietf.barnes@gmail.com >> >>> wrote: >> >> Hi, >> >> >> >> An adhoc for the telepresence work has been suggested for IETF-78. >> >> >> >> The agenda would be something like the following (depending, of >> >> course, upon the discussion during the WG session): >> >> >> >> 1) Debrief - DISPATCH session (10 min) >> >> >> >> 2) Next Steps (45 minutes): >> >> a) Additional use cases to consider (and volunteers to provide >> >> details) ? >> >> b) Refining problem statement document >> >> c) Starting requirements document >> >> d) Architectural Framework document - is it time to start that? >> >> >> >> 3) Plans going forward - discuss regular calls, mailing list setup, >> >> etc. (10 min) >> >> >> >> 4) AOB (discuss potential technical issues, etc.) as time allows (10 >> >> min) >> >> >> >> >> >> Please respond to the doodle poll if you have an interest in and would >> >> like to contribute to this proposed work item (i.e., willing to be >> >> part of a design team): >> >> http://www.doodle.com/h968u6tgehyt9ffg >> >> >> >> The links to charter proposal and related documents are in the >> >> DISPATCH WG agenda: >> >> http://www.ietf.org/proceedings/78/agenda/dispatch.html >> >> >> >> PLEASE respond by COB on Monday, July 19th, so that we can work on >> >> getting a meeting room for the selected time. >> >> >> >> Thanks, >> >> Mary >> >> DISPATCH WG co-chair >> >> >> >> _______________________________________________ >> >> 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 >> >> > --000e0cd32b5ca23d0b048c4b0611 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes.

Thanks,
Mary.

On Mon, Jul 26, 2010 at 9:02 AM, Marshall Eubanks = <tme@americafree.tv>= wrote:
Ah, thanks for the clarification. That mean= s that the NOTE WELL will apply, and we need a scribe.

Regards
Marshall


On Jul 26, 2010, at 10:01 AM, Mary Barnes wrote:

This isn't a bar bof. It's an "official" DISPATCH WG adho= c, so I don't personally think it needs to be put on the bar bof list.<= br>
Mary.

On Mon, Jul 26, 2010 at 8:59 AM, Gonzalo Camarillo <gcamaril@gmail.com> wrote:
Hi,

yes, I sent an email to RAI before. Make sure you upload your bar bofs
to that wiki.

Cheers,

Gonzalo

On 26/07/2010 3:58 PM, Marshall Eubanks wrote:
> Don't forget to post it here -
>
> http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 >
> or send an email to Lars
>
> Marshall
>
> On Jul 26, 2010, at 6:28 AM, Mary Barnes wrote:
>
>> Hi folks,
>>
>> Tuesday lunchtime was the most popular timeslot for this adhoc. I<= br> >> will post the room information as soon as it's available. The = plan
>> is that folks would grab some lunch and bring that to the meeting<= br> >> room, so we can hopefully get started around 11:45.
>>
>> Thanks,
>> Mary.
>>
>> On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes <mary.ietf.barnes@gmail.com<= /a>
>>> wrote:
>> Hi,
>>
>> An adhoc for the telepresence work has been suggested for IETF-78.=
>>
>> The agenda would be something like the following (depending, of >> course, upon the discussion during the WG session):
>>
>> 1) Debrief - DISPATCH session (10 min)
>>
>> 2) =A0Next Steps (45 minutes):
>> a) Additional use cases to consider (and volunteers to provide
>> details) ?
>> b) Refining problem statement document
>> c) Starting requirements document
>> d) Architectural Framework document - is it time to start that? >>
>> 3) Plans going forward - discuss regular calls, mailing list setup= ,
>> etc. (10 min)
>>
>> 4) AOB (discuss potential technical issues, etc.) as time allows (= 10
>> min)
>>
>>
>> Please respond to the doodle poll if you have an interest in and w= ould
>> like to contribute to this proposed work item (i.e., willing to be=
>> part of a design team):
>> http://www.doodle.com/h968u6tgehyt9ffg
>>
>> The links to charter proposal and related documents are in the
>> DISPATCH WG agenda:
>> http://www.ietf.org/proceedings/78/agenda/dispatch.html=
>>
>> PLEASE respond by COB on Monday, July 19th, so that we can work on=
>> getting a meeting room for the selected time.
>>
>> Thanks,
>> Mary
>> DISPATCH WG co-chair
>>
>> _______________________________________________
>> dispatch mailing list
>> dispatch@ie= tf.org
>> https://www.ietf.org/mailman/listinfo/dispatch
>
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.o= rg
> https://www.ietf.org/mailman/listinfo/dispatch



--000e0cd32b5ca23d0b048c4b0611-- From mary.ietf.barnes@gmail.com Mon Jul 26 07:16:16 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CBD03A6A06 for ; Mon, 26 Jul 2010 07:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfgQz4Ae6iCy for ; Mon, 26 Jul 2010 07:16:09 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 36D903A6BFF for ; Mon, 26 Jul 2010 07:16:09 -0700 (PDT) Received: by mail-px0-f172.google.com with SMTP id 20so68677pxi.31 for ; Mon, 26 Jul 2010 07:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=pOu4usLg5j07E4UTy9RuMeXtdRiC0Rk69aEdgyXZOP4=; b=scHLri9Thpmi5mLiz44IIT8oqh+qKIzuHxOgT5gtDfkRW18//NBW83clD9PazCCxNC 4VxtwEAx2FLKaTf8UIHXCsd7IOQy1WMW6L9KUeogAecTQyePGOQkdJ1kFrnPQRgbJPos Gc3OtaAfUcX/Y59LgfQEfAu5LV+YV2Qq59ZFU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=p9pwBHb6/zXIckwODWd9yQMXWdhWB9JURdWx5uvVcN5lCqv1wi0Z1Nw7i80s5kuiRJ bYBbCGz3dOpT/VKuS6MLIsPcyR1jEnzodZ3c9moJjKdtu+nQPYCDR75N5ZILZRzVX/yU NVum9wDw5oEDsVoyRvvXqDEC96mMI8SCHJa6M= MIME-Version: 1.0 Received: by 10.114.131.13 with SMTP id e13mr11185982wad.201.1280153790435; Mon, 26 Jul 2010 07:16:30 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Mon, 26 Jul 2010 07:16:29 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Jul 2010 09:16:29 -0500 Message-ID: From: Mary Barnes To: Venkatesh Venkataramanan Content-Type: multipart/alternative; boundary=001636417fb5efd2cb048c4b07db Cc: "rai-ads@tools.ietf.org" , DISPATCH , "Botzko, Stephen" , Gonzalo Camarillo Subject: Re: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:16:16 -0000 --001636417fb5efd2cb048c4b07db Content-Type: text/plain; charset=ISO-8859-1 Correct. Thanks, Mary. On Mon, Jul 26, 2010 at 9:13 AM, Venkatesh Venkataramanan < venkatev@cisco.com> wrote: > Marshall: > > I think the Telepresence adhoc Mary is talking about is the one related to > multi-stream work that just got kicked off a few months ago. It is not the > same as the Bar Bof that is related to setting up ENUM for Telepresence > routing. > > Venkatesh > > > On 7/26/10 7:02 AM, "Marshall Eubanks" wrote: > > > Ah, thanks for the clarification. That means that the NOTE WELL will > > apply, and we need a scribe. > > > > Regards > > Marshall > > > > On Jul 26, 2010, at 10:01 AM, Mary Barnes wrote: > > > >> This isn't a bar bof. It's an "official" DISPATCH WG adhoc, so I > >> don't personally think it needs to be put on the bar bof list. > >> > >> Mary. > >> > >> On Mon, Jul 26, 2010 at 8:59 AM, Gonzalo Camarillo > >> wrote: > >> Hi, > >> > >> yes, I sent an email to RAI before. Make sure you upload your bar bofs > >> to that wiki. > >> > >> Cheers, > >> > >> Gonzalo > >> > >> On 26/07/2010 3:58 PM, Marshall Eubanks wrote: > >>> Don't forget to post it here - > >>> > >>> http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF78 > >>> > >>> or send an email to Lars > >>> > >>> Marshall > >>> > >>> On Jul 26, 2010, at 6:28 AM, Mary Barnes wrote: > >>> > >>>> Hi folks, > >>>> > >>>> Tuesday lunchtime was the most popular timeslot for this adhoc. I > >>>> will post the room information as soon as it's available. The plan > >>>> is that folks would grab some lunch and bring that to the meeting > >>>> room, so we can hopefully get started around 11:45. > >>>> > >>>> Thanks, > >>>> Mary. > >>>> > >>>> On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes < > mary.ietf.barnes@gmail.com > >>>>> wrote: > >>>> Hi, > >>>> > >>>> An adhoc for the telepresence work has been suggested for IETF-78. > >>>> > >>>> The agenda would be something like the following (depending, of > >>>> course, upon the discussion during the WG session): > >>>> > >>>> 1) Debrief - DISPATCH session (10 min) > >>>> > >>>> 2) Next Steps (45 minutes): > >>>> a) Additional use cases to consider (and volunteers to provide > >>>> details) ? > >>>> b) Refining problem statement document > >>>> c) Starting requirements document > >>>> d) Architectural Framework document - is it time to start that? > >>>> > >>>> 3) Plans going forward - discuss regular calls, mailing list setup, > >>>> etc. (10 min) > >>>> > >>>> 4) AOB (discuss potential technical issues, etc.) as time allows > >> (10 > >>>> min) > >>>> > >>>> > >>>> Please respond to the doodle poll if you have an interest in and > >> would > >>>> like to contribute to this proposed work item (i.e., willing to be > >>>> part of a design team): > >>>> http://www.doodle.com/h968u6tgehyt9ffg > >>>> > >>>> The links to charter proposal and related documents are in the > >>>> DISPATCH WG agenda: > >>>> http://www.ietf.org/proceedings/78/agenda/dispatch.html > >>>> > >>>> PLEASE respond by COB on Monday, July 19th, so that we can work on > >>>> getting a meeting room for the selected time. > >>>> > >>>> Thanks, > >>>> Mary > >>>> DISPATCH WG co-chair > >>>> > >>>> _______________________________________________ > >>>> 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 > > --001636417fb5efd2cb048c4b07db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Correct.

Thanks,
Mary.

On Mon, Jul 26, 2010 at 9:13 AM, Venkatesh Venkataramanan <venkatev@cisco.com> wrote:
Marshall:

I think the Telepresence adhoc Mary is talking about is the one related to<= br> multi-stream work that just got kicked off a few months ago. It is not the<= br> same as the Bar Bof that is related to setting up ENUM for Telepresence
routing.

Venkatesh


On 7/26/10 7:02 AM, "Marshall Eubanks" <tme@americafree.tv> wrote:

> Ah, thanks for the clarification. That means that the NOTE WELL will > apply, and we need a scribe.
>
> Regards
> Marshall
>
> On Jul 26, 2010, at 10:01 AM, Mary Barnes wrote:
>
>> This isn't a bar bof. It's an "official" DISPATC= H WG adhoc, so I
>> don't personally think it needs to be put on the bar bof list.=
>>
>> Mary.
>>
>> On Mon, Jul 26, 2010 at 8:59 AM, Gonzalo Camarillo
>> <gcamaril@gmail.com&g= t; wrote:
>> Hi,
>>
>> yes, I sent an email to RAI before. Make sure you upload your bar = bofs
>> to that wiki.
>>
>> Cheers,
>>
>> Gonzalo
>>
>> On 26/07/2010 3:58 PM, Marshall Eubanks wrote:
>>> Don't forget to post it here -
>>>
>>> http://trac.tools.ietf.org/bof/trac/wiki/BarBofsIETF= 78
>>>
>>> or send an email to Lars
>>>
>>> Marshall
>>>
>>> On Jul 26, 2010, at 6:28 AM, Mary Barnes wrote:
>>>
>>>> Hi folks,
>>>>
>>>> Tuesday lunchtime was the most popular timeslot for this a= dhoc. I
>>>> will post the room information as soon as it's availab= le. The plan
>>>> is that folks would grab some lunch and bring that to the = meeting
>>>> room, so we can hopefully get started around 11:45.
>>>>
>>>> Thanks,
>>>> Mary.
>>>>
>>>> On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes <mary.ietf.barnes@gmail.com
>>>>> wrote:
>>>> Hi,
>>>>
>>>> An adhoc for the telepresence work has been suggested for = IETF-78.
>>>>
>>>> The agenda would be something like the following (dependin= g, of
>>>> course, upon the discussion during the WG session):
>>>>
>>>> 1) Debrief - DISPATCH session (10 min)
>>>>
>>>> 2) =A0Next Steps (45 minutes):
>>>> a) Additional use cases to consider (and volunteers to pro= vide
>>>> details) ?
>>>> b) Refining problem statement document
>>>> c) Starting requirements document
>>>> d) Architectural Framework document - is it time to start = that?
>>>>
>>>> 3) Plans going forward - discuss regular calls, mailing li= st setup,
>>>> etc. (10 min)
>>>>
>>>> 4) AOB (discuss potential technical issues, etc.) as time = allows
>> (10
>>>> min)
>>>>
>>>>
>>>> Please respond to the doodle poll if you have an interest = in and
>> would
>>>> like to contribute to this proposed work item (i.e., willi= ng to be
>>>> part of a design team):
>>>> http://www.doodle.com/h968u6tgehyt9ffg
>>>>
>>>> The links to charter proposal and related documents are in= the
>>>> DISPATCH WG agenda:
>>>> http://www.ietf.org/proceedings/78/agenda/dispa= tch.html
>>>>
>>>> PLEASE respond by COB on Monday, July 19th, so that we can= work on
>>>> getting a meeting room for the selected time.
>>>>
>>>> Thanks,
>>>> Mary
>>>> DISPATCH WG co-chair
>>>>
>>>> _______________________________________________
>>>> 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


--001636417fb5efd2cb048c4b07db-- From mary.ietf.barnes@gmail.com Mon Jul 26 07:20:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 09BF33A6981 for ; Mon, 26 Jul 2010 07:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuLsEgP5vQL2 for ; Mon, 26 Jul 2010 07:20:12 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 461C53A687C for ; Mon, 26 Jul 2010 07:20:12 -0700 (PDT) Received: by gxk1 with SMTP id 1so1040761gxk.31 for ; Mon, 26 Jul 2010 07:20:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=bO5Ai7aXtngMKySJvq/6oPUWFYoCfBpDyNzQ6Wv++iQ=; b=mD3UoW2gXD6VgvZMUoivzmua9YAy3brCyy3wOMAVXxb6DKHxwDjOiNa9XHJk9uJxNi h17NrK0EAXV78OQ8+RVWX/06h8cRfjBxNsGol6FXcFUTq+8ml31+YGcPPQe305jc2HWr /9Ayt0Ov941lZ+fWmdQnvqxu7/MPvEpJW41lE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MJr2zIrSDqebWvzIPq5zjAj5qf8pGz1Uk1leaFcp8gGNYR8lkm5UKwnLH9gqCZ7/q7 9i/PmreW/xCmKqB8OHQ7fffzrQH6cxO6QczxQFjZ6RE9X37t7IA8T0ns1y0MFVACYqnZ wF7WEUznd4Ugskb/trSVdPSyTvmSjQOX9P8QY= MIME-Version: 1.0 Received: by 10.150.68.9 with SMTP id q9mr9288041yba.208.1280154033011; Mon, 26 Jul 2010 07:20:33 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Mon, 26 Jul 2010 07:20:32 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Jul 2010 09:20:32 -0500 Message-ID: From: Mary Barnes To: Hasnaa Moustafa Content-Type: multipart/alternative; boundary=000e0cd597de653e7a048c4b1650 Cc: dispatch@ietf.org Subject: Re: [dispatch] dispatch Digest, Vol 16, Issue 83 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:20:14 -0000 --000e0cd597de653e7a048c4b1650 Content-Type: text/plain; charset=ISO-8859-1 Hasnaa, I'm not sure which version of the agenda you are looking at. The current agenda doesn't have anything about adhocs: http://www.ietf.org/proceedings/78/agenda/dispatch.html If you previously looked at the agenda, you may need to reload your browser. Thanks, Mary. On Mon, Jul 26, 2010 at 9:14 AM, Hasnaa Moustafa wrote: > Hi, >> > > It is understood from this message that the ad hoc meeting is on Tuesday, > however the agenda shows that there is an adhoc meeting on Thursday > (Thursday was not proposed in the doodle pool!). > > Please confirm ASAP the exact slot (to be able to plan our other meetings). > > Kind regards, > Hassnaa > > >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 26 Jul 2010 05:28:23 -0500 >> From: Mary Barnes >> Subject: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 >> To: DISPATCH >> Cc: "Botzko, Stephen" , >> rai-ads@tools.ietf.org >> Message-ID: >> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Hi folks, >> >> Tuesday lunchtime was the most popular timeslot for this adhoc. I will >> post >> the room information as soon as it's available. The plan is that folks >> would >> grab some lunch and bring that to the meeting room, so we can hopefully >> get >> started around 11:45. >> >> Thanks, >> Mary. >> >> On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes > >wrote: >> >> > Hi, >> > >> > An adhoc for the telepresence work has been suggested for IETF-78. >> > >> > The agenda would be something like the following (depending, of >> > course, upon the discussion during the WG session): >> > >> > 1) Debrief - DISPATCH session (10 min) >> > >> > 2) Next Steps (45 minutes): >> > a) Additional use cases to consider (and volunteers to provide details) >> ? >> > b) Refining problem statement document >> > c) Starting requirements document >> > d) Architectural Framework document - is it time to start that? >> > >> > 3) Plans going forward - discuss regular calls, mailing list setup, >> > etc. (10 min) >> > >> > 4) AOB (discuss potential technical issues, etc.) as time allows (10 >> min) >> > >> > >> > Please respond to the doodle poll if you have an interest in and would >> > like to contribute to this proposed work item (i.e., willing to be >> > part of a design team): >> > http://www.doodle.com/h968u6tgehyt9ffg >> > >> > The links to charter proposal and related documents are in the >> > DISPATCH WG agenda: >> > http://www.ietf.org/proceedings/78/agenda/dispatch.html >> > >> > PLEASE respond by COB on Monday, July 19th, so that we can work on >> > getting a meeting room for the selected time. >> > >> > Thanks, >> > Mary >> > DISPATCH WG co-chair >> > >> -------------- next part -------------- >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --000e0cd597de653e7a048c4b1650 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hasnaa,

I'm not sure which version of the agenda you= are looking at. =A0The current agenda doesn't have anything about adho= cs:

If you previously looked at the agenda, you may need to= reload your browser.

Thanks,
Mary.=A0


On Mon, Jul 26, 2010= at 9:14 AM, Hasnaa Moustafa <hasnaa.moustafa@gmail.com> wrote:
Hi,
=A0
It is=A0understood from this message that the ad hoc meeting is on Tue= sday, however the agenda shows that there is an adhoc meeting on Thursday (= Thursday was not proposed in the doodle pool!).
=A0
Please confirm ASAP the exact slot (to be able to plan our other meeti= ngs).
=A0
Kind regards,
Hassnaa
=A0

---------------------------------= -------------------------------------

Message: 1
Date: Mon, 26 Ju= l 2010 05:28:23 -0500
From: Mary Barnes <mary.ietf.barnes@gmail.com>
Subject: [dispatch] Telep= resence adhoc - Tuesday, July 27, 2010
To: DISPATCH <dispatch@ietf.org>
Cc: "Botzko, Stephen" <Stephen.Botzko@polycom.com>,
=A0 =A0 =A0= =A0rai-ads@too= ls.ietf.org
Message-ID:
=A0 =A0 =A0 =A0<AANLkTinSL=3DXYAiPMgbvSTeh-YaM=3D_QXwTM3DU4Vp5v3= Z@mail.gmail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

Hi folks,=

Tuesday lunchtime was the most popular timeslot for this adhoc. I w= ill post
the room information as soon as it's available. The plan is= that folks would
grab some lunch and bring that to the meeting room, so we can hopefully get=
started around 11:45.

Thanks,
Mary.

On Fri, Jul 16, 20= 10 at 12:10 PM, Mary Barnes <mary.ietf.barnes@gmail.com>wrote:

> Hi,
>
> An adhoc for the telepresence work has been su= ggested for IETF-78.
>
> The agenda would be something like the= following (depending, of
> course, upon the discussion during the WG= session):
>
> 1) Debrief - DISPATCH session (10 min)
>
> 2) =A0N= ext Steps (45 minutes):
> a) Additional use cases to consider (and vo= lunteers to provide details) ?
> b) Refining problem statement docume= nt
> c) Starting requirements document
> d) Architectural Framework d= ocument - is it time to start that?
>
> 3) Plans going forward = - discuss regular calls, mailing list setup,
> etc. (10 min)
>
> 4) AOB (discuss potential technical issues, etc.) as time allows (10 m= in)
>
>
> Please respond to the doodle poll if you have a= n interest in and would
> like to contribute to this proposed work it= em (i.e., willing to be
> part of a design team):
> http://www.doodle.com/h968u6tgehyt9ffg>
> The links to charter proposal and related documents are in t= he
> DISPATCH WG agenda:
> http://www.ietf.org/proceedings= /78/agenda/dispatch.html
>
> PLEASE respond by COB on Monda= y, July 19th, so that we can work on
> getting a meeting room for the selected time.
>
> Thanks,<= br>> Mary
> DISPATCH WG co-chair
>
-------------- next pa= rt --------------

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


--000e0cd597de653e7a048c4b1650-- From tme@americafree.tv Mon Jul 26 07:47:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DCA93A6A84 for ; Mon, 26 Jul 2010 07:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTTXUY08FFfI for ; Mon, 26 Jul 2010 07:47:02 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id C1FFC3A6BB7 for ; Mon, 26 Jul 2010 07:46:42 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 3A0D081BAF98; Mon, 26 Jul 2010 10:47:03 -0400 (EDT) Message-Id: <536F7A89-D9AE-4EAE-B2D6-DC78DCC60469@americafree.tv> From: Marshall Eubanks To: Gonzalo Camarillo In-Reply-To: <4C4D30E0.7000603@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 10:47:02 -0400 References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><022f01cb1eb4$2f9f59b0$8ede0d10$@com><04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> <15655197-E667-4A1F-BD12-1A 1961081D7D@americafree.tv> <1C6FD77A-A6C6-4897-B1CA-D2FC844522F1@americafree.tv> <4C4B0A28.4040206@cisco.com> <4FCE84E6-D98C-46A1-8505 -E1C7578B14F4@americafree.tv> <99AD8262-C872-4F9D-8DA9-CF4E562141E6@americafree.tv > <4C4D30E0.7000603@ericsson.com> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:47:03 -0000 On Jul 26, 2010, at 2:53 AM, Gonzalo Camarillo wrote: > Hi Marshall, > > the last session today ends at 19:40. Where and when exactly shall > we meet? Well, I put 1940 (AKA 7:40 PM) on the Doodle poll for that reason. So, that's _when_ (obviously, we need to wait around a bit to collect stragglers). I do not see an obvious session for everyone to be at - what if we meet just near the registration ? Say at the SIDN "booth" with the big inflated tulip across from the registration desks. Regards Marshall > > Thanks, > > Gonzalo > > On 26/07/2010 3:49 AM, Marshall Eubanks wrote: >> Sorry - please disregard that, as this will NOT be a lunch meeting. >> This is a dinner meeting. >> >> I would suggest that we either >> >> - eat at the NH hotel or >> - take a taxi to the city center. >> >> Regards >> Marshall >> >> On Jul 24, 2010, at 5:11 PM, Marshall Eubanks wrote: >> >>> How about this >>> >>> Lunch will be available from 11:00 to 15:00 Monday through Thursday >>> in the >>> Expo Foyer at the MECC, and 11:00 to 14:00 on Friday. The menu will >>> vary >>> throughout the week, but a sample of offered items is below: >>> >>> Marshall >>> >>> On Jul 24, 2010, at 11:43 AM, Paul Kyzivat wrote: >>> >>>> >>>> >>>> Marshall Eubanks wrote: >>>> >>>>> Based on the doodle, and with Mary Barnes acceptance (as she will >>>>> not be able to attend), I think that >>>>> we should meet just after the last session on Monday. (See the >>>>> Doodle site for the votes.) >>>> >>>> Any idea *where* to meet? Perhaps in the ietf registration table >>>> area? >>>> (Not having seen the facility yet, I don't know what else there >>>> is.) >>>> >>>>> Do people want to make this a dinner meeting and, if so, in the >>>>> MECC area or somewhere else ? Specific suggestions would be >>>>> welcomed. >>>> >>>> If we are meeting at 7:50, then unless its for dinner there may not >>>> be any dinner. So dinner sounds good to me. >>>> >>>> I have no idea of where. I haven't done *any* homework on >>>> Mastricht. >>>> >>>> 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 >> > > From gonzalo.camarillo@ericsson.com Mon Jul 26 07:53:25 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9E053A683F for ; Mon, 26 Jul 2010 07:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.789 X-Spam-Level: X-Spam-Status: No, score=-105.789 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UzqPRoKQfpBY for ; Mon, 26 Jul 2010 07:53:17 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id AC4273A6A83 for ; Mon, 26 Jul 2010 07:53:00 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-16-4c4da16195b6 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id C2.9C.10125.161AD4C4; Mon, 26 Jul 2010 16:53:21 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 16:53:20 +0200 Received: from [131.160.126.137] ([131.160.126.137]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 16:53:19 +0200 Message-ID: <4C4DA15E.1060207@ericsson.com> Date: Mon, 26 Jul 2010 16:53:18 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Marshall Eubanks References: <1D062974A4845E4D8A343C6538049202030CA296@XMB-BGL-414.cisco.com><04ac01cb1ee4$ea7712c0$bf653840$@com><04CA7DCC63584C4D8967FF818D80965B01BB8419@XMB-RCD-113.cisco.com>, <4C3668F4.1080807@cisco.com><114DAD31379DFA438C0A2E39B3B8AF5D01419B2525@srvxchg><4C3E3FF6.1050003@cisco.com><7A658B6C-E0E0-48C5-B27A-DBFE79E076F7@americafree.tv> <02E96FA3-FB50-4A10-8341-C992638D8BD1@americafree.tv> <15655197-E667-4A1F-BD12-1A 1961081D7D@americafree.tv> <1C6FD77A-A6C6-4897-B1CA-D2FC844522F1@americafree.tv> <4C4B0A28.4040206@cisco.com> <4FCE84E6-D98C-46A1-8505 -E1C7578B14F4@americafree.tv> <99AD8262-C872-4F9D-8DA9-CF4E562141E6@americafree.tv > <4C4D30E0.7000603@ericsson.com> <536F7A89-D9AE-4EAE-B2D6-DC78DCC60469@americafree. tv> In-Reply-To: <536F7A89-D9AE-4EAE-B2D6-DC78DCC60469@americafree.tv> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2010 14:53:20.0932 (UTC) FILETIME=[4A2BA640:01CB2CD2] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH list , Daryl Malas Subject: Re: [dispatch] Should IETF have a BEHAVE WG for SBCs? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 14:53:25 -0000 Sure, let's meet there after the last session. Cheers, Gonzalo On 26/07/2010 4:47 PM, Marshall Eubanks wrote: > > On Jul 26, 2010, at 2:53 AM, Gonzalo Camarillo wrote: > >> Hi Marshall, >> >> the last session today ends at 19:40. Where and when exactly shall >> we meet? > > Well, I put 1940 (AKA 7:40 PM) on the Doodle poll for that reason. > > So, that's _when_ (obviously, we need to wait around a bit to collect > stragglers). > > I do not see an obvious session for everyone to be at - what if we > meet just near the registration ? Say > at the SIDN "booth" with the big inflated tulip across from the > registration desks. > > Regards > Marshall > > > >> >> Thanks, >> >> Gonzalo >> >> On 26/07/2010 3:49 AM, Marshall Eubanks wrote: >>> Sorry - please disregard that, as this will NOT be a lunch meeting. >>> This is a dinner meeting. >>> >>> I would suggest that we either >>> >>> - eat at the NH hotel or >>> - take a taxi to the city center. >>> >>> Regards >>> Marshall >>> >>> On Jul 24, 2010, at 5:11 PM, Marshall Eubanks wrote: >>> >>>> How about this >>>> >>>> Lunch will be available from 11:00 to 15:00 Monday through Thursday >>>> in the >>>> Expo Foyer at the MECC, and 11:00 to 14:00 on Friday. The menu will >>>> vary >>>> throughout the week, but a sample of offered items is below: >>>> >>>> Marshall >>>> >>>> On Jul 24, 2010, at 11:43 AM, Paul Kyzivat wrote: >>>> >>>>> >>>>> >>>>> Marshall Eubanks wrote: >>>>> >>>>>> Based on the doodle, and with Mary Barnes acceptance (as she will >>>>>> not be able to attend), I think that >>>>>> we should meet just after the last session on Monday. (See the >>>>>> Doodle site for the votes.) >>>>> >>>>> Any idea *where* to meet? Perhaps in the ietf registration table >>>>> area? >>>>> (Not having seen the facility yet, I don't know what else there >>>>> is.) >>>>> >>>>>> Do people want to make this a dinner meeting and, if so, in the >>>>>> MECC area or somewhere else ? Specific suggestions would be >>>>>> welcomed. >>>>> >>>>> If we are meeting at 7:50, then unless its for dinner there may not >>>>> be any dinner. So dinner sounds good to me. >>>>> >>>>> I have no idea of where. I haven't done *any* homework on >>>>> Mastricht. >>>>> >>>>> 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 >>> >> >> > From dromasca@avaya.com Mon Jul 26 23:23:41 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F183A6845 for ; Mon, 26 Jul 2010 23:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5fzrbe8A2PP for ; Mon, 26 Jul 2010 23:23:39 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 2A4693A686B for ; Mon, 26 Jul 2010 23:23:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.55,266,1278302400"; d="scan'208,217";a="199837006" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 27 Jul 2010 02:23:59 -0400 X-IronPort-AV: E=Sophos;i="4.55,266,1278302400"; d="scan'208,217";a="486060545" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 27 Jul 2010 02:23:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2D54.44942D5D" Date: Tue, 27 Jul 2010 08:23:45 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 Thread-Index: Acssreu51wHx3duQT2KtIi1D3mevpAApkxww References: From: "Romascanu, Dan (Dan)" To: "Mary Barnes" , "DISPATCH" Cc: rai-ads@tools.ietf.org, "Botzko, Stephen" Subject: Re: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 06:23:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2D54.44942D5D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is there already a room allocated for this meeting?=20 =20 Dan =20 ________________________________ From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Monday, July 26, 2010 1:28 PM To: DISPATCH Cc: Botzko, Stephen; rai-ads@tools.ietf.org Subject: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 =09 =09 Hi folks,=20 Tuesday lunchtime was the most popular timeslot for this adhoc. I will post the room information as soon as it's available. The plan is that folks would grab some lunch and bring that to the meeting room, so we can hopefully get started around 11:45. Thanks, Mary.=20 =09 =09 On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes wrote: =09 Hi, =09 An adhoc for the telepresence work has been suggested for IETF-78. =09 The agenda would be something like the following (depending, of course, upon the discussion during the WG session): =09 1) Debrief - DISPATCH session (10 min) =09 2) Next Steps (45 minutes): a) Additional use cases to consider (and volunteers to provide details) ? b) Refining problem statement document c) Starting requirements document d) Architectural Framework document - is it time to start that? =09 3) Plans going forward - discuss regular calls, mailing list setup, etc. (10 min) =09 4) AOB (discuss potential technical issues, etc.) as time allows (10 min) =09 =09 Please respond to the doodle poll if you have an interest in and would like to contribute to this proposed work item (i.e., willing to be part of a design team): http://www.doodle.com/h968u6tgehyt9ffg =09 The links to charter proposal and related documents are in the DISPATCH WG agenda: http://www.ietf.org/proceedings/78/agenda/dispatch.html =09 PLEASE respond by COB on Monday, July 19th, so that we can work on getting a meeting room for the selected time. =09 Thanks, Mary DISPATCH WG co-chair =09 ------_=_NextPart_001_01CB2D54.44942D5D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Is=20 there already a room allocated for this meeting?
 
Dan
 

From: dispatch-bounces@ietf.org=20 [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary=20 Barnes
Sent: Monday, July 26, 2010 1:28 PM
To:=20 DISPATCH
Cc: Botzko, Stephen;=20 rai-ads@tools.ietf.org
Subject: [dispatch] Telepresence = adhoc -=20 Tuesday, July 27, 2010

Hi folks,

Tuesday lunchtime was the most popular timeslot for this adhoc. I = will=20 post the room information as soon as it's available. The plan is that = folks=20 would grab some lunch and bring that to the meeting room, so we can = hopefully=20 get started around 11:45.

Thanks,
Mary. 

On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes = <mary.ietf.barnes@gmail.com= >=20 wrote:
Hi,

An=20 adhoc for the telepresence work has been suggested for = IETF-78.

The=20 agenda would be something like the following (depending, = of
course, upon=20 the discussion during the WG session):

1) Debrief - DISPATCH = session=20 (10 min)

2)  Next Steps (45 minutes):
a) Additional = use cases=20 to consider (and volunteers to provide details) ?
b) Refining = problem=20 statement document
c) Starting requirements document
d) = Architectural=20 Framework document - is it time to start that?

3) Plans going = forward=20 - discuss regular calls, mailing list setup,
etc. (10 = min)

4) AOB=20 (discuss potential technical issues, etc.) as time allows (10=20 min)


Please respond to the doodle poll if you have an = interest in=20 and would
like to contribute to this proposed work item (i.e., = willing to=20 be
part of a design team):
http://www.doodle.com/h968u6tgehyt9ffg

The = links to=20 charter proposal and related documents are in the
DISPATCH WG=20 agenda:
http://www.ietf.org/proceedings/78/agenda/dispatch.html

PLEASE=20 respond by COB on Monday, July 19th, so that we can work = on
getting a=20 meeting room for the selected = time.

Thanks,
Mary
DISPATCH WG=20 co-chair

------_=_NextPart_001_01CB2D54.44942D5D-- From gcamaril@gmail.com Mon Jul 26 23:24:51 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4BB63A696F for ; Mon, 26 Jul 2010 23:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.511 X-Spam-Level: X-Spam-Status: No, score=-5.511 tagged_above=-999 required=5 tests=[AWL=1.087, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhxC4vz2ZIJj for ; Mon, 26 Jul 2010 23:24:50 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 873333A6845 for ; Mon, 26 Jul 2010 23:24:50 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-25-4c4e7bc7d610 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AA.8E.10125.7CB7E4C4; Tue, 27 Jul 2010 08:25:11 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jul 2010 08:25:11 +0200 Received: from [131.160.126.137] ([131.160.126.137]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Jul 2010 08:25:11 +0200 Message-ID: <4C4E7BC6.20601@gmail.com> Date: Tue, 27 Jul 2010 08:25:10 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Romascanu, Dan (Dan)" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2010 06:25:11.0386 (UTC) FILETIME=[7765E3A0:01CB2D54] X-Brightmail-Tracker: AAAAAA== Cc: DISPATCH , "Botzko, Stephen" , "rai-ads@tools.ietf.org" Subject: Re: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 06:24:52 -0000 Hi, we are working with the secretary on this. Mary will announce the room as soon as we know. Cheers, Gonzalo On 27/07/2010 8:23 AM, Romascanu, Dan (Dan) wrote: > Is there already a room allocated for this meeting? > > Dan > > > ------------------------------------------------------------------------ > *From:* dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] > *On Behalf Of *Mary Barnes > *Sent:* Monday, July 26, 2010 1:28 PM > *To:* DISPATCH > *Cc:* Botzko, Stephen; rai-ads@tools.ietf.org > *Subject:* [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 > > Hi folks, > > Tuesday lunchtime was the most popular timeslot for this adhoc. I > will post the room information as soon as it's available. The plan > is that folks would grab some lunch and bring that to the meeting > room, so we can hopefully get started around 11:45. > > Thanks, > Mary. > > On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes > > wrote: > > Hi, > > An adhoc for the telepresence work has been suggested for IETF-78. > > The agenda would be something like the following (depending, of > course, upon the discussion during the WG session): > > 1) Debrief - DISPATCH session (10 min) > > 2) Next Steps (45 minutes): > a) Additional use cases to consider (and volunteers to provide > details) ? > b) Refining problem statement document > c) Starting requirements document > d) Architectural Framework document - is it time to start that? > > 3) Plans going forward - discuss regular calls, mailing list setup, > etc. (10 min) > > 4) AOB (discuss potential technical issues, etc.) as time allows > (10 min) > > > Please respond to the doodle poll if you have an interest in and > would > like to contribute to this proposed work item (i.e., willing to be > part of a design team): > http://www.doodle.com/h968u6tgehyt9ffg > > The links to charter proposal and related documents are in the > DISPATCH WG agenda: > http://www.ietf.org/proceedings/78/agenda/dispatch.html > > PLEASE respond by COB on Monday, July 19th, so that we can work on > getting a meeting room for the selected time. > > Thanks, > Mary > DISPATCH WG co-chair > > From stephen.botzko@gmail.com Tue Jul 27 00:07:44 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCFD93A6907 for ; Tue, 27 Jul 2010 00:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.017 X-Spam-Level: X-Spam-Status: No, score=-2.017 tagged_above=-999 required=5 tests=[AWL=0.582, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yinwLrM5GUUg for ; Tue, 27 Jul 2010 00:07:42 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 288B23A68E7 for ; Tue, 27 Jul 2010 00:07:42 -0700 (PDT) Received: by wwj40 with SMTP id 40so717774wwj.13 for ; Tue, 27 Jul 2010 00:08:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=FfdEZ8zimDhRGNG5oVUQB3cxWW4WpmoX9HwCURx2Fxw=; b=OurPX5gkVyNOKtzH08ONill/DW6oRT/xfz6SO+LOMaI+xRO3hxu/qhr7Wc2RLnPb2r YHCjgPV5/N5DQ9uraUuJIXJhN79foYtP3O96FRTXjBXxerWQbX5Ckz583kTTRhtwxQK8 ckf35wREVXp4iQWYvgNFv+zGCykZ76es+KMGU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Yc96RDiI87nI0nGYjm0OYqf3YadynQZ0Cq/A/nH1biBKuwqgSCvlsemUc+b08vsixz C0L/YL2xWlKkQmCcebdWFLqnMUt/baq0wwjDsVVhh+odYVyVJqp9tdjroCpLnvihVhwt uCOSMOtJbAXXiEBSTuZ2OkdkK5LYO50oAc/uw= MIME-Version: 1.0 Received: by 10.216.169.80 with SMTP id m58mr8490329wel.79.1280214483058; Tue, 27 Jul 2010 00:08:03 -0700 (PDT) Received: by 10.216.80.81 with HTTP; Tue, 27 Jul 2010 00:08:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Jul 2010 09:08:02 +0200 Message-ID: From: stephen botzko To: "Romascanu, Dan (Dan)" Content-Type: multipart/alternative; boundary=0016363ba7a07fc3c4048c5929cd Cc: DISPATCH , "Botzko, Stephen" , rai-ads@tools.ietf.org Subject: Re: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 07:07:44 -0000 --0016363ba7a07fc3c4048c5929cd Content-Type: text/plain; charset=ISO-8859-1 London; 11:45 today. On Tue, Jul 27, 2010 at 8:23 AM, Romascanu, Dan (Dan) wrote: > Is there already a room allocated for this meeting? > > Dan > > > ------------------------------ > *From:* dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] *On > Behalf Of *Mary Barnes > *Sent:* Monday, July 26, 2010 1:28 PM > *To:* DISPATCH > *Cc:* Botzko, Stephen; rai-ads@tools.ietf.org > *Subject:* [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 > > Hi folks, > > Tuesday lunchtime was the most popular timeslot for this adhoc. I will post > the room information as soon as it's available. The plan is that folks would > grab some lunch and bring that to the meeting room, so we can hopefully get > started around 11:45. > > Thanks, > Mary. > > On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes wrote: > >> Hi, >> >> An adhoc for the telepresence work has been suggested for IETF-78. >> >> The agenda would be something like the following (depending, of >> course, upon the discussion during the WG session): >> >> 1) Debrief - DISPATCH session (10 min) >> >> 2) Next Steps (45 minutes): >> a) Additional use cases to consider (and volunteers to provide details) ? >> b) Refining problem statement document >> c) Starting requirements document >> d) Architectural Framework document - is it time to start that? >> >> 3) Plans going forward - discuss regular calls, mailing list setup, >> etc. (10 min) >> >> 4) AOB (discuss potential technical issues, etc.) as time allows (10 min) >> >> >> Please respond to the doodle poll if you have an interest in and would >> like to contribute to this proposed work item (i.e., willing to be >> part of a design team): >> http://www.doodle.com/h968u6tgehyt9ffg >> >> The links to charter proposal and related documents are in the >> DISPATCH WG agenda: >> http://www.ietf.org/proceedings/78/agenda/dispatch.html >> >> PLEASE respond by COB on Monday, July 19th, so that we can work on >> getting a meeting room for the selected time. >> >> Thanks, >> Mary >> DISPATCH WG co-chair >> > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --0016363ba7a07fc3c4048c5929cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable London; 11:45 today.

On Tue, Jul 27, 2010= at 8:23 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:
Is=20 there already a room allocated for this meeting?
= =A0
Dan
=A0

From: dispatch-bounces@ietf.org=20 [mailto:di= spatch-bounces@ietf.org] On Behalf Of Mary=20 Barnes
Sent: Monday, July 26, 2010 1:28 PM
To:=20 DISPATCH
Cc: Botzko, Stephen;=20 rai-ads@tools= .ietf.org
Subject: [dispatch] Telepresence adhoc -=20 Tuesday, July 27, 2010

Hi folks,

Tuesday lunchtime was the most popular timeslot for this adhoc. I wi= ll=20 post the room information as soon as it's available. The plan is that= folks=20 would grab some lunch and bring that to the meeting room, so we can hopef= ully=20 get started around 11:45.

Thanks,
Mary.=A0

On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes = <mary.ietf.barnes@gmail.com>=20 wrote:
Hi,

An= =20 adhoc for the telepresence work has been suggested for IETF-78.

= The=20 agenda would be something like the following (depending, of
course, = upon=20 the discussion during the WG session):

1) Debrief - DISPATCH ses= sion=20 (10 min)

2) =A0Next Steps (45 minutes):
a) Additional use cas= es=20 to consider (and volunteers to provide details) ?
b) Refining proble= m=20 statement document
c) Starting requirements document
d) Architect= ural=20 Framework document - is it time to start that?

3) Plans going fo= rward=20 - discuss regular calls, mailing list setup,
etc. (10 min)

4)= AOB=20 (discuss potential technical issues, etc.) as time allows (10=20 min)


Please respond to the doodle poll if you have an intere= st in=20 and would
like to contribute to this proposed work item (i.e., willi= ng to=20 be
part of a design team):
http://www.doodle.com/h968u6tgehyt9ffg
The links to=20 charter proposal and related documents are in the
DISPATCH WG=20 agenda:
http://www.ietf.org/proceedings/78/agenda/dispatc= h.html

PLEASE=20 respond by COB on Monday, July 19th, so that we can work on
getting = a=20 meeting room for the selected time.

Thanks,
Mary
DISPATCH = WG=20 co-chair


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


--0016363ba7a07fc3c4048c5929cd-- From fluffy@cisco.com Tue Jul 27 00:08:14 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E908E3A6907 for ; Tue, 27 Jul 2010 00:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.415 X-Spam-Level: X-Spam-Status: No, score=-110.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHKbVTzVkqzh for ; Tue, 27 Jul 2010 00:08:14 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id E92F73A68E7 for ; Tue, 27 Jul 2010 00:08:13 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwHAHMiTkxAZnwN/2dsb2JhbAAen0dxpWGbQ4U2BIho X-IronPort-AV: E=Sophos;i="4.55,266,1278288000"; d="scan'208";a="139568616" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2010 07:08:35 +0000 Received: from ams3-vpn-dhcp5715.cisco.com (ams3-vpn-dhcp5715.cisco.com [10.61.86.82]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6R78Y25011598 for ; Tue, 27 Jul 2010 07:08:35 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jul 2010 09:08:33 +0200 Message-Id: <5C0A702F-0827-404E-820B-24EEE1022335@cisco.com> To: "dispatch@ietf.org list" Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [dispatch] Tele Presence ADHoc - TODAY X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 07:08:15 -0000 We will be meeting in the "London" room at 11:45 (right after the end of = the main DISPATCH meeting) From dschwartz@xconnect.net Tue Jul 27 00:30:28 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDFA23A6A95 for ; Tue, 27 Jul 2010 00:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMLNIgRzslR6 for ; Tue, 27 Jul 2010 00:30:26 -0700 (PDT) Received: from outlook.xconnect.net (outlook.xconnect.net [212.25.92.170]) by core3.amsl.com (Postfix) with ESMTP id 754F63A6A73 for ; Tue, 27 Jul 2010 00:30:25 -0700 (PDT) Received: from ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) by ISR-JLM-MAIL1.xconnect.co.il ([172.16.100.8]) with mapi; Tue, 27 Jul 2010 10:30:44 +0300 From: David Schwartz To: stephen botzko , "Romascanu, Dan (Dan)" Date: Tue, 27 Jul 2010 10:28:58 +0300 Thread-Topic: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 Thread-Index: AcstWow1o7wh8jKmQ5yu/RHd1L7riAAAtRys Message-ID: <6EA53FAD386F9D46B97D49BFE148D51439E45117@ISR-JLM-MAIL1.xconnect.co.il> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "rai-ads@tools.ietf.org" , DISPATCH , "Botzko, Stephen" Subject: Re: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 07:30:29 -0000 I know this is an ad hoc meeting but I was wondering if nonetheless someone= can take notes and post to the list for those unable to attend. Thanks, :D ________________________________________ From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On Behalf Of st= ephen botzko [stephen.botzko@gmail.com] Sent: Tuesday, July 27, 2010 10:08 AM To: Romascanu, Dan (Dan) Cc: DISPATCH; Botzko, Stephen; rai-ads@tools.ietf.org Subject: Re: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 London; 11:45 today. On Tue, Jul 27, 2010 at 8:23 AM, Romascanu, Dan (Dan) > wrote: Is there already a room allocated for this meeting? Dan ________________________________ From: dispatch-bounces@ietf.org [mailto:d= ispatch-bounces@ietf.org] On Behalf Of Ma= ry Barnes Sent: Monday, July 26, 2010 1:28 PM To: DISPATCH Cc: Botzko, Stephen; rai-ads@tools.ietf.org Subject: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 Hi folks, Tuesday lunchtime was the most popular timeslot for this adhoc. I will post= the room information as soon as it's available. The plan is that folks wou= ld grab some lunch and bring that to the meeting room, so we can hopefully = get started around 11:45. Thanks, Mary. On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes > wrote: Hi, An adhoc for the telepresence work has been suggested for IETF-78. The agenda would be something like the following (depending, of course, upon the discussion during the WG session): 1) Debrief - DISPATCH session (10 min) 2) Next Steps (45 minutes): a) Additional use cases to consider (and volunteers to provide details) ? b) Refining problem statement document c) Starting requirements document d) Architectural Framework document - is it time to start that? 3) Plans going forward - discuss regular calls, mailing list setup, etc. (10 min) 4) AOB (discuss potential technical issues, etc.) as time allows (10 min) Please respond to the doodle poll if you have an interest in and would like to contribute to this proposed work item (i.e., willing to be part of a design team): http://www.doodle.com/h968u6tgehyt9ffg The links to charter proposal and related documents are in the DISPATCH WG agenda: http://www.ietf.org/proceedings/78/agenda/dispatch.html PLEASE respond by COB on Monday, July 19th, so that we can work on getting a meeting room for the selected time. Thanks, Mary DISPATCH WG co-chair _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From tme@americafree.tv Tue Jul 27 00:32:08 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD2C3A6A92 for ; Tue, 27 Jul 2010 00:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uEqj2qUGGbt for ; Tue, 27 Jul 2010 00:32:06 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 56A773A6A38 for ; Tue, 27 Jul 2010 00:32:05 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 9DB7781D78EB; Tue, 27 Jul 2010 03:32:26 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Cullen Jennings In-Reply-To: <5C0A702F-0827-404E-820B-24EEE1022335@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Jul 2010 03:32:25 -0400 References: <5C0A702F-0827-404E-820B-24EEE1022335@cisco.com> X-Mailer: Apple Mail (2.936) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Tele Presence ADHoc - TODAY X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 07:32:08 -0000 what about time to get lunch ? On Jul 27, 2010, at 3:08 AM, Cullen Jennings wrote: > > We will be meeting in the "London" room at 11:45 (right after the > end of the main DISPATCH meeting) > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From tme@americafree.tv Tue Jul 27 00:37:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9203A69E9 for ; Tue, 27 Jul 2010 00:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPcUnHLmRBab for ; Tue, 27 Jul 2010 00:37:16 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id C4C8B3A69A5 for ; Tue, 27 Jul 2010 00:37:15 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 9DE0081D7B55; Tue, 27 Jul 2010 03:37:36 -0400 (EDT) Message-Id: <9D180259-D6C7-48C9-8090-09BA6B1DAC6B@americafree.tv> From: Marshall Eubanks To: David Schwartz In-Reply-To: <6EA53FAD386F9D46B97D49BFE148D51439E45117@ISR-JLM-MAIL1.xconnect.co.il> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Jul 2010 03:37:35 -0400 References: , <6EA53FAD386F9D46B97D49BFE148D51439E45117@ISR-JLM-MAIL1.xconnect.co.il> X-Mailer: Apple Mail (2.936) Cc: DISPATCH , "rai-ads@tools.ietf.org" , "Botzko, Stephen" Subject: Re: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 07:37:17 -0000 I could jabber scribe it in "DISPATCH" On Jul 27, 2010, at 3:28 AM, David Schwartz wrote: > I know this is an ad hoc meeting but I was wondering if nonetheless > someone can take notes and post to the list for those unable to > attend. > > Thanks, > > :D > ________________________________________ > From: dispatch-bounces@ietf.org [dispatch-bounces@ietf.org] On > Behalf Of stephen botzko [stephen.botzko@gmail.com] > Sent: Tuesday, July 27, 2010 10:08 AM > To: Romascanu, Dan (Dan) > Cc: DISPATCH; Botzko, Stephen; rai-ads@tools.ietf.org > Subject: Re: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 > > London; 11:45 today. > > On Tue, Jul 27, 2010 at 8:23 AM, Romascanu, Dan (Dan) > wrote: > Is there already a room allocated for this meeting? > > Dan > > > ________________________________ > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org > ] On Behalf Of Mary Barnes > Sent: Monday, July 26, 2010 1:28 PM > To: DISPATCH > Cc: Botzko, Stephen; rai-ads@tools.ietf.org > > Subject: [dispatch] Telepresence adhoc - Tuesday, July 27, 2010 > > Hi folks, > > Tuesday lunchtime was the most popular timeslot for this adhoc. I > will post the room information as soon as it's available. The plan > is that folks would grab some lunch and bring that to the meeting > room, so we can hopefully get started around 11:45. > > Thanks, > Mary. > > On Fri, Jul 16, 2010 at 12:10 PM, Mary Barnes > wrote: > Hi, > > An adhoc for the telepresence work has been suggested for IETF-78. > > The agenda would be something like the following (depending, of > course, upon the discussion during the WG session): > > 1) Debrief - DISPATCH session (10 min) > > 2) Next Steps (45 minutes): > a) Additional use cases to consider (and volunteers to provide > details) ? > b) Refining problem statement document > c) Starting requirements document > d) Architectural Framework document - is it time to start that? > > 3) Plans going forward - discuss regular calls, mailing list setup, > etc. (10 min) > > 4) AOB (discuss potential technical issues, etc.) as time allows (10 > min) > > > Please respond to the doodle poll if you have an interest in and would > like to contribute to this proposed work item (i.e., willing to be > part of a design team): > http://www.doodle.com/h968u6tgehyt9ffg > > The links to charter proposal and related documents are in the > DISPATCH WG agenda: > http://www.ietf.org/proceedings/78/agenda/dispatch.html > > PLEASE respond by COB on Monday, July 19th, so that we can work on > getting a meeting room for the selected time. > > Thanks, > Mary > DISPATCH WG co-chair > > > _______________________________________________ > 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 mperumal@cisco.com Tue Jul 27 06:55:19 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B563A3A6A98 for ; Tue, 27 Jul 2010 06:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.338 X-Spam-Level: X-Spam-Status: No, score=-9.338 tagged_above=-999 required=5 tests=[AWL=1.261, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HGRo2vBWJk0p for ; Tue, 27 Jul 2010 06:55:18 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id BEDAA3A6994 for ; Tue, 27 Jul 2010 06:55:18 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOGBTkxAaHte/2dsb2JhbACfZnGmHptHhTYEhAeHHQwB X-IronPort-AV: E=Sophos;i="4.55,267,1278288000"; d="scan'208";a="231319823" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 27 Jul 2010 13:55:39 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6RDtcOx017386; Tue, 27 Jul 2010 13:55:39 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Jul 2010 19:25:38 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jul 2010 19:25:33 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020332B8ED@XMB-BGL-414.cisco.com> In-Reply-To: <430FC6BDED356B4C8498F634416644A9258D7F406A@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsqapPVh+OK8YFpQXGnQnKGiHSQ5gABOsNgAABvVUAAAJWCQADF5h7A References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail><1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> <4C4882BE.3060402@cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F403B@mail> <4C499854.6030105@cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F4054@mail> <1D062974A4845E4D8A343C65380492020332B298@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F406A@mail> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Hadriel Kaplan" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 27 Jul 2010 13:55:38.0662 (UTC) FILETIME=[64E8EC60:01CB2D93] Cc: dispatch@ietf.org Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 13:55:19 -0000 |That wouldn't fulfill Requirement 2b in the draft: "The identifier must |not reveal to the receiver of it that the Call-ID, tags, or any other SIP=20 |header or body portion have been changed by middle-boxes, with as high a |probability as possible." This makes sense. |So the idea would be for the operator to install the session-id key(s)=20 |on the probes or the probe-manager through an out-of-band method. In=20 |other words, the process of putting the key in the monitor does not |have to be elegant or defined, and isn't done very often. It is hard to imagine they would be using randomly generated keys or provisioning them on the monitor using an out-of-band mechanism on a call-by-call basis -- seems would make it difficult for other similar vendors to implement.=20 Muthu |-----Original Message----- |From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] |Sent: Friday, July 23, 2010 8:09 PM |To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat) |Cc: dispatch@ietf.org |Subject: RE: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 | | | |> -----Original Message----- |> From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] |> Sent: Friday, July 23, 2010 10:23 AM |> To: Hadriel Kaplan; Paul Kyzivat (pkyzivat) |> |> Can't we include the key, the pseudo-random number generated by the B2BUA, |> in a session-id header parameter so that the B2BUA doesn't have to share |> anything with the monitor? It should still be computationally infeasible |> to derive the original call-id from its hash, since neither this call-id |> not the key is reused later for another hash. | |That wouldn't fulfill Requirement 2b in the draft: "The identifier must not |reveal to the receiver of it that the Call-ID, tags, or any other SIP header |or body portion have been changed by middle-boxes, with as high a |probability as possible." | |I think Laura's use-case isn't for some random monitor device introduced ad- |hoc - it's really for a permanent monitor probe. Such devices are currently |deployed in lots of service providers. They're deployed on a permanent |basis, constantly monitoring SIP traffic. So the idea would be for the |operator to install the session-id key(s) on the probes or the probe-manager |through an out-of-band method. In other words, the process of putting the |key in the monitor does not have to be elegant or defined, and isn't done |very often. | |I will ping the monitoring vendors again and see if some of them can join |this conversation, although it may be easier to get them to do it once we |get a WG for the concept... just so the mailing list they have to join will |be more focused. | |-hadriel From abegen@cisco.com Tue Jul 27 15:15:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDC793A6832 for ; Tue, 27 Jul 2010 15:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ld6gkQGCB4xQ for ; Tue, 27 Jul 2010 15:15:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DFF6B3A67F1 for ; Tue, 27 Jul 2010 15:15:11 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwFAAf3TkyrR7Ht/2dsb2JhbACTGIxRcadZmx6FNgSECYcb X-IronPort-AV: E=Sophos;i="4.55,270,1278288000"; d="scan'208";a="564708518" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 27 Jul 2010 22:15:34 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6RMFYGs022641 for ; Tue, 27 Jul 2010 22:15:34 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Jul 2010 15:15:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jul 2010 15:15:45 -0700 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540CB60046@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt Thread-Index: Acst2CjFgEWn5UiiRBSIGb4FuqD/rQ== From: "Ali C. Begen (abegen)" To: X-OriginalArrivalTime: 27 Jul 2010 22:15:34.0201 (UTC) FILETIME=[3BA4F290:01CB2DD9] Subject: Re: [dispatch] I-D Action:draft-wu-http-streaming-optimization-ps-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 22:15:12 -0000 (Responding to Gonzalo's email) I read this draft, but I won't comment on the draft here. Rather, I = would like to understand the goal(s) of this draft. HTTP streaming, as noted by the draft, has been around for some time now = and there are already multiple products available. Many groups besides = IETF have shown interest in this topic and worked towards producing = their own specs in the past year. Just last week, MPEG also joined the = club and has started evaluating the received proposals. Sure, we can discuss some of the design issues here at IETF. But, do we = want to achieve more than that? If yes, we should be aware of the time = pressure. -acbegen=20 From gonzalo.camarillo@ericsson.com Wed Jul 28 00:24:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94FE13A69B2 for ; Wed, 28 Jul 2010 00:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.781 X-Spam-Level: X-Spam-Status: No, score=-103.781 tagged_above=-999 required=5 tests=[AWL=-1.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtNwaLVAY0aU for ; Wed, 28 Jul 2010 00:24:32 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 44C503A68F2 for ; Wed, 28 Jul 2010 00:24:31 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-a3-4c4fdb459dfb Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FC.E4.06895.54BDF4C4; Wed, 28 Jul 2010 09:24:53 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jul 2010 09:24:53 +0200 Received: from [131.160.126.137] ([131.160.126.137]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 28 Jul 2010 09:24:53 +0200 Message-ID: <4C4FDB44.6070805@ericsson.com> Date: Wed, 28 Jul 2010 09:24:52 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: <04CAD96D4C5A3D48B1919248A8FE0D540CB60046@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540CB60046@xmb-sjc-215.amer.cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2010 07:24:53.0350 (UTC) FILETIME=[F8D3F860:01CB2E25] X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: [dispatch] HTTP streaming WAS (Re: I-D Action:draft-wu-http-streaming-optimization-ps-00.txt) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 07:24:34 -0000 Hi, yes, to be clear, the idea is not to only discuss this draft. The idea is to discuss what can be done in the HTTP streaming area at the IETF (I have changes the subject of this email). As Ali pointed out below, this is an important area that is advancing fast. So, we would like to get your input sooner rather than later. Thanks, Gonzalo On 28/07/2010 12:15 AM, Ali C. Begen (abegen) wrote: > (Responding to Gonzalo's email) > > I read this draft, but I won't comment on the draft here. Rather, I would like to understand the goal(s) of this draft. > > HTTP streaming, as noted by the draft, has been around for some time now and there are already multiple products available. Many groups besides IETF have shown interest in this topic and worked towards producing their own specs in the past year. Just last week, MPEG also joined the club and has started evaluating the received proposals. > > Sure, we can discuss some of the design issues here at IETF. But, do we want to achieve more than that? If yes, we should be aware of the time pressure. > > -acbegen > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Hirsalantie 11 Mobile: +358 40 702 35 35 Ericsson Fax : +358 9 299 35 35 02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.piuha.fi/~gonzalo From HKaplan@acmepacket.com Wed Jul 28 01:07:27 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47A993A6940 for ; Wed, 28 Jul 2010 01:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[AWL=-1.905, BAYES_40=-0.185, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFcD3Pyx7ceu for ; Wed, 28 Jul 2010 01:07:26 -0700 (PDT) Received: from ETMail2.acmepacket.com (host9.216.41.24.conversent.net [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id D06173A6891 for ; Wed, 28 Jul 2010 01:07:25 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Wed, 28 Jul 2010 04:07:47 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 28 Jul 2010 04:07:47 -0400 From: Hadriel Kaplan To: "dispatch@ietf.org" Date: Wed, 28 Jul 2010 04:07:48 -0400 Thread-Topic: SIPSCOTCH/session-id charter scope Thread-Index: AcsuK/fDY67OGNWcRGaDyFGxa3N08g== Message-ID: <430FC6BDED356B4C8498F634416644A92694002808@mail> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 08:07:27 -0000 Howdy, One of the objections to the currently proposed SIPSCOTCH charter is on how= one knows whether to use the same session-id or not - i.e., what defines t= he same higher layer session. =20 In particular, the following paragraph of the charter: "The definition of a higher-layer "session" of the same "message-flow" is n= ot defined by SIP when it involves a B2BUA, and is difficult to normatively= define in practice. For the purposes of this WG charter's scope, two or m= ore dialogs of a B2BUA are correlated under any conditions where correlatio= n might aid troubleshooting, by identifying them as belonging to the same h= igher-level session. Any solution documents from this working group may ex= pand or constrain the scope of their mechanism's correlation, if the workin= g group so decides." This objection was also raised on the DISPATCH mailing list thread starting= here: http://www.ietf.org/mail-archive/web/dispatch/current/msg01981.html I believe the available options to handle this issue are: 1) Defer it to the new WG's solution doc to specify. 2) Try to articulate rules in the charter for when two messages/dialogs are= part of the same "session". This was actually attempted in a previous inc= arnation of the charter, in an email thread starting here: http://www.ietf.org/mail-archive/web/dispatch/current/msg01817.html 3) Instead of defining "rules", try to enumerate examples/use-cases which a= re and are-not in scope to be the same session. Any comments/preferences? -hadriel From HKaplan@acmepacket.com Wed Jul 28 01:11:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C18743A69E5 for ; Wed, 28 Jul 2010 01:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.371 X-Spam-Level: X-Spam-Status: No, score=-2.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SofK8U3CJ95x for ; Wed, 28 Jul 2010 01:11:08 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 734EA3A69EC for ; Wed, 28 Jul 2010 01:11:08 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 28 Jul 2010 04:11:30 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 28 Jul 2010 04:11:30 -0400 From: Hadriel Kaplan To: "Muthu ArulMozhi Perumal (mperumal)" , "Paul Kyzivat (pkyzivat)" Date: Wed, 28 Jul 2010 04:11:31 -0400 Thread-Topic: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 Thread-Index: AcsqapPVh+OK8YFpQXGnQnKGiHSQ5gABOsNgAABvVUAAAJWCQADF5h7AACg1pfA= Message-ID: <430FC6BDED356B4C8498F634416644A9269400280B@mail> References: <430FC6BDED356B4C8498F634416644A91FE8964124@mail><1D062974A4845E4D8A343C65380492020332AAFB@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F3A6C@mail> <4C4882BE.3060402@cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F403B@mail> <4C499854.6030105@cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F4054@mail> <1D062974A4845E4D8A343C65380492020332B298@XMB-BGL-414.cisco.com> <430FC6BDED356B4C8498F634416644A9258D7F406A@mail> <1D062974A4845E4D8A343C65380492020332B8ED@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020332B8ED@XMB-BGL-414.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Updated: draft-kaplan-dispatch-session-id-02 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 08:11:11 -0000 > -----Original Message----- > From: Muthu ArulMozhi Perumal (mperumal) [mailto:mperumal@cisco.com] > Sent: Tuesday, July 27, 2010 9:56 AM > To: Hadriel Kaplan; Paul Kyzivat (pkyzivat) >=20 > |So the idea would be for the operator to install the session-id key(s) > |on the probes or the probe-manager through an out-of-band method. In > |other words, the process of putting the key in the monitor does not > |have to be elegant or defined, and isn't done very often. >=20 > It is hard to imagine they would be using randomly generated keys or > provisioning them on the monitor using an out-of-band mechanism on a > call-by-call basis -- seems would make it difficult for other similar > vendors to implement. > Muthu No the idea is it's the private key that is provisioned on the monitoring s= ystem, not the session-id values. The same key would be used to generate a= ll the session-id's, as per the algorithm in the draft. -hadriel From peter.musgrave@magorcorp.com Wed Jul 28 01:19:37 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31DF328C0EE for ; Wed, 28 Jul 2010 01:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.422 X-Spam-Level: X-Spam-Status: No, score=-1.422 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38SzJaRs3DvM for ; Wed, 28 Jul 2010 01:19:36 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id F3B413A69A2 for ; Wed, 28 Jul 2010 01:19:35 -0700 (PDT) Received: by wyb40 with SMTP id 40so4100717wyb.31 for ; Wed, 28 Jul 2010 01:19:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.69.202 with SMTP id a10mr10183253wbj.81.1280305197756; Wed, 28 Jul 2010 01:19:57 -0700 (PDT) Received: by 10.216.238.24 with HTTP; Wed, 28 Jul 2010 01:19:57 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A92694002808@mail> References: <430FC6BDED356B4C8498F634416644A92694002808@mail> Date: Wed, 28 Jul 2010 10:19:57 +0200 Message-ID: From: Peter Musgrave To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 08:19:37 -0000 Hi Hadriel, I guess I favour a mix of (1) and (2). I don't think a charter needs to define the rules (that's what the doc is for!) I think the issue is to ensure that the charter does not leave an opening for this to become a 'rat hole' and devolve into a long discussion about dialog correlation (which is in principle not technically possible). How about a charter statement of: "The definition of a higher-layer "session" of the same "message-flow" is not defined by SIP when it involves a B2BUA, and is difficult to normatively define in practice. =A0For the purposes of this WG charter's scope, simple rules for conveyance of session-ID will be defined for the common cases of through calls, forked calls, Refer and Join. These rules will be selected based on maximizing their value to troubleshooting in the common cases. " Peter Musgrave On Wed, Jul 28, 2010 at 10:07 AM, Hadriel Kaplan w= rote: > Howdy, > One of the objections to the currently proposed SIPSCOTCH charter is on h= ow one knows whether to use the same session-id or not - i.e., what defines= the same higher layer session. > > In particular, the following paragraph of the charter: > "The definition of a higher-layer "session" of the same "message-flow" is= not defined by SIP when it involves a B2BUA, and is difficult to normative= ly define in practice. =A0For the purposes of this WG charter's scope, two = or more dialogs of a B2BUA are correlated under any conditions where correl= ation might aid troubleshooting, by identifying them as belonging to the sa= me higher-level session. =A0Any solution documents from this working group = may expand or constrain the scope of their mechanism's correlation, if the = working group so decides." > > This objection was also raised on the DISPATCH mailing list thread starti= ng here: > http://www.ietf.org/mail-archive/web/dispatch/current/msg01981.html > > > I believe the available options to handle this issue are: > > 1) Defer it to the new WG's solution doc to specify. > > 2) Try to articulate rules in the charter for when two messages/dialogs a= re part of the same "session". =A0This was actually attempted in a previous= incarnation of the charter, in an email thread starting here: > http://www.ietf.org/mail-archive/web/dispatch/current/msg01817.html > > 3) Instead of defining "rules", try to enumerate examples/use-cases which= are and are-not in scope to be the same session. > > Any comments/preferences? > > -hadriel > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From tme@americafree.tv Wed Jul 28 03:07:31 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0149228C124 for ; Wed, 28 Jul 2010 03:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRKXmDDJt1HW for ; Wed, 28 Jul 2010 03:07:29 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id B05CB28C13E for ; Wed, 28 Jul 2010 03:07:28 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 1DB88821AD6F; Wed, 28 Jul 2010 06:07:48 -0400 (EDT) Message-Id: <127E0124-0E68-4295-B65D-E792B26DCF68@americafree.tv> From: Marshall Eubanks To: Marshall Eubanks In-Reply-To: <368EAE3E-191E-479B-B8B1-1D0874DFDA9F@americafree.tv> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 28 Jul 2010 06:07:46 -0400 References: <368EAE3E-191E-479B-B8B1-1D0874DFDA9F@americafree.tv> X-Mailer: Apple Mail (2.936) Cc: DISPATCH list , bernie@ucom.ch Subject: Re: [dispatch] Possible bar bof on a global videoconferencing / telepresence directory ? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 10:07:31 -0000 Hello; I am sorry, but the wiki is incorrect. This Bar Bof is STILL for tomorrow. Regards Marshall On Jul 25, 2010, at 10:25 PM, Marshall Eubanks wrote: > Based on the doodle, I think that this should be Thursday at lunch > and (although I would love to hear any other suggestions) we > probably should just get a lunch at the MECC. > > I have invited Bernie Hoeneisen, the ENUM chair. > > Regards > Marshall > > On Jul 23, 2010, at 12:04 PM, Marshall Eubanks wrote: > >> Well, we got a little interest, so I set up a Doodle poll : >> >> http://www.doodle.com/424zcx6iqicfy8nz >> >> If you are interested, please select one or more times. As before, >> use green for prefer, yellow for OK, red for can't make it. >> >> Regards >> >> Marshall >> >> On Jul 22, 2010, at 11:12 AM, Marshall Eubanks wrote: >> >>> Something that I have been giving a lot of thought to recently is >>> how to establish a global directory for videoconferencing and >>> telepresence, and whether this should be based on / derived from >>> ENUM. >>> >>> So, I am wondering if >>> >>> - there are others here interested in this same topic and >>> - whether or not we should get together briefly for a "bar bof" or >>> an even more informal meeting in Maastricht. >>> >>> So, if this subject interests you, please respond to this email. >>> If there is interest, I will set up a quick doodle. >>> >>> Regards >>> Marshall >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> > > From laura.liess.dt@googlemail.com Wed Jul 28 07:19:59 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE543A6958 for ; Wed, 28 Jul 2010 07:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfCa6NTzPu3g for ; Wed, 28 Jul 2010 07:19:58 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 8185F3A694A for ; Wed, 28 Jul 2010 07:19:57 -0700 (PDT) Received: by ewy22 with SMTP id 22so1939637ewy.31 for ; Wed, 28 Jul 2010 07:20:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=YBvgHJGOhHHqGUkfDoHxDJjC69svMEsePGHwVdZX8EE=; b=HRciPExCGikmh8VQGL3l0CJR0cv1f972KTEM5mfPScLaDk0ZiTdmVYdg8s4xNCMzsF XN7lldl06lFYkHE9A3d2dWsiXonwYjomtG12iBTlIFX7fuU9ZY0BLZHi5arwD4RFOSnx z8U6ZuZxhLSfLvPx7C5IVlpuNkFV7McAgh1No= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=Dn/8EMlIG9JujJCvbWyCabnBpuMG9hp219Ri9XZEOVXivNmWK6/5+Tq0MVLaeRj05k 2qwc6TZWqNZyVxsZYPOjWrkCf7sJ43Xx4yOKcBC3RfQMnp9IShMH04vIwdsLqY3ewNZj Fo+VEZWBDGbYy0Th6U+I9cqnsx2v5hpo+RckA= Received: by 10.14.47.69 with SMTP id s45mr2238052eeb.10.1280326816048; Wed, 28 Jul 2010 07:20:16 -0700 (PDT) Received: from LauraLiess (dhcp-87d8.meeting.ietf.org [130.129.135.216]) by mx.google.com with ESMTPS id a48sm9584570eei.13.2010.07.28.07.20.14 (version=SSLv3 cipher=RC4-MD5); Wed, 28 Jul 2010 07:20:15 -0700 (PDT) From: Laura Liess To: "'Peter Musgrave'" , "'Hadriel Kaplan'" References: <430FC6BDED356B4C8498F634416644A92694002808@mail> In-Reply-To: Date: Wed, 28 Jul 2010 16:20:14 +0200 Message-ID: <4c503c9f.487e0e0a.19fc.3621@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsuLbCDaimCGOjGTzKvhCIh0xtmngAJDlYA Content-Language: de Cc: dispatch@ietf.org Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 14:19:59 -0000 +1 I fully agree with Peter's text proposal. From my point of view, the correlation rules are part of the problem we need to solve in the WG. We = can not state the rules in the charter, we can state that the WG should = define such rules. And because it may be not possible to define clear general = rules working for the most general case, the proposal to define rules for the common use cases seems quite reasonable to me.=20 Thanks a lot, Laura > -----Urspr=FCngliche Nachricht----- > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im > Auftrag von Peter Musgrave > Gesendet: Mittwoch, 28. Juli 2010 10:20 > An: Hadriel Kaplan > Cc: dispatch@ietf.org > Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope >=20 > Hi Hadriel, >=20 > I guess I favour a mix of (1) and (2). I don't think a charter needs > to define the rules (that's what the doc is for!) I think the issue is > to ensure that the charter does not leave an opening for this to > become a 'rat hole' and devolve into a long discussion about dialog > correlation (which is in principle not technically possible). >=20 > How about a charter statement of: > "The definition of a higher-layer "session" of the same "message-flow" > is not defined by SIP when it involves a B2BUA, and is difficult to > normatively define in practice. =A0For the purposes of this WG = charter's > scope, simple rules for conveyance of session-ID will be defined for > the common cases of through calls, forked calls, Refer and Join. These > rules will be selected based on maximizing their value to > troubleshooting in the common cases. " >=20 >=20 > Peter Musgrave >=20 > On Wed, Jul 28, 2010 at 10:07 AM, Hadriel Kaplan > wrote: > > Howdy, > > One of the objections to the currently proposed SIPSCOTCH charter is > on how one knows whether to use the same session-id or not - i.e., = what > defines the same higher layer session. > > > > In particular, the following paragraph of the charter: > > "The definition of a higher-layer "session" of the same "message- > flow" is not defined by SIP when it involves a B2BUA, and is difficult > to normatively define in practice. =A0For the purposes of this WG > charter's scope, two or more dialogs of a B2BUA are correlated under > any conditions where correlation might aid troubleshooting, by > identifying them as belonging to the same higher-level session. =A0Any > solution documents from this working group may expand or constrain the > scope of their mechanism's correlation, if the working group so > decides." > > > > This objection was also raised on the DISPATCH mailing list thread > starting here: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg01981.html > > > > > > I believe the available options to handle this issue are: > > > > 1) Defer it to the new WG's solution doc to specify. > > > > 2) Try to articulate rules in the charter for when two > messages/dialogs are part of the same "session". =A0This was actually > attempted in a previous incarnation of the charter, in an email thread > starting here: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg01817.html > > > > 3) Instead of defining "rules", try to enumerate examples/use-cases > which are and are-not in scope to be the same session. > > > > Any comments/preferences? > > > > -hadriel > > _______________________________________________ > > 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 john.elwell@siemens-enterprise.com Wed Jul 28 07:46:54 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84AAF28C154 for ; Wed, 28 Jul 2010 07:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZglCbZkdNAW for ; Wed, 28 Jul 2010 07:46:53 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 1A3023A6949 for ; Wed, 28 Jul 2010 07:46:52 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-996257; Wed, 28 Jul 2010 16:47:14 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id A420323F0278; Wed, 28 Jul 2010 16:47:14 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 28 Jul 2010 16:47:14 +0200 From: "Elwell, John" To: Laura Liess , 'Peter Musgrave' , 'Hadriel Kaplan' Date: Wed, 28 Jul 2010 16:47:13 +0200 Thread-Topic: [dispatch] SIPSCOTCH/session-id charter scope Thread-Index: AcsuLbCDaimCGOjGTzKvhCIh0xtmngAJDlYAAARy3FA= Message-ID: References: <430FC6BDED356B4C8498F634416644A92694002808@mail> <4c503c9f.487e0e0a.19fc.3621@mx.google.com> In-Reply-To: <4c503c9f.487e0e0a.19fc.3621@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 14:46:54 -0000 +1 John=20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Laura Liess > Sent: 28 July 2010 15:20 > To: 'Peter Musgrave'; 'Hadriel Kaplan' > Cc: dispatch@ietf.org > Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope >=20 >=20 > +1 > I fully agree with Peter's text proposal. From my point of view, the > correlation rules are part of the problem we need to solve in=20 > the WG. We can > not state the rules in the charter, we can state that the WG=20 > should define > such rules. And because it may be not possible to define=20 > clear general rules > working for the most general case, the proposal to define=20 > rules for the > common use cases seems quite reasonable to me.=20 >=20 > Thanks a lot, > Laura >=20 >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im > > Auftrag von Peter Musgrave > > Gesendet: Mittwoch, 28. Juli 2010 10:20 > > An: Hadriel Kaplan > > Cc: dispatch@ietf.org > > Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope > >=20 > > Hi Hadriel, > >=20 > > I guess I favour a mix of (1) and (2). I don't think a charter needs > > to define the rules (that's what the doc is for!) I think=20 > the issue is > > to ensure that the charter does not leave an opening for this to > > become a 'rat hole' and devolve into a long discussion about dialog > > correlation (which is in principle not technically possible). > >=20 > > How about a charter statement of: > > "The definition of a higher-layer "session" of the same=20 > "message-flow" > > is not defined by SIP when it involves a B2BUA, and is difficult to > > normatively define in practice. =A0For the purposes of this=20 > WG charter's > > scope, simple rules for conveyance of session-ID will be defined for > > the common cases of through calls, forked calls, Refer and=20 > Join. These > > rules will be selected based on maximizing their value to > > troubleshooting in the common cases. " > >=20 > >=20 > > Peter Musgrave > >=20 > > On Wed, Jul 28, 2010 at 10:07 AM, Hadriel Kaplan > > wrote: > > > Howdy, > > > One of the objections to the currently proposed SIPSCOTCH=20 > charter is > > on how one knows whether to use the same session-id or not=20 > - i.e., what > > defines the same higher layer session. > > > > > > In particular, the following paragraph of the charter: > > > "The definition of a higher-layer "session" of the same "message- > > flow" is not defined by SIP when it involves a B2BUA, and=20 > is difficult > > to normatively define in practice. =A0For the purposes of this WG > > charter's scope, two or more dialogs of a B2BUA are correlated under > > any conditions where correlation might aid troubleshooting, by > > identifying them as belonging to the same higher-level session. =A0Any > > solution documents from this working group may expand or=20 > constrain the > > scope of their mechanism's correlation, if the working group so > > decides." > > > > > > This objection was also raised on the DISPATCH mailing list thread > > starting here: > > >=20 > http://www.ietf.org/mail-archive/web/dispatch/current/msg01981.html > > > > > > > > > I believe the available options to handle this issue are: > > > > > > 1) Defer it to the new WG's solution doc to specify. > > > > > > 2) Try to articulate rules in the charter for when two > > messages/dialogs are part of the same "session". =A0This was actually > > attempted in a previous incarnation of the charter, in an=20 > email thread > > starting here: > > >=20 > http://www.ietf.org/mail-archive/web/dispatch/current/msg01817.html > > > > > > 3) Instead of defining "rules", try to enumerate=20 > examples/use-cases > > which are and are-not in scope to be the same session. > > > > > > Any comments/preferences? > > > > > > -hadriel > > > _______________________________________________ > > > 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From R.Jesske@telekom.de Wed Jul 28 07:50:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D63213A6949 for ; Wed, 28 Jul 2010 07:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.724 X-Spam-Level: X-Spam-Status: No, score=-3.724 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7X6VYe566-s for ; Wed, 28 Jul 2010 07:50:41 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id F06AF28C18C for ; Wed, 28 Jul 2010 07:50:40 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 28 Jul 2010 16:51:00 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Jul 2010 16:50:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Jul 2010 16:50:58 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD406631CA9@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <4c503c9f.487e0e0a.19fc.3621@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIPSCOTCH/session-id charter scope Thread-Index: AcsuLbCDaimCGOjGTzKvhCIh0xtmngAJDlYAAASRlhA= References: <430FC6BDED356B4C8498F634416644A92694002808@mail> <4c503c9f.487e0e0a.19fc.3621@mx.google.com> From: To: , , X-OriginalArrivalTime: 28 Jul 2010 14:50:59.0424 (UTC) FILETIME=[4AA6BE00:01CB2E64] Cc: dispatch@ietf.org Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 14:50:42 -0000 +1 I support this too. Best Regards Roland=20 -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Laura Liess Gesendet: Mittwoch, 28. Juli 2010 16:20 An: 'Peter Musgrave'; 'Hadriel Kaplan' Cc: dispatch@ietf.org Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope +1 I fully agree with Peter's text proposal. From my point of view, the correlation rules are part of the problem we need to solve in the WG. We = can not state the rules in the charter, we can state that the WG should = define such rules. And because it may be not possible to define clear general = rules working for the most general case, the proposal to define rules for the common use cases seems quite reasonable to me.=20 Thanks a lot, Laura > -----Urspr=FCngliche Nachricht----- > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im > Auftrag von Peter Musgrave > Gesendet: Mittwoch, 28. Juli 2010 10:20 > An: Hadriel Kaplan > Cc: dispatch@ietf.org > Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope >=20 > Hi Hadriel, >=20 > I guess I favour a mix of (1) and (2). I don't think a charter needs > to define the rules (that's what the doc is for!) I think the issue is > to ensure that the charter does not leave an opening for this to > become a 'rat hole' and devolve into a long discussion about dialog > correlation (which is in principle not technically possible). >=20 > How about a charter statement of: > "The definition of a higher-layer "session" of the same "message-flow" > is not defined by SIP when it involves a B2BUA, and is difficult to > normatively define in practice. =A0For the purposes of this WG = charter's > scope, simple rules for conveyance of session-ID will be defined for > the common cases of through calls, forked calls, Refer and Join. These > rules will be selected based on maximizing their value to > troubleshooting in the common cases. " >=20 >=20 > Peter Musgrave >=20 > On Wed, Jul 28, 2010 at 10:07 AM, Hadriel Kaplan > wrote: > > Howdy, > > One of the objections to the currently proposed SIPSCOTCH charter is > on how one knows whether to use the same session-id or not - i.e., = what > defines the same higher layer session. > > > > In particular, the following paragraph of the charter: > > "The definition of a higher-layer "session" of the same "message- > flow" is not defined by SIP when it involves a B2BUA, and is difficult > to normatively define in practice. =A0For the purposes of this WG > charter's scope, two or more dialogs of a B2BUA are correlated under > any conditions where correlation might aid troubleshooting, by > identifying them as belonging to the same higher-level session. =A0Any > solution documents from this working group may expand or constrain the > scope of their mechanism's correlation, if the working group so > decides." > > > > This objection was also raised on the DISPATCH mailing list thread > starting here: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg01981.html > > > > > > I believe the available options to handle this issue are: > > > > 1) Defer it to the new WG's solution doc to specify. > > > > 2) Try to articulate rules in the charter for when two > messages/dialogs are part of the same "session". =A0This was actually > attempted in a previous incarnation of the charter, in an email thread > starting here: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg01817.html > > > > 3) Instead of defining "rules", try to enumerate examples/use-cases > which are and are-not in scope to be the same session. > > > > Any comments/preferences? > > > > -hadriel > > _______________________________________________ > > 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 victor.pascual.avila@gmail.com Wed Jul 28 08:01:10 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 278C23A6949 for ; Wed, 28 Jul 2010 08:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPCs5uRzKnju for ; Wed, 28 Jul 2010 08:01:08 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 9C62F3A699E for ; Wed, 28 Jul 2010 08:01:07 -0700 (PDT) Received: by bwz7 with SMTP id 7so4725178bwz.31 for ; Wed, 28 Jul 2010 08:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q0HnAeZd9O9Aev0inBoPTXlHO5a7jqI/0C8gwRteNoA=; b=WgOH8g+ijaupCqxPjvzCL7ngUn0x44fDwMsvT/AgYO9sv7ZKOKlaaZzNTGknxzmfqL i02ZpaGKXgaYO8NEdc4QJ3U4VCZF6iEMhSJV0RfRUXHIcBgLhZNDmLJfVtet9+rVm6I1 V78EMyBYGSR/+0u4cauEfsgGYJaiY3+qw0pbI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=x338ziWdezj17LQl6yiet/w3hSNz0B0yVKOSQQbLq40d/fKXfOB1uTLTOSqAnzuJc6 FL8ks1PNXQZdSRlwS6R1XseFpfVT5TZ8ZuotlrYDsjsc+LOOzw5aJxAIasf84YUgs03h TUa3VWgmwaPtMcIswLUGcnltjcjn3454c4534= MIME-Version: 1.0 Received: by 10.204.46.23 with SMTP id h23mr8063620bkf.75.1280329289814; Wed, 28 Jul 2010 08:01:29 -0700 (PDT) Received: by 10.204.25.131 with HTTP; Wed, 28 Jul 2010 08:01:29 -0700 (PDT) In-Reply-To: <9886E5FCA6D76549A3011068483A4BD406631CA9@S4DE8PSAAQB.mitte.t-com.de> References: <430FC6BDED356B4C8498F634416644A92694002808@mail> <4c503c9f.487e0e0a.19fc.3621@mx.google.com> <9886E5FCA6D76549A3011068483A4BD406631CA9@S4DE8PSAAQB.mitte.t-com.de> Date: Wed, 28 Jul 2010 17:01:29 +0200 Message-ID: From: Victor Pascual Avila To: R.Jesske@telekom.de Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org, HKaplan@acmepacket.com Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 15:01:10 -0000 +1 On Wed, Jul 28, 2010 at 4:50 PM, wrote: > +1 > I support this too. > > Best Regards > > Roland > > > > -----Urspr=C3=BCngliche Nachricht----- > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im Auft= rag von Laura Liess > Gesendet: Mittwoch, 28. Juli 2010 16:20 > An: 'Peter Musgrave'; 'Hadriel Kaplan' > Cc: dispatch@ietf.org > Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope > > > +1 > I fully agree with Peter's text proposal. From my point of view, the > correlation rules are part of the problem we need to solve in the WG. We = can > not state the rules in the charter, we can state that the WG should defin= e > such rules. And because it may be not possible to define clear general ru= les > working for the most general case, the proposal to define rules for the > common use cases seems quite reasonable to me. > > Thanks =C2=A0a lot, > Laura > > > >> -----Urspr=C3=BCngliche Nachricht----- >> Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im >> Auftrag von Peter Musgrave >> Gesendet: Mittwoch, 28. Juli 2010 10:20 >> An: Hadriel Kaplan >> Cc: dispatch@ietf.org >> Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope >> >> Hi Hadriel, >> >> I guess I favour a mix of (1) and (2). I don't think a charter needs >> to define the rules (that's what the doc is for!) I think the issue is >> to ensure that the charter does not leave an opening for this to >> become a 'rat hole' and devolve into a long discussion about dialog >> correlation (which is in principle not technically possible). >> >> How about a charter statement of: >> "The definition of a higher-layer "session" of the same "message-flow" >> is not defined by SIP when it involves a B2BUA, and is difficult to >> normatively define in practice. =C2=A0For the purposes of this WG charte= r's >> scope, simple rules for conveyance of session-ID will be defined for >> the common cases of through calls, forked calls, Refer and Join. These >> rules will be selected based on maximizing their value to >> troubleshooting in the common cases. " >> >> >> Peter Musgrave >> >> On Wed, Jul 28, 2010 at 10:07 AM, Hadriel Kaplan >> wrote: >> > Howdy, >> > One of the objections to the currently proposed SIPSCOTCH charter is >> on how one knows whether to use the same session-id or not - i.e., what >> defines the same higher layer session. >> > >> > In particular, the following paragraph of the charter: >> > "The definition of a higher-layer "session" of the same "message- >> flow" is not defined by SIP when it involves a B2BUA, and is difficult >> to normatively define in practice. =C2=A0For the purposes of this WG >> charter's scope, two or more dialogs of a B2BUA are correlated under >> any conditions where correlation might aid troubleshooting, by >> identifying them as belonging to the same higher-level session. =C2=A0An= y >> solution documents from this working group may expand or constrain the >> scope of their mechanism's correlation, if the working group so >> decides." >> > >> > This objection was also raised on the DISPATCH mailing list thread >> starting here: >> > http://www.ietf.org/mail-archive/web/dispatch/current/msg01981.html >> > >> > >> > I believe the available options to handle this issue are: >> > >> > 1) Defer it to the new WG's solution doc to specify. >> > >> > 2) Try to articulate rules in the charter for when two >> messages/dialogs are part of the same "session". =C2=A0This was actually >> attempted in a previous incarnation of the charter, in an email thread >> starting here: >> > http://www.ietf.org/mail-archive/web/dispatch/current/msg01817.html >> > >> > 3) Instead of defining "rules", try to enumerate examples/use-cases >> which are and are-not in scope to be the same session. >> > >> > Any comments/preferences? >> > >> > -hadriel >> > _______________________________________________ >> > 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 > --=20 Victor Pascual =C3=81vila From partr@cisco.com Wed Jul 28 14:45:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8617A3A6885 for ; Wed, 28 Jul 2010 14:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.657 X-Spam-Level: X-Spam-Status: No, score=-9.657 tagged_above=-999 required=5 tests=[AWL=0.942, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsJJKHWE3sF9 for ; Wed, 28 Jul 2010 14:45:02 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6B1293A6866 for ; Wed, 28 Jul 2010 14:45:02 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAH9BUExAaHte/2dsb2JhbACgCHGoU5sAhTYEhAyHIAwB Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-2.cisco.com with ESMTP; 28 Jul 2010 21:45:24 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6SLjNCe022944; Wed, 28 Jul 2010 21:45:24 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Jul 2010 03:15:23 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Jul 2010 03:13:20 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIPSCOTCH/session-id charter scope Thread-Index: AcsuZdOoW0Wyc5w7TomSsKFGpxRDmwANYO5w References: <430FC6BDED356B4C8498F634416644A92694002808@mail><4c503c9f.487e0e0a.19fc.3621@mx.google.com><9886E5FCA6D76549A3011068483A4BD406631CA9@S4DE8PSAAQB.mitte.t-com.de> From: "Parthasarathi R (partr)" To: "Victor Pascual Avila" , X-OriginalArrivalTime: 28 Jul 2010 21:45:23.0999 (UTC) FILETIME=[2F17CAF0:01CB2E9E] Cc: dispatch@ietf.org, HKaplan@acmepacket.com Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 21:45:03 -0000 Hadriel, Session is a misnomer as it may be related to two or more dialogs depend = upon the B2BUA, Focus behavior. As you mentioned in point 3, it is = better to focus on the complex use cases document where the = troubleshooting is really tough in the SIP networks. Existing 3PCC, = BLISS callflow, conference callflow shall be referenced. The common = industry standard call services like Call transfer, call hold shall be = added as usecase. This will help in creating the clear session-id = charter.=20 I'm sort of thinking that B2BUA will not abuse this session-id but SBC = *may*. =20 Thanks Partha -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Victor Pascual Avila Sent: Wednesday, July 28, 2010 8:31 PM To: R.Jesske@telekom.de Cc: dispatch@ietf.org; HKaplan@acmepacket.com Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope +1 On Wed, Jul 28, 2010 at 4:50 PM, wrote: > +1 > I support this too. > > Best Regards > > Roland > > > > -----Urspr=FCngliche Nachricht----- > Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im=20 > Auftrag von Laura Liess > Gesendet: Mittwoch, 28. Juli 2010 16:20 > An: 'Peter Musgrave'; 'Hadriel Kaplan' > Cc: dispatch@ietf.org > Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope > > > +1 > I fully agree with Peter's text proposal. From my point of view, the=20 > correlation rules are part of the problem we need to solve in the WG.=20 > We can not state the rules in the charter, we can state that the WG=20 > should define such rules. And because it may be not possible to define = > clear general rules working for the most general case, the proposal to = > define rules for the common use cases seems quite reasonable to me. > > Thanks =A0a lot, > Laura > > > >> -----Urspr=FCngliche Nachricht----- >> Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im=20 >> Auftrag von Peter Musgrave >> Gesendet: Mittwoch, 28. Juli 2010 10:20 >> An: Hadriel Kaplan >> Cc: dispatch@ietf.org >> Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope >> >> Hi Hadriel, >> >> I guess I favour a mix of (1) and (2). I don't think a charter needs=20 >> to define the rules (that's what the doc is for!) I think the issue=20 >> is to ensure that the charter does not leave an opening for this to=20 >> become a 'rat hole' and devolve into a long discussion about dialog=20 >> correlation (which is in principle not technically possible). >> >> How about a charter statement of: >> "The definition of a higher-layer "session" of the same = "message-flow" >> is not defined by SIP when it involves a B2BUA, and is difficult to=20 >> normatively define in practice. =A0For the purposes of this WG=20 >> charter's scope, simple rules for conveyance of session-ID will be=20 >> defined for the common cases of through calls, forked calls, Refer=20 >> and Join. These rules will be selected based on maximizing their=20 >> value to troubleshooting in the common cases. " >> >> >> Peter Musgrave >> >> On Wed, Jul 28, 2010 at 10:07 AM, Hadriel Kaplan=20 >> wrote: >> > Howdy, >> > One of the objections to the currently proposed SIPSCOTCH charter=20 >> > is >> on how one knows whether to use the same session-id or not - i.e.,=20 >> what defines the same higher layer session. >> > >> > In particular, the following paragraph of the charter: >> > "The definition of a higher-layer "session" of the same "message- >> flow" is not defined by SIP when it involves a B2BUA, and is=20 >> difficult to normatively define in practice. =A0For the purposes of=20 >> this WG charter's scope, two or more dialogs of a B2BUA are=20 >> correlated under any conditions where correlation might aid=20 >> troubleshooting, by identifying them as belonging to the same=20 >> higher-level session. =A0Any solution documents from this working = group=20 >> may expand or constrain the scope of their mechanism's correlation,=20 >> if the working group so decides." >> > >> > This objection was also raised on the DISPATCH mailing list thread >> starting here: >> > http://www.ietf.org/mail-archive/web/dispatch/current/msg01981.html >> > >> > >> > I believe the available options to handle this issue are: >> > >> > 1) Defer it to the new WG's solution doc to specify. >> > >> > 2) Try to articulate rules in the charter for when two >> messages/dialogs are part of the same "session". =A0This was actually = >> attempted in a previous incarnation of the charter, in an email=20 >> thread starting here: >> > http://www.ietf.org/mail-archive/web/dispatch/current/msg01817.html >> > >> > 3) Instead of defining "rules", try to enumerate examples/use-cases >> which are and are-not in scope to be the same session. >> > >> > Any comments/preferences? >> > >> > -hadriel >> > _______________________________________________ >> > 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 > -- Victor Pascual =C1vila _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From gao.yang2@zte.com.cn Wed Jul 28 17:50:18 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A53B128C181 for ; Wed, 28 Jul 2010 17:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.894 X-Spam-Level: X-Spam-Status: No, score=-99.894 tagged_above=-999 required=5 tests=[AWL=1.944, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m33cGR1jhOcd for ; Wed, 28 Jul 2010 17:50:17 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 114C03A67F7 for ; Wed, 28 Jul 2010 17:50:16 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 3510992332426; Thu, 29 Jul 2010 08:49:56 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 83990.2898723675; Thu, 29 Jul 2010 08:50:36 +0800 (CST) Received: from notes_svr7_1.zte.com.cn ([10.30.1.248]) by mse2.zte.com.cn with ESMTP id o6T0o7ke061922; Thu, 29 Jul 2010 08:50:25 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: dispatch@ietf.org, peter.musgrave@magorcorp.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 29 Jul 2010 08:48:53 +0800 X-MIMETrack: Serialize by Router on notes_svr7_1/zte_ltd(Release 8.5.1FP2|March 17, 2010) at 2010-07-29 08:47:09, Serialize complete at 2010-07-29 08:47:09 Content-Type: multipart/alternative; boundary="=_alternative 000486874825776F_=" X-MAIL: mse2.zte.com.cn o6T0o7ke061922 Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 00:50:18 -0000 This is a multipart message in MIME format. --=_alternative 000486874825776F_= Content-Type: text/plain; charset="US-ASCII" Hi Peter Musgrave > How about a charter statement of: > "The definition of a higher-layer "session" of the same "message-flow" > is not defined by SIP when it involves a B2BUA, and is difficult to > normatively define in practice. For the purposes of this WG charter's > scope, simple rules for conveyance of session-ID will be defined for > the common cases of through calls, forked calls, Refer and Join. I'd like to check that do you mean "UPDATE RFC3891" about REFER here? > There rules will be selected based on maximizing their value to > troubleshooting in the common cases. " Thanks, Gao -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000486874825776F_= Content-Type: text/html; charset="US-ASCII"
Hi Peter Musgrave

> How about a charter statement of:
> "The definition of a higher-layer "session" of the same "message-flow"
> is not defined by SIP when it involves a B2BUA, and is difficult to
> normatively define in practice.  For the purposes of this WG charter's
> scope, simple rules for conveyance of session-ID will be defined for
> the common cases of through calls, forked calls, Refer and Join.

I'd like to check that do you mean "UPDATE RFC3891" about REFER here?

> There rules will be selected based on maximizing their value to
> troubleshooting in the common cases. "

Thanks,

Gao 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000486874825776F_=-- From peter.musgrave@magorcorp.com Wed Jul 28 22:34:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DBAA3A6817 for ; Wed, 28 Jul 2010 22:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvR91WfJQb0q for ; Wed, 28 Jul 2010 22:34:31 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 5AFD53A67E7 for ; Wed, 28 Jul 2010 22:34:30 -0700 (PDT) Received: by ywa8 with SMTP id 8so98442ywa.31 for ; Wed, 28 Jul 2010 22:34:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.13.12 with SMTP id q12mr445612ybi.229.1280381683671; Wed, 28 Jul 2010 22:34:43 -0700 (PDT) Received: by 10.229.20.198 with HTTP; Wed, 28 Jul 2010 22:34:43 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Jul 2010 07:34:43 +0200 Message-ID: From: Peter Musgrave To: gao.yang2@zte.com.cn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 05:34:32 -0000 Hi Gao, I mean the REFER method (RFC3515). Peter On Thu, Jul 29, 2010 at 2:48 AM, wrote: > > Hi Peter Musgrave > >> How about a charter statement of: >> "The definition of a higher-layer "session" of the same "message-flow" >> is not defined by SIP when it involves a B2BUA, and is difficult to >> normatively define in practice. =A0For the purposes of this WG charter's >> scope, simple rules for conveyance of session-ID will be defined for >> the common cases of through calls, forked calls, Refer and Join. > > I'd like to check that do you mean "UPDATE RFC3891" about REFER here? > >> There rules will be selected based on maximizing their value to >> troubleshooting in the common cases. " > > Thanks, > > Gao > > -------------------------------------------------------- > ZTE=A0Information=A0Security=A0Notice:=A0The=A0information=A0contained=A0= in=A0this=A0mail=A0is=A0solely=A0property=A0of=A0the=A0sender's=A0organizat= ion.=A0This=A0mail=A0communication=A0is=A0confidential.=A0Recipients=A0name= d=A0above=A0are=A0obligated=A0to=A0maintain=A0secrecy=A0and=A0are=A0not=A0p= ermitted=A0to=A0disclose=A0the=A0contents=A0of=A0this=A0communication=A0to= =A0others. > This=A0email=A0and=A0any=A0files=A0transmitted=A0with=A0it=A0are=A0confid= ential=A0and=A0intended=A0solely=A0for=A0the=A0use=A0of=A0the=A0individual= =A0or=A0entity=A0to=A0whom=A0they=A0are=A0addressed.=A0If=A0you=A0have=A0re= ceived=A0this=A0email=A0in=A0error=A0please=A0notify=A0the=A0originator=A0o= f=A0the=A0message.=A0Any=A0views=A0expressed=A0in=A0this=A0message=A0are=A0= those=A0of=A0the=A0individual=A0sender. > This=A0message=A0has=A0been=A0scanned=A0for=A0viruses=A0and=A0Spam=A0by= =A0ZTE=A0Anti-Spam=A0system. > From peter.musgrave@magorcorp.com Wed Jul 28 22:39:01 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD463A67C2 for ; Wed, 28 Jul 2010 22:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnVLLvyFu4d0 for ; Wed, 28 Jul 2010 22:38:59 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 6294D3A63EC for ; Wed, 28 Jul 2010 22:38:59 -0700 (PDT) Received: by gyg8 with SMTP id 8so96582gyg.31 for ; Wed, 28 Jul 2010 22:39:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.186.15 with SMTP id n15mr12806044anp.171.1280381962654; Wed, 28 Jul 2010 22:39:22 -0700 (PDT) Received: by 10.229.20.198 with HTTP; Wed, 28 Jul 2010 22:39:22 -0700 (PDT) In-Reply-To: References: <430FC6BDED356B4C8498F634416644A92694002808@mail> <4c503c9f.487e0e0a.19fc.3621@mx.google.com> <9886E5FCA6D76549A3011068483A4BD406631CA9@S4DE8PSAAQB.mitte.t-com.de> Date: Thu, 29 Jul 2010 07:39:22 +0200 Message-ID: From: Peter Musgrave To: "Parthasarathi R (partr)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: dispatch@ietf.org, HKaplan@acmepacket.com, R.Jesske@telekom.de Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 05:39:01 -0000 HI Partha, I think is better to focus on the common use cases (whether they are complex or simple). IMHO the majority of them are usually not more complicated than a REFER. I think as part of the doc review we can evaluate cases from 3PCC and BLISS callflow examples and see what interest there is them. I do not see the need to make this specific in the charter. I think (to channel JDR) "Let's not let the perfect be the enemy of the good". I think the existing charter text does discusses the mechanics (REFER, forking) which are basic to SIP and the specific use cases can be discussed in the contexts you are suggesting without a change to the charter text I suggested. Peter On Wed, Jul 28, 2010 at 11:43 PM, Parthasarathi R (partr) wrote: > Hadriel, > > Session is a misnomer as it may be related to two or more dialogs depend = upon the B2BUA, Focus behavior. As you mentioned in point 3, it is better t= o focus on the complex use cases document where the troubleshooting is real= ly tough in the SIP networks. Existing 3PCC, BLISS callflow, conference cal= lflow shall be referenced. The common industry standard call services like = Call transfer, call hold shall be added as usecase. This will help in creat= ing the clear session-id charter. > > I'm sort of thinking that B2BUA will not abuse this session-id but SBC *m= ay*. > > Thanks > Partha > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf Of Victor Pascual Avila > Sent: Wednesday, July 28, 2010 8:31 PM > To: R.Jesske@telekom.de > Cc: dispatch@ietf.org; HKaplan@acmepacket.com > Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope > > +1 > > On Wed, Jul 28, 2010 at 4:50 PM, =A0 wrote: >> +1 >> I support this too. >> >> Best Regards >> >> Roland >> >> >> >> -----Urspr=FCngliche Nachricht----- >> Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im >> Auftrag von Laura Liess >> Gesendet: Mittwoch, 28. Juli 2010 16:20 >> An: 'Peter Musgrave'; 'Hadriel Kaplan' >> Cc: dispatch@ietf.org >> Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope >> >> >> +1 >> I fully agree with Peter's text proposal. From my point of view, the >> correlation rules are part of the problem we need to solve in the WG. >> We can not state the rules in the charter, we can state that the WG >> should define such rules. And because it may be not possible to define >> clear general rules working for the most general case, the proposal to >> define rules for the common use cases seems quite reasonable to me. >> >> Thanks =A0a lot, >> Laura >> >> >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im >>> Auftrag von Peter Musgrave >>> Gesendet: Mittwoch, 28. Juli 2010 10:20 >>> An: Hadriel Kaplan >>> Cc: dispatch@ietf.org >>> Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope >>> >>> Hi Hadriel, >>> >>> I guess I favour a mix of (1) and (2). I don't think a charter needs >>> to define the rules (that's what the doc is for!) I think the issue >>> is to ensure that the charter does not leave an opening for this to >>> become a 'rat hole' and devolve into a long discussion about dialog >>> correlation (which is in principle not technically possible). >>> >>> How about a charter statement of: >>> "The definition of a higher-layer "session" of the same "message-flow" >>> is not defined by SIP when it involves a B2BUA, and is difficult to >>> normatively define in practice. =A0For the purposes of this WG >>> charter's scope, simple rules for conveyance of session-ID will be >>> defined for the common cases of through calls, forked calls, Refer >>> and Join. These rules will be selected based on maximizing their >>> value to troubleshooting in the common cases. " >>> >>> >>> Peter Musgrave >>> >>> On Wed, Jul 28, 2010 at 10:07 AM, Hadriel Kaplan >>> wrote: >>> > Howdy, >>> > One of the objections to the currently proposed SIPSCOTCH charter >>> > is >>> on how one knows whether to use the same session-id or not - i.e., >>> what defines the same higher layer session. >>> > >>> > In particular, the following paragraph of the charter: >>> > "The definition of a higher-layer "session" of the same "message- >>> flow" is not defined by SIP when it involves a B2BUA, and is >>> difficult to normatively define in practice. =A0For the purposes of >>> this WG charter's scope, two or more dialogs of a B2BUA are >>> correlated under any conditions where correlation might aid >>> troubleshooting, by identifying them as belonging to the same >>> higher-level session. =A0Any solution documents from this working group >>> may expand or constrain the scope of their mechanism's correlation, >>> if the working group so decides." >>> > >>> > This objection was also raised on the DISPATCH mailing list thread >>> starting here: >>> > http://www.ietf.org/mail-archive/web/dispatch/current/msg01981.html >>> > >>> > >>> > I believe the available options to handle this issue are: >>> > >>> > 1) Defer it to the new WG's solution doc to specify. >>> > >>> > 2) Try to articulate rules in the charter for when two >>> messages/dialogs are part of the same "session". =A0This was actually >>> attempted in a previous incarnation of the charter, in an email >>> thread starting here: >>> > http://www.ietf.org/mail-archive/web/dispatch/current/msg01817.html >>> > >>> > 3) Instead of defining "rules", try to enumerate examples/use-cases >>> which are and are-not in scope to be the same session. >>> > >>> > Any comments/preferences? >>> > >>> > -hadriel >>> > _______________________________________________ >>> > 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 >> > > > > -- > Victor Pascual =C1vila > _______________________________________________ > 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 gao.yang2@zte.com.cn Wed Jul 28 22:55:26 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF9A53A6869 for ; Wed, 28 Jul 2010 22:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.21 X-Spam-Level: X-Spam-Status: No, score=-97.21 tagged_above=-999 required=5 tests=[AWL=-1.064, BAYES_05=-1.11, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMNECDk11VUF for ; Wed, 28 Jul 2010 22:55:24 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id C7F8C3A68F0 for ; Wed, 28 Jul 2010 22:55:21 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 3510992332426; Thu, 29 Jul 2010 13:54:53 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 74015.2898723675; Thu, 29 Jul 2010 13:47:13 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6T5t86s056163; Thu, 29 Jul 2010 13:55:08 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: Peter Musgrave MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 29 Jul 2010 13:53:31 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-29 13:54:59, Serialize complete at 2010-07-29 13:54:59 Content-Type: multipart/alternative; boundary="=_alternative 00206A3A4825776F_=" X-MAIL: mse2.zte.com.cn o6T5t86s056163 Cc: dispatch@ietf.org Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 05:55:27 -0000 This is a multipart message in MIME format. --=_alternative 00206A3A4825776F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUGV0ZXIsDQoNCkFzIHdlIGtub3csIFJFRkVSJ3Mgb25lIGNvbW1vbiBwcm9ibGVtIHdpdGgg QjJCVUEgaXMgYWJvdXQgDQpSZXBsYWNlcyhSRkMzODkxKS4gU28sIEknZCBsaWtlIHRvIGRvdWJs ZSBjaGVjayB0aGF0IGlzIGl0IGFib3V0IFJlcGxhY2VzLCANCm9yIGp1c3QgYWJvdXQgUkZDMzUx NT8NCg0KVGhhbmtzLA0KDQpHYW8gDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDogODcyMTENCiBUZWwyICAgOigrODYpLTAy NS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KUGV0ZXIgTXVzZ3JhdmUgPHBldGVyLm11c2dy YXZlQG1hZ29yY29ycC5jb20+IA0KMjAxMC0wNy0yOSAxMzozNA0KDQrK1bz+yMsNCmdhby55YW5n MkB6dGUuY29tLmNuDQqzrcvNDQpkaXNwYXRjaEBpZXRmLm9yZw0K1vfM4g0KUmU6IFtkaXNwYXRj aF0gU0lQU0NPVENIL3Nlc3Npb24taWQgY2hhcnRlciBzY29wZQ0KDQoNCg0KDQoNCg0KSGkgR2Fv LA0KDQpJIG1lYW4gdGhlIFJFRkVSIG1ldGhvZCAoUkZDMzUxNSkuDQoNClBldGVyDQoNCk9uIFRo dSwgSnVsIDI5LCAyMDEwIGF0IDI6NDggQU0sICA8Z2FvLnlhbmcyQHp0ZS5jb20uY24+IHdyb3Rl Og0KPg0KPiBIaSBQZXRlciBNdXNncmF2ZQ0KPg0KPj4gSG93IGFib3V0IGEgY2hhcnRlciBzdGF0 ZW1lbnQgb2Y6DQo+PiAiVGhlIGRlZmluaXRpb24gb2YgYSBoaWdoZXItbGF5ZXIgInNlc3Npb24i IG9mIHRoZSBzYW1lICJtZXNzYWdlLWZsb3ciDQo+PiBpcyBub3QgZGVmaW5lZCBieSBTSVAgd2hl biBpdCBpbnZvbHZlcyBhIEIyQlVBLCBhbmQgaXMgZGlmZmljdWx0IHRvDQo+PiBub3JtYXRpdmVs eSBkZWZpbmUgaW4gcHJhY3RpY2UuICBGb3IgdGhlIHB1cnBvc2VzIG9mIHRoaXMgV0cgY2hhcnRl cidzDQo+PiBzY29wZSwgc2ltcGxlIHJ1bGVzIGZvciBjb252ZXlhbmNlIG9mIHNlc3Npb24tSUQg d2lsbCBiZSBkZWZpbmVkIGZvcg0KPj4gdGhlIGNvbW1vbiBjYXNlcyBvZiB0aHJvdWdoIGNhbGxz LCBmb3JrZWQgY2FsbHMsIFJlZmVyIGFuZCBKb2luLg0KPg0KPiBJJ2QgbGlrZSB0byBjaGVjayB0 aGF0IGRvIHlvdSBtZWFuICJVUERBVEUgUkZDMzg5MSIgYWJvdXQgUkVGRVIgaGVyZT8NCj4NCj4+ IFRoZXJlIHJ1bGVzIHdpbGwgYmUgc2VsZWN0ZWQgYmFzZWQgb24gbWF4aW1pemluZyB0aGVpciB2 YWx1ZSB0bw0KPj4gdHJvdWJsZXNob290aW5nIGluIHRoZSBjb21tb24gY2FzZXMuICINCj4NCj4g VGhhbmtzLA0KPg0KPiBHYW8NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90 aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJv cGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRp b24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQg dG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhl IGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQo+IA0KVGhpcyBlbWFp bCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0 byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBB bnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2 aWR1YWwgc2VuZGVyLg0KPiANClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1 c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0KPg0KDQoNCg0KDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUg SW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlv bi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5h bWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBw ZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0 byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBh cmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0 b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFy ZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4g c2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 00206A3A4825776F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFBldGVyLDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXMgd2Uga25vdywgUkVGRVIn czxiPiA8L2I+b25lIGNvbW1vbg0KcHJvYmxlbSB3aXRoIEIyQlVBIGlzIGFib3V0IFJlcGxhY2Vz KFJGQzM4OTEpLiBTbywgSSdkIGxpa2UgdG8gZG91YmxlIGNoZWNrDQp0aGF0IGlzIGl0IGFib3V0 IFJlcGxhY2VzLCBvciBqdXN0IGFib3V0IFJGQzM1MTU/PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MsPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW8gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7 OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFp bCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+PGI+UGV0ZXIgTXVzZ3JhdmUgJmx0O3BldGVyLm11c2dyYXZlQG1hZ29yY29ycC5jb20mZ3Q7 PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDct MjkgMTM6MzQ8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+Z2FvLnlhbmcyQHp0ZS5jb20uY248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmRpc3BhdGNo QGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW2Rpc3BhdGNoXSBTSVBTQ09UQ0gvc2Vz c2lvbi1pZA0KY2hhcnRlciBzY29wZTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJy Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SGkgR2FvLDxicj4NCjxicj4NCkkgbWVhbiB0aGUgUkVG RVIgbWV0aG9kIChSRkMzNTE1KS48YnI+DQo8YnI+DQpQZXRlcjxicj4NCjxicj4NCk9uIFRodSwg SnVsIDI5LCAyMDEwIGF0IDI6NDggQU0sICZuYnNwOyZsdDtnYW8ueWFuZzJAenRlLmNvbS5jbiZn dDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkgUGV0ZXIgTXVzZ3JhdmU8YnI+DQomZ3Q7 PGJyPg0KJmd0OyZndDsgSG93IGFib3V0IGEgY2hhcnRlciBzdGF0ZW1lbnQgb2Y6PGJyPg0KJmd0 OyZndDsgJnF1b3Q7VGhlIGRlZmluaXRpb24gb2YgYSBoaWdoZXItbGF5ZXIgJnF1b3Q7c2Vzc2lv biZxdW90OyBvZg0KdGhlIHNhbWUgJnF1b3Q7bWVzc2FnZS1mbG93JnF1b3Q7PGJyPg0KJmd0OyZn dDsgaXMgbm90IGRlZmluZWQgYnkgU0lQIHdoZW4gaXQgaW52b2x2ZXMgYSBCMkJVQSwgYW5kIGlz IGRpZmZpY3VsdA0KdG88YnI+DQomZ3Q7Jmd0OyBub3JtYXRpdmVseSBkZWZpbmUgaW4gcHJhY3Rp Y2UuICZuYnNwO0ZvciB0aGUgcHVycG9zZXMgb2YgdGhpcw0KV0cgY2hhcnRlcidzPGJyPg0KJmd0 OyZndDsgc2NvcGUsIHNpbXBsZSBydWxlcyBmb3IgY29udmV5YW5jZSBvZiBzZXNzaW9uLUlEIHdp bGwgYmUgZGVmaW5lZA0KZm9yPGJyPg0KJmd0OyZndDsgdGhlIGNvbW1vbiBjYXNlcyBvZiB0aHJv dWdoIGNhbGxzLCBmb3JrZWQgY2FsbHMsIFJlZmVyIGFuZCBKb2luLjxicj4NCiZndDs8YnI+DQom Z3Q7IEknZCBsaWtlIHRvIGNoZWNrIHRoYXQgZG8geW91IG1lYW4gJnF1b3Q7VVBEQVRFIFJGQzM4 OTEmcXVvdDsgYWJvdXQNClJFRkVSIGhlcmU/PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IFRoZXJl IHJ1bGVzIHdpbGwgYmUgc2VsZWN0ZWQgYmFzZWQgb24gbWF4aW1pemluZyB0aGVpciB2YWx1ZSB0 bzxicj4NCiZndDsmZ3Q7IHRyb3VibGVzaG9vdGluZyBpbiB0aGUgY29tbW9uIGNhc2VzLiAmcXVv dDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MsPGJyPg0KJmd0Ozxicj4NCiZndDsgR2FvPGJy Pg0KJmd0Ozxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IFpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2Vj dXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWlu ZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtw cm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24u Jm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25m aWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUm bmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2Fu ZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2Um bmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRp b24mbmJzcDt0byZuYnNwO290aGVycy48YnI+DQomZ3Q7IFRoaXMmbmJzcDtlbWFpbCZuYnNwO2Fu ZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQm bmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3Nv bGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZu YnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDty ZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVh c2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4m bmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLjxicj4NCiZndDsgVGhpcyZuYnNwO21lc3Nh Z2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMm bmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtz eXN0ZW0uPGJyPg0KJmd0Ozxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtU aGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNw O21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNw O2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRz Jm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5i c3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7 cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5i c3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0K VGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21p dHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2Fu ZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0 byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5i c3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7 aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdp bmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3Mm bmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5i c3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpU aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9y Jm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0Fu dGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 00206A3A4825776F_=-- From peter.musgrave@magorcorp.com Wed Jul 28 23:22:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C368B3A6915 for ; Wed, 28 Jul 2010 23:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.965 X-Spam-Level: X-Spam-Status: No, score=0.965 tagged_above=-999 required=5 tests=[AWL=-2.109, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgeQxjeiRVcH for ; Wed, 28 Jul 2010 23:22:51 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 70FF23A683F for ; Wed, 28 Jul 2010 23:22:51 -0700 (PDT) Received: by gwaa18 with SMTP id a18so2017gwa.31 for ; Wed, 28 Jul 2010 23:23:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.17.27 with SMTP id u27mr550198ybi.158.1280384594835; Wed, 28 Jul 2010 23:23:14 -0700 (PDT) Received: by 10.229.20.198 with HTTP; Wed, 28 Jul 2010 23:23:14 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Jul 2010 08:23:14 +0200 Message-ID: From: Peter Musgrave To: gao.yang2@zte.com.cn Content-Type: multipart/alternative; boundary=000e0cd68d06f379f7048c80c431 Cc: dispatch@ietf.org Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 06:22:52 -0000 --000e0cd68d06f379f7048c80c431 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable I'm sorry I misunderstood (and did not drink enough coffee yet!) Yes - it includes Replaces (RFC3891). Peter 2010/7/29 > > Hi Peter, > > As we know, REFER's* *one common problem with B2BUA is about > Replaces(RFC3891). So, I'd like to double check that is it about Replaces= , > or just about RFC3515? > > Thanks, > > Gao > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > *Peter Musgrave * > > 2010-07-29 13:34 > =CA=D5=BC=FE=C8=CB > gao.yang2@zte.com.cn > =B3=AD=CB=CD > dispatch@ietf.org > =D6=F7=CC=E2 > Re: [dispatch] SIPSCOTCH/session-id charter scope > > > > > Hi Gao, > > I mean the REFER method (RFC3515). > > Peter > > On Thu, Jul 29, 2010 at 2:48 AM, wrote: > > > > Hi Peter Musgrave > > > >> How about a charter statement of: > >> "The definition of a higher-layer "session" of the same "message-flow" > >> is not defined by SIP when it involves a B2BUA, and is difficult to > >> normatively define in practice. For the purposes of this WG charter's > >> scope, simple rules for conveyance of session-ID will be defined for > >> the common cases of through calls, forked calls, Refer and Join. > > > > I'd like to check that do you mean "UPDATE RFC3891" about REFER here? > > > >> There rules will be selected based on maximizing their value to > >> troubleshooting in the common cases. " > > > > Thanks, > > > > Gao > > > > -------------------------------------------------------- > > > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > > > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > > > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. > > --000e0cd68d06f379f7048c80c431 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable I'm sorry I misunderstood (and did not drink enough coffee yet!)
Yes - it includes Replaces (RFC3891). 

Peter

2010/7/29 <gao.yang2@zte.com.cn>

Hi Peter,

As we know, REFER's one= common problem with B2BUA is about Replaces(RFC3891). So, I'd like to double c= heck that is it about Replaces, or just about RFC3515?

Thanks,

Gao

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yan= g2@zte.com.cn
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Peter Musgrave <peter.musgrave@magorcorp.com>

2010-07-29 13:34

=CA=D5=BC=FE=C8= =CB
gao.yang2@zte.com.cn
=B3=AD=CB=CD
dispatch@ietf.org
=D6=F7=CC=E2
Re: [dispatch] SIPSCOTCH/sess= ion-id charter scope





Hi Gao,

I mean the REFER method (RFC3515).

Peter

On Thu, Jul 29, 2010 at 2:48 AM,  <gao.yang2@zte.com.cn> wrote:
>
> Hi Peter Musgrave
>
>> How about a charter statement of:
>> "The definition of a higher-layer "session" of the same "message-flow"
>> is not defined by SIP when it involves a B2BUA, and is difficult to
>> normatively define in practice.  For the purposes of this WG charter's
>> scope, simple rules for conveyance of session-ID will be defined for
>> the common cases of through calls, forked calls, Refer and Join. >
> I'd like to check that do you mean "UPDATE RFC3891" abou= t REFER here?
>
>> There rules will be selected based on maximizing their value to >> troubleshooting in the common cases. "
>
> Thanks,
>
> Gao
>
> --------------------------------------------------------
> ZTE Information Security Notice: The informat= ion contained in this mail is solely pro= perty of the sender's organization. This = mail communication is confidential. Recipients nam= ed above are obligated to maintain secrecy&nb= sp;and are not permitted to disclose the = ;contents of this communication to others.
> This email and any files transmitted wit= h it are confidential and intended solely&nbs= p;for the use of the individual or entit= y to whom they are addressed. If you&nbs= p;have received this email in error please&nb= sp;notify the originator of the message. Any&= nbsp;views expressed in this message are thos= e of the individual sender.
> This message has been scanned for viruse= s and Spam by ZTE Anti-Spam system.
>

 

--------------------------------------------------------
ZTE Information Security Notice: The information&n=
bsp;contained in this mail is solely property=
 of the sender's organization. This mail&=
nbsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy an=
d are not permitted to disclose the cont=
ents of this communication to others.
This email and any files transmitted with&nbs=
p;it are confidential and intended solely for=
 the use of the individual or entity&nbs=
p;to whom they are addressed. If you hav=
e received this email in error please no=
tify the originator of the message. Any =
views expressed in this message are those&nbs=
p;of the individual sender.
This message has been scanned for viruses&nbs=
p;and Spam by ZTE Anti-Spam system.

--000e0cd68d06f379f7048c80c431-- From gao.yang2@zte.com.cn Thu Jul 29 00:09:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 439E83A67F9 for ; Thu, 29 Jul 2010 00:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.983 X-Spam-Level: X-Spam-Status: No, score=-96.983 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wZcZRq4kRAQ for ; Thu, 29 Jul 2010 00:09:13 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id EBDC23A68F0 for ; Thu, 29 Jul 2010 00:09:12 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 20595992332426; Thu, 29 Jul 2010 14:37:32 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 83990.2898723675; Thu, 29 Jul 2010 14:38:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6T6bdqI046581; Thu, 29 Jul 2010 14:37:39 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: Peter Musgrave MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 29 Jul 2010 14:36:01 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-29 14:37:29, Serialize complete at 2010-07-29 14:37:29 Content-Type: multipart/alternative; boundary="=_alternative 00244E814825776F_=" X-MAIL: mse2.zte.com.cn o6T6bdqI046581 Cc: dispatch@ietf.org Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 07:09:15 -0000 This is a multipart message in MIME format. --=_alternative 00244E814825776F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUGV0ZXIsDQoNCkkgb25jZSB0YWxrZWQgYWJvdXQgdGhlIFVQREFURSBSRkMzODkxIHRvcGlj Og0KDQpodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZGlzcGF0Y2gvY3VycmVu dC9tc2cwMjEzNi5odG1sDQoNCmFuZCANCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL2Rpc3BhdGNoL2N1cnJlbnQvbXNnMDIxMzcuaHRtbA0KDQoNCkJUVywgaWYgeW91IGFy ZSBhdCBOZXRoZXJsYW5kcyBub3csIEkgZ3Vlc3MgaXQncyBtb3Jpbmcgbm93IDopDQpJIGhhdmUg YSBsb3Qgb2YgcHJvZHVjdGlvbiBpc3N1ZSB0aGlzIHRpbWUsIHNvIEkgY2FuIG5vdCBmaW5kIHRp bWUgZm9yIA0KdGhpcyB0aW1lJ3MgSUVURiBtZWV0aW5nLiBJIGhvcGUgdG8gc2VlIHlvdSBpbiB0 aGUgbmV4dCBtZWV0aW5nIGluIENoaW5hLg0KDQpDaGVlcnMsDQoNCkdhbw0KDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3 MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRl LmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNClBldGVy IE11c2dyYXZlIDxwZXRlci5tdXNncmF2ZUBtYWdvcmNvcnAuY29tPiANCjIwMTAtMDctMjkgMTQ6 MjMNCg0KytW8/sjLDQpnYW8ueWFuZzJAenRlLmNvbS5jbg0Ks63LzQ0KZGlzcGF0Y2hAaWV0Zi5v cmcNCtb3zOINClJlOiBbZGlzcGF0Y2hdIFNJUFNDT1RDSC9zZXNzaW9uLWlkIGNoYXJ0ZXIgc2Nv cGUNCg0KDQoNCg0KDQoNCkknbSBzb3JyeSBJIG1pc3VuZGVyc3Rvb2QgKGFuZCBkaWQgbm90IGRy aW5rIGVub3VnaCBjb2ZmZWUgeWV0ISkNCg0KWWVzIC0gaXQgaW5jbHVkZXMgUmVwbGFjZXMgKFJG QzM4OTEpLiANCg0KUGV0ZXINCg0KMjAxMC83LzI5IDxnYW8ueWFuZzJAenRlLmNvbS5jbj4NCg0K SGkgUGV0ZXIsIA0KDQpBcyB3ZSBrbm93LCBSRUZFUidzIG9uZSBjb21tb24gcHJvYmxlbSB3aXRo IEIyQlVBIGlzIGFib3V0IA0KUmVwbGFjZXMoUkZDMzg5MSkuIFNvLCBJJ2QgbGlrZSB0byBkb3Vi bGUgY2hlY2sgdGhhdCBpcyBpdCBhYm91dCBSZXBsYWNlcywgDQpvciBqdXN0IGFib3V0IFJGQzM1 MTU/IA0KDQpUaGFua3MsIA0KDQpHYW8gDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQpaaXAgICAgOiAyMTAwMTINClRlbCAgICA6IDg3MjExDQpUZWwyICAgOigrODYpLTAy NS01Mjg3NzIxMQ0KZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09IA0KDQoNCg0KUGV0ZXIgTXVzZ3JhdmUgPHBldGVyLm11c2dy YXZlQG1hZ29yY29ycC5jb20+IA0KMjAxMC0wNy0yOSAxMzozNCANCg0KDQrK1bz+yMsNCmdhby55 YW5nMkB6dGUuY29tLmNuIA0Ks63LzQ0KZGlzcGF0Y2hAaWV0Zi5vcmcgDQrW98ziDQpSZTogW2Rp c3BhdGNoXSBTSVBTQ09UQ0gvc2Vzc2lvbi1pZCBjaGFydGVyIHNjb3BlDQoNCg0KDQoNCg0KDQoN Cg0KSGkgR2FvLA0KDQpJIG1lYW4gdGhlIFJFRkVSIG1ldGhvZCAoUkZDMzUxNSkuDQoNClBldGVy DQoNCk9uIFRodSwgSnVsIDI5LCAyMDEwIGF0IDI6NDggQU0sICA8Z2FvLnlhbmcyQHp0ZS5jb20u Y24+IHdyb3RlOg0KPg0KPiBIaSBQZXRlciBNdXNncmF2ZQ0KPg0KPj4gSG93IGFib3V0IGEgY2hh cnRlciBzdGF0ZW1lbnQgb2Y6DQo+PiAiVGhlIGRlZmluaXRpb24gb2YgYSBoaWdoZXItbGF5ZXIg InNlc3Npb24iIG9mIHRoZSBzYW1lICJtZXNzYWdlLWZsb3ciDQo+PiBpcyBub3QgZGVmaW5lZCBi eSBTSVAgd2hlbiBpdCBpbnZvbHZlcyBhIEIyQlVBLCBhbmQgaXMgZGlmZmljdWx0IHRvDQo+PiBu b3JtYXRpdmVseSBkZWZpbmUgaW4gcHJhY3RpY2UuICBGb3IgdGhlIHB1cnBvc2VzIG9mIHRoaXMg V0cgY2hhcnRlcidzDQo+PiBzY29wZSwgc2ltcGxlIHJ1bGVzIGZvciBjb252ZXlhbmNlIG9mIHNl c3Npb24tSUQgd2lsbCBiZSBkZWZpbmVkIGZvcg0KPj4gdGhlIGNvbW1vbiBjYXNlcyBvZiB0aHJv dWdoIGNhbGxzLCBmb3JrZWQgY2FsbHMsIFJlZmVyIGFuZCBKb2luLg0KPg0KPiBJJ2QgbGlrZSB0 byBjaGVjayB0aGF0IGRvIHlvdSBtZWFuICJVUERBVEUgUkZDMzg5MSIgYWJvdXQgUkVGRVIgaGVy ZT8NCj4NCj4+IFRoZXJlIHJ1bGVzIHdpbGwgYmUgc2VsZWN0ZWQgYmFzZWQgb24gbWF4aW1pemlu ZyB0aGVpciB2YWx1ZSB0bw0KPj4gdHJvdWJsZXNob290aW5nIGluIHRoZSBjb21tb24gY2FzZXMu ICINCj4NCj4gVGhhbmtzLA0KPg0KPiBHYW8NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gWlRFIEluZm9ybWF0aW9uIFNlY3Vy aXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgDQppcyBz b2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNv bW11bmljYXRpb24gDQppcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJl IG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IA0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRv IGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhlcnMu DQo+IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25m aWRlbnRpYWwgYW5kIA0KaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIA0KYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIA0Kb3JpZ2luYXRv ciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJl IHRob3NlIA0Kb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KPiBUaGlzIG1lc3NhZ2UgaGFzIGJl ZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVt Lg0KPg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIA0Kc29sZWx5IHByb3BlcnR5IG9mIHRoZSBz ZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIA0KY29uZmlk ZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4g c2VjcmVjeSBhbmQgDQphcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMg b2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIA0Kb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZp bGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgDQpz b2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhl eSBhcmUgYWRkcmVzc2VkLiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJy b3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiANCnRoZSBtZXNzYWdlLiBBbnkgdmll d3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIA0KaW5kaXZpZHVh bCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQg U3BhbSBieSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRp b24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFp bCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBt YWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3Zl IGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQg dG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMu DQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlk ZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwg b3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhl IG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBv ZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBm b3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 00244E814825776F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFBldGVyLDwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBvbmNlIHRhbGtlZCBhYm91 dCB0aGUgVVBEQVRFIFJGQzM4OTENCnRvcGljOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2Rpc3BhdGNoL2N1cnJlbnQvbXNnMDIxMzYuaHRtbDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YW5kIDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+aHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2Vi L2Rpc3BhdGNoL2N1cnJlbnQvbXNnMDIxMzcuaHRtbDwvZm9udD4NCjxicj4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QlRXLCBpZiB5b3UgYXJlIGF0IE5ldGhlcmxh bmRzIG5vdywNCkkgZ3Vlc3MgaXQncyBtb3Jpbmcgbm93IDopPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGhhdmUgYSBsb3Qgb2YgcHJvZHVjdGlvbiBpc3N1ZSB0 aGlzDQp0aW1lLCBzbyBJIGNhbiBub3QgZmluZCB0aW1lIGZvciB0aGlzIHRpbWUncyBJRVRGIG1l ZXRpbmcuIEkgaG9wZSB0byBzZWUNCnlvdSBpbiB0aGUgbmV4dCBtZWV0aW5nIGluIENoaW5hLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Q2hlZXJzLDwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJy Pg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1 LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+UGV0ZXIgTXVzZ3JhdmUgJmx0O3BldGVyLm11c2dy YXZlQG1hZ29yY29ycC5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPjIwMTAtMDctMjkgMTQ6MjM8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRh YmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Z2FvLnlhbmcyQHp0ZS5jb20uY248L2ZvbnQ+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPmRpc3BhdGNoQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98zi PC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW2Rp c3BhdGNoXSBTSVBTQ09UQ0gvc2Vzc2lvbi1pZA0KY2hhcnRlciBzY29wZTwvZm9udD48L3RhYmxl Pg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxi cj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlm Ij5JJ20gc29ycnkgSSBtaXN1bmRlcnN0b29kIChhbmQgZGlkIG5vdA0KZHJpbmsgZW5vdWdoIGNv ZmZlZSB5ZXQhKTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJp ZiI+WWVzIC0gaXQgaW5jbHVkZXMgUmVwbGFjZXMgKFJGQzM4OTEpLg0KPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5QZXRlcjxicj4NCjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC83LzI5ICZsdDs8L2ZvbnQ+PGEg aHJlZj1tYWlsdG86Z2FvLnlhbmcyQHp0ZS5jb20uY24+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUg ZmFjZT0ic2Fucy1zZXJpZiI+PHU+Z2FvLnlhbmcyQHp0ZS5jb20uY248L3U+PC9mb250PjwvYT48 Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+Jmd0OzwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KSGkgUGV0ZXIsPC9mb250Pjxmb250IHNpemU9MyBm YWNlPSJzYW5zLXNlcmlmIj4gPGJyPg0KPC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj48YnI+DQpBcyB3ZSBrbm93LCBSRUZFUidzPGI+IDwvYj5vbmUgY29tbW9uIHByb2JsZW0g d2l0aCBCMkJVQSBpcyBhYm91dCBSZXBsYWNlcyhSRkMzODkxKS4NClNvLCBJJ2QgbGlrZSB0byBk b3VibGUgY2hlY2sgdGhhdCBpcyBpdCBhYm91dCBSZXBsYWNlcywgb3IganVzdCBhYm91dCBSRkMz NTE1PzwvZm9udD48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8YnI+DQo8L2ZvbnQ+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NClRoYW5rcyw8L2ZvbnQ+PGZvbnQg c2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjxicj4NCkdhbyA8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2Vy aWYiPjxicj4NCjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PGJyPg0KPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQpaaXAgJm5ic3A7ICZuYnNwOzog MjEwMDEyPGJyPg0KVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KVGVsMiAmbmJzcDsgOigr ODYpLTAyNS01Mjg3NzIxMTxicj4NCmVfbWFpbCA6IDwvZm9udD48YSBocmVmPW1haWx0bzpnYW8u eWFuZzJAenRlLmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZh Y2U9InNhbnMtc2VyaWYiPjx1Pmdhby55YW5nMkB6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PC9mb250Pjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj4NCjxicj4N Cjxicj4NCjwvZm9udD4NCjxwPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZCB3aWR0aD00OSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPlBldGVyIE11 c2dyYXZlICZsdDs8L2I+PC9mb250PjxhIGhyZWY9bWFpbHRvOnBldGVyLm11c2dyYXZlQG1hZ29y Y29ycC5jb20gdGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTEgY29sb3I9Ymx1ZSBmYWNlPSJzYW5z LXNlcmlmIj48Yj48dT5wZXRlci5tdXNncmF2ZUBtYWdvcmNvcnAuY29tPC91PjwvYj48L2ZvbnQ+ PC9hPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj4mZ3Q7PC9iPg0KPC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDctMjkgMTM6MzQ8L2ZvbnQ+ PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRkIHdpZHRoPTUwJT4N Cjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MTAl Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjL PC9mb250PjwvZGl2Pg0KPHRkIHdpZHRoPTg5JT48YSBocmVmPW1haWx0bzpnYW8ueWFuZzJAenRl LmNvbS5jbiB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MSBjb2xvcj1ibHVlIGZhY2U9InNhbnMt c2VyaWYiPjx1Pmdhby55YW5nMkB6dGUuY29tLmNuPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0z IGZhY2U9InNhbnMtc2VyaWYiPg0KPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250Pjwv ZGl2Pg0KPHRkPjxhIGhyZWY9bWFpbHRvOmRpc3BhdGNoQGlldGYub3JnIHRhcmdldD1fYmxhbms+ PGZvbnQgc2l6ZT0xIGNvbG9yPWJsdWUgZmFjZT0ic2Fucy1zZXJpZiI+PHU+ZGlzcGF0Y2hAaWV0 Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgZmFjZT0ic2Fucy1zZXJpZiI+DQo8L2Zv bnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPlJlOiBbZGlzcGF0Y2hdIFNJUFNDT1RDSC9zZXNzaW9uLWlkDQpjaGFy dGVyIHNjb3BlPC9mb250PjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTUwJT4NCjx0ZCB3aWR0aD01MCU+PC90YWJsZT4N Cjxicj48L3RhYmxlPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8 L2ZvbnQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQpIaSBHYW8sPGJyPg0KPGJyPg0KSSBt ZWFuIHRoZSBSRUZFUiBtZXRob2QgKFJGQzM1MTUpLjxicj4NCjxicj4NClBldGVyPGJyPg0KPGJy Pg0KT24gVGh1LCBKdWwgMjksIDIwMTAgYXQgMjo0OCBBTSwgJm5ic3A7Jmx0OzwvZm9udD48L3R0 PjxhIGhyZWY9bWFpbHRvOmdhby55YW5nMkB6dGUuY29tLmNuIHRhcmdldD1fYmxhbms+PHR0Pjxm b250IHNpemU9MiBjb2xvcj1ibHVlPjx1Pmdhby55YW5nMkB6dGUuY29tLmNuPC91PjwvZm9udD48 L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPiZndDsNCndyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7 IEhpIFBldGVyIE11c2dyYXZlPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IEhvdyBhYm91dCBhIGNo YXJ0ZXIgc3RhdGVtZW50IG9mOjxicj4NCiZndDsmZ3Q7ICZxdW90O1RoZSBkZWZpbml0aW9uIG9m IGEgaGlnaGVyLWxheWVyICZxdW90O3Nlc3Npb24mcXVvdDsgb2YNCnRoZSBzYW1lICZxdW90O21l c3NhZ2UtZmxvdyZxdW90Ozxicj4NCiZndDsmZ3Q7IGlzIG5vdCBkZWZpbmVkIGJ5IFNJUCB3aGVu IGl0IGludm9sdmVzIGEgQjJCVUEsIGFuZCBpcyBkaWZmaWN1bHQNCnRvPGJyPg0KJmd0OyZndDsg bm9ybWF0aXZlbHkgZGVmaW5lIGluIHByYWN0aWNlLiAmbmJzcDtGb3IgdGhlIHB1cnBvc2VzIG9m IHRoaXMNCldHIGNoYXJ0ZXInczxicj4NCiZndDsmZ3Q7IHNjb3BlLCBzaW1wbGUgcnVsZXMgZm9y IGNvbnZleWFuY2Ugb2Ygc2Vzc2lvbi1JRCB3aWxsIGJlIGRlZmluZWQNCmZvcjxicj4NCiZndDsm Z3Q7IHRoZSBjb21tb24gY2FzZXMgb2YgdGhyb3VnaCBjYWxscywgZm9ya2VkIGNhbGxzLCBSZWZl ciBhbmQgSm9pbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJJ2QgbGlrZSB0byBjaGVjayB0aGF0IGRv IHlvdSBtZWFuICZxdW90O1VQREFURSBSRkMzODkxJnF1b3Q7IGFib3V0DQpSRUZFUiBoZXJlPzxi cj4NCiZndDs8YnI+DQomZ3Q7Jmd0OyBUaGVyZSBydWxlcyB3aWxsIGJlIHNlbGVjdGVkIGJhc2Vk IG9uIG1heGltaXppbmcgdGhlaXIgdmFsdWUgdG88YnI+DQomZ3Q7Jmd0OyB0cm91Ymxlc2hvb3Rp bmcgaW4gdGhlIGNvbW1vbiBjYXNlcy4gJnF1b3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtz LDxicj4NCiZndDs8YnI+DQomZ3Q7IEdhbzxicj4NCiZndDs8YnI+DQomZ3Q7IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMNCm1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6 YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQppcyBjb25maWRlbnRpYWwuIFJlY2lwaWVu dHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5DQphbmQgYXJl IG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNh dGlvbiB0bw0Kb3RoZXJzLjxicj4NCiZndDsgVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5z bWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQNCmludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZQ0KYWRk cmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBu b3RpZnkgdGhlIG9yaWdpbmF0b3INCm9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2Vk IGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwNCnNlbmRlci48YnI+ DQomZ3Q7IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFt IGJ5IFpURSBBbnRpLVNwYW0NCnN5c3RlbS48YnI+DQomZ3Q7PGJyPg0KPC9mb250PjwvdHQ+PGZv bnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjxicj4NCjwvZm9udD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0zPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPg0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwNCmlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0 aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbg0KaXMgY29u ZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRh aW4gc2VjcmVjeQ0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50 cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8NCm90aGVycy48YnI+DQpUaGlzIGVtYWlsIGFuZCBh bnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRl ZA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9t IHRoZXkgYXJlIGFkZHJlc3NlZC4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZg0KdGhlIG1lc3NhZ2UuIEFueSB2 aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVh bA0Kc2VuZGVyLjxicj4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2Vz IGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLjxicj4NCjwvZm9udD48L3R0Pg0KPGJy Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZu YnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNw O2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5 Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtU aGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlh bC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29i bGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7 YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3Ro ZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNw O3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7 ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2Nv bmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5i c3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3Im bmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRk cmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhp cyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZu YnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5i c3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDtt ZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1 YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJz cDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDti eSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 00244E814825776F_=-- From partr@cisco.com Thu Jul 29 01:11:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DC6B3A67B1 for ; Thu, 29 Jul 2010 01:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.815 X-Spam-Level: X-Spam-Status: No, score=-9.815 tagged_above=-999 required=5 tests=[AWL=0.784, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3k6OqyPiOvk for ; Thu, 29 Jul 2010 01:11:11 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id CF33C3A685B for ; Thu, 29 Jul 2010 01:11:11 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK7UUExAaHte/2dsb2JhbACgCHGkbZsCgnGCRwSEEYcmDAE X-IronPort-AV: E=Sophos;i="4.55,279,1278288000"; d="scan'208";a="164558238" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 29 Jul 2010 08:11:34 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6T8BIcW024469; Thu, 29 Jul 2010 08:11:33 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Jul 2010 13:41:32 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Jul 2010 13:41:30 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIPSCOTCH/session-id charter scope Thread-Index: Acsu4GioAlTDDKwJQEquFx/d7VVLTAADxxXw References: <430FC6BDED356B4C8498F634416644A92694002808@mail><4c503c9f.487e0e0a.19fc.3621@mx.google.com><9886E5FCA6D76549A3011068483A4BD406631CA9@S4DE8PSAAQB.mitte.t-com.de> From: "Parthasarathi R (partr)" To: "Peter Musgrave" X-OriginalArrivalTime: 29 Jul 2010 08:11:32.0275 (UTC) FILETIME=[A787C830:01CB2EF5] Cc: dispatch@ietf.org, HKaplan@acmepacket.com, R.Jesske@telekom.de Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 08:11:13 -0000 Hi Peter/Hadriel, IMO, we are far from perfection as SBC which is a industry accepted SIP = entity not considered in this charter. SBC is a complex entity compares = to simple IETF defined entities like B2BUA. I'm making the point that = IETF WG (SIPSCOTCH) has to atleast consider creating the session = identity which satisfy all IETF SIP defined entities like B2BUA, Focus = for this new session-id. This will be helpful for complex entity like = SBC to scale the proposed mechanism. I'm not looking for perfect solution but I don't want to see the = multiple version of session-ids RFCs in the forthcoming years as we = narrow down too much now. The session-id has to be extensible or = scalable. As a B2BUA implementer, I'll come with some of the commonly = deployment industry callflows like REFER handling by 3PCC B2BUA and = also, expect the other implementers to provide the input on the same = line for better troubleshooting using session-id. BTW, I never thought that the troubleshooting B2BUA/SBC has protocol = dependency as the troubleshooting is being done with receiving/sending = SIP messages even in the complex customer deployment. Also, B2BUA/SBC = entity which I'm talking about interop with most of the B2BUA/SBC in the = Enterprise/Service provider network. ISTM, I'm using the industry best = practices/tools to troubleshoot/debug without protocol dependency. Having said that, I'm in agreement for this WG as the proposed = session-id will facilitate for innovative application/service in SIP.=20 Thanks Partha -----Original Message----- From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com]=20 Sent: Thursday, July 29, 2010 11:09 AM To: Parthasarathi R (partr) Cc: Victor Pascual Avila; R.Jesske@telekom.de; dispatch@ietf.org; = HKaplan@acmepacket.com Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope HI Partha, I think is better to focus on the common use cases (whether they are = complex or simple). IMHO the majority of them are usually not more = complicated than a REFER. I think as part of the doc review we can evaluate cases from 3PCC and = BLISS callflow examples and see what interest there is them. I do not = see the need to make this specific in the charter. I think (to channel JDR) "Let's not let the perfect be the enemy of the = good". I think the existing charter text does discusses the mechanics = (REFER, forking) which are basic to SIP and the specific use cases can = be discussed in the contexts you are suggesting without a change to the = charter text I suggested. Peter On Wed, Jul 28, 2010 at 11:43 PM, Parthasarathi R (partr) = wrote: > Hadriel, > > Session is a misnomer as it may be related to two or more dialogs = depend upon the B2BUA, Focus behavior. As you mentioned in point 3, it = is better to focus on the complex use cases document where the = troubleshooting is really tough in the SIP networks. Existing 3PCC, = BLISS callflow, conference callflow shall be referenced. The common = industry standard call services like Call transfer, call hold shall be = added as usecase. This will help in creating the clear session-id = charter. > > I'm sort of thinking that B2BUA will not abuse this session-id but SBC = *may*. > > Thanks > Partha > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of Victor Pascual Avila > Sent: Wednesday, July 28, 2010 8:31 PM > To: R.Jesske@telekom.de > Cc: dispatch@ietf.org; HKaplan@acmepacket.com > Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope > > +1 > > On Wed, Jul 28, 2010 at 4:50 PM, =A0 wrote: >> +1 >> I support this too. >> >> Best Regards >> >> Roland >> >> >> >> -----Urspr=FCngliche Nachricht----- >> Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im=20 >> Auftrag von Laura Liess >> Gesendet: Mittwoch, 28. Juli 2010 16:20 >> An: 'Peter Musgrave'; 'Hadriel Kaplan' >> Cc: dispatch@ietf.org >> Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope >> >> >> +1 >> I fully agree with Peter's text proposal. From my point of view, the=20 >> correlation rules are part of the problem we need to solve in the WG. >> We can not state the rules in the charter, we can state that the WG=20 >> should define such rules. And because it may be not possible to=20 >> define clear general rules working for the most general case, the=20 >> proposal to define rules for the common use cases seems quite = reasonable to me. >> >> Thanks =A0a lot, >> Laura >> >> >> >>> -----Urspr=FCngliche Nachricht----- >>> Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = >>> Auftrag von Peter Musgrave >>> Gesendet: Mittwoch, 28. Juli 2010 10:20 >>> An: Hadriel Kaplan >>> Cc: dispatch@ietf.org >>> Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope >>> >>> Hi Hadriel, >>> >>> I guess I favour a mix of (1) and (2). I don't think a charter needs = >>> to define the rules (that's what the doc is for!) I think the issue=20 >>> is to ensure that the charter does not leave an opening for this to=20 >>> become a 'rat hole' and devolve into a long discussion about dialog=20 >>> correlation (which is in principle not technically possible). >>> >>> How about a charter statement of: >>> "The definition of a higher-layer "session" of the same = "message-flow" >>> is not defined by SIP when it involves a B2BUA, and is difficult to=20 >>> normatively define in practice. =A0For the purposes of this WG=20 >>> charter's scope, simple rules for conveyance of session-ID will be=20 >>> defined for the common cases of through calls, forked calls, Refer=20 >>> and Join. These rules will be selected based on maximizing their=20 >>> value to troubleshooting in the common cases. " >>> >>> >>> Peter Musgrave >>> >>> On Wed, Jul 28, 2010 at 10:07 AM, Hadriel Kaplan=20 >>> wrote: >>> > Howdy, >>> > One of the objections to the currently proposed SIPSCOTCH charter=20 >>> > is >>> on how one knows whether to use the same session-id or not - i.e.,=20 >>> what defines the same higher layer session. >>> > >>> > In particular, the following paragraph of the charter: >>> > "The definition of a higher-layer "session" of the same "message- >>> flow" is not defined by SIP when it involves a B2BUA, and is=20 >>> difficult to normatively define in practice. =A0For the purposes of=20 >>> this WG charter's scope, two or more dialogs of a B2BUA are=20 >>> correlated under any conditions where correlation might aid=20 >>> troubleshooting, by identifying them as belonging to the same=20 >>> higher-level session. =A0Any solution documents from this working=20 >>> group may expand or constrain the scope of their mechanism's=20 >>> correlation, if the working group so decides." >>> > >>> > This objection was also raised on the DISPATCH mailing list thread >>> starting here: >>> > http://www.ietf.org/mail-archive/web/dispatch/current/msg01981.htm >>> > l >>> > >>> > >>> > I believe the available options to handle this issue are: >>> > >>> > 1) Defer it to the new WG's solution doc to specify. >>> > >>> > 2) Try to articulate rules in the charter for when two >>> messages/dialogs are part of the same "session". =A0This was = actually=20 >>> attempted in a previous incarnation of the charter, in an email=20 >>> thread starting here: >>> > http://www.ietf.org/mail-archive/web/dispatch/current/msg01817.htm >>> > l >>> > >>> > 3) Instead of defining "rules", try to enumerate=20 >>> > examples/use-cases >>> which are and are-not in scope to be the same session. >>> > >>> > Any comments/preferences? >>> > >>> > -hadriel >>> > _______________________________________________ >>> > 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 >> > > > > -- > Victor Pascual =C1vila > _______________________________________________ > 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 tme@americafree.tv Thu Jul 29 02:26:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 629A528C116; Thu, 29 Jul 2010 02:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EgKGhVPlKG7; Thu, 29 Jul 2010 02:26:14 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 483B228C120; Thu, 29 Jul 2010 02:26:14 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 48538825B01C; Thu, 29 Jul 2010 05:26:37 -0400 (EDT) Message-Id: From: Marshall Eubanks To: DISPATCH list , 78attendees@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Jul 2010 05:26:21 -0400 X-Mailer: Apple Mail (2.936) Cc: Jonathan Lennox , Bernie Hoeneisen , bo zhou , Riccardo Bernardini Subject: [dispatch] bar bof on a global videoconferencing / telepresence directory X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 09:26:15 -0000 Hello; This BOF will occur today. I have asked the Secretariat for a room; they are still working on it. If we get a room, I will CC to this message, otherwise, let's meet in the lunch room. I am a tall guy wearing a reddish shirt and a white hat. Regards Marshall From tme@americafree.tv Thu Jul 29 02:41:00 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EE613A6967; Thu, 29 Jul 2010 02:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.488 X-Spam-Level: X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEXj4e1iMzFl; Thu, 29 Jul 2010 02:40:58 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 96DAA3A69B2; Thu, 29 Jul 2010 02:40:58 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 7FFD0825B85C; Thu, 29 Jul 2010 05:41:21 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Marshall Eubanks In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Jul 2010 05:41:17 -0400 References: X-Mailer: Apple Mail (2.936) Cc: Jonathan Lennox , 78attendees@ietf.org, DISPATCH list , Riccardo Bernardini , Bernie Hoeneisen , bo zhou Subject: Re: [dispatch] bar bof on a global videoconferencing / telepresence directory X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 09:41:00 -0000 Let's meet in the IAOC room, 2.7 (directly above registration). Marshall On Jul 29, 2010, at 5:26 AM, Marshall Eubanks wrote: > Hello; > > This BOF will occur today. I have asked the Secretariat for a room; > they are still working on it. If we > get a room, I will CC to this message, otherwise, let's meet in the > lunch room. I am a tall guy wearing a reddish shirt and a white hat. > > Regards > Marshall > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From HKaplan@acmepacket.com Thu Jul 29 05:14:50 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 891FE28C111 for ; Thu, 29 Jul 2010 05:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.514 X-Spam-Level: X-Spam-Status: No, score=-1.514 tagged_above=-999 required=5 tests=[AWL=-0.644, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy5tOjksbBg8 for ; Thu, 29 Jul 2010 05:14:49 -0700 (PDT) Received: from ETMail2.acmepacket.com (host9.216.41.24.conversent.net [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id C6C5928C12B for ; Thu, 29 Jul 2010 05:14:48 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 29 Jul 2010 08:15:11 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 29 Jul 2010 08:15:11 -0400 From: Hadriel Kaplan To: "Parthasarathi R (partr)" , Peter Musgrave Date: Thu, 29 Jul 2010 08:15:12 -0400 Thread-Topic: [dispatch] SIPSCOTCH/session-id charter scope Thread-Index: Acsu4GioAlTDDKwJQEquFx/d7VVLTAADxxXwAAm+SAA= Message-ID: <430FC6BDED356B4C8498F634416644A92694002B6E@mail> References: <430FC6BDED356B4C8498F634416644A92694002808@mail><4c503c9f.487e0e0a.19fc.3621@mx.google.com><9886E5FCA6D76549A3011068483A4BD406631CA9@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 12:14:50 -0000 Hi Partha, I'm not sure exactly what you mean. This discussion is just about the SIPS= COTCH charter. As far as the *charter* is concerned, it has the following = sentence: "In particular, the mechanism must be able to allow such correlation across= SIP B2BUAs of as many functional types as possible, such as Application Se= rvers, Softswitches, PBXs, SBCs, etc." So as far as the charter's concerne= d, SBC's are included. With Peter's changes, the charter would also specify that the solution "wil= l be defined for the common cases of through calls, forked calls, Refer and= Join." Note that the session-id draft, which is a proposed potential solution for = SIPSCOTCH, goes into actual detail with regards to B2BUA behavior, forking,= REFER, and Replaces behavior. =20 So what *exactly* is missing from the *charter* that you'd like us to add? = Can you suggest text? -hadriel > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Thursday, July 29, 2010 4:12 AM > To: Peter Musgrave > Cc: Victor Pascual Avila; R.Jesske@telekom.de; dispatch@ietf.org; Hadriel > Kaplan > Subject: RE: [dispatch] SIPSCOTCH/session-id charter scope >=20 > Hi Peter/Hadriel, >=20 > IMO, we are far from perfection as SBC which is a industry accepted SIP > entity not considered in this charter. SBC is a complex entity compares t= o > simple IETF defined entities like B2BUA. I'm making the point that IETF W= G > (SIPSCOTCH) has to atleast consider creating the session identity which > satisfy all IETF SIP defined entities like B2BUA, Focus for this new > session-id. This will be helpful for complex entity like SBC to scale the > proposed mechanism. >=20 > I'm not looking for perfect solution but I don't want to see the multiple > version of session-ids RFCs in the forthcoming years as we narrow down to= o > much now. The session-id has to be extensible or scalable. As a B2BUA > implementer, I'll come with some of the commonly deployment industry > callflows like REFER handling by 3PCC B2BUA and also, expect the other > implementers to provide the input on the same line for better > troubleshooting using session-id. >=20 > BTW, I never thought that the troubleshooting B2BUA/SBC has protocol > dependency as the troubleshooting is being done with receiving/sending SI= P > messages even in the complex customer deployment. Also, B2BUA/SBC entity > which I'm talking about interop with most of the B2BUA/SBC in the > Enterprise/Service provider network. ISTM, I'm using the industry best > practices/tools to troubleshoot/debug without protocol dependency. >=20 > Having said that, I'm in agreement for this WG as the proposed session-id > will facilitate for innovative application/service in SIP. >=20 > Thanks > Partha >=20 > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > Sent: Thursday, July 29, 2010 11:09 AM > To: Parthasarathi R (partr) > Cc: Victor Pascual Avila; R.Jesske@telekom.de; dispatch@ietf.org; > HKaplan@acmepacket.com > Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope >=20 > HI Partha, >=20 > I think is better to focus on the common use cases (whether they are > complex or simple). IMHO the majority of them are usually not more > complicated than a REFER. >=20 > I think as part of the doc review we can evaluate cases from 3PCC and > BLISS callflow examples and see what interest there is them. I do not see > the need to make this specific in the charter. >=20 > I think (to channel JDR) "Let's not let the perfect be the enemy of the > good". I think the existing charter text does discusses the mechanics > (REFER, forking) which are basic to SIP and the specific use cases can be > discussed in the contexts you are suggesting without a change to the > charter text I suggested. >=20 > Peter >=20 > On Wed, Jul 28, 2010 at 11:43 PM, Parthasarathi R (partr) > wrote: > > Hadriel, > > > > Session is a misnomer as it may be related to two or more dialogs depen= d > upon the B2BUA, Focus behavior. As you mentioned in point 3, it is better > to focus on the complex use cases document where the troubleshooting is > really tough in the SIP networks. Existing 3PCC, BLISS callflow, > conference callflow shall be referenced. The common industry standard cal= l > services like Call transfer, call hold shall be added as usecase. This > will help in creating the clear session-id charter. > > > > I'm sort of thinking that B2BUA will not abuse this session-id but SBC > *may*. > > > > Thanks > > Partha > > > > -----Original Message----- > > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > > Behalf Of Victor Pascual Avila > > Sent: Wednesday, July 28, 2010 8:31 PM > > To: R.Jesske@telekom.de > > Cc: dispatch@ietf.org; HKaplan@acmepacket.com > > Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope > > > > +1 > > > > On Wed, Jul 28, 2010 at 4:50 PM, =A0 wrote: > >> +1 > >> I support this too. > >> > >> Best Regards > >> > >> Roland > >> > >> > >> > >> -----Urspr=FCngliche Nachricht----- > >> Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im > >> Auftrag von Laura Liess > >> Gesendet: Mittwoch, 28. Juli 2010 16:20 > >> An: 'Peter Musgrave'; 'Hadriel Kaplan' > >> Cc: dispatch@ietf.org > >> Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope > >> > >> > >> +1 > >> I fully agree with Peter's text proposal. From my point of view, the > >> correlation rules are part of the problem we need to solve in the WG. > >> We can not state the rules in the charter, we can state that the WG > >> should define such rules. And because it may be not possible to > >> define clear general rules working for the most general case, the > >> proposal to define rules for the common use cases seems quite > reasonable to me. > >> > >> Thanks =A0a lot, > >> Laura > >> > >> > >> > >>> -----Urspr=FCngliche Nachricht----- > >>> Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im > >>> Auftrag von Peter Musgrave > >>> Gesendet: Mittwoch, 28. Juli 2010 10:20 > >>> An: Hadriel Kaplan > >>> Cc: dispatch@ietf.org > >>> Betreff: Re: [dispatch] SIPSCOTCH/session-id charter scope > >>> > >>> Hi Hadriel, > >>> > >>> I guess I favour a mix of (1) and (2). I don't think a charter needs > >>> to define the rules (that's what the doc is for!) I think the issue > >>> is to ensure that the charter does not leave an opening for this to > >>> become a 'rat hole' and devolve into a long discussion about dialog > >>> correlation (which is in principle not technically possible). > >>> > >>> How about a charter statement of: > >>> "The definition of a higher-layer "session" of the same "message-flow= " > >>> is not defined by SIP when it involves a B2BUA, and is difficult to > >>> normatively define in practice. =A0For the purposes of this WG > >>> charter's scope, simple rules for conveyance of session-ID will be > >>> defined for the common cases of through calls, forked calls, Refer > >>> and Join. These rules will be selected based on maximizing their > >>> value to troubleshooting in the common cases. " > >>> > >>> > >>> Peter Musgrave > >>> > >>> On Wed, Jul 28, 2010 at 10:07 AM, Hadriel Kaplan > >>> wrote: > >>> > Howdy, > >>> > One of the objections to the currently proposed SIPSCOTCH charter > >>> > is > >>> on how one knows whether to use the same session-id or not - i.e., > >>> what defines the same higher layer session. > >>> > > >>> > In particular, the following paragraph of the charter: > >>> > "The definition of a higher-layer "session" of the same "message- > >>> flow" is not defined by SIP when it involves a B2BUA, and is > >>> difficult to normatively define in practice. =A0For the purposes of > >>> this WG charter's scope, two or more dialogs of a B2BUA are > >>> correlated under any conditions where correlation might aid > >>> troubleshooting, by identifying them as belonging to the same > >>> higher-level session. =A0Any solution documents from this working > >>> group may expand or constrain the scope of their mechanism's > >>> correlation, if the working group so decides." > >>> > > >>> > This objection was also raised on the DISPATCH mailing list thread > >>> starting here: > >>> > http://www.ietf.org/mail-archive/web/dispatch/current/msg01981.htm > >>> > l > >>> > > >>> > > >>> > I believe the available options to handle this issue are: > >>> > > >>> > 1) Defer it to the new WG's solution doc to specify. > >>> > > >>> > 2) Try to articulate rules in the charter for when two > >>> messages/dialogs are part of the same "session". =A0This was actually > >>> attempted in a previous incarnation of the charter, in an email > >>> thread starting here: > >>> > http://www.ietf.org/mail-archive/web/dispatch/current/msg01817.htm > >>> > l > >>> > > >>> > 3) Instead of defining "rules", try to enumerate > >>> > examples/use-cases > >>> which are and are-not in scope to be the same session. > >>> > > >>> > Any comments/preferences? > >>> > > >>> > -hadriel > >>> > _______________________________________________ > >>> > 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 > >> > > > > > > > > -- > > Victor Pascual =C1vila > > _______________________________________________ > > 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 HKaplan@acmepacket.com Thu Jul 29 05:32:52 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A773428C146 for ; Thu, 29 Jul 2010 05:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3k1Caf6yC5D for ; Thu, 29 Jul 2010 05:32:44 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5822028C0FF for ; Thu, 29 Jul 2010 05:32:44 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 29 Jul 2010 08:33:07 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 29 Jul 2010 08:33:07 -0400 From: Hadriel Kaplan To: Peter Musgrave Date: Thu, 29 Jul 2010 08:33:08 -0400 Thread-Topic: [dispatch] SIPSCOTCH/session-id charter scope Thread-Index: AcsuLawZJKtC7rRGRuqosDvwDsvizQA7ALxg Message-ID: <430FC6BDED356B4C8498F634416644A92694002B7A@mail> References: <430FC6BDED356B4C8498F634416644A92694002808@mail> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 12:32:54 -0000 Hi Peter, I like it too. One question - when you say "rules" in the sentence: "For the purposes of this WG charter's scope, simple rules for conveyance o= f session-ID will be defined for the common cases of through calls, forked = calls, Refer and Join."=20 ...do you mean rules that may end up to be "these are not the same identifi= er"? In other words, would this charter text allow us to define something = like session-id and say a Join call does NOT use the same session-id, and s= till comply with the charter because we defined a rule for Join? -hadriel > -----Original Message----- > From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] > Sent: Wednesday, July 28, 2010 4:20 AM > To: Hadriel Kaplan > Cc: dispatch@ietf.org > Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope >=20 > Hi Hadriel, >=20 > I guess I favour a mix of (1) and (2). I don't think a charter needs > to define the rules (that's what the doc is for!) I think the issue is > to ensure that the charter does not leave an opening for this to > become a 'rat hole' and devolve into a long discussion about dialog > correlation (which is in principle not technically possible). >=20 > How about a charter statement of: > "The definition of a higher-layer "session" of the same "message-flow" > is not defined by SIP when it involves a B2BUA, and is difficult to > normatively define in practice. =A0For the purposes of this WG charter's > scope, simple rules for conveyance of session-ID will be defined for > the common cases of through calls, forked calls, Refer and Join. These > rules will be selected based on maximizing their value to > troubleshooting in the common cases. " >=20 >=20 > Peter Musgrave >=20 > On Wed, Jul 28, 2010 at 10:07 AM, Hadriel Kaplan > wrote: > > Howdy, > > One of the objections to the currently proposed SIPSCOTCH charter is on > how one knows whether to use the same session-id or not - i.e., what > defines the same higher layer session. > > > > In particular, the following paragraph of the charter: > > "The definition of a higher-layer "session" of the same "message-flow" > is not defined by SIP when it involves a B2BUA, and is difficult to > normatively define in practice. =A0For the purposes of this WG charter's > scope, two or more dialogs of a B2BUA are correlated under any conditions > where correlation might aid troubleshooting, by identifying them as > belonging to the same higher-level session. =A0Any solution documents fro= m > this working group may expand or constrain the scope of their mechanism's > correlation, if the working group so decides." > > > > This objection was also raised on the DISPATCH mailing list thread > starting here: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg01981.html > > > > > > I believe the available options to handle this issue are: > > > > 1) Defer it to the new WG's solution doc to specify. > > > > 2) Try to articulate rules in the charter for when two messages/dialogs > are part of the same "session". =A0This was actually attempted in a previ= ous > incarnation of the charter, in an email thread starting here: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg01817.html > > > > 3) Instead of defining "rules", try to enumerate examples/use-cases > which are and are-not in scope to be the same session. > > > > Any comments/preferences? > > > > -hadriel > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > From peter.musgrave@magorcorp.com Thu Jul 29 06:11:53 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1918C3A69F9 for ; Thu, 29 Jul 2010 06:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.194 X-Spam-Level: X-Spam-Status: No, score=-2.194 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8ooBVhO3Ckk for ; Thu, 29 Jul 2010 06:11:42 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by core3.amsl.com (Postfix) with ESMTP id 46C0328C0F0 for ; Thu, 29 Jul 2010 06:11:41 -0700 (PDT) Received: by qyk8 with SMTP id 8so159584qyk.10 for ; Thu, 29 Jul 2010 06:12:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.103.130 with SMTP id k2mr92516qao.63.1280409124131; Thu, 29 Jul 2010 06:12:04 -0700 (PDT) Received: by 10.229.129.141 with HTTP; Thu, 29 Jul 2010 06:12:04 -0700 (PDT) In-Reply-To: <430FC6BDED356B4C8498F634416644A92694002B7A@mail> References: <430FC6BDED356B4C8498F634416644A92694002808@mail> <430FC6BDED356B4C8498F634416644A92694002B7A@mail> Date: Thu, 29 Jul 2010 15:12:04 +0200 Message-ID: From: Peter Musgrave To: Hadriel Kaplan Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 13:11:53 -0000 Precisely. I mean that we define what happens to the session id (use the same, use A or B, make a new one etc.) for each of the actions (through call, fork, REFER etc.) Peter On Thu, Jul 29, 2010 at 2:33 PM, Hadriel Kaplan wr= ote: > Hi Peter, > I like it too. > > One question - when you say "rules" in the sentence: > "For the purposes of this WG charter's scope, simple rules for conveyance= of session-ID will be defined for the common cases of through calls, forke= d calls, Refer and Join." > > ...do you mean rules that may end up to be "these are not the same identi= fier"? =A0In other words, would this charter text allow us to define someth= ing like session-id and say a Join call does NOT use the same session-id, a= nd still comply with the charter because we defined a rule for Join? > > -hadriel > >> -----Original Message----- >> From: Peter Musgrave [mailto:peter.musgrave@magorcorp.com] >> Sent: Wednesday, July 28, 2010 4:20 AM >> To: Hadriel Kaplan >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope >> >> Hi Hadriel, >> >> I guess I favour a mix of (1) and (2). I don't think a charter needs >> to define the rules (that's what the doc is for!) I think the issue is >> to ensure that the charter does not leave an opening for this to >> become a 'rat hole' and devolve into a long discussion about dialog >> correlation (which is in principle not technically possible). >> >> How about a charter statement of: >> "The definition of a higher-layer "session" of the same "message-flow" >> is not defined by SIP when it involves a B2BUA, and is difficult to >> normatively define in practice. =A0For the purposes of this WG charter's >> scope, simple rules for conveyance of session-ID will be defined for >> the common cases of through calls, forked calls, Refer and Join. These >> rules will be selected based on maximizing their value to >> troubleshooting in the common cases. " >> >> >> Peter Musgrave >> >> On Wed, Jul 28, 2010 at 10:07 AM, Hadriel Kaplan >> wrote: >> > Howdy, >> > One of the objections to the currently proposed SIPSCOTCH charter is o= n >> how one knows whether to use the same session-id or not - i.e., what >> defines the same higher layer session. >> > >> > In particular, the following paragraph of the charter: >> > "The definition of a higher-layer "session" of the same "message-flow" >> is not defined by SIP when it involves a B2BUA, and is difficult to >> normatively define in practice. =A0For the purposes of this WG charter's >> scope, two or more dialogs of a B2BUA are correlated under any condition= s >> where correlation might aid troubleshooting, by identifying them as >> belonging to the same higher-level session. =A0Any solution documents fr= om >> this working group may expand or constrain the scope of their mechanism'= s >> correlation, if the working group so decides." >> > >> > This objection was also raised on the DISPATCH mailing list thread >> starting here: >> > http://www.ietf.org/mail-archive/web/dispatch/current/msg01981.html >> > >> > >> > I believe the available options to handle this issue are: >> > >> > 1) Defer it to the new WG's solution doc to specify. >> > >> > 2) Try to articulate rules in the charter for when two messages/dialog= s >> are part of the same "session". =A0This was actually attempted in a prev= ious >> incarnation of the charter, in an email thread starting here: >> > http://www.ietf.org/mail-archive/web/dispatch/current/msg01817.html >> > >> > 3) Instead of defining "rules", try to enumerate examples/use-cases >> which are and are-not in scope to be the same session. >> > >> > Any comments/preferences? >> > >> > -hadriel >> > _______________________________________________ >> > dispatch mailing list >> > dispatch@ietf.org >> > https://www.ietf.org/mailman/listinfo/dispatch >> > > From HKaplan@acmepacket.com Thu Jul 29 07:15:30 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A2FC528C180 for ; Thu, 29 Jul 2010 07:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQsYhbl+lCcH for ; Thu, 29 Jul 2010 07:15:22 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 86F4928C119 for ; Thu, 29 Jul 2010 07:15:20 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 29 Jul 2010 10:15:43 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 29 Jul 2010 10:15:43 -0400 From: Hadriel Kaplan To: "Parthasarathi R (partr)" , Peter Musgrave Date: Thu, 29 Jul 2010 10:15:44 -0400 Thread-Topic: [dispatch] SIPSCOTCH/session-id charter scope Thread-Index: Acsu4GioAlTDDKwJQEquFx/d7VVLTAADxxXwAA4qnIA= Message-ID: <430FC6BDED356B4C8498F634416644A92694002BFC@mail> References: <430FC6BDED356B4C8498F634416644A92694002808@mail><4c503c9f.487e0e0a.19fc.3621@mx.google.com><9886E5FCA6D76549A3011068483A4BD406631CA9@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [dispatch] SIPSCOTCH/session-id charter scope X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 14:15:30 -0000 Ooops, sorry I didn't notice your email's last line (below). So do you think the charter as written provides enough scope, or would you = like to suggest some addition to it? Thanks! -hadriel > -----Original Message----- > From: Parthasarathi R (partr) [mailto:partr@cisco.com] > Sent: Thursday, July 29, 2010 4:12 AM > To: Peter Musgrave >=20 > Having said that, I'm in agreement for this WG as the proposed session-id > will facilitate for innovative application/service in SIP. > Thanks > Partha From mary.ietf.barnes@gmail.com Thu Jul 29 08:20:32 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA83828C1CE; Thu, 29 Jul 2010 08:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zj1m3d4OpCxA; Thu, 29 Jul 2010 08:20:31 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 8934528C1A8; Thu, 29 Jul 2010 08:20:31 -0700 (PDT) Received: by gwaa18 with SMTP id a18so197229gwa.31 for ; Thu, 29 Jul 2010 08:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=xFOIi4OC9P5dSjFm0ly6pV6kzmuYEJD7kzo75iJ4k8g=; b=JwoKZFL6EETFuONdeTWE3N7wp9tHd5WlMytG3areW/I0xDKPyxwidENbvJcMrPpg/6 bnlhmg2bIycFFhpjJo+V0dFP5OUQYDaZ16mC+a9zSkAkd1FQT54iNGrQs8sG4Ne+vNv/ K0k8hvxe8WHJdqWNYRkpwF7WOD1vEwz2DQ0x8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wxXNB0DtaUXfK10pwLQLieSKKbJW2svcCKr2V7cfc/EKUnxqa8UigxKaa3hACrfdJ5 pjz/MO/6CFTcReUb4eIuFbXBwwYPtSHqLf9GJgp1bzMWRe3UgZb2f3pBBYVdhrb6S7EP vU7V4P+shMWuHx0A5Zm3SVpirqGLFSagrj15Q= MIME-Version: 1.0 Received: by 10.150.72.6 with SMTP id u6mr1328318yba.187.1280416855057; Thu, 29 Jul 2010 08:20:55 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Thu, 29 Jul 2010 08:20:54 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Jul 2010 10:20:54 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=000e0cd591c6cf6660048c8847eb Cc: rai@ietf.org, rai-ads@tools.ietf.org Subject: [dispatch] DISPATCH deadlines for IETF-79 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 15:20:32 -0000 --000e0cd591c6cf6660048c8847eb Content-Type: text/plain; charset=ISO-8859-1 Hi folks, The following summarizes the deadlines for topics for DISPATCH for IETF-79: * August 30, 2010. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. [Two weeks prior to BoF proposal deadline] * Sept. 6, 2010. Cutoff for charter proposals for topics. [One week prior to BoF proposal deadline] * Sept. 20, 2010. Topics that are to be the focus of IETF-79 are announced. [One week before deadline to request WG slots] * Oct. 18th, 2010. -00 draft deadline. * Oct. 25th, 2010. Draft deadline. These deadlines have been published on the DISPATCH WG wiki page: http://trac.tools.ietf.org/wg/dispatch/trac/wiki Note that these dates are closer to the end of the meeting than those for IETF-78 because there is just over 3 months between the end of IETF-78 and beginning of IETF-79 (versus the 4 months we had between this meeting and Anaheim). Note that registration and WG/Bof scheduling for IETF-79 starts on August 9th: http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF79 DISPATCH sets the first deadline such that it's still possible to request a BoF for topics that may be wider in scope and require broader community review. The deadlines for BoFs are set by the leadership so that there is time to consider BoFs in the scheduling. Also, as Gonzalo noted in a separate email, WGs need to have a draft charter at the time they request a WG slot. Further information on the motivation for the DISPATCH planning model is provided in the wiki. Regards, Mary DISPATCH WG co-chair --000e0cd591c6cf6660048c8847eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi folks,

The following summarizes the deadlines for topics for DISPATCH for IETF-79:=
<= br>
* August 30, 2010. Cutoff date to notify the chai= rs/DISPATCH WG of
=A0=A0plans to submit a proposal. [Two weeks prior to = BoF proposal deadline]

* Sept. 6, 2010. Cutoff for charter proposals for topics. [One week pri= or to BoF proposal deadline]

* Sept. 20, 2010. Topics that are to be the focus of IETF-79 are=A0anno= unced.
=A0=A0[One week before deadline to request WG=A0sl= ots]

* Oct. 18th, 2010. -00 draft deadline.

* Oct. 25th, 2010. Draft = deadline.

These deadlines have been published on the DISPATCH WG wik= i page:
http://trac.tools.ietf.org/= wg/dispatch/trac/wiki=A0

Note that these dates are closer to the end of th= e meeting than those for IETF-78 =A0because there is just over 3 months bet= ween the end of IETF-78 and beginning of IETF-79 (versus the 4 months we ha= d between this meeting and Anaheim).=A0
=A0
Note that registration and WG/Bof scheduling fo= r IETF-79 starts on August 9th:

DISPATCH sets the first deadline such that it&= #39;s still possible to request a BoF for topics that may be wider in scope= and require broader community review. =A0The deadlines for BoFs are set by= the leadership so that there is time to consider BoFs in the scheduling. A= lso, as Gonzalo noted in a separate email, WGs need to have a draft charter= at the time they request a WG slot. =A0Further information on the motivati= on for the DISPATCH planning model =A0is provided in the wiki.

Regards,
Mary
DISPATCH WG co-chair

--000e0cd591c6cf6660048c8847eb-- From fluffy@cisco.com Thu Jul 29 09:29:56 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 467B828C100 for ; Thu, 29 Jul 2010 09:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.52 X-Spam-Level: X-Spam-Status: No, score=-110.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czncNlBVi3z3 for ; Thu, 29 Jul 2010 09:29:55 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 4B9EB3A679F for ; Thu, 29 Jul 2010 09:29:55 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACtJUUxAZnwN/2dsb2JhbACgB3GlYJsTgwMIgi0EiHk X-IronPort-AV: E=Sophos;i="4.55,281,1278288000"; d="scan'208";a="140838241" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 29 Jul 2010 16:30:19 +0000 Received: from dhcp-10-61-110-127.cisco.com (dhcp-10-61-110-127.cisco.com [10.61.110.127]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6TGUDre029491 for ; Thu, 29 Jul 2010 16:30:18 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Jul 2010 18:30:18 +0200 Message-Id: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> To: "dispatch@ietf.org list" Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 16:29:56 -0000 I tried to write a proposal that I think reflects what the proponents of = this WG want. Here's my stab at it.=20 ------------------ Troubleshooting SIP networks can be improved by correlating messaging = across several devices. This working group will define a correlation = identifier to be used for the troubleshooting and the for correlation of = logging information from different SIP devices in the network.=20 Sip transactions are often triggered by another SIP transaction. Two = transactions are in the same "session" if one was triggered by the other = due to redirection, REFER processing, retargeting, or forwarding on a = B2BUA. This working group will define a correlation identifier that = identifies all the transactions in the same session. The scope of the = identifier pertains to the SIP signaling layer only, and not media. = For example, several UA participating in a conference call may be = receiving the same media but would not be in the same session.=20 The design of the correlation identifier needs to take into account the = issue of not revealing the topology of network. The mechanism should be = applicable for Proxies, UAs, PBXs, SBCs, Application Servers, = Softswitches, Phones, and Gateways.=20 This working group will coordinate with other relevant working groups = and area including Ops, and sipcore.=20 From peter.musgrave@magorcorp.com Thu Jul 29 11:18:35 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FA3B3A6926 for ; Thu, 29 Jul 2010 11:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bEeDWvQlhgq for ; Thu, 29 Jul 2010 11:18:34 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 7A2913A67F0 for ; Thu, 29 Jul 2010 11:18:34 -0700 (PDT) Received: by pwj1 with SMTP id 1so259672pwj.31 for ; Thu, 29 Jul 2010 11:18:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.127.9 with SMTP id z9mr510271wfc.193.1280427538128; Thu, 29 Jul 2010 11:18:58 -0700 (PDT) Received: by 10.229.129.141 with HTTP; Thu, 29 Jul 2010 11:18:58 -0700 (PDT) In-Reply-To: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> Date: Thu, 29 Jul 2010 20:18:58 +0200 Message-ID: From: Peter Musgrave To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 18:18:35 -0000 I think this is fine. Peter Musgrave On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings wrote: > > I tried to write a proposal that I think reflects what the proponents of = this WG want. Here's my stab at it. > > ------------------ > > > Troubleshooting SIP networks can be improved by correlating messaging acr= oss several devices. This working group will define a correlation identifie= r to be used for the troubleshooting and the for correlation of logging inf= ormation from different SIP devices in the network. > > Sip transactions are often triggered by another SIP transaction. Two tran= sactions are in the same "session" if one was triggered by the other due to= redirection, REFER processing, retargeting, or forwarding on a B2BUA. This= working group will define a correlation identifier that identifies =A0all = the transactions in the same session. =A0The scope of the identifier pertai= ns to the SIP signaling layer only, and not media. =A0 For example, several= UA participating in a conference call may be receiving the same media but = would not be in the same session. > > The design of the correlation identifier needs to take into account the i= ssue of not revealing the topology of network. The mechanism should be appl= icable for Proxies, UAs, PBXs, SBCs, Application Servers, Softswitches, Pho= nes, and Gateways. > > This working group will coordinate with other relevant working groups and= area including Ops, and sipcore. > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From HKaplan@acmepacket.com Thu Jul 29 11:34:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4D93A698E for ; Thu, 29 Jul 2010 11:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HK3MvQum8s9 for ; Thu, 29 Jul 2010 11:34:42 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1E8AB3A6985 for ; Thu, 29 Jul 2010 11:34:42 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 29 Jul 2010 14:35:04 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 29 Jul 2010 14:35:04 -0400 From: Hadriel Kaplan To: Cullen Jennings , "dispatch@ietf.org list" Date: Thu, 29 Jul 2010 14:35:05 -0400 Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvO1ePrFehsviGSqKG1+JQXtYkowAEUvKw Message-ID: <430FC6BDED356B4C8498F634416644A92694002CFF@mail> References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> In-Reply-To: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 18:34:43 -0000 Looks fine to me. -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Thursday, July 29, 2010 12:30 PM > To: dispatch@ietf.org list > Subject: [dispatch] Proposal for Session ID charter >=20 >=20 > I tried to write a proposal that I think reflects what the proponents of > this WG want. Here's my stab at it. >=20 > ------------------ >=20 >=20 > Troubleshooting SIP networks can be improved by correlating messaging > across several devices. This working group will define a correlation > identifier to be used for the troubleshooting and the for correlation of > logging information from different SIP devices in the network. >=20 > Sip transactions are often triggered by another SIP transaction. Two > transactions are in the same "session" if one was triggered by the other > due to redirection, REFER processing, retargeting, or forwarding on a > B2BUA. This working group will define a correlation identifier that > identifies all the transactions in the same session. The scope of the > identifier pertains to the SIP signaling layer only, and not media. For > example, several UA participating in a conference call may be receiving > the same media but would not be in the same session. >=20 > The design of the correlation identifier needs to take into account the > issue of not revealing the topology of network. The mechanism should be > applicable for Proxies, UAs, PBXs, SBCs, Application Servers, Softswitche= s, > Phones, and Gateways. >=20 > This working group will coordinate with other relevant working groups and > area including Ops, and sipcore. >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From laura.liess.dt@googlemail.com Thu Jul 29 13:19:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A81A73A6359 for ; Thu, 29 Jul 2010 13:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2Fzw6u7jJcd for ; Thu, 29 Jul 2010 13:19:19 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 653E13A6867 for ; Thu, 29 Jul 2010 13:19:19 -0700 (PDT) Received: by wyb40 with SMTP id 40so541379wyb.31 for ; Thu, 29 Jul 2010 13:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zLmRvnpo8hX0oxEXP8hxiKxNHYj3kBrQMQb3S7z+oRo=; b=WNKJNYHAH0oQh7XOYU8b7Y84Gxw17i8aDTP1lkxefVd1F6C9ucmJRaCw0Pzit0g5CM LMYZQdQPNf//ThUmikFpRzezqkpSYtPvEu/Qd+V9JoanaBtUpZyuQVD0tlnUVhWUKxAt 6TB7+5PcFVaw6ng77EARw9pfwvAz0Mh/bN8JM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=tJl7Z1ndJF9W2XewzdCdh2mZPC7iqvkZBQ9GkIDoitwEePROp/Nq5juxYRKsj7xi2M pzkTPlcgRt7FVJGzaS4uLwMVr/PHa09BQvcjlGslN/io+QiKPCEj1QnJs9cAEhTCASYX MH5Y492m/Tz3YgjZf5MQlr3gDd2SxUeU/K9aM= MIME-Version: 1.0 Received: by 10.216.210.206 with SMTP id u56mr653661weo.50.1280434782906; Thu, 29 Jul 2010 13:19:42 -0700 (PDT) Received: by 10.216.152.104 with HTTP; Thu, 29 Jul 2010 13:19:42 -0700 (PDT) In-Reply-To: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> Date: Thu, 29 Jul 2010 22:19:42 +0200 Message-ID: From: Laura Liess To: Cullen Jennings Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 20:19:20 -0000 It works for me. Laura 2010/7/29 Cullen Jennings : > > I tried to write a proposal that I think reflects what the proponents of = this WG want. Here's my stab at it. > > ------------------ > > > Troubleshooting SIP networks can be improved by correlating messaging acr= oss several devices. This working group will define a correlation identifie= r to be used for the troubleshooting and the for correlation of logging inf= ormation from different SIP devices in the network. > > Sip transactions are often triggered by another SIP transaction. Two tran= sactions are in the same "session" if one was triggered by the other due to= redirection, REFER processing, retargeting, or forwarding on a B2BUA. This= working group will define a correlation identifier that identifies =A0all = the transactions in the same session. =A0The scope of the identifier pertai= ns to the SIP signaling layer only, and not media. =A0 For example, several= UA participating in a conference call may be receiving the same media but = would not be in the same session. > > The design of the correlation identifier needs to take into account the i= ssue of not revealing the topology of network. The mechanism should be appl= icable for Proxies, UAs, PBXs, SBCs, Application Servers, Softswitches, Pho= nes, and Gateways. > > This working group will coordinate with other relevant working groups and= area including Ops, and sipcore. > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From victor.pascual.avila@gmail.com Thu Jul 29 15:49:17 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2D403A67E5 for ; Thu, 29 Jul 2010 15:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs8XkHTT87ux for ; Thu, 29 Jul 2010 15:49:15 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id BC61E3A67C3 for ; Thu, 29 Jul 2010 15:49:14 -0700 (PDT) Received: by bwz7 with SMTP id 7so578605bwz.31 for ; Thu, 29 Jul 2010 15:49:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QjlVgjAQp8SGMoW9x49qGGB+teF8ZyvfMe+jvLvJiew=; b=Q2ugoH/wBvcZq2Svco3jKpnR1wacijuSDz6CWfMnaGtZASTTooPZUT1nbr747+rUSK 6MDnZZzhL1IOW4/t1KnhJfhnqR21yYFYwYY0SUfg0zPHcPbnmz5M+8vKqbIU2ikeLiD0 mdVAH9Taao9g2Enj2mBllRStqR0yEB9Lz3r24= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cPdMBSJjXfsurEAza3ytq2fYbTW9ZbkPO4G7+sh91J43UmzodthH8HQ8l8Cx8IQJ/U 84syMge0hi5yjclS2WtDaxSeTFnDH3oJgvKxHuh82m1fls3YWbzQRzTlFxU/eyua4WF5 Zv2Z9NkbB9ZL57Q2dJRuGnK5NXdlP6gm2EHuQ= MIME-Version: 1.0 Received: by 10.204.82.155 with SMTP id b27mr499835bkl.182.1280443777925; Thu, 29 Jul 2010 15:49:37 -0700 (PDT) Received: by 10.204.25.131 with HTTP; Thu, 29 Jul 2010 15:49:37 -0700 (PDT) In-Reply-To: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> Date: Fri, 30 Jul 2010 00:49:37 +0200 Message-ID: From: Victor Pascual Avila To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 22:49:17 -0000 I like it On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings wrote: > > I tried to write a proposal that I think reflects what the proponents of = this WG want. Here's my stab at it. > > ------------------ > > > Troubleshooting SIP networks can be improved by correlating messaging acr= oss several devices. This working group will define a correlation identifie= r to be used for the troubleshooting and the for correlation of logging inf= ormation from different SIP devices in the network. > > Sip transactions are often triggered by another SIP transaction. Two tran= sactions are in the same "session" if one was triggered by the other due to= redirection, REFER processing, retargeting, or forwarding on a B2BUA. This= working group will define a correlation identifier that identifies =C2=A0a= ll the transactions in the same session. =C2=A0The scope of the identifier = pertains to the SIP signaling layer only, and not media. =C2=A0 For example= , several UA participating in a conference call may be receiving the same m= edia but would not be in the same session. > > The design of the correlation identifier needs to take into account the i= ssue of not revealing the topology of network. The mechanism should be appl= icable for Proxies, UAs, PBXs, SBCs, Application Servers, Softswitches, Pho= nes, and Gateways. > > This working group will coordinate with other relevant working groups and= area including Ops, and sipcore. > > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --=20 Victor Pascual =C3=81vila From gao.yang2@zte.com.cn Thu Jul 29 17:38:42 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF773A696D; Thu, 29 Jul 2010 17:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.873 X-Spam-Level: X-Spam-Status: No, score=-97.873 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtTIjjSOF0WZ; Thu, 29 Jul 2010 17:38:41 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id CDCA43A67E1; Thu, 29 Jul 2010 17:38:40 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 35102302718646; Fri, 30 Jul 2010 08:38:16 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 99247.2522988160; Fri, 30 Jul 2010 08:38:51 +0800 (CST) Received: from notes_svr7_1.zte.com.cn ([10.30.1.248]) by mse2.zte.com.cn with ESMTP id o6U0cmCa097160; Fri, 30 Jul 2010 08:38:48 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> To: Cullen Jennings MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 30 Jul 2010 08:37:18 +0800 X-MIMETrack: Serialize by Router on notes_svr7_1/zte_ltd(Release 8.5.1FP2|March 17, 2010) at 2010-07-30 08:35:32, Serialize complete at 2010-07-30 08:35:32 Content-Type: multipart/alternative; boundary="=_alternative 000376E548257770_=" X-MAIL: mse2.zte.com.cn o6U0cmCa097160 Cc: dispatch-bounces@ietf.org, "dispatch@ietf.org list" Subject: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 00:38:42 -0000 This is a multipart message in MIME format. --=_alternative 000376E548257770_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgQ3VsbGVuLA0KDQpJIGFtIGZpbmUgd2l0aCB0aGlzIG9uZSwgYXMgdGhlcmUncyBubyBleHBs aWNpdCBkZW1hbmQgZm9yIFVQREFURWluZyANClJGQzM4OTEuDQoNClRoYW5rcywNCg0KR2FvDQoN Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQog VGVsICAgIDogODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdh by55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0K DQoNCg0KQ3VsbGVuIEplbm5pbmdzIDxmbHVmZnlAY2lzY28uY29tPiANCreivP7IyzogIGRpc3Bh dGNoLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTAtMDctMzAgMDA6MzANCg0KytW8/sjLDQoiZGlzcGF0 Y2hAaWV0Zi5vcmcgbGlzdCIgPGRpc3BhdGNoQGlldGYub3JnPg0Ks63LzQ0KDQrW98ziDQpbZGlz cGF0Y2hdIFByb3Bvc2FsIGZvciBTZXNzaW9uIElEIGNoYXJ0ZXINCg0KDQoNCg0KDQoNCg0KSSB0 cmllZCB0byB3cml0ZSBhIHByb3Bvc2FsIHRoYXQgSSB0aGluayByZWZsZWN0cyB3aGF0IHRoZSBw cm9wb25lbnRzIG9mIA0KdGhpcyBXRyB3YW50LiBIZXJlJ3MgbXkgc3RhYiBhdCBpdC4gDQoNCi0t LS0tLS0tLS0tLS0tLS0tLQ0KDQoNClRyb3VibGVzaG9vdGluZyBTSVAgbmV0d29ya3MgY2FuIGJl IGltcHJvdmVkIGJ5IGNvcnJlbGF0aW5nIG1lc3NhZ2luZyANCmFjcm9zcyBzZXZlcmFsIGRldmlj ZXMuIFRoaXMgd29ya2luZyBncm91cCB3aWxsIGRlZmluZSBhIGNvcnJlbGF0aW9uIA0KaWRlbnRp ZmllciB0byBiZSB1c2VkIGZvciB0aGUgdHJvdWJsZXNob290aW5nIGFuZCB0aGUgZm9yIGNvcnJl bGF0aW9uIG9mIA0KbG9nZ2luZyBpbmZvcm1hdGlvbiBmcm9tIGRpZmZlcmVudCBTSVAgZGV2aWNl cyBpbiB0aGUgbmV0d29yay4gDQoNClNpcCB0cmFuc2FjdGlvbnMgYXJlIG9mdGVuIHRyaWdnZXJl ZCBieSBhbm90aGVyIFNJUCB0cmFuc2FjdGlvbi4gVHdvIA0KdHJhbnNhY3Rpb25zIGFyZSBpbiB0 aGUgc2FtZSAic2Vzc2lvbiIgaWYgb25lIHdhcyB0cmlnZ2VyZWQgYnkgdGhlIG90aGVyIA0KZHVl IHRvIHJlZGlyZWN0aW9uLCBSRUZFUiBwcm9jZXNzaW5nLCByZXRhcmdldGluZywgb3IgZm9yd2Fy ZGluZyBvbiBhIA0KQjJCVUEuIFRoaXMgd29ya2luZyBncm91cCB3aWxsIGRlZmluZSBhIGNvcnJl bGF0aW9uIGlkZW50aWZpZXIgdGhhdCANCmlkZW50aWZpZXMgIGFsbCB0aGUgdHJhbnNhY3Rpb25z IGluIHRoZSBzYW1lIHNlc3Npb24uICBUaGUgc2NvcGUgb2YgdGhlIA0KaWRlbnRpZmllciBwZXJ0 YWlucyB0byB0aGUgU0lQIHNpZ25hbGluZyBsYXllciBvbmx5LCBhbmQgbm90IG1lZGlhLiAgIEZv ciANCmV4YW1wbGUsIHNldmVyYWwgVUEgcGFydGljaXBhdGluZyBpbiBhIGNvbmZlcmVuY2UgY2Fs bCBtYXkgYmUgcmVjZWl2aW5nIA0KdGhlIHNhbWUgbWVkaWEgYnV0IHdvdWxkIG5vdCBiZSBpbiB0 aGUgc2FtZSBzZXNzaW9uLiANCg0KVGhlIGRlc2lnbiBvZiB0aGUgY29ycmVsYXRpb24gaWRlbnRp ZmllciBuZWVkcyB0byB0YWtlIGludG8gYWNjb3VudCB0aGUgDQppc3N1ZSBvZiBub3QgcmV2ZWFs aW5nIHRoZSB0b3BvbG9neSBvZiBuZXR3b3JrLiBUaGUgbWVjaGFuaXNtIHNob3VsZCBiZSANCmFw cGxpY2FibGUgZm9yIFByb3hpZXMsIFVBcywgUEJYcywgU0JDcywgQXBwbGljYXRpb24gU2VydmVy cywgDQpTb2Z0c3dpdGNoZXMsIFBob25lcywgYW5kIEdhdGV3YXlzLiANCg0KVGhpcyB3b3JraW5n IGdyb3VwIHdpbGwgY29vcmRpbmF0ZSB3aXRoIG90aGVyIHJlbGV2YW50IHdvcmtpbmcgZ3JvdXBz IGFuZCANCmFyZWEgaW5jbHVkaW5nIE9wcywgYW5kIHNpcGNvcmUuIA0KDQoNCg0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRpc3BhdGNoIG1h aWxpbmcgbGlzdA0KZGlzcGF0Y2hAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZGlzcGF0Y2gNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5 IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5 IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5p Y2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdh dGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3Nl IHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFp bCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0 byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBB bnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2 aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMg YW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 000376E548257770_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEN1bGxlbiw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYW0gZmluZSB3aXRoIHRo aXMgb25lLCBhcyB0aGVyZSdzDQpubyBleHBsaWNpdCBkZW1hbmQgZm9yIFVQREFURWluZyBSRkMz ODkxLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhh bmtzLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2Fv PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEw MDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4 NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0K PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Q3VsbGVuIEplbm5pbmdzICZsdDtmbHVm ZnlAY2lzY28uY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtkaXNwYXRjaC1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDctMzAgMDA6MzA8L2ZvbnQ+ DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7I yzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7 ZGlzcGF0Y2hAaWV0Zi5vcmcgbGlzdCZxdW90OyAmbHQ7ZGlzcGF0Y2hAaWV0Zi5vcmcmZ3Q7PC9m b250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5b ZGlzcGF0Y2hdIFByb3Bvc2FsIGZvciBTZXNzaW9uIElEIGNoYXJ0ZXI8L2ZvbnQ+PC90YWJsZT4N Cjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+ PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCkkgdHJpZWQg dG8gd3JpdGUgYSBwcm9wb3NhbCB0aGF0IEkgdGhpbmsgcmVmbGVjdHMgd2hhdCB0aGUgcHJvcG9u ZW50cyBvZg0KdGhpcyBXRyB3YW50LiBIZXJlJ3MgbXkgc3RhYiBhdCBpdC4gPGJyPg0KPGJyPg0K LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KPGJyPg0KVHJvdWJsZXNob290aW5nIFNJUCBu ZXR3b3JrcyBjYW4gYmUgaW1wcm92ZWQgYnkgY29ycmVsYXRpbmcgbWVzc2FnaW5nIGFjcm9zcw0K c2V2ZXJhbCBkZXZpY2VzLiBUaGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZWZpbmUgYSBjb3JyZWxh dGlvbiBpZGVudGlmaWVyDQp0byBiZSB1c2VkIGZvciB0aGUgdHJvdWJsZXNob290aW5nIGFuZCB0 aGUgZm9yIGNvcnJlbGF0aW9uIG9mIGxvZ2dpbmcgaW5mb3JtYXRpb24NCmZyb20gZGlmZmVyZW50 IFNJUCBkZXZpY2VzIGluIHRoZSBuZXR3b3JrLiA8YnI+DQo8YnI+DQpTaXAgdHJhbnNhY3Rpb25z IGFyZSBvZnRlbiB0cmlnZ2VyZWQgYnkgYW5vdGhlciBTSVAgdHJhbnNhY3Rpb24uIFR3byB0cmFu c2FjdGlvbnMNCmFyZSBpbiB0aGUgc2FtZSAmcXVvdDtzZXNzaW9uJnF1b3Q7IGlmIG9uZSB3YXMg dHJpZ2dlcmVkIGJ5IHRoZSBvdGhlciBkdWUNCnRvIHJlZGlyZWN0aW9uLCBSRUZFUiBwcm9jZXNz aW5nLCByZXRhcmdldGluZywgb3IgZm9yd2FyZGluZyBvbiBhIEIyQlVBLg0KVGhpcyB3b3JraW5n IGdyb3VwIHdpbGwgZGVmaW5lIGEgY29ycmVsYXRpb24gaWRlbnRpZmllciB0aGF0IGlkZW50aWZp ZXMNCiZuYnNwO2FsbCB0aGUgdHJhbnNhY3Rpb25zIGluIHRoZSBzYW1lIHNlc3Npb24uICZuYnNw O1RoZSBzY29wZSBvZiB0aGUNCmlkZW50aWZpZXIgcGVydGFpbnMgdG8gdGhlIFNJUCBzaWduYWxp bmcgbGF5ZXIgb25seSwgYW5kIG5vdCBtZWRpYS4gJm5ic3A7DQpGb3IgZXhhbXBsZSwgc2V2ZXJh bCBVQSBwYXJ0aWNpcGF0aW5nIGluIGEgY29uZmVyZW5jZSBjYWxsIG1heSBiZSByZWNlaXZpbmcN CnRoZSBzYW1lIG1lZGlhIGJ1dCB3b3VsZCBub3QgYmUgaW4gdGhlIHNhbWUgc2Vzc2lvbi4gPGJy Pg0KPGJyPg0KVGhlIGRlc2lnbiBvZiB0aGUgY29ycmVsYXRpb24gaWRlbnRpZmllciBuZWVkcyB0 byB0YWtlIGludG8gYWNjb3VudCB0aGUNCmlzc3VlIG9mIG5vdCByZXZlYWxpbmcgdGhlIHRvcG9s b2d5IG9mIG5ldHdvcmsuIFRoZSBtZWNoYW5pc20gc2hvdWxkIGJlDQphcHBsaWNhYmxlIGZvciBQ cm94aWVzLCBVQXMsIFBCWHMsIFNCQ3MsIEFwcGxpY2F0aW9uIFNlcnZlcnMsIFNvZnRzd2l0Y2hl cywNClBob25lcywgYW5kIEdhdGV3YXlzLiA8YnI+DQo8YnI+DQpUaGlzIHdvcmtpbmcgZ3JvdXAg d2lsbCBjb29yZGluYXRlIHdpdGggb3RoZXIgcmVsZXZhbnQgd29ya2luZyBncm91cHMgYW5kDQph cmVhIGluY2x1ZGluZyBPcHMsIGFuZCBzaXBjb3JlLiA8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4NCmRpc3BhdGNoIG1haWxpbmcgbGlzdDxicj4NCmRpc3BhdGNoQGlldGYub3Jn PGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kaXNwYXRjaDxicj4N Cjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRp b24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZu YnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3Nv bGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29y Z2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtp cyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92 ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNy ZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJz cDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7 Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7 YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtp dCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7 c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtp bmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5 Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNw O3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3Bs ZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3Ro ZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtp biZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNw O2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2Fu ZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4N CjwvcHJlPg== --=_alternative 000376E548257770_=-- From john.elwell@siemens-enterprise.com Fri Jul 30 00:46:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DF6328C259 for ; Fri, 30 Jul 2010 00:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.883 X-Spam-Level: X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUEYHetj-AOx for ; Fri, 30 Jul 2010 00:46:04 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 6F45928C257 for ; Fri, 30 Jul 2010 00:46:04 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1017082; Fri, 30 Jul 2010 09:46:28 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 1512023F028E; Fri, 30 Jul 2010 09:46:28 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 30 Jul 2010 09:46:28 +0200 From: "Elwell, John" To: Cullen Jennings Date: Fri, 30 Jul 2010 09:46:27 +0200 Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvcFeZLlDXduP0TvWSrwQ06XKjIQASlPsA Message-ID: References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 07:46:06 -0000 Can somebody please remind me why this is scoped only for troubleshooting. = For example, in SIPREC, we anticipate a need for a Session Recording Server= to be able to correlate two recorded sessions from different Session Recor= ding Clients. For example, if a customer call is transferred from one agent= to a second agent, the two agents might be using different Session Recordi= ng Clients to send media to the Session Recording Server. What would be the= barrier to using session ID for this case? Is it just the lack of guarante= ed uniqueness, or are there other factors? John =20 > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Victor Pascual Avila > Sent: 29 July 2010 23:50 > To: Cullen Jennings > Cc: dispatch@ietf.org list > Subject: Re: [dispatch] Proposal for Session ID charter >=20 > I like it >=20 > On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings=20 > wrote: > > > > I tried to write a proposal that I think reflects what the=20 > proponents of this WG want. Here's my stab at it. > > > > ------------------ > > > > > > Troubleshooting SIP networks can be improved by correlating=20 > messaging across several devices. This working group will=20 > define a correlation identifier to be used for the=20 > troubleshooting and the for correlation of logging=20 > information from different SIP devices in the network. > > > > Sip transactions are often triggered by another SIP=20 > transaction. Two transactions are in the same "session" if=20 > one was triggered by the other due to redirection, REFER=20 > processing, retargeting, or forwarding on a B2BUA. This=20 > working group will define a correlation identifier that=20 > identifies =A0all the transactions in the same session. =A0The=20 > scope of the identifier pertains to the SIP signaling layer=20 > only, and not media. =A0 For example, several UA participating=20 > in a conference call may be receiving the same media but=20 > would not be in the same session. > > > > The design of the correlation identifier needs to take into=20 > account the issue of not revealing the topology of network.=20 > The mechanism should be applicable for Proxies, UAs, PBXs,=20 > SBCs, Application Servers, Softswitches, Phones, and Gateways. > > > > This working group will coordinate with other relevant=20 > working groups and area including Ops, and sipcore. > > > > > > > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 >=20 >=20 > --=20 > Victor Pascual =C1vila > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > = From R.Jesske@telekom.de Fri Jul 30 01:13:12 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 369923A6AB6 for ; Fri, 30 Jul 2010 01:13:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.383 X-Spam-Level: X-Spam-Status: No, score=-3.383 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zEaK4n6Yv4H for ; Fri, 30 Jul 2010 01:13:09 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 266BF28C25D for ; Fri, 30 Jul 2010 01:13:06 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 30 Jul 2010 10:13:30 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Jul 2010 10:13:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Jul 2010 10:13:29 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD406689D19@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvO2QHV8FB127MTkSlK4/Bv0lXCAAg6WKw References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> From: To: , X-OriginalArrivalTime: 30 Jul 2010 08:13:30.0311 (UTC) FILETIME=[184C6570:01CB2FBF] Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 08:13:12 -0000 Hi Cullen, Thank you for your proposal. I'm fine with it =20 Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] Im = Auftrag von Cullen Jennings Gesendet: Donnerstag, 29. Juli 2010 18:30 An: dispatch@ietf.org list Betreff: [dispatch] Proposal for Session ID charter I tried to write a proposal that I think reflects what the proponents of = this WG want. Here's my stab at it.=20 ------------------ Troubleshooting SIP networks can be improved by correlating messaging = across several devices. This working group will define a correlation = identifier to be used for the troubleshooting and the for correlation of = logging information from different SIP devices in the network.=20 Sip transactions are often triggered by another SIP transaction. Two = transactions are in the same "session" if one was triggered by the other = due to redirection, REFER processing, retargeting, or forwarding on a = B2BUA. This working group will define a correlation identifier that = identifies all the transactions in the same session. The scope of the = identifier pertains to the SIP signaling layer only, and not media. = For example, several UA participating in a conference call may be = receiving the same media but would not be in the same session.=20 The design of the correlation identifier needs to take into account the = issue of not revealing the topology of network. The mechanism should be = applicable for Proxies, UAs, PBXs, SBCs, Application Servers, = Softswitches, Phones, and Gateways.=20 This working group will coordinate with other relevant working groups = and area including Ops, and sipcore.=20 _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@cisco.com Fri Jul 30 01:21:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFDCB3A6914 for ; Fri, 30 Jul 2010 01:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.574 X-Spam-Level: X-Spam-Status: No, score=-10.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OG3qTTQKHtU6 for ; Fri, 30 Jul 2010 01:21:06 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 8E8923A6A31 for ; Fri, 30 Jul 2010 01:21:06 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,285,1278288000"; d="scan'208";a="141175020" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 30 Jul 2010 08:21:31 +0000 Received: from [10.55.80.151] (dhcp-10-55-80-151.cisco.com [10.55.80.151]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6U8LUaq020071; Fri, 30 Jul 2010 08:21:30 GMT Message-ID: <4C528B89.5090906@cisco.com> Date: Fri, 30 Jul 2010 04:21:29 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Elwell, John" References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 08:21:07 -0000 Elwell, John wrote: > Can somebody please remind me why this is scoped only for troubleshooting. Yeah. This seems to be "that which shall not be spoken". It seems clear that people intend to use this for more than troubleshooting, or else have very broad definitions of what troubleshooting is. ISTM its would be good to have a number of intended uses, so long as they are compatible - can use the same correlation algorithm. OTOH, opening it up that way could lead to a food fight and different uses fight to get a correlation function that meets their needs. Thanks, Paul > For example, in SIPREC, we anticipate a need for a Session Recording Server to be able to correlate two recorded sessions from different Session Recording Clients. For example, if a customer call is transferred from one agent to a second agent, the two agents might be using different Session Recording Clients to send media to the Session Recording Server. What would be the barrier to using session ID for this case? Is it just the lack of guaranteed uniqueness, or are there other factors? > > John > > >> -----Original Message----- >> From: dispatch-bounces@ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Victor Pascual Avila >> Sent: 29 July 2010 23:50 >> To: Cullen Jennings >> Cc: dispatch@ietf.org list >> Subject: Re: [dispatch] Proposal for Session ID charter >> >> I like it >> >> On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings >> wrote: >>> I tried to write a proposal that I think reflects what the >> proponents of this WG want. Here's my stab at it. >>> ------------------ >>> >>> >>> Troubleshooting SIP networks can be improved by correlating >> messaging across several devices. This working group will >> define a correlation identifier to be used for the >> troubleshooting and the for correlation of logging >> information from different SIP devices in the network. >>> Sip transactions are often triggered by another SIP >> transaction. Two transactions are in the same "session" if >> one was triggered by the other due to redirection, REFER >> processing, retargeting, or forwarding on a B2BUA. This >> working group will define a correlation identifier that >> identifies all the transactions in the same session. The >> scope of the identifier pertains to the SIP signaling layer >> only, and not media. For example, several UA participating >> in a conference call may be receiving the same media but >> would not be in the same session. >>> The design of the correlation identifier needs to take into >> account the issue of not revealing the topology of network. >> The mechanism should be applicable for Proxies, UAs, PBXs, >> SBCs, Application Servers, Softswitches, Phones, and Gateways. >>> This working group will coordinate with other relevant >> working groups and area including Ops, and sipcore. >>> >>> >>> >>> >>> >>> _______________________________________________ >>> dispatch mailing list >>> dispatch@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> >> >> -- >> Victor Pascual Ávila >> _______________________________________________ >> 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 john.elwell@siemens-enterprise.com Fri Jul 30 01:33:07 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19C3028C255 for ; Fri, 30 Jul 2010 01:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.878 X-Spam-Level: X-Spam-Status: No, score=-2.878 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mv71CmlE6ZP8 for ; Fri, 30 Jul 2010 01:33:04 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 30D2E28C273 for ; Fri, 30 Jul 2010 01:33:02 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1016328; Fri, 30 Jul 2010 10:33:27 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 093401EB82AB; Fri, 30 Jul 2010 10:33:27 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 30 Jul 2010 10:33:26 +0200 From: "Elwell, John" To: Paul Kyzivat Date: Fri, 30 Jul 2010 10:33:25 +0200 Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvwDgT2PcFvPeXR7aORda/Z64uUQAAQRnA Message-ID: References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> <4C528B89.5090906@cisco.com> In-Reply-To: <4C528B89.5090906@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 08:33:07 -0000 What I was thinking was that it could be used for other purposes "at your o= wn risk". However, if we tried to get this into some other RFC (e.g., if SI= PREC were to need it for correlating two sessions at a session recording se= rver), we might get pushback if the session-ID RFC limits its scope to trou= bleshooting. I wouldn't want to go through the effort of specifying yet ano= ther header field whenever some other usage arises. The trick seems to be to make session-ID sufficiently general purpose witho= ut introducing any disincentive for B2BUA implementers and deployers to use= it correctly. John =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: 30 July 2010 09:21 > To: Elwell, John > Cc: Cullen Jennings; dispatch@ietf.org list > Subject: Re: [dispatch] Proposal for Session ID charter >=20 >=20 >=20 > Elwell, John wrote: > > Can somebody please remind me why this is scoped only for=20 > troubleshooting. >=20 > Yeah. This seems to be "that which shall not be spoken". >=20 > It seems clear that people intend to use this for more than=20 > troubleshooting, or else have very broad definitions of what=20 > troubleshooting is. >=20 > ISTM its would be good to have a number of intended uses, so long as=20 > they are compatible - can use the same correlation algorithm. >=20 > OTOH, opening it up that way could lead to a food fight and different=20 > uses fight to get a correlation function that meets their needs. >=20 > Thanks, > Paul >=20 > > For example, in SIPREC, we anticipate a need for a Session=20 > Recording Server to be able to correlate two recorded=20 > sessions from different Session Recording Clients. For=20 > example, if a customer call is transferred from one agent to=20 > a second agent, the two agents might be using different=20 > Session Recording Clients to send media to the Session=20 > Recording Server. What would be the barrier to using session=20 > ID for this case? Is it just the lack of guaranteed=20 > uniqueness, or are there other factors? > >=20 > > John > > =20 > >=20 > >> -----Original Message----- > >> From: dispatch-bounces@ietf.org=20 > >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Victor=20 > Pascual Avila > >> Sent: 29 July 2010 23:50 > >> To: Cullen Jennings > >> Cc: dispatch@ietf.org list > >> Subject: Re: [dispatch] Proposal for Session ID charter > >> > >> I like it > >> > >> On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings=20 > >> wrote: > >>> I tried to write a proposal that I think reflects what the=20 > >> proponents of this WG want. Here's my stab at it. > >>> ------------------ > >>> > >>> > >>> Troubleshooting SIP networks can be improved by correlating=20 > >> messaging across several devices. This working group will=20 > >> define a correlation identifier to be used for the=20 > >> troubleshooting and the for correlation of logging=20 > >> information from different SIP devices in the network. > >>> Sip transactions are often triggered by another SIP=20 > >> transaction. Two transactions are in the same "session" if=20 > >> one was triggered by the other due to redirection, REFER=20 > >> processing, retargeting, or forwarding on a B2BUA. This=20 > >> working group will define a correlation identifier that=20 > >> identifies all the transactions in the same session. The=20 > >> scope of the identifier pertains to the SIP signaling layer=20 > >> only, and not media. For example, several UA participating=20 > >> in a conference call may be receiving the same media but=20 > >> would not be in the same session. > >>> The design of the correlation identifier needs to take into=20 > >> account the issue of not revealing the topology of network.=20 > >> The mechanism should be applicable for Proxies, UAs, PBXs,=20 > >> SBCs, Application Servers, Softswitches, Phones, and Gateways. > >>> This working group will coordinate with other relevant=20 > >> working groups and area including Ops, and sipcore. > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> dispatch mailing list > >>> dispatch@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dispatch > >>> > >> > >> > >> --=20 > >> Victor Pascual =C1vila > >> _______________________________________________ > >> 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 > = From peter.musgrave@magorcorp.com Fri Jul 30 01:33:55 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135FE28C28B for ; Fri, 30 Jul 2010 01:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59IXPbY5Zwx9 for ; Fri, 30 Jul 2010 01:33:52 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id E66B928C28A for ; Fri, 30 Jul 2010 01:33:51 -0700 (PDT) Received: by gxk1 with SMTP id 1so615484gxk.31 for ; Fri, 30 Jul 2010 01:34:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.152.40 with SMTP id e40mr1710414ano.198.1280478856274; Fri, 30 Jul 2010 01:34:16 -0700 (PDT) Received: by 10.229.129.141 with HTTP; Fri, 30 Jul 2010 01:34:16 -0700 (PDT) In-Reply-To: <4C528B89.5090906@cisco.com> References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> <4C528B89.5090906@cisco.com> Date: Fri, 30 Jul 2010 10:34:16 +0200 Message-ID: From: Peter Musgrave To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 08:33:55 -0000 Hi, IIRC the question Robert Sparks asked at dispatch was part of this. RS: "Does anyone think this provides dialog correlation? It doesn't" I think the issue was that an INVITE which forks and is answered by two parties will have the same SessionID used for what could be viewed as separate logical sessions. In practice - I would expect one branch to get dropped - but it might cause some heartburn in some non-troubleshooting applications of session-ID. Hence the scope appears to be constructed to exclude cases like this. I agree people may use it for more than the defined scope - but the charter is designed to ensure people do this at their own risk and to avoid the debate which other scopes would engender. Peter Musgrave On Fri, Jul 30, 2010 at 10:21 AM, Paul Kyzivat wrote: > > > Elwell, John wrote: >> >> Can somebody please remind me why this is scoped only for troubleshootin= g. > > Yeah. This seems to be "that which shall not be spoken". > > It seems clear that people intend to use this for more than troubleshooti= ng, > or else have very broad definitions of what troubleshooting is. > > ISTM its would be good to have a number of intended uses, so long as they > are compatible - can use the same correlation algorithm. > > OTOH, opening it up that way could lead to a food fight and different use= s > fight to get a correlation function that meets their needs. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> For example, in SIPREC, we anticipate a need for a Session Recording >> Server to be able to correlate two recorded sessions from different Sess= ion >> Recording Clients. For example, if a customer call is transferred from o= ne >> agent to a second agent, the two agents might be using different Session >> Recording Clients to send media to the Session Recording Server. What wo= uld >> be the barrier to using session ID for this case? Is it just the lack of >> guaranteed uniqueness, or are there other factors? >> >> John >> >>> >>> -----Original Message----- >>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>> Behalf Of Victor Pascual Avila >>> Sent: 29 July 2010 23:50 >>> To: Cullen Jennings >>> Cc: dispatch@ietf.org list >>> Subject: Re: [dispatch] Proposal for Session ID charter >>> >>> I like it >>> >>> On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings >>> wrote: >>>> >>>> I tried to write a proposal that I think reflects what the >>> >>> proponents of this WG want. Here's my stab at it. >>>> >>>> ------------------ >>>> >>>> >>>> Troubleshooting SIP networks can be improved by correlating >>> >>> messaging across several devices. This working group will define a >>> correlation identifier to be used for the troubleshooting and the for >>> correlation of logging information from different SIP devices in the >>> network. >>>> >>>> Sip transactions are often triggered by another SIP >>> >>> transaction. Two transactions are in the same "session" if one was >>> triggered by the other due to redirection, REFER processing, retargetin= g, or >>> forwarding on a B2BUA. This working group will define a correlation >>> identifier that identifies =A0all the transactions in the same session.= =A0The >>> scope of the identifier pertains to the SIP signaling layer only, and n= ot >>> media. =A0 For example, several UA participating in a conference call m= ay be >>> receiving the same media but would not be in the same session. >>>> >>>> The design of the correlation identifier needs to take into >>> >>> account the issue of not revealing the topology of network. The mechani= sm >>> should be applicable for Proxies, UAs, PBXs, SBCs, Application Servers, >>> Softswitches, Phones, and Gateways. >>>> >>>> This working group will coordinate with other relevant >>> >>> working groups and area including Ops, and sipcore. >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> dispatch mailing list >>>> dispatch@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> >>> >>> -- >>> Victor Pascual =C1vila >>> _______________________________________________ >>> 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 fluffy@cisco.com Fri Jul 30 01:43:13 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B9A28C27E for ; Fri, 30 Jul 2010 01:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.483 X-Spam-Level: X-Spam-Status: No, score=-110.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Age9akxLZcy2 for ; Fri, 30 Jul 2010 01:42:54 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5D8B628C1AA for ; Fri, 30 Jul 2010 01:42:54 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,285,1278288000"; d="scan'208";a="141179867" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 30 Jul 2010 08:43:17 +0000 Received: from ams3-vpn-dhcp6188.cisco.com (ams3-vpn-dhcp6188.cisco.com [10.61.88.43]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6U8hGGx020272; Fri, 30 Jul 2010 08:43:16 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Cullen Jennings In-Reply-To: Date: Fri, 30 Jul 2010 10:43:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8F047BF4-3504-4594-8077-1A7DF247EAD4@cisco.com> References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> <4C528B89.5090906@cisco.com> To: "Elwell, John" X-Mailer: Apple Mail (2.1081) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 08:43:13 -0000 If folks want to use it for something other than troubleshooting, now = would be the time to talk about that. The charter proposal in this = thread will most likely end up with producing an RFC that is not useful = for much other than troubleshooting. For example, given the way session = is defined here, it does not seem like it would work for SIPREC.=20 On Jul 30, 2010, at 10:33 , Elwell, John wrote: > What I was thinking was that it could be used for other purposes "at = your own risk". However, if we tried to get this into some other RFC = (e.g., if SIPREC were to need it for correlating two sessions at a = session recording server), we might get pushback if the session-ID RFC = limits its scope to troubleshooting. I wouldn't want to go through the = effort of specifying yet another header field whenever some other usage = arises. >=20 > The trick seems to be to make session-ID sufficiently general purpose = without introducing any disincentive for B2BUA implementers and = deployers to use it correctly. >=20 > John >=20 >=20 >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 >> Sent: 30 July 2010 09:21 >> To: Elwell, John >> Cc: Cullen Jennings; dispatch@ietf.org list >> Subject: Re: [dispatch] Proposal for Session ID charter >>=20 >>=20 >>=20 >> Elwell, John wrote: >>> Can somebody please remind me why this is scoped only for=20 >> troubleshooting. >>=20 >> Yeah. This seems to be "that which shall not be spoken". >>=20 >> It seems clear that people intend to use this for more than=20 >> troubleshooting, or else have very broad definitions of what=20 >> troubleshooting is. >>=20 >> ISTM its would be good to have a number of intended uses, so long as=20= >> they are compatible - can use the same correlation algorithm. >>=20 >> OTOH, opening it up that way could lead to a food fight and different=20= >> uses fight to get a correlation function that meets their needs. >>=20 >> Thanks, >> Paul >>=20 >>> For example, in SIPREC, we anticipate a need for a Session=20 >> Recording Server to be able to correlate two recorded=20 >> sessions from different Session Recording Clients. For=20 >> example, if a customer call is transferred from one agent to=20 >> a second agent, the two agents might be using different=20 >> Session Recording Clients to send media to the Session=20 >> Recording Server. What would be the barrier to using session=20 >> ID for this case? Is it just the lack of guaranteed=20 >> uniqueness, or are there other factors? >>>=20 >>> John >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org=20 >>>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Victor=20 >> Pascual Avila >>>> Sent: 29 July 2010 23:50 >>>> To: Cullen Jennings >>>> Cc: dispatch@ietf.org list >>>> Subject: Re: [dispatch] Proposal for Session ID charter >>>>=20 >>>> I like it >>>>=20 >>>> On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings=20 >>>> wrote: >>>>> I tried to write a proposal that I think reflects what the=20 >>>> proponents of this WG want. Here's my stab at it. >>>>> ------------------ >>>>>=20 >>>>>=20 >>>>> Troubleshooting SIP networks can be improved by correlating=20 >>>> messaging across several devices. This working group will=20 >>>> define a correlation identifier to be used for the=20 >>>> troubleshooting and the for correlation of logging=20 >>>> information from different SIP devices in the network. >>>>> Sip transactions are often triggered by another SIP=20 >>>> transaction. Two transactions are in the same "session" if=20 >>>> one was triggered by the other due to redirection, REFER=20 >>>> processing, retargeting, or forwarding on a B2BUA. This=20 >>>> working group will define a correlation identifier that=20 >>>> identifies all the transactions in the same session. The=20 >>>> scope of the identifier pertains to the SIP signaling layer=20 >>>> only, and not media. For example, several UA participating=20 >>>> in a conference call may be receiving the same media but=20 >>>> would not be in the same session. >>>>> The design of the correlation identifier needs to take into=20 >>>> account the issue of not revealing the topology of network.=20 >>>> The mechanism should be applicable for Proxies, UAs, PBXs,=20 >>>> SBCs, Application Servers, Softswitches, Phones, and Gateways. >>>>> This working group will coordinate with other relevant=20 >>>> working groups and area including Ops, and sipcore. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>>=20 >>>>=20 >>>>=20 >>>> --=20 >>>> Victor Pascual =C1vila >>>> _______________________________________________ >>>> 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 >>>=20 >>=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From R.Jesske@telekom.de Fri Jul 30 01:53:36 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BABDC28C2A0 for ; Fri, 30 Jul 2010 01:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.368 X-Spam-Level: X-Spam-Status: No, score=-3.368 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7q8LRxmrXUv5 for ; Fri, 30 Jul 2010 01:53:29 -0700 (PDT) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id 43DBE28C269 for ; Fri, 30 Jul 2010 01:53:20 -0700 (PDT) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail31.telekom.de with ESMTP; 30 Jul 2010 10:53:38 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Jul 2010 10:53:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2FC4.B336FEBF" Date: Fri, 30 Jul 2010 10:53:36 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD406689D61@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: How to proceed with "Reason in responses" Thread-Index: AcsvxLG33Qx1SAb3S4+kcH5O0IhTtw== From: To: X-OriginalArrivalTime: 30 Jul 2010 08:53:38.0093 (UTC) FILETIME=[B372C5D0:01CB2FC4] Subject: [dispatch] How to proceed with "Reason in responses" X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 08:53:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2FC4.B336FEBF Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dear all, The drafts for the "Reason header in Responses" http://tools.ietf.org/html/draft-jesske-dispatch-req-reason-in-responses -01 http://tools.ietf.org/html/draft-jesske-dispatch-reason-in-responses-02 Where discussed over the last coupe of months. The interest of people was not enthusiastic but it was there. So now I would like to ask the group how to proceed. Is there enough interest that we proceed with this drafts within dispatch as a Working Group Item. Or have the people the feeling that I should go for an individual draft, where Gonzalo offered me to sponsor it. Opinions? Thank you and Best Regards Roland ------_=_NextPart_001_01CB2FC4.B336FEBF Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable How to proceed with "Reason in responses"

Dear all,
The drafts for the "Reason header = in Responses"

http://tools.ietf.org/html/draft-jesske-dispatch-req-reaso= n-in-responses-01

http://tools.ietf.org/html/draft-jesske-dispatch-reason-in= -responses-02

Where discussed over the last coupe of = months. The interest of people was not enthusiastic but it was = there.

So now I would like to ask the group = how to proceed. Is there enough interest that we proceed with this = drafts within dispatch as a Working Group Item.

Or have the people the feeling that I = should go for an individual draft, where Gonzalo offered me to sponsor = it.

Opinions?

Thank you and Best Regards

Roland


------_=_NextPart_001_01CB2FC4.B336FEBF-- From mperumal@cisco.com Fri Jul 30 02:04:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A4828C24B for ; Fri, 30 Jul 2010 02:04:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.435 X-Spam-Level: X-Spam-Status: No, score=-9.435 tagged_above=-999 required=5 tests=[AWL=1.164, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48cfmN79lBYL for ; Fri, 30 Jul 2010 02:04:19 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 4CCF33A6AB1 for ; Fri, 30 Jul 2010 02:04:19 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALUxUkxAaHte/2dsb2JhbACgGHGjZJsCgnATCIIuBIQShyUMAQ X-IronPort-AV: E=Sophos;i="4.55,285,1278288000"; d="scan'208";a="165170456" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 30 Jul 2010 09:04:41 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6U93QLH007942; Fri, 30 Jul 2010 09:04:41 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Jul 2010 14:34:30 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Jul 2010 14:34:27 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020341D3C6@XMB-BGL-414.cisco.com> In-Reply-To: <4C528B89.5090906@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvwEBjPpDzxZmQS76Y9TSKbWbHfwAAOdhw References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> <4C528B89.5090906@cisco.com> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 30 Jul 2010 09:04:30.0809 (UTC) FILETIME=[387F5490:01CB2FC6] Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 09:04:20 -0000 If the correlation-id can identify its usage, I don't see why there = would be a food fight. It seems logical for this WG to have an = achievable goal and limit its work to the 'troubleshooting' usage, and = define the rules for passing this id between different SIP entities it = intends to troubleshoot. However, I don't see why we should stop another = WG from defining an entirely different usage of this correlation-id.=20 One way of conveying this usage is using a header parameter, so the = rules defined by this WG would apply when this parameter specifies = 'troubleshooting', which could even be the default usage when one isn't = specified. However, the rules for constructing this correlation-id in = such a way that it doesn't conflict with the policy functions, such as = topology hiding in B2BUAs/SBCs, could remain common to all usages. This seems analogous to STUN -- a tool than can have many usages. Muthu |-----Original Message----- |From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf |Of Paul Kyzivat (pkyzivat) |Sent: Friday, July 30, 2010 1:51 PM |To: Elwell, John |Cc: dispatch@ietf.org list |Subject: Re: [dispatch] Proposal for Session ID charter | |Elwell, John wrote: |> Can somebody please remind me why this is scoped only for = troubleshooting. | |Yeah. This seems to be "that which shall not be spoken". | |It seems clear that people intend to use this for more than |troubleshooting, or else have very broad definitions of what |troubleshooting is. | |ISTM its would be good to have a number of intended uses, so long as |they are compatible - can use the same correlation algorithm. | |OTOH, opening it up that way could lead to a food fight and different |uses fight to get a correlation function that meets their needs. | | Thanks, | Paul | |> For example, in SIPREC, we anticipate a need for a Session Recording |Server to be able to correlate two recorded sessions from different = Session |Recording Clients. For example, if a customer call is transferred from = one |agent to a second agent, the two agents might be using different = Session |Recording Clients to send media to the Session Recording Server. What = would |be the barrier to using session ID for this case? Is it just the lack = of |guaranteed uniqueness, or are there other factors? |> |> John |> |> |>> -----Original Message----- |>> From: dispatch-bounces@ietf.org |>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Victor Pascual Avila |>> Sent: 29 July 2010 23:50 |>> To: Cullen Jennings |>> Cc: dispatch@ietf.org list |>> Subject: Re: [dispatch] Proposal for Session ID charter |>> |>> I like it |>> |>> On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings |>> wrote: |>>> I tried to write a proposal that I think reflects what the |>> proponents of this WG want. Here's my stab at it. |>>> ------------------ |>>> |>>> |>>> Troubleshooting SIP networks can be improved by correlating |>> messaging across several devices. This working group will |>> define a correlation identifier to be used for the |>> troubleshooting and the for correlation of logging |>> information from different SIP devices in the network. |>>> Sip transactions are often triggered by another SIP |>> transaction. Two transactions are in the same "session" if |>> one was triggered by the other due to redirection, REFER |>> processing, retargeting, or forwarding on a B2BUA. This |>> working group will define a correlation identifier that |>> identifies all the transactions in the same session. The |>> scope of the identifier pertains to the SIP signaling layer |>> only, and not media. For example, several UA participating |>> in a conference call may be receiving the same media but |>> would not be in the same session. |>>> The design of the correlation identifier needs to take into |>> account the issue of not revealing the topology of network. |>> The mechanism should be applicable for Proxies, UAs, PBXs, |>> SBCs, Application Servers, Softswitches, Phones, and Gateways. |>>> This working group will coordinate with other relevant |>> working groups and area including Ops, and sipcore. |>>> |>>> |>>> |>>> |>>> |>>> _______________________________________________ |>>> dispatch mailing list |>>> dispatch@ietf.org |>>> https://www.ietf.org/mailman/listinfo/dispatch |>>> |>> |>> |>> -- |>> Victor Pascual =C1vila |>> _______________________________________________ |>> 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 andrew.hutton@siemens-enterprise.com Fri Jul 30 02:23:05 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0DCCF3A69D1 for ; Fri, 30 Jul 2010 02:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T4qgz3fuqO5s for ; Fri, 30 Jul 2010 02:23:03 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 7569B3A6874 for ; Fri, 30 Jul 2010 02:23:03 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1018314; Fri, 30 Jul 2010 11:23:27 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 3837D23F028E; Fri, 30 Jul 2010 11:23:27 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 30 Jul 2010 11:23:27 +0200 From: "Hutton, Andrew" To: "Muthu ArulMozhi Perumal (mperumal)" , "Paul Kyzivat (pkyzivat)" , "Elwell, John" Date: Fri, 30 Jul 2010 11:23:25 +0200 Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvwEBjPpDzxZmQS76Y9TSKbWbHfwAAOdhwAAFhkzA= Message-ID: <101C6067BEC68246B0C3F6843BCCC1E307C82B5F46@MCHP058A.global-ad.net> References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> <4C528B89.5090906@cisco.com> <1D062974A4845E4D8A343C65380492020341D3C6@XMB-BGL-414.cisco.com> In-Reply-To: <1D062974A4845E4D8A343C65380492020341D3C6@XMB-BGL-414.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 09:23:05 -0000 I think it is highly likely that correlating messages across several device= s (I.e. two sides of a B2BUA) is going to be useful for more than just trou= bleshooting and agree that will be tool that can have many usages. However the originator of the identifier cannot be expected to know what it= is going to be used for so having an parameter specifying the usage does n= ot make sense to me. One example of how this might be useful to SIPREC is that it could be used = to enable the recording system to identify that it recording the same sessi= on by two different recording clients.=20 I would like to see the charter for the session ID working group being less= specific about the usage and the solution to allow the WG to formulate the= use cases and associated requirements. Maybe this may result in more work = for the WG but that would be better than having multiple solutions for esse= ntially the same problem. Regards Andy > -----Original Message----- > From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf Of Muthu=20 > ArulMozhi Perumal (mperumal) > Sent: 30 July 2010 11:04 > To: Paul Kyzivat (pkyzivat); Elwell, John > Cc: dispatch@ietf.org > Subject: Re: [dispatch] Proposal for Session ID charter >=20 > If the correlation-id can identify its usage, I don't see why=20 > there would be a food fight. It seems logical for this WG to=20 > have an achievable goal and limit its work to the=20 > 'troubleshooting' usage, and define the rules for passing=20 > this id between different SIP entities it intends to=20 > troubleshoot. However, I don't see why we should stop another=20 > WG from defining an entirely different usage of this correlation-id.=20 >=20 > One way of conveying this usage is using a header parameter,=20 > so the rules defined by this WG would apply when this=20 > parameter specifies 'troubleshooting', which could even be=20 > the default usage when one isn't specified. However, the=20 > rules for constructing this correlation-id in such a way that=20 > it doesn't conflict with the policy functions, such as=20 > topology hiding in B2BUAs/SBCs, could remain common to all usages. >=20 > This seems analogous to STUN -- a tool than can have many usages. >=20 > Muthu >=20 > |-----Original Message----- > |From: dispatch-bounces@ietf.org=20 > [mailto:dispatch-bounces@ietf.org] On Behalf > |Of Paul Kyzivat (pkyzivat) > |Sent: Friday, July 30, 2010 1:51 PM > |To: Elwell, John > |Cc: dispatch@ietf.org list > |Subject: Re: [dispatch] Proposal for Session ID charter > | > |Elwell, John wrote: > |> Can somebody please remind me why this is scoped only for=20 > troubleshooting. > | > |Yeah. This seems to be "that which shall not be spoken". > | > |It seems clear that people intend to use this for more than > |troubleshooting, or else have very broad definitions of what > |troubleshooting is. > | > |ISTM its would be good to have a number of intended uses, so long as > |they are compatible - can use the same correlation algorithm. > | > |OTOH, opening it up that way could lead to a food fight and different > |uses fight to get a correlation function that meets their needs. > | > | Thanks, > | Paul > | > |> For example, in SIPREC, we anticipate a need for a Session=20 > Recording > |Server to be able to correlate two recorded sessions from=20 > different Session > |Recording Clients. For example, if a customer call is=20 > transferred from one > |agent to a second agent, the two agents might be using=20 > different Session > |Recording Clients to send media to the Session Recording=20 > Server. What would > |be the barrier to using session ID for this case? Is it just=20 > the lack of > |guaranteed uniqueness, or are there other factors? > |> > |> John > |> > |> > |>> -----Original Message----- > |>> From: dispatch-bounces@ietf.org > |>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Victor=20 > Pascual Avila > |>> Sent: 29 July 2010 23:50 > |>> To: Cullen Jennings > |>> Cc: dispatch@ietf.org list > |>> Subject: Re: [dispatch] Proposal for Session ID charter > |>> > |>> I like it > |>> > |>> On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings > |>> wrote: > |>>> I tried to write a proposal that I think reflects what the > |>> proponents of this WG want. Here's my stab at it. > |>>> ------------------ > |>>> > |>>> > |>>> Troubleshooting SIP networks can be improved by correlating > |>> messaging across several devices. This working group will > |>> define a correlation identifier to be used for the > |>> troubleshooting and the for correlation of logging > |>> information from different SIP devices in the network. > |>>> Sip transactions are often triggered by another SIP > |>> transaction. Two transactions are in the same "session" if > |>> one was triggered by the other due to redirection, REFER > |>> processing, retargeting, or forwarding on a B2BUA. This > |>> working group will define a correlation identifier that > |>> identifies all the transactions in the same session. The > |>> scope of the identifier pertains to the SIP signaling layer > |>> only, and not media. For example, several UA participating > |>> in a conference call may be receiving the same media but > |>> would not be in the same session. > |>>> The design of the correlation identifier needs to take into > |>> account the issue of not revealing the topology of network. > |>> The mechanism should be applicable for Proxies, UAs, PBXs, > |>> SBCs, Application Servers, Softswitches, Phones, and Gateways. > |>>> This working group will coordinate with other relevant > |>> working groups and area including Ops, and sipcore. > |>>> > |>>> > |>>> > |>>> > |>>> > |>>> _______________________________________________ > |>>> dispatch mailing list > |>>> dispatch@ietf.org > |>>> https://www.ietf.org/mailman/listinfo/dispatch > |>>> > |>> > |>> > |>> -- > |>> Victor Pascual =C1vila > |>> _______________________________________________ > |>> 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 > = From mperumal@cisco.com Fri Jul 30 02:42:47 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12E128C2A7 for ; Fri, 30 Jul 2010 02:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.518 X-Spam-Level: X-Spam-Status: No, score=-9.518 tagged_above=-999 required=5 tests=[AWL=1.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO92KHETMN2M for ; Fri, 30 Jul 2010 02:42:45 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 93C4028C28A for ; Fri, 30 Jul 2010 02:42:45 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL47UkxAaHte/2dsb2JhbACgF3GjWpsJgnATCIIuBIQShyUMAQ X-IronPort-AV: E=Sophos;i="4.55,286,1278288000"; d="scan'208";a="566046982" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-6.cisco.com with ESMTP; 30 Jul 2010 09:43:09 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6U9gxH4018549; Fri, 30 Jul 2010 09:43:08 GMT Received: from xmb-bgl-414.cisco.com ([72.163.129.210]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Jul 2010 15:13:04 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Jul 2010 15:13:02 +0530 Message-ID: <1D062974A4845E4D8A343C65380492020341D3E3@XMB-BGL-414.cisco.com> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E307C82B5F46@MCHP058A.global-ad.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvwEBjPpDzxZmQS76Y9TSKbWbHfwAAOdhwAAFhkzAAAK+OsA== References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com><4C528B89.5090906@cisco.com> <1D062974A4845E4D8A343C65380492020341D3C6@XMB-BGL-414.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E307C82B5F46@MCHP058A.global-ad.net> From: "Muthu ArulMozhi Perumal (mperumal)" To: "Hutton, Andrew" , "Paul Kyzivat (pkyzivat)" , "Elwell, John" X-OriginalArrivalTime: 30 Jul 2010 09:43:04.0752 (UTC) FILETIME=[9BB70300:01CB2FCB] Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 09:42:47 -0000 |However the originator of the identifier cannot be expected to know |what it is going to be used for Two possible approaches: 1. Use different ids for different usages, so an intermediary would = insert a new id at the point from which a new type of correlation is = required. 2. Allow an intermediary to add another usage and then define the set of = rules that should be applied when two or more usages are specified. |I would like to see the charter for the session ID working group=20 |being less specific about the usage and the solution to allow the |WG to formulate the use cases and associated requirements. Sure, but considering the fact that people can come up with numerous = usages of this correlation-id, it seems this WG might find it difficult = to freeze on a limited set of them. Muthu |-----Original Message----- |From: Hutton, Andrew [mailto:andrew.hutton@siemens-enterprise.com] |Sent: Friday, July 30, 2010 2:53 PM |To: Muthu ArulMozhi Perumal (mperumal); Paul Kyzivat (pkyzivat); = Elwell, |John |Cc: dispatch@ietf.org |Subject: RE: [dispatch] Proposal for Session ID charter | | |I think it is highly likely that correlating messages across several = devices |(I.e. two sides of a B2BUA) is going to be useful for more than just |troubleshooting and agree that will be tool that can have many usages. | |However the originator of the identifier cannot be expected to know = what it |is going to be used for so having an parameter specifying the usage = does not |make sense to me. | |One example of how this might be useful to SIPREC is that it could be = used |to enable the recording system to identify that it recording the same |session by two different recording clients. | |I would like to see the charter for the session ID working group being = less |specific about the usage and the solution to allow the WG to formulate = the |use cases and associated requirements. Maybe this may result in more = work |for the WG but that would be better than having multiple solutions for |essentially the same problem. | |Regards |Andy | | | |> -----Original Message----- |> From: dispatch-bounces@ietf.org |> [mailto:dispatch-bounces@ietf.org] On Behalf Of Muthu |> ArulMozhi Perumal (mperumal) |> Sent: 30 July 2010 11:04 |> To: Paul Kyzivat (pkyzivat); Elwell, John |> Cc: dispatch@ietf.org |> Subject: Re: [dispatch] Proposal for Session ID charter |> |> If the correlation-id can identify its usage, I don't see why |> there would be a food fight. It seems logical for this WG to |> have an achievable goal and limit its work to the |> 'troubleshooting' usage, and define the rules for passing |> this id between different SIP entities it intends to |> troubleshoot. However, I don't see why we should stop another |> WG from defining an entirely different usage of this correlation-id. |> |> One way of conveying this usage is using a header parameter, |> so the rules defined by this WG would apply when this |> parameter specifies 'troubleshooting', which could even be |> the default usage when one isn't specified. However, the |> rules for constructing this correlation-id in such a way that |> it doesn't conflict with the policy functions, such as |> topology hiding in B2BUAs/SBCs, could remain common to all usages. |> |> This seems analogous to STUN -- a tool than can have many usages. |> |> Muthu |> |> |-----Original Message----- |> |From: dispatch-bounces@ietf.org |> [mailto:dispatch-bounces@ietf.org] On Behalf |> |Of Paul Kyzivat (pkyzivat) |> |Sent: Friday, July 30, 2010 1:51 PM |> |To: Elwell, John |> |Cc: dispatch@ietf.org list |> |Subject: Re: [dispatch] Proposal for Session ID charter |> | |> |Elwell, John wrote: |> |> Can somebody please remind me why this is scoped only for |> troubleshooting. |> | |> |Yeah. This seems to be "that which shall not be spoken". |> | |> |It seems clear that people intend to use this for more than |> |troubleshooting, or else have very broad definitions of what |> |troubleshooting is. |> | |> |ISTM its would be good to have a number of intended uses, so long as |> |they are compatible - can use the same correlation algorithm. |> | |> |OTOH, opening it up that way could lead to a food fight and = different |> |uses fight to get a correlation function that meets their needs. |> | |> | Thanks, |> | Paul |> | |> |> For example, in SIPREC, we anticipate a need for a Session |> Recording |> |Server to be able to correlate two recorded sessions from |> different Session |> |Recording Clients. For example, if a customer call is |> transferred from one |> |agent to a second agent, the two agents might be using |> different Session |> |Recording Clients to send media to the Session Recording |> Server. What would |> |be the barrier to using session ID for this case? Is it just |> the lack of |> |guaranteed uniqueness, or are there other factors? |> |> |> |> John |> |> |> |> |> |>> -----Original Message----- |> |>> From: dispatch-bounces@ietf.org |> |>> [mailto:dispatch-bounces@ietf.org] On Behalf Of Victor |> Pascual Avila |> |>> Sent: 29 July 2010 23:50 |> |>> To: Cullen Jennings |> |>> Cc: dispatch@ietf.org list |> |>> Subject: Re: [dispatch] Proposal for Session ID charter |> |>> |> |>> I like it |> |>> |> |>> On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings |> |>> wrote: |> |>>> I tried to write a proposal that I think reflects what the |> |>> proponents of this WG want. Here's my stab at it. |> |>>> ------------------ |> |>>> |> |>>> |> |>>> Troubleshooting SIP networks can be improved by correlating |> |>> messaging across several devices. This working group will |> |>> define a correlation identifier to be used for the |> |>> troubleshooting and the for correlation of logging |> |>> information from different SIP devices in the network. |> |>>> Sip transactions are often triggered by another SIP |> |>> transaction. Two transactions are in the same "session" if |> |>> one was triggered by the other due to redirection, REFER |> |>> processing, retargeting, or forwarding on a B2BUA. This |> |>> working group will define a correlation identifier that |> |>> identifies all the transactions in the same session. The |> |>> scope of the identifier pertains to the SIP signaling layer |> |>> only, and not media. For example, several UA participating |> |>> in a conference call may be receiving the same media but |> |>> would not be in the same session. |> |>>> The design of the correlation identifier needs to take into |> |>> account the issue of not revealing the topology of network. |> |>> The mechanism should be applicable for Proxies, UAs, PBXs, |> |>> SBCs, Application Servers, Softswitches, Phones, and Gateways. |> |>>> This working group will coordinate with other relevant |> |>> working groups and area including Ops, and sipcore. |> |>>> |> |>>> |> |>>> |> |>>> |> |>>> |> |>>> _______________________________________________ |> |>>> dispatch mailing list |> |>>> dispatch@ietf.org |> |>>> https://www.ietf.org/mailman/listinfo/dispatch |> |>>> |> |>> |> |>> |> |>> -- |> |>> Victor Pascual =C1vila |> |>> _______________________________________________ |> |>> 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 |> From pkyzivat@cisco.com Fri Jul 30 03:07:21 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150FC3A681D for ; Fri, 30 Jul 2010 03:07:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.425 X-Spam-Level: X-Spam-Status: No, score=-9.425 tagged_above=-999 required=5 tests=[AWL=-1.126, BAYES_00=-2.599, MANGLED_BELOW=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pCVtgsl+DJw for ; Fri, 30 Jul 2010 03:07:19 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2DF9C3A6814 for ; Fri, 30 Jul 2010 03:07:19 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJpBUkxAZnwN/2dsb2JhbACgF3GjVZsOgwMIgi4EiHo X-IronPort-AV: E=Sophos;i="4.55,286,1278288000"; d="scan'208";a="141162710" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 30 Jul 2010 10:07:43 +0000 Received: from [10.55.80.151] (dhcp-10-55-80-151.cisco.com [10.55.80.151]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6UA7g30020001; Fri, 30 Jul 2010 10:07:43 GMT Message-ID: <4C52A46E.1070305@cisco.com> Date: Fri, 30 Jul 2010 06:07:42 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Peter Musgrave References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> <4C528B89.5090906@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 10:07:21 -0000 There are two "risks" to scoping this so narrowly: 1) "troubleshooting" is quite a broad and vague application. The correlation adopted will facilitate some class of issues, depending on the correlation function chosen. Some are likely to be disappointed. (I consider this risk to be "low", as those who care should speak up now. And possibly an upward compatible extension could be done later if the need were found.) 2) Other applications that require correlation of some class of related dialogs for some purpose other than troubleshooting are driven away, and so must define yet another header and id for their own purposes. (Whether this is bad or not is debatable. I know there are currently proprietary headers for such purposes, and *that* isn't so helpful in interop situations.) Thanks, Paul Peter Musgrave wrote: > Hi, > > IIRC the question Robert Sparks asked at dispatch was part of this. > > RS: "Does anyone think this provides dialog correlation? It doesn't" > > I think the issue was that an INVITE which forks and is answered by > two parties will have the same SessionID used for what could be viewed > as separate logical sessions. > > In practice - I would expect one branch to get dropped - but it might > cause some heartburn in some non-troubleshooting applications of > session-ID. Hence the scope appears to be constructed to exclude cases > like this. I agree people may use it for more than the defined scope - > but the charter is designed to ensure people do this at their own risk > and to avoid the debate which other scopes would engender. > > Peter Musgrave > > On Fri, Jul 30, 2010 at 10:21 AM, Paul Kyzivat wrote: >> >> Elwell, John wrote: >>> Can somebody please remind me why this is scoped only for troubleshooting. >> Yeah. This seems to be "that which shall not be spoken". >> >> It seems clear that people intend to use this for more than troubleshooting, >> or else have very broad definitions of what troubleshooting is. >> >> ISTM its would be good to have a number of intended uses, so long as they >> are compatible - can use the same correlation algorithm. >> >> OTOH, opening it up that way could lead to a food fight and different uses >> fight to get a correlation function that meets their needs. >> >> Thanks, >> Paul >> >>> For example, in SIPREC, we anticipate a need for a Session Recording >>> Server to be able to correlate two recorded sessions from different Session >>> Recording Clients. For example, if a customer call is transferred from one >>> agent to a second agent, the two agents might be using different Session >>> Recording Clients to send media to the Session Recording Server. What would >>> be the barrier to using session ID for this case? Is it just the lack of >>> guaranteed uniqueness, or are there other factors? >>> >>> John >>> >>>> -----Original Message----- >>>> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >>>> Behalf Of Victor Pascual Avila >>>> Sent: 29 July 2010 23:50 >>>> To: Cullen Jennings >>>> Cc: dispatch@ietf.org list >>>> Subject: Re: [dispatch] Proposal for Session ID charter >>>> >>>> I like it >>>> >>>> On Thu, Jul 29, 2010 at 6:30 PM, Cullen Jennings >>>> wrote: >>>>> I tried to write a proposal that I think reflects what the >>>> proponents of this WG want. Here's my stab at it. >>>>> ------------------ >>>>> >>>>> >>>>> Troubleshooting SIP networks can be improved by correlating >>>> messaging across several devices. This working group will define a >>>> correlation identifier to be used for the troubleshooting and the for >>>> correlation of logging information from different SIP devices in the >>>> network. >>>>> Sip transactions are often triggered by another SIP >>>> transaction. Two transactions are in the same "session" if one was >>>> triggered by the other due to redirection, REFER processing, retargeting, or >>>> forwarding on a B2BUA. This working group will define a correlation >>>> identifier that identifies all the transactions in the same session. The >>>> scope of the identifier pertains to the SIP signaling layer only, and not >>>> media. For example, several UA participating in a conference call may be >>>> receiving the same media but would not be in the same session. >>>>> The design of the correlation identifier needs to take into >>>> account the issue of not revealing the topology of network. The mechanism >>>> should be applicable for Proxies, UAs, PBXs, SBCs, Application Servers, >>>> Softswitches, Phones, and Gateways. >>>>> This working group will coordinate with other relevant >>>> working groups and area including Ops, and sipcore. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> dispatch mailing list >>>>> dispatch@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/dispatch >>>>> >>>> >>>> -- >>>> Victor Pascual Ávila >>>> _______________________________________________ >>>> 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 HKaplan@acmepacket.com Fri Jul 30 03:35:43 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D433A6823 for ; Fri, 30 Jul 2010 03:35:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iq9SqB9cVtkt for ; Fri, 30 Jul 2010 03:35:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 72D243A6872 for ; Fri, 30 Jul 2010 03:35:14 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 30 Jul 2010 06:35:33 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 30 Jul 2010 06:35:16 -0400 From: Hadriel Kaplan To: "Elwell, John" , Cullen Jennings Date: Fri, 30 Jul 2010 06:35:14 -0400 Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvcFeZLlDXduP0TvWSrwQ06XKjIQASlPsAAAOXpmA= Message-ID: <430FC6BDED356B4C8498F634416644A92694002E5D@mail> References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 10:35:43 -0000 Hey John, I have been told siprec would need it, but whenever I ask someone why it ne= eds it no one can give me a clear answer. As far as I can tell it doesn't.= I know that in some current recording environments we use a call identifi= er value other than Call-ID and tags, but as far as I can tell it's not the= same as session-id would be. As for why only troubleshooting - it's because every use-case we can think = of for session-id has the potential to cause a middlebox to change the sess= ion-id, nullifying its value for troubleshooting. I'm thinking that in the= next rev of session-id draft I should actually add an appendix describing = those use-cases and why it's dangerous for them. -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Elwell, John > Sent: Friday, July 30, 2010 3:46 AM >=20 > Can somebody please remind me why this is scoped only for troubleshooting= . > For example, in SIPREC, we anticipate a need for a Session Recording > Server to be able to correlate two recorded sessions from different > Session Recording Clients. For example, if a customer call is transferred > from one agent to a second agent, the two agents might be using different > Session Recording Clients to send media to the Session Recording Server. > What would be the barrier to using session ID for this case? Is it just > the lack of guaranteed uniqueness, or are there other factors? >=20 From HKaplan@acmepacket.com Fri Jul 30 04:40:03 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 608DA3A63D3 for ; Fri, 30 Jul 2010 04:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id na23ugPYQc-X for ; Fri, 30 Jul 2010 04:40:02 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 486613A68D9 for ; Fri, 30 Jul 2010 04:40:02 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 30 Jul 2010 07:40:23 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 30 Jul 2010 07:40:00 -0400 From: Hadriel Kaplan To: "Hutton, Andrew" , "Muthu ArulMozhi Perumal (mperumal)" , "Paul Kyzivat (pkyzivat)" , "Elwell, John" Date: Fri, 30 Jul 2010 07:39:57 -0400 Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvwEBjPpDzxZmQS76Y9TSKbWbHfwAAOdhwAAFhkzAABFkTAA== Message-ID: <430FC6BDED356B4C8498F634416644A92694002E68@mail> References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> <4C528B89.5090906@cisco.com> <1D062974A4845E4D8A343C65380492020341D3C6@XMB-BGL-414.cisco.com> <101C6067BEC68246B0C3F6843BCCC1E307C82B5F46@MCHP058A.global-ad.net> In-Reply-To: <101C6067BEC68246B0C3F6843BCCC1E307C82B5F46@MCHP058A.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 11:40:03 -0000 Is the requirement for SIPREC to correlate two SIP dialogs/messages as the = same session, or is it really to correlate *media* streams as the same *med= ia* session? As far as I can tell, it's media streams you care about, not = SIP messages. That's a different problem. For example, if there are two SIP sessions whi= ch are members of the same conference call, do you need to know they're the= same or do you want to see them as separate? Or for example in a forked c= all in which both forks end up being answered and survive, would both forks= be considered the same session for recording or two separate ones? Or for= call-transferred calls, there are specific cases in which session-id will = end up with two different id's for the final session (different on each sid= e of a b2bua), which is arguably an acceptable deficiency of session-id for= troubleshooting, but probably not for recording. But IMHO, ultimately it doesn't matter even if they *are* the same semantic= s and scenarios. Because as soon as you use session-id for Recording, some= one will be compelled to change the session-id value in certain call cases = - for example, so that they are recorded as separate sessions - at which po= int session-id's troubleshooting benefits go away. -hadriel > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Hutton, Andrew > Sent: Friday, July 30, 2010 5:23 AM >=20 > I think it is highly likely that correlating messages across several > devices (I.e. two sides of a B2BUA) is going to be useful for more than > just troubleshooting and agree that will be tool that can have many usage= s. >=20 > However the originator of the identifier cannot be expected to know what > it is going to be used for so having an parameter specifying the usage > does not make sense to me. >=20 > One example of how this might be useful to SIPREC is that it could be use= d > to enable the recording system to identify that it recording the same > session by two different recording clients. >=20 > I would like to see the charter for the session ID working group being > less specific about the usage and the solution to allow the WG to > formulate the use cases and associated requirements. Maybe this may resul= t > in more work for the WG but that would be better than having multiple > solutions for essentially the same problem. >=20 > Regards > Andy From HKaplan@acmepacket.com Fri Jul 30 04:44:20 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 663CE3A63D3 for ; Fri, 30 Jul 2010 04:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xzhblqaUVSZ for ; Fri, 30 Jul 2010 04:44:19 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 34B833A63EC for ; Fri, 30 Jul 2010 04:44:19 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 30 Jul 2010 07:44:43 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 30 Jul 2010 07:44:22 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Peter Musgrave Date: Fri, 30 Jul 2010 07:44:21 -0400 Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvzxBsafq1F/F2TyimIJKjLTIAkgADQTWQ Message-ID: <430FC6BDED356B4C8498F634416644A92694002E6A@mail> References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> <4C528B89.5090906@cisco.com> <4C52A46E.1070305@cisco.com> In-Reply-To: <4C52A46E.1070305@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 11:44:20 -0000 > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Friday, July 30, 2010 6:08 AM >=20 > 2) Other applications that require correlation of some class of > related dialogs for some purpose other than troubleshooting > are driven away, and so must define yet another header and id > for their own purposes. I know adding more headers sucks. But that may be the safest thing. -hadriel From partr@cisco.com Fri Jul 30 05:17:15 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D163B3A68E7 for ; Fri, 30 Jul 2010 05:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.886 X-Spam-Level: X-Spam-Status: No, score=-9.886 tagged_above=-999 required=5 tests=[AWL=0.713, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p2SZha20LsR for ; Fri, 30 Jul 2010 05:17:13 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 52CEA3A6926 for ; Fri, 30 Jul 2010 05:17:13 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAB5gUkxAaHte/2dsb2JhbACgF3GkKpsNgnCCSQSEE4clDAE X-IronPort-AV: E=Sophos;i="4.55,287,1278288000"; d="scan'208";a="233070819" Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-5.cisco.com with ESMTP; 30 Jul 2010 12:17:36 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6UCHZhI019391; Fri, 30 Jul 2010 12:17:35 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Jul 2010 17:47:35 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 30 Jul 2010 17:47:33 +0530 Message-ID: In-Reply-To: <430FC6BDED356B4C8498F634416644A92694002E6A@mail> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: AcsvzxBsafq1F/F2TyimIJKjLTIAkgADQTWQAABlmWA= References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com><4C528B89.5090906@cisco.com><4C52A46E.1070305@cisco.com> <430FC6BDED356B4C8498F634416644A92694002E6A@mail> From: "Parthasarathi R (partr)" To: "Hadriel Kaplan" , "Paul Kyzivat (pkyzivat)" , "Peter Musgrave" X-OriginalArrivalTime: 30 Jul 2010 12:17:35.0510 (UTC) FILETIME=[31846B60:01CB2FE1] Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 12:17:15 -0000 Hadriel, Instead working with solution in mind, Shall we start with the usecases document. The usecase document will help us to decide whether the single header or multiple header required. It will help to identify the generic session-id if one exists. The usecase requirement will be very useful as we are talking about the complex dialog scenarios which involves set of B2BUA.=20 As I mentioned in the earlier mail thread, I'll come up with the usecase document as a starting point, add more relevant usecases and we will brainstorm whether the usecases are relevant for the session id or not. Please let me know your opinion on the same. Thanks Partha=20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Friday, July 30, 2010 5:14 PM To: Paul Kyzivat (pkyzivat); Peter Musgrave Cc: dispatch@ietf.org list Subject: Re: [dispatch] Proposal for Session ID charter > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: Friday, July 30, 2010 6:08 AM >=20 > 2) Other applications that require correlation of some class of > related dialogs for some purpose other than troubleshooting > are driven away, and so must define yet another header and id > for their own purposes. I know adding more headers sucks. But that may be the safest thing. -hadriel _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From toto.shyardi@gmail.com Fri Jul 30 05:51:34 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1AC53A69AA for ; Fri, 30 Jul 2010 05:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2C+1TNGqUTm7 for ; Fri, 30 Jul 2010 05:51:26 -0700 (PDT) Received: from mail-px0-f172.google.com (mail-px0-f172.google.com [209.85.212.172]) by core3.amsl.com (Postfix) with ESMTP id 5361A3A6944 for ; Fri, 30 Jul 2010 05:51:26 -0700 (PDT) Received: by pxi20 with SMTP id 20so589577pxi.31 for ; Fri, 30 Jul 2010 05:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=GQkiElbbMaIOXLo5Cay17jceqpFmk99tF5myA48of/M=; b=H9+lZE85EwhbzAwPZxk4vgYBEW96Cigu77q3pad8jqfv2WoWx4HXicY+0/TLt/24NU w/bffgSUocufR/PpAJpWXmtRhVjPfI77LKB0qQPgnU6pZ0QJ/uyVZJUNYHCZ1ViymUuI dsS+P/S6YL0++vDP+A8gBWhFwgAtZuQ/jaFaw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JokfQ0K3HK/S+viuffAR+P7a6eDEyGDkvfg2PUPoGXDTA/WX7OGyxM5TEY+b2Bq3rC LsD/xDlFL3MhwM3998k43IT7pdg5VjkgTKbq44o4gTziKsIuC52yyImJ5FKHfnfkFcfY RvyHwX/2XL9tHefkmeOKpYMsEgnHdmMwBMsA4= MIME-Version: 1.0 Received: by 10.143.153.40 with SMTP id f40mr1609007wfo.47.1280494307779; Fri, 30 Jul 2010 05:51:47 -0700 (PDT) Received: by 10.220.175.131 with HTTP; Fri, 30 Jul 2010 05:51:47 -0700 (PDT) In-Reply-To: References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com> <4C528B89.5090906@cisco.com> <4C52A46E.1070305@cisco.com> <430FC6BDED356B4C8498F634416644A92694002E6A@mail> Date: Fri, 30 Jul 2010 07:51:47 -0500 Message-ID: From: Toto Shyardi To: "Parthasarathi R (partr)" Content-Type: multipart/alternative; boundary=001636e0ba395a23f8048c9a50dc Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 12:51:34 -0000 --001636e0ba395a23f8048c9a50dc Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jul 30, 2010 at 7:17 AM, Parthasarathi R (partr) wrote: > Hadriel, > > Instead working with solution in mind, Shall we start with the usecases > document. The usecase document will help us to decide whether the single > Short of the IETF solution, the 3GPP invented its own "session-id" for the following application: 1. Assume UA-a has a voice dialog with UA-b (over access network X), and there is a B2BUA between them. 2. During the voice dialog, the UA-a roams into access network Y. There is a "small" overlap between networks X and Y (i.e. X*Y), and the UA-a is a dual-radio device (it can simultaneously transmit in X and Y). 3. While in X*Y, UA-a establishes a second dialog (over Y), and indicates to the UA-b that *this dialog replaced the original dialog *(by specifying the dialog-id between the UA-a and B2BUA). It also terminates the original dialog over the network X. 4. Obviously, the "handoff" fails, since the original dialog between the UA-a and the B2BUA has different dialog-id then the dialog between the B2BUA and the UA-b. Hence, the need for some "session-id" that consists of concatenated dialogs. Toto --001636e0ba395a23f8048c9a50dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jul 30, 2010 at 7:17 AM, Parthas= arathi R (partr) <p= artr@cisco.com> wrote:
Hadriel,

Instead working with solution in mind, Shall we start with the usecases
document. The usecase document will help us to decide whether the single



<= span style=3D"font-family: "Times New Roman";">Short of the IETF = solution, the 3GPP invented its own "session-id" for the following application:

=C2=A0

1. Assume UA-a has a voice dialog with UA-b (over access network X= ), and there is a B2BUA between them.

2. During the voice dialog, the UA-a roams into access network Y. = There is a "small" overlap between networks X and Y (i.e. X*Y), and the UA-a is a dual-radio device (it can simultaneously transmit in X and Y).

3. While in X*Y, UA-a establishes a second dialog (over Y), and indicates to the UA-b that this dialog replaced the original dialog = (by specifying the dialog-id between the UA-a and B2BUA). It also terminates the original dial= og over the network X.

4. Obviously, the "handoff" fails, since the original dialog between the UA-a and the B2BUA has different dialog-id then the dial= og between the B2BUA and the UA-b.

=C2=A0

Hence, the need for some "session-id" that consists of concatenated dialogs.

=C2=A0

Toto

=C2=A0

--001636e0ba395a23f8048c9a50dc-- From partr@cisco.com Fri Jul 30 06:05:30 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA9A23A69D2 for ; Fri, 30 Jul 2010 06:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.945 X-Spam-Level: X-Spam-Status: No, score=-9.945 tagged_above=-999 required=5 tests=[AWL=0.653, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4E4aTBuNuKq for ; Fri, 30 Jul 2010 06:05:29 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3B3773A69A0 for ; Fri, 30 Jul 2010 06:05:29 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMFAJ9qUkxAZnwN/2dsb2JhbACBRJ5TcaR7mwqFOQSEE4clDAE X-IronPort-AV: E=Sophos;i="4.55,287,1278288000"; d="scan'208,217";a="141238705" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 30 Jul 2010 13:05:53 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6UD5fKv028184; Fri, 30 Jul 2010 13:05:53 GMT Received: from xmb-bgl-411.cisco.com ([72.163.129.207]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 30 Jul 2010 18:35:41 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB2FE7.E960B09F" Date: Fri, 30 Jul 2010 18:35:38 +0530 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Proposal for Session ID charter Thread-Index: Acsv5gLd8f0PxBLBReCCMgx6YBeRjgAACBug References: <585BC8BE-2D22-4EC3-8958-8DA24C9E9A6C@cisco.com><4C528B89.5090906@cisco.com><4C52A46E.1070305@cisco.com><430FC6BDED356B4C8498F634416644A92694002E6A@mail> From: "Parthasarathi R (partr)" To: "Toto Shyardi" X-OriginalArrivalTime: 30 Jul 2010 13:05:41.0485 (UTC) FILETIME=[E9B141D0:01CB2FE7] Cc: dispatch@ietf.org, Hadriel Kaplan Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 13:05:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB2FE7.E960B09F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Toto, =20 Thanks for indicating about 3GPP session id. I'll include the below mentioned usecase and provide 3GPP reference for more details. I'm pretty sure that we will hear much more as I heard that most of the vendors have proprietary session-id for different applications with different callflows.=20 =20 All, =20 Toto mail ascertain the requirement of usecase document for this session-id mechanism. Please let me know in case any other opinion. =20 Thanks Partha ________________________________ From: Toto Shyardi [mailto:toto.shyardi@gmail.com]=20 Sent: Friday, July 30, 2010 6:22 PM To: Parthasarathi R (partr) Cc: Hadriel Kaplan; Paul Kyzivat (pkyzivat); Peter Musgrave; dispatch@ietf.org Subject: Re: [dispatch] Proposal for Session ID charter On Fri, Jul 30, 2010 at 7:17 AM, Parthasarathi R (partr) wrote: Hadriel, =09 Instead working with solution in mind, Shall we start with the usecases document. The usecase document will help us to decide whether the single =09 Short of the IETF solution, the 3GPP invented its own "session-id" for the following application: =20 1. Assume UA-a has a voice dialog with UA-b (over access network X), and there is a B2BUA between them. 2. During the voice dialog, the UA-a roams into access network Y. There is a "small" overlap between networks X and Y (i.e. X*Y), and the UA-a is a dual-radio device (it can simultaneously transmit in X and Y). 3. While in X*Y, UA-a establishes a second dialog (over Y), and indicates to the UA-b that this dialog replaced the original dialog (by specifying the dialog-id between the UA-a and B2BUA). It also terminates the original dialog over the network X. 4. Obviously, the "handoff" fails, since the original dialog between the UA-a and the B2BUA has different dialog-id then the dialog between the B2BUA and the UA-b. =20 Hence, the need for some "session-id" that consists of concatenated dialogs.=20 =20 Toto =20 ------_=_NextPart_001_01CB2FE7.E960B09F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Toto,
 
Thanks for indicating about 3GPP session id. I'll=20 include the below mentioned usecase and provide 3GPP reference = for more details. I'm pretty sure that  we will hear much = more as=20 I heard that most of the vendors have proprietary session-id for = different=20 applications with different callflows. 
 
All,
 
Toto mail ascertain the requirement of = usecase=20 document for this session-id mechanism. Please let me know in case = any=20 other opinion.
 
Thanks
Partha

From: Toto Shyardi=20 [mailto:toto.shyardi@gmail.com]
Sent: Friday, July 30, 2010 = 6:22=20 PM
To: Parthasarathi R (partr)
Cc: Hadriel Kaplan; = Paul=20 Kyzivat (pkyzivat); Peter Musgrave; dispatch@ietf.org
Subject: = Re:=20 [dispatch] Proposal for Session ID charter



On Fri, Jul 30, 2010 at 7:17 AM, Parthasarathi = R (partr)=20 <partr@cisco.com> = wrote:
Hadriel,

Instead working with solution in = mind, Shall=20 we start with the usecases
document. The usecase document will help = us to=20 decide whether the single



Short of the=20 IETF solution, the 3GPP invented its own "session-id" for the following=20 application:

 

1. Assume=20 UA-a has a voice dialog with UA-b (over access network X), and there is = a B2BUA=20 between them.

2. During the=20 voice dialog, the UA-a roams into access network Y. There is a "small" = overlap=20 between networks X and Y (i.e. X*Y), and the UA-a is a dual-radio device = (it can=20 simultaneously transmit in X and Y).

3. While in=20 X*Y, UA-a establishes a second dialog (over Y), and indicates to the = UA-b that=20 this dialog replaced the original dialog (by specifying the = dialog-id=20 between the UA-a and B2BUA). It also terminates the original dialog over = the=20 network X.

4. Obviously,=20 the "handoff" fails, since the original dialog between the UA-a and the = B2BUA=20 has different dialog-id then the dialog between the B2BUA and the=20 UA-b.

 

Hence, the=20 need for some "session-id" that consists of concatenated dialogs. =

 

Toto

 

------_=_NextPart_001_01CB2FE7.E960B09F-- From gao.yang2@zte.com.cn Fri Jul 30 06:36:19 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E4173A69DA for ; Fri, 30 Jul 2010 06:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.957 X-Spam-Level: X-Spam-Status: No, score=-99.957 tagged_above=-999 required=5 tests=[AWL=1.881, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6e6FLz64vwt for ; Fri, 30 Jul 2010 06:36:18 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 0F16B3A69DB for ; Fri, 30 Jul 2010 06:36:15 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 3510992332426; Fri, 30 Jul 2010 21:35:53 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 14499.1807591319; Fri, 30 Jul 2010 21:28:10 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6UDabj3033080; Fri, 30 Jul 2010 21:36:37 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 30 Jul 2010 21:34:50 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-30 21:36:18, Serialize complete at 2010-07-30 21:36:18 Content-Type: multipart/alternative; boundary="=_alternative 004AA6A448257770_=" X-MAIL: mse2.zte.com.cn o6UDabj3033080 Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 13:36:19 -0000 This is a multipart message in MIME format. --=_alternative 004AA6A448257770_= Content-Type: text/plain; charset="US-ASCII" Hi Toto > Short of the IETF solution, the 3GPP invented its own "session-id" > for the following application: I hasn't seen any normative(TS) solution about this "Replaces" problem in 3GPP. If you have found it, please show it to me. Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 004AA6A448257770_= Content-Type: text/html; charset="US-ASCII"
Hi Toto

> Short of the IETF solution, the 3GPP invented its own "session-id"
> for the following application:

I hasn't seen any normative(TS) solution about this "Replaces" problem in 3GPP. If you have found it, please show it to me.

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 004AA6A448257770_=-- From gao.yang2@zte.com.cn Fri Jul 30 06:55:06 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5012F3A69E2 for ; Fri, 30 Jul 2010 06:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.863 X-Spam-Level: X-Spam-Status: No, score=-99.863 tagged_above=-999 required=5 tests=[AWL=1.975, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BEcw994f8Q0 for ; Fri, 30 Jul 2010 06:55:01 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id B31363A69FF for ; Fri, 30 Jul 2010 06:54:53 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 20595992332426; Fri, 30 Jul 2010 21:54:12 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 14499.1807591319; Fri, 30 Jul 2010 21:46:52 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6UDtSNs075235; Fri, 30 Jul 2010 21:55:29 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 30 Jul 2010 21:53:41 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-30 21:55:10, Serialize complete at 2010-07-30 21:55:10 Content-Type: multipart/alternative; boundary="=_alternative 004C604D48257770_=" X-MAIL: mse2.zte.com.cn o6UDtSNs075235 Cc: dispatch@ietf.org Subject: Re: [dispatch] Proposal for Session ID charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 13:55:06 -0000 This is a multipart message in MIME format. --=_alternative 004C604D48257770_= Content-Type: text/plain; charset="US-ASCII" Hi Toto, > Short of the IETF solution, the 3GPP invented its own "session-id" > for the following application: > > 1. Assume UA-a has a voice dialog with UA-b (over access network X), > and there is a B2BUA between them. > 2. During the voice dialog, the UA-a roams into access network Y. > There is a "small" overlap between networks X and Y (i.e. X*Y), and > the UA-a is a dual-radio device (it can simultaneously transmit in X and Y). > 3. While in X*Y, UA-a establishes a second dialog (over Y), and > indicates to the UA-b that this dialog replaced the original dialog > (by specifying the dialog-id between the UA-a and B2BUA). It also > terminates the original dialog over the network X. > 4. Obviously, the "handoff" fails, since the original dialog between > the UA-a and the B2BUA has different dialog-id then the dialog > between the B2BUA and the UA-b. > > Hence, the need for some "session-id" that consists of concatenated dialogs. By my understanding, current 3GPP's dual radio PS-PS Access transfer is also based on SCC-AS. Then the Replaces header is not used in this situation. Currently, 3GPP has a Replaces problem in conference call flow, but I think it can be solved by solutions without any *dialog correlation header *. Thanks, Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 004C604D48257770_= Content-Type: text/html; charset="US-ASCII"
Hi Toto,

> Short of the IETF solution, the 3GPP invented its own "session-id"
> for the following application:
>  
> 1. Assume UA-a has a voice dialog with UA-b (over access network X),
> and there is a B2BUA between them.
> 2. During the voice dialog, the UA-a roams into access network Y.
> There is a "small" overlap between networks X and Y (i.e. X*Y), and
> the UA-a is a dual-radio device (it can simultaneously transmit in X and Y).
> 3. While in X*Y, UA-a establishes a second dialog (over Y), and
> indicates to the UA-b that this dialog replaced the original dialog
> (by specifying the dialog-id between the UA-a and B2BUA). It also
> terminates the original dialog over the network X.
> 4. Obviously, the "handoff" fails, since the original dialog between
> the UA-a and the B2BUA has different dialog-id then the dialog
> between the B2BUA and the UA-b.
>  
> Hence, the need for some "session-id" that consists of concatenated dialogs.

By my understanding, current 3GPP's dual radio PS-PS Access transfer is also based on SCC-AS. Then the Replaces header is not used in this situation.

Currently, 3GPP has a Replaces problem in conference call flow, but I think it can be solved by solutions without any *dialog correlation header*.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 004C604D48257770_=-- From gao.yang2@zte.com.cn Fri Jul 30 07:44:45 2010 Return-Path: X-Original-To: dispatch@core3.amsl.com Delivered-To: dispatch@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD1353A699C for ; Fri, 30 Jul 2010 07:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.783 X-Spam-Level: X-Spam-Status: No, score=-99.783 tagged_above=-999 required=5 tests=[AWL=1.455, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgpjJMsW2Gxb for ; Fri, 30 Jul 2010 07:44:44 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 497E03A6993 for ; Fri, 30 Jul 2010 07:44:44 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 3510992332426; Fri, 30 Jul 2010 22:44:23 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 14499.992332426; Fri, 30 Jul 2010 22:36:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6UEiqkJ044683 for ; Fri, 30 Jul 2010 22:44:52 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: dispatch@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 30 Jul 2010 22:43:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-30 22:44:33, Serialize complete at 2010-07-30 22:44:33 Content-Type: multipart/alternative; boundary="=_alternative 0050E4F148257770_=" X-MAIL: mse2.zte.com.cn o6UEiqkJ044683 Subject: [dispatch] About B2BUA and e2e features: X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2010 14:44:46 -0000 This is a multipart message in MIME format. --=_alternative 0050E4F148257770_= Content-Type: text/plain; charset="US-ASCII" For people care about B2BUA, There has been a quit long discussion for the Session-ID and B2BUA topic. There are some people want to make "session-id" to UPDATE current normative RFCs, at least *potentially*. I think the more general question behind this is about B2BUA and e2e feature, or in other words, do we need to *modify* e2e features for B2BUA use cases. IMO, I do not want to see any normative modification for B2BUA use cases. Any SIP equipment should handle it's B2BUA behavior carefully. By my experience in IMS, if AS want to behave as B2BUA, it MUST modify the Replaces header's dialog information to make the Replaces header's dialog-id can be handled OK by the receiver(UAS for the request with replaces header), this is defined in 24.229. And the AS should also guarantee itself would be trigger for the subsequent request with replaces header, by modifying iFC. And about SBC, if it want to behave as B2BUA, it also should modify the Replaces header's dialog information to make the Replaces header's dialog-id can be handled OK by the receiver(UAS for the request with replaces header). And we usually deployed SBC at the edge of the IMS Core, so the subsequent request with replaces header alway pass the same logical SBC. If there are more than one physical SBCs deployed in the network, they should share the dialog information when handle Replaces header. So, B2BUA should regulate it's behavior for e2e features, while not *modifying* e2e features for B2BUA use cases. Thanks, Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0050E4F148257770_= Content-Type: text/html; charset="US-ASCII"
For people care about B2BUA,

There has been a quit long discussion for the Session-ID and B2BUA topic. There are some people want to make "session-id" to UPDATE current normative RFCs, at least *potentially*.

I think the more general question behind this is about B2BUA and e2e feature, or in other words, do we need to *modify* e2e features for B2BUA use cases. IMO, I do not want to see any normative modification for B2BUA use cases.

Any SIP equipment should handle it's B2BUA behavior carefully. By my experience in IMS, if AS want to behave as B2BUA, it MUST modify the Replaces header's dialog information to make the Replaces header's dialog-id can be handled OK by the receiver(UAS for the request with replaces header), this is defined in 24.229. And the AS should also guarantee itself would be trigger for the subsequent request with replaces header, by modifying iFC.

And about SBC, if it want to behave as B2BUA, it also should modify the Replaces header's dialog information to make the Replaces header's dialog-id can be handled OK by the receiver(UAS for the request with replaces header). And we usually deployed SBC at the edge of the IMS Core, so the subsequent request with replaces header alway pass the same logical SBC. If there are more than one physical SBCs deployed in the network, they should share the dialog information when handle Replaces header.

So, B2BUA should regulate it's behavior for e2e features, while not *modifying* e2e features for B2BUA use cases.

Thanks,

Gao

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0050E4F148257770_=--