From rmohanr@cisco.com Wed Jan 4 22:15:33 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC5221F87BA for ; Wed, 4 Jan 2012 22:15:33 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjtyLn-jJoBw for ; Wed, 4 Jan 2012 22:15:32 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7207621F8694 for ; Wed, 4 Jan 2012 22:15:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rmohanr@cisco.com; l=1905; q=dns/txt; s=iport; t=1325744131; x=1326953731; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=tJM3E6pE2EYemY3K93yfSEvpAaYZB8n9S790Weg1Dbw=; b=irDeznRcn+8JLREBzM8mXHO/myZqVSJ+4J8VeFSVp62857CkTkHdOVT5 ec8IqxVUmvh1/RLC/eXxmV0NrlRDUadUCWdW+Ef6sBwznIrSrcDxCgDtY lNo3HgMCn6R2ezhPSPAwpU3UuAxTpHBGNH1T1HddeSFfo9NJ1CI+k3D2c Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocAANU+BU9Io8UY/2dsb2JhbABDnCuRTYFyAQEBBAEBAQ8BHQorCRcEAgEIEQQBAQsGFwEGASYfCQgBAQQBCggIARIHh2CXLQGdeYsuYwSIN5dAh0o X-IronPort-AV: E=Sophos;i="4.71,460,1320624000"; d="scan'208";a="2809246" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 05 Jan 2012 06:15:29 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q056ExXs013089; Thu, 5 Jan 2012 06:15:29 GMT Received: from xmb-bgl-417.cisco.com ([72.163.129.213]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 11:45: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: Thu, 5 Jan 2012 11:45:28 +0530 Message-ID: <35BCE99A477D6A4986FB2216D8CF2CFD08F27E22@XMB-BGL-417.cisco.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C01DAE0D9@inba-mail01.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] SIP media load balancer requirement Thread-Index: AczAUbSbDDcFGmmuRPiqlrieYjsdqQLDziqA References: <387F9047F55E8C42850AD6B3A7A03C6C01DAE0D9@inba-mail01.sonusnet.com> From: "Ram Mohan R (rmohanr)" To: "Ravindran, Parthasarathi" , X-OriginalArrivalTime: 05 Jan 2012 06:15:28.0878 (UTC) FILETIME=[6BE478E0:01CCCB71] Subject: Re: [dispatch] SIP media load balancer requirement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 06:15:33 -0000 Hi Partha, I would be interested in this work. See more inline > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Ravindran, Parthasarathi > Sent: Thursday, December 22, 2011 8:02 AM > To: dispatch@ietf.org > Subject: [dispatch] SIP media load balancer requirement >=20 > Hi all, >=20 > As a continuation of IETF-81 Dispatch minutes > (http://www.ietf.org/mail-archive/web/dispatch/current/msg03742.html) > about SIP load balancing, I thought of discussing about SIP media > servers load balancing as mentioned in the SIP load balancing proposed > charter (http://www.ietf.org/mail- > archive/web/dispatch/current/msg03615.html). >=20 > "As SIP request resource consumption in SIP signaling only server > varies drastically from SIP media servers [3], should the solution be > split such that load balancing of a pure signaling server is different > than that of a SIP server that handles signaling as well as media?" >=20 > SIP media server load balancing solution will be different from > signaling only because the downstream resource consumption is mainly > because of media (RTP) than signaling (SIP) and the units to indicate > the load balancing information will be different in both solution. > There is a need to indicate those media resource consumption to the > load balancer in the standard manner. Please let me know your comment > on this. I think what we need is some text/document saying how media overload is different from signaling overload and what are the different resources that need to considered for media overload. In that way we will have good starting point to discuss on this topic. Regards, Ram >=20 > Thanks > Partha > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pravindran@sonusnet.com Wed Jan 4 22:27:44 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891EE21F87D3 for ; Wed, 4 Jan 2012 22:27:44 -0800 (PST) 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.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npi86bw+b+BT for ; Wed, 4 Jan 2012 22:27:43 -0800 (PST) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 57CA721F87D2 for ; Wed, 4 Jan 2012 22:27:43 -0800 (PST) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q056SJt4010964; Thu, 5 Jan 2012 01:28:19 -0500 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 01:27:36 -0500 Received: from INBA-HUB02.sonusnet.com ([10.70.51.87]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jan 2012 11:58:24 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Thu, 5 Jan 2012 11:58:23 +0530 From: "Ravindran, Parthasarathi" To: "Ram Mohan R (rmohanr)" , "dispatch@ietf.org" Thread-Topic: [dispatch] SIP media load balancer requirement Thread-Index: AczAUbSbDDcFGmmuRPiqlrieYjsdqQLDziqAAARMF+A= Date: Thu, 5 Jan 2012 06:28:22 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DC3C4F@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C01DAE0D9@inba-mail01.sonusnet.com> <35BCE99A477D6A4986FB2216D8CF2CFD08F27E22@XMB-BGL-417.cisco.com> In-Reply-To: <35BCE99A477D6A4986FB2216D8CF2CFD08F27E22@XMB-BGL-417.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jan 2012 06:28:24.0674 (UTC) FILETIME=[3A4D8C20:01CCCB73] Subject: Re: [dispatch] SIP media load balancer requirement X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 06:27:44 -0000 Hi Ram, Nice to see your interest. Please read inline for more comments. Thanks Partha >-----Original Message----- >From: Ram Mohan R (rmohanr) [mailto:rmohanr@cisco.com] >Sent: Thursday, January 05, 2012 11:45 AM >To: Ravindran, Parthasarathi; dispatch@ietf.org >Subject: RE: [dispatch] SIP media load balancer requirement > >Hi Partha, > >I would be interested in this work. See more inline > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Ravindran, Parthasarathi >> Sent: Thursday, December 22, 2011 8:02 AM >> To: dispatch@ietf.org >> Subject: [dispatch] SIP media load balancer requirement >> >> Hi all, >> >> As a continuation of IETF-81 Dispatch minutes >> (http://www.ietf.org/mail-archive/web/dispatch/current/msg03742.html) >> about SIP load balancing, I thought of discussing about SIP media >> servers load balancing as mentioned in the SIP load balancing proposed >> charter (http://www.ietf.org/mail- >> archive/web/dispatch/current/msg03615.html). >> >> "As SIP request resource consumption in SIP signaling only server >> varies drastically from SIP media servers [3], should the solution be >> split such that load balancing of a pure signaling server is different >> than that of a SIP server that handles signaling as well as media?" >> >> SIP media server load balancing solution will be different from >> signaling only because the downstream resource consumption is mainly >> because of media (RTP) than signaling (SIP) and the units to indicate >> the load balancing information will be different in both solution. >> There is a need to indicate those media resource consumption to the >> load balancer in the standard manner. Please let me know your comment >> on this. > >I think what we need is some text/document saying how media overload is >different from signaling overload and what are the different resources >that need to considered for media overload. In that way we will have >good starting point to discuss on this topic. The focus of this charter is about SIP media load balancing and no= t media overload handling. I agree with you that SIP media load balancing a= lgorithm works in conjunction with media overload mechanism and selection o= f the load balancing algorithm majorly depends upon media overload mechanis= m.=20 SIP media load balancer requirement is to consider media resource consumpti= on of the peer apart from the signaling resource consumption. > >Regards, >Ram >> >> Thanks >> Partha >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Mon Jan 9 09:29:40 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0450511E80CE for ; Mon, 9 Jan 2012 09:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.808 X-Spam-Level: X-Spam-Status: No, score=-103.808 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHMOIPqng8HW for ; Mon, 9 Jan 2012 09:29:36 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BBD2C11E80A3 for ; Mon, 9 Jan 2012 09:29:35 -0800 (PST) Received: by vbbfo1 with SMTP id fo1so3041518vbb.31 for ; Mon, 09 Jan 2012 09:29:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=IFy6U1PhcSCAr1Q50BiCBnkMoqXQbyGeez4sM8D5pG8=; b=ucOcg/WuhDs82LCCohv8cZ6foaLFlcLjAWnQtwr+mOZCmku5i75rz87lyVHWWDLVqv +O67aRlvB+U0YZ/XNogLp7d1aHNzstyJTBaj/mKmFo4LbLwwd8AVBYjr2QlIA6+7klbF Cic7S3oj6XviQm6GeTwsozOMNu9FkUVwK+eqs= MIME-Version: 1.0 Received: by 10.52.35.13 with SMTP id d13mr7943523vdj.55.1326130175126; Mon, 09 Jan 2012 09:29:35 -0800 (PST) Received: by 10.52.108.196 with HTTP; Mon, 9 Jan 2012 09:29:35 -0800 (PST) Date: Mon, 9 Jan 2012 11:29:35 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: rai-ads@tools.ietf.org Subject: [dispatch] Reminder: DISPATCH WG Deadlines for IETF-83 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 17:29:40 -0000 Hi folks, A reminder that the first deadline for the upcoming meeting is in one week's time (Monday, January 16th). This is an easy one - you just need to send the chairs an email that you intend to put forth a topic and please identify the topic. Then you have a week to put together details for the topic proposal. If your topic garners WG interest on the mailing list over the next two weeks, then it will be considered in developing the agenda for the f2f meeting. You have up until the normal meeting deadlines to submit any related drafts. Thanks, Mary. ---------- Forwarded message ---------- From: Mary Barnes Date: Thu, Dec 8, 2011 at 2:28 PM Subject: Deadlines for IETF-83 To: DISPATCH Cc: Cullen Jennings , rai-ads@tools.ietf.org Hi folks, As presented in Taipei and per the wiki, the deadlines for IETF-83 are as follows: http://trac.tools.ietf.org/wg/dispatch/trac/wiki * Jan 16th, 2012. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. [Two weeks prior to deadline for scheduling WG sessions] * Jan 23, 2012. Cutoff for charter proposals for topics. [Three weeks prior to BoF proposal deadline, two weeks before announcement of topics] * Feb 6, 2012. Topics that are to be the focus of IETF-83 are announced. [One week before AD BoF approval, 4 weeks before -00 deadline, *one week* after deadline for requesting WG session] * March 5, 2012. -00 draft deadline. * March 12, 2012, 2011. Draft deadline. So, please send proposals ASAP and comment on those topics that were posted after the IETF-82 deadlines (e.g., STRAW). =A0The sooner discussion is started, the better prepared we will be to dispatch the item before or at the meeting. Thanks, Mary DISPATCH WG co-chair From petithug@acm.org Mon Jan 16 10:25:43 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534B021F86C2; Mon, 16 Jan 2012 10:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.337 X-Spam-Level: X-Spam-Status: No, score=-102.337 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeUmXGQZyEYA; Mon, 16 Jan 2012 10:25:42 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id A78A621F86A2; Mon, 16 Jan 2012 10:25:42 -0800 (PST) Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 71B1420142; Mon, 16 Jan 2012 18:11:59 +0000 (UTC) Message-ID: <4F146BA2.2080106@acm.org> Date: Mon, 16 Jan 2012 10:25:38 -0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20120104 Icedove/8.0 MIME-Version: 1.0 To: DISPATCH list References: <20120116175444.21776.21853.idtracker@ietfa.amsl.com> In-Reply-To: <20120116175444.21776.21853.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.4 X-Forwarded-Message-Id: <20120116175444.21776.21853.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "vipr@ietf.org" , P2PSIP Mailing List Subject: [dispatch] Fwd: I-D Action: draft-petithuguenin-dispatch-unique-overlay-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 18:25:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I would like to request a timeslot in the DISPATCH session in Paris to talk about infrastructure overlays, which is a special class of RELOAD overlays that by their own definition require that only one instance of this overlay exists on the Internet (excluding instances deployed for test and experimentation). This kind of overlay could be useful for stuff like bitcoin or boinc, but the main motivation is to support VIPR, which works only if there is a unique overlay instance. The discussion will be around the problems that infrastructure overlays solve and the list of requirements for the mechanism used to implement it but, although this is not part of the discussion, the new version of the draft contains an appendix explaining one possible solution. - -------- Original Message -------- Subject: I-D Action: draft-petithuguenin-dispatch-unique-overlay-01.txt Date: Mon, 16 Jan 2012 09:54:44 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Infrastructure Overlay Author(s) : Marc Petit-Huguenin Filename : draft-petithuguenin-dispatch-unique-overlay-01.txt Pages : 6 Date : 2012-01-16 This document provides requirements for infrastructure overlays, a special kind of peer-to-peer overlay whose main purpose would be defeated if more than one instance would exist on the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-petithuguenin-dispatch-unique-overlay-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-petithuguenin-dispatch-unique-overlay-01.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQIcBAEBCAAGBQJPFGudAAoJECnERZXWan7EDnoQAIdc/tgnhObDZP7iEm8XYN9t 9Eop2B6WQCS9KRjMDagjojY7smAdRkof23Tru+4q+jj7W2f+BbL3/EWex2y8/uRS jZC0Z5pgw6hJrwR+UQni8XfuAWuoBJ6Rl9UHlBKRwyiyZn/mJD8Z1aUWO8FIXdLI zM+x2E2FEeuW9HbvDQ19+5JrBce7VplOvyZz2OOZzvkgBQFDYVJIvvpzE26OuGQa I9sz2EedPn+xnpRC5XtKxQDkkRRreB6xDyaM6heqzqldcBbvIyNFDfmHDOkTVQIi qP5eCwB2vHCN+nlKfhm/F2Bx+coFvYJ628rB4rMcoBCa+VuXspyPMhUaXWQhCioc +N17jsF02q31HO/SBE8vMQRPTZcv/t24d5VZhoxTdBAZt420W2eWNXeDpoWobN9c nN7fkFkTfuK4xP6374GieEmfgOquLXMM556DTJN/5c5l7E7So+udSw0ctIjehBrZ VMLI8GRrISv/mIjOV4cW2Wevn+g5Dw0P3Ptg6N2Dd84CkbRqBkqmfLrvpdhkdhWd wN3kCi6vLF3XfGJrnyyVY15KO+Cg3j9uAmVRZj+Nxdm6hngtklQJwHTiKtDGKgCp 7qoVFmJGVCYNpyBbvKETRhSTsAPz8p/ygU2ququExiaa8DW4/jGxB+xMfqpMMvez MhcXnZzLQmSjdv45ZZaQ =aaO4 -----END PGP SIGNATURE----- From sapnas@s-mail.com Tue Jan 17 05:15:23 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AB121F85AE; Tue, 17 Jan 2012 05:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.523 X-Spam-Level: X-Spam-Status: No, score=-0.523 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_50=0.001, FH_RELAY_NODNS=1.451, GB_I_LETTER=-2, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CulYX76EEMDE; Tue, 17 Jan 2012 05:15:23 -0800 (PST) Received: from s-mail.com (unknown [82.198.169.101]) by ietfa.amsl.com (Postfix) with ESMTP id 07DBC21F85D5; Tue, 17 Jan 2012 05:15:23 -0800 (PST) Received: from apache by s-mail.com with local (Exim 3.36 #3) id 1Rn8sk-0007Kf-00; Tue, 17 Jan 2012 13:15:22 +0000 Message-ID: <4f157468.79663c4b@s-mail.com> Date: Tue, 17 Jan 2012 13:15:20 +0000 From: sapna s To: ietf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Cc: dispatch@ietf.org Subject: [dispatch] Avoidance draft review X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 13:15:23 -0000 Hi, Please review the *silent* draft in dispatch group for security issue avoidance. Author was earlier talking abt top prize to top person. Top Person was having Prior Knowledge about whereabouts of Most Wanted Person (who was dead in APR last or May first week , who was in the region whose head was sometime Musharraf). Web site at www. .com Looks like due to which top person is blocking the review. Please review draft. Thx Sapna S NOTE: ___________________________________________________________ This letter has been delivered unencrypted. We would like to remind you that full end-to-end protection of email correspondence is only provided if both sender and recipient are Secure Mail users. To register FREE at Secure Mail, please visit our site: http://www.s-mail.com From rifatyu@avaya.com Fri Jan 20 10:55:47 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D889B21F864A for ; Fri, 20 Jan 2012 10:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.385 X-Spam-Level: X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tp6KTLhA3234 for ; Fri, 20 Jan 2012 10:55:47 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5AEB021F8648 for ; Fri, 20 Jan 2012 10:55:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FAJS3GU+HCzI1/2dsb2JhbABDgk2jMgGHJWSBBYF5Ehs7IwEVayYBBBsah2KYcoQZm0mLQ2MEiDySVIxy X-IronPort-AV: E=Sophos;i="4.71,544,1320642000"; d="scan'208,217";a="287304448" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Jan 2012 13:55:44 -0500 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 20 Jan 2012 13:42:08 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 20 Jan 2012 13:55:38 -0500 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "dispatch@ietf.org" Date: Fri, 20 Jan 2012 13:55:35 -0500 Thread-Topic: [dispatch] DISPATCH timeslot Thread-Index: AczXpReetkgareELQEevu0QGgQbs9w== Message-ID: <6369CB70BFD88942B9705AC1E639A3382310F063F6@DC-US1MBEX4.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: ogs= BWBp BscL CH8W CgsG EiR0 FX/6 G8fJ HbRP Ie40 IhXa InzD JH21 Ja3o JsU0 KKUU; 1; ZABpAHMAcABhAHQAYwBoAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {4B4C05F3-F8AB-4AA8-ACFD-4EAF3AE77C0F}; cgBpAGYAYQB0AHkAdQBAAGEAdgBhAHkAYQAuAGMAbwBtAA==; Fri, 20 Jan 2012 18:55:35 GMT; WwBkAGkAcwBwAGEAdABjAGgAXQAgAEQASQBTAFAAQQBUAEMASAAgAHQAaQBtAGUAcwBsAG8AdAA= x-cr-puzzleid: {4B4C05F3-F8AB-4AA8-ACFD-4EAF3AE77C0F} acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6369CB70BFD88942B9705AC1E639A3382310F063F6DCUS1MBEX4glo_" MIME-Version: 1.0 Subject: [dispatch] DISPATCH timeslot X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 18:55:48 -0000 --_000_6369CB70BFD88942B9705AC1E639A3382310F063F6DCUS1MBEX4glo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cullen, Mary, This is to request a DISPATCH timeslot to discuss the draft "Conference Foc= us Indicating CCMP Support". http://tools.ietf.org/id/draft-yusef-xcon-ccmp-indication-00.txt The CCMP protocol allows a UA to discover if a conference server supports C= CMP. The draft it trying to address the need for a UA to discover if a conferenc= e focus supports CCMP. The draft presents multiple options and pros and cons of each one. We would appreciate any comments. Regards, Rifaat --_000_6369CB70BFD88942B9705AC1E639A3382310F063F6DCUS1MBEX4glo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Cullen, Mary,

 

= This is to request a DISPATCH timeslot to discuss the draft “Conferen= ce Focus Indicating CCMP Support”.

http://tools.ietf.org/id/draft-yusef-xcon-ccmp-indication-00.txt

 

T= he CCMP protocol allows a UA to discover if a conference server supports CC= MP.

The draft it trying to address the n= eed for a UA to discover if a conference focus supports CCMP.

The draft presents multiple options and pros and cons= of each one.

 

We would appreciate any comments.

 

Regards,

=

Rifaat

 =

= --_000_6369CB70BFD88942B9705AC1E639A3382310F063F6DCUS1MBEX4glo_-- From bo.burman@ericsson.com Mon Jan 23 07:50:28 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B614721F8797 for ; Mon, 23 Jan 2012 07:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtbKPmxMRpAy for ; Mon, 23 Jan 2012 07:50:28 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8A321F8794 for ; Mon, 23 Jan 2012 07:50:27 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-16-4f1d81c21e6e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B8.17.02613.2C18D1F4; Mon, 23 Jan 2012 16:50:26 +0100 (CET) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.126]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 23 Jan 2012 16:50:26 +0100 From: Bo Burman To: "dispatch@ietf.org" Date: Mon, 23 Jan 2012 16:50:24 +0100 Thread-Topic: Media Stream related signaling Thread-Index: AczZ5rhYJCBqmo1vRaCfF/ps/EzATQ== Message-ID: <05F760EF51FA6A4F804F9759C239313A3271BADD0B@ESESSCMS0361.eemea.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [dispatch] Media Stream related signaling X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 15:50:29 -0000 Dispatch, We have requested agenda time for the upcoming meeting to discuss the subje= ct of Media Stream related signaling. From the feedback we got in AVTEXT WG= on the discussion for a certain problem, the one related to pausing and re= suming sender to middlebox media traffic, it is clear that a more high leve= l discussion needs to happen. We have two Internet drafts related to the issues we would like to discuss. Media Stream Selection (MESS) - draft-westerlund-dispatch-stream-selection-00 RTP Media Stream Pause and Resume - draft-westerlund-avtext-rtp-stream-pause-00 The first one (MESS) proposes that for the general selection of media strea= ms, an end-point within a centralized conferencing scenario desires to rece= ive a media plane oriented rather than RTP/RTCP based signaling, which appe= ars to have benefits as discussed in the draft. As mentioned, the pause resume draft is targeted for a different use case w= here a media plane solution has potential for other benefits. This was disc= ussed and the main outcome of that discussion was three quite different opi= nions; a) We already do this signaling using TMMBR (RFC 5104) by setting the bit-r= ate value to 0, which the current specs doesn't allow. b) This should be done in signalling plane, RTP/RTCP shouldn't be bloated. = (But I did interpret this as not necessarily needing to be SIP). c) When it comes to pause/resume, unless it is done using SIP/SDP it will n= ot work through any Session Border Gateway as the session will be torn down= after n seconds. Thus I think it important that we take a discussion around the use cases, e= xisting solutions, limitations in those or the proposal to try to determine= what is the most reasonable way of solving the problems and how to enable; 1) Receiver based selection of media streams from a larger set of streams, = including different quality levels like video resolutions, in a centralized= conferencing application. 2) Optimize the transport so that media streams currently not used can be t= urned off temporarily and then quickly resumed when someone determines a ne= ed for the media stream. For example using mechanism (1) but also for voice= activity based, centrally controlled or other mechanisms to select which m= edia streams are delivered to other session participants. We are working to revise our Internet drafts. We seek as much input as poss= ible into this prior to the meeting so that we can ensure that any discussi= on are as on topic and focused as possible. Regards Bo Burman & Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7141311 F=E4r=F6gatan 6 | Mobile +46 73 0949021 SE-164 80 Stockholm, Sweden| mailto: bo.burman at ericsson.com ---------------------------------------------------------------------- From mphmmr@gmail.com Mon Jan 23 08:44:02 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5A121F86AB for ; Mon, 23 Jan 2012 08:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=1.552, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQZW4GBcOAtC for ; Mon, 23 Jan 2012 08:44:01 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA0E21F86A9 for ; Mon, 23 Jan 2012 08:44:01 -0800 (PST) Received: by lagj5 with SMTP id j5so2032576lag.31 for ; Mon, 23 Jan 2012 08:44:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7srAoQlpmpZ8KtSIePeyNg8xGADzPsYu1eMRCrt/6dQ=; b=J8te0UH0FTLWY4Chur890LMetTCrqWHcB2dC7KD3ZiyvtUj7W8lzLGb37Rscveb4Ip 1Ma40IjOdBBD9cBYf/tYDhjRNxwY1mPbE1aP4MDJdQweZcKyCAeRuszgSAW2FtlQ1AhL 0sJ5IRGWqOTd12i36PyIhavXu4Wz5RoQMWECE= MIME-Version: 1.0 Received: by 10.152.106.227 with SMTP id gx3mr4643113lab.45.1327337040210; Mon, 23 Jan 2012 08:44:00 -0800 (PST) Received: by 10.112.57.164 with HTTP; Mon, 23 Jan 2012 08:44:00 -0800 (PST) In-Reply-To: <05F760EF51FA6A4F804F9759C239313A3271BADD0B@ESESSCMS0361.eemea.ericsson.se> References: <05F760EF51FA6A4F804F9759C239313A3271BADD0B@ESESSCMS0361.eemea.ericsson.se> Date: Mon, 23 Jan 2012 11:44:00 -0500 Message-ID: From: Michael Hammer To: Bo Burman Content-Type: multipart/alternative; boundary=f46d040892c3c76ae304b734bc49 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Media Stream related signaling X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 16:44:03 -0000 --f46d040892c3c76ae304b734bc49 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bo, Rather than "turning [the media] stream off temporarily", you should consider putting the media stream into a low energy state, which would not be bit rate =3D 0 but would have some limited keep-alive stream that the SB= C recognizes to keep the pinhole open. There are probably multiple ways to make that happen. Hope that is semantically what you meant. Mike On Mon, Jan 23, 2012 at 10:50 AM, Bo Burman wrote: > Dispatch, > > We have requested agenda time for the upcoming meeting to discuss the > subject of Media Stream related signaling. From the feedback we got in > AVTEXT WG on the discussion for a certain problem, the one related to > pausing and resuming sender to middlebox media traffic, it is clear that = a > more high level discussion needs to happen. > > We have two Internet drafts related to the issues we would like to discus= s. > Media Stream Selection (MESS) > - draft-westerlund-dispatch-stream-selection-00 > RTP Media Stream Pause and Resume > - draft-westerlund-avtext-rtp-stream-pause-00 > > The first one (MESS) proposes that for the general selection of media > streams, an end-point within a centralized conferencing scenario desires = to > receive a media plane oriented rather than RTP/RTCP based signaling, whic= h > appears to have benefits as discussed in the draft. > > As mentioned, the pause resume draft is targeted for a different use case > where a media plane solution has potential for other benefits. This was > discussed and the main outcome of that discussion was three quite differe= nt > opinions; > > a) We already do this signaling using TMMBR (RFC 5104) by setting the > bit-rate value to 0, which the current specs doesn't allow. > > b) This should be done in signalling plane, RTP/RTCP shouldn't be bloated= . > (But I did interpret this as not necessarily needing to be SIP). > > c) When it comes to pause/resume, unless it is done using SIP/SDP it will > not work through any Session Border Gateway as the session will be torn > down after n seconds. > > Thus I think it important that we take a discussion around the use cases, > existing solutions, limitations in those or the proposal to try to > determine what is the most reasonable way of solving the problems and how > to enable; > > 1) Receiver based selection of media streams from a larger set of streams= , > including different quality levels like video resolutions, in a centraliz= ed > conferencing application. > > 2) Optimize the transport so that media streams currently not used can be > turned off temporarily and then quickly resumed when someone determines a > need for the media stream. For example using mechanism (1) but also for > voice activity based, centrally controlled or other mechanisms to select > which media streams are delivered to other session participants. > > We are working to revise our Internet drafts. We seek as much input as > possible into this prior to the meeting so that we can ensure that any > discussion are as on topic and focused as possible. > > Regards > > Bo Burman & Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7141311 > F=E4r=F6gatan 6 | Mobile +46 73 0949021 > SE-164 80 Stockholm, Sweden| mailto: bo.burman at ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --f46d040892c3c76ae304b734bc49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Bo,

Rather than "turning [the media] stream off tem= porarily", you should consider putting the media stream into a low ene= rgy state, which would not be bit rate =3D 0 but would have some limited ke= ep-alive stream that the SBC recognizes to keep the pinhole open.

There are probably multiple ways to make that happen. = =A0Hope that is semantically what you meant.

Mike<= /div>


On Mon, Jan 23, 2012 at 10:50 = AM, Bo Burman <bo.burman@ericsson.com> wrote:
Dispatch,

We have requested agenda time for the upcoming meeting to discuss the subje= ct of Media Stream related signaling. From the feedback we got in AVTEXT WG= on the discussion for a certain problem, the one related to pausing and re= suming sender to middlebox media traffic, it is clear that a more high leve= l discussion needs to happen.

We have two Internet drafts related to the issues we would like to discuss.=
Media Stream Selection (MESS)
=A0- draft-westerlund-dispatch-stream-selection-00
RTP Media Stream Pause and Resume
=A0- draft-westerlund-avtext-rtp-stream-pause-00

The first one (MESS) proposes that for the general selection of media strea= ms, an end-point within a centralized conferencing scenario desires to rece= ive a media plane oriented rather than RTP/RTCP based signaling, which appe= ars to have benefits as discussed in the draft.

As mentioned, the pause resume draft is targeted for a different use case w= here a media plane solution has potential for other benefits. This was disc= ussed and the main outcome of that discussion was three quite different opi= nions;

a) We already do this signaling using TMMBR (RFC 5104) by setting the bit-r= ate value to 0, which the current specs doesn't allow.

b) This should be done in signalling plane, RTP/RTCP shouldn't be bloat= ed. (But I did interpret this as not necessarily needing to be SIP).

c) When it comes to pause/resume, unless it is done using SIP/SDP it will n= ot work through any Session Border Gateway as the session will be torn down= after n seconds.

Thus I think it important that we take a discussion around the use cases, e= xisting solutions, limitations in those or the proposal to try to determine= what is the most reasonable way of solving the problems and how to enable;=

1) Receiver based selection of media streams from a larger set of streams, = including different quality levels like video resolutions, in a centralized= conferencing application.

2) Optimize the transport so that media streams currently not used can be t= urned off temporarily and then quickly resumed when someone determines a ne= ed for the media stream. For example using mechanism (1) but also for voice= activity based, centrally controlled or other mechanisms to select which m= edia streams are delivered to other session participants.

We are working to revise our Internet drafts. We seek as much input as poss= ible into this prior to the meeting so that we can ensure that any discussi= on are as on topic and focused as possible.

Regards

Bo Burman & Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7141311
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949021
SE-164 80 Stockholm, Sweden| mailto: bo.burman at ericsson.com
----------------------------------------------------------------------

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

--f46d040892c3c76ae304b734bc49-- From richard@shockey.us Mon Jan 23 10:37:17 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3556121F8523 for ; Mon, 23 Jan 2012 10:37:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.219 X-Spam-Level: X-Spam-Status: No, score=-100.219 tagged_above=-999 required=5 tests=[AWL=-0.138, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qr-mC-kETD7j for ; Mon, 23 Jan 2012 10:37:16 -0800 (PST) Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 786E521F8512 for ; Mon, 23 Jan 2012 10:37:16 -0800 (PST) Received: (qmail 23189 invoked by uid 0); 23 Jan 2012 18:37:14 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by cpoproxy1.bluehost.com with SMTP; 23 Jan 2012 18:37:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To:References:Cc:To:From; bh=syR1/DFUtYVAFbstnB76krR0gbxC2Dm7xoRmXVocd2Y=; b=g3eL7byzRljxtEYwDOopf8Roh4OY3xW8id5hk+R+ErA0CDkAd8ElFytAPr/A8odSWaCc1P4rrnUqpHI9mRELOWfjBAYCmn0fhPhprbmaX2yhzVSNz+ckWugCT7FCXZ1m; Received: from [173.66.41.162] (helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1RpOlW-0003gV-8O; Mon, 23 Jan 2012 11:37:14 -0700 From: "Richard Shockey" To: "'Henning Schulzrinne'" , References: In-Reply-To: Date: Mon, 23 Jan 2012 13:37:13 -0500 Message-ID: <013b01ccd9fe$06f91710$14eb4530$@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: AczZIAWGv101/0KGSDGvyPot2XKt/QA3JyNQ Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.41.162 authed with richard@shockey.us} Cc: dispatch@ietf.org Subject: Re: [dispatch] Interested in giving a talk at the FCC? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 18:37:17 -0000 I'd like to whole heartedly endorse this suggestion and encourage a variety of IETF Subject matter experts to give talks relevant to the FCC. I personally help arrange two seminars at the FCC at the invitation of Doug Sicker, Henning's predecessor as CTO The first on was a tutorial on SIP and the second on MPLS. As a rule these kinds of talks should be vendor/policy neutral. -----Original Message----- From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Henning Schulzrinne Sent: Sunday, January 22, 2012 11:10 AM To: ietf@ietf.org Subject: Interested in giving a talk at the FCC? If you're interested in giving a seminar to technical staff and/or economists at the US Federal Communications Commission (FCC), please let me know. The FCC won't be able to pay for travel, so we'd likely schedule any talks when you are in the DC area. Also, if you know of any colleagues the Commission staff should hear from, feel free to suggest them. I won't make any promises that I'll be able to accommodate all or even most offers, but this is an experiment to see if we can broaden the perspectives heard at the FCC. Most FCC staff are generalists, so topics should be accessible and of interest to this community. (In general, the FCC deals with many aspects of wired and wireless communications, and is interested in applications, as well as lower layers. Examples of topics of particular interest are spectrum-related issues, increasing broadband availability, security/privacy, IPv6, PSTN-transition issues, public safety and accessibility. Thus, if you're interested, please get in touch with me with a rough description of what you'd talk about. If there's local interest in your topic, I will get back to you to work out details. There is no deadline as such, so consider this a standing offer. Henning ------ Henning Schulzrinne CTO, FCC 7C252, (202) 418-1544 _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf From sohel_khan777@yahoo.com Mon Jan 23 12:51:04 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA2E21F86DA for ; Mon, 23 Jan 2012 12:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElWU8O5SSf7u for ; Mon, 23 Jan 2012 12:51:03 -0800 (PST) Received: from nm1.bullet.mail.bf1.yahoo.com (nm1.bullet.mail.bf1.yahoo.com [98.139.212.160]) by ietfa.amsl.com (Postfix) with SMTP id D7FC821F86AF for ; Mon, 23 Jan 2012 12:50:58 -0800 (PST) Received: from [98.139.212.150] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 23 Jan 2012 20:50:53 -0000 Received: from [98.139.215.250] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 23 Jan 2012 20:50:53 -0000 Received: from [127.0.0.1] by omp1063.mail.bf1.yahoo.com with NNFMP; 23 Jan 2012 20:50:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 319005.26580.bm@omp1063.mail.bf1.yahoo.com Received: (qmail 81987 invoked by uid 60001); 23 Jan 2012 20:50:53 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1327351853; bh=XSfoQ/CORLXoHYv/MdEvzXJVB/pTYSAI8HvLUWbj6nU=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=BLpCGQb7s7crJrg0gzseFBrdDFA/nr7Nj5vqI8sTEcyCYsKqNr/7wnv3WdoTkirZUiwnds5xxQOPAB8R0A1af7TLB4AHXwpo/cqrj43tH0a4BIexEA2aTAwc8F4MZ1EP7SIw/M3qQOv14AyYe2gjPmllC9uhgtAPP/sDKoANb50= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=cFApBP9NA89sp/B+rwI3i24NwOUJYtsgt1vBf3sn4Cab11dHFEIZ19eYvN2+ilf4x+XxLN+tm4j5GmmlKMRvTWA3nZRXCei9fkXREmaYf8UGDo35c0Oj6mW6kTmQy1HSxJvySa9qVEqEgJEPPHuhVcH2gqQkcokH1dAXuKKTAKY=; X-YMail-OSG: iEy_9lQVM1m1_fWvX6azfJ.ozv4uR7ect2.oihz9ey2GFcN uHVPNVmp_o3P8WH5qGUOOt3pCb0EXMGUTJbeog8j8I4tsMULkhtEH4t3y7ms U6kOByOBFNAWi5uuG5qkalPbZWTqL1FfVyDmY3fq.ReU0SxV8Da9jtRoZqhm FZi48bY2mTttZAZughTKby0CH3hcpDqufK73ZwuBZaPRGiKkc0vZTINx_eU7 wCR4aynsmCUv7A_AT9NVBizsK_XD3rqJFxWgw8wlnAuBI2bZ_V57DYYt0IFJ 9lLE_tJIL8MiCj8nA9kopn8W4rovn9ocSTOCqUZAR1sUgE6pOQn1NyuxbLyG .lvh_LhCxG2MI4y2iPj4_M1Eq6rSyrMFOq2jA.nCdZlQ_2sM7r_rokIfe6UU srF47YXUIg0Qh4Oo0cE41Z2kF3FcJI.x8e_X4NLNOlRZDNVYuUO8KSjO34Kb nmoPCR8NZjs3EZ46zG_VQ9dX9BNDxuEw- Received: from [68.87.42.110] by web162006.mail.bf1.yahoo.com via HTTP; Mon, 23 Jan 2012 12:50:52 PST X-Mailer: YahooMailWebService/0.8.116.331537 Message-ID: <1327351852.65491.YahooMailNeo@web162006.mail.bf1.yahoo.com> Date: Mon, 23 Jan 2012 12:50:52 -0800 (PST) From: Sohel Khan To: "dispatch@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1229592896-1874021676-1327351852=:65491" Subject: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sohel Khan List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 20:51:04 -0000 --1229592896-1874021676-1327351852=:65491 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable SIP calls=C2=A0routing in an infinite loop in a subset of networks is a kno= wn phenomenon. =0AVarious SIP methods exist today may be used to detect and= mitigate loops. Operational engineers would like to see a method that indi= cates the sequence of providers=E2=80=99 IDs in the call path. Based on the= input from the operational engineers, we are proposing a=C2=A0new SIP head= er to detect SIP routing loop. This method is preferred by = the operational engineers of large providers=E2=80=99 networks.=0A=C2=A0=0A= If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} arrives t= o Alpha=E2=80=99s network, Alpha=C2=A0will detect 77777777 in the SPID sequ= ence and conclude that a loop has occurred. =0A=C2=A0=0AIn the above use ca= se, an example =E2=80=9CSPID-sequence=E2=80=9Dheader is as follows:=0ASPID-= Sequence:;index=3D1;=0ASPID-Sequence:;index=3D1= .1;=0ASPID-Sequence:;index=3D1.2;=0A=C2=A0=0ASPID-Sequence:;index=3D1;=0ASPID-Sequence:;index=3D1.1;=0ASPID-= Sequence:;index=3D1.2=0ASPID-Sequence:;index=3D1= .3;=0AA provider should not delete any value from the=C2=A0SPID sequence un= less the SPID is its own.=0AWe had some discussion in the DISPATCH meetings= on ideas such as this. We would need a broader community support and help = to initiate a work in IETF RTC WG on SPID sequence.=0APlease let us know yo= ur opinion.=0A=C2=A0=0A=0ARegards, Sohel Khan=0AA provider wishing not to d= ivulge its SPID, may insert a private or a blank value.=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =0AWith = the new method, the SIP INVITE contains the new header SPID sequence {33333= 333, 55555555, 77777777}. =0A=C2=A0=0A=C2=A0=0AAssume that a SIP call origi= nating from=C2=A0provider Alpha (SPID: 77777777) and traversing through=C2= =A0provider Bravo=C2=A0(SPID: 55555555),=C2=A0Charlie (SPID: 33333333), and= looping back to=C2=A0Alpha.=0A --1229592896-1874021676-1327351852=:65491 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
SIP calls routing in an infinite loop in a subset of networks = is a known phenomenon.
Various SIP methods exist today may be = used to detect and mitigate loops. Operational engineers would like = to see a method that indicates the sequence of providers=E2=80=99 IDs in th= e call path. Based on the input from the operational engineers, we are proposing a new SI= P header <SPID Sequence> to detect SIP routing loop. This method is p= referred by the operational engineers of large providers=E2=80=99 networks.=
 
Assume that a SIP call originating from provider Alpha (SPID: 77777777) and tr= aversing through provider Bravo (SPID: 55555555), Charlie (S= PID: 33333333), and looping back to Alpha.
 
With the new m= ethod, the SIP INVITE contains the new header SPID sequence {33333333, 5555= 5555, 77777777}.
 
If a SI= P INVITE with SPID sequence {33333333, 55555555, 77777777} arrives to Alpha= =E2=80=99s network, Alpha will detect 77777777 in the SPID sequence an= d conclude that a loop has occurred.
 
In the above use case, an example =E2=80=9C= SPID-sequence=E2=80=9D header is as follows:
SPID-Sequence:<sip:33333333<= /A>>;index=3D1;
SPID-Sequence:<sip:55555555<= /A>>;index=3D1.1;
SPID-Sequence:<sip:77777777<= /A>>;index=3D1.2;
 
A provider wishing not to divulge its SPI= D, may insert a private or a blank value.     &nbs= p;        
=
SPID-Sequence:<sip:33333333<= /A>>;index=3D1;
SPID-Sequence:<sip:55555555<= /A>>;index=3D1.1;
SPID-Sequence:<sip:77777777<= /A>>;index=3D1.2
SPID-Sequence:<s= ip:PRIVATE>;index=3D1.3;
A provider should not delete= any value from the SPID sequence unless the SPID is its own.
We had some discussion in the DISPATCH meetings on ideas= such as this. We would need a broader community support and help to initia= te a work in IETF RTC WG on SPID sequence.
Please let us know your opinion.
 

 
Regards, Sohel Khan
--1229592896-1874021676-1327351852=:65491-- From dworley@avaya.com Mon Jan 23 13:18:57 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E1421F86C7 for ; Mon, 23 Jan 2012 13:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.186 X-Spam-Level: X-Spam-Status: No, score=-103.186 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 463veNHvIeLv for ; Mon, 23 Jan 2012 13:18:57 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 364ED21F8548 for ; Mon, 23 Jan 2012 13:18:57 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngHAPXNHU/GmAcF/2dsb2JhbABDnV+EIowpgQWBcgEBAQECARJsCwIBCA0IMTITEgEBBAESCBqHWp0nmzWLQ2MEiDuSV4UKh2k X-IronPort-AV: E=Sophos;i="4.71,557,1320642000"; d="scan'208";a="326038650" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Jan 2012 16:18:54 -0500 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jan 2012 16:13:51 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Mon, 23 Jan 2012 16:18:53 -0500 From: "Worley, Dale R (Dale)" To: Sohel Khan , "dispatch@ietf.org" Date: Mon, 23 Jan 2012 16:18:53 -0500 Thread-Topic: [dispatch] SPID Sequence and Loop Detection Thread-Index: AczaEL6ZRsoc1bDiTE2Qd7COMSTgmQAAxDp5 Message-ID: References: <1327351852.65491.YahooMailNeo@web162006.mail.bf1.yahoo.com> In-Reply-To: <1327351852.65491.YahooMailNeo@web162006.mail.bf1.yahoo.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 21:18:57 -0000 > From: Sohel Khan [sohel_khan777@yahoo.com] >=20 > If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} > arrives to Alpha=92s network, Alpha will detect 77777777 in the SPID > sequence and conclude that a loop has occurred. And that conclusion is incorrect, because at the second entry to Alpha, Alpha has no way of knowing that the request-URI is at all the same as the request-URI at the time of first entry to Alpha. In practice, if user A1 on network Alpha call-forwards his phone to user B on network Bravo, and user B call-forwards his phone to user A2 on network Alpha, all calls to A1 will be routed to B, and then to A2, and will be rejected upon the second entry to Alpha. Something closer to the loop detection algorithm of RFC 5393 will be needed. Dale From vkg@bell-labs.com Mon Jan 23 13:35:54 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE58421F861D for ; Mon, 23 Jan 2012 13:35:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.591 X-Spam-Level: X-Spam-Status: No, score=-108.591 tagged_above=-999 required=5 tests=[AWL=2.008, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqEI0TdbeGF0 for ; Mon, 23 Jan 2012 13:35:51 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1778921F8616 for ; Mon, 23 Jan 2012 13:35:51 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q0NLZoFb007635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 Jan 2012 15:35:50 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0NLZo8q024589 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Jan 2012 15:35:50 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q0NLZns0007781 for ; Mon, 23 Jan 2012 15:35:50 -0600 (CST) Message-ID: <4F1DD3A8.80701@bell-labs.com> Date: Mon, 23 Jan 2012 15:39:52 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: "dispatch@ietf.org" 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-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [dispatch] SIP Load Balancing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 21:35:54 -0000 Folks: During the summer IETF (Quebec City, summer 2011) there was a discussion on SIP load balancing [1]. The general hum indicated that folks consider this work important enough to be at least looked at by the IETF, especially given gear from different vendors and the need to perform feedback-based load balancing. The details of what "this work" entails need to be fleshed out. For instance, there were good discussions on whether signaling- only and media-based servers needed different load balancing techniques, and what exactly needs standardization here. Robert rightly suggested that having a document describing existing SIP load balancing techniques would be a good first step to seeing what work needs to be done here. So, responding to that starting point, Partha, Paul and I have put together the beginnings of a survey document that looks at various techniques whereby load balancing is done today [2]. The work is not complete, but a good start towards getting a document that describes different techniques in use today. We will like to start a larger discussion on the survey document to see if we have adequately captured the different ways to do load balancing today. Our hope is that this work will serve as input to the questions of exactly what should be standardized. To that extent, we kindly solicit your comments and thoughts on the survey draft. Thanks, [1] http://www.ietf.org/proceedings/81/minutes/dispatch.txt [2] http://tools.ietf.org/html/draft-partha-dispatch-siploadbalancing-survey-00 - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From HKaplan@acmepacket.com Mon Jan 23 23:15:43 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7847321F8601 for ; Mon, 23 Jan 2012 23:15:43 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OosD25AbC7Yk for ; Mon, 23 Jan 2012 23:15:42 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id A4F4521F85FD for ; Mon, 23 Jan 2012 23:15:42 -0800 (PST) Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 24 Jan 2012 02:15:39 -0500 Received: from MAIL2.acmepacket.com ([169.254.2.176]) by Mail1.acmepacket.com ([169.254.1.108]) with mapi id 14.01.0270.001; Tue, 24 Jan 2012 02:15:39 -0500 From: Hadriel Kaplan To: "dispatch@ietf.org list" Thread-Topic: STRAW Charter Proposal Thread-Index: AQHM2mf5LnZ1j84CGUegN4A8YOcfrw== Date: Tue, 24 Jan 2012 07:15:38 +0000 Message-ID: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Subject: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 07:15:43 -0000 Howdy, As instructed by DISPATCH chairs, I am re-posting the STRAW Charter Proposa= l, as a topic for the Paris meeting. The proposed charter is as follows: Description of STRAW Working Group =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Name: Sip Traversal Required for Applications to Work (STRAW) Problem Statement:=20 Within the context of the SIP protocol and architecture, a Back-to-Back Use= r Agent (B2BUA) is any SIP device in the logical path between two User Agen= ts performing a role beyond that of a Proxy as defined in RFC 3261. The B2= BUA may be as simple as a session-stateful Proxy becoming a B2BUA in order = to terminate dead sessions by generating BYEs; or it may be a 3PCC-style ag= ent only modifying SDP; or it may be a Session Border Controller performing= such functions as in RFC 5853; or it may be an Enterprise PBX terminating = REFERs and such; or it may be a complete UAS and UAC implementation with a = PRI loopback in-between.=20 In its most extreme form, the scope of the SIP protocol ends at the UAS of = the B2BUA, and a new SIP protocol scope begins on its UAC side. In practic= e, however, users expect some SIP protocol aspects to go beyond the scope o= f the B2BUA's UAS side, and be traversed onto its UAC side, as if the B2BUA= was not an end unto itself; this is similar to the expectation that emails= work when they cross from POP and IMAP to/from SMTP. It is impossible to normatively define all the behaviors of B2BUAs in gener= al, or even subsets of them such as SBCs. Unlike consumer NATs, B2BUAs perf= orm widely varying functions for purposes which may be unique to their envi= ronment, unique to their architecture, or unique to the wishes of their adm= inistrator. Instead of defining all things a given type of B2BUA must do, = a more practical objective would be to define what very few things any B2BU= A must do to make a specific SIP mechanism work, and let the market decide = whether to do those things. The name of this working group reflects that practical objective: if there = were a thin straw between the SIP UAS and UAC of a B2BUA, what must be pass= ed through that straw and used on each side. Or viewed another way, if a B= 2BUA were in fact a UAS and UAC connected with a PRI loopback circuit, and = if we could extend ISDN, what information would we carry in ISDN across the= PRI for a specific SIP mechanism to work end-to-end. For example, the WG could produce a document which specifies that the Max-F= orwards header field value should be copied and decremented across the B2BU= A, if the B2BUA wishes to prevent loops. Administrators could then tell th= eir B2BUA vendors to comply with the document, if the administrator so wish= es. Objectives: The objectives of the STRAW Working Group are to publish normative document= s which define which SIP header fields, parameters, MIME bodies, body conte= nt fields/information, or media-plane characteristics are required to trave= rse between the User Agent "sides" of a B2BUA for specific functions to wor= k. =20 Deliverables would indicate which types of B2BUAs would apply or not. For = example, a document defining the requirements for end-to-end DTLS-SRTP woul= d not apply to B2BUAs which terminate media, such as transcoders or recorde= rs. The intention of this WG is to document such requirements in separate docum= ents, per SIP or media function, instead of as one document for all functio= ns. That will both reduce the time to publication, as well a provide B2BUA= administrators and manufacturers with simple comply/no-comply criteria. Initial Deliverables: 1) A taxonomy document defining role-types of B2BUAs, as a reference for ot= her deliverables. 2) A document defining the requirements for B2BUAs with respect to loop det= ection/prevention. 3) A document defining the requirements for B2BUAs to support end-to-end an= d hop-by-hop media-loopback test calls. 4) A document defining the requirements for B2BUAs to support DTLS-SRTP (RF= C 5764) end-to-end. 5) A document defining the requirements for B2BUAs to support STUN connecti= vity checks end-to-end. From bo.burman@ericsson.com Tue Jan 24 00:22:28 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66B7F21F8566 for ; Tue, 24 Jan 2012 00:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3xdpKoiP+ZS for ; Tue, 24 Jan 2012 00:22:27 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id A033D21F8577 for ; Tue, 24 Jan 2012 00:22:26 -0800 (PST) X-AuditID: c1b4fb3d-b7b26ae000000a35-8a-4f1e6a413bfa Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7F.6F.02613.14A6E1F4; Tue, 24 Jan 2012 09:22:25 +0100 (CET) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.126]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 24 Jan 2012 09:22:25 +0100 From: Bo Burman To: Michael Hammer Date: Tue, 24 Jan 2012 09:22:22 +0100 Thread-Topic: [dispatch] Media Stream related signaling Thread-Index: AczZ7jUfu+g1NWx+RPCm93WOziqMLwAfn0UQ Message-ID: <05F760EF51FA6A4F804F9759C239313A3271BADF04@ESESSCMS0361.eemea.ericsson.se> References: <05F760EF51FA6A4F804F9759C239313A3271BADD0B@ESESSCMS0361.eemea.ericsson.se> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: multipart/alternative; boundary="_000_05F760EF51FA6A4F804F9759C239313A3271BADF04ESESSCMS0361e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Media Stream related signaling X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 08:22:28 -0000 --_000_05F760EF51FA6A4F804F9759C239313A3271BADF04ESESSCMS0361e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mike, yes, that is in principle what was intended with "pause" - something that i= s as low energy as possible but that is readily available and can be quickl= y and efficiently resumed when needed again. We did think about what to send instead of the paused media. It is however = not clear to us if it will be sufficient to use e.g. ICE or RTP-RTCP Mux as= keepalive to make the SBC keep the pinhole, or if it will be necessary to = use actual RTP media packets to create a keepalive stream. That is also the= case when neither ICE nor RTP-RTCP Mux are used. Any ideas? BR /Bo ________________________________ From: Michael Hammer [mailto:mphmmr@gmail.com] Sent: Monday, January 23, 2012 5:44 PM To: Bo Burman Cc: dispatch@ietf.org Subject: Re: [dispatch] Media Stream related signaling Bo, Rather than "turning [the media] stream off temporarily", you should consid= er putting the media stream into a low energy state, which would not be bit= rate =3D 0 but would have some limited keep-alive stream that the SBC reco= gnizes to keep the pinhole open. There are probably multiple ways to make that happen. Hope that is semanti= cally what you meant. Mike On Mon, Jan 23, 2012 at 10:50 AM, Bo Burman > wrote: Dispatch, We have requested agenda time for the upcoming meeting to discuss the subje= ct of Media Stream related signaling. From the feedback we got in AVTEXT WG= on the discussion for a certain problem, the one related to pausing and re= suming sender to middlebox media traffic, it is clear that a more high leve= l discussion needs to happen. We have two Internet drafts related to the issues we would like to discuss. Media Stream Selection (MESS) - draft-westerlund-dispatch-stream-selection-00 RTP Media Stream Pause and Resume - draft-westerlund-avtext-rtp-stream-pause-00 The first one (MESS) proposes that for the general selection of media strea= ms, an end-point within a centralized conferencing scenario desires to rece= ive a media plane oriented rather than RTP/RTCP based signaling, which appe= ars to have benefits as discussed in the draft. As mentioned, the pause resume draft is targeted for a different use case w= here a media plane solution has potential for other benefits. This was disc= ussed and the main outcome of that discussion was three quite different opi= nions; a) We already do this signaling using TMMBR (RFC 5104) by setting the bit-r= ate value to 0, which the current specs doesn't allow. b) This should be done in signalling plane, RTP/RTCP shouldn't be bloated. = (But I did interpret this as not necessarily needing to be SIP). c) When it comes to pause/resume, unless it is done using SIP/SDP it will n= ot work through any Session Border Gateway as the session will be torn down= after n seconds. Thus I think it important that we take a discussion around the use cases, e= xisting solutions, limitations in those or the proposal to try to determine= what is the most reasonable way of solving the problems and how to enable; 1) Receiver based selection of media streams from a larger set of streams, = including different quality levels like video resolutions, in a centralized= conferencing application. 2) Optimize the transport so that media streams currently not used can be t= urned off temporarily and then quickly resumed when someone determines a ne= ed for the media stream. For example using mechanism (1) but also for voice= activity based, centrally controlled or other mechanisms to select which m= edia streams are delivered to other session participants. We are working to revise our Internet drafts. We seek as much input as poss= ible into this prior to the meeting so that we can ensure that any discussi= on are as on topic and focused as possible. Regards Bo Burman & Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7141311 F=E4r=F6gatan 6 | Mobile +46 73 0949021 SE-164 80 Stockholm, Sweden| mailto: bo.burman at ericsson.com ---------------------------------------------------------------------- _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_05F760EF51FA6A4F804F9759C239313A3271BADF04ESESSCMS0361e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Mike,
 
yes, that is in principle what was intended with "= pause" -=20 something that is as low energy as possible but that is readily available a= nd=20 can be quickly and efficiently resumed when needed again.
 
We did think about what to send instead of the pau= sed=20 media. It is however not clear to us if it will be sufficient to use e.g. I= CE or=20 RTP-RTCP Mux as keepalive to make the SBC keep the pinhole, or if it will b= e=20 necessary to use actual RTP media packets to create a keepalive stream. Tha= t is=20 also the case when neither ICE nor RTP-RTCP Mux are used. Any=20 ideas?
 
BR
/Bo

From: Michael Hammer [mailto:mphmmr@gma= il.com]=20
Sent: Monday, January 23, 2012 5:44 PM
To: Bo=20 Burman
Cc: dispatch@ietf.org
Subject: Re: [dispatch] Me= dia=20 Stream related signaling

Bo,

Rather than "turning [the media] stream off temporarily", you should=20 consider putting the media stream into a low energy state, which would not = be=20 bit rate =3D 0 but would have some limited keep-alive stream that the SBC=20 recognizes to keep the pinhole open.

There are probably multiple ways to make that happen.  Hope that = is=20 semantically what you meant.

Mike


On Mon, Jan 23, 2012 at 10:50 AM, Bo Burman <bo.burman@ericsson.com>=20 wrote:
Dispatch,

We=20 have requested agenda time for the upcoming meeting to discuss the subjec= t of=20 Media Stream related signaling. From the feedback we got in AVTEXT WG on = the=20 discussion for a certain problem, the one related to pausing and resuming= =20 sender to middlebox media traffic, it is clear that a more high level=20 discussion needs to happen.

We have two Internet drafts related to= the=20 issues we would like to discuss.
Media Stream Selection (MESS)
&nbs= p;-=20 draft-westerlund-dispatch-stream-selection-00
RTP Media Stream Pause a= nd=20 Resume
 - draft-westerlund-avtext-rtp-stream-pause-00

The = first=20 one (MESS) proposes that for the general selection of media streams, an=20 end-point within a centralized conferencing scenario desires to receive a= =20 media plane oriented rather than RTP/RTCP based signaling, which appears = to=20 have benefits as discussed in the draft.

As mentioned, the pause r= esume=20 draft is targeted for a different use case where a media plane solution h= as=20 potential for other benefits. This was discussed and the main outcome of = that=20 discussion was three quite different opinions;

a) We already do th= is=20 signaling using TMMBR (RFC 5104) by setting the bit-rate value to 0, whic= h the=20 current specs doesn't allow.

b) This should be done in signalling= =20 plane, RTP/RTCP shouldn't be bloated. (But I did interpret this as not=20 necessarily needing to be SIP).

c) When it comes to pause/resume,= =20 unless it is done using SIP/SDP it will not work through any Session Bord= er=20 Gateway as the session will be torn down after n seconds.

Thus I t= hink=20 it important that we take a discussion around the use cases, existing=20 solutions, limitations in those or the proposal to try to determine what = is=20 the most reasonable way of solving the problems and how to enable;
1)=20 Receiver based selection of media streams from a larger set of streams,=20 including different quality levels like video resolutions, in a centraliz= ed=20 conferencing application.

2) Optimize the transport so that media= =20 streams currently not used can be turned off temporarily and then quickly= =20 resumed when someone determines a need for the media stream. For example = using=20 mechanism (1) but also for voice activity based, centrally controlled or = other=20 mechanisms to select which media streams are delivered to other session=20 participants.

We are working to revise our Internet drafts. We see= k as=20 much input as possible into this prior to the meeting so that we can ensu= re=20 that any discussion are as on topic and focused as=20 possible.

Regards

Bo Burman & Magnus=20 Westerlund

-------------------------------------------------------= ---------------
Multimedia=20 Technologies, Ericsson Research=20 EAB/TVM
--------------------------------------------------------------= --------
Ericsson=20 AB                | Phone  <= A=20 href=3D"tel:%2B46%2010%207141311" value=3D"+46107141311">+46 10=20 7141311
F=E4r=F6gatan 6             =  =20  | Mobile +46 73=20 0949021
SE-164 80 Stockholm, Sweden| mailto: bo.burman at ericsson.com
-------------------------------------= ---------------------------------

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

--_000_05F760EF51FA6A4F804F9759C239313A3271BADF04ESESSCMS0361e_-- From ron.even.tlv@gmail.com Tue Jan 24 03:06:01 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F5F21F8546 for ; Tue, 24 Jan 2012 03:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5z4T1SNNL5n for ; Tue, 24 Jan 2012 03:06:00 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1D121F853D for ; Tue, 24 Jan 2012 03:05:59 -0800 (PST) Received: by eaai13 with SMTP id i13so1704738eaa.31 for ; Tue, 24 Jan 2012 03:05:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=rLosjVl9bKiVGM2MYI1SoPkFvhZvrCnTlzaBSRjTjRw=; b=HBuq8FEN9Tw8PloD8AZZdmCiaMs4PGO0v4fF14WUhaYg1q2+ICdZ2sUv3lGgA+Yyis 076JXMsLnYT199c/bOR+mufGj80OTwsz4VzsWphRF3haJZznhEvnoEvxV5u7xDwP2qtd 1vmcxSKamxjJen117r/HBtdr2/gzN56BouLjA= Received: by 10.213.14.147 with SMTP id g19mr321499eba.126.1327403158951; Tue, 24 Jan 2012 03:05:58 -0800 (PST) Received: from windows8d787f9 ([109.67.208.29]) by mx.google.com with ESMTPS id c16sm66316190eei.1.2012.01.24.03.05.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 24 Jan 2012 03:05:58 -0800 (PST) From: "Roni Even" To: "'Bo Burman'" , References: <05F760EF51FA6A4F804F9759C239313A3271BADD0B@ESESSCMS0361.eemea.ericsson.se> In-Reply-To: <05F760EF51FA6A4F804F9759C239313A3271BADD0B@ESESSCMS0361.eemea.ericsson.se> Date: Tue, 24 Jan 2012 13:02:04 +0200 Message-ID: <4f1e9096.107f0e0a.3451.6ef8@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: AczZ5rhYJCBqmo1vRaCfF/ps/EzATQAoG+7g Content-Language: en-us Subject: Re: [dispatch] Media Stream related signaling X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 11:06:01 -0000 Hi, About a) We already do this signaling using TMMBR (RFC 5104) by setting the bit-rate value to 0, which the current specs doesn't allow. I am not sure why? The text in 3.5.4 "The limit may change to any value between zero and the session maximum, as negotiated during session establishment signaling." And there is also the message format in section 4.2.1.1 allows the value of 0 Thanks Roni Even > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Bo Burman > Sent: Monday, January 23, 2012 5:50 PM > To: dispatch@ietf.org > Subject: [dispatch] Media Stream related signaling >=20 > Dispatch, >=20 > We have requested agenda time for the upcoming meeting to discuss the > subject of Media Stream related signaling. From the feedback we got in > AVTEXT WG on the discussion for a certain problem, the one related to > pausing and resuming sender to middlebox media traffic, it is clear > that a more high level discussion needs to happen. >=20 > We have two Internet drafts related to the issues we would like to > discuss. > Media Stream Selection (MESS) > - draft-westerlund-dispatch-stream-selection-00 > RTP Media Stream Pause and Resume > - draft-westerlund-avtext-rtp-stream-pause-00 >=20 > The first one (MESS) proposes that for the general selection of media > streams, an end-point within a centralized conferencing scenario > desires to receive a media plane oriented rather than RTP/RTCP based > signaling, which appears to have benefits as discussed in the draft. >=20 > As mentioned, the pause resume draft is targeted for a different use > case where a media plane solution has potential for other benefits. > This was discussed and the main outcome of that discussion was three > quite different opinions; >=20 > a) We already do this signaling using TMMBR (RFC 5104) by setting the > bit-rate value to 0, which the current specs doesn't allow. >=20 > b) This should be done in signalling plane, RTP/RTCP shouldn't be > bloated. (But I did interpret this as not necessarily needing to be > SIP). >=20 > c) When it comes to pause/resume, unless it is done using SIP/SDP it > will not work through any Session Border Gateway as the session will = be > torn down after n seconds. >=20 > Thus I think it important that we take a discussion around the use > cases, existing solutions, limitations in those or the proposal to try > to determine what is the most reasonable way of solving the problems > and how to enable; >=20 > 1) Receiver based selection of media streams from a larger set of > streams, including different quality levels like video resolutions, in > a centralized conferencing application. >=20 > 2) Optimize the transport so that media streams currently not used can > be turned off temporarily and then quickly resumed when someone > determines a need for the media stream. For example using mechanism = (1) > but also for voice activity based, centrally controlled or other > mechanisms to select which media streams are delivered to other = session > participants. >=20 > We are working to revise our Internet drafts. We seek as much input as > possible into this prior to the meeting so that we can ensure that any > discussion are as on topic and focused as possible. >=20 > Regards >=20 > Bo Burman & Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7141311 > F=E4r=F6gatan 6 | Mobile +46 73 0949021 > SE-164 80 Stockholm, Sweden| mailto: bo.burman at ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From magnus.westerlund@ericsson.com Tue Jan 24 04:42:47 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8128521F84DF for ; Tue, 24 Jan 2012 04:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.765 X-Spam-Level: X-Spam-Status: No, score=-109.765 tagged_above=-999 required=5 tests=[AWL=0.834, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyZdKPEQxtE2 for ; Tue, 24 Jan 2012 04:42:47 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id AF54921F84A2 for ; Tue, 24 Jan 2012 04:42:46 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-8c-4f1ea7452677 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 69.71.27041.547AE1F4; Tue, 24 Jan 2012 13:42:45 +0100 (CET) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 24 Jan 2012 13:42:45 +0100 Message-ID: <4F1EA744.5080803@ericsson.com> Date: Tue, 24 Jan 2012 13:42:44 +0100 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Roni Even References: <05F760EF51FA6A4F804F9759C239313A3271BADD0B@ESESSCMS0361.eemea.ericsson.se> <4f1e9096.107f0e0a.3451.6ef8@mx.google.com> In-Reply-To: <4f1e9096.107f0e0a.3451.6ef8@mx.google.com> X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Media Stream related signaling : Why not TMMBR X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 12:42:47 -0000 On 2012-01-24 12:02, Roni Even wrote: > Hi, > > About > a) We already do this signaling using TMMBR (RFC 5104) by setting the > bit-rate value to 0, which the current specs doesn't allow. > > I am not sure why? The text in 3.5.4 "The limit may change to any value > between zero and the session maximum, as negotiated during session > establishment > signaling." And there is also the message format in section 4.2.1.1 > allows the value of 0 Roni, Our main argument is that the semantics of TMMBR is not generally matching the one needed for pause an resume. As indicated in the AVTEXT slides unless you are absolutely certain that there are no other RTP entity on the path between the TMMBR issuing and the TMMBR responding entity using it to set to 0 can cause significant issues for that other party in that the stream is pause for that entity also. Another problem with TMMBR is that is has the following NORMATIVE requirement on how it goes about increasing the bit-rate: If the media sender concludes that it can increase the maximum total media bit rate value, it SHALL wait before actually doing so, for a period long enough to allow a media receiver to respond to the TMMBN if it determines that its tuple belongs in the bounding set. This delay period is estimated by the formula: 2 * RTT + T_Dither_Max, Thus a receiver should not get media until 2*RTT + T_Dither_Max after it request "RESUME". But following this clearly makes TMMBR unusable for PAUSE RESUME. And this is required also in point to point: Even in point-to-point sessions, a media sender MUST obey the aforementioned rule, as it is not guaranteed that a participant is able to determine correctly whether all the sources are co-located in a single node, and are coordinated. Thus at a minimum if one like to use TMMBR we need to redefine TMMBR such that it allows for the functionality. That likely means separating the two use cases from each other to avoid the risk of miss classification of topologies. Which from my perspective means different signalling code-points to make it clear to the end-points what to do. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From lennox@cs.columbia.edu Tue Jan 24 08:00:24 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD14D21F85A3 for ; Tue, 24 Jan 2012 08:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXtuNDjp4E1m for ; Tue, 24 Jan 2012 08:00:24 -0800 (PST) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3E921F85A2 for ; Tue, 24 Jan 2012 08:00:24 -0800 (PST) Received: from compute01.cs.columbia.edu (compute01.cs.columbia.edu [128.59.11.31]) by mailbackend.panix.com (Postfix) with ESMTP id 197852EC86; Tue, 24 Jan 2012 11:00:22 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20254.54678.532914.974442@compute01.cs.columbia.edu> Date: Tue, 24 Jan 2012 11:00:22 -0500 To: Hadriel Kaplan In-Reply-To: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> References: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> X-Mailer: VM 7.19 under Emacs 22.1.1 From: lennox@cs.columbia.edu Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 16:00:24 -0000 On Tuesday, January 24 2012, "Hadriel Kaplan" wrote to "dispatch@ietf.org list" saying: > Howdy, > As instructed by DISPATCH chairs, I am re-posting the STRAW Charter Proposal, as a topic for the Paris meeting. > The proposed charter is as follows: One item that I think is important to raise here -- though it should perhaps be part of the taxonomy document, rather than in the charter itself -- is that there needs to be a fairly rigorous notion of what kinds of devices are *not* B2BUAs in STRAW's scope. In particular, while an MCU can be regarded as a collection of two or more UAs back-to-back-to-back, I think it's not anyone's intention that MCU behavior be in scope for STRAW. It seems to me that the cases where STRAW should apply -- i.e., where the intended semantic is that two dialogs are the "same call" -- are very similar to (perhaps the same as) the cases where two dialogs should have the same Session-ID. Thus reducing to a previous (intractable) problem. -- Jonathan Lennox lennox@cs.columbia.edu / jonathan@vidyo.com From pkyzivat@alum.mit.edu Tue Jan 24 08:20:11 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CE221F8604 for ; Tue, 24 Jan 2012 08:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.617 X-Spam-Level: X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZPWLT0gLTYL for ; Tue, 24 Jan 2012 08:20:11 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id EF76221F85C4 for ; Tue, 24 Jan 2012 08:20:10 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta03.westchester.pa.mail.comcast.net with comcast id RUEN1i00B0vyq2s53ULBCH; Tue, 24 Jan 2012 16:20:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta05.westchester.pa.mail.comcast.net with comcast id RULB1i00C07duvL3RULBDL; Tue, 24 Jan 2012 16:20:11 +0000 Message-ID: <4F1EDA39.6060504@alum.mit.edu> Date: Tue, 24 Jan 2012 11:20:09 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <4FCD68F4-C9CE-4C90-8DFC-02AE85562C77@acmepacket.com> <20254.54678.532914.974442@compute01.cs.columbia.edu> In-Reply-To: <20254.54678.532914.974442@compute01.cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [dispatch] STRAW Charter Proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 16:20:11 -0000 On 1/24/12 11:00 AM, lennox@cs.columbia.edu wrote: > It seems to me that the cases where STRAW should apply -- i.e., where the > intended semantic is that two dialogs are the "same call" -- are very > similar to (perhaps the same as) the cases where two dialogs should have the > same Session-ID. Thus reducing to a previous (intractable) problem. :-) From richard@shockey.us Tue Jan 24 12:28:37 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB8121F854A for ; Tue, 24 Jan 2012 12:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.091 X-Spam-Level: X-Spam-Status: No, score=-99.091 tagged_above=-999 required=5 tests=[AWL=-1.197, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPBcLHop-gak for ; Tue, 24 Jan 2012 12:28:36 -0800 (PST) Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 9583421F8532 for ; Tue, 24 Jan 2012 12:28:36 -0800 (PST) Received: (qmail 20509 invoked by uid 0); 24 Jan 2012 20:28:35 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy8.bluehost.com with SMTP; 24 Jan 2012 20:28:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=k577J0Fl1PtfGdH7EgVtkPLu+sHrNVWTLk7qyyTtgNw=; b=W0yir1Cx+GkiFSCUEWefdz8YD6j21fXp2NHhXC74F68uIEcKRLNPXNo2InyHxnkI9ULlq3hfH5/R1+o3Asv55HmBeyAotPzkPRO6YGvrvZ6GQztINQmQI76TaIxzC1c/; Received: from [173.66.41.162] (helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1Rpmyp-0008CE-4H; Tue, 24 Jan 2012 13:28:35 -0700 From: "Richard Shockey" To: , , Date: Tue, 24 Jan 2012 15:28:33 -0500 Message-ID: <00fc01ccdad6$bf28f250$3d7ad6f0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FD_01CCDAAC.D652EA50" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acza1r5eb73JA2MmQeS1U+mk/++X0w== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.41.162 authed with richard@shockey.us} Subject: [dispatch] FYI : Canada's CRTC mandates all IP Interconnection for voice. X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 20:28:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00FD_01CCDAAC.D652EA50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In this decision, the Commission decides that it is in the public interest to establish a set of principles to facilitate IP voice network interconnections between network operators while allowing market forces to shape the details of the arrangements. Specifically, in areas where a carrier provides IP voice interconnection to an affiliate, a division of its operations, or an unrelated service provider, the carrier must negotiate a similar arrangement with any other carrier that requests such an arrangement. Within six months of a formal request, an arrangement is to be concluded. http://www.crtc.gc.ca/eng/com100/2012/r120119.htm Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org ------=_NextPart_000_00FD_01CCDAAC.D652EA50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

In this decision, the = Commission decides that it is in the public interest to establish a set = of principles to facilitate IP voice network interconnections between = network operators while allowing market forces to shape the details of = the arrangements. Specifically, in areas where a carrier provides IP = voice interconnection to an affiliate, a division of its operations, or = an unrelated service provider, the carrier must negotiate a similar = arrangement with any other carrier that requests such an arrangement. = Within six months of a formal request, an arrangement is to be = concluded.

 

http://www.crt= c.gc.ca/eng/com100/2012/r120119.htm

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP = Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype= -linkedin-facebook: rshockey101
http//www.sipforum.org

 

------=_NextPart_000_00FD_01CCDAAC.D652EA50-- From sohel_khan777@yahoo.com Tue Jan 24 13:59:47 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EEA11E8086 for ; Tue, 24 Jan 2012 13:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgX7qbY96oNo for ; Tue, 24 Jan 2012 13:59:46 -0800 (PST) Received: from nm14.bullet.mail.bf1.yahoo.com (nm14.bullet.mail.bf1.yahoo.com [98.139.212.173]) by ietfa.amsl.com (Postfix) with SMTP id 404DE11E8079 for ; Tue, 24 Jan 2012 13:59:46 -0800 (PST) Received: from [98.139.212.153] by nm14.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jan 2012 21:59:45 -0000 Received: from [98.139.212.223] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 24 Jan 2012 21:59:45 -0000 Received: from [127.0.0.1] by omp1032.mail.bf1.yahoo.com with NNFMP; 24 Jan 2012 21:59:45 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 662691.6472.bm@omp1032.mail.bf1.yahoo.com Received: (qmail 74506 invoked by uid 60001); 24 Jan 2012 21:59:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1327442385; bh=ZG+zVDEHC64zl889R7DMrD0oo+MKROKS1UR1xlQAh1E=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Gshe79tuwv92jYGE5hwx2tg1fGi9d5sW007z/oJMEh2WhjTb7is+YAQUBM4lshDaZulh14Rnfaqll8ClRhDkNbLWNXXKuhTqwxB6wQOX0GYKwqtDycQ/9rmWOwfscLJG7BRBTEeZ/jKbG1xRLYjgDWrDyCU1SmRJtUoo3ibjhTU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=j9BkjsZAOm+nt/G0zM/W4PkJcVzA9LalJAt6eP5OfjBJ4Nbi7bjVNYiL09NB3otuBEUstJuSJG+MQeKsxU3VLvFBlurqLuH1AG/MdG8hIYnAJoe7cbHjkA26JZ2xxRMOfjPH0tqlT5Oosd7n2igX3icqWWjcGPv7vdX60rMMk4A=; X-YMail-OSG: GzG58tgVM1lIqMt9wNxLQ2_hdpLOr2vjHKK2lof8augEZkz WwfXs47rhkq2mdyjFC7JOKA5rxDQHJVylWlz0DGDKqny2d6OXPIdeAaG5PSL wTnnuxQjZIOybQl22HW4atfBwM2aISD9Sko19d7g_ViN5_HgBzD6Nz2qQI47 Siu9nsaJnBhgImsfGkO_zrDlM3KPgVAH70OWYQsx56gKLWCSBTB3P85aULOg 4BuvbBSxOo1VLY1aTQa9D8yN7rBlQX9iz4LcjlaDX4w57xnT0GqhkHjEBu4y WdGYyBru9FV6xCn3ySEhl1xrSvkXN9Sv0Y.B5PgyHF0guQTVt9jdWLoJ4I5x DdTIChiTWAczsJn12Uf_L.IsHtArgpfYo9pFwR9iybzy3kJBR_Znw.NRBfEZ Xy0SoxH5piCqN9FF45r.6Wlev5FKTKbLEAlhBi_ciHleRcxKPKHWyag1BYTJ wnPxXXjypS6deRfvfsSpj0gCO8Als6BEMwjkkg6wGwzs1vpYd5Eid Received: from [68.87.42.110] by web162005.mail.bf1.yahoo.com via HTTP; Tue, 24 Jan 2012 13:59:45 PST X-Mailer: YahooMailWebService/0.8.116.331537 References: <1327351852.65491.YahooMailNeo@web162006.mail.bf1.yahoo.com> Message-ID: <1327442385.69551.YahooMailNeo@web162005.mail.bf1.yahoo.com> Date: Tue, 24 Jan 2012 13:59:45 -0800 (PST) From: Sohel Khan To: "dispatch@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1328350513-1008145155-1327442385=:69551" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sohel Khan List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 21:59:47 -0000 ---1328350513-1008145155-1327442385=:69551 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable We are not discussing routing loop due to call forwarding.=0AVarious loop m= itigation mechanism=C2=A0may=C2=A0be applicable=C2=A0to=C2=A0mitigate diffe= rent types of routing loops.=0ASPID sequence mechanism may apply to routing= loops due to least cost routing=C2=A0=0AProvider Alpha routes the call to = Provider Bravo because Provider Alpha considers that Provider Bravo is a le= ast cost route.=0AProvider Bravo routes the call to Provider Charlie becaus= e Provider Bravo considers that Provider Charlie is a least cost route.=0AP= rovider Charlie routes the call back to Provider Alpha because Provider Cha= rlie considers that Provider Alpha is a least cost route. Thus, an infinite= routing loop=C2=A0occurs.=C2=A0 SPID Sequence can be hypothetically viewed= as the BGP AS_PATH route vector=0ARegards, Sohel Khan=0A=0A=0A____________= ____________________=0AFrom: "Worley, Dale R (Dale)" =0A= To: Sohel Khan ; "dispatch@ietf.org" =0ASent: Monday, January 23, 2012 4:18 PM=0ASubject: RE: [dispatch] = SPID Sequence and Loop Detection=0A=0A> From: Sohel Khan [sohel_khan777@yah= oo.com]=0A> =0A> If a SIP INVITE with SPID sequence {33333333, 55555555, 77= 777777}=0A> arrives to Alpha=E2=80=99s network, Alpha will detect 77777777 = in the SPID=0A> sequence and conclude that a loop has occurred.=0A=0AAnd th= at conclusion is incorrect, because at the second entry to=0AAlpha, Alpha h= as no way of knowing that the request-URI is at all the=0Asame as the reque= st-URI at the time of first entry to Alpha.=0A=0AIn practice, if user A1 on= network Alpha call-forwards his phone to=0Auser B on network Bravo, and us= er B call-forwards his phone to user A2=0Aon network Alpha, all calls to A1= will be routed to B, and then to A2,=0Aand will be rejected upon the secon= d entry to Alpha.=0A=0ASomething closer to the loop detection algorithm of = RFC 5393 will be=0Aneeded.=0A=0ADale ---1328350513-1008145155-1327442385=:69551 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
We are not discussing routing loop due to= call forwarding.
Various loop mitigation mechanism may be applicable = ;to mitigate different types of routing loops.
SPID sequence mechanism may apply to routing loops due to least co= st routing
Provider Alpha routes the call to Provider Bravo because Provider = Alpha considers that Provider Bravo is a least cost route.
Provider Bravo routes the call to Provider Charlie because Provide= r Bravo considers that Provider Charlie is a least cost route.<= /o:p>
Provider Charlie routes the call back to Provider Alpha because Pr= ovider Charlie considers that Provider Alpha is a least cost route. Thus, a= n infinite routing loop occurs.  SPID Sequence can be hypothetica= lly viewed as the BGP AS_PATH route vector
&nbs= p;
Regards, Sohel Khan
From:= "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Sohel Khan <sohel_khan777@yaho= o.com>; "dispatch@ietf.org" <dispatch@ietf.org>
Sent: Monday, January 23, 2012 4:18 PMSubject: RE: [dispatch] SP= ID Sequence and Loop Detection

> From: Sohel Khan [<= A href=3D"mailto:sohel_khan777@yahoo.com" ymailto=3D"mailto:sohel_khan777@y= ahoo.com">sohel_khan777@yahoo.com]
>
> If a SIP INVITE wit= h SPID sequence {33333333, 55555555, 77777777}
> arrives to Alpha=E2=80=99s network,= Alpha will detect 77777777 in the SPID
> sequence and conclude that = a loop has occurred.

And that conclusion is incorrect, because at th= e second entry to
Alpha, Alpha has no way of knowing that the request-UR= I is at all the
same as the request-URI at the time of first entry to Al= pha.

In practice, if user A1 on network Alpha call-forwards his phon= e to
user B on network Bravo, and user B call-forwards his phone to user= A2
on network Alpha, all calls to A1 will be routed to B, and then to A= 2,
and will be rejected upon the second entry to Alpha.

Something= closer to the loop detection algorithm of RFC 5393 will be
needed.
<= BR>Dale


---1328350513-1008145155-1327442385=:69551-- From pkyzivat@alum.mit.edu Tue Jan 24 19:21:03 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF1E11E8086 for ; Tue, 24 Jan 2012 19:21:03 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvsV-L++a2iD for ; Tue, 24 Jan 2012 19:21:02 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAC021F84FB for ; Tue, 24 Jan 2012 19:21:00 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta08.westchester.pa.mail.comcast.net with comcast id Rf7m1i0031swQuc58fM19M; Wed, 25 Jan 2012 03:21:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id RfM11i00607duvL3bfM1jn; Wed, 25 Jan 2012 03:21:01 +0000 Message-ID: <4F1F751C.2000309@alum.mit.edu> Date: Tue, 24 Jan 2012 22:21:00 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <1327351852.65491.YahooMailNeo@web162006.mail.bf1.yahoo.com> <1327442385.69551.YahooMailNeo@web162005.mail.bf1.yahoo.com> In-Reply-To: <1327442385.69551.YahooMailNeo@web162005.mail.bf1.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 03:21:03 -0000 On 1/24/12 4:59 PM, Sohel Khan wrote: > We are not discussing routing loop due to call forwarding. > Various loop mitigation mechanism may be applicable to mitigate > different types of routing loops. You may not be discussing/considering those things, but you should be, because (as Dale explained) the mechanism you are proposing would *break* non-loop calls that revisit the same provider. Thanks, Paul > SPID sequence mechanism may apply to routing loops due to least cost routing > Provider Alpha routes the call to Provider Bravo because Provider Alpha > considers that Provider Bravo is a least cost route. > Provider Bravo routes the call to Provider Charlie because Provider > Bravo considers that Provider Charlie is a least cost route. > Provider Charlie routes the call back to Provider Alpha because Provider > Charlie considers that Provider Alpha is a least cost route. Thus, an > infinite routing loop occurs. SPID Sequence can be hypothetically viewed > as the BGP AS_PATH route vector > Regards, Sohel Khan > *From:* "Worley, Dale R (Dale)" > *To:* Sohel Khan ; "dispatch@ietf.org" > > *Sent:* Monday, January 23, 2012 4:18 PM > *Subject:* RE: [dispatch] SPID Sequence and Loop Detection > >> From: Sohel Khan [sohel_khan777@yahoo.com > ] >> >> If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} >> arrives to Alpha’s network, Alpha will detect 77777777 in the SPID >> sequence and conclude that a loop has occurred. > > And that conclusion is incorrect, because at the second entry to > Alpha, Alpha has no way of knowing that the request-URI is at all the > same as the request-URI at the time of first entry to Alpha. > > In practice, if user A1 on network Alpha call-forwards his phone to > user B on network Bravo, and user B call-forwards his phone to user A2 > on network Alpha, all calls to A1 will be routed to B, and then to A2, > and will be rejected upon the second entry to Alpha. > > Something closer to the loop detection algorithm of RFC 5393 will be > needed. > > Dale > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From ibc@aliax.net Wed Jan 25 04:57:34 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5EF21F85B5 for ; Wed, 25 Jan 2012 04:57:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uirWkdyXk+1Y for ; Wed, 25 Jan 2012 04:57:33 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 93A1121F85B4 for ; Wed, 25 Jan 2012 04:57:33 -0800 (PST) Received: by ggnq4 with SMTP id q4so2147667ggn.31 for ; Wed, 25 Jan 2012 04:57:33 -0800 (PST) Received: by 10.101.27.2 with SMTP id e2mr5752332anj.52.1327496253177; Wed, 25 Jan 2012 04:57:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.108.18 with HTTP; Wed, 25 Jan 2012 04:57:12 -0800 (PST) In-Reply-To: <1327351852.65491.YahooMailNeo@web162006.mail.bf1.yahoo.com> References: <1327351852.65491.YahooMailNeo@web162006.mail.bf1.yahoo.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 25 Jan 2012 13:57:12 +0100 Message-ID: To: Sohel Khan X-Gm-Message-State: ALoCoQmRsgLh5tzpyVW5d1vllMXKAJjGOI/bW5+z7Qy9WCBF+/STqOsCHr/Vkbo7N8iNug1hX453 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 12:57:34 -0000 2012/1/23 Sohel Khan : > SIP calls=C2=A0routing in an infinite loop in a subset of networks is a k= nown > phenomenon. > Various SIP methods exist today may be used to detect and mitigate loops. > Operational engineers would like to see a method that indicates the seque= nce > of providers=E2=80=99 IDs in the call path. Based on the input from the o= perational > engineers, we are proposing a=C2=A0new SIP header to dete= ct SIP > routing loop. This method is preferred by the operational engineers of la= rge > providers=E2=80=99 networks. IMHO RFC 5393 is the correct way to go. Your proposal breaks valid scenarios. Check RC 5393. --=20 I=C3=B1aki Baz Castillo From sohel_khan777@yahoo.com Wed Jan 25 14:25:17 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA8211E80A6 for ; Wed, 25 Jan 2012 14:25:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.513 X-Spam-Level: X-Spam-Status: No, score=0.513 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_20=-0.74, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFRqI81o6GQe for ; Wed, 25 Jan 2012 14:25:16 -0800 (PST) Received: from nm25.bullet.mail.bf1.yahoo.com (nm25.bullet.mail.bf1.yahoo.com [98.139.212.184]) by ietfa.amsl.com (Postfix) with SMTP id 5646C11E8098 for ; Wed, 25 Jan 2012 14:25:16 -0800 (PST) Received: from [98.139.215.142] by nm25.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jan 2012 22:25:10 -0000 Received: from [98.139.215.248] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 25 Jan 2012 22:25:10 -0000 Received: from [127.0.0.1] by omp1061.mail.bf1.yahoo.com with NNFMP; 25 Jan 2012 22:25:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 550860.33783.bm@omp1061.mail.bf1.yahoo.com Received: (qmail 87325 invoked by uid 60001); 25 Jan 2012 22:25:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1327530310; bh=e+5TpRt8TD5/B9fSf43zW0Zn7C196qX5VZDiDoHWlX8=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:To:MIME-Version:Content-Type; b=t8lRfRI7oYLkCeH5HaoNce0VDnb2yNIea5ssh0ArPWYREloSrNGSjkk965e0AfMKb8W6DxheScegXJE4sR6HAnoJbk66Iwsyw2Kd7JNmKgDYf09nTO++HRcshrvuEGtUkemBHQ+0SSKXy3FDe75In5wlXq9CXar8B8izRgmykNA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:To:MIME-Version:Content-Type; b=QwZntZHaoK0ML8rPgABFDTkoYSPGcjExIdgugIuWEeOIOUilvY7VUOEBavBtv3pVWAJK1sIwNlQcoheFpwjRoZ0wFobYX+uX+sbsZW8cywJ9ubotm/9yOqFDv7vfqrTyglZsbvc2Z2ktQVzSyI8lAUOkg1J/w9h8hNTq0E+UJos=; X-YMail-OSG: ok.0HVUVM1leXi2YYB0oxmAmIUPtGrA5HePSjMqxZq.afnQ w4scFgTH_LjkLmwWKPN0FnlUyEbav4jaLXBrgBYkHYUgiBfmm0x8vXBO.zwK pE_TAENJUY2wCyBCY7oFdc8PEF8MTKRktWpz6LFy_7zkpKfFOSKJs6iA1.Ev ZSa_J2hwvyXdopqzOmr6QMgk66wPegEJRD0I1L0VlSAR97XSWk7VvcPTaKUB rDBxEoIqywV3nL2hDd_peMzssQGW8M9Irm6XTVqyz2lag3P9NBKIlTdrNisp MHV6IThdAA9z3j1gO_U6Vl.0lY7pQ7nEWIVgu02x7K50qKSNfwpqkBudMtSX q8mIn6qPFE2pFooBZKjxh9.iJbexlsQgCZ3OztFN4LDbmkQmXV.HWy1b5Fnx 1fRRaY0WYveMoByMnAc61wAiHoTSDlAVRUleOvEHup270MNR_.8uNR9hJmkC 65b0Eq6HVIpRN5NCcz7t5ETJmwQcpVg-- Received: from [68.87.42.110] by web162002.mail.bf1.yahoo.com via HTTP; Wed, 25 Jan 2012 14:25:10 PST X-Mailer: YahooMailWebService/0.8.116.331537 Message-ID: <1327530310.86812.YahooMailNeo@web162002.mail.bf1.yahoo.com> Date: Wed, 25 Jan 2012 14:25:10 -0800 (PST) From: Sohel Khan To: "dispatch@ietf.org" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4756291-252513321-1327530310=:86812" Subject: [dispatch] (no subject) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sohel Khan List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 22:25:17 -0000 --4756291-252513321-1327530310=:86812 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Paul and Dale.=0AI think the provider interal rule may vary.=0ADepen= ding upon a provider internal rule, a provider may or may not take action b= ased upon the information in the SPID sequence. Even inside a provider, the= re can be two different types of SIP agents. One may choose to take particu= lar action based on the information on the SPID and the other session agent= may not take any action based on the information on the SPID. =0APlease le= t me know if I still missing something.=0AFor the call forwarding loops, th= e operatioonal engineers prefer to use Diversion counter to break loops. = =0AI will read the RFC that Dale suggested and will get back to you on this= =A0further.=0A=A0=0ASohel=0A=A0=0AMessage: 3=0ADate: Tue, 24 Jan 2012 22:21= :00 -0500=0AFrom: Paul Kyzivat =0ATo: dispatch@ietf.= org=0ASubject: Re: [dispatch] SPID Sequence and Loop Detection=0AMessage-ID= : <4F1F751C.2000309@alum.mit.edu>=0AContent-Type: text/plain; charset=3Dwin= dows-1252; format=3Dflowed=0A=0AOn 1/24/12 4:59 PM, Sohel Khan wrote:=0A> W= e are not discussing routing loop due to call forwarding.=0A> Various loop = mitigation mechanism may be applicable to mitigate=0A> different types of r= outing loops.=0A=0AYou may not be discussing/considering those things, but = you should be, =0Abecause (as Dale explained) the mechanism you are proposi= ng would =0A*break* non-loop calls that revisit the same provider.=0A=0A=A0= =A0=A0 Thanks,=0A=A0=A0=A0 Paul=0A=0A=0ARegards, Sohel Khan --4756291-252513321-1327530310=:86812 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Paul and Dale.
I think the provider= interal rule may vary.
Depending upon a pro= vider internal rule, a provider may or may not take action based upon the i= nformation in the SPID sequence. Even in= side a provider, there can be two different types of SIP agents. One may ch= oose to take particular action based on the information on the SPID and the other session agent may not take any action = based on the information on the SPID.
Please let me know i= f I still missing something.
For the call forward= ing loops, the operatioonal engineers prefer to use Diversion counter to br= eak loops.
I will read the RFC = that Dale suggested and will get back to you on this further.
 
Sohel
 
Message: 3
Date: = Tue, 24 Jan 2012 22:21:00 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.e= du>
To: dispatch@ietf.org<= BR>Subject: Re: [dispatch] SPID Sequence and Loop Detection
Message-ID: = < I will read the RFC that Dale suggested and will get back to you on this > further. > Sohel > Message: 3 > Date: Tue, 24 Jan 2012 22:21:00 -0500 > From: Paul Kyzivat > > To: dispatch@ietf.org > Subject: Re: [dispatch] SPID Sequence and Loop Detection > Message-ID: <4F1F751C.2000309@alum.mit.edu > > > Content-Type: text/plain; charset=windows-1252; format=flowed > > On 1/24/12 4:59 PM, Sohel Khan wrote: >> We are not discussing routing loop due to call forwarding. >> Various loop mitigation mechanism may be applicable to mitigate >> different types of routing loops. > > You may not be discussing/considering those things, but you should be, > because (as Dale explained) the mechanism you are proposing would > *break* non-loop calls that revisit the same provider. > > Thanks, > Paul > Regards, Sohel Khan > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From harald@alvestrand.no Fri Jan 27 00:42:06 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBDD221F8566 for ; Fri, 27 Jan 2012 00:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.074 X-Spam-Level: X-Spam-Status: No, score=-110.074 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7frNz4TyDsVe for ; Fri, 27 Jan 2012 00:42:06 -0800 (PST) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id CA09221F8562 for ; Fri, 27 Jan 2012 00:42:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9B8A339E0FA; Fri, 27 Jan 2012 09:42:04 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxREoOENT-Vf; Fri, 27 Jan 2012 09:42:03 +0100 (CET) Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id C697539E0BE; Fri, 27 Jan 2012 09:42:03 +0100 (CET) Message-ID: <4F22635B.1030708@alvestrand.no> Date: Fri, 27 Jan 2012 09:42:03 +0100 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Bo Burman References: <05F760EF51FA6A4F804F9759C239313A3271BADD0B@ESESSCMS0361.eemea.ericsson.se> In-Reply-To: <05F760EF51FA6A4F804F9759C239313A3271BADD0B@ESESSCMS0361.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Media Stream related signaling X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 08:42:07 -0000 Note - a related draft is this one (expired): draft-lennox-mmusic-sdp-source-selection-02.txt It proposes an SDP-based mechanism for turning streams on and off. This subject has also been discussed in RTCWEB, and may also be in scope for CLUE. Harald On 01/23/2012 04:50 PM, Bo Burman wrote: > Dispatch, > > We have requested agenda time for the upcoming meeting to discuss the subject of Media Stream related signaling. From the feedback we got in AVTEXT WG on the discussion for a certain problem, the one related to pausing and resuming sender to middlebox media traffic, it is clear that a more high level discussion needs to happen. > > We have two Internet drafts related to the issues we would like to discuss. > Media Stream Selection (MESS) > - draft-westerlund-dispatch-stream-selection-00 > RTP Media Stream Pause and Resume > - draft-westerlund-avtext-rtp-stream-pause-00 > > The first one (MESS) proposes that for the general selection of media streams, an end-point within a centralized conferencing scenario desires to receive a media plane oriented rather than RTP/RTCP based signaling, which appears to have benefits as discussed in the draft. > > As mentioned, the pause resume draft is targeted for a different use case where a media plane solution has potential for other benefits. This was discussed and the main outcome of that discussion was three quite different opinions; > > a) We already do this signaling using TMMBR (RFC 5104) by setting the bit-rate value to 0, which the current specs doesn't allow. > > b) This should be done in signalling plane, RTP/RTCP shouldn't be bloated. (But I did interpret this as not necessarily needing to be SIP). > > c) When it comes to pause/resume, unless it is done using SIP/SDP it will not work through any Session Border Gateway as the session will be torn down after n seconds. > > Thus I think it important that we take a discussion around the use cases, existing solutions, limitations in those or the proposal to try to determine what is the most reasonable way of solving the problems and how to enable; > > 1) Receiver based selection of media streams from a larger set of streams, including different quality levels like video resolutions, in a centralized conferencing application. > > 2) Optimize the transport so that media streams currently not used can be turned off temporarily and then quickly resumed when someone determines a need for the media stream. For example using mechanism (1) but also for voice activity based, centrally controlled or other mechanisms to select which media streams are delivered to other session participants. > > We are working to revise our Internet drafts. We seek as much input as possible into this prior to the meeting so that we can ensure that any discussion are as on topic and focused as possible. > > Regards > > Bo Burman& Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7141311 > Färögatan 6 | Mobile +46 73 0949021 > SE-164 80 Stockholm, Sweden| mailto: bo.burman at ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From fluffy@fluffy.im Fri Jan 27 10:56:29 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CCAA21F8643 for ; Fri, 27 Jan 2012 10:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.505 X-Spam-Level: X-Spam-Status: No, score=-3.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xx4Kz0aNAyL8 for ; Fri, 27 Jan 2012 10:56:28 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC52321F8642 for ; Fri, 27 Jan 2012 10:56:28 -0800 (PST) Received: by dado14 with SMTP id o14so1940929dad.31 for ; Fri, 27 Jan 2012 10:56:28 -0800 (PST) Received: by 10.68.118.136 with SMTP id km8mr16704910pbb.73.1327690588488; Fri, 27 Jan 2012 10:56:28 -0800 (PST) Received: from [192.168.4.100] (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id i10sm21982681pbg.10.2012.01.27.10.56.26 (version=SSLv3 cipher=OTHER); Fri, 27 Jan 2012 10:56:27 -0800 (PST) Sender: Cullen Jennings Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: <1327351852.65491.YahooMailNeo@web162006.mail.bf1.yahoo.com> Date: Fri, 27 Jan 2012 11:56:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1BAB1005-A9DA-4C31-99A8-7BADD03C34C2@iii.ca> References: <1327351852.65491.YahooMailNeo@web162006.mail.bf1.yahoo.com> To: Sohel Khan X-Mailer: Apple Mail (2.1084) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2012 18:56:29 -0000 When doing least cost routing, my experience has been that if A delivers = the call to B that B will then send to C, B wants to hide this fact from = C and certainly wants to hide from A that they the call went to C. = Otherwise B gets cut out and A and C just set up a peering deal = directly.=20 So I worry a scheme like this would not work as B's SBC would be = configured to remove this.=20 On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote: > SIP calls routing in an infinite loop in a subset of networks is a = known phenomenon. > Various SIP methods exist today may be used to detect and mitigate = loops. Operational engineers would like to see a method that indicates = the sequence of providers=92 IDs in the call path. Based on the input = from the operational engineers, we are proposing a new SIP header to detect SIP routing loop. This method is preferred by the = operational engineers of large providers=92 networks. > =20 > Assume that a SIP call originating from provider Alpha (SPID: = 77777777) and traversing through provider Bravo (SPID: 55555555), = Charlie (SPID: 33333333), and looping back to Alpha. > =20 > With the new method, the SIP INVITE contains the new header SPID = sequence {33333333, 55555555, 77777777}. > =20 > If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} = arrives to Alpha=92s network, Alpha will detect 77777777 in the SPID = sequence and conclude that a loop has occurred. > =20 > In the above use case, an example =93SPID-sequence=94 header is as = follows: > SPID-Sequence:;index=3D1; > SPID-Sequence:;index=3D1.1; > SPID-Sequence:;index=3D1.2; > =20 > A provider wishing not to divulge its SPID, may insert a private or a = blank value. =20 > SPID-Sequence:;index=3D1; > SPID-Sequence:;index=3D1.1; > SPID-Sequence:;index=3D1.2 > SPID-Sequence:;index=3D1.3; > A provider should not delete any value from the SPID sequence unless = the SPID is its own. > We had some discussion in the DISPATCH meetings on ideas such as this. = We would need a broader community support and help to initiate a work in = IETF RTC WG on SPID sequence. > Please let us know your opinion. > =20 >=20 > =20 > Regards, Sohel Khan > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From sohel_khan777@yahoo.com Mon Jan 30 12:14:38 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C174621F86A3 for ; Mon, 30 Jan 2012 12:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.172 X-Spam-Level: X-Spam-Status: No, score=0.172 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFtjjE1SGGL4 for ; Mon, 30 Jan 2012 12:14:38 -0800 (PST) Received: from nm40-vm7.bullet.mail.bf1.yahoo.com (nm40-vm7.bullet.mail.bf1.yahoo.com [72.30.239.215]) by ietfa.amsl.com (Postfix) with SMTP id ACA6721F8699 for ; Mon, 30 Jan 2012 12:14:37 -0800 (PST) Received: from [98.139.212.151] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 30 Jan 2012 20:14:37 -0000 Received: from [98.139.212.217] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 30 Jan 2012 20:14:37 -0000 Received: from [127.0.0.1] by omp1026.mail.bf1.yahoo.com with NNFMP; 30 Jan 2012 20:14:37 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 122011.62888.bm@omp1026.mail.bf1.yahoo.com Received: (qmail 49612 invoked by uid 60001); 30 Jan 2012 20:14:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1327954476; bh=Il1xT9yFNs9Q+oPyMTuG0DxDyl1o50TxfT1rk5ourk0=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=n53Rr6Wf55jGqGezyabcqXw0MiAz80ZNzkdkisKvbR6pzFkPEDfhpwZ4ZNb00jGYIGea7gP5tL0Pwvypbji9YGZu3MNQMWd/ABQVjlX/exRKhRcPoAREpZpsYXrxTZq3koRuPfwYSVLTu2V5llM4+e2JvtROwtcDaW+9FbMxXDE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=atQQEPCWTBwmFp92WihAoYpRbhpijzd9ikDFx+R2wY1VwTcMh0qIELj1eaIehLQiG5JCn8R7F4xQnyBdo9jgOtLDGghX4JN44qV3FgCALUSgziCY3wXhoSGwGRS0G05uT8j/NBnpY659NnFAWeh/JRpie/MbdW6eUyqrVfxr294=; X-YMail-OSG: kJIJBrIVM1majRrzalCIoSjnTZlfWruPxLlhZqDhmEyhTiE dlw4CVqmistvfDjDfXnMN_gYr0WQgkFDGo1Zs6IMsPtBv_wV352LaOcnKebd lGiuSmqnj9VA9sLTfK1NyiPhoJ17_x6e6UkJk1nHT7wTw7nRZWe.VTsKSgOD CvFaTREDS4t6YJa0RYC01NwqXnZDOVQdklX7byqHoZWYX4opm1yj54T9Vr_V HiD8Sux9tTCOXjGzFLYtaVeprAfhHScfXK8bdJ81kLhkrq7.Avgsat5jPaeC NWVN9NsQrqdR7gMOu.akcZAzihLicpXuEXQvYHmfr845UakEcZ78v_SYc5co ZBnwN7VscZH.wSfFaLhnc.EXbEP0lwhELzJKXNhqYPLurQQen8AnpVIK2Bx_ .fRsv4r5U2f3P63NwY97TGWWuJs70uLASC5lqKDZRmxI4MQfJCR0_4umPG1R CevE3YtuAmp_W.ZIMbxUILtT7KnXqWK93LvUCoYqBNIFQkB2KG4dx Received: from [68.87.42.110] by web162002.mail.bf1.yahoo.com via HTTP; Mon, 30 Jan 2012 12:14:36 PST X-Mailer: YahooMailWebService/0.8.116.331537 References: <1327351852.65491.YahooMailNeo@web162006.mail.bf1.yahoo.com> <1BAB1005-A9DA-4C31-99A8-7BADD03C34C2@iii.ca> Message-ID: <1327954476.49537.YahooMailNeo@web162002.mail.bf1.yahoo.com> Date: Mon, 30 Jan 2012 12:14:36 -0800 (PST) From: Sohel Khan To: Cullen Jennings In-Reply-To: <1BAB1005-A9DA-4C31-99A8-7BADD03C34C2@iii.ca> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4756291-657517060-1327954476=:49537" Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sohel Khan List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 20:14:38 -0000 --4756291-657517060-1327954476=:49537 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Cullen.=0AActually, in my opinion, providers neither=C2=A0will add a= =C2=A0=C2=A0SPID nor will add a=C2=A0known deterministic=C2=A0number.=0AIns= tead, providers will implement a stochastic model, and will add a private e= ncrypted number so that only a provider can decrypt its own identity in the= chain.=0A=C2=A0=0A=C2=A0Regards, Sohel Khan=0A=0A=0A______________________= __________=0AFrom: Cullen Jennings =0ATo: Sohel Khan =0ACc: "dispatch@ietf.org" =0ASent: = Friday, January 27, 2012 1:56 PM=0ASubject: Re: [dispatch] SPID Sequence an= d Loop Detection=0A=0A=0AWhen doing least cost routing, my experience has b= een that if A delivers the call to B that B will then send to C, B wants to= hide this fact from C and certainly wants to hide from A that they the cal= l went to C. Otherwise B gets cut out and A and C just set up a peering dea= l directly. =0A=0ASo I worry a scheme like this would not work as B's SBC w= ould be configured to remove this. =0A=0A=0AOn Jan 23, 2012, at 1:50 PM, So= hel Khan wrote:=0A=0A> SIP calls routing in an infinite loop in a subset of= networks is a known phenomenon.=0A> Various SIP methods exist today may be= used to detect and mitigate loops. Operational engineers would like to see= a method that indicates the sequence of providers=E2=80=99 IDs in the call= path. Based on the input from the operational engineers, we are proposing = a new SIP header to detect SIP routing loop. This method is= preferred by the operational engineers of large providers=E2=80=99 network= s.=0A>=C2=A0 =0A> Assume that a SIP call originating from provider Alpha (S= PID: 77777777) and traversing through provider Bravo (SPID: 55555555), Char= lie (SPID: 33333333), and looping back to Alpha.=0A>=C2=A0 =0A> With the ne= w method, the SIP INVITE contains the new header SPID sequence {33333333, 5= 5555555, 77777777}.=0A>=C2=A0 =0A> If a SIP INVITE with SPID sequence {3333= 3333, 55555555, 77777777} arrives to Alpha=E2=80=99s network, Alpha will de= tect 77777777 in the SPID sequence and conclude that a loop has occurred.= =0A>=C2=A0 =0A> In the above use case, an example =E2=80=9CSPID-sequence=E2= =80=9D header is as follows:=0A> SPID-Sequence:;index=3D1;=0A= > SPID-Sequence:;index=3D1.1;=0A> SPID-Sequence:;index=3D1.2;=0A>=C2=A0 =0A> A provider wishing not to divulge its SPID, m= ay insert a private or a blank value.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =0A> SPID-Sequence:;index=3D1;=0A> SPID-Sequence:<= sip:55555555>;index=3D1.1;=0A> SPID-Sequence:;index=3D1.2=0A>= SPID-Sequence:;index=3D1.3;=0A> A provider should not delete = any value from the SPID sequence unless the SPID is its own.=0A> We had som= e discussion in the DISPATCH meetings on ideas such as this. We would need = a broader community support and help to initiate a work in IETF RTC WG on S= PID sequence.=0A> Please let us know your opinion.=0A>=C2=A0 =0A> =0A>=C2= =A0 =0A> Regards, Sohel Khan=0A> __________________________________________= _____=0A> dispatch mailing list=0A> dispatch@ietf.org=0A> https://www.ietf.= org/mailman/listinfo/dispatch --4756291-657517060-1327954476=:49537 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks Cullen.
Actually, in my opin= ion, providers neither will add a  SPID nor will add a = known deterministic number.
Instead, providers w= ill implement a stochastic model, and will add a private encrypted number s= o that only a provider can decrypt its own identity in the chain.
 
 Regards, Soh= el Khan
From:= Cullen Jennings <fluffy@iii.ca>
To: Sohel Khan <sohel_khan777@yahoo.com> Cc: "dispatch@ietf.org" &= lt;dispatch@ietf.org>
Sent: Friday, January 27, 2012 1:56 PM
Subject: Re: [dispatch] SPID Sequence and Loop Detection


When doing least cost routing, my experience has bee= n that if A delivers the call to B that B will then send to C, B wants to h= ide this fact from C and certainly wants to hide from A that they the call went to C. Ot= herwise B gets cut out and A and C just set up a peering deal directly.
So I worry a scheme like this would not work as B's SBC would be confi= gured to remove this.


On Jan 23, 2012, at 1:50 PM, Sohel Khan w= rote:

> SIP calls routing in an infinite loop in a subset of netw= orks is a known phenomenon.
> Various SIP methods exist today may be = used to detect and mitigate loops. Operational engineers would like to see = a method that indicates the sequence of providers=E2=80=99 IDs in the call = path. Based on the input from the operational engineers, we are proposing a= new SIP header <SPID Sequence> to detect SIP routing loop. This meth= od is preferred by the operational engineers of large providers=E2=80=99 ne= tworks.
> 
> Assume that a SIP call originating from prov= ider Alpha (SPID: 77777777) and traversing through provider Bravo (SPID: 55555555), Charlie (SPID: 33333333), and looping back to Alpha.
>&nb= sp;
> With the new method, the SIP INVITE contains the new header SP= ID sequence {33333333, 55555555, 77777777}.
> 
> If a SIP= INVITE with SPID sequence {33333333, 55555555, 77777777} arrives to Alpha= =E2=80=99s network, Alpha will detect 77777777 in the SPID sequence and con= clude that a loop has occurred.
> 
> In the above use cas= e, an example =E2=80=9CSPID-sequence=E2=80=9D header is as follows:
>= SPID-Sequence:<sip:33333333>;index=3D1;
> SPID-Sequence:<si= p:55555555>;index=3D1.1;
> SPID-Sequence:<sip:77777777>;inde= x=3D1.2;
> 
> A provider wishing not to divulge its SPID,= may insert a private or a blank value.          &= nbsp;  
> SPID-Sequence:<sip:33333333>;index=3D1;
>= SPID-Sequence:<sip:55555555>;index=3D1.1;
> SPID-Sequence:<sip:77777777>;index=3D1.2
> SPID-Sequence:<s= ip:PRIVATE>;index=3D1.3;
> A provider should not delete any value = from the SPID sequence unless the SPID is its own.
> We had some disc= ussion in the DISPATCH meetings on ideas such as this. We would need a broa= der community support and help to initiate a work in IETF RTC WG on SPID se= quence.
> Please let us know your opinion.
> 
> > 
> Regards, Sohel Khan
> __________________________= _____________________
> dispatch mailing list
> dispatch@ietf.or= g
> https://www.ietf.org/mailman/listinfo/dispatch


--4756291-657517060-1327954476=:49537-- From pkyzivat@alum.mit.edu Mon Jan 30 12:30:21 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8497111E80BB for ; Mon, 30 Jan 2012 12:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRMVNZLY2NdM for ; Mon, 30 Jan 2012 12:30:20 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id A4FE111E8091 for ; Mon, 30 Jan 2012 12:30:20 -0800 (PST) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta04.westchester.pa.mail.comcast.net with comcast id Tvxx1i0061uE5Es54wWMrd; Mon, 30 Jan 2012 20:30:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id TwWL1i01C07duvL3cwWLKC; Mon, 30 Jan 2012 20:30:21 +0000 Message-ID: <4F26FDD7.6090403@alum.mit.edu> Date: Mon, 30 Jan 2012 15:30:15 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <1327351852.65491.YahooMailNeo@web162006.mail.bf1.yahoo.com> <1BAB1005-A9DA-4C31-99A8-7BADD03C34C2@iii.ca> <1327954476.49537.YahooMailNeo@web162002.mail.bf1.yahoo.com> In-Reply-To: <1327954476.49537.YahooMailNeo@web162002.mail.bf1.yahoo.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 20:30:21 -0000 On 1/30/12 3:14 PM, Sohel Khan wrote: > Thanks Cullen. > Actually, in my opinion, providers neither will add a SPID nor will add > a known deterministic number. > Instead, providers will implement a stochastic model, and will add a > private encrypted number so that only a provider can decrypt its own > identity in the chain. So, are you withdrawing your proposal? Or are you suggesting modifying it to carry these encrypted ids? If the latter, then I guess what you are proposing is a new mechanism by which a provider can tell that a message has returned to it after having been routed to some other provider? To use that it would have to attempt to decrypt every value in the list. And most of the time none of those would turn out to be its own. And the revisit to the provider may be legitimate, rather than a "loop". Rather than that, you might want to review draft-kaplan-dispatch-b2bua-loop-detection-00 and draft-jones-ipmc-session-id-reqts-01, which might serve your purpose. Thanks, Paul > Regards, Sohel Khan > *From:* Cullen Jennings > *To:* Sohel Khan > *Cc:* "dispatch@ietf.org" > *Sent:* Friday, January 27, 2012 1:56 PM > *Subject:* Re: [dispatch] SPID Sequence and Loop Detection > > > When doing least cost routing, my experience has been that if A delivers > the call to B that B will then send to C, B wants to hide this fact from > C and certainly wants to hide from A that they the call went to C. > Otherwise B gets cut out and A and C just set up a peering deal directly. > > So I worry a scheme like this would not work as B's SBC would be > configured to remove this. > > > On Jan 23, 2012, at 1:50 PM, Sohel Khan wrote: > > > SIP calls routing in an infinite loop in a subset of networks is a > known phenomenon. > > Various SIP methods exist today may be used to detect and mitigate > loops. Operational engineers would like to see a method that indicates > the sequence of providers’ IDs in the call path. Based on the input from > the operational engineers, we are proposing a new SIP header Sequence> to detect SIP routing loop. This method is preferred by the > operational engineers of large providers’ networks. > > > > Assume that a SIP call originating from provider Alpha (SPID: > 77777777) and traversing through provider Bravo (SPID: 55555555), > Charlie (SPID: 33333333), and looping back to Alpha. > > > > With the new method, the SIP INVITE contains the new header SPID > sequence {33333333, 55555555, 77777777}. > > > > If a SIP INVITE with SPID sequence {33333333, 55555555, 77777777} > arrives to Alpha’s network, Alpha will detect 77777777 in the SPID > sequence and conclude that a loop has occurred. > > > > In the above use case, an example “SPID-sequence” header is as follows: > > SPID-Sequence:;index=1; > > SPID-Sequence:;index=1.1; > > SPID-Sequence:;index=1.2; > > > > A provider wishing not to divulge its SPID, may insert a private or a > blank value. > > SPID-Sequence:;index=1; > > SPID-Sequence:;index=1.1; > > SPID-Sequence:;index=1.2 > > SPID-Sequence:;index=1.3; > > A provider should not delete any value from the SPID sequence unless > the SPID is its own. > > We had some discussion in the DISPATCH meetings on ideas such as > this. We would need a broader community support and help to initiate a > work in IETF RTC WG on SPID sequence. > > Please let us know your opinion. > > > > > > > > Regards, Sohel Khan > > _______________________________________________ > > 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 sohel_khan777@yahoo.com Mon Jan 30 13:47:14 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E66F21F8459 for ; Mon, 30 Jan 2012 13:47:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[AWL=1.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuaUDf4uFyIp for ; Mon, 30 Jan 2012 13:47:13 -0800 (PST) Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) by ietfa.amsl.com (Postfix) with SMTP id 9623811E80B0 for ; Mon, 30 Jan 2012 13:47:08 -0800 (PST) Received: from [98.139.212.149] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 30 Jan 2012 21:47:08 -0000 Received: from [98.139.212.213] by tm6.bullet.mail.bf1.yahoo.com with NNFMP; 30 Jan 2012 21:47:08 -0000 Received: from [127.0.0.1] by omp1022.mail.bf1.yahoo.com with NNFMP; 30 Jan 2012 21:47:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 73712.30028.bm@omp1022.mail.bf1.yahoo.com Received: (qmail 59060 invoked by uid 60001); 30 Jan 2012 21:47:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1327960027; bh=WS+93uHHENGrmFIKPEl9QqCxN8t7XRB8cZoNELhXDT4=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=DrUKJKECl+LXge2RPEutT/CEDRakjCdUXAaVJ71srD4dVVy1LFLqdlH2brdVVPjlmeYnR0eIhnukvPlke19s5/cDkqIaiSCPeYACA6KKJ8kfE8C3VDF45N0zhbJfjA5shJbpMcQzAIGKxJORu5bL332Bp5lOBep0UoEKXP8gLvA= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=YT8aCw+H+k+BCOFp7R8X9YWh/U2SIz6ISQiPcNH4zdc+rWXXQlY7TXJjn379AlG6H+/Cy4N+3zJ/7NBYPCsgM5EotG0C08IO55g3EEG3EEkj2IcTTrq4urpHAabF808cVGBbFdYn9omNZCox6j4h0lqUjwoLWAfNxvUNPUF6mug=; X-YMail-OSG: 9mxaIY4VM1kdpbmuU0CKpA0PJ3QrTYIvXJdoIf.4sKh.T.8 jm8i_TRHcla1HIJv4krEjO4Sjf6MG4VzAg_6As.DksAdbhYLIwKPNgYIngCm IohnyRk3rbQGp6IF47KfB_nVxfVQPsEfYioamt2IV4.f4m3tZEZq04rWUcZF 6A0sB8JwE5JJR8cCmv.5ihHMVjp22iQMB_hV1T98.vFySObm7_LMrwayVR8T VoUPbRjMKjaBOTvCzAaVGPBbbmYTc8XunhhqAdBdWYNBNe_DMrdRQr_DJKK5 q38ybs2PhV2zf5OAkBHvfh1PaO6KryDyProeEDrFoVBSK6woiwfKrk79LUb. Eear2xgubbtCz0nf_2M0X0xKFmeg6dMSHZEpnGTnt0QmP15t20BGiun0pNy6 ql6C42bmfag8dujStrADL.7cOmQmve2f.QtJ5OToQdLnkX0cOjOIwJkp3SZO x6tRF9ajlgbeCXsHAqMHsSBH05yfp_a.oLbWdxw87e26T.7VfNuA- Received: from [68.87.42.110] by web162001.mail.bf1.yahoo.com via HTTP; Mon, 30 Jan 2012 13:47:07 PST X-Mailer: YahooMailWebService/0.8.116.331537 References: Message-ID: <1327960027.29111.YahooMailNeo@web162001.mail.bf1.yahoo.com> Date: Mon, 30 Jan 2012 13:47:07 -0800 (PST) From: Sohel Khan To: "dispatch@ietf.org" , Paul Kyzivat In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1969517296-869412809-1327960027=:29111" Subject: Re: [dispatch] SPID Sequence and Loop Detection (Paul Kyzivat) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sohel Khan List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 21:47:14 -0000 --1969517296-869412809-1327960027=:29111 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thank you Paul for the good input.=0ALet us discuss the two scenarios in de= tails.=0AThe scenarios:=0A1) Loop due to call forwarding=0A2) Route analysi= s=0A=A0=0ALoop due to call forwarding:=0AMy=A0analysis of=A0the empirical d= ata shows that the majority of the loops due to call forwarding occur due i= n a Fixed-Mobile convergence scenario. A user Jon Doe has two phones: Wirel= ines and Wireless with two telephone numbers (TNine and TNess). Mr. Doe set= s call forward of his Wirline phone to the Wireless phone prior to heading = for the office.=A0 All calls arriving at his home are forwarded by the Wire= line phone to his Wireless phone. By 2:00 PM, Mr. Doe is tierd of receiving= calls and sets call forward of his Wireless phone to the Wireline phone. N= ow the game=A0 starts: Wireline phone forwards calls to the Wireless phone = and the Wireless Phone forwards calls to the Wireline phone. It just takes = one or two of this scenario to exhaust a significant amount of processors (= e.g., SIP proxies) =A0in the network. Generally, it occurs between a Wireli= ne provider and a Wireless provider peering with each other. We call solve = this either by=A0 the proposed "SPID Sequence" header or by diversion-counter of the Diversion Indication heade= r (RFC 5806).=0A=A0=0ALoop due to least cost route analysis:=0ALet us assum= e that in a Utopian Internet, three SIP Multimeida networks exist: Alpha, B= ravo, and Charlie.=0AAll these three networks, no SBC or B2BUA exist !=0A= =A0=0AEach network has only one SIP Proxy and one SIP Redirect Server. The = SIP Redirect servers in these three networks=A0are intelligent. Before=A0a = SIP Redirect Server=A0decides a redirection, it performs a relational algeb= ra to find the best redirection of a particular INVITE (not all invites). A= lpha SIP Redirect Server =A0finds a redirection in Bravo's network; thus, A= lpha's Proxy redirects.the INVITE Bravo's network. The Bravo's redirect ser= ver also determines a redirection based on a intelligent logic; thus. Bravo= 's proxy redirects the INVITE to Charlie Network. The Charlie's network red= irects the INVITE to Alpha's Network. Note that while Alpha, Bravo, and Cha= irle network's redirection logic is either intelligent or consider it "inte= lligent", the aggregate effect in the three networks is infinite loop!=0A= =A0=0AAs=A0 I wrote in the other post, providers may not use the legible SP= ID or a=A0 legible know deterministic value; providers may use encrypted st= ochastic values so that no providers unders the identity of other providers= in the path.=0A=A0=0A=A0=0A=A0Date: Wed, 25 Jan 2012 22:17:31 -0500=0AFrom= : Paul Kyzivat =0ATo: dispatch@ietf.org=0ASubject: R= e: [dispatch] SPID Sequence and Loop Detection=0AMessage-ID: <4F20C5CB.7030= 203@alum.mit.edu>=0AContent-Type: text/plain; charset=3DISO-8859-1; format= =3Dflowed=0A=0AOn 1/25/12 5:25 PM, Sohel Khan wrote:=0A> Thanks Paul and Da= le.=0A> I think the provider interal rule may vary.=0A> Depending upon a pr= ovider internal rule, a provider may or may not take=0A> action based upon = the information in the SPID sequence. Even inside a=0A> provider, there can= be two different types of SIP agents. One may choose=0A> to take particula= r action based on the information on the SPID and the=0A> other session age= nt may not take any action based on the information on=0A> the SPID.=0A=0AB= ut in some cases it may decide there is an error based on the message =0Are= visiting a particular provider??? (After all, that is what your =0Aoriginal= message asserted.)=0A=0AThat policy could break some *valid* non-looping s= ituations that revisit =0Aa provider based on call forwarding or other acti= ons.=0A=0A> Please let me know if I still missing something.=0A> For the ca= ll forwarding loops, the operatioonal engineers prefer to use=0A> Diversion= counter to break loops.=0A=0AWhere do you get the diversion counter? From = the Diversion header? Or =0Afrom H-I?=0A=0AThis *might* work in a closed ga= rden if all messages are policed to =0Aadhere to some proprietary constrain= ts. But it won't work in general.=0A=0AAnd I don't think you can fall back = on SBCs to "make this right" for =0Ayou. They can't necessarily identify an= d tunnel sufficient information.=0A=0A=A0=A0=A0 Thanks,=0A=A0=A0=A0 Paul --1969517296-869412809-1327960027=:29111 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thank you Paul for the good input.=
Let us discuss the t= wo scenarios in details.
The scenarios:
1) Loop due to call forwarding
2) Route analysis
 
Loop due to call for= warding:
My analysis of&= nbsp;the empirical data shows that the m= ajority of the loops due to call forwarding occur due in a Fixed-Mobile con= vergence scenario. A user Jon Doe has two phones: Wirelines and Wireless wi= th two telephone numbers (TNine and TNess). Mr. Doe sets call forward of hi= s Wirline phone to the Wireless phone prior to heading for the office. = ; All calls arriving at his home are forwarded by the Wireline phone to his= Wireless phone. By 2:00 PM, Mr. Doe is tierd of receiving calls and sets c= all forward of his Wireless phone to the Wireline phone. Now the game  starts: Wireline phone forwards calls t= o the Wireless phone and the Wireless Phone forwards calls to the Wireline = phone. It just takes one or two of this scenario to exhaust a significant a= mount of processors (e.g., SIP proxies)  in the network. Generally, it occurs between a Wireline provider and a Wireless provider peering with ea= ch other. We call solve this either by  the proposed "SPID Sequence" h= eader or by diversion-counter of the Diversion Indication header (RFC 5806)= .
 
Loop due to least co= st route analysis:
Let us assume that i= n a Utopian Internet, three SIP Multimeida networks exist: Alpha, Bravo, an= d Charlie.
All these three netw= orks, no SBC or B2BUA exist !
 
Each network has onl= y one SIP Proxy and one SIP Redirect Server. The SIP Redirect servers in these three networks are intelligent.= Before a SIP Redirect Server decides a redirection, it performs = a relational algebra to find the best redirection of a particular INVITE (n= ot all invites). Alpha SIP Redirect Server  finds a redirection in Bra= vo's network; thus, Alpha's Proxy redirects.the INVITE Bravo's network. The= Bravo's redirect server also determines a redirection based on a intellige= nt logic; thus. Bravo's proxy redirects the INVITE to Charlie Network. The = Charlie's network redirects the INVITE to Alpha's Network. Note that while = Alpha, Bravo, and Chairle network's redirection logic is either intelligent= or consider it "intelligent", the aggregate effect in the three networks i= s infinite loop!
 
As  I wrote in = the other post, providers may not use the legible SPID or a  legible k= now deterministic value; providers may use encrypted stochastic values so t= hat no providers unders the identity of other providers in the path.
 
 
 Date: Wed, 25 Jan 2012 22:17:31 -0500
F= rom: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: dispatch= @ietf.org
Subject: Re: [dispatch] SPID Sequence and Loop DetectionMessage-ID: <4F20C5CB.7030203@alum.mit.edu= >
Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
=
On 1/25/12 5:25 PM, Sohel Khan wrote:
> Thanks Paul and Dale.
= > I think the provider interal rule may vary.
> Depending upon a p= rovider internal rule, a provider may or may not take
> action based = upon the information in the SPID sequence. Even inside a
> provider, = there can be two different types of SIP agents. One may choose
> to t= ake particular action based on the information on the SPID and the
> other session = agent may not take any action based on the information on
> the SPID.=

But in some cases it may decide there is an error based on the mess= age
revisiting a particular provider??? (After all, that is what your <= BR>original message asserted.)

That policy could break some *valid* = non-looping situations that revisit
a provider based on call forwarding= or other actions.

> Please let me know if I still missing someth= ing.
> For the call forwarding loops, the operatioonal engineers pref= er to use
> Diversion counter to break loops.

Where do you get= the diversion counter? From the Diversion header? Or
from H-I?

= This *might* work in a closed garden if all messages are policed to
adh= ere to some proprietary constraints. But it won't work in general.

A= nd I don't think you can fall back on SBCs to "make this right" for
you. They can't necessarily identify and tunnel sufficient information= .

    Thanks,
    Paul

--1969517296-869412809-1327960027=:29111-- From sohel_khan777@yahoo.com Mon Jan 30 14:15:30 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5E111E80AE for ; Mon, 30 Jan 2012 14:15:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.096 X-Spam-Level: X-Spam-Status: No, score=-0.096 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KASiP3SAqDhE for ; Mon, 30 Jan 2012 14:15:29 -0800 (PST) Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) by ietfa.amsl.com (Postfix) with SMTP id E46A121F85F9 for ; Mon, 30 Jan 2012 14:15:28 -0800 (PST) Received: from [98.139.212.145] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 30 Jan 2012 22:15:28 -0000 Received: from [98.139.212.201] by tm2.bullet.mail.bf1.yahoo.com with NNFMP; 30 Jan 2012 22:15:28 -0000 Received: from [127.0.0.1] by omp1010.mail.bf1.yahoo.com with NNFMP; 30 Jan 2012 22:15:28 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 476003.12665.bm@omp1010.mail.bf1.yahoo.com Received: (qmail 69501 invoked by uid 60001); 30 Jan 2012 22:15:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1327961727; bh=IZjxXeNBgT75qoQiYDD4tDk0UYMRKmB06x0/6sLzZzk=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=f1vLqNUfHNcyV35Z6S6ygJW2k3W6e7Cy0WCg9s6DWClN8WcKPo44TOdfNcDwfnt+3/M04cYb3Hzj7YuaftK8Qj+/GSr6jNLi+GZ4/iQqAxbfXNQlSjfRmMbOvvj8seaSCj+hOaxT8ppV/EOwMpoUot0I4mdwwQXMMf442BbClSQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=rBA1hFHnVXd6iRq08rTv4TAH/SUh+SR19M8ShogpL1KSaN8tiJ0osQ5SLEniQc/p0dPzG+UJP6Aqeu1OYDuKmjdq6CLVDjuGo8SC6n4LlCqJIkrZ+ZMmWiy+scwc4vT/4ket1Uuuj4glP3ouUigqKwo7kJ9PUtpgICFBGpPtTyE=; X-YMail-OSG: o_NBwb4VM1nav.ANx0.8E9lep30xQeLT43hhdp712rbJ3_P _vNJVTnuDe6OTTKKc_vwQnP2qG_zjsIyFFiKDSho14ssr6KFwUzgOWB2RMYb V2jARfQK.dJzMTGZJ0OVKDXWk1WhprSXiLV7n5HaBITV7ikKIUKEar9DHn2T Qifv_lLEfNff3ShsxQd8wkgL9r_jCRy6adhjNgdX9l68Guk6BUaz4zZOTEJE M3Xwkwk_AiYzGz1TxNVrWuNTFCfYf1YQTIy8P.34XC3uGcpHb24X5LDfahrU cIaYle73Z.KQgmI63UzbwZq8mWuX2p5cnRakFn1xm98zmQ2.FhnSYvKtSMix XAk1Q2TgfFzeKOlCxekYGnbZYWBdoIyPtIEy2Hb4MnM0C1RCeDFZcbY6UbSP ozdXaLiUesh6BjzQ_vevnczZA544b2fGnVyk7LM_0_0h142R9dZiiY9w6GZB sbowNx.aoHxX6RT.Ozqf85X4YDmqHPagb6llcpHnTxu6gb_pHYDWpAA-- Received: from [68.87.42.110] by web162002.mail.bf1.yahoo.com via HTTP; Mon, 30 Jan 2012 14:15:27 PST X-Mailer: YahooMailWebService/0.8.116.331537 References: Message-ID: <1327961727.69408.YahooMailNeo@web162002.mail.bf1.yahoo.com> Date: Mon, 30 Jan 2012 14:15:27 -0800 (PST) From: Sohel Khan To: "dispatch@ietf.org" , Paul Kyzivat In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="4756291-1280636108-1327961727=:69408" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sohel Khan List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 22:15:30 -0000 --4756291-1280636108-1327961727=:69408 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks Paul. No, I am not withdrawing the proposal.=0AI am modifying=A0the = proposal=A0to=A0mitigate concerns raised in this discussion list.=0AYou are= correct that=A0 I proposing=A0 a new mechanism by =0Awhich a provider can = tell that a message has returned to it after having =0Abeen routed to some = other provider. =0AAssume, there are three encrypted values in a sequence. = Only one proxy of a provider has to decrypt these three fixed sized encrypt= ed values. =0AOther than a looped case, the calls arriving back is most pro= bably for=A0call forwarding=A0case.=0AOperation Engineers like to use Diver= sion Indication header for call forwarding although the RFC is a historical= RFC.=0AIf an INVITE contains a Diversion header, then the provider should = not analyze the proposed provider sequence header.=0AMax-Forwards and Max-B= readths techniques also need to be implemented along with above methods sin= ce Max-Forwards and Max-Breadths have also limitations.=0A=A0=0A=A0=0ASohel= Khan --4756291-1280636108-1327961727=:69408 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Paul. No, I am not withdrawing the= proposal.
I am modifying = the proposal to mitigate concerns raised in this discussion list.=
You are correct that=   I proposing  a new mechanism by
which a provider can tell t= hat a message has returned to it after having
been routed to some other= provider.
Assume, there are th= ree encrypted values in a sequence. Only one proxy of a provider has to dec= rypt these three fixed sized encrypted values.
Other than a looped = case, the calls arriving back is most probably for call forwarding&nbs= p;case.
Operation Engineers = like to use Diversion Indication header for call forwarding although the RF= C is a historical RFC.
If an INVITE contain= s a Diversion header, then the provider should not analyze the proposed pro= vider sequence header.
Max-Forwards and Max= -Breadths techniques also need to be implemented along with above methods s= ince Max-Forwards and Max-Breadths have also limitations.
 
=  
Sohel Khan

 
--4756291-1280636108-1327961727=:69408-- From pkyzivat@alum.mit.edu Mon Jan 30 15:12:41 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12AF21F8567 for ; Mon, 30 Jan 2012 15:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QDU6830ItuwK for ; Mon, 30 Jan 2012 15:12:40 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5625821F8559 for ; Mon, 30 Jan 2012 15:12:40 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta13.westchester.pa.mail.comcast.net with comcast id TyVo1i0041swQuc5DzCgCu; Mon, 30 Jan 2012 23:12:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id TzCg1i00j07duvL3bzCgfV; Mon, 30 Jan 2012 23:12:40 +0000 Message-ID: <4F2723E7.90801@alum.mit.edu> Date: Mon, 30 Jan 2012 18:12:39 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Sohel Khan References: <1327961727.69408.YahooMailNeo@web162002.mail.bf1.yahoo.com> In-Reply-To: <1327961727.69408.YahooMailNeo@web162002.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 23:12:42 -0000 On 1/30/12 5:15 PM, Sohel Khan wrote: > Thanks Paul. No, I am not withdrawing the proposal. > I am modifying the proposal to mitigate concerns raised in this > discussion list. > You are correct that I proposing a new mechanism by > which a provider can tell that a message has returned to it after having > been routed to some other provider. > Assume, there are three encrypted values in a sequence. Only one proxy > of a provider has to decrypt these three fixed sized encrypted values. IIUC, you proposed that each provider would insert an encrypted identifier for itself. To achieve your goal of not identifying the provider to other providers, it needs to: - vary from call to call - not be superficially recognizable as being from you Thus, *somewhere* after the message enters your control you will need to decode all the ids based on your algorithm in order to determine which are yours. You will need to do that for every id in the message. (But I agree you can probably find a way to only do it once, regardless of how many of your nodes the message traverses before leaving. I also suspect it will be difficult to find a way to construct this encrypted id that will achieve your objectives. > Other than a looped case, the calls arriving back is most probably for > call forwarding case. > Operation Engineers like to use Diversion Indication header for call > forwarding although the RFC is a historical RFC. > If an INVITE contains a Diversion header, then the provider should not > analyze the proposed provider sequence header. You cannot assume that other providers use Diversion. With your approach, if a call passes through your provider, then to another where it is forwarded (without Diversion) back to you, then you will erroneously consider it a loop. > Max-Forwards and Max-Breadths techniques also need to be implemented > along with above methods since Max-Forwards and Max-Breadths have also > limitations. > Sohel Khan I fail to see how what you propose adds anything other than problems. Thanks, Paul From pkyzivat@alum.mit.edu Mon Jan 30 15:15:54 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D2411E80C7 for ; Mon, 30 Jan 2012 15:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=-0.303, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 953t1cYTbbx2 for ; Mon, 30 Jan 2012 15:15:54 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id AA9F011E80C6 for ; Mon, 30 Jan 2012 15:15:52 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta03.westchester.pa.mail.comcast.net with comcast id Twyy1i0021vXlb853zFtjq; Mon, 30 Jan 2012 23:15:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id TzFs1i02H07duvL3dzFsD7; Mon, 30 Jan 2012 23:15:53 +0000 Message-ID: <4F2724A7.8000409@alum.mit.edu> Date: Mon, 30 Jan 2012 18:15:51 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Sohel Khan References: <1327960027.29111.YahooMailNeo@web162001.mail.bf1.yahoo.com> In-Reply-To: <1327960027.29111.YahooMailNeo@web162001.mail.bf1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SPID Sequence and Loop Detection (Paul Kyzivat) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2012 23:15:54 -0000 On 1/30/12 4:47 PM, Sohel Khan wrote: > Thank you Paul for the good input. > Let us discuss the two scenarios in details. > The scenarios: > 1) Loop due to call forwarding > 2) Route analysis > Loop due to call forwarding: > My analysis of the empirical data shows that the majority of the loops > due to call forwarding occur due in a Fixed-Mobile convergence scenario. > A user Jon Doe has two phones: Wirelines and Wireless with two telephone > numbers (TNine and TNess). Mr. Doe sets call forward of his Wirline > phone to the Wireless phone prior to heading for the office. All calls > arriving at his home are forwarded by the Wireline phone to his Wireless > phone. By 2:00 PM, Mr. Doe is tierd of receiving calls and sets call > forward of his Wireless phone to the Wireline phone. Now the game > starts: Wireline phone forwards calls to the Wireless phone and the > Wireless Phone forwards calls to the Wireline phone. It just takes one > or two of this scenario to exhaust a significant amount of processors > (e.g., SIP proxies) in the network. Generally, it occurs between a > Wireline provider and a Wireless provider peering with each other. We > call solve this either by the proposed "SPID Sequence" header or by > diversion-counter of the Diversion Indication header (RFC 5806). You can solve this with max-forwards. You can't count on Diversion being used. And, as I noted in other reply, the spid sequence doesn't reliably work when you realize you can't count on Diversion. > Loop due to least cost route analysis: > Let us assume that in a Utopian Internet, three SIP Multimeida networks > exist: Alpha, Bravo, and Charlie. > All these three networks, no SBC or B2BUA exist ! > Each network has only one SIP Proxy and one SIP Redirect Server. The SIP > Redirect servers in these three networks are intelligent. Before a SIP > Redirect Server decides a redirection, it performs a relational algebra > to find the best redirection of a particular INVITE (not all invites). > Alpha SIP Redirect Server finds a redirection in Bravo's network; thus, > Alpha's Proxy redirects.the INVITE Bravo's network. The Bravo's redirect > server also determines a redirection based on a intelligent logic; thus. > Bravo's proxy redirects the INVITE to Charlie Network. The Charlie's > network redirects the INVITE to Alpha's Network. Note that while Alpha, > Bravo, and Chairle network's redirection logic is either intelligent or > consider it "intelligent", the aggregate effect in the three networks is > infinite loop! > As I wrote in the other post, providers may not use the legible SPID or > a legible know deterministic value; providers may use encrypted > stochastic values so that no providers unders the identity of other > providers in the path. Again, see my other reply. Thanks, Paul > Date: Wed, 25 Jan 2012 22:17:31 -0500 > From: Paul Kyzivat > > To: dispatch@ietf.org > Subject: Re: [dispatch] SPID Sequence and Loop Detection > Message-ID: <4F20C5CB.7030203@alum.mit.edu > > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 1/25/12 5:25 PM, Sohel Khan wrote: > > Thanks Paul and Dale. > > I think the provider interal rule may vary. > > Depending upon a provider internal rule, a provider may or may not take > > action based upon the information in the SPID sequence. Even inside a > > provider, there can be two different types of SIP agents. One may choose > > to take particular action based on the information on the SPID and the > > other session agent may not take any action based on the information on > > the SPID. > > But in some cases it may decide there is an error based on the message > revisiting a particular provider??? (After all, that is what your > original message asserted.) > > That policy could break some *valid* non-looping situations that revisit > a provider based on call forwarding or other actions. > > > Please let me know if I still missing something. > > For the call forwarding loops, the operatioonal engineers prefer to use > > Diversion counter to break loops. > > Where do you get the diversion counter? From the Diversion header? Or > from H-I? > > This *might* work in a closed garden if all messages are policed to > adhere to some proprietary constraints. But it won't work in general. > > And I don't think you can fall back on SBCs to "make this right" for > you. They can't necessarily identify and tunnel sufficient information. > > Thanks, > Paul > From keith.drage@alcatel-lucent.com Tue Jan 31 03:15:13 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6EE21F8733 for ; Tue, 31 Jan 2012 03:15:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.36 X-Spam-Level: X-Spam-Status: No, score=-109.36 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTZ8az8U7pUZ for ; Tue, 31 Jan 2012 03:15:12 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4E96521F862B for ; Tue, 31 Jan 2012 03:15:12 -0800 (PST) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q0VBEaXW017541 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 31 Jan 2012 12:15:09 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Tue, 31 Jan 2012 12:15:05 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Sohel Khan Date: Tue, 31 Jan 2012 12:15:03 +0100 Thread-Topic: [dispatch] SPID Sequence and Loop Detection Thread-Index: AczfpLT4PA4LUVIlQ8CmxTfHuc0/QgAZCXiQ Message-ID: References: <1327961727.69408.YahooMailNeo@web162002.mail.bf1.yahoo.com> <4F2723E7.90801@alum.mit.edu> In-Reply-To: <4F2723E7.90801@alum.mit.edu> 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.69 on 155.132.188.80 Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 11:15:13 -0000 If you are into anything more complicated that identifying the number of ho= ps so far routed over, then you need to count more than the number of diver= sions. Some multiple diversion scenarios can be perfectly legitimate, and i= ndeed transit multiple operators, particularly when some of those users may= be roaming or on enterprise networks beyond a public network. To do that analysis correctly you need more information akin to the History= -Info header field (or at least the tree structure within it). It seems we provide mechanisms, and then people refuse to use them because = they reveal information, and we have to invent another mechanism, .... etc. I would also note that I would oppose any chartered work investigating the = applicability of the Diversion header. Regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 30 January 2012 23:13 > To: Sohel Khan > Cc: dispatch@ietf.org > Subject: Re: [dispatch] SPID Sequence and Loop Detection >=20 > On 1/30/12 5:15 PM, Sohel Khan wrote: > > Thanks Paul. No, I am not withdrawing the proposal. > > I am modifying the proposal to mitigate concerns raised in this > > discussion list. > > You are correct that I proposing a new mechanism by > > which a provider can tell that a message has returned to it after havin= g > > been routed to some other provider. > > Assume, there are three encrypted values in a sequence. Only one proxy > > of a provider has to decrypt these three fixed sized encrypted values. >=20 > IIUC, you proposed that each provider would insert an encrypted > identifier for itself. To achieve your goal of not identifying the > provider to other providers, it needs to: > - vary from call to call > - not be superficially recognizable as being from you >=20 > Thus, *somewhere* after the message enters your control you will need to > decode all the ids based on your algorithm in order to determine which > are yours. You will need to do that for every id in the message. (But I > agree you can probably find a way to only do it once, regardless of how > many of your nodes the message traverses before leaving. >=20 > I also suspect it will be difficult to find a way to construct this > encrypted id that will achieve your objectives. >=20 > > Other than a looped case, the calls arriving back is most probably for > > call forwarding case. > > Operation Engineers like to use Diversion Indication header for call > > forwarding although the RFC is a historical RFC. > > If an INVITE contains a Diversion header, then the provider should not > > analyze the proposed provider sequence header. >=20 > You cannot assume that other providers use Diversion. > With your approach, if a call passes through your provider, then to > another where it is forwarded (without Diversion) back to you, then you > will erroneously consider it a loop. >=20 > > Max-Forwards and Max-Breadths techniques also need to be implemented > > along with above methods since Max-Forwards and Max-Breadths have also > > limitations. > > Sohel Khan >=20 > I fail to see how what you propose adds anything other than problems. >=20 > Thanks, > Paul >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Tue Jan 31 06:20:10 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39BF621F851D for ; Tue, 31 Jan 2012 06:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tT9Mnk0lmbO7 for ; Tue, 31 Jan 2012 06:20:09 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD9621F851C for ; Tue, 31 Jan 2012 06:20:09 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id UCEp1i0041c6gX853EL9q5; Tue, 31 Jan 2012 14:20:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id UEL91i00w07duvL3jEL9Gw; Tue, 31 Jan 2012 14:20:09 +0000 Message-ID: <4F27F898.4020104@alum.mit.edu> Date: Tue, 31 Jan 2012 09:20:08 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <1327961727.69408.YahooMailNeo@web162002.mail.bf1.yahoo.com> <4F2723E7.90801@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dispatch@ietf.org" , Sohel Khan Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 14:20:10 -0000 On 1/31/12 6:15 AM, DRAGE, Keith (Keith) wrote: > If you are into anything more complicated that identifying the number of hops so far routed over, then you need to count more than the number of diversions. Some multiple diversion scenarios can be perfectly legitimate, and indeed transit multiple operators, particularly when some of those users may be roaming or on enterprise networks beyond a public network. > > To do that analysis correctly you need more information akin to the History-Info header field (or at least the tree structure within it). > > It seems we provide mechanisms, and then people refuse to use them because they reveal information, and we have to invent another mechanism, .... etc. +1 > I would also note that I would oppose any chartered work investigating the applicability of the Diversion header. +1 Thanks, Paul > Regards > > Keith > >> -----Original Message----- >> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: 30 January 2012 23:13 >> To: Sohel Khan >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] SPID Sequence and Loop Detection >> >> On 1/30/12 5:15 PM, Sohel Khan wrote: >>> Thanks Paul. No, I am not withdrawing the proposal. >>> I am modifying the proposal to mitigate concerns raised in this >>> discussion list. >>> You are correct that I proposing a new mechanism by >>> which a provider can tell that a message has returned to it after having >>> been routed to some other provider. >>> Assume, there are three encrypted values in a sequence. Only one proxy >>> of a provider has to decrypt these three fixed sized encrypted values. >> >> IIUC, you proposed that each provider would insert an encrypted >> identifier for itself. To achieve your goal of not identifying the >> provider to other providers, it needs to: >> - vary from call to call >> - not be superficially recognizable as being from you >> >> Thus, *somewhere* after the message enters your control you will need to >> decode all the ids based on your algorithm in order to determine which >> are yours. You will need to do that for every id in the message. (But I >> agree you can probably find a way to only do it once, regardless of how >> many of your nodes the message traverses before leaving. >> >> I also suspect it will be difficult to find a way to construct this >> encrypted id that will achieve your objectives. >> >>> Other than a looped case, the calls arriving back is most probably for >>> call forwarding case. >>> Operation Engineers like to use Diversion Indication header for call >>> forwarding although the RFC is a historical RFC. >>> If an INVITE contains a Diversion header, then the provider should not >>> analyze the proposed provider sequence header. >> >> You cannot assume that other providers use Diversion. >> With your approach, if a call passes through your provider, then to >> another where it is forwarded (without Diversion) back to you, then you >> will erroneously consider it a loop. >> >>> Max-Forwards and Max-Breadths techniques also need to be implemented >>> along with above methods since Max-Forwards and Max-Breadths have also >>> limitations. >>> Sohel Khan >> >> I fail to see how what you propose adds anything other than problems. >> >> Thanks, >> Paul >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > From paulej@packetizer.com Tue Jan 31 06:21:37 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20D6721F851C for ; Tue, 31 Jan 2012 06:21:37 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jaZEYEmW6vF for ; Tue, 31 Jan 2012 06:21:36 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 8080021F851D for ; Tue, 31 Jan 2012 06:21:34 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q0VELTTW009393 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 31 Jan 2012 09:21:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1328019690; bh=l0zzJmW2KeS09JjkC2lmSC/VJrrzcOWyEPQmFCCjLos=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Njrh8fTQ3pq5V6PcsO75AC3Bf1tNTednkqOCzw3JrYQaKMCR7plB8KJ9Pxh3ddXzP HtkJfwDTJs1tGYn5/c+MgGp3x5eQjtPixDi9yZAXpNgG6LPRpgD+UmQSyXFg5nMrAO v43fuJYlYyTKWpgHD63L9CgpisZ1DdeOOFyvUriA= From: "Paul E. Jones" To: References: <20120130174255.22362.57121.idtracker@ietfa.amsl.com> In-Reply-To: <20120130174255.22362.57121.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2012 09:21:25 -0500 Message-ID: <025501cce023$9dac1740$d90445c0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQGUUJnDOu2jV9eBmX83PNsGtOIHuZaXpfeg Content-Language: en-us Subject: [dispatch] FW: I-D Action: draft-jones-ipmc-session-id-reqts-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 14:21:37 -0000 FYI > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Monday, January 30, 2012 12:43 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-jones-ipmc-session-id-reqts-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Requirements for an End-to-End Session > Identification in IP-Based Multimedia Communication Networks > Author(s) : Paul E. Jones > Gonzalo Salgueiro > James Polk > Parthasarathi Ravindran > Laura Liess > Roland Jesske > Salvatore Loreto > Hadriel Kaplan > Filename : draft-jones-ipmc-session-id-reqts-01.txt > Pages : 8 > Date : 2012-01-30 > > This document specifies the requirements for an end-to-end session > identifier in IP-based multimedia communication networks. This > identifier would enable endpoints, intermediate devices, and > management and monitoring systems to identify a session end-to-end, > associate multiple endpoints with a given multipoint conference, > track communication sessions when they are redirected, and associate > one or more media flows with a given communication session. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jones-ipmc-session-id-reqts- > 01.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-jones-ipmc-session-id-reqts- > 01.txt > > _______________________________________________ > 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 paulej@packetizer.com Tue Jan 31 06:21:41 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30B121F85A1 for ; Tue, 31 Jan 2012 06:21:41 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id it12MSRucL0F for ; Tue, 31 Jan 2012 06:21:41 -0800 (PST) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id 03B5021F8554 for ; Tue, 31 Jan 2012 06:21:40 -0800 (PST) Received: from sydney (rrcs-98-101-148-48.midsouth.biz.rr.com [98.101.148.48]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id q0VELdnB009403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 31 Jan 2012 09:21:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1328019700; bh=8gfPQhtRSieWhZK/jKtSZGQVQS5JaAGlycw81thMAvc=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=CjsxxxXuq0b42nFPSoy1zv7h1jnIqmZKw+aShEdnYzxdpsAjuTNXqYOHwomFfiQGY BXH/ADdQgns8BIPBegTBEOCDBPne4AycQMLjUz8YLVcKYN6JocMPtcMRiYme3uDrOA fT1a32Z2FVLB4p5WF4VfCdKyNrWgEq6kTLg4am10= From: "Paul E. Jones" To: References: <20120130174723.24154.42967.idtracker@ietfa.amsl.com> In-Reply-To: <20120130174723.24154.42967.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2012 09:21:35 -0500 Message-ID: <025701cce023$a3e73ea0$ebb5bbe0$@packetizer.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQIDa+1s2drowN80fCjgp31smH3qQJW5b2PQ Content-Language: en-us Subject: [dispatch] FW: I-D Action: draft-jones-ipmc-session-id-03.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 14:21:41 -0000 FYI > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce- > bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Monday, January 30, 2012 12:47 PM > To: i-d-announce@ietf.org > Subject: I-D Action: draft-jones-ipmc-session-id-03.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : End-to-End Session Identification in IP-Based > Multimedia Communication Networks > Author(s) : Paul E. Jones > Chris Pearce > James Polk > Gonzalo Salgueiro > Filename : draft-jones-ipmc-session-id-03.txt > Pages : 8 > Date : 2012-01-30 > > This document describes an end-to-end Session Identifier for use in > IP-based Multimedia Communication systems that enables endpoints, > intermediate devices, and management systems to identify a session > end-to-end, associate multiple endpoints with a given multipoint > conference, track communication sessions when they are redirected, > and associate one or more media flows with a given communication > session. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-jones-ipmc-session-id-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-jones-ipmc-session-id-03.txt > > _______________________________________________ > 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 sohel_khan777@yahoo.com Tue Jan 31 09:17:18 2012 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AD121F8476 for ; Tue, 31 Jan 2012 09:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=1.218, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lu-3KX1E6xEC for ; Tue, 31 Jan 2012 09:17:16 -0800 (PST) Received: from nm38-vm1.bullet.mail.bf1.yahoo.com (nm38-vm1.bullet.mail.bf1.yahoo.com [72.30.239.17]) by ietfa.amsl.com (Postfix) with SMTP id 27A4A21F844A for ; Tue, 31 Jan 2012 09:17:16 -0800 (PST) Received: from [98.139.212.147] by nm38.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jan 2012 17:17:10 -0000 Received: from [98.139.212.251] by tm4.bullet.mail.bf1.yahoo.com with NNFMP; 31 Jan 2012 17:17:10 -0000 Received: from [127.0.0.1] by omp1060.mail.bf1.yahoo.com with NNFMP; 31 Jan 2012 17:17:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 719859.13376.bm@omp1060.mail.bf1.yahoo.com Received: (qmail 96395 invoked by uid 60001); 31 Jan 2012 17:17:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1328030230; bh=tP5cTuLEXylU13v2KWprCrf1HV3NP6lgQdy6UVPj4Qo=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=oECtSnQf0vsOfs4iKQt1QNHUrD+XBG2QCig2XJ5vEFC/0Ww+CTkNQbKIoT1Wm1ZODpkHqru3I15zZNsbF69gUE38i83Zq4XZkEdJ3i9lsWEyqm+UrYpNDNEBE5QjAfMRy7Z0iSw7GFrN3QrOj+fLBmhQBygWRVxnhl7791NXaDc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=2C1d/xld/GfyTH8S5nxUfOeNpcIA1YZTGuvOZ1+dpIB5tuWXU/ZxxraMX84M3haM2XR4FF9k2ov3Cm6RAaUl4pDk+kwSxuDeDlVLx78w1/5CyVhRCNHqsi3vX6XA9HnEGhMRLhB41B8A4zdR2iiFRWkJ0F36U+mVBUE6apOdCe4=; X-YMail-OSG: ndsM9CgVM1ltAaSHQjRhcdgna9Y1gX4ZEIn.0YPwzyAGtXD UblvHZ.M0jomIzZA3Uh3IhCy7NE1brSY.U_bFRoM.F30B_1mY3DQNTESXEf0 f2_fP5ooRMrbLG2la5q9Xip9eQLGYZjG7FKURizZ.XWgAgzk32YRMayEvrTk LQzB7qFavEvp3cm6BhUMdAdvlYeQIRE7aumznm5PLel8Rw9oxvpunlI9XU84 Xz7LRZIR3iVgBe6hv6YUh1R_lJBpswWVbgeiNLuRiaRBhSPjUTyWm9bEMw78 F3ctEPjEkOU5quuIHS69cOFmkSiPEQORbsvFguaDyShTe.IdksbJRyK57e8x tjPKRzM4vsojQYhXoVcZUHDwOUyGW0ItS2deT_HL0K74Uv7IAohKSvxa2dSr PNBVY8GGqJMfPp1z023o_PlbbOaOoi.W_qspAEwiE_TDtgy9zTk8dhv_jUb4 2LKrAQo5pWHdsgTT7AwLuOOBnwXsuiZKZ_9h4L7cGXg_OrnJM46s- Received: from [68.87.42.110] by web162001.mail.bf1.yahoo.com via HTTP; Tue, 31 Jan 2012 09:17:10 PST X-Mailer: YahooMailWebService/0.8.116.331537 References: <1327961727.69408.YahooMailNeo@web162002.mail.bf1.yahoo.com> <4F2723E7.90801@alum.mit.edu> Message-ID: <1328030230.95017.YahooMailNeo@web162001.mail.bf1.yahoo.com> Date: Tue, 31 Jan 2012 09:17:10 -0800 (PST) From: Sohel Khan To: "DRAGE, Keith \(Keith\)" , Paul Kyzivat In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1969517296-246355704-1328030230=:95017" Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SPID Sequence and Loop Detection X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Sohel Khan List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 17:17:18 -0000 --1969517296-246355704-1328030230=:95017 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Thanks Keith and Paul.=0AFirst of all, I am not proposing to start a charte= r at this time. =0AMy intention is now to have a discussion to find a best = solution to detect that loop has occurred. In my opinion, the proposed SPID= Sequence or Domain Sequence is analogous to the AS-PATH of BGP. =C2=A0Some= of you raised concern on disclosing the identity of=C2=A0providers; thus, = I suggested=C2=A0that we include=C2=A0encrypted provider ID in the sequence= . I agree with Keith that we should try to use existing mechanism (e.g., Hi= story-info) instead of re-inventing something else. The History-Info can be= used for redirection related functions. The History-info also helps operat= ion to determine the sequence of all the proxies in the call path. =C2=A0We= observed that fqdn of proxies are generally included in the call paths. In= the peering context, it helps to analyze the entry/exit proxies of a provi= der=E2=80=99s network. Note that a large network may contain 100s of entry/= exit proxies. The proxy fqdn information in the History-Info not always is = fixed sized. =C2=A0The history information may not contain the name of the provider. Sometimes, name of the provider = added in the history-info by different proxies use different combinations; = thus, it is difficult for an automated system in an entry/exit proxy to ana= lyze and detect loop in real time.=C2=A0 On the other hand, the proposed SP= ID sequence/domain sequence information is planned to be fixed length; thus= , easier for the entry/exit points to discover loop. Let us continue to dis= cuss, we will=C2=A0appreciate your help to come up with a comprehensive sol= ution.=0A=C2=A0=0ARegards, Sohel Khan=0A=0A=0A_____________________________= ___=0AFrom: "DRAGE, Keith (Keith)" =0ATo: P= aul Kyzivat ; Sohel Khan = =0ACc: "dispatch@ietf.org" =0ASent: Tuesday, January 31= , 2012 6:15 AM=0ASubject: RE: [dispatch] SPID Sequence and Loop Detection= =0A=0AIf you are into anything more complicated that identifying the number= of hops so far routed over, then you need to count more than the number of= diversions. Some multiple diversion scenarios can be perfectly legitimate,= and indeed transit multiple operators, particularly when some of those use= rs may be roaming or on enterprise networks beyond a public network.=0A=0AT= o do that analysis correctly you need more information akin to the History-= Info header field (or at least the tree structure within it).=0A=0AIt seems= we provide mechanisms, and then people refuse to use them because they rev= eal information, and we have to invent another mechanism, .... etc.=0A=0AI = would also note that I would oppose any chartered work investigating the ap= plicability of the Diversion header.=0A=0ARegards=0A=0AKeith=0A=0A> -----Or= iginal Message-----=0A> From: dispatch-bounces@ietf.org [mailto:dispatch-bo= unces@ietf.org] On=0A> Behalf Of Paul Kyzivat=0A> Sent: 30 January 2012 23:= 13=0A> To: Sohel Khan=0A> Cc: dispatch@ietf.org=0A> Subject: Re: [dispatch]= SPID Sequence and Loop Detection=0A> =0A> On 1/30/12 5:15 PM, Sohel Khan w= rote:=0A> > Thanks Paul. No, I am not withdrawing the proposal.=0A> > I am = modifying the proposal to mitigate concerns raised in this=0A> > discussion= list.=0A> > You are correct that I proposing a new mechanism by=0A> > whic= h a provider can tell that a message has returned to it after having=0A> > = been routed to some other provider.=0A> > Assume, there are three encrypted= values in a sequence. Only one proxy=0A> > of a provider has to decrypt th= ese three fixed sized encrypted values.=0A> =0A> IIUC, you proposed that ea= ch provider would insert an encrypted=0A> identifier for itself. To achieve= your goal of not identifying the=0A> provider to other providers, it needs= to:=0A> - vary from call to call=0A> - not be superficially recognizable a= s being from you=0A> =0A> Thus, *somewhere* after the message enters your c= ontrol you will need to=0A> decode all the ids based on your algorithm in o= rder to determine which=0A> are yours. You will need to do that for every i= d in the message. (But I=0A> agree you can probably find a way to only do i= t once, regardless of how=0A> many of your nodes the message traverses befo= re leaving.=0A> =0A> I also suspect it will be difficult to find a way to c= onstruct this=0A> encrypted id that will achieve your objectives.=0A> =0A> = > Other than a looped case, the calls arriving back is most probably for=0A= > > call forwarding case.=0A> > Operation Engineers like to use Diversion I= ndication header for call=0A> > forwarding although the RFC is a historical= RFC.=0A> > If an INVITE contains a Diversion header, then the provider sho= uld not=0A> > analyze the proposed provider sequence header.=0A> =0A> You c= annot assume that other providers use Diversion.=0A> With your approach, if= a call passes through your provider, then to=0A> another where it is forwa= rded (without Diversion) back to you, then you=0A> will erroneously conside= r it a loop.=0A> =0A> > Max-Forwards and Max-Breadths techniques also need = to be implemented=0A> > along with above methods since Max-Forwards and Max= -Breadths have also=0A> > limitations.=0A> > Sohel Khan=0A> =0A> I fail to = see how what you propose adds anything other than problems.=0A> =0A> =C2=A0= =C2=A0=C2=A0 Thanks,=0A> =C2=A0=C2=A0=C2=A0 Paul=0A> =0A> _________________= ______________________________=0A> dispatch mailing list=0A> dispatch@ietf.= org=0A> https://www.ietf.org/mailman/listinfo/dispatch --1969517296-246355704-1328030230=:95017 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Thanks Keith and Pa= ul.
First of all, I am not proposing to start= a charter at this time.
My intention is now= to have a discussion to find a best solution to detect that loop has occur= red. In my opinion, the proposed SPID Sequence or Domain Sequence is= analogous to the AS-PATH of BGP. =  Some of you raised concern on disclosing the identity of = providers; thus, I suggested that we include encrypted provider I= D in the sequence. I agree with Keith that we should try to use existing me= chanism (e.g., History-info) instead of re-inventing something else. The Hi= story-Info can be used for redirection related functions. The History-info = also helps operation to determine the sequence of all the proxies in the ca= ll path.  We observed that fq= dn of proxies are generally included in the call paths. In the peering cont= ext, it helps to analyze the entry/exit proxies of a provider=E2=80=99s net= work. Note that a large network may contain 100s of entry/exit proxies. The prox= y fqdn information in the History-Info not always is fixed sized.  The history information may not conta= in the name of the provider. Sometimes, name of the provider added in the h= istory-info by different proxies use different combinations; thus, it is di= fficult for an automated system in an entry/exit proxy to analyze and detec= t loop in real time.  On the other hand, the proposed SPID sequence/do= main sequence information is planned to be fixed length; thus, easier for t= he entry/exit points to discover loop. L= et us continue to discuss, we will appreciate your help to come up wit= h a comprehensive solution.
 
Regards, Sohel Khan
From:= "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>To: Paul Kyzivat <pkyz= ivat@alum.mit.edu>; Sohel Khan <sohel_khan777@yahoo.com>
Cc: "dispatch@ietf.org" <disp= atch@ietf.org>
Sent:= Tuesday, January 31, 2012 6:15 AM
= Subject: RE: [dispatch] SPID Sequence and Loop Detection

If you are into anything more complicated that identifying the= number of hops so far routed over, then you need to count more than the number of di= versions. Some multiple diversion scenarios can be perfectly legitimate, an= d indeed transit multiple operators, particularly when some of those users = may be roaming or on enterprise networks beyond a public network.

To= do that analysis correctly you need more information akin to the History-I= nfo header field (or at least the tree structure within it).

It seem= s we provide mechanisms, and then people refuse to use them because they re= veal information, and we have to invent another mechanism, .... etc.
I would also note that I would oppose any chartered work investigating the= applicability of the Diversion header.

Regards

Keith

= > -----Original Message-----
> From: dispatch-bounc= es@ietf.org [mailto:dispatch-bounces@ietf.org= ] On
> Behalf Of Paul Kyzivat
> Sent: 30 January 2012 23:13
= > To: Sohel Khan
> Cc: dispatch@ietf.org
> Subject: Re: [= dispatch] SPID Sequence and Loop Detection
>
> On 1/30/12 5:15= PM, Sohel Khan wrote:
> > Thanks Paul. No, I am not withdrawing t= he proposal.
> > I am modifying the proposal to mitigate concerns = raised in this
> > discussion list.
> > You are correct t= hat I proposing a new mechanism by
> > which a provider can tell t= hat a message has returned to it after having
> > been routed to s= ome other provider.
> > Assume, there are three encrypted values i= n a sequence. Only one proxy
> > of a provider has to decrypt thes= e three fixed sized encrypted values.
>
> IIUC, you proposed that each provider would insert an encrypted
> identifier for itself= . To achieve your goal of not identifying the
> provider to other pro= viders, it needs to:
> - vary from call to call
> - not be supe= rficially recognizable as being from you
>
> Thus, *somewhere*= after the message enters your control you will need to
> decode all = the ids based on your algorithm in order to determine which
> are you= rs. You will need to do that for every id in the message. (But I
> ag= ree you can probably find a way to only do it once, regardless of how
&g= t; many of your nodes the message traverses before leaving.
>
>= ; I also suspect it will be difficult to find a way to construct this
&g= t; encrypted id that will achieve your objectives.
>
> > Ot= her than a looped case, the calls arriving back is most probably for
>= ; > call forwarding case.
> > Operation Engineers like to use Diversion Indication header for call
> > forwarding althou= gh the RFC is a historical RFC.
> > If an INVITE contains a Divers= ion header, then the provider should not
> > analyze the proposed = provider sequence header.
>
> You cannot assume that other pro= viders use Diversion.
> With your approach, if a call passes through = your provider, then to
> another where it is forwarded (without Diver= sion) back to you, then you
> will erroneously consider it a loop.>
> > Max-Forwards and Max-Breadths techniques also need to b= e implemented
> > along with above methods since Max-Forwards and = Max-Breadths have also
> > limitations.
> > Sohel Khan>
> I fail to see how what you propose adds anything other than = problems.
>
>     Thanks,
>   &= nbsp; Paul
>
> _______________________________________________
> dispatch mailing l= ist
> dispatch@ietf.org
> https://www.ietf.org/mailman/listi= nfo/dispatch


--1969517296-246355704-1328030230=:95017--