From adam@nostrum.com Mon Apr 2 08:40:43 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BC421F8653 for ; Mon, 2 Apr 2012 08:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 6R7VRwRuH+l5 for ; Mon, 2 Apr 2012 08:40:43 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0406521F864A for ; Mon, 2 Apr 2012 08:40:39 -0700 (PDT) Received: from dn3-110.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q32FebCC041707 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 2 Apr 2012 10:40:37 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4F79C874.2080207@nostrum.com> Date: Mon, 02 Apr 2012 10:40:36 -0500 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] 3rd WGLC: draft-ietf-sipcore-rfc4244bis-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:40:43 -0000 [as chair] SIPCORE working group: This message is notice of a third (and hopefully final) working group last call for the History-Info document (draft-ietf-sipcore-rfc4244bis-07): http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-07.txt This working group last call will conclude on Monday, April 16th. Interested parties should carefully review the associated draft and provide feedback on the SIPCORE list prior to that date. Thank you. /a From adam@nostrum.com Mon Apr 2 08:53:10 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E0A21F863F for ; Mon, 2 Apr 2012 08:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 40Kdw8ARyHb7 for ; Mon, 2 Apr 2012 08:53:09 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id C36E721F85E7 for ; Mon, 2 Apr 2012 08:53:09 -0700 (PDT) Received: from dn3-110.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q32FqwtP043725 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 2 Apr 2012 10:53:04 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4F79CB59.3040506@nostrum.com> Date: Mon, 02 Apr 2012 10:52:57 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: <4F72D93A.8040501@nostrum.com> <4F730519.6040802@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C429F5D81@ESESSCMS0356.eemea.ericsson.se> <4F730828.5040100@digium.com> <3EB12CE3-EBDE-49B0-8ECC-9A0A54CDBD2F@acmepacket.com> <4F737AEC.9050204@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "" Subject: Re: [sipcore] Confirming Consensus: WebSockets X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 15:53:10 -0000 [as a participant] Hadriel: I understand the practicalities you're trying to highlight, but I don't think it's reasonable to work around the not-formally-defined and constantly shifting behavior of arguably noncompliant intermediaries at this point. Maybe STRAW can take on an item to define out-of-dialog request routing behaviors, and discuss GRUU interaction; then we can talk in terms of intermediaries that implement those specific procedures. For the time being, I think we need to work with the standardized tools that have been defined -- tools that work just fine in an actual standards-compliant network -- and let those entities that break proper routing deal with the consequences through whatever proprietary band-aids amuse them. In this context, that would (IMHO) involve a discussion of the problems solved by GRUU, and a pointer to the document. I agree with Christer that -- like outbound -- we don't need to mandate GRUU; we simply need to describe what happens without it, and let implementors make their own evaluation about whether those properties warrant the additional implementation complexity. /a On 3/29/12 12:40 PM, Hadriel Kaplan wrote: > On Mar 28, 2012, at 10:56 PM, Paul Kyzivat wrote: > >> Please correct me if I'm wrong, but I *think* what you are trying to say is that out of dialog requests to the contact address from a dialog will mostly never work, unless somebody puts the phone-number-style URI in the contact address, or if the contact is one that was substituted by the last SBC. > I'm not quite sure what *you're* saying, so I can't tell if it's what I'm also trying to say. :) > > >> I would think, *if they wanted to*, SBCs could make whatever substitution is necessary to make a gruu that they receive in a contact address be usable on the other side. This would be in their traditional role of fixing all the interop problems of the networks they connect. > > Sort of. There are some folks in the IETF who don't want the SBCs to change them at all if they're GRUUs. And there are also other SDOs/groups that seem to think they will be getting GRUUs, that they MUST get GRUUs, and that it will somehow make things magically work. > > -hadriel > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Mon Apr 2 09:09:05 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A25821F8690 for ; Mon, 2 Apr 2012 09:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 1CWTgcxJhExd for ; Mon, 2 Apr 2012 09:09:05 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EB50B21F8680 for ; Mon, 2 Apr 2012 09:09:04 -0700 (PDT) Received: from dn3-110.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q32G8kQ0046496 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 2 Apr 2012 11:08:47 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4F79CF0E.3050706@nostrum.com> Date: Mon, 02 Apr 2012 11:08:46 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Hadriel Kaplan References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se> <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com> <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com> <4F706026.4090105@digium.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "" , "Kevin P. Fleming" Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 16:09:05 -0000 On 3/26/12 3:46 PM, Hadriel Kaplan wrote: > On Mar 26, 2012, at 2:25 PM, Kevin P. Fleming wrote: > >> For nearly *all* WebSocket use cases (that we've agreed to address with this draft), SIP endpoints will have this issue. Since the WebSocket transport is being documented *after* the creation of the solution (GRUU), it seems reasonable to me for the WebSocket transport document to refer to that solution as the preferred mechanism. It shouldn't be mandated, but preferring it seems practical and useful. > I would agree, if it weren't for that I wrote a draft of problems with using GRUUs. :) > > See here: > http://tools.ietf.org/html/draft-kaplan-dispatch-gruu-problematic-00 > > And before Paul says anything, the draft is NOT blaming GRUUs. It's not their fault the Internet is a nasty place. ;) > Well, be honest about the contents of the document, though. It boils down to: (a) here are some poorly-thought-out things that B2BUAs can do to ruin the beneficial properties of GRUUs, and (b) broken deployments are broken. It's more of a "worst common practices" document than an indictment of GRUUs. The solution to pretty much all the issues that draft highlights is: "don't do that, then." It's not the GRUUs that are broken -- it's the deployments and poorly-designed B2BUAs. /a From victor.pascual.avila@gmail.com Mon Apr 2 09:10:26 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F72921F86DE for ; Mon, 2 Apr 2012 09:10:26 -0700 (PDT) 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 NrIQwGatqP3X for ; Mon, 2 Apr 2012 09:10:25 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 33C5321F86DD for ; Mon, 2 Apr 2012 09:10:16 -0700 (PDT) Received: by iazz13 with SMTP id z13so5291408iaz.31 for ; Mon, 02 Apr 2012 09:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jafs9f4jmwgAeW2kOX3UW1prVTO1sRRxL71d8+Tm/pw=; b=a3ji2P76AGzG6yJPBYhIL8RHk61XPwEv+RwvF9Szag7MRQSOwtD7lnIWO87xyyacqp q7mzAxOkgeRSvyxxpKDAoCZuc/1+7pyQ8aruDyTiyQ1RVEld57WGiovs4TvrCD2XQP/i mEqK82SfWKjkDCfpReGf5LNHVyDfPIobZ/sIV78w4frHb9/dogbvJykJJqExa7PROzpt aUjj5VnCg/57J2G3+NeCaxDt+9JT3QYgkhuPC5GxAlF9iBukTIpi9icxZUQBPbPA+KRN FZyGzayRYqxknF1s85dhSw7UuWTERWOk9dBY4/24llpSOMMfRs0uf30wyg+Fk8iKk8vw RaMQ== MIME-Version: 1.0 Received: by 10.50.186.197 with SMTP id fm5mr6257457igc.23.1333383015914; Mon, 02 Apr 2012 09:10:15 -0700 (PDT) Received: by 10.231.196.72 with HTTP; Mon, 2 Apr 2012 09:10:15 -0700 (PDT) In-Reply-To: <4F79CB59.3040506@nostrum.com> References: <4F72D93A.8040501@nostrum.com> <4F730519.6040802@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C429F5D81@ESESSCMS0356.eemea.ericsson.se> <4F730828.5040100@digium.com> <3EB12CE3-EBDE-49B0-8ECC-9A0A54CDBD2F@acmepacket.com> <4F737AEC.9050204@alum.mit.edu> <4F79CB59.3040506@nostrum.com> Date: Mon, 2 Apr 2012 18:10:15 +0200 Message-ID: From: Victor Pascual Avila To: Adam Roach Content-Type: text/plain; charset=UTF-8 Cc: "" Subject: Re: [sipcore] Confirming Consensus: WebSockets X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 16:10:26 -0000 On Mon, Apr 2, 2012 at 5:52 PM, Adam Roach wrote: > I agree with Christer that -- like outbound -- we don't need to mandate > GRUU; we simply need to describe what happens without it, and let > implementors make their own evaluation about whether those properties > warrant the additional implementation complexity. Agreed -- this is what we're actually planning to do for the next revision of the document -Victor From ibc@aliax.net Mon Apr 2 09:37:31 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B09B21F86B7 for ; Mon, 2 Apr 2012 09:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqJWYRVqisOC for ; Mon, 2 Apr 2012 09:37:30 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 735EB21F86B2 for ; Mon, 2 Apr 2012 09:37:30 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2161338vbb.31 for ; Mon, 02 Apr 2012 09:37:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=k/PQIDEx26lVpdJCAlTZ4MpQ3vqoY2O2IvYK8SSWaLg=; b=H900b2f+561bGe6xArbjEi1zXqw3PNnj6mbYip+xDWPuDl0lRvNUKQyW5tf1cMtPGe 4+XBIwKNOuWcL7eumkIUAveVCY6H/aSKpO9Cac1hJTvq3YI480P2n8kcAxXeRWXtj//w dVyXwyiss8FMR5vSfos4TMWP/Isorz2uLXtT4D/lY6QWOVg/zHXktaFS6wmshUFd0ZXh xb2epTqhlrSIAlYF5FbJt+KF5a7Pfp7yie5feHL0vk8b0o4D7hqR8ilWPGD5IN5plHr5 KE1vlClHNcle08gqf7kTt9t8pDM3S/n3DI2nY1twP6O8nDDO+hO76r+9W1nkVUsj7fcY c1Mg== Received: by 10.220.140.196 with SMTP id j4mr4746441vcu.22.1333384649948; Mon, 02 Apr 2012 09:37:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Mon, 2 Apr 2012 09:37:09 -0700 (PDT) In-Reply-To: <4F79CF0E.3050706@nostrum.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se> <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com> <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com> <4F706026.4090105@digium.com> <4F79CF0E.3050706@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 2 Apr 2012 18:37:09 +0200 Message-ID: To: Adam Roach Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlxoKA0xsuau+oF333/qVwDfxOJaBbvpKct1cIloLf0apU+FEHjQ1SsoZmqFJPNkzlPVKUA Cc: "" , "Kevin P. Fleming" Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 16:37:31 -0000 2012/4/2 Adam Roach : > Well, be honest about the contents of the document, though. It boils down > to: (a) here are some poorly-thought-out things that B2BUAs can do to rui= n > the beneficial properties of GRUUs, and (b) broken deployments are broken= . > > It's more of a "worst common practices" document than an indictment of > GRUUs. The solution to pretty much all the issues that draft highlights i= s: > "don't do that, then." It's not the GRUUs that are broken -- it's the > deployments and poorly-designed B2BUAs. Completely agreed. I don't understand why we should discuss here about the fact that non standard devices (B2BUAs, SBCs) do not play well with real standard specifications (Outbound, GRUU). Neither we should consider here (when talking about standards) the fact that some SIP servers implement their proprietary "version" of Outbound and/or Connection Reuse. Outbound and GRUU do work in well designed standard networks. Regards. --=20 I=C3=B1aki Baz Castillo From dworley@avaya.com Mon Apr 2 09:55:45 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 991BD21F865D for ; Mon, 2 Apr 2012 09:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.237 X-Spam-Level: X-Spam-Status: No, score=-98.237 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MISSING_SUBJECT=1.762, 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 CZyRRMYFyYBe for ; Mon, 2 Apr 2012 09:55:45 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id E15DC21F863F for ; Mon, 2 Apr 2012 09:55:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgIAF7ZeU/GmAcF/2dsb2JhbAA8CaZaAZAvcYEHghASKBMsEhYpQhkGAgIEBAoEAwoahW+BeJ5bnBCLBw+FI2MEm3OKHYMDIoEe X-IronPort-AV: E=Sophos;i="4.75,358,1330923600"; d="scan'208";a="2498564" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 02 Apr 2012 12:55:44 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Apr 2012 12:54:30 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 2 Apr 2012 12:55:43 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Mon, 2 Apr 2012 12:53:25 -0400 Thread-Index: AQHNEPEeoY/AgBxd/UWeeYudwb9dKA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmoberg@axway.com" , "bruno.chatras@orange.com" Subject: [sipcore] (no subject) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 16:55:45 -0000 Bruno Chatras has pointed out that a number of examples in various SIP-rela= ted RFCs show Content-Length header fields in the headers of body-parts of mult= ipart entities. MIME does not define the meaining of such header fields, as the = MIME framing of body parts is done by the boundary markers. As Dale Moberg has pointed out, these header fields might not be truly inco= rrect but merely redundant or "to be ignored". But given that MIME multipart already frames the body-parts, Content-Length headers on body-parts are never necessary. So it seems to me that we should decide on a "best practices" for the use o= f Content-Length in the headers of a body part, to clarify the ambiguities in= the specifications, and to state whether it's preferable to include such a Cont= ent-Length or not. I've appended a list of all the examples carrying such Content-Length heade= rs that I could find by automated means. Dale ---------------------------------------------------------------------------= ----------------------------- RFC 2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services Suspicious line at rfc2848.txt:2195: Content-Length: 236 Suspicious line at rfc2848.txt:2209: Content-Length:50 Suspicious line at rfc2848.txt:2268: Content-Length: 316 Suspicious line at rfc2848.txt:2284: Content-Length: 172 Suspicious line at rfc2848.txt:2372: Content-Length: 325 Suspicious line at rfc2848.txt:2387: Content-Length: 352 Several of these body-part headers are not separated from the body-part contents by CR-LF-CR-LF. RFC 3261 SIP: Session Initiation Protocol Suspicious line at rfc3261.txt:11846: Content-Length: 231 RFC 3892 The Session Initiation Protocol (SIP) Referred-By Mechanism Suspicious line at rfc3892.txt:642: Content-Length: (appropriate valu= e) Suspicious line at rfc3892.txt:687: Content-Length: (appropriate valu= e) Suspicious line at rfc3892.txt:702: Content-Length: (appropriate valu= e) Suspicious line at rfc3892.txt:879: Content-Length: (appropriate valu= e) Suspicious line at rfc3892.txt:887: Content-Length: (appropriate valu= e) Suspicious line at rfc3892.txt:938: Content-Length: (appropriate valu= e) Suspicious line at rfc3892.txt:964: Content-Length: (appropriate valu= e) Suspicious line at rfc3892.txt:972: Content-Length: (appropriate valu= e) Suspicious line at rfc3892.txt:1056: Content-Length: (appropriate valu= e) Suspicious line at rfc3892.txt:1106: Content-Length: (appropriate valu= e) Suspicious line at rfc3892.txt:1168: Content-Length: (appropriate valu= e) Suspicious line at rfc3892.txt:1196: Content-Length: (appropriate valu= e) RFC 3893 Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format Suspicious line at rfc3893.txt:249: Content-Length: 147 (This has an extra CR-LF before the body-part headers.) Suspicious line at rfc3893.txt:263: Content-Length: 608 RFC 4463 A Media Resource Control Protocol (MRCP) Developed by Cisco, Nuance, and Speechworks Suspicious line at rfc4463.txt:1705: Content-Length:176 Suspicious line at rfc4463.txt:1714: Content-Length:104 Suspicious line at rfc4463.txt:2977: Content-Length:176 (Also missing the CR-LF after the body part headers.) Suspicious line at rfc4463.txt:2985: Content-Length:104 RFC 5547 A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer Suspicious line at rfc5547.txt:1645: Content-Length: [length of SDP] Suspicious line at rfc5547.txt:1670: Content-Length: [length of image] Suspicious line at rfc5547.txt:2093: Content-Length: [length of SDP] Suspicious line at rfc5547.txt:2118: Content-Length: [length of image] RFC 5589 Session Initiation Protocol (SIP) Call Control - Transfer Suspicious line at rfc5589.txt:2609: Content-Length: 2961 (An extra CR-LF in the middle of the body part headers.) Suspicious line at rfc5589.txt:2677: Content-Length: 156 (An extra CR-LF in the middle of the body part headers.) Suspicious line at rfc5589.txt:2696: Content-Length: 2961 RFC 6086 Session Initiation Protocol (SIP) INFO Method and Package Framework Suspicious line at rfc6086.txt:1594: Content-length: 59 Suspicious line at rfc6086.txt:1620: Content-length: 59 Suspicious line at rfc6086.txt:1637: Content-length: 59 Suspicious line at rfc6086.txt:1664: Content-length: 59 From brett@broadsoft.com Mon Apr 2 10:52:39 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD3DA21F86C9 for ; Mon, 2 Apr 2012 10:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nh0zFuOtTrDR for ; Mon, 2 Apr 2012 10:52:39 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.202]) by ietfa.amsl.com (Postfix) with ESMTP id F035721F85A5 for ; Mon, 2 Apr 2012 10:52:38 -0700 (PDT) Received: from CASUMHUB02.citservers.local (172.16.98.58) by FW02.citservers.local (172.16.98.4) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 2 Apr 2012 10:54:22 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Mon, 2 Apr 2012 10:54:21 -0700 From: Brett Tate To: SIPCORE , "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" Date: Mon, 2 Apr 2012 10:52:35 -0700 Thread-Topic: draft-ietf-sipcore-rfc4244bis-07: comments Thread-Index: Ac0Q+WLIfgXAOxAWTsOuR8PooKqmxQ== Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C1E1AF91A@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-07: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 17:52:39 -0000 Howdy, The following are some draft-ietf-sipcore-rfc4244bis-07 comments. Thanks, Brett ------ Section 16.1: "changed rom" should be "changed from". Appendix B: - If depicting an RFC 3261 compliant UAS, the 302/486/ACK examples must inc= lude To tags. - If depicting an RFC 3261 compliant UAS, the Via headers using an FQDN mus= t cause the UAS to add a received parameter to the Via. Section B.1: - In case not intentional, the 302's ACK is not depicted within the call fl= ow. - F3: Missing top Via entry of F2. - F4: The top unique via branch should be changed since it was already used= within F2. - F5: Missing top Via entry of F4. The Contact should be changed since it = reflects the proxy instead of UAS location. - F6: The top unique via branch should be changed since it was already used= within F2. - F7: Missing top Via entry of F6. The Contact should be changed since it = reflects the proxy instead of UAS location. Section B.2: - In case not intentional, the 302's ACK is not depicted within the call fl= ow. - F3: Missing top Via entry of F2. - F4: The top unique via branch should be changed since it was already used= within F2. - F5: Missing top Via entry of F4. The Contact should be changed since it = reflects the proxy instead of UAS location. - F6: The top unique via branch should be changed since it was already used= within F2. - F7: Missing top Via entry of F6. The Contact should be changed since it = reflects the proxy instead of UAS location. This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you ar= e not the intended recipient and have received this email in error, please = notify BroadSoft, Inc. immediately by replying to this message, or by sendi= ng an email to helpdesk@broadsoft.com, and destroy all copies of this messa= ge, along with any attachment, prior to reading, distributing or copying it= . From pkyzivat@alum.mit.edu Mon Apr 2 11:12:29 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E9A21F8638 for ; Mon, 2 Apr 2012 11:12:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJZqsn6DGVi1 for ; Mon, 2 Apr 2012 11:12:28 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id E7F4A21F8603 for ; Mon, 2 Apr 2012 11:12:27 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta06.westchester.pa.mail.comcast.net with comcast id t69w1i0081GhbT8566CU4K; Mon, 02 Apr 2012 18:12:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta07.westchester.pa.mail.comcast.net with comcast id t6CU1i00K07duvL3T6CUbw; Mon, 02 Apr 2012 18:12:28 +0000 Message-ID: <4F79EC0A.2060201@alum.mit.edu> Date: Mon, 02 Apr 2012 20:12:26 +0200 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] Content-Length in multipart body parts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 18:12:29 -0000 [reposting with a subject line] On 4/2/12 6:53 PM, Worley, Dale R (Dale) wrote: > Bruno Chatras has pointed out that a number of examples in various SIP-related > RFCs show Content-Length header fields in the headers of body-parts of multipart > entities. MIME does not define the meaining of such header fields, as the MIME > framing of body parts is done by the boundary markers. > > As Dale Moberg has pointed out, these header fields might not be truly incorrect > but merely redundant or "to be ignored". > > But given that MIME multipart already frames the body-parts, Content-Length > headers on body-parts are never necessary. > > So it seems to me that we should decide on a "best practices" for the use of > Content-Length in the headers of a body part, to clarify the ambiguities in the > specifications, and to state whether it's preferable to include such a Content-Length > or not. > > I've appended a list of all the examples carrying such Content-Length headers > that I could find by automated means. > > Dale > -------------------------------------------------------------------------------------------------------- > RFC 2848 > > The PINT Service Protocol: > Extensions to SIP and SDP for IP Access to Telephone Call Services > > Suspicious line at rfc2848.txt:2195: Content-Length: 236 > Suspicious line at rfc2848.txt:2209: Content-Length:50 > Suspicious line at rfc2848.txt:2268: Content-Length: 316 > Suspicious line at rfc2848.txt:2284: Content-Length: 172 > Suspicious line at rfc2848.txt:2372: Content-Length: 325 > Suspicious line at rfc2848.txt:2387: Content-Length: 352 > > Several of these body-part headers are not separated from the > body-part contents by CR-LF-CR-LF. > > RFC 3261 > > SIP: Session Initiation Protocol > > Suspicious line at rfc3261.txt:11846: Content-Length: 231 > > RFC 3892 > > The Session Initiation Protocol (SIP) Referred-By Mechanism > > Suspicious line at rfc3892.txt:642: Content-Length: (appropriate value) > Suspicious line at rfc3892.txt:687: Content-Length: (appropriate value) > Suspicious line at rfc3892.txt:702: Content-Length: (appropriate value) > Suspicious line at rfc3892.txt:879: Content-Length: (appropriate value) > Suspicious line at rfc3892.txt:887: Content-Length: (appropriate value) > Suspicious line at rfc3892.txt:938: Content-Length: (appropriate value) > Suspicious line at rfc3892.txt:964: Content-Length: (appropriate value) > Suspicious line at rfc3892.txt:972: Content-Length: (appropriate value) > Suspicious line at rfc3892.txt:1056: Content-Length: (appropriate value) > Suspicious line at rfc3892.txt:1106: Content-Length: (appropriate value) > Suspicious line at rfc3892.txt:1168: Content-Length: (appropriate value) > Suspicious line at rfc3892.txt:1196: Content-Length: (appropriate value) > > RFC 3893 > > Session Initiation Protocol (SIP) > Authenticated Identity Body (AIB) Format > > Suspicious line at rfc3893.txt:249: Content-Length: 147 > (This has an extra CR-LF before the body-part headers.) > Suspicious line at rfc3893.txt:263: Content-Length: 608 > > RFC 4463 > > A Media Resource Control Protocol (MRCP) > Developed by Cisco, Nuance, and Speechworks > > Suspicious line at rfc4463.txt:1705: Content-Length:176 > Suspicious line at rfc4463.txt:1714: Content-Length:104 > Suspicious line at rfc4463.txt:2977: Content-Length:176 > (Also missing the CR-LF after the body part headers.) > Suspicious line at rfc4463.txt:2985: Content-Length:104 > > RFC 5547 > > A Session Description Protocol (SDP) Offer/Answer Mechanism > to Enable File Transfer > > Suspicious line at rfc5547.txt:1645: Content-Length: [length of SDP] > Suspicious line at rfc5547.txt:1670: Content-Length: [length of image] > Suspicious line at rfc5547.txt:2093: Content-Length: [length of SDP] > Suspicious line at rfc5547.txt:2118: Content-Length: [length of image] > > RFC 5589 > > Session Initiation Protocol (SIP) Call Control - Transfer > > Suspicious line at rfc5589.txt:2609: Content-Length: 2961 > (An extra CR-LF in the middle of the body part headers.) > Suspicious line at rfc5589.txt:2677: Content-Length: 156 > (An extra CR-LF in the middle of the body part headers.) > Suspicious line at rfc5589.txt:2696: Content-Length: 2961 > > RFC 6086 > > Session Initiation Protocol (SIP) INFO Method and Package Framework > > Suspicious line at rfc6086.txt:1594: Content-length: 59 > Suspicious line at rfc6086.txt:1620: Content-length: 59 > Suspicious line at rfc6086.txt:1637: Content-length: 59 > Suspicious line at rfc6086.txt:1664: Content-length: 59 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From HKaplan@acmepacket.com Mon Apr 2 15:21:55 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AC121F86B6 for ; Mon, 2 Apr 2012 15:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6++-6rev9scG for ; Mon, 2 Apr 2012 15:21:54 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id EB21921F85A5 for ; Mon, 2 Apr 2012 15:21:41 -0700 (PDT) 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; Mon, 2 Apr 2012 18:21:40 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.219]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Mon, 2 Apr 2012 18:21:39 -0400 From: Hadriel Kaplan To: Paul Kyzivat , "Dale R (Dale) Worley" Thread-Topic: [sipcore] Content-Length in multipart body parts Thread-Index: AQHNER74z18qePMXDkOZc0sDO/XU0g== Date: Mon, 2 Apr 2012 22:21:38 +0000 Message-ID: <91DCD0FE-A00F-4A10-8230-63F367B4E3AF@acmepacket.com> References: <4F79EC0A.2060201@alum.mit.edu> In-Reply-To: <4F79EC0A.2060201@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "" Subject: Re: [sipcore] Content-Length in multipart body parts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 22:21:55 -0000 Ugh. Yeah, that's not good for examples to show. So what's the solution? Errata? -hadriel p.s. I like the "Suspicious Line" thing - all RFC lines are suspicious! ;) On Apr 2, 2012, at 2:12 PM, Paul Kyzivat wrote: > [reposting with a subject line] >=20 > On 4/2/12 6:53 PM, Worley, Dale R (Dale) wrote: >> Bruno Chatras has pointed out that a number of examples in various SIP-r= elated >> RFCs show Content-Length header fields in the headers of body-parts of m= ultipart >> entities. MIME does not define the meaining of such header fields, as t= he MIME >> framing of body parts is done by the boundary markers. >>=20 >> As Dale Moberg has pointed out, these header fields might not be truly i= ncorrect >> but merely redundant or "to be ignored". >>=20 >> But given that MIME multipart already frames the body-parts, Content-Len= gth >> headers on body-parts are never necessary. >>=20 >> So it seems to me that we should decide on a "best practices" for the us= e of >> Content-Length in the headers of a body part, to clarify the ambiguities= in the >> specifications, and to state whether it's preferable to include such a C= ontent-Length >> or not. >>=20 >> I've appended a list of all the examples carrying such Content-Length he= aders >> that I could find by automated means. >>=20 >> Dale >> ------------------------------------------------------------------------= -------------------------------- >> RFC 2848 >>=20 >> The PINT Service Protocol: >> Extensions to SIP and SDP for IP Access to Telephone Call Services >>=20 >> Suspicious line at rfc2848.txt:2195: Content-Length: 236 >> Suspicious line at rfc2848.txt:2209: Content-Length:50 >> Suspicious line at rfc2848.txt:2268: Content-Length: 316 >> Suspicious line at rfc2848.txt:2284: Content-Length: 172 >> Suspicious line at rfc2848.txt:2372: Content-Length: 325 >> Suspicious line at rfc2848.txt:2387: Content-Length: 352 >>=20 >> Several of these body-part headers are not separated from the >> body-part contents by CR-LF-CR-LF. >>=20 >> RFC 3261 >>=20 >> SIP: Session Initiation Protocol >>=20 >> Suspicious line at rfc3261.txt:11846: Content-Length: 231 >>=20 >> RFC 3892 >>=20 >> The Session Initiation Protocol (SIP) Referred-By Mechanism >>=20 >> Suspicious line at rfc3892.txt:642: Content-Length: (appropriate v= alue) >> Suspicious line at rfc3892.txt:687: Content-Length: (appropriate v= alue) >> Suspicious line at rfc3892.txt:702: Content-Length: (appropriate v= alue) >> Suspicious line at rfc3892.txt:879: Content-Length: (appropriate v= alue) >> Suspicious line at rfc3892.txt:887: Content-Length: (appropriate v= alue) >> Suspicious line at rfc3892.txt:938: Content-Length: (appropriate v= alue) >> Suspicious line at rfc3892.txt:964: Content-Length: (appropriate v= alue) >> Suspicious line at rfc3892.txt:972: Content-Length: (appropriate v= alue) >> Suspicious line at rfc3892.txt:1056: Content-Length: (appropriate v= alue) >> Suspicious line at rfc3892.txt:1106: Content-Length: (appropriate v= alue) >> Suspicious line at rfc3892.txt:1168: Content-Length: (appropriate v= alue) >> Suspicious line at rfc3892.txt:1196: Content-Length: (appropriate v= alue) >>=20 >> RFC 3893 >>=20 >> Session Initiation Protocol (SIP) >> Authenticated Identity Body (AIB) Format >>=20 >> Suspicious line at rfc3893.txt:249: Content-Length: 147 >> (This has an extra CR-LF before the body-part headers.) >> Suspicious line at rfc3893.txt:263: Content-Length: 608 >>=20 >> RFC 4463 >>=20 >> A Media Resource Control Protocol (MRCP) >> Developed by Cisco, Nuance, and Speechworks >>=20 >> Suspicious line at rfc4463.txt:1705: Content-Length:176 >> Suspicious line at rfc4463.txt:1714: Content-Length:104 >> Suspicious line at rfc4463.txt:2977: Content-Length:176 >> (Also missing the CR-LF after the body part headers.) >> Suspicious line at rfc4463.txt:2985: Content-Length:104 >>=20 >> RFC 5547 >>=20 >> A Session Description Protocol (SDP) Offer/Answer Mechanism >> to Enable File Transfer >>=20 >> Suspicious line at rfc5547.txt:1645: Content-Length: [length of SDP] >> Suspicious line at rfc5547.txt:1670: Content-Length: [length of image= ] >> Suspicious line at rfc5547.txt:2093: Content-Length: [length of SDP] >> Suspicious line at rfc5547.txt:2118: Content-Length: [length of image= ] >>=20 >> RFC 5589 >>=20 >> Session Initiation Protocol (SIP) Call Control - Transfer >>=20 >> Suspicious line at rfc5589.txt:2609: Content-Length: 2961 >> (An extra CR-LF in the middle of the body part headers.) >> Suspicious line at rfc5589.txt:2677: Content-Length: 156 >> (An extra CR-LF in the middle of the body part headers.) >> Suspicious line at rfc5589.txt:2696: Content-Length: 2961 >>=20 >> RFC 6086 >>=20 >> Session Initiation Protocol (SIP) INFO Method and Package Framework >>=20 >> Suspicious line at rfc6086.txt:1594: Content-length: 59 >> Suspicious line at rfc6086.txt:1620: Content-length: 59 >> Suspicious line at rfc6086.txt:1637: Content-length: 59 >> Suspicious line at rfc6086.txt:1664: Content-length: 59 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Mon Apr 2 15:37:15 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54BD921F874A for ; Mon, 2 Apr 2012 15:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wl-kUmdUoBAH for ; Mon, 2 Apr 2012 15:37:14 -0700 (PDT) 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 4C19221F86E3 for ; Mon, 2 Apr 2012 15:37:14 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta08.westchester.pa.mail.comcast.net with comcast id tAFc1i0041uE5Es58Ad96D; Mon, 02 Apr 2012 22:37:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id tAd91i00J07duvL3cAd9np; Mon, 02 Apr 2012 22:37:09 +0000 Message-ID: <4F7A2A13.5090002@alum.mit.edu> Date: Mon, 02 Apr 2012 18:37:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4F79EC0A.2060201@alum.mit.edu> <91DCD0FE-A00F-4A10-8230-63F367B4E3AF@acmepacket.com> In-Reply-To: <91DCD0FE-A00F-4A10-8230-63F367B4E3AF@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Dale R \(Dale\) Worley" , "" Subject: Re: [sipcore] Content-Length in multipart body parts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Apr 2012 22:37:15 -0000 On 4/2/12 6:21 PM, Hadriel Kaplan wrote: > > Ugh. Yeah, that's not good for examples to show. > So what's the solution? Errata? Yes, I think the errata process is the right one for this. Thanks, Paul > -hadriel > p.s. I like the "Suspicious Line" thing - all RFC lines are suspicious! ;) > > > On Apr 2, 2012, at 2:12 PM, Paul Kyzivat wrote: > >> [reposting with a subject line] >> >> On 4/2/12 6:53 PM, Worley, Dale R (Dale) wrote: >>> Bruno Chatras has pointed out that a number of examples in various SIP-related >>> RFCs show Content-Length header fields in the headers of body-parts of multipart >>> entities. MIME does not define the meaining of such header fields, as the MIME >>> framing of body parts is done by the boundary markers. >>> >>> As Dale Moberg has pointed out, these header fields might not be truly incorrect >>> but merely redundant or "to be ignored". >>> >>> But given that MIME multipart already frames the body-parts, Content-Length >>> headers on body-parts are never necessary. >>> >>> So it seems to me that we should decide on a "best practices" for the use of >>> Content-Length in the headers of a body part, to clarify the ambiguities in the >>> specifications, and to state whether it's preferable to include such a Content-Length >>> or not. >>> >>> I've appended a list of all the examples carrying such Content-Length headers >>> that I could find by automated means. >>> >>> Dale >>> -------------------------------------------------------------------------------------------------------- >>> RFC 2848 >>> >>> The PINT Service Protocol: >>> Extensions to SIP and SDP for IP Access to Telephone Call Services >>> >>> Suspicious line at rfc2848.txt:2195: Content-Length: 236 >>> Suspicious line at rfc2848.txt:2209: Content-Length:50 >>> Suspicious line at rfc2848.txt:2268: Content-Length: 316 >>> Suspicious line at rfc2848.txt:2284: Content-Length: 172 >>> Suspicious line at rfc2848.txt:2372: Content-Length: 325 >>> Suspicious line at rfc2848.txt:2387: Content-Length: 352 >>> >>> Several of these body-part headers are not separated from the >>> body-part contents by CR-LF-CR-LF. >>> >>> RFC 3261 >>> >>> SIP: Session Initiation Protocol >>> >>> Suspicious line at rfc3261.txt:11846: Content-Length: 231 >>> >>> RFC 3892 >>> >>> The Session Initiation Protocol (SIP) Referred-By Mechanism >>> >>> Suspicious line at rfc3892.txt:642: Content-Length: (appropriate value) >>> Suspicious line at rfc3892.txt:687: Content-Length: (appropriate value) >>> Suspicious line at rfc3892.txt:702: Content-Length: (appropriate value) >>> Suspicious line at rfc3892.txt:879: Content-Length: (appropriate value) >>> Suspicious line at rfc3892.txt:887: Content-Length: (appropriate value) >>> Suspicious line at rfc3892.txt:938: Content-Length: (appropriate value) >>> Suspicious line at rfc3892.txt:964: Content-Length: (appropriate value) >>> Suspicious line at rfc3892.txt:972: Content-Length: (appropriate value) >>> Suspicious line at rfc3892.txt:1056: Content-Length: (appropriate value) >>> Suspicious line at rfc3892.txt:1106: Content-Length: (appropriate value) >>> Suspicious line at rfc3892.txt:1168: Content-Length: (appropriate value) >>> Suspicious line at rfc3892.txt:1196: Content-Length: (appropriate value) >>> >>> RFC 3893 >>> >>> Session Initiation Protocol (SIP) >>> Authenticated Identity Body (AIB) Format >>> >>> Suspicious line at rfc3893.txt:249: Content-Length: 147 >>> (This has an extra CR-LF before the body-part headers.) >>> Suspicious line at rfc3893.txt:263: Content-Length: 608 >>> >>> RFC 4463 >>> >>> A Media Resource Control Protocol (MRCP) >>> Developed by Cisco, Nuance, and Speechworks >>> >>> Suspicious line at rfc4463.txt:1705: Content-Length:176 >>> Suspicious line at rfc4463.txt:1714: Content-Length:104 >>> Suspicious line at rfc4463.txt:2977: Content-Length:176 >>> (Also missing the CR-LF after the body part headers.) >>> Suspicious line at rfc4463.txt:2985: Content-Length:104 >>> >>> RFC 5547 >>> >>> A Session Description Protocol (SDP) Offer/Answer Mechanism >>> to Enable File Transfer >>> >>> Suspicious line at rfc5547.txt:1645: Content-Length: [length of SDP] >>> Suspicious line at rfc5547.txt:1670: Content-Length: [length of image] >>> Suspicious line at rfc5547.txt:2093: Content-Length: [length of SDP] >>> Suspicious line at rfc5547.txt:2118: Content-Length: [length of image] >>> >>> RFC 5589 >>> >>> Session Initiation Protocol (SIP) Call Control - Transfer >>> >>> Suspicious line at rfc5589.txt:2609: Content-Length: 2961 >>> (An extra CR-LF in the middle of the body part headers.) >>> Suspicious line at rfc5589.txt:2677: Content-Length: 156 >>> (An extra CR-LF in the middle of the body part headers.) >>> Suspicious line at rfc5589.txt:2696: Content-Length: 2961 >>> >>> RFC 6086 >>> >>> Session Initiation Protocol (SIP) INFO Method and Package Framework >>> >>> Suspicious line at rfc6086.txt:1594: Content-length: 59 >>> Suspicious line at rfc6086.txt:1620: Content-length: 59 >>> Suspicious line at rfc6086.txt:1637: Content-length: 59 >>> Suspicious line at rfc6086.txt:1664: Content-length: 59 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > From shida@ntt-at.com Mon Apr 2 17:39:49 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B7121F8682 for ; Mon, 2 Apr 2012 17:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 lfJP0qUPkwtt for ; Mon, 2 Apr 2012 17:39:49 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 4953E21F867B for ; Mon, 2 Apr 2012 17:39:48 -0700 (PDT) Received: from [83.61.0.117] (port=27512 helo=[10.0.0.50]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SErmh-0003fB-JV; Mon, 02 Apr 2012 19:39:43 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C1E1AF91A@EXMBXCLUS01.citservers.local> Date: Tue, 3 Apr 2012 02:39:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4D77F5DD-2A17-46C9-9461-2B1840A0081A@ntt-at.com> References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C1E1AF91A@EXMBXCLUS01.citservers.local> To: Brett Tate X-Mailer: Apple Mail (2.1257) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 117.red-83-61-0.staticip.rima-tde.net ([10.0.0.50]) [83.61.0.117]:27512 X-Source-Auth: shida@agnada.com X-Email-Count: 7 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" , SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-07: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 00:39:50 -0000 Brett; Many thanks for having a close look at the example messages. We will incorporate these changes. Many Thanks Shida On Apr 2, 2012, at 7:52 PM, Brett Tate wrote: > Howdy, >=20 > The following are some draft-ietf-sipcore-rfc4244bis-07 comments. >=20 > Thanks, > Brett >=20 > ------ >=20 > Section 16.1: "changed rom" should be "changed from". >=20 > Appendix B: >=20 > - If depicting an RFC 3261 compliant UAS, the 302/486/ACK examples = must include To tags. >=20 > - If depicting an RFC 3261 compliant UAS, the Via headers using an = FQDN must cause the UAS to add a received parameter to the Via. >=20 > Section B.1: >=20 > - In case not intentional, the 302's ACK is not depicted within the = call flow. >=20 > - F3: Missing top Via entry of F2. >=20 > - F4: The top unique via branch should be changed since it was already = used within F2. >=20 > - F5: Missing top Via entry of F4. The Contact should be changed = since it reflects the proxy instead of UAS location. >=20 > - F6: The top unique via branch should be changed since it was already = used within F2. >=20 > - F7: Missing top Via entry of F6. The Contact should be changed = since it reflects the proxy instead of UAS location. >=20 > Section B.2: >=20 > - In case not intentional, the 302's ACK is not depicted within the = call flow. >=20 > - F3: Missing top Via entry of F2. >=20 > - F4: The top unique via branch should be changed since it was already = used within F2. >=20 > - F5: Missing top Via entry of F4. The Contact should be changed = since it reflects the proxy instead of UAS location. >=20 > - F6: The top unique via branch should be changed since it was already = used within F2. >=20 > - F7: Missing top Via entry of F6. The Contact should be changed = since it reflects the proxy instead of UAS location. >=20 >=20 > This email is intended solely for the person or entity to which it is = addressed and may contain confidential and/or privileged information. = If you are not the intended recipient and have received this email in = error, please notify BroadSoft, Inc. immediately by replying to this = message, or by sending an email to helpdesk@broadsoft.com, and destroy = all copies of this message, along with any attachment, prior to reading, = distributing or copying it. From pkyzivat@alum.mit.edu Mon Apr 2 21:20:47 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5E821F8751 for ; Mon, 2 Apr 2012 21:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRYPm8ojxpvd for ; Mon, 2 Apr 2012 21:20:46 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7A45921F8750 for ; Mon, 2 Apr 2012 21:20:44 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta10.westchester.pa.mail.comcast.net with comcast id tGL11i0031ZXKqc5AGLlTd; Tue, 03 Apr 2012 04:20:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id tGLk1i00d07duvL3hGLkKc; Tue, 03 Apr 2012 04:20:45 +0000 Message-ID: <4F7A7A9B.9080300@alum.mit.edu> Date: Tue, 03 Apr 2012 00:20:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4F72D93A.8040501@nostrum.com> <4F730519.6040802@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C429F5D81@ESESSCMS0356.eemea.ericsson.se> <4F730828.5040100@digium.com> <3EB12CE3-EBDE-49B0-8ECC-9A0A54CDBD2F@acmepacket.com> <4F737AEC.9050204@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] Confirming Consensus: WebSockets X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 04:20:47 -0000 [as individual] On 3/29/12 1:40 PM, Hadriel Kaplan wrote: > > On Mar 28, 2012, at 10:56 PM, Paul Kyzivat wrote: > >> Please correct me if I'm wrong, but I *think* what you are trying to say is that out of dialog requests to the contact address from a dialog will mostly never work, unless somebody puts the phone-number-style URI in the contact address, or if the contact is one that was substituted by the last SBC. > > I'm not quite sure what *you're* saying, so I can't tell if it's what I'm also trying to say. :) OK, I'll try again, and at the same time back off from some assumptions I was making about what you were saying. The point of a UA using a Gruu (a gruu (globally routable ua uri) assigned by a registrar according to 5627) as its contact address in a dialog is so that it knows that it can be reached out-of-dialog by any UA that receives its contact address. When you disparage using Gruus in this way, without offering a reference to an alternative, I guess you are saying the UA should just use its own, non-gruu URI, and rely on "somebody else" to "make it better" in some unspecified, magic way. Is that right? How is the UA to know this will happen? How does it know that it will work in all the cases that matter to it? >> I would think, *if they wanted to*, SBCs could make whatever substitution is necessary to make a gruu that they receive in a contact address be usable on the other side. This would be in their traditional role of fixing all the interop problems of the networks they connect. > > Sort of. There are some folks in the IETF who don't want the SBCs to change them at all if they're GRUUs. Yes. I think that if they are constructed to be globally routable then they should not need to be changed in any 3261 conforming network. I guess I would not object if an SBC did something to a Gruu to make it work in an environment that was *not* conforming and where the Gruu would otherwise not work. I would also expect that network to *not* advertise itself as conforming to sip. > And there are also other SDOs/groups that seem to think they will be getting GRUUs, > that they MUST get GRUUs, and that it will somehow make things magically work. Well, 3261 says that UAs MUST use a contact URI with global scope. 5627 was created because many UAs were not following this because they had no access to such a URI. The 3261 requirement is not to use a Gruu assigned by a registrar according to 5627. The UA can get one any way it wants. The registrar mechanism is just one way to achieve that. But its pretty sad if an SBC goes out of its way to break a UA that is trying hard to do what it is required to do. Now this doesn't mean I'm blaming *you*, or *Acme*, or any SBC vendor, for doing this. As you repeatedly stress, and I understand, you are just doing what your customers ask you to do. So its *them* that I blame for this. If they are going to require non-conforming behavior, or "fix" conforming behavior to be non-conforming, they they should make it clear to *their* customers that they are operating a closed environment that is not sip-conforming. Thanks, Paul From christer.holmberg@ericsson.com Mon Apr 2 23:39:44 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2584221F86CF for ; Mon, 2 Apr 2012 23:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 wTDR3l0-SgDr for ; Mon, 2 Apr 2012 23:39:43 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1EE21F86C5 for ; Mon, 2 Apr 2012 23:39:42 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-a9-4f7a9b2c9fb5 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3B.2B.25560.C2B9A7F4; Tue, 3 Apr 2012 08:39:41 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 3 Apr 2012 08:39:40 +0200 From: Christer Holmberg To: Paul Kyzivat , Hadriel Kaplan Date: Tue, 3 Apr 2012 08:39:38 +0200 Thread-Topic: [sipcore] Content-Length in multipart body parts Thread-Index: Ac0RISltI66FLSKZSCC/pFN2WEBEfgAQusag Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C42C04CA3@ESESSCMS0356.eemea.ericsson.se> References: <4F79EC0A.2060201@alum.mit.edu> <91DCD0FE-A00F-4A10-8230-63F367B4E3AF@acmepacket.com> <4F7A2A13.5090002@alum.mit.edu> In-Reply-To: <4F7A2A13.5090002@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-Brightmail-Tracker: AAAAAA== Cc: "Dale R \(Dale\) Worley" , "" Subject: Re: [sipcore] Content-Length in multipart body parts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 06:39:44 -0000 Hi, >> Ugh. Yeah, that's not good for examples to show. >> So what's the solution? Errata? > > Yes, I think the errata process is the right one for this. Agree, eventhough the C-L should cause no conflicts (as long as the value i= s correct). And, even if a specific MIME contains another (nested) multipart entry, C-L= should not be needed, as the MIME borders are still present. Regards, Christer > -hadriel > p.s. I like the "Suspicious Line" thing - all RFC lines are=20 > suspicious! ;) > > > On Apr 2, 2012, at 2:12 PM, Paul Kyzivat wrote: > >> [reposting with a subject line] >> >> On 4/2/12 6:53 PM, Worley, Dale R (Dale) wrote: >>> Bruno Chatras has pointed out that a number of examples in various=20 >>> SIP-related RFCs show Content-Length header fields in the headers of=20 >>> body-parts of multipart entities. MIME does not define the meaining=20 >>> of such header fields, as the MIME framing of body parts is done by the= boundary markers. >>> >>> As Dale Moberg has pointed out, these header fields might not be=20 >>> truly incorrect but merely redundant or "to be ignored". >>> >>> But given that MIME multipart already frames the body-parts,=20 >>> Content-Length headers on body-parts are never necessary. >>> >>> So it seems to me that we should decide on a "best practices" for=20 >>> the use of Content-Length in the headers of a body part, to clarify=20 >>> the ambiguities in the specifications, and to state whether it's=20 >>> preferable to include such a Content-Length or not. >>> >>> I've appended a list of all the examples carrying such=20 >>> Content-Length headers that I could find by automated means. >>> >>> Dale >>> -------------------------------------------------------------------- >>> ------------------------------------ >>> RFC 2848 >>> >>> The PINT Service Protocol: >>> Extensions to SIP and SDP for IP Access to Telephone Call=20 >>> Services >>> >>> Suspicious line at rfc2848.txt:2195: Content-Length: 236 >>> Suspicious line at rfc2848.txt:2209: Content-Length:50 >>> Suspicious line at rfc2848.txt:2268: Content-Length: 316 >>> Suspicious line at rfc2848.txt:2284: Content-Length: 172 >>> Suspicious line at rfc2848.txt:2372: Content-Length: 325 >>> Suspicious line at rfc2848.txt:2387: Content-Length: 352 >>> >>> Several of these body-part headers are not separated from the=20 >>> body-part contents by CR-LF-CR-LF. >>> >>> RFC 3261 >>> >>> SIP: Session Initiation Protocol >>> >>> Suspicious line at rfc3261.txt:11846: Content-Length: 231 >>> >>> RFC 3892 >>> >>> The Session Initiation Protocol (SIP) Referred-By Mechanism >>> >>> Suspicious line at rfc3892.txt:642: Content-Length: (appropriate = value) >>> Suspicious line at rfc3892.txt:687: Content-Length: (appropriate = value) >>> Suspicious line at rfc3892.txt:702: Content-Length: (appropriate = value) >>> Suspicious line at rfc3892.txt:879: Content-Length: (appropriate = value) >>> Suspicious line at rfc3892.txt:887: Content-Length: (appropriate = value) >>> Suspicious line at rfc3892.txt:938: Content-Length: (appropriate = value) >>> Suspicious line at rfc3892.txt:964: Content-Length: (appropriate = value) >>> Suspicious line at rfc3892.txt:972: Content-Length: (appropriate = value) >>> Suspicious line at rfc3892.txt:1056: Content-Length: (appropriate = value) >>> Suspicious line at rfc3892.txt:1106: Content-Length: (appropriate = value) >>> Suspicious line at rfc3892.txt:1168: Content-Length: (appropriate = value) >>> Suspicious line at rfc3892.txt:1196: Content-Length: (appropriate = value) >>> >>> RFC 3893 >>> >>> Session Initiation Protocol (SIP) >>> Authenticated Identity Body (AIB) Format >>> >>> Suspicious line at rfc3893.txt:249: Content-Length: 147 >>> (This has an extra CR-LF before the body-part headers.) >>> Suspicious line at rfc3893.txt:263: Content-Length: 608 >>> >>> RFC 4463 >>> >>> A Media Resource Control Protocol (MRCP) >>> Developed by Cisco, Nuance, and Speechworks >>> >>> Suspicious line at rfc4463.txt:1705: Content-Length:176 >>> Suspicious line at rfc4463.txt:1714: Content-Length:104 >>> Suspicious line at rfc4463.txt:2977: Content-Length:176 >>> (Also missing the CR-LF after the body part headers.) >>> Suspicious line at rfc4463.txt:2985: Content-Length:104 >>> >>> RFC 5547 >>> >>> A Session Description Protocol (SDP) Offer/Answer Mechanism >>> to Enable File Transfer >>> >>> Suspicious line at rfc5547.txt:1645: Content-Length: [length of SDP] >>> Suspicious line at rfc5547.txt:1670: Content-Length: [length of imag= e] >>> Suspicious line at rfc5547.txt:2093: Content-Length: [length of SDP] >>> Suspicious line at rfc5547.txt:2118: Content-Length: [length of imag= e] >>> >>> RFC 5589 >>> >>> Session Initiation Protocol (SIP) Call Control - Transfer >>> >>> Suspicious line at rfc5589.txt:2609: Content-Length: 2961 >>> (An extra CR-LF in the middle of the body part headers.) >>> Suspicious line at rfc5589.txt:2677: Content-Length: 156 >>> (An extra CR-LF in the middle of the body part headers.) >>> Suspicious line at rfc5589.txt:2696: Content-Length: 2961 >>> >>> RFC 6086 >>> >>> Session Initiation Protocol (SIP) INFO Method and Package=20 >>> Framework >>> >>> Suspicious line at rfc6086.txt:1594: Content-length: 59 >>> Suspicious line at rfc6086.txt:1620: Content-length: 59 >>> Suspicious line at rfc6086.txt:1637: Content-length: 59 >>> Suspicious line at rfc6086.txt:1664: Content-length: 59 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From bruno.chatras@orange.com Tue Apr 3 02:09:14 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF3A21F8535 for ; Tue, 3 Apr 2012 02:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 DIxlSOinzXlI for ; Tue, 3 Apr 2012 02:09:13 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 911CE21F848A for ; Tue, 3 Apr 2012 02:09:12 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8E46E4110D9; Tue, 3 Apr 2012 11:09:11 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 839264110D8; Tue, 3 Apr 2012 11:09:11 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Apr 2012 11:09:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Apr 2012 11:09:10 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214103F38BB3@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C42C04CA3@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Content-Length in multipart body parts Thread-Index: Ac0RISltI66FLSKZSCC/pFN2WEBEfgAQusagAAVCjZA= References: <4F79EC0A.2060201@alum.mit.edu><91DCD0FE-A00F-4A10-8230-63F367B4E3AF@acmepacket.com><4F7A2A13.5090002@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C42C04CA3@ESESSCMS0356.eemea.ericsson.se> From: To: , , X-OriginalArrivalTime: 03 Apr 2012 09:09:11.0412 (UTC) FILETIME=[6EF8B340:01CD1179] Cc: dworley@avaya.com, sipcore@ietf.org Subject: Re: [sipcore] Content-Length in multipart body parts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 09:09:14 -0000 I assume you mean a set of errata to fix the "Suspicious" examples. If = Yes, I do agree as well. > -----Message d'origine----- > De=A0: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De = la > part de Christer Holmberg > Envoy=E9=A0: mardi 3 avril 2012 08:40 > =C0=A0: Paul Kyzivat; Hadriel Kaplan > Cc=A0: Dale R (Dale) Worley; > Objet=A0: Re: [sipcore] Content-Length in multipart body parts >=20 > Hi, >=20 > >> Ugh. Yeah, that's not good for examples to show. > >> So what's the solution? Errata? > > > > Yes, I think the errata process is the right one for this. >=20 > Agree, eventhough the C-L should cause no conflicts (as long as the > value is correct). >=20 > And, even if a specific MIME contains another (nested) multipart = entry, > C-L should not be needed, as the MIME borders are still present. >=20 > Regards, >=20 > Christer >=20 >=20 > > -hadriel > > p.s. I like the "Suspicious Line" thing - all RFC lines are > > suspicious! ;) > > > > > > On Apr 2, 2012, at 2:12 PM, Paul Kyzivat wrote: > > > >> [reposting with a subject line] > >> > >> On 4/2/12 6:53 PM, Worley, Dale R (Dale) wrote: > >>> Bruno Chatras has pointed out that a number of examples in various > >>> SIP-related RFCs show Content-Length header fields in the headers > of > >>> body-parts of multipart entities. MIME does not define the > meaining > >>> of such header fields, as the MIME framing of body parts is done = by > the boundary markers. > >>> > >>> As Dale Moberg has pointed out, these header fields might not be > >>> truly incorrect but merely redundant or "to be ignored". > >>> > >>> But given that MIME multipart already frames the body-parts, > >>> Content-Length headers on body-parts are never necessary. > >>> > >>> So it seems to me that we should decide on a "best practices" for > >>> the use of Content-Length in the headers of a body part, to = clarify > >>> the ambiguities in the specifications, and to state whether it's > >>> preferable to include such a Content-Length or not. > >>> > >>> I've appended a list of all the examples carrying such > >>> Content-Length headers that I could find by automated means. > >>> > >>> Dale > >>> = ------------------------------------------------------------------- > - > >>> ------------------------------------ > >>> RFC 2848 > >>> > >>> The PINT Service Protocol: > >>> Extensions to SIP and SDP for IP Access to Telephone Call > >>> Services > >>> > >>> Suspicious line at rfc2848.txt:2195: Content-Length: 236 > >>> Suspicious line at rfc2848.txt:2209: Content-Length:50 > >>> Suspicious line at rfc2848.txt:2268: Content-Length: 316 > >>> Suspicious line at rfc2848.txt:2284: Content-Length: 172 > >>> Suspicious line at rfc2848.txt:2372: Content-Length: 325 > >>> Suspicious line at rfc2848.txt:2387: Content-Length: 352 > >>> > >>> Several of these body-part headers are not separated from the > >>> body-part contents by CR-LF-CR-LF. > >>> > >>> RFC 3261 > >>> > >>> SIP: Session Initiation Protocol > >>> > >>> Suspicious line at rfc3261.txt:11846: Content-Length: 231 > >>> > >>> RFC 3892 > >>> > >>> The Session Initiation Protocol (SIP) Referred-By Mechanism > >>> > >>> Suspicious line at rfc3892.txt:642: Content-Length: > (appropriate value) > >>> Suspicious line at rfc3892.txt:687: Content-Length: > (appropriate value) > >>> Suspicious line at rfc3892.txt:702: Content-Length: > (appropriate value) > >>> Suspicious line at rfc3892.txt:879: Content-Length: > (appropriate value) > >>> Suspicious line at rfc3892.txt:887: Content-Length: > (appropriate value) > >>> Suspicious line at rfc3892.txt:938: Content-Length: > (appropriate value) > >>> Suspicious line at rfc3892.txt:964: Content-Length: > (appropriate value) > >>> Suspicious line at rfc3892.txt:972: Content-Length: > (appropriate value) > >>> Suspicious line at rfc3892.txt:1056: Content-Length: > (appropriate value) > >>> Suspicious line at rfc3892.txt:1106: Content-Length: > (appropriate value) > >>> Suspicious line at rfc3892.txt:1168: Content-Length: > (appropriate value) > >>> Suspicious line at rfc3892.txt:1196: Content-Length: > (appropriate value) > >>> > >>> RFC 3893 > >>> > >>> Session Initiation Protocol (SIP) > >>> Authenticated Identity Body (AIB) Format > >>> > >>> Suspicious line at rfc3893.txt:249: Content-Length: 147 > >>> (This has an extra CR-LF before the body-part headers.) > >>> Suspicious line at rfc3893.txt:263: Content-Length: 608 > >>> > >>> RFC 4463 > >>> > >>> A Media Resource Control Protocol (MRCP) > >>> Developed by Cisco, Nuance, and Speechworks > >>> > >>> Suspicious line at rfc4463.txt:1705: Content-Length:176 > >>> Suspicious line at rfc4463.txt:1714: Content-Length:104 > >>> Suspicious line at rfc4463.txt:2977: Content-Length:176 > >>> (Also missing the CR-LF after the body part headers.) > >>> Suspicious line at rfc4463.txt:2985: Content-Length:104 > >>> > >>> RFC 5547 > >>> > >>> A Session Description Protocol (SDP) Offer/Answer Mechanism > >>> to Enable File Transfer > >>> > >>> Suspicious line at rfc5547.txt:1645: Content-Length: [length of > SDP] > >>> Suspicious line at rfc5547.txt:1670: Content-Length: [length of > image] > >>> Suspicious line at rfc5547.txt:2093: Content-Length: [length of > SDP] > >>> Suspicious line at rfc5547.txt:2118: Content-Length: [length of > image] > >>> > >>> RFC 5589 > >>> > >>> Session Initiation Protocol (SIP) Call Control - Transfer > >>> > >>> Suspicious line at rfc5589.txt:2609: Content-Length: 2961 > >>> (An extra CR-LF in the middle of the body part headers.) > >>> Suspicious line at rfc5589.txt:2677: Content-Length: 156 > >>> (An extra CR-LF in the middle of the body part headers.) > >>> Suspicious line at rfc5589.txt:2696: Content-Length: 2961 > >>> > >>> RFC 6086 > >>> > >>> Session Initiation Protocol (SIP) INFO Method and Package > >>> Framework > >>> > >>> Suspicious line at rfc6086.txt:1594: Content-length: 59 > >>> Suspicious line at rfc6086.txt:1620: Content-length: 59 > >>> Suspicious line at rfc6086.txt:1637: Content-length: 59 > >>> Suspicious line at rfc6086.txt:1664: Content-length: 59 > >>> _______________________________________________ > >>> sipcore mailing list > >>> sipcore@ietf.org > >>> https://www.ietf.org/mailman/listinfo/sipcore > >>> > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > > > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Tue Apr 3 06:52:48 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3E911E8085 for ; Tue, 3 Apr 2012 06:52:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VooWbPhWpZ-5 for ; Tue, 3 Apr 2012 06:52:47 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 2C82B21F8582 for ; Tue, 3 Apr 2012 06:52:47 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta12.westchester.pa.mail.comcast.net with comcast id tPA41i0031ei1Bg5CRsnEa; Tue, 03 Apr 2012 13:52:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta24.westchester.pa.mail.comcast.net with comcast id tRsn1i00G07duvL3kRsnDJ; Tue, 03 Apr 2012 13:52:47 +0000 Message-ID: <4F7B00AD.3020301@alum.mit.edu> Date: Tue, 03 Apr 2012 09:52:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: bruno.chatras@orange.com References: <4F79EC0A.2060201@alum.mit.edu><91DCD0FE-A00F-4A10-8230-63F367B4E3AF@acmepacket.com><4F7A2A13.5090002@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C42C04CA3@ESESSCMS0356.eemea.ericsson.se> <9ECCF01B52E7AB408A7EB8535264214103F38BB3@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214103F38BB3@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dworley@avaya.com, sipcore@ietf.org Subject: Re: [sipcore] Content-Length in multipart body parts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 13:52:48 -0000 On 4/3/12 5:09 AM, bruno.chatras@orange.com wrote: > I assume you mean a set of errata to fix the "Suspicious" examples. If Yes, I do agree as well. Yes, that is what I meant. Thanks, Paul >> -----Message d'origine----- >> De : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la >> part de Christer Holmberg >> Envoyé : mardi 3 avril 2012 08:40 >> Ą : Paul Kyzivat; Hadriel Kaplan >> Cc : Dale R (Dale) Worley; >> Objet : Re: [sipcore] Content-Length in multipart body parts >> >> Hi, >> >>>> Ugh. Yeah, that's not good for examples to show. >>>> So what's the solution? Errata? >>> >>> Yes, I think the errata process is the right one for this. >> >> Agree, eventhough the C-L should cause no conflicts (as long as the >> value is correct). >> >> And, even if a specific MIME contains another (nested) multipart entry, >> C-L should not be needed, as the MIME borders are still present. >> >> Regards, >> >> Christer >> >> >>> -hadriel >>> p.s. I like the "Suspicious Line" thing - all RFC lines are >>> suspicious! ;) >>> >>> >>> On Apr 2, 2012, at 2:12 PM, Paul Kyzivat wrote: >>> >>>> [reposting with a subject line] >>>> >>>> On 4/2/12 6:53 PM, Worley, Dale R (Dale) wrote: >>>>> Bruno Chatras has pointed out that a number of examples in various >>>>> SIP-related RFCs show Content-Length header fields in the headers >> of >>>>> body-parts of multipart entities. MIME does not define the >> meaining >>>>> of such header fields, as the MIME framing of body parts is done by >> the boundary markers. >>>>> >>>>> As Dale Moberg has pointed out, these header fields might not be >>>>> truly incorrect but merely redundant or "to be ignored". >>>>> >>>>> But given that MIME multipart already frames the body-parts, >>>>> Content-Length headers on body-parts are never necessary. >>>>> >>>>> So it seems to me that we should decide on a "best practices" for >>>>> the use of Content-Length in the headers of a body part, to clarify >>>>> the ambiguities in the specifications, and to state whether it's >>>>> preferable to include such a Content-Length or not. >>>>> >>>>> I've appended a list of all the examples carrying such >>>>> Content-Length headers that I could find by automated means. >>>>> >>>>> Dale >>>>> ------------------------------------------------------------------- >> - >>>>> ------------------------------------ >>>>> RFC 2848 >>>>> >>>>> The PINT Service Protocol: >>>>> Extensions to SIP and SDP for IP Access to Telephone Call >>>>> Services >>>>> >>>>> Suspicious line at rfc2848.txt:2195: Content-Length: 236 >>>>> Suspicious line at rfc2848.txt:2209: Content-Length:50 >>>>> Suspicious line at rfc2848.txt:2268: Content-Length: 316 >>>>> Suspicious line at rfc2848.txt:2284: Content-Length: 172 >>>>> Suspicious line at rfc2848.txt:2372: Content-Length: 325 >>>>> Suspicious line at rfc2848.txt:2387: Content-Length: 352 >>>>> >>>>> Several of these body-part headers are not separated from the >>>>> body-part contents by CR-LF-CR-LF. >>>>> >>>>> RFC 3261 >>>>> >>>>> SIP: Session Initiation Protocol >>>>> >>>>> Suspicious line at rfc3261.txt:11846: Content-Length: 231 >>>>> >>>>> RFC 3892 >>>>> >>>>> The Session Initiation Protocol (SIP) Referred-By Mechanism >>>>> >>>>> Suspicious line at rfc3892.txt:642: Content-Length: >> (appropriate value) >>>>> Suspicious line at rfc3892.txt:687: Content-Length: >> (appropriate value) >>>>> Suspicious line at rfc3892.txt:702: Content-Length: >> (appropriate value) >>>>> Suspicious line at rfc3892.txt:879: Content-Length: >> (appropriate value) >>>>> Suspicious line at rfc3892.txt:887: Content-Length: >> (appropriate value) >>>>> Suspicious line at rfc3892.txt:938: Content-Length: >> (appropriate value) >>>>> Suspicious line at rfc3892.txt:964: Content-Length: >> (appropriate value) >>>>> Suspicious line at rfc3892.txt:972: Content-Length: >> (appropriate value) >>>>> Suspicious line at rfc3892.txt:1056: Content-Length: >> (appropriate value) >>>>> Suspicious line at rfc3892.txt:1106: Content-Length: >> (appropriate value) >>>>> Suspicious line at rfc3892.txt:1168: Content-Length: >> (appropriate value) >>>>> Suspicious line at rfc3892.txt:1196: Content-Length: >> (appropriate value) >>>>> >>>>> RFC 3893 >>>>> >>>>> Session Initiation Protocol (SIP) >>>>> Authenticated Identity Body (AIB) Format >>>>> >>>>> Suspicious line at rfc3893.txt:249: Content-Length: 147 >>>>> (This has an extra CR-LF before the body-part headers.) >>>>> Suspicious line at rfc3893.txt:263: Content-Length: 608 >>>>> >>>>> RFC 4463 >>>>> >>>>> A Media Resource Control Protocol (MRCP) >>>>> Developed by Cisco, Nuance, and Speechworks >>>>> >>>>> Suspicious line at rfc4463.txt:1705: Content-Length:176 >>>>> Suspicious line at rfc4463.txt:1714: Content-Length:104 >>>>> Suspicious line at rfc4463.txt:2977: Content-Length:176 >>>>> (Also missing the CR-LF after the body part headers.) >>>>> Suspicious line at rfc4463.txt:2985: Content-Length:104 >>>>> >>>>> RFC 5547 >>>>> >>>>> A Session Description Protocol (SDP) Offer/Answer Mechanism >>>>> to Enable File Transfer >>>>> >>>>> Suspicious line at rfc5547.txt:1645: Content-Length: [length of >> SDP] >>>>> Suspicious line at rfc5547.txt:1670: Content-Length: [length of >> image] >>>>> Suspicious line at rfc5547.txt:2093: Content-Length: [length of >> SDP] >>>>> Suspicious line at rfc5547.txt:2118: Content-Length: [length of >> image] >>>>> >>>>> RFC 5589 >>>>> >>>>> Session Initiation Protocol (SIP) Call Control - Transfer >>>>> >>>>> Suspicious line at rfc5589.txt:2609: Content-Length: 2961 >>>>> (An extra CR-LF in the middle of the body part headers.) >>>>> Suspicious line at rfc5589.txt:2677: Content-Length: 156 >>>>> (An extra CR-LF in the middle of the body part headers.) >>>>> Suspicious line at rfc5589.txt:2696: Content-Length: 2961 >>>>> >>>>> RFC 6086 >>>>> >>>>> Session Initiation Protocol (SIP) INFO Method and Package >>>>> Framework >>>>> >>>>> Suspicious line at rfc6086.txt:1594: Content-length: 59 >>>>> Suspicious line at rfc6086.txt:1620: Content-length: 59 >>>>> Suspicious line at rfc6086.txt:1637: Content-length: 59 >>>>> Suspicious line at rfc6086.txt:1664: Content-length: 59 >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From kpfleming@digium.com Tue Apr 3 14:47:04 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A105221F86D5 for ; Tue, 3 Apr 2012 14:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.74 X-Spam-Level: X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, 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 ZOKm3N3DR4AN for ; Tue, 3 Apr 2012 14:47:04 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 09D6721F86D1 for ; Tue, 3 Apr 2012 14:47:03 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SFBZ8-00019b-Jl for sipcore@ietf.org; Tue, 03 Apr 2012 16:47:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 9EC56D8002 for ; Tue, 3 Apr 2012 16:47:02 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6xe3ApF5f-P for ; Tue, 3 Apr 2012 16:47:02 -0500 (CDT) Received: from [10.11.9.129] (50-1-53-2.dedicated.static.sonic.net [50.1.53.2]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id F3B91D8004 for ; Tue, 3 Apr 2012 16:47:01 -0500 (CDT) Message-ID: <4F7B6FD5.2050906@digium.com> Date: Tue, 03 Apr 2012 14:47:01 -0700 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Editorial (minor) comment on RFC 5627 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 21:47:04 -0000 On 03/31/2012 12:58 PM, Nataraju A.B wrote: > Hi All, > > > I feel following is an editorial comment on the RFC 5627... > > > > 4.4. Using One's Own GRUUs > > > ....A UA compliant to this specification SHOULD use one of its GRUUs as its remote target. This includes.. > > > . . . . > > o a 2xx response to NOTIFY > o the UPDATE request > o a 2xx response to *NOTIFY* > > > The last point must have been mentioned as > > o a 2xx response to **UPDATE** Please check to see whether an errata has been filed already, and if not, you should file one yourself so this will be tracked for a future revision of the document. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From nataraju.sip@gmail.com Tue Apr 3 18:04:02 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485E011E8073 for ; Tue, 3 Apr 2012 18:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.048 X-Spam-Level: X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 i1pEj2tKVSAy for ; Tue, 3 Apr 2012 18:04:01 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B803911E8072 for ; Tue, 3 Apr 2012 18:04:00 -0700 (PDT) Received: by lagj5 with SMTP id j5so399823lag.31 for ; Tue, 03 Apr 2012 18:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iJidp5RWrDuVIwgD07ertiXimENvOB+KqvRr3FwiIUc=; b=JdNKSWDUtBGkRQy4lIYYR1ODtSsfRRDbVML6DZcplFUWhJ1CEC3XBiuzwz+vIUGm/h Ll8vb2Cfzcej5dVwVKodsY6h5OW8IY4f+5c9JlqXH2Jw7hsS9Kpw0q22zjQGAwTzw3u/ 8k6JD7pIiumoopkDEjpcQ+iRs9fypSNjuOu0rsJx2VDA4SPvt2+azwEfPjGxwMmgOrQi HgpYG4GeJWkHOYOe8jZjBeza0EzuvgRAOMCWI/FYACpKH+9iVxLkm0tU3EKbeQgxCpAj ToRWmOmzRfe73I8i8R0ZNjcFm8nMUtCaydGXpmJiyLTuZ8/1WDM/IR4j0FsMoceSI0xD rxaw== MIME-Version: 1.0 Received: by 10.152.147.100 with SMTP id tj4mr15193500lab.39.1333501439676; Tue, 03 Apr 2012 18:03:59 -0700 (PDT) Received: by 10.112.103.103 with HTTP; Tue, 3 Apr 2012 18:03:59 -0700 (PDT) In-Reply-To: <4F7B6FD5.2050906@digium.com> References: <4F7B6FD5.2050906@digium.com> Date: Wed, 4 Apr 2012 06:33:59 +0530 Message-ID: From: "Nataraju A.B" To: "Kevin P. Fleming" Content-Type: multipart/alternative; boundary=e89a8f22bd899e90ca04bccfff5b Cc: sipcore@ietf.org Subject: Re: [sipcore] Editorial (minor) comment on RFC 5627 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 01:04:02 -0000 --e89a8f22bd899e90ca04bccfff5b Content-Type: text/plain; charset=ISO-8859-1 I have filed the bug against rfc 5627 *Errata ID: 3173 * Thanks, Nataraju A.B. On Wed, Apr 4, 2012 at 3:17 AM, Kevin P. Fleming wrote: > On 03/31/2012 12:58 PM, Nataraju A.B wrote: > >> Hi All, >> >> >> I feel following is an editorial comment on the RFC 5627... >> >> >> >> 4.4. Using One's Own GRUUs >> >> >> ....A UA compliant to this specification SHOULD use one of its GRUUs >> as its remote target. This includes.. >> >> >> . . . . >> >> o a 2xx response to NOTIFY >> o the UPDATE request >> o a 2xx response to *NOTIFY* >> >> >> The last point must have been mentioned as >> >> o a 2xx response to **UPDATE** >> > > Please check to see whether an errata has been filed already, and if not, > you should file one yourself so this will be tracked for a future revision > of the document. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at www.digium.com & www.asterisk.org > > ______________________________**_________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/**listinfo/sipcore > -- Thanks, Nataraju A.B. --e89a8f22bd899e90ca04bccfff5b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have filed the bug against rfc 5627

Errata ID: 3173=A0

Tha= nks,
Nataraju A.B.

On Wed, Apr 4, 2012 at 3:17 AM, Kevin P. Fleming= <kpfleming@di= gium.com> wrote:
On 03/31/2012 12:58 PM, Nataraju A.B wrot= e:
Hi All,


I feel following is an editorial comment on the RFC 5627...



4.4. =A0Using One's Own GRUUs


=A0 =A0 ....A UA compliant to this specification SHOULD use one of its GRU= Us as its remote target. This includes..


=A0 =A0. . . .

=A0 =A0o =A0a 2xx response to NOTIFY
=A0 =A0o =A0the UPDATE request
=A0 =A0o =A0a 2xx response to *NOTIFY*


The last point must have been mentioned as

=A0 =A0o =A0a 2xx response to **UPDATE**

Please check to see whether an errata has been filed already, and if not, y= ou should file one yourself so this will be tracked for a future revision o= f the document.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@d= igium.com | SIP: kpfleming@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.dig= ium.com & www= .asterisk.org

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



--
= Tha= nks,
Nataraju A.B.

--e89a8f22bd899e90ca04bccfff5b-- From pkyzivat@alum.mit.edu Wed Apr 4 07:07:27 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CB021F87A8 for ; Wed, 4 Apr 2012 07:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jD85eAuYS67c for ; Wed, 4 Apr 2012 07:07:26 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 35E2821F87A7 for ; Wed, 4 Apr 2012 07:07:26 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA11.westchester.pa.mail.comcast.net with comcast id tq0h1i0060vyq2s5Bq7S3R; Wed, 04 Apr 2012 14:07:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta05.westchester.pa.mail.comcast.net with comcast id tq7S1i00f07duvL3Rq7SRn; Wed, 04 Apr 2012 14:07:26 +0000 Message-ID: <4F7C559D.50508@alum.mit.edu> Date: Wed, 04 Apr 2012 10:07:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <4F7B6FD5.2050906@digium.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Editorial (minor) comment on RFC 5627 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2012 14:07:27 -0000 On 4/3/12 9:03 PM, Nataraju A.B wrote: > I have filed the bug against rfc 5627 > > *Errata ID: 3173 > * Thanks! Paul > Thanks, > Nataraju A.B. > > On Wed, Apr 4, 2012 at 3:17 AM, Kevin P. Fleming > wrote: > > On 03/31/2012 12:58 PM, Nataraju A.B wrote: > > Hi All, > > > I feel following is an editorial comment on the RFC 5627... > > > > 4.4. Using One's Own GRUUs > > > ....A UA compliant to this specification SHOULD use one of > its GRUUs as its remote target. This includes.. > > > . . . . > > o a 2xx response to NOTIFY > o the UPDATE request > o a 2xx response to *NOTIFY* > > > The last point must have been mentioned as > > o a 2xx response to **UPDATE** > > > Please check to see whether an errata has been filed already, and if > not, you should file one yourself so this will be tracked for a > future revision of the document. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: kfleming@digium.com | SIP: > kpfleming@digium.com | Skype: kpfleming > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at www.digium.com & > www.asterisk.org > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > > > > -- > Thanks, > Nataraju A.B. > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nataraju.sip@gmail.com Thu Apr 5 11:42:43 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4906B21F869D for ; Thu, 5 Apr 2012 11:42:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.581 X-Spam-Level: X-Spam-Status: No, score=-0.581 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_50=0.001, HTML_FONT_FACE_BAD=0.884, 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 BQ219DQyi3KE for ; Thu, 5 Apr 2012 11:42:42 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 84F2C21F869C for ; Thu, 5 Apr 2012 11:42:41 -0700 (PDT) Received: by lagj5 with SMTP id j5so543106lag.31 for ; Thu, 05 Apr 2012 11:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mWw5sc4fsHmcWJsrIqm6v5pCVygoqwO/KLbpLdKbyfU=; b=mcVCFf+aaHi//+ha4S1OjzNrm+1me1stFRbE6OtFiDbGJgGyxmH4HUcwaqjDCg1K0C +7caKfGdEcEnIR7q6/h46baLYQISgphrK8G8+QDsyWCBscghHY74anz6tOGuDkyJS5Ic uRqA5zEZCkNnRTj0eVdikJtw7Hgw9OHMF+SWXJfr7XtxM7z62V1C/QsPCn/KdKcq2bLq Xll6kSYlgirbHhee27W5Iy0SLB9PmP/PxEnxV0XrPh2wwrVcE8+YVmRUgSRuM5DmZx/b 22Fy8H+HdpuDNcOkc62FGT1BFc6NHT6EO/g82n55BjEYiui4rBolkOWZtKyyqu4O7Jrv h/Pg== MIME-Version: 1.0 Received: by 10.152.110.193 with SMTP id ic1mr4703714lab.4.1333651359797; Thu, 05 Apr 2012 11:42:39 -0700 (PDT) Received: by 10.112.103.103 with HTTP; Thu, 5 Apr 2012 11:42:39 -0700 (PDT) Date: Fri, 6 Apr 2012 00:12:39 +0530 Message-ID: From: "Nataraju A.B" To: sipcore@ietf.org, Jonathan Rosenberg Content-Type: multipart/alternative; boundary=f46d04083b0f8e120704bcf2e76f Subject: [sipcore] clarification needed : GRUU - Contact mapping - RFC 5627 (GRUU) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 18:42:43 -0000 --f46d04083b0f8e120704bcf2e76f Content-Type: text/plain; charset=ISO-8859-1 Hi All, AFAIU, the GRUU is always associated with a specific UA instance (only one). But the following text from RFC5627 seems to convey single GRUU can be mapped on to more than one contact/UA instance. Following is the excerpt from RFC5627. <5627> 3.4. Dereferencing a GRUU Because a GRUU is simply a URI, a UA dereferences it in exactly the same way as it would any other URI. However, once the request has been routed to the appropriate proxy, the behavior is slightly different. The proxy will map the GRUU to the AOR and determine the set of contacts that the particular UA instance has registered. The GRUU is then mapped to **those contacts**, and the request is routed towards the UA. I feel the text must rephrased as follows <> Because a GRUU is simply a URI, a UA dereferences it in exactly the same way as it would any other URI. However, once the request has been routed to the appropriate proxy, the behavior is slightly different. The proxy will map the GRUU to the AOR and determine the set of contacts that are registered with the AOR. Then GRUU is mapped to specific contact based on matching instance id (+sip.instance), and then request is routed towards the specific UA. I appreciate your opinion on the same issue. Thanks, Nataraju A.B. --f46d04083b0f8e120704bcf2e76f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 
Hi All,


AFAIU, the GRUU is al=
ways associated with a specific UA instance (only one). But the following t=
ext from=A0RFC5627 seems to convey single GRUU can be mapped on to more tha=
n one contact/UA instance.=A0

Following is the excerpt from RFC5627.

<5627>
3.4.  Dereferencing a GRUU<=
/pre>
   Because a GRUU is simply a=
 URI, a UA dereferences it in exactly the
   same way as it would any other URI.  However, once the request has
   been routed to the appropriate proxy, the behavior is slightly
   different.  The proxy will map the GRUU to the A=
OR and determine the
   set of contacts that the particular UA instance has registered.  The
   GRUU is then mapped to **those contacts**, and the request is routed
   towards the UA.

</5627><=
/font>
I feel the text must rephrased as follows



=

<&=
gt;

=A0 =A0Because a GRUU is simply a URI, a UA dereferences it in exactly the<=
/div>
=A0 =A0same way as it would any other URI. =A0However, once the r=
equest has
=A0 =A0been routed to the appropriate proxy, the behav=
ior is slightly


=A0 =A0different. =A0The proxy will map the GR=
UU to the AOR and determine the
=
=A0 =A0set of contacts that are registered with the AOR. Then=A0
=A0 =A0GRUU is mapped to specific contact ba=
sed on matching instance id=A0


=A0 =A0(+=
sip.instance), and then request is routed=A0towards the specific UA.=

</>



I appreciat=
e your opinion on the same issue.

Thanks,<=
/font>


Nataraju A.B.


--f46d04083b0f8e120704bcf2e76f--

From pkyzivat@alum.mit.edu  Thu Apr  5 11:47:14 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6930C21F863D for ; Thu,  5 Apr 2012 11:47:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0aDuGLqx999 for ; Thu,  5 Apr 2012 11:47:14 -0700 (PDT)
Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id C96C721F8613 for ; Thu,  5 Apr 2012 11:47:13 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id uDu11i0041vXlb851JnEw6; Thu, 05 Apr 2012 18:47:14 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id uJnD1i00c07duvL3dJnErv; Thu, 05 Apr 2012 18:47:14 +0000
Message-ID: <4F7DE8B0.1040109@alum.mit.edu>
Date: Thu, 05 Apr 2012 14:47:12 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: sipcore@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [sipcore] clarification needed : GRUU - Contact mapping - RFC 5627 (GRUU)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 05 Apr 2012 18:47:14 -0000

On 4/5/12 2:42 PM, Nataraju A.B wrote:
> Hi All,
>
>
> AFAIU, the GRUU is always associated with a specific UA instance (only one). But the following text from RFC5627 seems to convey single GRUU can be mapped on to more than one contact/UA instance.

The text below covers that case where a particular UA is fault tolerant 
and replicated or has multiple interfaces.  (Such as spelled out in 
outbound - RFC5626.

	Thanks,
	Paul

> Following is the excerpt from RFC5627.
>
>
> <5627>
>
> 3.4.  Dereferencing a GRUU
>
>     Because a GRUU is simply a URI, a UA dereferences it in exactly the
>     same way as it would any other URI.  However, once the request has
>     been routed to the appropriate proxy, the behavior is slightly
>     different.The proxy will map the GRUU to the AOR and determine the
>     set of contacts that the particular UA instance has registered.  The
>     GRUU is then mapped to **those contacts**, and the request is routed
>     towards the UA.
>
> 
>
> I feel the text must rephrased as follows
>
> <>
>     Because a GRUU is simply a URI, a UA dereferences it in exactly the
>     same way as it would any other URI.  However, once the request has
>     been routed to the appropriate proxy, the behavior is slightly
>     different. The proxy will map the GRUU to the AOR and determine the
>     set of contacts that are registered with the AOR. Then
>     GRUU is mapped to specific contact based on matching instance id
>     (+sip.instance), and then request is routed towards the specific UA.
> 
>
> I appreciate your opinion on the same issue.
>
> Thanks,
> Nataraju A.B.
>
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore


From adam@nostrum.com  Wed Apr 11 07:38:34 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE45B21F85CE for ; Wed, 11 Apr 2012 07:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.562
X-Spam-Level: 
X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, SPF_PASS=-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 tMZALzM1hwbz for ; Wed, 11 Apr 2012 07:38:34 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1E54921F85CD for ; Wed, 11 Apr 2012 07:38:33 -0700 (PDT)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q3BEcWpd069306 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 11 Apr 2012 09:38:33 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4F859768.2050702@nostrum.com>
Date: Wed, 11 Apr 2012 09:38:32 -0500
From: Adam Roach - SIPCORE Chair 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "SIPCORE (Session Initiation Protocol Core) WG" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Subject: [sipcore] New Milestone: WebSockets transport
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: SIPCORE Chairs 
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Apr 2012 14:38:34 -0000

[as chair]

Based on feedback at the meeting in Paris and a lack of on-list 
objection, I'm declaring working group consensus for adding a milestone 
to the SIPCORE charter for the definition of a new WebSockets transport 
for SIP. The new milestone I am requesting is:


Apr 2013  WebSockets transport definition for SIP to the IESG (proposed 
standard)


In terms of document adoption: we did not call for any specific document 
to be adopted in Paris, and response to the call for consensus on the 
email list has been tepid (only six people have responded to that call: 
one requested holding off adoption until changes have been made to 
reflect the discussion to date; an author spoke in favor of adoption; 
and the remaining four participants voiced neither support or objection).

Absent an indication of consensus to adopt the document, I request that 
the authors submit a new version reflecting the discussions we have had 
on the email list and in Paris regarding the outbound and GRUU 
mechanisms. I will then issue a second formal call for adoption of the 
document to satisfy the milestone.

Thank you.

/a

From internet-drafts@ietf.org  Wed Apr 11 15:09:36 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CFC11E80EE; Wed, 11 Apr 2012 15:09:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.52
X-Spam-Level: 
X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, 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 pTW-gIyJFZSv; Wed, 11 Apr 2012 15:09:36 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6213511E80CC; Wed, 11 Apr 2012 15:09:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120411220936.15081.26823.idtracker@ietfa.amsl.com>
Date: Wed, 11 Apr 2012 15:09:36 -0700
Cc: sipcore@ietf.org
Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc3265bis-08.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 11 Apr 2012 22:09:37 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Session Initiation Protocol Core Work=
ing Group of the IETF.

	Title           : SIP-Specific Event Notification
	Author(s)       : Adam Roach
	Filename        : draft-ietf-sipcore-rfc3265bis-08.txt
	Pages           : 52
	Date            : 2012-04-11

   This document describes an extension to the Session Initiation
   Protocol (SIP).  The purpose of this extension is to provide an
   extensible framework by which SIP nodes can request notification from
   remote nodes indicating that certain events have occurred.

   Note that the event notification mechanisms defined herein are NOT
   intended to be a general-purpose infrastructure for all classes of
   event subscription and notification.

   This document represents a backwards-compatible improvement on the
   original mechanism described by RFC 3265, taking into account several
   years of implementation experience.  Accordingly, this document
   obsoletes RFC 3265.  This document also updates RFC 4660 slightly to
   accommodate some small changes to the mechanism that were discussed
   in that document.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-08.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-08.txt


From adam@nostrum.com  Thu Apr 12 10:19:46 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E97121F86B0 for ; Thu, 12 Apr 2012 10:19:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.479
X-Spam-Level: 
X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, SPF_PASS=-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 DJP-ZpiY0sui for ; Thu, 12 Apr 2012 10:19:46 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id DA4B321F86A7 for ; Thu, 12 Apr 2012 10:19:45 -0700 (PDT)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q3CHJe4W035343 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 12 Apr 2012 12:19:45 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4F870EAC.3030900@nostrum.com>
Date: Thu, 12 Apr 2012 12:19:40 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "SIPCORE (Session Initiation Protocol Core) WG" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Subject: [sipcore] RFC3265bis: reason code registration policy
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Apr 2012 17:19:46 -0000

[as document author]

As you probably know, RFC3265bis has been handed off to the IESG for 
pre-publication evaluation.

Section 7.2 of the RFC3265bis document discusses the new IANA registry 
for the "reason" code. The gen-art review of this document turned up the 
following discrepancy:

  * 'Following the policies outlined in "Guidelines for Writing an IANA
    Considerations Section in RFCs" [RFC5226], new reason codes require
    a Standards Action.'

  * ' Insertion of such values takes place as part of the RFC
    publication process or as the result of inter-SDO liaison activity.'


The problem is that the "Standards Action" requirement is defined: 
"Values are assigned only for Standards Track RFCs approved by the 
IESG," which implies that inter-SDO liaising isn't sufficient for adding 
values.

I can't find any relic of this issue being discussed on the mailing 
list, and have no specific recollection how we arrived at the current 
text. Keep in mind that the need to expand these reason codes should be 
very slight (we've only had one in nine years since 3265 was published), 
and will almost certainly be paired with protocol changes that RFC 5727 
would require an RFC for anyway.

Based on those two factors (and especially the second one), I think what 
we probably want to do is remove the phrase "of as the result of 
inter-SDO liaison activity," and leave the policy "Standards Action" as 
currently stated.

Please raise any objections to this proposed course of action on the 
SIPCORE mailing list. I will make sure the results of any on-list 
discussion are brought to the attention of the IESG.

/a


From jmillan@aliax.net  Thu Apr 12 13:44:36 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93D521F86BB for ; Thu, 12 Apr 2012 13:44:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwFb4iBRLP4s for ; Thu, 12 Apr 2012 13:44:36 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 02A4E21F86B6 for ; Thu, 12 Apr 2012 13:44:35 -0700 (PDT)
Received: by iazz13 with SMTP id z13so3907030iaz.31 for ; Thu, 12 Apr 2012 13:44:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=t8kkL/5IS3HSjgDnBs83g08lh/HsI25vDHUHUUpS/Go=; b=BtgNJICFsFSvdVfAyoXtokTK+Fv2pfotONLL0IKDCI8nqshYrjKHY9ntFaAd4M8lHo 58alG9CJLwjxjhoR4Rnfk5RSDvpsEMEbfrH1n+jf6a/NxBdCBnzFdrnc4c5JvkjhnKLX NRsu80Ge4e+BrCEpOFZYXbI1zZdiGDVL6jowCtKVK/eo46Y+d7FvxM6Ve7YAPIu65qvG zyXx7AtYEIfi9ZslUKnCCCl4gOrpBZLkALwS5qFe9BmgEz+OAIESdtIVdL4daF5dsuU4 3vYFoRvMD8vBRtGcB4GeeL3d2XOox1JrLo4SpeV5cyk9IdwpLEGAwOLGihXCnYU8oh2S cefA==
MIME-Version: 1.0
Received: by 10.50.88.199 with SMTP id bi7mr7633380igb.15.1334263475576; Thu, 12 Apr 2012 13:44:35 -0700 (PDT)
Received: by 10.231.123.17 with HTTP; Thu, 12 Apr 2012 13:44:35 -0700 (PDT)
In-Reply-To: <4F859768.2050702@nostrum.com>
References: <4F859768.2050702@nostrum.com>
Date: Thu, 12 Apr 2012 22:44:35 +0200
Message-ID: 
From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= 
To: SIPCORE Chairs 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlisOHcQLlMESZkjOtU5/QIvjI2mToH0u1gUG1Fpe9gF4pVTiNZGuMxmJbT8MmYcc5aRtly
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] New Milestone: WebSockets transport
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 12 Apr 2012 20:44:36 -0000

El d=EDa 11 de abril de 2012 16:38, Adam Roach - SIPCORE Chair
 escribi=F3:
> [as chair]
>
> Based on feedback at the meeting in Paris and a lack of on-list objection=
,
> I'm declaring working group consensus for adding a milestone to the SIPCO=
RE
> charter for the definition of a new WebSockets transport for SIP. The new
> milestone I am requesting is:
>
>
> Apr 2013 =A0WebSockets transport definition for SIP to the IESG (proposed
> standard)
>
>
> In terms of document adoption: we did not call for any specific document =
to
> be adopted in Paris, and response to the call for consensus on the email
> list has been tepid (only six people have responded to that call: one
> requested holding off adoption until changes have been made to reflect th=
e
> discussion to date; an author spoke in favor of adoption; and the remaini=
ng
> four participants voiced neither support or objection).
>
> Absent an indication of consensus to adopt the document, I request that t=
he
> authors submit a new version reflecting the discussions we have had on th=
e
> email list and in Paris regarding the outbound and GRUU mechanisms. I wil=
l
> then issue a second formal call for adoption of the document to satisfy t=
he
> milestone.
>

A new version of the document addressing the discussions we have had
will be submitted in the next few days.

Thank you.

> Thank you.
>
> /a
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore

From nataraju.sip@gmail.com  Fri Apr 13 10:23:07 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F25B21F87A5 for ; Fri, 13 Apr 2012 10:23:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.498
X-Spam-Level: 
X-Spam-Status: No, score=-0.498 tagged_above=-999 required=5 tests=[AWL=-0.083, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MANGLED_SAVELE=2.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 V95EGFNWmOi9 for ; Fri, 13 Apr 2012 10:23:05 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 417D121F8587 for ; Fri, 13 Apr 2012 10:23:04 -0700 (PDT)
Received: by lagj5 with SMTP id j5so2780657lag.31 for ; Fri, 13 Apr 2012 10:23:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=wCsxARW4imtDMP8G6QmMMfdWX+jkueCBLGUIt7dzZX0=; b=HLDNW4zi/BQB7IQWurFjm2W51Ki/AWnEyS3yv89hg8LRUfGbzcdkVFVHFtjflin+aN 5ywLRIXGGiS7ju4ETiOCvx0eRFQnBl8NJFzISMZ3/9aDH2+QY/x/lcenuKtWb7UljXFP 9X6LlaDPoR0XdwufDC9nd4yYN/G6MquoVqzOgLHIgcCkAJXGaU/DGGahEGsncOfWODJ2 0+8K9cVAwrztFjylgwaOqfkfQlWt/zctrx2nNlE2aP2UB0sImuv7McFWu2wXAkWsSltE b2nhSok0xJIvCxHtecoZO6A417AoXGTx7wpgkb6bAghz5MGyrJHg2LizpD8haDEPgNla Dd0Q==
MIME-Version: 1.0
Received: by 10.152.132.166 with SMTP id ov6mr2366904lab.35.1334337783180; Fri, 13 Apr 2012 10:23:03 -0700 (PDT)
Received: by 10.112.103.103 with HTTP; Fri, 13 Apr 2012 10:23:03 -0700 (PDT)
Date: Fri, 13 Apr 2012 22:53:03 +0530
Message-ID: 
From: "Nataraju A.B" 
To: Adam Roach , sipcore@ietf.org
Content-Type: multipart/alternative; boundary=f46d0430855a93ad1604bd92b957
Subject: [sipcore] draft-ietf-sipcore-rfc3265bis-08.txt - Review comments (Nataraju A B)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 13 Apr 2012 17:23:07 -0000

--f46d0430855a93ad1604bd92b957
Content-Type: text/plain; charset=ISO-8859-1

Adam,

Please find some editorial comments on the draft
"draft draft-ietf-sipcore-rfc3265bis-08.txt"

For simplicity, I have mentioned both the current text and proposed text.

The comments / corrective text can be found with prefix and suffix  --- **

-----------------------------------------------------
1.1.  Overview of Operation
CurrentText:
   The general concept is that entities in the network can subscribe to
   resource or call state for various resources or calls in the network,
   and those entities (or entities acting on their behalf) can send
   notifications when those states change.

ReplacementText:
   The general concept is that entities in the network can subscribe to
   resource or call state **at / of** various resources or calls in the
network,
   and those entities (or entities acting on their behalf) **who** can send
   notifications when those states change.
-----------------------------------------------------

1.1.  Overview of Operation

CurrentText:
   Subscriptions are expired and must be refreshed by subsequent
   SUBSCRIBE requests.

ReplacementText:
   Subscriptions are expired and must be refreshed by subsequent
   SUBSCRIBE requests **before expiration**.
-----------------------------------------------------

2.  Definitions

CurrentText:
   Subscriber:  A subscriber is a user agent which receives NOTIFY
      requests from notifiers; these NOTIFY requests contain information
      about the state of a resource in which the subscriber is
      interested.  Subscribers typically also generate SUBSCRIBE
      requests and send them to notifiers to create subscriptions.

Comment:
After this information, we can add a normative text which indicates
 when a SIP entity might get NOTIFY messages without actually
 sending SUBSCRIBE request. For example, REFER request might end up with
implicit subscription. Also mention any other requests which may lead to
 implicit subscriptions (other than REFER).
-----------------------------------------------------
2.  Definitions

CurrentText:
   Subscription:  A subscription is a set of application state
      associated with a dialog.  This application state includes a
      pointer to the associated dialog, the event package name, and
      possibly an identification token.  Event packages will define
      additional subscription state information.  By definition,
      subscriptions exist in both a subscriber and a notifier.

ReplacementText:
   Subscription:  A subscription is a set of application **states**
      associated with a dialog.  **The** application state includes a
      pointer to the associated dialog, the event package name, and
      possibly an identification token.  Event packages will define
      additional subscription state information.  By definition,
      subscriptions exist in both a subscriber and a notifier.
-----------------------------------------------------
3.1.1.  Subscription Duration

CurrentText:

   subscription.  In order to keep subscriptions effective beyond the
   duration communicated in the "Expires" header field, subscribers need
   to refresh subscriptions on a periodic basis using a new SUBSCRIBE
   request on the same dialog as defined in [RFC3261].

ReplacementText
3.1.1.  Subscription Duration

   subscription.  In order to keep subscriptions effective beyond the
   duration communicated in the "Expires" header field, subscribers need
   to refresh subscriptions **before expiration** on a periodic basis using
a new SUBSCRIBE
   request on the same dialog as defined in [RFC3261].
-----------------------------------------------------
3.1.1.  Subscription Duration

CurrentText:
      In addition to being a request to unsubscribe, a SUBSCRIBE request
      with "Expires" of 0 also causes a fetch of state; see
      Section 4.4.3.

Comment:
     The above text has been mentioned to be normative text. But I feel
this
     shall be written as a regualr text in the draft/rfc. because this is
the
     expected behavior from the notifier.
-----------------------------------------------------
3.1.2.  Identification of Subscribed Events and Event Classes

CurrentText:
   Subscribers MUST include exactly one "Event" header field in
   SUBSCRIBE requests, indicating to which event or class of events they
   are subscribing.  The "Event" header field will contain a token which
   indicates the type of state for which a subscription is being
   requested.  This token will be registered with the IANA and will
   correspond to an event package which further describes the semantics
   of the event or event class.


ReplacementText:
   Subscribers MUST include exactly one "Event" header field in
   SUBSCRIBE requests, indicating to which event or class of events they
   are subscribing.  The "Event" header field **MUST** contain a token which
   indicates the type of state for which a subscription is being
   requested.  This token will be registered with the IANA and will
   correspond to an event package which further describes the semantics
   of the event or event class.
-----------------------------------------------------
3.1.  SUBSCRIBE

CurrentText:
   The SUBSCRIBE method is used to request current state and state
   updates from a remote node.  SUBSCRIBE requests are target refresh


ReplacementText:
   The SUBSCRIBE method is used to request current state and **subsequent**
state
   updates from a remote node.  SUBSCRIBE requests are target refresh


-----------------------------------------------------
3.1.1.  Subscription Duration

CurrentText:

   SUBSCRIBE requests SHOULD contain an "Expires" header field (defined
   in [RFC3261]).  This expires value indicates the duration of the
   subscription.  In order to keep subscriptions effective beyond the
   duration communicated in the "Expires" header field, subscribers need
   to refresh subscriptions on a periodic basis using a new SUBSCRIBE
   request on the same dialog as defined in [RFC3261].

Comment:
We can add a normative text saying, the refresh time will be
 normally 50% to 75% of subscription duration.

-----------------------------------------------------
3.2.1.

CurrentText:
   This body will contain either the state of the subscribed resource or
   a pointer to such state in the form of a URI (see Section 5.4.13).

ReplacementText/Comment:
   This body **SHALL** contain either the state of the subscribed resource
or
   a pointer to such state in the form of a **URL** (see Section 5.4.13).
-----------------------------------------------------
4.1.2.  Creating and Maintaining Subscriptions


CurrentText:

   From the subscriber's perspective, a subscription proceeds according
   to the following state diagram:

Comment:
Here it is better to mention, what happens to FSM when 200-SUBSCRIBE
 received in notify_wait state (because very often this is possible).
 If no change in state of FSM, then some normative text shall convey the
same.
        It may be no-operation, but better to mention the same.
-----------------------------------------------------
4.1.2.1.  Requesting a Subscription

CurrentText:
   When a subscriber wishes to subscribe to a particular state for a
   resource, it forms a SUBSCRIBE request.  If the initial SUBSCRIBE

ReplacementText:
   When a subscriber wishes to subscribe to a particular state **of** a
   resource, it forms a SUBSCRIBE request **according to sec 3.1 and send
it across to notifier**.  If the initial SUBSCRIBE

-----------------------------------------------------
4.1.2.1.  Requesting a Subscription

CurrentText:
   [RFC3261].  For the sake of clarity: if a SUBSCRIBE request contains
   an "Accept" header field, but that field does not indicate a media
   type that the notifier is capable of generating in its NOTIFY
   requests, then the proper error response is 406 (Not Acceptable).

COMMENT:
It is better to mention it as a normative text (indented).

-----------------------------------------------------
4.1.3.  Receiving and Processing State Information

CurrentText:

   If the "Subscription-State" value is "terminated", the subscriber
   MUST consider the subscription terminated.  The "expires" parameter
   has no semantics for "terminated" -- notifiers SHOULD NOT include an

ReplacementText:

   If the "Subscription-State" value is "terminated", the subscriber
   MUST consider the subscription terminated.  The "expires" parameter
   has no semantics for "terminated" **state**. Notifiers SHOULD NOT
include an
-----------------------------------------------------

CurrentText:
   deactivated:  The subscription has been terminated, but the
      subscriber SHOULD retry immediately with a new subscription.  One

ReplacementText:
   deactivated:  The subscription has been terminated, but the
      subscriber SHOULD retry with a new subscription.  One

   Is It mandatory to resubscribe immediately. if not remove the word
"immediately".
   If it is delayed, what are the consequences ????

-----------------------------------------------------
4.2.1.  Subscription Establishment and Maintenance

CurrentText:
      inability to signal the success of a REFER request while signaling
      a problem with the subscription; and difficulty performing one
      action without the other.  Additionally, the proper exchange of

ReplacementText:
      inability to signal the success of a REFER request while signaling
      a problem with the subscription; and difficulty **in** performing one
      action without the other.  Additionally, the proper exchange of

-----------------------------------------------------
4.2.1.4.  Refreshing of Subscriptions

CurrentText:
   If no refresh for a notification address is received before its
   expiration time, the subscription is removed.  When removing a

ReplacementText:
   If no refresh for a notification is received before its
   expiration time, the subscription is removed.  When removing a
 Comment: Word "address" needs to be removed.
-----------------------------------------------------
4.3.  Proxy Behavior

CurrentText:
   Proxies that did not add a Record-Route header field to the initial
   SUBSCRIBE request MUST NOT add a Record-Route header field to any of
   the associated NOTIFY requests.

ReplacementText:
   Proxies that did not add a Record-Route header field to the initial
   SUBSCRIBE request MUST NOT add a Record-Route header field to any of
   the associated NOTIFY requests **or any SUBSCRIBE refresh requests**.
-----------------------------------------------------
4.4.1.  Dialog Creation and Termination

CurrentText:

      A subscriber may send a SUBSCRIBE request with an "Expires" header
      field of 0 in order to trigger the sending of such a NOTIFY
      request; however, for the purposes of subscription and dialog
      lifetime, the subscription is not considered terminated until the
      NOTIFY transaction with a "Subscription-State" of "terminated"
      completes.

Comment:
We may have to mention how long the dialog must be kept alive, before
 being cleaned up. Do we delete the dialog immediately after 200-SUB
or wait till NOTIFY with "Subscription-State"="terminated". If we always
 wait till Last Notify for dialog termination, then 200-SUB don't have any
impact on the dialog termination. Atleast some normative text is of
 necessity, for better understanding of the topic.
-----------------------------------------------------
4.4.3.  Polling Resource State

CurrentText:

   Note that the NOTIFY requests triggered by SUBSCRIBE requests with
   "Expires" header fields of 0 will contain a "Subscription-State"
   value of "terminated", and a "reason" parameter of "timeout".

ReplacementText:
   Note that the NOTIFY requests triggered by SUBSCRIBE requests with
   "Expires" header fields of 0 **shall** contain a "Subscription-State"
   value of "terminated", and a "reason" parameter of "timeout".
-----------------------------------------------------
4.5.2.  Sharing Dialogs

CurrentText:
      for a dialog (e.g., route set handling).  In particular, multiple
      subscriptions within a dialog are expire independently, and
      require independent subscription refreshes.

ReplacementText:
      for a dialog (e.g., route set handling).  In particular, multiple
      subscriptions within a dialog **operates** independently, and
      require independent subscription refreshes.
-----------------------------------------------------
4.5.2.  Sharing Dialogs

CurrentText:
   o  Subscribers MAY include an "id" parameter in SUBSCRIBE request
      "Event" header field to allow differentiation between multiple

ReplacementText:
   o  Subscribers MAY include an "id" parameter in SUBSCRIBE **request's**
      "Event" header field to allow differentiation between multiple
OR
   o  Subscribers MAY include an "id" parameter in **"Event" header field
      of SUBSCRIBE request** to allow differentiation between multiple
-----------------------------------------------------
4.5.2.  Sharing Dialogs

CurrentText:
   o  When a subscriber refreshes a the subscription timer, the
      SUBSCRIBE request MUST contain the same "Event" header field "id"
      parameter as was present in the SUBSCRIBE request that created the
      subscription.  (Otherwise, the notifier will interpret the

ReplacementText:
   o  When a subscriber refreshes a the subscription timer, the
      SUBSCRIBE request MUST contain the same **"id" parameter in "Event"
      header field, which** was present in the SUBSCRIBE request that
created the
      subscription.  (Otherwise, the notifier will interpret the
-----------------------------------------------------
4.5.2.  Sharing Dialogs

CurrentText:

   o  When a subscription is created in the notifier, it stores any
      "Event" header field "id" parameter as part of the subscription
      information (along with the event package name).

ReplacementText:
   o  When a subscription is created in the notifier, it stores **the**
      **"id" parameter in "Event" header field** as part of the subscription
      information (along with the event package name).
-----------------------------------------------------
4.6.  CANCEL Requests for SUBSCRIBE and NOTIFY Transactions

CurrentText:

   Neither SUBSCRIBE nor NOTIFY requests can be canceled.  If a UAS
   receives a CANCEL request that matches a known SUBSCRIBE or NOTIFY
   transaction, it MUST respond to the CANCEL request, but otherwise
   ignore it.  In particular, the CANCEL request MUST NOT affect
   processing of the SUBSCRIBE or NOTIFY request in any way.

ReplacementText/Comment:
What should be the response code for the CANCEL's reply ???
 Preferably 200-OK shall be used.
-----------------------------------------------------
4.6.  CANCEL Requests for SUBSCRIBE and NOTIFY Transactions

CurrentText:

   UACs SHOULD NOT send CANCEL requests for SUBSCRIBE or NOTIFY
   transactions.

ReplacementText:
   UACs **MUST** NOT send CANCEL requests for SUBSCRIBE or NOTIFY
   transactions. **UASs SHOULD send 200OK for CANCEL within NOTIFY
   or SUBSCRIBE transaction duration. As per sec 9 of [RFC3261]**
-----------------------------------------------------
5.3.2.  State Deltas

CurrentText:

   In the case that the state information to be conveyed is large, the
   event package may choose to detail a scheme by which NOTIFY requests
   contain state deltas instead of complete state.


ReplacementText:
   In the case that the state information to be conveyed is large, the
   event package may choose a scheme by which NOTIFY requests
   contain state deltas instead of complete state.

comment: deleted words "to detail" in 2nd line.

-----------------------------------------------------
5.3.2.  State Deltas

CurrentText:

   If a NOTIFY request arrives that has a version number that is
   incremented by more than one, the subscriber knows that a state delta
   has been missed; it ignores the NOTIFY request containing the state
   delta (except for the version number, which it retains to detect
   message loss), and re-sends a SUBSCRIBE request to force a NOTIFY
   request containing a complete state snapshot.

Comment:
   From this text, it infers that if any state delta lost, then subscriber
   sends refresh SUBSCRIBE (re-SUBSCRIBE) request. This re-SUBSCRIBE
request inturn lead
   to fetching the complete state information.

   It may be a good diea to differentiate the re-SUBSCRIBE triggered by
different scenarios.
   a) natural re-SUBSCRIBE request, which extends the SUBSCRIBE duration.
In this
      case it is *not *necessary to fetch the complete state information
   b) re-SUBSCRIBE triggered because of lost NOTIFY request (ref sec 5.3.2.
      VERSION number in received NOTIFY is increased by greater than ONE).
      In this case subscriber wants to fetch the complete state information.

   If we don't differentiate these two cases, then natural re-SUBSCRIBE
request
   unnecessarily fetch the complete state information, which may not be
necessary / expected.
   But uses higher network bandwidth to fetch the complete state
information.
-----------------------------------------------------
5.4.7.  Notifier generation of NOTIFY requests

CurrentText:
   This section may optionally describe the behavior used to process the
   subsequent response.

Comment:
   In this section 5.4.7, the above statement is not clear, what is really
meant to be.

-----------------------------------------------------
5.4.13.  Use of URIs to Retrieve State

CurrentText:

ReplacementText:
   In this context, I feel Use of "URLs" is more appropriate than "URIs".
-----------------------------------------------------


Thanks,
Nataraju A.B.
E-ID : nataraju.ab@gmail.com / nataraju.sip@gmail.com
+91-98455-95744

--f46d0430855a93ad1604bd92b957
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Adam,

Please find some editorial comments on =
the draft "draft=A0draft-ietf-sipcore-rfc3265bis-08.txt"





For simplicity, I have mentioned =
both the current text and proposed text.

The comments / correct=
ive text can be found with prefix and suffix =A0--- **





-----------------------------------------------------
1.1. =A0Overview of Operation
CurrentText:



=A0 =A0The general concept is that entities in=
 the network can subscribe to


=A0 =A0resource or call state for various reso=
urces or calls in the network,
=A0=
 =A0and those entities (or entities acting on their behalf) can send=



=A0 =A0notifications when those states change.



ReplacementText:
=A0 =A0The general concept is that entities in the=
 network can subscribe to
=A0 =A0r=
esource or call state **at / of** various resources or calls in the network=
,



=A0 =A0and those entities (or entities acting =
on their behalf) **who** can send


=A0 =A0notifications when those states change.=

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



1.1. =A0Overview of Operation

CurrentTe=
xt:
=A0 =A0Subscriptions are expir=
ed and must be refreshed by subsequent




=A0 =A0SUBSCRIBE requests.

Replace=
mentText:
=A0 =A0Subscriptions are=
 expired and must be refreshed by subsequent



=A0 =A0SUBSCRIBE requests **before expiration*=
*.
-------------------------------=
----------------------



=
2. =A0Definitions

CurrentText:
=A0 =A0Subscriber: =A0A subscriber is a user agent which receives =
NOTIFY



=A0 =A0 =A0 requests from notifiers; these NOT=
IFY requests contain information


=A0 =A0 =A0 about the state of a resource in w=
hich the subscriber is
=A0 =A0 =A0=
 interested. =A0Subscribers typically also generate SUBSCRIBE
<=
div>=A0 =A0 =A0 requests and send them to notifiers=
 to create subscriptions.





=
Comment:
	After this information, we can add a normative text whi=
ch indicates=A0



	w=
hen a SIP entity might get NOTIFY messages without actually=A0


	s=
ending SUBSCRIBE request. For example, REFER request might end up with=A0
	implicit subscription. Also mention any other requests which may =
lead to=A0




	i=
mplicit subscriptions (other than REFER).
-----------------------------------------------------
<=
div>

2. =A0Definitions


CurrentText:
=A0 =A0Subscription: =
=A0A subscription is a set of application state
=A0 =A0 =A0 associated with a dialog. =A0This application sta=
te includes a



=A0 =A0 =A0 pointer to the associated dialog, =
the event package name, and


=A0 =A0 =A0 possibly an identification token. =
=A0Event packages will define
=A0 =
=A0 =A0 additional subscription state information. =A0By definition,=

=A0 =A0 =A0 subscriptions exist in both =
a subscriber and a notifier.





=
ReplacementText:
=A0 =A0Subscripti=
on: =A0A subscription is a set of application **states**
<=
font color=3D"#000099">=A0 =A0 =A0 associated with a dialog. =A0**The** app=
lication state includes a



=A0 =A0 =A0 pointer to the associated dialog, =
the event package name, and


=A0 =A0 =A0 possibly an identification token. =
=A0Event packages will define
=A0 =
=A0 =A0 additional subscription state information. =A0By definition,=

=A0 =A0 =A0 subscriptions exist in both =
a subscriber and a notifier.




----------------------------------------------=
-------
3.1.1. =A0Subscription Dur=
ation

CurrentText:




=
=A0 =A0subscription. =A0In order to keep subscriptions effective beyond the=



=A0 =A0duration communicated in the "Expi=
res" header field, subscribers need
=A0 =A0to refresh subscriptions on a periodic basis using a new SUBS=
CRIBE



=A0 =A0request on the same dialog as defined i=
n [RFC3261].



=
ReplacementText
3.1.1. =A0Subscrip=
tion Duration

=A0 =A0subscription. =A0In order to keep subscrip=
tions effective beyond the



=A0 =A0duration communicated in the "Expi=
res" header field, subscribers need


=A0 =A0to refresh subscriptions **before expir=
ation** on a periodic basis using a new SUBSCRIBE
=A0 =A0request on the same dialog as defined in [RFC3261].<=
/font>



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


3.1.1. =A0Subscription Duration

Cu=
rrentText:
=A0 =A0 =A0 In addition=
 to being a request to unsubscribe, a SUBSCRIBE request



=A0 =A0 =A0 with "Expires" of 0 also=
 causes a fetch of state; see


=A0 =A0 =A0 Section 4.4.3.

Comment=
:
=A0 =A0 =A0The above text has be=
en mentioned to be normative text. But I feel this=A0



=A0 =A0 =A0shall be written as a regualr text =
in the draft/rfc. because this is the=A0


=A0 =A0 =A0expected behavior from the notifier=
.
--------------------------------=
---------------------
3.1.2. =A0Id=
entification of Subscribed Events and Event Classes




=
CurrentText:


=A0 =A0Subscribers MUST include exactly one &q=
uot;Event" header field in
=
=A0 =A0SUBSCRIBE requests, indicating to which event or class of events the=
y



=A0 =A0are subscribing. =A0The "Event&quo=
t; header field will contain a token which


=A0 =A0indicates the type of state for which a=
 subscription is being
=A0 =A0requ=
ested. =A0This token will be registered with the IANA and will
=

=A0 =A0correspond to an event package which fu=
rther describes the semantics




=A0 =A0of the event or event class.


ReplacementText:


=A0 =A0Subscribers MUST include exactly one "E=
vent" header field in
=A0 =A0=
SUBSCRIBE requests, indicating to which event or class of events they



=A0 =A0are subscribing. =A0The "Event&quo=
t; header field **MUST** contain a token which
=A0 =A0indicates the type of state for which a subscription is=
 being



=A0 =A0requested. =A0This token will be regist=
ered with the IANA and will


=A0 =A0correspond to an event package which fu=
rther describes the semantics
=A0 =
=A0of the event or event class.
--=
---------------------------------------------------



3.1. =A0SUBSCRIBE



CurrentText:
=A0 =A0The SUBSCRIBE method is used to request current=
 state and state
=A0 =A0updates fr=
om a remote node. =A0SUBSCRIBE requests are target refresh




=


ReplacementText:
=A0 =A0The SUBSCR=
IBE method is used to request current state and **subsequent** state=

=A0 =A0updates from a remote node. =A0SU=
BSCRIBE requests are target refresh




=



----------------------------------------------=
-------
3.1.1. =A0Subscription Dur=
ation

CurrentText:




=
=A0 =A0SUBSCRIBE requests SHOULD contain an "Expires" header fiel=
d (defined


=A0 =A0in [RFC3261]). =A0This expires value in=
dicates the duration of the
=A0 =
=A0subscription. =A0In order to keep subscriptions effective beyond the


=A0 =A0duration communicated in the "Expires&q=
uot; header field, subscribers need


=A0 =A0to refresh subscriptions on a periodic =
basis using a new SUBSCRIBE
=A0 =
=A0request on the same dialog as defined in [RFC3261].




Comment:
	We can add a =
normative text saying, the refresh time will be


	n=
ormally 50% to 75% of subscription duration.

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



3.2.1.=A0



CurrentText:
=A0 =A0This body will contain either the state of the =
subscribed resource or
=A0 =A0a po=
inter to such state in the form of a URI (see Section 5.4.13).




=
ReplacementText/Comment:


=A0 =A0This body **SHALL** contain either the =
state of the subscribed resource or
=A0 =A0a pointer to such state in the form of a **URL** (see Section 5.4.=
13).



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


4.1.2. =A0Creating and Maintaining Subscriptio=
ns


CurrentText:




=
=A0 =A0From the subscriber's perspective, a subscription proceeds accor=
ding
=A0 =A0to the following state=
 diagram:





=
Comment:
	Here it is better to mention, what happens to FSM when =
200-SUBSCRIBE=A0



	r=
eceived in notify_wait state (because very often this is possible).<=
/div>

	I=
f no change in state of FSM, then some normative text shall convey the same=
.
=A0 =A0 =A0 =A0 It may be no-ope=
ration, but better to mention the same.



----------------------------------------------=
-------
4.1.2.1. =A0Requesting a S=
ubscription



=
CurrentText:
=A0 =A0When a subscri=
ber wishes to subscribe to a particular state for a
=A0 =A0resource, it forms a SUBSCRIBE request. =A0If the =
initial SUBSCRIBE




=
ReplacementText:


=A0 =A0When a subscriber wishes to subscribe t=
o a particular state **of** a
=A0 =
=A0resource, it forms a SUBSCRIBE request **according to sec 3.1 and send i=
t across to notifier**. =A0If the initial SUBSCRIBE





-----=
------------------------------------------------
4.1.2.1. =A0Requesting a Subscription




CurrentText:
=A0 =A0[RFC3261]. =A0For the sake of clarity: if a SUB=
SCRIBE request contains


=A0 =A0an "Accept" header field, but=
 that field does not indicate a media
=A0 =A0type that the notifier is capable of generating in its NOTIFY



=A0 =A0requests, then the proper error respons=
e is 406 (Not Acceptable).



=
COMMENT:
	It is better to mention it as a normative text (indente=
d).




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


4.1.3. =A0Receiving and Processing State Infor=
mation

CurrentText:



=A0 =A0If the "Subscription-State" v=
alue is "terminated", the subscriber
=A0 =A0MUST consider the subscription terminated. =A0The "=
;expires" parameter




=A0 =A0has no semantics for "terminated&q=
uot; -- notifiers SHOULD NOT include an

ReplacementText:=





=
=A0 =A0If the "Subscription-State" value is "terminated"=
;, the subscriber


=A0 =A0MUST consider the subscription terminat=
ed. =A0The "expires" parameter
=A0 =A0has no semantics for "terminated" **state**. Notifi=
ers SHOULD NOT include an



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



=
CurrentText:
=A0 =A0deactivated: =
=A0The subscription has been terminated, but the
=A0 =A0 =A0 subscriber SHOULD retry immediately with a new s=
ubscription. =A0One




=
ReplacementText:


=A0 =A0deactivated: =A0The subscription has be=
en terminated, but the
=A0 =A0 =A0=
 subscriber SHOULD retry with a new subscription. =A0One
<=
font color=3D"#000099">



=A0 =A0Is It mandatory to resubsc=
ribe immediately. if not remove the word "immediately".

=A0 =A0If it is delayed, what are the conseque=
nces ????

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




4.2.1. =A0Subscription Establishment and Maint=
enance

CurrentText:
=
=A0 =A0 =A0 inability to signal the success of a REFER request while signal=
ing




=A0 =A0 =A0 a problem with the subscription; a=
nd difficulty performing one
=A0 =
=A0 =A0 action without the other. =A0Additionally, the proper exchange of



Repla=
cementText:
=A0 =A0 =A0 inability =
to signal the success of a REFER request while signaling


=A0 =A0 =A0 a problem with the subscription; a=
nd difficulty **in** performing one
=A0 =A0 =A0 action without the other. =A0Additionally, the proper exchang=
e of




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


4.2.1.4. =A0Refreshing of Subscriptions=


CurrentText:
=A0 =A0If no re=
fresh for a notification address is received before its



=A0 =A0expiration time, the subscription is re=
moved. =A0When removing a



=
ReplacementText:
=A0 =A0If no refr=
esh for a notification is received before its
=A0 =A0expiration time, the subscription is removed. =A0When r=
emoving a



	<=
/span>


Comment:	=
Word "address" needs to be removed.
-----------------------------------------------------



4.3. =A0Proxy Behavior


Curre=
ntText:
=A0 =A0Proxies that did no=
t add a Record-Route header field to the initial
=A0 =A0SUBSCRIBE request MUST NOT add a Record-Route header =
field to any of



=A0 =A0the associated NOTIFY requests.<=
/div>


=
ReplacementText:
=A0 =A0Proxies th=
at did not add a Record-Route header field to the initial
=
=A0 =A0SUBSCRIBE request MUST NOT add a Record-Rout=
e header field to any of



=A0 =A0the associated NOTIFY requests **or any=
 SUBSCRIBE refresh requests**.


----------------------------------------------=
-------
4.4.1. =A0Dialog Creation =
and Termination

<=
div>

CurrentText:

=A0 =A0 =A0 A subscriber m=
ay send a SUBSCRIBE request with an "Expires" header


=A0 =A0 =A0 field of 0 in order to trigger the=
 sending of such a NOTIFY
=A0 =A0 =
=A0 request; however, for the purposes of subscription and dialog
=A0 =A0 =A0 lifetime, the subscription is n=
ot considered terminated until the




=A0 =A0 =A0 NOTIFY transaction with a "Su=
bscription-State" of "terminated"
=A0 =A0 =A0 completes.




Comment:
	We may have to mention how=
 long the dialog must be kept alive, before=A0


	b=
eing cleaned up. Do we delete the dialog immediately after 200-SUB=A0
	<=
/span>or wait till NOTIFY with "Subscription-State"=3D"termi=
nated". If we always=A0




	w=
ait till Last Notify for dialog termination, then 200-SUB don't have an=
y=A0
	impact on the dialog termination. Atleast some normative te=
xt is of=A0




	n=
ecessity, for better understanding of the topic.
-----------------------------------------------------=




4.4.3. =A0Polling Resource State



=
CurrentText:

=A0 =A0Note that the NOTIFY requests triggered by =
SUBSCRIBE requests with



=A0 =A0"Expires" header fields of 0 =
will contain a "Subscription-State"


=A0 =A0value of "terminated", and a =
"reason" parameter of "timeout".

Replacemen=
tText:



=A0 =A0Note that the NOTIFY requests triggered=
 by SUBSCRIBE requests with


=A0 =A0"Expires" header fields of 0 =
**shall** contain a "Subscription-State"
=A0 =A0value of "terminated", and a "reason=
" parameter of "timeout".



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


4.5.2. =A0Sharing Dialogs

CurrentT=
ext:
=A0 =A0 =A0 for a dialog (e.g=
., route set handling). =A0In particular, multiple



=A0 =A0 =A0 subscriptions within a dialog are =
expire independently, and


=A0 =A0 =A0 require independent subscription r=
efreshes.

ReplacementText:
=A0 =A0 =A0 for a dialog (e.g., route set handling). =A0In particular,=
 multiple



=A0 =A0 =A0 subscriptions within a dialog **op=
erates** independently, and


=A0 =A0 =A0 require independent subscription r=
efreshes.
------------------------=
-----------------------------
4.5.=
2. =A0Sharing Dialogs




=
CurrentText:
=A0 =A0o =A0Subscribe=
rs MAY include an "id" parameter in SUBSCRIBE request

=A0 =A0 =A0 "Event" header field to =
allow differentiation between multiple

ReplacementText:<=
/div>


=A0 =A0o =A0Subscribers MAY include an "id&quo=
t; parameter in SUBSCRIBE **request's**


=A0 =A0 =A0 "Event" header field to =
allow differentiation between multiple
				OR
=A0 =A0o =A0Subscribers MAY include an "id"=
 parameter in **"Event" header field




=A0 =A0 =A0 of SUBSCRIBE request** to allow di=
fferentiation between multiple
---=
--------------------------------------------------
4.5.2. =A0Sharing Dialogs




=
CurrentText:

=A0 =A0o =A0When a subscriber refreshes a the subscription timer, the
=A0 =A0 =A0 SUBSCRIBE request MUST cont=
ain the same "Event" header field "id"
=A0 =A0 =A0 parameter as was present in the SUBSCR=
IBE request that created the




=A0 =A0 =A0 subscription. =A0(Otherwise, the n=
otifier will interpret the

ReplacementText:
=A0 =A0o =A0When a subscriber refreshes a the subscri=
ption timer, the



=A0 =A0 =A0 SUBSCRIBE request MUST contain the=
 same **"id" parameter in "Event"=A0


=A0 =A0 =A0 header field, which** was present =
in the SUBSCRIBE request that created the
=A0 =A0 =A0 subscription. =A0(Otherwise, the notifier will interpre=
t the



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


4.5.2. =A0Sharing Dialogs

CurrentT=
ext:

=A0 =A0o =A0When a subscription is created in the notifier=
, it stores any



=A0 =A0 =A0 "Event" header field &qu=
ot;id" parameter as part of the subscription


=A0 =A0 =A0 information (along with the event =
package name).

ReplacementText:
=A0 =A0o =A0When a subscription is created in the notifier, it st=
ores **the**



=A0 =A0 =A0 **"id" parameter in &quo=
t;Event" header field** as part of the subscription


=A0 =A0 =A0 information (along with the event =
package name).
-------------------=
----------------------------------
4.6. =A0CANCEL Requests for SUBSCRIBE and NOTIFY Transactions




=
CurrentText:



=
=A0 =A0Neither SUBSCRIBE nor NOTIFY requests can be canceled. =A0If a UAS
=A0 =A0receives a CANCEL request th=
at matches a known SUBSCRIBE or NOTIFY



=A0 =A0transaction, it MUST respond to the CAN=
CEL request, but otherwise


=A0 =A0ignore it. =A0In particular, the CANCEL=
 request MUST NOT affect
=A0 =A0pr=
ocessing of the SUBSCRIBE or NOTIFY request in any way.




ReplacementText/Comment:
	What should be the response code for the CANCEL's reply ???



	P=
referably 200-OK shall be used.
--=
---------------------------------------------------
4.6. =A0CANCEL Requests for SUBSCRIBE and NOTIFY Transact=
ions





=
CurrentText:

=A0 =A0UACs SHOULD NOT send CANCEL requests for SU=
BSCRIBE or NOTIFY



=A0 =A0transactions.

ReplacementTe=
xt:
=A0 =A0UACs **MUST** NOT send =
CANCEL requests for SUBSCRIBE or NOTIFY




=A0 =A0transactions. **UASs SHOULD send 200OK =
for CANCEL within NOTIFY=A0
=A0 =
=A0or SUBSCRIBE transaction duration. As per sec 9 of [RFC3261]**
-------------------------------------------=
----------



5.3.2. =A0State Deltas



=
CurrentText:

=A0 =A0In the case that the state information to b=
e conveyed is large, the



=A0 =A0event package may choose to detail a sc=
heme by which NOTIFY requests

=A0 =A0contain state deltas instead of complete state.


ReplacementText:
=A0 =A0In the case that the state information to be co=
nveyed is large, the



=A0 =A0event package may choose a scheme by wh=
ich NOTIFY requests


=A0 =A0contain state deltas instead of complet=
e state.

comment:	d=
eleted words "to detail" in 2nd line.





-----------------------------------------------------
5.3.2. =A0State Deltas

CurrentText:<=
/div>



=
=A0 =A0If a NOTIFY request arrives that has a version number that is=


=A0 =A0incremented by more than one, the subscriber knows that a state delt=
a
=A0 =A0has been missed; it ignor=
es the NOTIFY request containing the state
=A0 =A0delta (except for the version number, which it retains to d=
etect




=A0 =A0message loss), and re-sends a SUBSCRIBE=
 request to force a NOTIFY
=A0 =A0=
request containing a complete state snapshot.




Comment:
=A0 =A0From this text, it infers that if any state delta l=
ost, then subscriber=A0


=A0 =A0sends refresh SUBSCRIBE (re-SUBSCRIBE) =
request. This re-SUBSCRIBE request inturn lead=A0
=A0 =A0to fetching the complete state information.=A0



=A0 =
=A0It may be a good diea to differentiate the re-SUBSCRIBE triggered by dif=
ferent scenarios.


=A0 =A0a) natural re-SUBSCRIBE request, which =
extends the SUBSCRIBE duration. In this=A0
=A0 =A0 =A0 case it is not necessary to fetch the complete =
state information



=A0 =A0b) re-SUBSCRIBE triggered because of lo=
st NOTIFY request (ref sec 5.3.2.=A0


=A0 =A0 =A0 VERSION number in received NOTIFY =
is increased by greater than ONE).=A0
=A0 =A0 =A0 In this case subscriber wants to fetch the complete state i=
nformation.




=
=A0 =A0If we don't differentiate these two cases, then natural re-SUBSC=
RIBE request


=A0 =A0unnecessarily fetch the complete state =
information, which may not be necessary / expected.=A0
=A0 =A0But uses higher network bandwidth to fetch the =
complete state information.



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


5.4.7. =A0Notifier generation of NOTIFY reques=
ts

CurrentText:
=A0 =
=A0This section may optionally describe the behavior used to process the



=A0 =A0subsequent response.
<=
font color=3D"#000099">


Comment:
=A0 =A0In this section 5.4.7, the above statement is not c=
lear, what is really meant to be.
=




----------------------------------------------=
-------
5.4.13. =A0Use of URIs to =
Retrieve State



=
CurrentText:

ReplacementText:
=A0 =A0In this context, I feel Use of "URLs" is more appr=
opriate than "URIs".=A0



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




Thanks,
Nataraju A.B.







+91-98455-95744



--f46d0430855a93ad1604bd92b957--

From ibc@aliax.net  Mon Apr 16 09:49:59 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAD911E80D3 for ; Mon, 16 Apr 2012 09:49:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.625
X-Spam-Level: 
X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=0.052,  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 30TjMCQQd7Wf for ; Mon, 16 Apr 2012 09:49:59 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5055511E80CA for ; Mon, 16 Apr 2012 09:49:59 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so4154488vbb.31 for ; Mon, 16 Apr 2012 09:49:58 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=1VkGgffIBEId0UwYuCJ8LvgWejI4+PfqTLGknnL555c=; b=D5AdjYXHum3qWWJNGk7osXJFtNVrul++LPWXQshJNlVGV7YTyAqXdP5DxR9lGiFwAw 2KPMXrCTA5QW1CvTQeuaj2gPL8F2PAAeoL+GdXEElDabCa6LzkRWVBJP24/uHvAd1Oky pwN4DUDy6bPiwqBhPyz8aVo4Fuz+DQSAguKBKmFy53AhdwWpXJulFC9sUtwHupfvg9bW KIBRuXOiU2rVM5apljOHHqT6S74dKvhRHmuYEuMwGCWLh4ZvrKBkdq/JdQbIfUY5CAck AR3f5B7kOwoZcykGrcXbZqB3Ju4RFl3N2yOp4df823CHdPHNwJmTrVsabs/aUROEM6DP kntg==
Received: by 10.52.91.72 with SMTP id cc8mr5772980vdb.17.1334594998820; Mon, 16 Apr 2012 09:49:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Mon, 16 Apr 2012 09:49:38 -0700 (PDT)
In-Reply-To: <20120416163812.5336.94632.idtracker@ietfa.amsl.com>
References: <20120416163812.5336.94632.idtracker@ietfa.amsl.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 16 Apr 2012 18:49:38 +0200
Message-ID: 
To: SIPCORE WG 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmYkBBGaWF6aPxwhYiBveSOTEfVZ6t0hSj5VYoTAwaVTOAOEz04Pejat/giLqbdlb89EpY+
Subject: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-02.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2012 16:50:00 -0000

A new version of I-D, draft-ibc-sipcore-sip-websocket-02.txt has been
successfully submitted by I=C3=B1aki Baz Castillo and posted to the IETF
repository.

Filename: =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ibc-sipcore-sip-websocket
Revision: =C2=A0 =C2=A0 =C2=A0 =C2=A002
Title: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The WebSocket Protocol as a Trans=
port for the Session
Initiation Protocol (SIP)
Creation date: =C2=A0 2012-04-16
WG ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Number of pages: 20

Abstract:
=C2=A0 The WebSocket protocol enables two-way realtime communication betwee=
n
=C2=A0 clients and servers. =C2=A0This document specifies a new WebSocket s=
ub-
=C2=A0 protocol as a reliable transport mechanism between SIP (Session
=C2=A0 Initiation Protocol) entities and enables usage of the SIP protocol
=C2=A0 in new scenarios.


- http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02
- http://tools.ietf.org/id/draft-ibc-sipcore-sip-websocket-02.txt


This new version incorporates improvements and changes based on the
comments and reviews on the previous version, along with the consensus
got in IETF 83 Paris.


As usual, comments are welcome. Thanks a lot.


--=20
I=C3=B1aki Baz Castillo


From adam@nostrum.com  Mon Apr 16 11:02:48 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6123821F8638 for ; Mon, 16 Apr 2012 11:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.488
X-Spam-Level: 
X-Spam-Status: No, score=-102.488 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, SPF_PASS=-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 PQHKhmVv3mS0 for ; Mon, 16 Apr 2012 11:02:47 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4E78621F8642 for ; Mon, 16 Apr 2012 11:02:47 -0700 (PDT)
Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q3GI2koM097015 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 16 Apr 2012 13:02:46 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4F8C5EC6.8090202@nostrum.com>
Date: Mon, 16 Apr 2012 13:02:46 -0500
From: Adam Roach - SIPCORE Chair 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "SIPCORE (Session Initiation Protocol Core) WG" 
References: 
In-Reply-To: 
X-Forwarded-Message-Id: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Subject: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: SIPCORE Chairs 
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2012 18:02:48 -0000

[as chair]

SIPCORE Working Group:

This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02 
document to satisfy our recently added milestone to define a WebSockets 
transport for the SIP protocol. Interested parties should voice their 
support and/or concerns on the SIPCORE mailing list. The chairs plan to 
make a determination of consensus on Friday, April 27th.

Thank you. The draft announcement follows.

/a

-------- Original Message --------
Subject: [sipcore] New Version Notification for 
draft-ibc-sipcore-sip-websocket-02.txt
Date: Mon, 16 Apr 2012 18:49:38 +0200
From: IƱaki Baz Castillo 
To: SIPCORE WG 

A new version of I-D, draft-ibc-sipcore-sip-websocket-02.txt has been
successfully submitted by IƱaki Baz Castillo and posted to the IETF
repository.

Filename:        draft-ibc-sipcore-sip-websocket
Revision:        02
Title:           The WebSocket Protocol as a Transport for the Session
Initiation Protocol (SIP)
Creation date:   2012-04-16
WG ID:           Individual Submission
Number of pages: 20

Abstract:
   The WebSocket protocol enables two-way realtime communication between
   clients and servers.  This document specifies a new WebSocket sub-
   protocol as a reliable transport mechanism between SIP (Session
   Initiation Protocol) entities and enables usage of the SIP protocol
   in new scenarios.


- http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02
- http://tools.ietf.org/id/draft-ibc-sipcore-sip-websocket-02.txt


This new version incorporates improvements and changes based on the
comments and reviews on the previous version, along with the consensus
got in IETF 83 Paris.


As usual, comments are welcome. Thanks a lot.


-- 
IƱaki Baz Castillo

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

From vkg@bell-labs.com  Mon Apr 16 11:04:57 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B239E21F8658 for ; Mon, 16 Apr 2012 11:04:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.266
X-Spam-Level: 
X-Spam-Status: No, score=-109.266 tagged_above=-999 required=5 tests=[AWL=1.333, 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 FfBLh+6vYxef for ; Mon, 16 Apr 2012 11:04:56 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id BFE8B21F8642 for ; Mon, 16 Apr 2012 11:04:56 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q3GI4tvI016197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 16 Apr 2012 13:04:56 -0500 (CDT)
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 q3GI4tZb019327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 16 Apr 2012 13:04:55 -0500
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 q3GI4teV009534 for ; Mon, 16 Apr 2012 13:04:55 -0500 (CDT)
Message-ID: <4F8C6073.1070001@bell-labs.com>
Date: Mon, 16 Apr 2012 13:09:55 -0500
From: "Vijay K. Gurbani" 
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1
MIME-Version: 1.0
To: sipcore@ietf.org
References:  <4F8C5EC6.8090202@nostrum.com>
In-Reply-To: <4F8C5EC6.8090202@nostrum.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: Re: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2012 18:04:57 -0000

On 04/16/2012 01:02 PM, Adam Roach - SIPCORE Chair wrote:
> [as chair]
>
> SIPCORE Working Group:
>
> This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02
> document to satisfy our recently added milestone to define a WebSockets
> transport for the SIP protocol. Interested parties should voice their
> support and/or concerns on the SIPCORE mailing list. The chairs plan to
> make a determination of consensus on Friday, April 27th.

I support adoption of draft-ibc-sip-websocket-02 to satisfy the newly
added milestone.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/

From gsalguei@cisco.com  Mon Apr 16 11:14:13 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4338211E80D0 for ; Mon, 16 Apr 2012 11:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.499
X-Spam-Level: 
X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, 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 AJEIb375kdUJ for ; Mon, 16 Apr 2012 11:14:12 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by ietfa.amsl.com (Postfix) with ESMTP id 83AD911E80AB for ; Mon, 16 Apr 2012 11:14:12 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3GIEBn1019964 for ; Mon, 16 Apr 2012 14:14:11 -0400 (EDT)
Received: from dhcp-64-102-210-169.cisco.com (dhcp-64-102-210-169.cisco.com [64.102.210.169]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id q3GIEBPR001258 for ; Mon, 16 Apr 2012 14:14:11 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1257)
From: Gonzalo Salgueiro 
In-Reply-To: <4F8C6073.1070001@bell-labs.com>
Date: Mon, 16 Apr 2012 14:14:11 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <4F8C5EC6.8090202@nostrum.com> <4F8C6073.1070001@bell-labs.com>
To: sipcore@ietf.org
X-Mailer: Apple Mail (2.1257)
Subject: Re: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2012 18:14:13 -0000

+1 on draft-ibc-sip-websocket-02 being adopted as WG item to address =
WebSockets milestone

--G


On Apr 16, 2012, at 2:09 PM, Vijay K. Gurbani wrote:

> On 04/16/2012 01:02 PM, Adam Roach - SIPCORE Chair wrote:
>> [as chair]
>>=20
>> SIPCORE Working Group:
>>=20
>> This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02
>> document to satisfy our recently added milestone to define a =
WebSockets
>> transport for the SIP protocol. Interested parties should voice their
>> support and/or concerns on the SIPCORE mailing list. The chairs plan =
to
>> make a determination of consensus on Friday, April 27th.
>=20
> I support adoption of draft-ibc-sip-websocket-02 to satisfy the newly
> added milestone.
>=20
> Thanks,
>=20
> - vijay
> --=20
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>=20


From salvatore.loreto@ericsson.com  Mon Apr 16 11:15:48 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E50311E8093 for ; Mon, 16 Apr 2012 11:15:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.735
X-Spam-Level: 
X-Spam-Status: No, score=-106.735 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 3BJK6DLUpNFt for ; Mon, 16 Apr 2012 11:15:47 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 84D4311E8086 for ; Mon, 16 Apr 2012 11:15:47 -0700 (PDT)
X-AuditID: c1b4fb2d-b7b76ae0000063d8-fe-4f8c61d13f93
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 47.6A.25560.1D16C8F4; Mon, 16 Apr 2012 20:15:45 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Mon, 16 Apr 2012 20:15:45 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 4D1712323	for ; Mon, 16 Apr 2012 21:15:45 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 40F0E52810	for ; Mon, 16 Apr 2012 21:15:45 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C65AA52672	for ; Mon, 16 Apr 2012 21:15:44 +0300 (EEST)
Message-ID: <4F8C61CF.9020907@ericsson.com>
Date: Mon, 16 Apr 2012 20:15:43 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: sipcore@ietf.org
References:  <4F8C5EC6.8090202@nostrum.com> <4F8C6073.1070001@bell-labs.com> 
In-Reply-To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2012 18:15:48 -0000

+1

On 4/16/12 8:14 PM, Gonzalo Salgueiro wrote:
> +1 on draft-ibc-sip-websocket-02 being adopted as WG item to address WebSockets milestone
>
> --G
>
>
> On Apr 16, 2012, at 2:09 PM, Vijay K. Gurbani wrote:
>
>> On 04/16/2012 01:02 PM, Adam Roach - SIPCORE Chair wrote:
>>> [as chair]
>>>
>>> SIPCORE Working Group:
>>>
>>> This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02
>>> document to satisfy our recently added milestone to define a WebSockets
>>> transport for the SIP protocol. Interested parties should voice their
>>> support and/or concerns on the SIPCORE mailing list. The chairs plan to
>>> make a determination of consensus on Friday, April 27th.
>> I support adoption of draft-ibc-sip-websocket-02 to satisfy the newly
>> added milestone.
>>
>> Thanks,
>>
>> - vijay
>> -- 
>> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
>> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
>> Web:   http://ect.bell-labs.com/who/vkg/
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore



From christer.holmberg@ericsson.com  Mon Apr 16 11:34:55 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8155721F85B9 for ; Mon, 16 Apr 2012 11:34:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.285
X-Spam-Level: 
X-Spam-Status: No, score=-6.285 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 aqhitprC2YnN for ; Mon, 16 Apr 2012 11:34:52 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 435E121F85AF for ; Mon, 16 Apr 2012 11:34:52 -0700 (PDT)
X-AuditID: c1b4fb2d-b7b76ae0000063d8-a6-4f8c664b81b1
Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FC.2B.25560.B466C8F4; Mon, 16 Apr 2012 20:34:51 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 16 Apr 2012 20:34:50 +0200
From: Christer Holmberg 
To: 'SIPCORE Chairs' , "SIPCORE (Session Initiation Protocol Core) WG" 
Date: Mon, 16 Apr 2012 20:34:49 +0200
Thread-Topic: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02
Thread-Index: Ac0b+ydpDITCizWFQjC84auYkuOKFAABGFLA
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C429F5DBD@ESESSCMS0356.eemea.ericsson.se>
References:  <4F8C5EC6.8090202@nostrum.com>
In-Reply-To: <4F8C5EC6.8090202@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2012 18:34:55 -0000

I support adoption of the draft.

Regards,

Christer=20

-----Original Message-----
From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf =
Of Adam Roach - SIPCORE Chair
Sent: 16. huhtikuuta 2012 21:03
To: SIPCORE (Session Initiation Protocol Core) WG
Subject: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02

[as chair]

SIPCORE Working Group:

This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02
document to satisfy our recently added milestone to define a WebSockets tra=
nsport for the SIP protocol. Interested parties should voice their support =
and/or concerns on the SIPCORE mailing list. The chairs plan to make a dete=
rmination of consensus on Friday, April 27th.

Thank you. The draft announcement follows.

/a

-------- Original Message --------
Subject: [sipcore] New Version Notification for draft-ibc-sipcore-sip-webso=
cket-02.txt
Date: Mon, 16 Apr 2012 18:49:38 +0200
From: I=F1aki Baz Castillo 
To: SIPCORE WG 

A new version of I-D, draft-ibc-sipcore-sip-websocket-02.txt has been succe=
ssfully submitted by I=F1aki Baz Castillo and posted to the IETF repository=
.

Filename:        draft-ibc-sipcore-sip-websocket
Revision:        02
Title:           The WebSocket Protocol as a Transport for the Session
Initiation Protocol (SIP)
Creation date:   2012-04-16
WG ID:           Individual Submission
Number of pages: 20

Abstract:
   The WebSocket protocol enables two-way realtime communication between
   clients and servers.  This document specifies a new WebSocket sub-
   protocol as a reliable transport mechanism between SIP (Session
   Initiation Protocol) entities and enables usage of the SIP protocol
   in new scenarios.


- http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02
- http://tools.ietf.org/id/draft-ibc-sipcore-sip-websocket-02.txt


This new version incorporates improvements and changes based on the comment=
s and reviews on the previous version, along with the consensus got in IETF=
 83 Paris.


As usual, comments are welcome. Thanks a lot.


--
I=F1aki Baz Castillo

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

From kpfleming@digium.com  Mon Apr 16 11:46:38 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B1811E80B1 for ; Mon, 16 Apr 2012 11:46:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hR5vrOH4ECv for ; Mon, 16 Apr 2012 11:46:37 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7A11111E809A for ; Mon, 16 Apr 2012 11:46:37 -0700 (PDT)
Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SJqwe-0006SP-Rf for sipcore@ietf.org; Mon, 16 Apr 2012 13:46:36 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id C4E40D8002 for ; Mon, 16 Apr 2012 13:46:36 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPXwg9oOf4JL for ; Mon, 16 Apr 2012 13:46:36 -0500 (CDT)
Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 4FB24D8004 for ; Mon, 16 Apr 2012 13:46:36 -0500 (CDT)
Message-ID: <4F8C6909.6070808@digium.com>
Date: Mon, 16 Apr 2012 13:46:33 -0500
From: "Kevin P. Fleming" 
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1
MIME-Version: 1.0
To: sipcore@ietf.org
References:  <4F8C5EC6.8090202@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05852C429F5DBD@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C429F5DBD@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2012 18:46:38 -0000

On 04/16/2012 01:34 PM, Christer Holmberg wrote:
>
> I support adoption of the draft.

I also support adoption of the draft.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

From saul@ag-projects.com  Mon Apr 16 12:28:12 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E355E21F8554 for ; Mon, 16 Apr 2012 12:28:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Level: 
X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
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 SqQkrktYIjjd for ; Mon, 16 Apr 2012 12:28:12 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 19DA821F8550 for ; Mon, 16 Apr 2012 12:28:11 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 630ECB01B0; Mon, 16 Apr 2012 21:28:09 +0200 (CEST)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 530E1B019C; Mon, 16 Apr 2012 21:28:09 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
In-Reply-To: <4F8C5EC6.8090202@nostrum.com>
Date: Mon, 16 Apr 2012 21:28:08 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8333DB56-246B-4FA3-BC69-601A5064B8B3@ag-projects.com>
References:  <4F8C5EC6.8090202@nostrum.com>
To: SIPCORE Chairs 
X-Mailer: Apple Mail (2.1084)
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 16 Apr 2012 19:28:13 -0000

I do support the adoption of this draft.


Regards,

On Apr 16, 2012, at 8:02 PM, Adam Roach - SIPCORE Chair wrote:

> [as chair]
>=20
> SIPCORE Working Group:
>=20
> This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02 =
document to satisfy our recently added milestone to define a WebSockets =
transport for the SIP protocol. Interested parties should voice their =
support and/or concerns on the SIPCORE mailing list. The chairs plan to =
make a determination of consensus on Friday, April 27th.
>=20
> Thank you. The draft announcement follows.
>=20
> /a
>=20
> -------- Original Message --------
> Subject: [sipcore] New Version Notification for =
draft-ibc-sipcore-sip-websocket-02.txt
> Date: Mon, 16 Apr 2012 18:49:38 +0200
> From: I=F1aki Baz Castillo 
> To: SIPCORE WG 
>=20
> A new version of I-D, draft-ibc-sipcore-sip-websocket-02.txt has been
> successfully submitted by I=F1aki Baz Castillo and posted to the IETF
> repository.
>=20
> Filename:        draft-ibc-sipcore-sip-websocket
> Revision:        02
> Title:           The WebSocket Protocol as a Transport for the Session
> Initiation Protocol (SIP)
> Creation date:   2012-04-16
> WG ID:           Individual Submission
> Number of pages: 20
>=20
> Abstract:
>  The WebSocket protocol enables two-way realtime communication between
>  clients and servers.  This document specifies a new WebSocket sub-
>  protocol as a reliable transport mechanism between SIP (Session
>  Initiation Protocol) entities and enables usage of the SIP protocol
>  in new scenarios.
>=20
>=20
> - http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02
> - http://tools.ietf.org/id/draft-ibc-sipcore-sip-websocket-02.txt
>=20
>=20
> This new version incorporates improvements and changes based on the
> comments and reviews on the previous version, along with the consensus
> got in IETF 83 Paris.
>=20
>=20
> As usual, comments are welcome. Thanks a lot.
>=20
>=20
> --=20
> I=F1aki Baz Castillo
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From internet-drafts@ietf.org  Tue Apr 17 00:02:48 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB79B21F854B; Tue, 17 Apr 2012 00:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.507
X-Spam-Level: 
X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, 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 Q6doHa1BWoDx; Tue, 17 Apr 2012 00:02:44 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0A1321F84BF; Tue, 17 Apr 2012 00:02:43 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120417070243.32354.18655.idtracker@ietfa.amsl.com>
Date: Tue, 17 Apr 2012 00:02:43 -0700
Cc: sipcore@ietf.org
Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-01.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2012 07:02:49 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Session Initiation Protocol Core Work=
ing Group of the IETF.

	Title           : Indication of features supported by proxy
	Author(s)       : Christer Holmberg
                          Ivo Sedlacek
                          Hadriel Kaplan
	Filename        : draft-ietf-sipcore-proxy-feature-01.txt
	Pages           : 17
	Date            : 2012-04-17

   This specification creates a new IANA registry, "SIP Feature Cap
   Registry", which is used to register indicators, "SIP feature caps",
   used by SIP entities to indicate support of features and
   capabilities, in cases where the Contact header field contains a URI
   that does not represent the SIP entity that wants to indicate support
   of its features and capabilities.

   This specification also defines a new SIP header field, Feature-Caps,
   that can be used by SIP entities to convey information about
   supported features and capabilities, using SIP feature caps.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-proxy-feature-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-ietf-sipcore-proxy-feature-01.txt


From christer.holmberg@ericsson.com  Tue Apr 17 00:05:32 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DDFE21F8570 for ; Tue, 17 Apr 2012 00:05:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.28
X-Spam-Level: 
X-Spam-Status: No, score=-6.28 tagged_above=-999 required=5 tests=[AWL=-0.032,  BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 fD2vWfq6YFQK for ; Tue, 17 Apr 2012 00:05:32 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A34E621F856F for ; Tue, 17 Apr 2012 00:05:31 -0700 (PDT)
X-AuditID: c1b4fb25-b7b18ae000000dce-60-4f8d163964d5
Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0191"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0191", Issuer "esessmw0191" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 60.F6.03534.9361D8F4; Tue, 17 Apr 2012 09:05:30 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 17 Apr 2012 09:05:29 +0200
From: Christer Holmberg 
To: "sipcore@ietf.org" 
Date: Tue, 17 Apr 2012 09:05:26 +0200
Thread-Topic: Draft new version: draft-ietf-sipcore-proxy-feature-01
Thread-Index: Ac0caEiaRgfiaTJVS+GeAzxkM0LILw==
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C42DF52F5@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852C42DF52F5ESESSCMS0356e_"
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2012 07:05:32 -0000

--_000_7F2072F1E0DE894DA4B517B93C6A05852C42DF52F5ESESSCMS0356e_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I've submitted a new version (-01) of the proxy-feature draft.

Based on the discussions in Paris, instead of using feature tags the draft =
now creates a new IANA "feature cap" registry.

Regards,

Christer

--_000_7F2072F1E0DE894DA4B517B93C6A05852C42DF52F5ESESSCMS0356e_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


=
Hi,
 
I’ve submitted a new version (-01=
) of the proxy-feature draft.
 =
;
Based on the discussions in Paris, instead =
of using feature tags the draft now creates a new IANA “feature cap&#=
8221; registry.
 
Regards,
 
Christer
=

--_000_7F2072F1E0DE894DA4B517B93C6A05852C42DF52F5ESESSCMS0356e_--

From oej@edvina.net  Tue Apr 17 00:47:36 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E7021F8587 for ; Tue, 17 Apr 2012 00:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBSG5OcKoQpg for ; Tue, 17 Apr 2012 00:47:35 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id E70B921F855D for ; Tue, 17 Apr 2012 00:47:34 -0700 (PDT)
Received: from [192.168.40.89] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 5B0BF754A8AC; Tue, 17 Apr 2012 07:47:32 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=iso-8859-1
From: "Olle E. Johansson" 
In-Reply-To: <4F8C5EC6.8090202@nostrum.com>
Date: Tue, 17 Apr 2012 09:47:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F4F24F7-2894-433B-8E07-49B2F0C959AF@edvina.net>
References:  <4F8C5EC6.8090202@nostrum.com>
To: SIPCORE Chairs 
X-Mailer: Apple Mail (2.1257)
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2012 07:47:36 -0000

16 apr 2012 kl. 20:02 skrev Adam Roach - SIPCORE Chair:

> [as chair]
>=20
> SIPCORE Working Group:
>=20
> This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02 =
document to satisfy our recently added milestone to define a WebSockets =
transport for the SIP protocol. Interested parties should voice their =
support and/or concerns on the SIPCORE mailing list. The chairs plan to =
make a determination of consensus on Friday, April 27th.
I support adoption of this document.

/O
>=20
> Thank you. The draft announcement follows.
>=20
> /a
>=20
> -------- Original Message --------
> Subject: [sipcore] New Version Notification for =
draft-ibc-sipcore-sip-websocket-02.txt
> Date: Mon, 16 Apr 2012 18:49:38 +0200
> From: I=F1aki Baz Castillo 
> To: SIPCORE WG 
>=20
> A new version of I-D, draft-ibc-sipcore-sip-websocket-02.txt has been
> successfully submitted by I=F1aki Baz Castillo and posted to the IETF
> repository.
>=20
> Filename:        draft-ibc-sipcore-sip-websocket
> Revision:        02
> Title:           The WebSocket Protocol as a Transport for the Session
> Initiation Protocol (SIP)
> Creation date:   2012-04-16
> WG ID:           Individual Submission
> Number of pages: 20
>=20
> Abstract:
>  The WebSocket protocol enables two-way realtime communication between
>  clients and servers.  This document specifies a new WebSocket sub-
>  protocol as a reliable transport mechanism between SIP (Session
>  Initiation Protocol) entities and enables usage of the SIP protocol
>  in new scenarios.
>=20
>=20
> - http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02
> - http://tools.ietf.org/id/draft-ibc-sipcore-sip-websocket-02.txt
>=20
>=20
> This new version incorporates improvements and changes based on the
> comments and reviews on the previous version, along with the consensus
> got in IETF 83 Paris.
>=20
>=20
> As usual, comments are welcome. Thanks a lot.
>=20
>=20
> --=20
> I=F1aki Baz Castillo
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore

---
* Olle E Johansson - oej@edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden




From nataraju.sip@gmail.com  Tue Apr 17 09:46:30 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA87D11E8074 for ; Tue, 17 Apr 2012 09:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.17
X-Spam-Level: 
X-Spam-Status: No, score=-1.17 tagged_above=-999 required=5 tests=[AWL=0.644,  BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001,  J_CHICKENPOX_62=0.6, 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 eqfwgHphrZNr for ; Tue, 17 Apr 2012 09:46:26 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A0DB821F848A for ; Tue, 17 Apr 2012 09:46:25 -0700 (PDT)
Received: by lagj5 with SMTP id j5so5372945lag.31 for ; Tue, 17 Apr 2012 09:46:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=GbUdzzBuIAgsl40lHhD3m5l5WXX4lM+rkiPP0H5T9Uo=; b=msTA2Hf8fCTgzG5E9SdeGsn0ksKzKZmaIHRGlr52FGWFU7HrTRKDIn9TaiML0CJIlg z8CABd5YmioO+2WywMxvXw9+9VOxtGwZKiH4gsN9QgSPnu/g6uylP+iMVWDtzStJ9o01 9ffsy5Lov6itzkSs6w6alvB18wykdY7ppH3Ed+hlpkcg43az5COGx8/EoCXgMu4rDbNT 3XkVfLcrenNy1t2wdXdiLGR7fnm4U/riPEyMNtRmFpsvLuLVRmlK97CjWlmeIBK4L0uR Wgfb7r7BrpRcaxfyv0Oh/xOcgdZQTJvsAI0XUOPf5k4vwbt17Bt/X6cwktzlxq1Cxtts IKPQ==
MIME-Version: 1.0
Received: by 10.112.28.33 with SMTP id y1mr4693612lbg.81.1334681184462; Tue, 17 Apr 2012 09:46:24 -0700 (PDT)
Received: by 10.112.103.103 with HTTP; Tue, 17 Apr 2012 09:46:24 -0700 (PDT)
Date: Tue, 17 Apr 2012 22:16:24 +0530
Message-ID: 
From: "Nataraju A.B" 
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , jmillan@aliax.net,  vpascual@acmepacket.com, sipcore@ietf.org
Content-Type: multipart/alternative; boundary=bcaec554d9aae3688704bde2adcc
Subject: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - Review comments (Nataraju A B)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 17 Apr 2012 16:46:30 -0000

--bcaec554d9aae3688704bde2adcc
Content-Type: text/plain; charset=ISO-8859-1

Hi Authros,

Please find some comments on the draft
"draft-ibc-sipcore-sip-websocket-02.txt"

For simplicity, I have mentioned both the current text and proposed text.

The comments / corrective text can be found with prefix and suffix  --- **

-----------------------------------------------------
Section :  8.1.  Registration
CurrentText:
   Alice    (SIP WSS)    proxy.atlanta.com
   |                             |
   |REGISTER F1                  |
   |---------------------------->|
   |200 OK F2                    |
   |<----------------------------|
   |                             |

ReplacementText / Comment:

   Alice    (SIP WSS)    proxy.atlanta.com
   |                             |
   |                             |
   |WebSocket Con Req F1         |
   |---------------------------->|
   |WebSocket Con Reply F2       |
   |<----------------------------|
   |                             |
   |                             |
   |REGISTER F3                  |
   |---------------------------->|
   |200 OK F4                    |
   |<----------------------------|
   |                             |

   Prefixed the WebSocket connection request followed by SIP registrations.
   F1, F2 will be same messages mentioned in sec 4.1

-----------------------------------------------------
Section :  8.1.  Registration
CurrentText:
   F1 REGISTER  Alice -> proxy.atlanta.com (transport WSS)

   REGISTER sip:proxy.atlanta.com SIP/2.0
   Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf

   F2 200 OK  proxy.atlanta.com -> Alice (transport WSS)

   SIP/2.0 200 OK
   Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf

ReplacementText / Comment:

If I understand right,
          Websocket connection is mapped on to SIP URI  --> HTTP
   Secure Websocket connection is mapped on to SIPS URI --> HTTPS

HTTP --> WS --> SIP URI --> port 80

HTTPS --> WSS --> SIPS URI --> port 443

Hence in the following messages "WSS" shall be replaced with "WS"

   F1 REGISTER  Alice -> proxy.atlanta.com (transport WSS)

   REGISTER sip:proxy.atlanta.com SIP/2.0
   Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf

WSS --> WS

   F2 200 OK  proxy.atlanta.com -> Alice (transport WSS)

   SIP/2.0 200 OK
   Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf

WSS --> WS


Probably in the appendix A.2, we can list out the call flows for *""SECURE
WEB SOCKET"" (WSS)*

For example, REGISTER request looks like this (with WSS)...

   REGISTER sips:proxy.atlanta.com SIP/2.0
   Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf
   From: sips:alice@atlanta.com;tag=65bnmj.34asd
   To: sips:alice@atlanta.com
   Call-ID: aiuy7k9njasd
   CSeq: 1 REGISTER
   Max-Forwards: 70
   Supported: path, outbound, gruu
   Contact: 
     ;reg-id=1
     ;+sip.instance=""


   changes:
   sip --> sips in RURI, From, TO, contact headers

-----------------------------------------------------
Section : 8.2.  INVITE dialog through a proxy
CurrentText:

   F1 INVITE  Alice -> proxy.atlanta.com (transport WSS)

   INVITE sip:bob@atlanta.com SIP/2.0
   Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
   From: sip:alice@atlanta.com;tag=asdyka899
   To: sip:bob@atlanta.com
   Call-ID: asidkj3ss
   CSeq: 1 INVITE
   Max-Forwards: 70
   Supported: path, outbound, gruu
   Route: 
   Contact: "
   Content-Type: application/sdp


ReplacementText / Comment:

   Extra closing double quote in contact header.

      Contact: 

   Route: 

   change :
        443-->80              assuming HTTP <-- WS <-- SIP URI
        This comment is applicable for messages F1, F3, F4, F5, F6, F8, F9,
F10,

   Changes
WSS --> WS            assuming HTTP <-- WS <-- SIP URI
        This comment is applicable for messages F1, F2, F3, F4, F5, F6, F7,


-----------------------------------------------------
Section : 1.  Introduction

CurrentText:
Media transport is out of the scope of this document

ReplacementText / Comment:
   Any other draft / rfc which addresses this issue. it would improve the
   readability of the document if we can is suggest reference for
completeness.

-----------------------------------------------------

Section : 5.1.  General
CurrentText:
      (typically web-based applications with an strict and simple API
      for receiving WebSocket messages).  There is no need to establish


ReplacementText / Comment:
      (typically web-based applications with **a** strict and simple API
      for receiving WebSocket messages).  There is no need to establish

-----------------------------------------------------
Section :
CurrentText:
   In the absence of an explicit port and DNS SRV resource records, the
   default port for a SIP URI with "ws" transport parameter is 80 in
   case of SIP scheme and 443 in case of SIPS scheme.


ReplacementText / Comment:
   In the absence of an explicit port and DNS SRV resource records, the
   default port for a SIP URI with "ws" transport parameter is 80 in
   case of SIP scheme and 443 in case of SIPS scheme **, which is same as
   that used for http and https protocols respectively**

These ports have been used for the sake of backward compatibility with
servers
which does not support WS/WSS.

-----------------------------------------------------
Section :
CurrentText:

 _This section is non-normative._

ReplacementText / Comment:
 Some sections have been explicitly mentioned with this text. Does that mean
 other sections are normative text. Not clear though.

-----------------------------------------------------

Thanks,
Nataraju A.B.
nataraju.ab@gmail.com / nataraju.sip@gmail.com
+91-98455-95744

--bcaec554d9aae3688704bde2adcc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


Hi Authros,

Please find some comments on the draft &qu=
ot;draft-ibc-sipcore-sip-websocket-02.txt"



For simplicity, I have mentioned both the current text and proposed =
text.


The comments / corrective text can be found with prefix and suffix =A0--- *=
*

-----------------------------------------------------

Section : =A08.1. =A0Registration
=
CurrentText:
=A0 =A0Alice =A0 =A0(=
SIP WSS) =A0 =A0proxy.atlanta.com<=
/div>

=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0|REGISTER F1 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0|
=A0 =A0|---------=
------------------->|

=A0 =A0|200 OK F2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0|<----------------------------|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 |


ReplacementText / Comment:

=A0 =A0Alice =A0 =A0(SIP WSS) =A0 =A0proxy.atlanta.com


=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0|WebSocket Con Req F1 =A0 =A0 =A0 =A0 |=



=A0 =A0|---------------------------->=
;|
=A0 =A0|WebSocket Con Reply F2 =
=A0 =A0 =A0 |
=A0 =A0|<--------=
--------------------|


=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =
=A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0|REGISTER F3 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0|


=A0 =A0|---------------------------->=
;|
=A0 =A0|200 OK F4 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =
=A0|<----------------------------|


=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 |

=

=A0 =A0Prefixed the WebSocket con=
nection request followed by SIP registrations.=A0


=A0 =A0F1, F2 will be same messages men=
tioned in sec 4.1

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


Section : =A08.1. =A0Registration
=

CurrentText:
=A0 =A0F1 REGISTER =A0Alice -> proxy.atlanta.com (transport WSS)



=A0 =A0REGISTER sip:proxy.atlan=
ta.com SIP/2.0
=A0 =A0Via: SIP=
/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf



=A0 =A0F2 200 OK =A0proxy.atlan=
ta.com -> Alice (transport WSS)



=A0 =A0SIP/2.0 200 OK
=A0 =A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;bran=
ch=3Dz9hG4bKasudf


ReplacementText / Comment:

If I understand right,=A0
=A0 =A0 =A0 =A0 =A0 Websocket connection is =
mapped on to SIP URI =A0--> HTTP


=A0 =A0Secure Websocket connection is m=
apped on to SIPS URI --> HTTPS
=

HTTP --> WS --> SIP URI=
 --> port 80



HTTPS --> WSS --> SIPS URI --> port 443

Hence i=
n the following messages "WSS" shall be replaced with "WS&qu=
ot;



=A0 =A0F1 REGISTER =A0Alice -> proxy.atlanta.com (transport WSS)



=A0 =A0REGISTER sip:proxy.atlanta.com SIP/2.0
=A0 =A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz=
9hG4bKasudf



	WSS=
 --> WS


=A0 =A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf





Probably in the append=
ix A.2, we can list out the call flows for ""SECURE WEB SOCKET=
"" (WSS)



For example, REGISTER request looks like this (with WSS)...

=A0 =A0Via: SIP/2.0/W= SS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf
=A0 =A0From: sips:alice@atlanta= .com;tag=3D65bnmj.34asd
=A0 =A0Contact: <sips:alice@df7jal23= ls0d.invalid;transport=3Dws>
= =A0 =A0 =A0;reg-id=3D1
=A0 =A0 =A0= ;+sip.instance=3D"<urn:uuid:f81-7dec-14a06cf1>"


=A0 =A0changes:
<= div style=3D"color:rgb(51,51,255)">=A0 =A0sip --> sips in RURI, From, TO= , contact headers
=A0 =A0
-----------------------------------------------------
Section : 8.2. =A0INVITE dialog through a pro= xy
CurrentText:

=A0 =A0Via: SIP= /2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
=A0 =A0From: sip:alice@atlanta.com;tag=3Dasdyka899
=A0 =A0Call-ID: asidkj3ss
=A0 =A0CSeq: 1 INVITE
=A0 =A0Max-Forwards: 70
=A0 =A0Supported: path, outbound, gruu
=A0 =A0Route: <sip:proxy.atlanta.com= :443;transport=3Dws;lr>
=A0 =A0= Contact: <sip:alice@atlanta.c= om
=A0 =A0 ;gr=3Durn:uuid:f81-7dec-14a06cf= 1;ob>"
=A0 =A0Content-Type= : application/sdp


ReplacementText / Comment:

=A0 =A0Extra closing double quote in contact header.

=A0 =A0 =A0 Contact: <sip:alice@atlanta.com
=A0 =A0 =A0 =A0 =A0 ;gr=3Durn:uuid:f81-7dec-= 14a06cf1;ob>

=A0 =A0Route: <sip:proxy.atlanta.com:80;transport=3Dws;lr> =A0= =A0

=A0 =A0change :=A0
=A0 =A0 =A0 =A0= 443-->80 =A0 =A0 =A0 =A0 =A0 =A0 =A0assuming=A0HTTP=A0<--=A0WS <-= - SIP URI
=A0 =A0 =A0 =A0 This com= ment is applicable for messages F1, F3, F4, F5, F6, F8, F9, F10,=A0

=A0 =A0Changes
WSS --> WS =A0 =A0= =A0 =A0 =A0 =A0assuming=A0HTTP=A0<--=A0WS <-- SIP URI
=A0 =A0 =A0 =A0 This comment is applica= ble for messages F1, F2, F3, F4, F5, F6, F7,=A0


-----------------------------------------------------
Section : 1. =A0Introduction

CurrentText:
Media transport is out of the scope of = this document

ReplacementText / Comment:
=A0 =A0Any other draft / rfc which addresses this issue. it would improve t= he=A0
=A0 =A0readability of the do= cument if we can is suggest reference for completeness.

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

Section : 5.1. =A0General
CurrentText:
=A0 =A0 =A0 (typicall= y web-based applications with an strict and simple API
=A0 =A0 =A0 for receiving WebSocket messages). =A0Ther= e is no need to establish


ReplacementText / Comm= ent:
=A0 =A0 =A0 (typically web-ba= sed applications with **a** strict and simple API
=A0 =A0 =A0 for receiving WebSocket mes= sages). =A0There is no need to establish

----------------------= -------------------------------
Section :=A0
CurrentText:
=A0 = =A0In the absence of an explicit port and DNS SRV resource records, the
=A0 =A0default port for a SIP URI with "ws" transport parameter i= s 80 in
=A0 =A0case of SIP scheme = and 443 in case of SIPS scheme.

ReplacementText / Comment:
= =A0 =A0In the absence of an explicit port and DNS SRV resource records, the=
=A0 =A0default port for a SIP URI with = "ws" transport parameter is 80 in
=A0 =A0case of SIP scheme and 443 in case of SIPS scheme **, whic= h is same as=A0
=A0 =A0that used for http and https pro= tocols respectively**

These ports have been used for the sake o= f backward compatibility with servers=A0
which does not support WS/WSS.

-----------------------------------------------------
Section :=A0
CurrentText:

=A0_This section is non-normative._

ReplacementText / Comment:
<= div style=3D"color:rgb(51,51,255)">=A0Some sections have been explicitly me= ntioned with this text. Does that mean
=A0other sections are normative text. Not clear though.

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

Thanks,
Nataraju A.B.
nataraju.ab@gmail.com / nataraju.sip@gmail.com
+91-98455-95744
--bcaec554d9aae3688704bde2adcc-- From dworley@avaya.com Tue Apr 17 09:57:00 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E582811E8074 for ; Tue, 17 Apr 2012 09:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=0.409, 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 GSodPqeBt1+P for ; Tue, 17 Apr 2012 09:56:56 -0700 (PDT) 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 3476011E80A3 for ; Tue, 17 Apr 2012 09:56:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAKWgjU+HCzI1/2dsb2JhbABCArE8gQeCEBIVE1EBFSEIQicEEwgah14DCAMLmF+EGpM5CIlYimWCaguCOmMElwCFA4oigwOBOAQE X-IronPort-AV: E=Sophos;i="4.75,437,1330923600"; d="scan'208";a="342849604" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Apr 2012 12:56:12 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 17 Apr 2012 12:40:00 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 17 Apr 2012 12:56:31 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Tue, 17 Apr 2012 12:56:30 -0400 Thread-Topic: draft-ietf-sipcore-rfc4244bis-07, sections 1 to 5 Thread-Index: AQHNHLWBah3lmRkD40WRPdtjldnh0g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-rfc4244bis-07, sections 1 to 5 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 16:57:01 -0000 Here are some things that I think could be improved in sections 1 to 5 of the 07 draft. They are listed in textual order. Abstract In addition, this specification defines a value for the Privacy header field specific to the History-Info header field. As in other places in the draft, mention is made that there *exists* a related Privacy value without giving any hint of the *purpose* of the value. This seems to me to be needlessly obscure. A better description would be "This specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field." 1. Introduction the receiving application to determine hints about how and why the should be the receiving application to obtain information about how and why the 2. Conventions and Terminology process of a SIP entity changing a Uniform Resource Identifier (URI) in a request based on the rules for determining request targets as This sentence does not specify *which* URI in the request is being changed. A better wording would be process of a SIP entity changing the request-URI [RFC3261, section 7.1] in a request based on the rules for determining request targets as The terms "target user" is used in this specification as the human user associated with particular AoR or AoRs (in case the human user has multiple alias). The use of "alias" here is not particularly good. A better phrase would be "in case the human user has multiple AoRs". 3. Background Current network applications provide the ability for elements should have added "Current network applications >>>for other protocols<<< provide". 2. Email forwarding whereby the forwarded-to user obtains a "history" of who sent the email to whom and at what time More apropos is the fact that most e-mail systems add "Received" lines, giving a detailed trace of the path of the message from sender to receiver, and if the Received headers include the "for" clause, the translation of the original destination address to the ultimate recipient's address can be tracked. E.g., Received: from eye.ariadne.com (eye.ariadne.com [127.0.0.1]) by eye.ariadne.com (8.14.4/8.14.4) with ESMTP id q3H8e3vI026332 for ; Tue, 17 Apr 2012 04:40:03 -0400 Received: from mail.comcast.net [76.96.58.11] by eye.ariadne.com with POP3 (fetchmail-6.3.20) for (single-drop); Tue, 17 Apr 2012 04:40:03 -0400= (EDT) Received: from imta34.emeryville.ca.mail.comcast.net (LHLO imta34.emeryville.ca.mail.comcast.net) (76.96.28.168) by sz0045.wc.mail.comcast.net with LMTP; Tue, 17 Apr 2012 08:26:05 +0000= (UTC) Received: from VIMPORTPART.COM ([78.46.253.246]) by imta34.emeryville.ca.mail.comcast.net with comcast id ywS21i00o5KkC6e0awS2oh; Tue, 17 Apr 2012 08:26:03 +0000 Received: by VIMPORTPART.COM (Postfix, from userid 0) id 21D99831D7; Tue, 17 Apr 2012 10:26:02 +0200 (CEST) o Capturing aliases and Globally Routable User Agent URIs (GRUUs) [RFC5627], which can be overwritten by a REGISTRAR or a "home should be "registrar". 4. Overview request to be changed by the same proxy/SIP Intermediary multiple should be "intermediary". header field parameters, along with examples is provided in reads better with a comma after "examples". In addition, this specification defines a priv-value for the Privacy header, "history", that applies to all the History-info header field entries in a Request or to a specific History-info header field hi- entry as described above. Further detail is provided in Section 10.1. Again, this description does not state that the priv-value requires that History-Info values be anonymized. Better would be In addition, this specification defines a priv-value for the Privacy header, "history", that >>>requires anonymization of<<< all the >>>History-Info<<< header field entries in a Request or to a specific History-info header field hi-entry as described above. Further detail is provided in Section 10.1. And "History-info" needs to be capitalized as "History-Info". 5. History-Info Header Field Protocol Structure these requests (ISSUER-req, see Appendix A). It looks like this phrase is intended to be a reference to the requirements listed in Appendix A. In that case, it should use brackets [...] rather than parentheses (...). But since there are only two such references (the other one is in section 13), it appears that the references were incompletely removed. Otherwise there would be many more of them. parameter is a string of digits, separated by dots to indicate the There is a long history of using the term "string of digits" in these drafts, despite that it's not a correct way to look at the syntax. The syntax is a sequence of positive integers separated by dots and the text should say that: parameter is a sequence of positive integers, separated by dots to indicate the This results in a tree representation of the history of the request, with the lowest- level index reflecting a branch of the tree. I'm not sure what is meant here. It is true that the lowest-level index reflects a branch of the tree, but so do all the higher-level indexes. I believe that what is intended is "leaf". This parameter contains either an "rc", "mp" or "np" header field parameter, which is interpreted as follows: "contains" should be "is". "np": The hi-targeted-to-URI represents that there was no change in Request-URI. This would apply for example when a proxy merely forwards a request to a next hop proxy and loose routing is used. Unlike the previous two cases, this case does not describe the function of the value of the np parameter. o Privacy: An optional parameter for History-Info, reflected in the History-Info header field values by including the Privacy Header [RFC3323] included in the hi- targeted-to-uri or by adding the Privacy header field to the request. The latter case indicates that the History-Info entries for the domain MUST be anonymized prior to forwarding, whereas the use of the Privacy header field included in the hi-targeted-to-uri means that a specific hi-entry MUST be anonymized. The phrase "the domain" is completely undefined here. I suspect you mean something like "all History-Info entries whose hi-targeted-to-uri has the same domain as the domain for which the SIP entity processing the message is responsible". Note that the backslash and CRLF between the fields in the examples below are for readability purposes only. Was "lines" meant instead of "fields"? Note that the backslash, CRLF and whitespace between the lines in the examples below are inserted for readability purposes only. (But History-Info can be broken into multiple lines due to the SWS that is part of HCOLON, COMMA and SEMI, and there can be multiple History-Info header fields due to the rule of section 7.3 [RFC3261].) History-Info: ;index=3D1;foo=3Dbar History-Info: ;index=3D1.1,\ ;index=3D1.2;mp=3D1.1,\ ;index=3D1.3;rc=3D1.2 5.1. History-Info Header Field Example Scenario One important thing illustrated by this call flow is that without History-Info, Bob would "lose" the target information, including any parameters in the request URI. It seems to me that "the target information" is ambiguous -- the target information of which request would be lost when? You want to say something like "the initial request-URI" or "the original target information". Note that an hi- entry is not included for the fork to sip:bob@192.0.2.7 since there was no response at the time the 200 OK is sent to Alice. This would be a lot clearer if it was more detailed: Note that in the 200 response to Alice, an hi-entry is not included for the fork to sip:bob@192.0.2.7 (index 1.1.1) since biloxi.example.com had not received a response from that fork at the time it sent the 200 OK that ultimately reached Alice. The formatting in this scenario is for visual purposes; thus, backslash and CRLF are used between the fields for readability. Although in fact there are no backslash-line breaks in the example. If there were, it might be needed to mention the included whitespace as in section 5. | | | Proxy Cancels INVITE | | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| Might be better illustrated by showing it as a CANCEL request: | | | CANCEL | | | | |-------------------------->| Dale From ibc@aliax.net Tue Apr 17 10:25:42 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C356E11E80B4 for ; Tue, 17 Apr 2012 10:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_62=0.6, 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 o7lBvuVzU3MS for ; Tue, 17 Apr 2012 10:25:38 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 191ED11E80A1 for ; Tue, 17 Apr 2012 10:25:37 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so494837vcb.31 for ; Tue, 17 Apr 2012 10:25:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=zMifovlyhb/BsqPh1XKDRweCkx0GKLF20OConOObz1Y=; b=S54xWqFCs7dBgQleU26CSQ3nwT3opzBnCgZllSVOwIbtTTpCOXKwE3WNjQeQJLMG/9 Ho+Tw62tBp21Yw9Y2dbICPhACpmOv7m+m3r7WQMJyQO+pSrec4NoEbhtdxxqV6i/5fCO x+EWllEj0D0sxTCYO7vb/qd22Jnbb9KPy3x9au0iBcKpDupwqYMLaZwXM9pGm+ABcexy pNndyIREpIEHFVL5AxJRqfsVMecYgAPDD4CG2CaZbGy8q3ZBX5jDzTJBUHNO/QY9+6/Q 6jG6qmlegiMvk3K7/C9YIcttvYrDYLypM1jgQjtkC4uWTgN7agkh9ExarPsIg/mgMHSQ zgbg== Received: by 10.220.140.207 with SMTP id j15mr2137806vcu.22.1334683537472; Tue, 17 Apr 2012 10:25:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 17 Apr 2012 10:25:17 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 17 Apr 2012 19:25:17 +0200 Message-ID: To: "Nataraju A.B" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnlLOptLrYxXf2Hd0c8q9RIJIYM9oe67Xu+mHIPtez7OrJiYJjSaSKJQPqtbDIyo4+F0PoN Cc: vpascual@acmepacket.com, jmillan@aliax.net, sipcore@ietf.org Subject: Re: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - Review comments (Nataraju A B) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:25:42 -0000 2012/4/17 Nataraju A.B : > Hi Authros, > > Please find some comments on the draft > "draft-ibc-sipcore-sip-websocket-02.txt" Hi Nataraju, thanks for your comments. We will address them. Some replies inline: > ----------------------------------------------------- > Section : =C2=A08.1. =C2=A0Registration > CurrentText: > =C2=A0 =C2=A0F1 REGISTER =C2=A0Alice -> proxy.atlanta.com (transport WSS) > > =C2=A0 =C2=A0REGISTER sip:proxy.atlanta.com SIP/2.0 > =C2=A0 =C2=A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf > > =C2=A0 =C2=A0F2 200 OK =C2=A0proxy.atlanta.com -> Alice (transport WSS) > > =C2=A0 =C2=A0SIP/2.0 200 OK > =C2=A0 =C2=A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf > > ReplacementText / Comment: > > If I understand right, > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Websocket connection is mapped on to S= IP URI =C2=A0--> HTTP > =C2=A0 =C2=A0Secure Websocket connection is mapped on to SIPS URI --> HTT= PS > > HTTP --> WS --> SIP URI --> port 80 > > HTTPS --> WSS --> SIPS URI --> port 443 > > Hence in the following messages "WSS" shall be replaced with "WS" > > =C2=A0 =C2=A0F1 REGISTER =C2=A0Alice -> proxy.atlanta.com (transport WSS) > > =C2=A0 =C2=A0REGISTER sip:proxy.atlanta.com SIP/2.0 > =C2=A0 =C2=A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf > > WSS --> WS > > =C2=A0 =C2=A0F2 200 OK =C2=A0proxy.atlanta.com -> Alice (transport WSS) > > =C2=A0 =C2=A0SIP/2.0 200 OK > =C2=A0 =C2=A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf > > WSS --> WS Usage of a secure transport (like TLS-TCP or WSS) does not mandate usage of SIPS schema. This is clearly explained in: http://tools.ietf.org/html/rfc5630#section-3.1.3 > For example, REGISTER request looks like this (with WSS)... > > =C2=A0 =C2=A0REGISTER sips:proxy.atlanta.com SIP/2.0 > =C2=A0 =C2=A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf > =C2=A0 =C2=A0From: sips:alice@atlanta.com;tag=3D65bnmj.34asd > =C2=A0 =C2=A0To: sips:alice@atlanta.com > =C2=A0 =C2=A0Call-ID: aiuy7k9njasd > =C2=A0 =C2=A0CSeq: 1 REGISTER > =C2=A0 =C2=A0Max-Forwards: 70 > =C2=A0 =C2=A0Supported: path, outbound, gruu > =C2=A0 =C2=A0Contact: > =C2=A0 =C2=A0 =C2=A0;reg-id=3D1 > =C2=A0 =C2=A0 =C2=A0;+sip.instance=3D"" > > > =C2=A0 =C2=A0changes: > =C2=A0 =C2=A0sip --> sips in RURI, From, TO, contact headers As stated above this is not needed. WSS (or TLS-TCP) can be used without using SIPS schema in SIP requests. That is a "best-effort TLS / WSS". Also using Outbound RFC 5626 helps here since the Outbound proxy (or the server the UA is connected to via TLS / WSS) can reuse the existing connection for incoming requests. This is also explained in http://tools.ietf.org/html/rfc5630#section-3.1.3. In summary: using a secure connection does not require using SIPS schema in the requests sent over it. > ----------------------------------------------------- > Section : 8.2. =C2=A0INVITE dialog through a proxy > CurrentText: > > =C2=A0 =C2=A0F1 INVITE =C2=A0Alice -> proxy.atlanta.com (transport WSS) > > =C2=A0 =C2=A0INVITE sip:bob@atlanta.com SIP/2.0 > =C2=A0 =C2=A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdas= ks > =C2=A0 =C2=A0From: sip:alice@atlanta.com;tag=3Dasdyka899 > =C2=A0 =C2=A0To: sip:bob@atlanta.com > =C2=A0 =C2=A0Call-ID: asidkj3ss > =C2=A0 =C2=A0CSeq: 1 INVITE > =C2=A0 =C2=A0Max-Forwards: 70 > =C2=A0 =C2=A0Supported: path, outbound, gruu > =C2=A0 =C2=A0Route: > =C2=A0 =C2=A0Contact: =C2=A0 =C2=A0 ;gr=3Durn:uuid:f81-7dec-14a06cf1;ob>" > =C2=A0 =C2=A0Content-Type: application/sdp > > > ReplacementText / Comment: > > =C2=A0 =C2=A0Extra closing double quote in contact header. Typo, thanks :) > =C2=A0 =C2=A0 =C2=A0 Contact: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;gr=3Durn:uuid:f81-7dec-14a06cf1;ob> > > =C2=A0 =C2=A0Route: > > =C2=A0 =C2=A0change : > =C2=A0 =C2=A0 =C2=A0 =C2=A0 443-->80 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0assuming=C2=A0HTTP=C2=A0<--=C2=A0WS <-- SIP URI > =C2=A0 =C2=A0 =C2=A0 =C2=A0 This comment is applicable for messages F1, F= 3, F4, F5, F6, F8, F9, > F10, Same comments as above :) The example uses a secure WS connection (on top of TLS) but does not use SIPS schema. > =C2=A0 =C2=A0Changes > WSS --> WS =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0assuming=C2=A0HTTP=C2= =A0<--=C2=A0WS <-- SIP URI > =C2=A0 =C2=A0 =C2=A0 =C2=A0 This comment is applicable for messages F1, F= 2, F3, F4, F5, F6, F7, Idem. > ----------------------------------------------------- > Section : 1. =C2=A0Introduction > > CurrentText: > Media transport is out of the scope of this document > > ReplacementText / Comment: > =C2=A0 =C2=A0Any other draft / rfc which addresses this issue. it would i= mprove the > =C2=A0 =C2=A0readability of the document if we can is suggest reference f= or > completeness. > > ----------------------------------------------------- We would not like to cover it. In case of web browsers, WebRTC specification is defining RTP/SRTP/ICE/TURN for web applications. But a SIP client using a WebSocket stack running in, i.e, a smartphone, could use usual RTP for media transport. We don't want to focus the draft on "web browsers" use case. > Section : 5.1. =C2=A0General > CurrentText: > =C2=A0 =C2=A0 =C2=A0 (typically web-based applications with an strict and= simple API > =C2=A0 =C2=A0 =C2=A0 for receiving WebSocket messages). =C2=A0There is no= need to establish > > > ReplacementText / Comment: > =C2=A0 =C2=A0 =C2=A0 (typically web-based applications with **a** strict = and simple API > =C2=A0 =C2=A0 =C2=A0 for receiving WebSocket messages). =C2=A0There is no= need to establish Typo :) > Section : > CurrentText: > =C2=A0 =C2=A0In the absence of an explicit port and DNS SRV resource reco= rds, the > =C2=A0 =C2=A0default port for a SIP URI with "ws" transport parameter is = 80 in > =C2=A0 =C2=A0case of SIP scheme and 443 in case of SIPS scheme. > > > ReplacementText / Comment: > =C2=A0 =C2=A0In the absence of an explicit port and DNS SRV resource reco= rds, the > =C2=A0 =C2=A0default port for a SIP URI with "ws" transport parameter is = 80 in > =C2=A0 =C2=A0case of SIP scheme and 443 in case of SIPS scheme **, which = is same as > =C2=A0 =C2=A0that used for http and https protocols respectively** > > These ports have been used for the sake of backward compatibility with > servers > which does not support WS/WSS. > > ----------------------------------------------------- > Section : > CurrentText: > > =C2=A0_This section is non-normative._ > > ReplacementText / Comment: > =C2=A0Some sections have been explicitly mentioned with this text. Does t= hat mean > =C2=A0other sections are normative text. Not clear though. Basically yes. The style is the same as in RFC 6455 (http://tools.ietf.org/html/rfc6455) in which non normative sections include the above line. Any suggestion to make it better is of course welcome. Thanks a lot for your review, we will address all the topics covered in it. --=20 I=C3=B1aki Baz Castillo From nataraju.sip@gmail.com Tue Apr 17 10:26:11 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6B611E80CE for ; Tue, 17 Apr 2012 10:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=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 p8v3Nzg8dEcK for ; Tue, 17 Apr 2012 10:26:07 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id A998911E80C9 for ; Tue, 17 Apr 2012 10:26:06 -0700 (PDT) Received: by lagj5 with SMTP id j5so5402483lag.31 for ; Tue, 17 Apr 2012 10:26:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=fOgiIJEoKliCJWCHUA2eyTuhmaJ40gt6HkJbqFazF9g=; b=qWXc3bDP2sy5/uoEi1Ca0rWB27gGRMDWq5AK/5StT+FB9Am1qlyV45p7tRmir0Rlwz QpGDJ+FxtlEbG4lWoZGrtSpoXA2S0A1ZY8+paf9wzCkpBTqeONLS40Wn0e2DS70UhFBE 9+y2tWxzKyzhkFG21AQlk9h/RWFJLmLeQVhB8xN+uhp8jE2i67GalrsQze98vTahCdaH BtpaDfFWEYeGAvzB0d/X0GNJWbfffol7oi1wqyV/3q2m404wTOJ/ir4LGvV/LwqVe84D Iy3MSgY+l19zo3nZ4sAVjj3BNHg05YUY3q6KXsFo67RZw6QJC8DF0gPT/Z2r3rtdBmIP kFNQ== MIME-Version: 1.0 Received: by 10.112.99.169 with SMTP id er9mr7413847lbb.67.1334683565540; Tue, 17 Apr 2012 10:26:05 -0700 (PDT) Received: by 10.112.103.103 with HTTP; Tue, 17 Apr 2012 10:26:05 -0700 (PDT) Date: Tue, 17 Apr 2012 22:56:05 +0530 Message-ID: From: "Nataraju A.B" To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , jmillan@aliax.net, vpascual@acmepacket.com, sipcore@ietf.org Content-Type: multipart/alternative; boundary=14dae9d67bd2cfc59104bde33b33 Subject: [sipcore] Call flow for Secure Web Socket creation --- draft-ibc-sipcore-sip-websocket-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Apr 2012 17:26:11 -0000 --14dae9d67bd2cfc59104bde33b33 Content-Type: text/plain; charset=ISO-8859-1 Hi All, I have written a call flow for the secure web socket usage with TCP. Please go through the same and share if any changes required. --------------------------------------------------------------------- 8.3. INVITE dialog through a proxy (Secure Web Socket, WSS) Alice (SIP WSS) proxy.atlanta.com (SIP TLS) Bob | | | |INVITE F1 | | |---------------------------->| | |100 Trying F2 | | |<----------------------------| | | |INVITE F3 | | |---------------------------->| | |200 OK F4 | | |<----------------------------| |200 OK F5 | | |<----------------------------| | | | | |ACK F6 | | |---------------------------->| | | |ACK F7 | | |---------------------------->| | | | | Both Way RTP Media | |<=========================================================>| | | | | |BYE F8 | | |<----------------------------| |BYE F9 | | |<----------------------------| | |200 OK F10 | | |---------------------------->| | | |200 OK F11 | | |---------------------------->| | | | In the same scenario Alice places a call to Bob's AoR. The WebSocket SIP server at proxy.atlanta.com acts as a SIP proxy routing the INVITE to the UDP location of Bob over TLS, who answers the call and terminates it later. Message details (authentication and SDP bodies are omitted for simplicity): F1 INVITE Alice -> proxy.atlanta.com (transport WSS) INVITE sips:bob@atlanta.com SIP/2.0 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks From: sips:alice@atlanta.com;tag=asdyka899 To: sips:bob@atlanta.com Call-ID: asidkj3ss CSeq: 1 INVITE Max-Forwards: 70 Supported: path, outbound, gruu Route: Contact: Content-Type: application/sdp F2 100 Trying proxy.atlanta.com -> Alice (transport WSS) SIP/2.0 100 Trying Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks From: sips:alice@atlanta.com;tag=asdyka899 To: sips:bob@atlanta.com Call-ID: asidkj3ss CSeq: 1 INVITE F3 INVITE proxy.atlanta.com -> Bob (transport TLS) INVITE sips:bob@203.0.113.22:5060 SIP/2.0 Via: SIP/2.0/TLS proxy.atlanta.com;branch=z9hG4bKhjhjqw32c Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Record-Route: , From: sips:alice@atlanta.com;tag=asdyka899 To: sips:bob@atlanta.com Call-ID: asidkj3ss CSeq: 1 INVITE Max-Forwards: 69 Supported: path, outbound, gruu Contact: Content-Type: application/sdp F4 200 OK Bob -> proxy.atlanta.com (transport TLS) SIP/2.0 200 OK Via: SIP/2.0/TLS proxy.atlanta.com;branch=z9hG4bKhjhjqw32c Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Record-Route: , From: sips:alice@atlanta.com;tag=asdyka899 To: sips:bob@atlanta.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 INVITE Max-Forwards: 69 Contact: Content-Type: application/sdp F5 200 OK proxy.atlanta.com -> Alice (transport WSS) SIP/2.0 200 OK Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks Record-Route: , From: sips:alice@atlanta.com;tag=asdyka899 To: sip:bob@atlanta.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 INVITE Max-Forwards: 69 Contact: Content-Type: application/sdp F6 ACK Alice -> proxy.atlanta.com (transport WSS) ACK sips:bob@203.0.113.22:5060;transport=TCP SIP/2.0 Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 Route: , , From: sips:alice@atlanta.com;tag=asdyka899 To: sips:bob@atlanta.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 ACK Max-Forwards: 70 F7 ACK proxy.atlanta.com -> Bob (transport TLS) ACK sips:bob@203.0.113.22:5060;transport=TCP SIP/2.0 Via: SIP/2.0/TLS proxy.atlanta.com;branch=z9hG4bKhwpoc80zzx Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090 From: sips:alice@atlanta.com;tag=asdyka899 To: sips:bob@atlanta.com;tag=bmqkjhsd Call-ID: asidkj3ss CSeq: 1 ACK Max-Forwards: 69 F8 BYE Bob -> proxy.atlanta.com (transport TLS) BYE sips:alice@atlanta.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001 Route: , From: sips:bob@atlanta.com;tag=bmqkjhsd To: sips:alice@atlanta.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE Max-Forwards: 70 F9 BYE proxy.atlanta.com -> Alice (transport WSS) BYE sips:alice@atlanta.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0 Via: SIP/2.0/WSS proxy.atlanta.com:443;branch=z9hG4bKmma01m3r5 Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001 From: sips:bob@atlanta.com;tag=bmqkjhsd To: sips:alice@atlanta.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE Max-Forwards: 69 F10 200 OK Alice -> proxy.atlanta.com (transport WSS) SIP/2.0 200 OK Via: SIP/2.0/WSS proxy.atlanta.com:443;branch=z9hG4bKmma01m3r5 Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001 From: sips:bob@atlanta.com;tag=bmqkjhsd To: sips:alice@atlanta.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE F11 200 OK proxy.atlanta.com -> Bob (transport TLS) SIP/2.0 200 OK Via: SIP/2.0/TLS 203.0.113.22;branch=z9hG4bKbiuiansd001 From: sips:bob@atlanta.com;tag=bmqkjhsd To: sips:alice@atlanta.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE Thanks, Nataraju A.B. nataraju.ab@gamil.com / nataraju.sip@gmail.com +91-98455-95744 --14dae9d67bd2cfc59104bde33b33 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,
I have written a call flow for the secure web socket usage with TCP.=A0=

=
Pleas= e go through the same and share if any changes required.
<= font face=3D"'courier new', monospace" size=3D"4">
---------------------------------------------------------------------
8.3. =A0INV= ITE dialog through a proxy (Secure Web Socket, WSS)

=
=A0 =A0Alice =A0 =A0(SIP WSS) =A0 =A0proxy.atlanta.com =A0 =A0(SIP TLS) =A0 =A0 =A0 Bob
= =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0|INV= ITE F1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0|---------------------------->| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0|100= Trying F2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0|<----------------------------| =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |INVITE F3 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |---------------------------->|
=A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |200 OK F4 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |<----------------------------|
=A0 =A0|200= OK F5 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0|<----------------------------| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0|ACK F6 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |
=A0 =A0|---= ------------------------->| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |ACK F7 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |------------------= ---------->|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<= /div>
=A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Both Way RTP Media =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0|<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>|
=A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |BYE F8 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |
=A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<--------------= --------------|
=A0 =A0|BYE F9 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0|<= ;----------------------------| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |
=A0 =A0|200 OK F10 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0|---= ------------------------->| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 |
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 |200 OK F11 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0| = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |------------------= ---------->|
=A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<= /div>

=
=A0 = =A0In the same scenario Alice places a call to Bob's AoR. =A0The WebSoc= ket
=A0 =A0SIP = server at proxy.atla= nta.com acts as a SIP proxy routing the
=A0 =A0INVITE to the UDP locat= ion of Bob over TLS, who answers the call and
=A0 =A0term= inates it later.

=A0 =A0Message details (authentication and SDP bodi= es are omitted for
=A0 =A0simp= licity):


=A0 =A0F1 INVITE =A0Alice -> proxy.atlanta.com (transport WSS)

=A0 =A0INVITE sips:bob@atlanta.com SIP/2.0
=A0 =A0Via: SIP/2.0/WSS df7jal23ls0d.inv= alid;branch=3Dz9hG4bK56sdasks
=A0 =A0From= : sips:alice@= atlanta.com;tag=3Dasdyka899
=A0 =A0Call= -ID: asidkj3ss
=A0 =A0CSeq: 1 INVITE
=A0 =A0Max-Forwards: 70
=A0 =A0Supp= orted: path, outbound, gruu
=A0 =A0Route: <sips:proxy.atlanta.com:443;t= ransport=3Dws;lr>
=A0 =A0Cont= act: <sips= :alice@atlanta.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob>
<= div>=A0 =A0Conte= nt-Type: application/sdp

=

<= /font>
=A0 =A0F2 100 Trying =A0proxy.atlanta.com -> Alice (transport WSS)

=
=A0 = =A0SIP/2.0 100 Trying
=A0 =A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch= =3Dz9hG4bK56sdasks
=A0 =A0From= : sips:alice@= atlanta.com;tag=3Dasdyka899
=A0 =A0Call= -ID: asidkj3ss
=A0 =A0CSeq: 1 INVITE


=A0 =A0F3 INVITE =A0proxy.atlanta.com -> Bob (transport TLS)

=
=A0 = =A0INVITE s= ips:bob@203.0.113.22:5060 SIP/2.0
=A0 =A0Via:= SIP/2.0/TLS proxy.a= tlanta.com;branch=3Dz9hG4bKhjhjqw32c
=A0 =A0Via: SIP/2.0/WSS df7jal23l= s0d.invalid;branch=3Dz9hG4bK56sdasks
=A0 =A0Reco= rd-Route: <sips:p= roxy.atlanta.com;transport=3DTCP;lr>,
=A0 =A0 =A0<sips:h7kjh12s@= proxy.atlanta.com:443;transport=3Dws;lr>
=A0 =A0From= : sips:alice@= atlanta.com;tag=3Dasdyka899
=A0 =A0Call= -ID: asidkj3ss
=A0 =A0CSeq: 1 INVITE
=A0 =A0Max-Forwards: 69
=A0 =A0Supp= orted: path, outbound, gruu
=A0 =A0Contact: <sips:alice@atlanta.com;gr=3Durn:uui= d:f81-7dec-14a06cf1;ob>
=A0 =A0Cont= ent-Type: application/sdp


=A0 =A0F4 200 OK =A0Bob -> proxy.atlanta.com (transport TLS)

=A0 =A0SIP/2.0 200 OK
=A0 =A0Via: SIP/2.0/TLS proxy.atlanta.com;branch=3Dz9hG4bKhjhjqw32= c
=A0 =A0Via:= SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks
=A0 =A0Record-R= oute: <sips:proxy= .atlanta.com;transport=3DTCP;lr>,
=A0 =A0 =A0= <sips:h7kjh12s@proxy.atlanta.com:443;transport=3Dws;lr>
<= div>=A0 =A0From:= sips:alice@a= tlanta.com;tag=3Dasdyka899
=A0 =A0To: = sips:bob@atlant= a.com;tag=3Dbmqkjhsd
=A0 =A0Call-ID: asidkj3ss
=A0 =A0CSeq= : 1 INVITE
=A0 =A0Max-Forwards: 69
=A0 =A0Contact: <sips:bob@203.0.113= .22:5060;transport=3DTCP>
=A0 =A0Cont= ent-Type: application/sdp


=A0 =A0F5 200 OK =A0proxy.atlanta.com -> Alice (transport WSS)

=A0 =A0SIP/2.0 200 OK
=A0 =A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branc= h=3Dz9hG4bK56sdasks
=A0 =A0Reco= rd-Route: <sips:p= roxy.atlanta.com;transport=3DTCP;lr>,
=A0 =A0 =A0<sips:h7kjh12s@= proxy.atlanta.com:443;transport=3Dws;lr>
=A0 =A0From= : sips:alice@= atlanta.com;tag=3Dasdyka899
=A0 =A0To: sip:bob@atlanta.com;tag=3Dbmqkjhsd
=A0 =A0Call= -ID: asidkj3ss
=A0 =A0CSeq: 1 INVITE
=A0 =A0Max-Forwards: 69
=A0 =A0Cont= act: <sips:bob@203.0.113.22:5060;transport=3DTCP>
=A0 =A0Content-Typ= e: application/sdp

=

<= /font>
=A0 =A0F6 ACK =A0Alice -> proxy.atlanta.com (transport WSS)

=
=A0 = =A0ACK sips:bob@203.0.113.22:5060;transport=3DTCP SIP/2.0
= =A0 =A0Via: SIP/= 2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090
=A0 =A0Rout= e: <sips:h7kjh12s@proxy.atlanta.com:443;transport=3Dws;lr>,
=A0 =A0 = =A0<sips:proxy.at= lanta.com;transport=3DTCP;lr>,
=A0 =A0From= : sips:alice@= atlanta.com;tag=3Dasdyka899
=A0 =A0To: sips:bob@atlanta.com;tag=3Dbmqkjhsd=
=A0 =A0Call= -ID: asidkj3ss
=A0 =A0CSeq: 1 ACK
=A0 =A0Max-Forwards: 70

=

<= /font>
=A0 =A0F7 ACK =A0pr= oxy.atlanta.com -> Bob (transport TLS)

=
=A0 = =A0ACK sips:bob@203.0.113.22:5060;transport=3DTCP SIP/2.0
= =A0 =A0Via: SIP/= 2.0/TLS proxy.atlant= a.com;branch=3Dz9hG4bKhwpoc80zzx
=A0 =A0Via:= SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKhgqqp090
=A0 =A0From: sips:alice@atla= nta.com;tag=3Dasdyka899
=A0 =A0To: = sips:bob@atlant= a.com;tag=3Dbmqkjhsd
=A0 =A0Call-ID: asidkj3ss
=A0 =A0CSeq= : 1 ACK
=A0 =A0Max-Forwards: 69


=A0 =A0F8 BYE =A0Bob -> proxy.atlanta.com (transport TLS)

=
=A0 = =A0BYE sips:a= lice@atlanta.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0
=A0 =A0Via:= SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
=A0 =A0Route: <si= ps:proxy.atlanta.com= ;transport=3DTCP;lr>,
=A0 =A0 =A0= <sips:h7kjh12s@proxy.atlanta.com:443;transport=3Dws;lr>
<= div>=A0 =A0From:= sips:bob@atlan= ta.com;tag=3Dbmqkjhsd
=A0 =A0To: = sips:alice@at= lanta.com;tag=3Dasdyka899
=A0 =A0Call-ID: asidkj3ss
=A0 =A0CSeq= : 1201 BYE
=A0 =A0Max-Forwards: 70


=A0 =A0F9 BYE =A0proxy.atlanta.com -> Alice (transport WSS)

=
=A0 = =A0BYE sips:a= lice@atlanta.com;gr=3Durn:uuid:f81-7dec-14a06cf1;ob SIP/2.0
=A0 =A0Via:= SIP/2.0/WSS proxy.atlanta.com:443;branch=3Dz9hG4bKmma01m3r5
=A0 =A0Via: S= IP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
=A0 =A0From= : sips:bob@atla= nta.com;tag=3Dbmqkjhsd
=A0 =A0To: sips:alice@atlanta.com;tag=3Dasdyka899=
=A0 =A0Call= -ID: asidkj3ss
=A0 =A0CSeq: 1201 BYE
=A0 =A0Max-Forwards: 69

=

<= /font>
=A0 =A0F10 200 OK =A0Alice -> proxy.atlanta.com (transport WSS)

=
=A0 = =A0SIP/2.0 200 OK
=A0 =A0Via: SIP/2.0/WSS proxy.atlanta.com:443;branch=3Dz= 9hG4bKmma01m3r5
=A0 =A0Via:= SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG4bKbiuiansd001
=A0 =A0Call-ID: asidkj3ss
=A0 =A0CSeq= : 1201 BYE


=A0 =A0F11 200 OK =A0proxy.atlanta.com -> Bob (transport TLS)

=A0 =A0SIP/2.0 200 OK
=A0 =A0Via: SIP/2.0/TLS 203.0.113.22;branch=3Dz9hG= 4bKbiuiansd001
=A0 =A0From= : sips:bob@atla= nta.com;tag=3Dbmqkjhsd
=A0 =A0To: sips:alice@atlanta.com;tag=3Dasdyka899=
=A0 =A0Call= -ID: asidkj3ss
=A0 =A0CSeq: 1201 BYE


Thanks,
Nataraju A.B.<= /font>
+91-98455-95744

--14dae9d67bd2cfc59104bde33b33-- From shida@ntt-at.com Tue Apr 17 17:08:06 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F2F11E80E0 for ; Tue, 17 Apr 2012 17:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.567 X-Spam-Level: X-Spam-Status: No, score=-101.567 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396, 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 iIzLIUOU-LBu for ; Tue, 17 Apr 2012 17:08:02 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 323F211E8086 for ; Tue, 17 Apr 2012 17:08:02 -0700 (PDT) Received: from [60.236.86.9] (port=50330 helo=[192.168.1.12]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SKIRF-0007nr-09; Tue, 17 Apr 2012 19:08:01 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Wed, 18 Apr 2012 09:07:58 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <8A41EEBD-DE37-4E5A-9B01-41F1F0C46380@ntt-at.com> References: To: "Worley, Dale R (Dale)" X-Mailer: Apple Mail (2.1257) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: flh1adm009.tky.mesh.ad.jp ([192.168.1.12]) [60.236.86.9]:50330 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-07, sections 1 to 5 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 00:08:06 -0000 Dale; Many thanks for your comments, my response inline. On Apr 18, 2012, at 1:56 AM, Worley, Dale R (Dale) wrote: > Here are some things that I think could be improved in sections 1 to 5 > of the 07 draft. They are listed in textual order. >=20 > Abstract >=20 > In addition, this specification defines a value for the Privacy > header field specific to the History-Info header field. >=20 > As in other places in the draft, mention is made that there *exists* a > related Privacy value without giving any hint of the *purpose* of the > value. This seems to me to be needlessly obscure. A better > description would be "This specification defines a value for the > Privacy header field that directs the anonymization of values in the > History-Info header field." Ok >=20 > 1. Introduction >=20 > the receiving application to determine hints about how and why the >=20 > should be >=20 > the receiving application to obtain information about how and why = the DONE >=20 > 2. Conventions and Terminology >=20 > process of a SIP entity changing a Uniform Resource Identifier (URI) > in a request based on the rules for determining request targets as >=20 > This sentence does not specify *which* URI in the request is being > changed. A better wording would be >=20 > process of a SIP entity changing the request-URI [RFC3261, section = 7.1] > in a request based on the rules for determining request targets as >=20 > The terms "target user" is used in this specification as the human > user associated with particular AoR or AoRs (in case the human user > has multiple alias). >=20 > The use of "alias" here is not particularly good. A better phrase > would be "in case the human user has multiple AoRs". DONE >=20 > 3. Background >=20 > Current network applications provide the ability for elements >=20 > should have added "Current network applications >>>for other > protocols<<< provide". DONE >=20 > 2. Email forwarding whereby the forwarded-to user obtains a > "history" of who sent the email to whom and at what time >=20 > More apropos is the fact that most e-mail systems add "Received" > lines, giving a detailed trace of the path of the message from sender > to receiver, and if the Received headers include the "for" clause, the > translation of the original destination address to the ultimate > recipient's address can be tracked. E.g., >=20 > Received: from eye.ariadne.com (eye.ariadne.com [127.0.0.1]) > by eye.ariadne.com (8.14.4/8.14.4) with ESMTP id = q3H8e3vI026332 > for ; Tue, 17 Apr 2012 04:40:03 -0400 > Received: from mail.comcast.net [76.96.58.11] > by eye.ariadne.com with POP3 (fetchmail-6.3.20) > for (single-drop); Tue, 17 Apr 2012 = 04:40:03 -0400 (EDT) > Received: from imta34.emeryville.ca.mail.comcast.net (LHLO > imta34.emeryville.ca.mail.comcast.net) (76.96.28.168) by > sz0045.wc.mail.comcast.net with LMTP; Tue, 17 Apr 2012 08:26:05 = +0000 (UTC) > Received: from VIMPORTPART.COM ([78.46.253.246]) > by imta34.emeryville.ca.mail.comcast.net with comcast > id ywS21i00o5KkC6e0awS2oh; Tue, 17 Apr 2012 08:26:03 +0000 > Received: by VIMPORTPART.COM (Postfix, from userid 0) > id 21D99831D7; Tue, 17 Apr 2012 10:26:02 +0200 (CEST) Tried to incorporate it.=20 >=20 > o Capturing aliases and Globally Routable User Agent URIs (GRUUs) > [RFC5627], which can be overwritten by a REGISTRAR or a "home >=20 > should be "registrar". DONE >=20 > 4. Overview >=20 > request to be changed by the same proxy/SIP Intermediary multiple >=20 > should be "intermediary". DONE >=20 > header field parameters, along with examples is provided in >=20 > reads better with a comma after "examples". DONE >=20 > In addition, this specification defines a priv-value for the Privacy > header, "history", that applies to all the History-info header field > entries in a Request or to a specific History-info header field hi- > entry as described above. Further detail is provided in > Section 10.1. >=20 > Again, this description does not state that the priv-value requires > that History-Info values be anonymized. Better would be >=20 > In addition, this specification defines a priv-value for the > Privacy header, "history", that >>>requires anonymization of<<< all > the >>>History-Info<<< header field entries in a Request or to a > specific History-info header field hi-entry as described above. > Further detail is provided in Section 10.1. DONE >=20 > And "History-info" needs to be capitalized as "History-Info". DONE >=20 > 5. History-Info Header Field Protocol Structure >=20 > these requests (ISSUER-req, see Appendix A). >=20 > It looks like this phrase is intended to be a reference to the > requirements listed in Appendix A. In that case, it should use > brackets [...] rather than parentheses (...). But since there are > only two such references (the other one is in section 13), it appears > that the references were incompletely removed. Otherwise there would > be many more of them. REMOVED. >=20 > parameter is a string of digits, separated by dots to indicate = the >=20 > There is a long history of using the term "string of digits" in these > drafts, despite that it's not a correct way to look at the syntax. > The syntax is a sequence of positive integers separated by dots and > the text should say that: >=20 > parameter is a sequence of positive integers, separated by dots > to indicate the >=20 > This results in a tree > representation of the history of the request, with the lowest- > level index reflecting a branch of the tree. >=20 > I'm not sure what is meant here. It is true that the lowest-level > index reflects a branch of the tree, but so do all the higher-level > indexes. I believe that what is intended is "leaf". FIXED >=20 > This > parameter contains either an "rc", "mp" or "np" header field > parameter, which is interpreted as follows: >=20 > "contains" should be "is". FIXED >=20 > "np": The hi-targeted-to-URI represents that there was no > change in Request-URI. This would apply for example when a > proxy merely forwards a request to a next hop proxy and loose > routing is used. >=20 > Unlike the previous two cases, this case does not describe the > function of the value of the np parameter. Any suggestion for rewording? >=20 > o Privacy: An optional parameter for History-Info, reflected in the > History-Info header field values by including the Privacy Header > [RFC3323] included in the hi- targeted-to-uri or by adding the > Privacy header field to the request. The latter case indicates > that the History-Info entries for the domain MUST be anonymized > prior to forwarding, whereas the use of the Privacy header field > included in the hi-targeted-to-uri means that a specific hi-entry > MUST be anonymized. >=20 > The phrase "the domain" is completely undefined here. I suspect you > mean something like "all History-Info entries whose hi-targeted-to-uri > has the same domain as the domain for which the SIP entity processing > the message is responsible". Sounds good.=20 >=20 > Note that the backslash and CRLF between the fields in > the examples below are for readability purposes only. >=20 > Was "lines" meant instead of "fields"? >=20 > Note that the backslash, CRLF and whitespace between the lines in > the examples below are inserted for readability purposes only. > (But History-Info can be broken into multiple lines due to the SWS > that is part of HCOLON, COMMA and SEMI, and there can be multiple > History-Info header fields due to the rule of section 7.3 > [RFC3261].) >=20 > History-Info: ;index=3D1;foo=3Dbar >=20 > History-Info: cause%3D302>;index=3D1.1,\ > cause%3D486>;index=3D1.2;mp=3D1.1,\ > ;index=3D1.3;rc=3D1.2 Will use this instead. >=20 > 5.1. History-Info Header Field Example Scenario >=20 > One important thing illustrated by this call flow is that without > History-Info, Bob would "lose" the target information, including any > parameters in the request URI. >=20 > It seems to me that "the target information" is ambiguous -- the > target information of which request would be lost when? You want to > say something like "the initial request-URI" or "the original target > information". >=20 > Note that an hi- > entry is not included for the fork to sip:bob@192.0.2.7 since there > was no response at the time the 200 OK is sent to Alice. >=20 > This would be a lot clearer if it was more detailed: >=20 > Note that in the 200 response to Alice, an hi-entry is not included > for the fork to sip:bob@192.0.2.7 (index 1.1.1) since > biloxi.example.com had not received a response from that fork at > the time it sent the 200 OK that ultimately reached Alice. >=20 > The formatting in this scenario is for visual purposes; thus, > backslash and CRLF are used between the fields for readability. >=20 > Although in fact there are no backslash-line breaks in the example. > If there were, it might be needed to mention the included whitespace > as in section 5. Removed. Many Thanks & Regards Shida >=20 > | | | Proxy Cancels INVITE | > | | |<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>| >=20 > Might be better illustrated by showing it as a CANCEL request: >=20 > | | | CANCEL | | > | | |-------------------------->| >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pravindran@sonusnet.com Tue Apr 17 22:01:34 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75C5521F857F for ; Tue, 17 Apr 2012 22:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WK-H+JrILvox for ; Tue, 17 Apr 2012 22:01:30 -0700 (PDT) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with ESMTP id E6DE921F8458 for ; Tue, 17 Apr 2012 22:01:29 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKT45KqdlrNrgiE1dJfN+F/Nr8Hes09PnO@postini.com; Tue, 17 Apr 2012 22:01:30 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 18 Apr 2012 01:02:02 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 10:31:23 +0530 From: "Ravindran, Parthasarathi" To: SIPCORE Chairs , "SIPCORE (Session Initiation Protocol Core) WG" Thread-Topic: Stateless or Transaction stateful proxy possible in Websocket transport? [RE: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: AQHNHSBiC8BxHa/YukW25Ena6sgXmw== Date: Wed, 18 Apr 2012 05:01:23 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> In-Reply-To: <4F8C5EC6.8090202@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 05:01:34 -0000 QXMgcGVyIG15IGN1cnJlbnQgcmVhZGluZywgVGhlIGN1cnJlbnQgZHJhZnQgYXNzdW1lcyBhYm91 dCBkaWFsb2ctc3RhdGVmdWwgcHJveHkgd2hlcmVpbiBhbGwgcmVjb3JkLXJvdXRlIGhlYWRlciB3 aWxsIGJlIGFkZGVkIHdoZW5ldmVyIFdlYnNvY2tldCB0byBvdGhlciB0cmFuc3BvcnQgcm91dGlu ZyBoYXBwZW5zIGluIHRoZSBwcm94eSBhbmQgcHJveHkgd2lsbCBiZSBpbnZvbHZlZCBpbiBhbGwg dGhlIHRyYW5zYWN0aW9uIHdpdGhpbiB0aGUgZGlhbG9nLiBTbywgaXQgaXMgbm90IHBvc3NpYmxl IHRvIGhhdmUgc3RhdGVsZXNzIG9yIHRyYW5zYWN0aW9uIHN0YXRlZnVsIHByb3h5LiBJdCB3aWxs IGJlIGdvb2QgaW4gY2FzZSB0aGlzIGxpbWl0YXRpb24gaXMgZXhwbGljaXRseSBtZW50aW9uZWQg aW4gdGhlIGRyYWZ0Lg0KDQpUaGFua3MNClBhcnRoYSANCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+RnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwY29yZS1i b3VuY2VzQGlldGYub3JnXSBPbg0KPkJlaGFsZiBPZiBBZGFtIFJvYWNoIC0gU0lQQ09SRSBDaGFp cg0KPlNlbnQ6IE1vbmRheSwgQXByaWwgMTYsIDIwMTIgMTE6MzMgUE0NCj5UbzogU0lQQ09SRSAo U2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIENvcmUpIFdHDQo+U3ViamVjdDogW3NpcGNvcmVd IENhbGwgZm9yIEFkb3B0aW9uOiBkcmFmdC1pYmMtc2lwY29yZS1zaXAtd2Vic29ja2V0LTAyDQo+ DQo+W2FzIGNoYWlyXQ0KPg0KPlNJUENPUkUgV29ya2luZyBHcm91cDoNCj4NCj5UaGlzIGlzIGEg Y2FsbCBmb3IgYWRvcHRpb24gb2YgdGhlIGRyYWZ0LWliYy1zaXBjb3JlLXNpcC13ZWJzb2NrZXQt MDINCj5kb2N1bWVudCB0byBzYXRpc2Z5IG91ciByZWNlbnRseSBhZGRlZCBtaWxlc3RvbmUgdG8g ZGVmaW5lIGEgV2ViU29ja2V0cw0KPnRyYW5zcG9ydCBmb3IgdGhlIFNJUCBwcm90b2NvbC4gSW50 ZXJlc3RlZCBwYXJ0aWVzIHNob3VsZCB2b2ljZSB0aGVpcg0KPnN1cHBvcnQgYW5kL29yIGNvbmNl cm5zIG9uIHRoZSBTSVBDT1JFIG1haWxpbmcgbGlzdC4gVGhlIGNoYWlycyBwbGFuIHRvDQo+bWFr ZSBhIGRldGVybWluYXRpb24gb2YgY29uc2Vuc3VzIG9uIEZyaWRheSwgQXByaWwgMjd0aC4NCj4N Cj5UaGFuayB5b3UuIFRoZSBkcmFmdCBhbm5vdW5jZW1lbnQgZm9sbG93cy4NCj4NCj4vYQ0KPg0K Pi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0NCj5TdWJqZWN0OiBbc2lwY29yZV0g TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1pYmMtc2lwY29yZS1zaXAtDQo+d2Vi c29ja2V0LTAyLnR4dA0KPkRhdGU6IE1vbiwgMTYgQXByIDIwMTIgMTg6NDk6MzggKzAyMDANCj5G cm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIDxpYmNAYWxpYXgubmV0Pg0KPlRvOiBTSVBDT1JFIFdH IDxzaXBjb3JlQGlldGYub3JnPg0KPg0KPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pYmMt c2lwY29yZS1zaXAtd2Vic29ja2V0LTAyLnR4dCBoYXMgYmVlbg0KPnN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgScOxYWtpIEJheiBDYXN0aWxsbyBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGDQo+cmVw b3NpdG9yeS4NCj4NCj5GaWxlbmFtZTogICAgICAgIGRyYWZ0LWliYy1zaXBjb3JlLXNpcC13ZWJz b2NrZXQNCj5SZXZpc2lvbjogICAgICAgIDAyDQo+VGl0bGU6ICAgICAgICAgICBUaGUgV2ViU29j a2V0IFByb3RvY29sIGFzIGEgVHJhbnNwb3J0IGZvciB0aGUgU2Vzc2lvbg0KPkluaXRpYXRpb24g UHJvdG9jb2wgKFNJUCkNCj5DcmVhdGlvbiBkYXRlOiAgIDIwMTItMDQtMTYNCj5XRyBJRDogICAg ICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KPk51bWJlciBvZiBwYWdlczogMjANCj4NCj5B YnN0cmFjdDoNCj4gICBUaGUgV2ViU29ja2V0IHByb3RvY29sIGVuYWJsZXMgdHdvLXdheSByZWFs dGltZSBjb21tdW5pY2F0aW9uIGJldHdlZW4NCj4gICBjbGllbnRzIGFuZCBzZXJ2ZXJzLiAgVGhp cyBkb2N1bWVudCBzcGVjaWZpZXMgYSBuZXcgV2ViU29ja2V0IHN1Yi0NCj4gICBwcm90b2NvbCBh cyBhIHJlbGlhYmxlIHRyYW5zcG9ydCBtZWNoYW5pc20gYmV0d2VlbiBTSVAgKFNlc3Npb24NCj4g ICBJbml0aWF0aW9uIFByb3RvY29sKSBlbnRpdGllcyBhbmQgZW5hYmxlcyB1c2FnZSBvZiB0aGUg U0lQIHByb3RvY29sDQo+ICAgaW4gbmV3IHNjZW5hcmlvcy4NCj4NCj4NCj4tIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWliYy1zaXBjb3JlLXNpcC13ZWJzb2NrZXQtMDINCj4tIGh0 dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1pYmMtc2lwY29yZS1zaXAtd2Vic29ja2V0LTAy LnR4dA0KPg0KPg0KPlRoaXMgbmV3IHZlcnNpb24gaW5jb3Jwb3JhdGVzIGltcHJvdmVtZW50cyBh bmQgY2hhbmdlcyBiYXNlZCBvbiB0aGUNCj5jb21tZW50cyBhbmQgcmV2aWV3cyBvbiB0aGUgcHJl dmlvdXMgdmVyc2lvbiwgYWxvbmcgd2l0aCB0aGUgY29uc2Vuc3VzDQo+Z290IGluIElFVEYgODMg UGFyaXMuDQo+DQo+DQo+QXMgdXN1YWwsIGNvbW1lbnRzIGFyZSB3ZWxjb21lLiBUaGFua3MgYSBs b3QuDQo+DQo+DQo+LS0NCj5Jw7Fha2kgQmF6IENhc3RpbGxvDQo+PGliY0BhbGlheC5uZXQ+DQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zaXBjb3Jl IG1haWxpbmcgbGlzdA0KPnNpcGNvcmVAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPnNpcGNvcmUgbWFpbGluZyBsaXN0DQo+c2lwY29yZUBpZXRmLm9y Zw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K From nataraju.sip@gmail.com Tue Apr 17 23:18:35 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28EE21F85C3 for ; Tue, 17 Apr 2012 23:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 tagged_above=-999 required=5 tests=[AWL=0.837, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 xlcneP3zGA8E for ; Tue, 17 Apr 2012 23:18:31 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 27D2F21F8606 for ; Tue, 17 Apr 2012 23:18:30 -0700 (PDT) Received: by lagj5 with SMTP id j5so5846929lag.31 for ; Tue, 17 Apr 2012 23:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=m1BFHEx9l4myNemMC9mEYr2Az3M9aPSJeXoMObr2jD0=; b=wUqofcuzbmIONgM6UWhT8DSIjKj3meU/05ll9EPDQ1n7DEJZPplh3M1RbhVqMFEVNR 52Kx+BoA3LkR5iqZ97JtpufIKMRyCpGK7HYJy1GfRsDSB7c0NoEM38xweeIbfFrmvyZC 0guibm9DWULHOCxHbP/za0O7ff8dsuHqKLA0u8WhdKDM08HJsIsyKU5V6I43ey+sDJAm 0JdVtmTSQEA78R7SBhdl9epRPogm2ImK0P6SjLwB0gu47b0uZIQ+TsUwzjaur6iAjAhC GjJMCNpbfExd2JFYFW3kdN+zwCQ+nMMKjvdSw4+htYLtIdACjuLhBNvtzwPealfDhynd legw== MIME-Version: 1.0 Received: by 10.112.25.40 with SMTP id z8mr318089lbf.95.1334729909792; Tue, 17 Apr 2012 23:18:29 -0700 (PDT) Received: by 10.112.103.103 with HTTP; Tue, 17 Apr 2012 23:18:29 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> Date: Wed, 18 Apr 2012 11:48:29 +0530 Message-ID: From: "Nataraju A.B" To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=f46d040122a324f02704bdee0608 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 06:18:35 -0000 --f46d040122a324f02704bdee0608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Partha, I also feel the same. The scenario is very similar to proxy interfacing between UDP and TCP on different sides, where dialog stateful proxy functionality is required. stateless / transaction stateful proxies would not work properly when requests are sent over different protocols. Thanks, Nataraju A B On Wed, Apr 18, 2012 at 10:31 AM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > As per my current reading, The current draft assumes about dialog-statefu= l > proxy wherein all record-route header will be added whenever Websocket to > other transport routing happens in the proxy and proxy will be involved i= n > all the transaction within the dialog. So, it is not possible to have > stateless or transaction stateful proxy. It will be good in case this > limitation is explicitly mentioned in the draft. > > Thanks > Partha > > >-----Original Message----- > >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > >Behalf Of Adam Roach - SIPCORE Chair > >Sent: Monday, April 16, 2012 11:33 PM > >To: SIPCORE (Session Initiation Protocol Core) WG > >Subject: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02 > > > >[as chair] > > > >SIPCORE Working Group: > > > >This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02 > >document to satisfy our recently added milestone to define a WebSockets > >transport for the SIP protocol. Interested parties should voice their > >support and/or concerns on the SIPCORE mailing list. The chairs plan to > >make a determination of consensus on Friday, April 27th. > > > >Thank you. The draft announcement follows. > > > >/a > > > >-------- Original Message -------- > >Subject: [sipcore] New Version Notification for draft-ibc-sipcore-sip- > >websocket-02.txt > >Date: Mon, 16 Apr 2012 18:49:38 +0200 > >From: I=F1aki Baz Castillo > >To: SIPCORE WG > > > >A new version of I-D, draft-ibc-sipcore-sip-websocket-02.txt has been > >successfully submitted by I=F1aki Baz Castillo and posted to the IETF > >repository. > > > >Filename: draft-ibc-sipcore-sip-websocket > >Revision: 02 > >Title: The WebSocket Protocol as a Transport for the Session > >Initiation Protocol (SIP) > >Creation date: 2012-04-16 > >WG ID: Individual Submission > >Number of pages: 20 > > > >Abstract: > > The WebSocket protocol enables two-way realtime communication between > > clients and servers. This document specifies a new WebSocket sub- > > protocol as a reliable transport mechanism between SIP (Session > > Initiation Protocol) entities and enables usage of the SIP protocol > > in new scenarios. > > > > > >- http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02 > >- http://tools.ietf.org/id/draft-ibc-sipcore-sip-websocket-02.txt > > > > > >This new version incorporates improvements and changes based on the > >comments and reviews on the previous version, along with the consensus > >got in IETF 83 Paris. > > > > > >As usual, comments are welcome. Thanks a lot. > > > > > >-- > >I=F1aki Baz Castillo > > > >_______________________________________________ > >sipcore mailing list > >sipcore@ietf.org > >https://www.ietf.org/mailman/listinfo/sipcore > >_______________________________________________ > >sipcore mailing list > >sipcore@ietf.org > >https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --=20 Thanks, Nataraju A.B. --f46d040122a324f02704bdee0608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Partha,=A0

I also feel the same. The scenario is very si= milar to proxy interfacing between UDP and TCP on different sides, where di= alog stateful proxy functionality is required. stateless / transaction stat= eful proxies would not work properly when requests are sent over different = protocols.

Thanks,
Nataraju A B

On Wed, Apr 18, 2012 at 10:31 AM, Ravindran, Parthasarathi <pravindran@sonusnet= .com> wrote:
As per my current reading, The current draft= assumes about dialog-stateful proxy wherein all record-route header will b= e added whenever Websocket to other transport routing happens in the proxy = and proxy will be involved in all the transaction within the dialog. So, it= is not possible to have stateless or transaction stateful proxy. It will b= e good in case this limitation is explicitly mentioned in the draft.

Thanks
Partha

>-----Original Message-----
>From: sipcore-bounces@ietf.= org [mailto:sipcore-bounces= @ietf.org] On
>Behalf Of Adam Roach - SIPCORE Chair
>Sent: Monday, April 16, 2012 11:33 PM
>To: SIPCORE (Session Initiation Protocol Core) WG
>Subject: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-0= 2
>
>[as chair]
>
>SIPCORE Working Group:
>
>This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02 >document to satisfy our recently added milestone to define a WebSockets=
>transport for the SIP protocol. Interested parties should voice their >support and/or concerns on the SIPCORE mailing list. The chairs plan to=
>make a determination of consensus on Friday, April 27th.
>
>Thank you. The draft announcement follows.
>
>/a
>
>-------- Original Message --------
>Subject: [sipcore] New Version Notification for draft-ibc-sipcore-sip-<= br> >websocket-02.txt
>Date: Mon, 16 Apr 2012 18:49:38 +0200
>From: I=F1aki Baz Castillo <ibc@ali= ax.net>
>To: SIPCORE WG <sipcore@ietf.org= >
>
>A new version of I-D, draft-ibc-sipcore-sip-websocket-02.txt has been >successfully submitted by I=F1aki Baz Castillo and posted to the IETF >repository.
>
>Filename: =A0 =A0 =A0 =A0draft-ibc-sipcore-sip-websocket
>Revision: =A0 =A0 =A0 =A002
>Title: =A0 =A0 =A0 =A0 =A0 The WebSocket Protocol as a Transport for th= e Session
>Initiation Protocol (SIP)
>Creation date: =A0 2012-04-16
>WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
>Number of pages: 20
>
>Abstract:
> =A0 The WebSocket protocol enables two-way realtime communication betw= een
> =A0 clients and servers. =A0This document specifies a new WebSocket su= b-
> =A0 protocol as a reliable transport mechanism between SIP (Session > =A0 Initiation Protocol) entities and enables usage of the SIP protoco= l
> =A0 in new scenarios.
>
>
>- http://tools.ietf.org/html/draft-ibc-sipcore-sip-web= socket-02
>- http://tools.ietf.org/id/draft-ibc-sipcore-sip-web= socket-02.txt
>
>
>This new version incorporates improvements and changes based on the
>comments and reviews on the previous version, along with the consensus<= br> >got in IETF 83 Paris.
>
>
>As usual, comments are welcome. Thanks a lot.
>
>
>--
>I=F1aki Baz Castillo
><ibc@aliax.net>
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org
>https://www.ietf.org/mailman/listinfo/sipcore
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org
>https://www.ietf.org/mailman/listinfo/sipcore
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore



--
Tha= nks,
Nataraju A.B.

--f46d040122a324f02704bdee0608-- From nataraju.sip@gmail.com Tue Apr 17 23:46:05 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F6621F85D3 for ; Tue, 17 Apr 2012 23:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, 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 0YktkzpKkurP for ; Tue, 17 Apr 2012 23:46:00 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C6E9A21F8572 for ; Tue, 17 Apr 2012 23:45:59 -0700 (PDT) Received: by lagj5 with SMTP id j5so5861701lag.31 for ; Tue, 17 Apr 2012 23:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Uiut9YI11NY1i4vAgUBsww7hH+gGe0RD7/nqNTsAdN8=; b=hPwML1bizor9+EM93S6jJMLNI2mJNShA3oWZt3fUxahoicFJMnvSL9AF55Jd9htMc5 6jUr5fg7tX0TcJMI2n8I7hzOuGbcGzpaPCJ60Z/azbG4Pexty50l5xfPyYVvnW0Ma7xU EkLoKxrD2UQgf+tX8LuSaBjixoTzWdXLL7hgcv+e7rc4rHvNYdIVY1gWtJ1yZ0wlny4S syckPtowOrgz5UEWqmkeM44p2HqgaOBCAKotyp5sXAGKc4WMe8BNtXzoCP/lJsYbuMuw eojJsFz+UyY27V6enUccxGcHzZdb6MZtP09QrHTAD8NFAHO+C2atPpqOO9yRMVrRbRMx Yu+Q== MIME-Version: 1.0 Received: by 10.152.162.68 with SMTP id xy4mr292216lab.49.1334731558572; Tue, 17 Apr 2012 23:45:58 -0700 (PDT) Received: by 10.112.103.103 with HTTP; Tue, 17 Apr 2012 23:45:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Apr 2012 12:15:58 +0530 Message-ID: From: "Nataraju A.B" To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=f46d044268226b541804bdee683d Cc: vpascual@acmepacket.com, jmillan@aliax.net, sipcore@ietf.org Subject: Re: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - Review comments (Nataraju A B) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 06:46:05 -0000 --f46d044268226b541804bdee683d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Inaki, Please find some more comments inline... Please let me know, the reasoning behind single transport parameter and two sent-protocol values. sent-protocol : WS and WSS transport =3D ws (only one new value) This might be confusing in future... To make the draft more readable, it may be a good idea to add transport parameter for WSS as well. transport =3D "UDP" / "TCP" / "TLS" / "SCTP" / "WS" */ "WSS"* / other-transport On Tue, Apr 17, 2012 at 10:55 PM, I=F1aki Baz Castillo wrot= e: > 2012/4/17 Nataraju A.B : > > Hi Authros, > > > > Please find some comments on the draft > > "draft-ibc-sipcore-sip-websocket-02.txt" > > > Hi Nataraju, thanks for your comments. We will address them. Some > replies inline: > > > > > ----------------------------------------------------- > > Section : 8.1. Registration > > CurrentText: > > F1 REGISTER Alice -> proxy.atlanta.com (transport WSS) > > > > REGISTER sip:proxy.atlanta.com SIP/2.0 > > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf > > > > F2 200 OK proxy.atlanta.com -> Alice (transport WSS) > > > > SIP/2.0 200 OK > > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf > > > > ReplacementText / Comment: > > > > If I understand right, > > Websocket connection is mapped on to SIP URI --> HTTP > > Secure Websocket connection is mapped on to SIPS URI --> HTTPS > > > > HTTP --> WS --> SIP URI --> port 80 > > > > HTTPS --> WSS --> SIPS URI --> port 443 > > > > Hence in the following messages "WSS" shall be replaced with "WS" > > > > F1 REGISTER Alice -> proxy.atlanta.com (transport WSS) > > > > REGISTER sip:proxy.atlanta.com SIP/2.0 > > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf > > > > WSS --> WS > > > > F2 200 OK proxy.atlanta.com -> Alice (transport WSS) > > > > SIP/2.0 200 OK > > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf > > > > WSS --> WS > > > Usage of a secure transport (like TLS-TCP or WSS) does not mandate > usage of SIPS schema. This is clearly explained in: > > http://tools.ietf.org/html/rfc5630#section-3.1.3 > > sec 3.1.3 . If one wants to use "best-effort TLS" for SIP, one just needs to use a SIP URI, and send the request over TLS. if we want to use SIP URI with any other secure communication mechanism like WSS, might require update to RFC5630. like sec 3.1.3 . If one wants to use "best-effort TLS/WSS" for SIP, one just needs to use a SIP URI, and send the request over TLS ** or any other secure transport mechanism like WSS** for these changes, you can add a new section "5.4 Updates to RFC 5630" Also add a normative reference for rfc5630 in sec "12.2. Informative References" [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009. > > > For example, REGISTER request looks like this (with WSS)... > > > > REGISTER sips:proxy.atlanta.com SIP/2.0 > > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf > > From: sips:alice@atlanta.com;tag=3D65bnmj.34asd > > To: sips:alice@atlanta.com > > Call-ID: aiuy7k9njasd > > CSeq: 1 REGISTER > > Max-Forwards: 70 > > Supported: path, outbound, gruu > > Contact: > > ;reg-id=3D1 > > ;+sip.instance=3D"" > > > > > > changes: > > sip --> sips in RURI, From, TO, contact headers > > As stated above this is not needed. WSS (or TLS-TCP) can be used > without using SIPS schema in SIP requests. That is a "best-effort TLS > / WSS". Also using Outbound RFC 5626 helps here since the Outbound > proxy (or the server the UA is connected to via TLS / WSS) can reuse > the existing connection for incoming requests. This is also explained > in http://tools.ietf.org/html/rfc5630#section-3.1.3. > > In summary: using a secure connection does not require using SIPS > schema in the requests sent over it. > > > > > > ----------------------------------------------------- > > Section : 8.2. INVITE dialog through a proxy > > CurrentText: > > > > F1 INVITE Alice -> proxy.atlanta.com (transport WSS) > > > > INVITE sip:bob@atlanta.com SIP/2.0 > > Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks > > From: sip:alice@atlanta.com;tag=3Dasdyka899 > > To: sip:bob@atlanta.com > > Call-ID: asidkj3ss > > CSeq: 1 INVITE > > Max-Forwards: 70 > > Supported: path, outbound, gruu > > Route: > > Contact: > ;gr=3Durn:uuid:f81-7dec-14a06cf1;ob>" > > Content-Type: application/sdp > > > > > > ReplacementText / Comment: > > > > Extra closing double quote in contact header. > > Typo, thanks :) > > [ABN] similar typo mistake in message F3 as well. > > > Contact: > ;gr=3Durn:uuid:f81-7dec-14a06cf1;ob> > > > > Route: > > > > change : > > 443-->80 assuming HTTP <-- WS <-- SIP URI > > This comment is applicable for messages F1, F3, F4, F5, F6, F8, > F9, > > F10, > > Same comments as above :) > > The example uses a secure WS connection (on top of TLS) but does not > use SIPS schema. > > [ABN] Probably for the sake of clarity, we can give call flow for Secure Web Socket (WSS) and non-secure Web Socket (WS). this content is already covered in different sections (this doc and rfc6455 as well). But putting it together with a call flow would make the concept more clearer. for all the messages WS, port 80 shall be used and port 443 for WSS. This is to make WS to be backward compatible with default HTTP and HTTPS ports. > > Changes > > WSS --> WS assuming HTTP <-- WS <-- SIP URI > > This comment is applicable for messages F1, F2, F3, F4, F5, F6, > F7, > > Idem. > > > > > > ----------------------------------------------------- > > Section : 1. Introduction > > > > CurrentText: > > Media transport is out of the scope of this document > > > > ReplacementText / Comment: > > Any other draft / rfc which addresses this issue. it would improve t= he > > readability of the document if we can is suggest reference for > > completeness. > > > > ----------------------------------------------------- > > We would not like to cover it. In case of web browsers, WebRTC > specification is defining RTP/SRTP/ICE/TURN for web applications. But > a SIP client using a WebSocket stack running in, i.e, a smartphone, > could use usual RTP for media transport. > > We don't want to focus the draft on "web browsers" use case. > > > > > Section : 5.1. General > > CurrentText: > > (typically web-based applications with an strict and simple API > > for receiving WebSocket messages). There is no need to establish > > > > > > ReplacementText / Comment: > > (typically web-based applications with **a** strict and simple AP= I > > for receiving WebSocket messages). There is no need to establish > > Typo :) > > > > > > Section : > > CurrentText: > > In the absence of an explicit port and DNS SRV resource records, the > > default port for a SIP URI with "ws" transport parameter is 80 in > > case of SIP scheme and 443 in case of SIPS scheme. > > > > > > ReplacementText / Comment: > > In the absence of an explicit port and DNS SRV resource records, the > > default port for a SIP URI with "ws" transport parameter is 80 in > > case of SIP scheme and 443 in case of SIPS scheme **, which is same = as > > that used for http and https protocols respectively** > > > > These ports have been used for the sake of backward compatibility with > > servers > > which does not support WS/WSS. > > > ??? > > ----------------------------------------------------- > > Section : > > CurrentText: > > > > _This section is non-normative._ > > > > ReplacementText / Comment: > > Some sections have been explicitly mentioned with this text. Does that > mean > > other sections are normative text. Not clear though. > > Basically yes. The style is the same as in RFC 6455 > (http://tools.ietf.org/html/rfc6455) in which non normative sections > include the above line. Any suggestion to make it better is of course > welcome. > > > > > Thanks a lot for your review, we will address all the topics covered in i= t. > > > -- > I=F1aki Baz Castillo > > --=20 Thanks, Nataraju A.B. --f46d044268226b541804bdee683d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Inaki,=A0

Please find some more comments inline...

<= div>
Please let me know, the reasoni= ng behind single transport parameter and two sent-protocol values.=A0
=
sent-protocol : WS and WSS
transport =3D ws (only one new value)<= /div>

This might be confusing in future...

To make the draft more readable, it=A0may=A0be a good= idea to add transport parameter for WSS as well.=A0

transport         =3D  "UDP" / "TCP=
" / "TLS" / "SCTP" / "WS" / "WSS=
"
                     / other-transport


O= n Tue, Apr 17, 2012 at 10:55 PM, I=F1aki Baz Castillo <= ;ibc@aliax.net> wrote:
2012/4/17 Nataraju A.B <nataraju.sip@gmail.com>:<= br>
> Hi Authros,
>
> Please find some comments on the draft
> "draft-ibc-sipcore-sip-websocket-02.txt"


Hi Nataraju, thanks for your comments. We will address them. Some
replies inline:



> -----------------------------------------------------
> Section : =A08.1. =A0Registration
> CurrentText:
> =A0 =A0F1 REGISTER =A0Alice -> proxy.atlanta.com (transport WSS)
>
> =A0 =A0REGISTER sip:proxy.atlanta.com SIP/2.0
> =A0 =A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf
>
> =A0 =A0F2 200 OK =A0proxy.atlanta.com -> Alice (transport WSS)
>
> =A0 =A0SIP/2.0 200 OK
> =A0 =A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf
>
> ReplacementText / Comment:
>
> If I understand right,
> =A0 =A0 =A0 =A0 =A0 Websocket connection is mapped on to SIP URI =A0--= > HTTP
> =A0 =A0Secure Websocket connection is mapped on to SIPS URI --> HTT= PS
>
> HTTP --> WS --> SIP URI --> port 80
>
> HTTPS --> WSS --> SIPS URI --> port 443
>
> Hence in the following messages "WSS" shall be replaced with= "WS"
>
> =A0 =A0F1 REGISTER =A0Alice -> proxy.atlanta.com (transport WSS)
>
> =A0 =A0REGISTER sip:proxy.atlanta.com SIP/2.0
> =A0 =A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf
>
> WSS --> WS
>
> =A0 =A0F2 200 OK =A0proxy.atlanta.com -> Alice (transport WSS)
>
> =A0 =A0SIP/2.0 200 OK
> =A0 =A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf
>
> WSS --> WS


Usage of a secure transport (like TLS-TCP or WSS) does not mandate usage of SIPS schema. This is clearly explained in:

=A0http://tools.ietf.org/html/rfc5630#section-3.1.3

<rfc5630> sec=A03.1.3.
   If on=
e wants to use "best-effort TLS" for SIP, one just needs to use
   a SIP URI, and send the request over TLS.
</rfc5= 630>

if we want to use SIP URI with any other secure= communication mechanism like WSS, might require=A0
update to RFC= 5630. like
<rfc5630> sec=A03.1.3.
   If on=
e wants to use "best-effort TLS/WSS" for SIP, one just needs to u=
se
   a SIP URI, and send the request over TLS ** or any other secure transpor=
t mechanism like WSS**
</rfc5630>

for these changes, you can add a new section "5.4=A0Updates to RFC 5630"

Also add a normative reference for rfc5630 in sec "= ;12.2. Informative References"

   [RFC5630]  Audet, F., "The Use of the SIPS URI Scheme in the Sessio=
n
              Initiation Protocol (SIP)", RFC 5630, October 2009.


> For example, REGISTER request looks like this (with WSS)...
>
> =A0 =A0REGISTER sips:proxy.atlanta.com SIP/2.0
> =A0 =A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bKasudf
> =A0 =A0From: sips:alice@atlanta.com;tag=3D65bnmj.34asd
> =A0 =A0To: sips:alice@atlanta.com
> =A0 =A0Call-ID: aiuy7k9njasd
> =A0 =A0CSeq: 1 REGISTER
> =A0 =A0Max-Forwards: 70
> =A0 =A0Supported: path, outbound, gruu
> =A0 =A0Contact: <sips:alice@df7jal23ls0d.invalid;transport=3Dws>=
> =A0 =A0 =A0;reg-id=3D1
> =A0 =A0 =A0;+sip.instance=3D"<urn:uuid:f81-7dec-14a06cf1>&q= uot;
>
>
> =A0 =A0changes:
> =A0 =A0sip --> sips in RURI, From, TO, contact headers

As stated above this is not needed. WSS (or TLS-TCP) can be used
without using SIPS schema in SIP requests. That is a "best-effort TLS<= br> / WSS". Also using Outbound RFC 5626 helps here since the Outbound
proxy (or the server the UA is connected to via TLS / WSS) can reuse
the existing connection for incoming requests. This is also explained
in http://tools.ietf.org/html/rfc5630#section-3.1.3.

In summary: using a secure connection does not require using SIPS
schema in the requests sent over it.




> -----------------------------------------------------
> Section : 8.2. =A0INVITE dialog through a proxy
> CurrentText:
>
> =A0 =A0F1 INVITE =A0Alice -> proxy.atlanta.com (transport WSS)
>
> =A0 =A0INVITE sip:bob@atlanta.com SIP/2.0
> =A0 =A0Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=3Dz9hG4bK56sdasks<= br> > =A0 =A0From: sip:alice@atlanta.com;tag=3Dasdyka899
> =A0 =A0To: = sip:bob@atlanta.com
> =A0 =A0Call-ID: asidkj3ss
> =A0 =A0CSeq: 1 INVITE
> =A0 =A0Max-Forwards: 70
> =A0 =A0Supported: path, outbound, gruu
> =A0 =A0Route: <sip:proxy.atlanta.com:443;transport=3Dws;lr>
> =A0 =A0Contact: <sip:alice@atlanta.com
> =A0 =A0 ;gr=3Durn:uuid:f81-7dec-14a06cf1;ob>"
> =A0 =A0Content-Type: application/sdp
>
>
> ReplacementText / Comment:
>
> =A0 =A0Extra closing double quote in contact header.

Typo, thanks :)

[ABN] similar typo mistake in message F3 a= s well.
=A0

> =A0 =A0 =A0 Contact: <sip:alice@atlanta.com
> =A0 =A0 =A0 =A0 =A0 ;gr=3Durn:uuid:f81-7dec-14a06cf1;ob>
>
> =A0 =A0Route: <sip:proxy.atlanta.com:80;transport=3Dws;lr>
>
> =A0 =A0change :
> =A0 =A0 =A0 =A0 443-->80 =A0 =A0 =A0 =A0 =A0 =A0 =A0assuming=A0HTTP= =A0<--=A0WS <-- SIP URI
> =A0 =A0 =A0 =A0 This comment is applicable for messages F1, F3, F4, F5= , F6, F8, F9,
> F10,

Same comments as above :)

The example uses a secure WS connection (on top of TLS) but does not
use SIPS schema.

=A0
[ABN] Probably for the sake = of clarity, we can give call flow for Secure Web Socket (WSS)=A0
= and non-secure Web Socket (WS). this content is already covered in differen= t sections (this doc and rfc6455 as well). But putting it together with a c= all flow would make the concept more clearer.

for all the messages WS, port 80 shall be used and port= 443 for WSS. This is to make WS to be backward compatible with default HTT= P and HTTPS ports.


> =A0 =A0Changes
> WSS --> WS =A0 =A0 =A0 =A0 =A0 =A0assuming=A0HTTP=A0<--=A0WS <= ;-- SIP URI
> =A0 =A0 =A0 =A0 This comment is applicable for messages F1, F2, F3, F4= , F5, F6, F7,

Idem.




> -----------------------------------------------------
> Section : 1. =A0Introduction
>
> CurrentText:
> Media transport is out of the scope of this document
>
> ReplacementText / Comment:
> =A0 =A0Any other draft / rfc which addresses this issue. it would impr= ove the
> =A0 =A0readability of the document if we can is suggest reference for<= br> > completeness.
>
> -----------------------------------------------------

We would not like to cover it. In case of web browsers, WebRTC
specification is defining RTP/SRTP/ICE/TURN for web applications. But
a SIP client using a WebSocket stack running in, i.e, a smartphone,
could use usual RTP for media transport.

We don't want to focus the draft on "web browsers" use case.<= br>



> Section : 5.1. =A0General
> CurrentText:
> =A0 =A0 =A0 (typically web-based applications with an strict and simpl= e API
> =A0 =A0 =A0 for receiving WebSocket messages). =A0There is no need to = establish
>
>
> ReplacementText / Comment:
> =A0 =A0 =A0 (typically web-based applications with **a** strict and si= mple API
> =A0 =A0 =A0 for receiving WebSocket messages). =A0There is no need to = establish

Typo :)




> Section :
> CurrentText:
> =A0 =A0In the absence of an explicit port and DNS SRV resource records= , the
> =A0 =A0default port for a SIP URI with "ws" transport parame= ter is 80 in
> =A0 =A0case of SIP scheme and 443 in case of SIPS scheme.
>
>
> ReplacementText / Comment:
> =A0 =A0In the absence of an explicit port and DNS SRV resource records= , the
> =A0 =A0default port for a SIP URI with "ws" transport parame= ter is 80 in
> =A0 =A0case of SIP scheme and 443 in case of SIPS scheme **, which is = same as
> =A0 =A0that used for http and https protocols respectively**
>
> These ports have been used for the sake of backward compatibility with=
> servers
> which does not support WS/WSS.
>
???=A0
=
> -----------------------------------------------------
> Section :
> CurrentText:
>
> =A0_This section is non-normative._
>
> ReplacementText / Comment:
> =A0Some sections have been explicitly mentioned with this text. Does t= hat mean
> =A0other sections are normative text. Not clear though.

Basically yes. The style is the same as in RFC 6455
(http://to= ols.ietf.org/html/rfc6455) in which non normative sections
include the above line. Any suggestion to make it better is of course
welcome.




Thanks a lot for your review, we will address all the topics covered in it.=


--
I=F1aki Baz Castillo
<ibc@aliax.net>= ;



--
Thanks,
Nataraju A.B.

--f46d044268226b541804bdee683d-- From pravindran@sonusnet.com Wed Apr 18 00:02:15 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAB821F84C5 for ; Wed, 18 Apr 2012 00:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 9Rag6WBZ-tmJ for ; Wed, 18 Apr 2012 00:02:11 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with ESMTP id 7F67F21F84B8 for ; Wed, 18 Apr 2012 00:02:10 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKT45m8ddaZATUjdHJ1D9GpQ1Ys9Le0DuS@postini.com; Wed, 18 Apr 2012 00:02:10 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 18 Apr 2012 03:02:43 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 12:32:02 +0530 From: "Ravindran, Parthasarathi" To: Nataraju A.B Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: AQHNHSsWQiKr/IZJokCfX43Mp6RbG5agJJrA Date: Wed, 18 Apr 2012 07:02:01 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E227F5Dinbamail01sonus_" MIME-Version: 1.0 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 07:02:15 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E227F5Dinbamail01sonus_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Nataraju, As per Sec 18 of RFC 3261 in , "All SIP elements MUST implement UDP and TCP= .", so it is possible to have stateless or transaction stateful proxy routi= ng with change in transport mechanism from UDP to TCP and vice versa. The s= imple scenario like INVITE transaction over TCP whereas Re-INVITE over UDP = based on contact SIP URI with UDP as a transport should work as per RFC 326= 1. In case of draft-ibc-sipcore-sip-websocket-02 draft, SIP UA over websocket = (like browser) will not implement either UDP or TCP transport which is a de= viation from RFC 3261. This deviation leads to this limitation of not havin= g stateless or Transaction stateful proxy in websocket transport. Thanks Partha From: Nataraju A.B [mailto:nataraju.sip@gmail.com] Sent: Wednesday, April 18, 2012 11:48 AM To: Ravindran, Parthasarathi Cc: SIPCORE Chairs; SIPCORE (Session Initiation Protocol Core) WG Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in = Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocke= t-02] Partha, I also feel the same. The scenario is very similar to proxy interfacing bet= ween UDP and TCP on different sides, where dialog stateful proxy functional= ity is required. stateless / transaction stateful proxies would not work pr= operly when requests are sent over different protocols. Thanks, Nataraju A B On Wed, Apr 18, 2012 at 10:31 AM, Ravindran, Parthasarathi > wrote: As per my current reading, The current draft assumes about dialog-stateful = proxy wherein all record-route header will be added whenever Websocket to o= ther transport routing happens in the proxy and proxy will be involved in a= ll the transaction within the dialog. So, it is not possible to have statel= ess or transaction stateful proxy. It will be good in case this limitation = is explicitly mentioned in the draft. Thanks Partha >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:si= pcore-bounces@ietf.org] On >Behalf Of Adam Roach - SIPCORE Chair >Sent: Monday, April 16, 2012 11:33 PM >To: SIPCORE (Session Initiation Protocol Core) WG >Subject: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02 > >[as chair] > >SIPCORE Working Group: > >This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02 >document to satisfy our recently added milestone to define a WebSockets >transport for the SIP protocol. Interested parties should voice their >support and/or concerns on the SIPCORE mailing list. The chairs plan to >make a determination of consensus on Friday, April 27th. > >Thank you. The draft announcement follows. > >/a > >-------- Original Message -------- >Subject: [sipcore] New Version Notification for draft-ibc-sipcore-sip- >websocket-02.txt >Date: Mon, 16 Apr 2012 18:49:38 +0200 >From: I=F1aki Baz Castillo > >To: SIPCORE WG > > >A new version of I-D, draft-ibc-sipcore-sip-websocket-02.txt has been >successfully submitted by I=F1aki Baz Castillo and posted to the IETF >repository. > >Filename: draft-ibc-sipcore-sip-websocket >Revision: 02 >Title: The WebSocket Protocol as a Transport for the Session >Initiation Protocol (SIP) >Creation date: 2012-04-16 >WG ID: Individual Submission >Number of pages: 20 > >Abstract: > The WebSocket protocol enables two-way realtime communication between > clients and servers. This document specifies a new WebSocket sub- > protocol as a reliable transport mechanism between SIP (Session > Initiation Protocol) entities and enables usage of the SIP protocol > in new scenarios. > > >- http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02 >- http://tools.ietf.org/id/draft-ibc-sipcore-sip-websocket-02.txt > > >This new version incorporates improvements and changes based on the >comments and reviews on the previous version, along with the consensus >got in IETF 83 Paris. > > >As usual, comments are welcome. Thanks a lot. > > >-- >I=F1aki Baz Castillo >> >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore -- Thanks, Nataraju A.B. --_000_387F9047F55E8C42850AD6B3A7A03C6C0E227F5Dinbamail01sonus_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Nataraju,

 <= /p>

As per Sec 18 of RFC 3261= in , “All SIP elements MUST implement UDP and TCP.”, so it is possible to have stateless or transacti= on stateful proxy routing with change in transport mechanism from UDP to TC= P and vice versa. The simple scenario like INVITE transaction over TCP whereas Re-INVITE over UDP based on contact SIP URI with UDP as a= transport should work as per RFC 3261.  

 <= /p>

In case of draft-ibc-sipc= ore-sip-websocket-02 draft, SIP UA over websocket (like browser) will not i= mplement either UDP or TCP transport which is a deviation from RFC 3261. This deviation leads to this limitation of not having state= less or Transaction stateful proxy in websocket transport.

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

From: Nataraju= A.B [mailto:nataraju.sip@gmail.com]
Sent: Wednesday, April 18, 2012 11:48 AM
To: Ravindran, Parthasarathi
Cc: SIPCORE Chairs; SIPCORE (Session Initiation Protocol Core) WG Subject: Re: [sipcore] Stateless or Transaction stateful proxy possi= ble in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-w= ebsocket-02]

 

Partha, 

 

I also feel the same. The scenario is very similar t= o proxy interfacing between UDP and TCP on different sides, where dialog st= ateful proxy functionality is required. stateless / transaction stateful pr= oxies would not work properly when requests are sent over different protocols.

 

Thanks,

Nataraju A B

On Wed, Apr 18, 2012 at 10:31 AM, Ravindran, Parthas= arathi <pravindran@sonusnet.c= om> wrote:

As per my current reading, The current draft assumes= about dialog-stateful proxy wherein all record-route header will be added = whenever Websocket to other transport routing happens in the proxy and prox= y will be involved in all the transaction within the dialog. So, it is not possible to have stateless or transaction= stateful proxy. It will be good in case this limitation is explicitly ment= ioned in the draft.

Thanks
Partha

>-----Original Message-----
>From: sipcore-bounces@ietf.= org [mailto:sipcore-bounces= @ietf.org] On
>Behalf Of Adam Roach - SIPCORE Chair
>Sent: Monday, April 16, 2012 11:33 PM
>To: SIPCORE (Session Initiation Protocol Core) WG
>Subject: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-0= 2
>
>[as chair]
>
>SIPCORE Working Group:
>
>This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02 >document to satisfy our recently added milestone to define a WebSockets=
>transport for the SIP protocol. Interested parties should voice their >support and/or concerns on the SIPCORE mailing list. The chairs plan to=
>make a determination of consensus on Friday, April 27th.
>
>Thank you. The draft announcement follows.
>
>/a
>
>-------- Original Message --------
>Subject: [sipcore] New Version Notification for draft-ibc-sipcore-sip-<= br> >websocket-02.txt
>Date: Mon, 16 Apr 2012 18:49:38 +0200
>From: I=F1aki Baz Castillo <ibc@ali= ax.net>
>To: SIPCORE WG <sipcore@ietf.org= >
>
>A new version of I-D, draft-ibc-sipcore-sip-websocket-02.txt has been >successfully submitted by I=F1aki Baz Castillo and posted to the IETF >repository.
>
>Filename:        draft-ibc-sipcore-sip-websocket >Revision:        02
>Title:           The WebSocket Protocol as a T= ransport for the Session
>Initiation Protocol (SIP)
>Creation date:   2012-04-16
>WG ID:           Individual Submission
>Number of pages: 20
>
>Abstract:
>   The WebSocket protocol enables two-way realtime communication b= etween
>   clients and servers.  This document specifies a new WebSoc= ket sub-
>   protocol as a reliable transport mechanism between SIP (Session=
>   Initiation Protocol) entities and enables usage of the SIP prot= ocol
>   in new scenarios.
>
>
>- http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02
>- http://tools.ietf.org/id/draft-ibc-sipcore-sip-websocket-02.txt
>
>
>This new version incorporates improvements and changes based on the
>comments and reviews on the previous version, along with the consensus<= br> >got in IETF 83 Paris.
>
>
>As usual, comments are welcome. Thanks a lot.
>
>
>--
>I=F1aki Baz Castillo
><ibc@aliax.net>
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org
>https://www.ietf.org/mailman/listinfo/sipcore
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org
>https://www.ietf.org/mailman/listinfo/sipcore
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore



 

--
Thanks,

Nataraju A.B.

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C0E227F5Dinbamail01sonus_-- From nataraju.sip@gmail.com Wed Apr 18 00:28:47 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B49421F85E7 for ; Wed, 18 Apr 2012 00:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.052 X-Spam-Level: X-Spam-Status: No, score=-2.052 tagged_above=-999 required=5 tests=[AWL=0.662, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 J1rcMMD0K5MU for ; Wed, 18 Apr 2012 00:28:43 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4DC121F85A0 for ; Wed, 18 Apr 2012 00:28:42 -0700 (PDT) Received: by lagj5 with SMTP id j5so5889396lag.31 for ; Wed, 18 Apr 2012 00:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SsT+RlcmJA9BoHfzCLFlBXdQcKegtSR/WdlY0+i65rk=; b=DvX386JgBHYITx4U+GB4bws4rV+1lpTwrc6Ujzon3HDxq+eknckP9zYSyC0V2Kys8L +14GyRh3ekNwAL+U7AuWEEiI/U84idkdXVR8aH2MGMiNqb1dqVstc284eMWpJZ22NEGd f8UKAZ2U3z968UZQ1M/j9reuY2cwjl5q1Dvg5RG78TzbYR+5wf/cMZW1VK99L52DyYmv leBxI/jLYeFeCZpfcNqzyagCCgeaGq5uhU65cQnUvEYGz6IOyEqXrB35iD5hkq64qHZh 1INMbZt6RY8TbdpWANori+JzOJdEF0W4gXN7LfTVXmppok638JzoZmLbJVmq/4VpyiVI w/jw== MIME-Version: 1.0 Received: by 10.112.25.40 with SMTP id z8mr409285lbf.95.1334734121603; Wed, 18 Apr 2012 00:28:41 -0700 (PDT) Received: by 10.112.103.103 with HTTP; Wed, 18 Apr 2012 00:28:41 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> Date: Wed, 18 Apr 2012 12:58:41 +0530 Message-ID: From: "Nataraju A.B" To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=f46d040122a33014d804bdef01fa Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 07:28:47 -0000 --f46d040122a33014d804bdef01fa Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Partha, I was referring to scenario, UAC Proxy UAS -----sips/tcp----> ------>sip/udp ---> UAC requested for a secure connection. But assume proxy at the edge and can't guarantee secure connection towards UAS. hence It is sending a request to UAS over simple udp *without security*. In this case, proxy must behave like a dialog stateful proxy. stateless or transaction stateful proxy can't inter work in this scenario. This is my understanding. Others please share your opinion on the same.... Thanks, Nataraju A B On Wed, Apr 18, 2012 at 12:32 PM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > Nataraju,** > > ** ** > > As per Sec 18 of RFC 3261 in , =93All SIP elements MUST implement UDP and > TCP.=94, so it is possible to have stateless or transaction stateful prox= y > routing with change in transport mechanism from UDP to TCP and vice versa= . > The simple scenario like INVITE transaction over TCP whereas Re-INVITE ov= er > UDP based on contact SIP URI with UDP as a transport should work as per R= FC > 3261. **** > > ** ** > > In case of draft-ibc-sipcore-sip-websocket-02 draft, SIP UA over websocke= t > (like browser) will not implement either UDP or TCP transport which is a > deviation from RFC 3261. This deviation leads to this limitation of not > having stateless or Transaction stateful proxy in websocket transport.***= * > > ** ** > > Thanks**** > > Partha**** > > ** ** > > *From:* Nataraju A.B [mailto:nataraju.sip@gmail.com] > *Sent:* Wednesday, April 18, 2012 11:48 AM > *To:* Ravindran, Parthasarathi > *Cc:* SIPCORE Chairs; SIPCORE (Session Initiation Protocol Core) WG > *Subject:* Re: [sipcore] Stateless or Transaction stateful proxy possible > in Websocket transport? [RE: Call for Adoption: > draft-ibc-sipcore-sip-websocket-02]**** > > ** ** > > Partha, **** > > ** ** > > I also feel the same. The scenario is very similar to proxy interfacing > between UDP and TCP on different sides, where dialog stateful proxy > functionality is required. stateless / transaction stateful proxies would > not work properly when requests are sent over different protocols.**** > > ** ** > > Thanks,**** > > Nataraju A B**** > > On Wed, Apr 18, 2012 at 10:31 AM, Ravindran, Parthasarathi < > pravindran@sonusnet.com> wrote:**** > > As per my current reading, The current draft assumes about dialog-statefu= l > proxy wherein all record-route header will be added whenever Websocket to > other transport routing happens in the proxy and proxy will be involved i= n > all the transaction within the dialog. So, it is not possible to have > stateless or transaction stateful proxy. It will be good in case this > limitation is explicitly mentioned in the draft. > > Thanks > Partha > > >-----Original Message----- > >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > >Behalf Of Adam Roach - SIPCORE Chair > >Sent: Monday, April 16, 2012 11:33 PM > >To: SIPCORE (Session Initiation Protocol Core) WG > >Subject: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02 > > > >[as chair] > > > >SIPCORE Working Group: > > > >This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02 > >document to satisfy our recently added milestone to define a WebSockets > >transport for the SIP protocol. Interested parties should voice their > >support and/or concerns on the SIPCORE mailing list. The chairs plan to > >make a determination of consensus on Friday, April 27th. > > > >Thank you. The draft announcement follows. > > > >/a > > > >-------- Original Message -------- > >Subject: [sipcore] New Version Notification for draft-ibc-sipcore-sip- > >websocket-02.txt > >Date: Mon, 16 Apr 2012 18:49:38 +0200 > >From: I=F1aki Baz Castillo > >To: SIPCORE WG > > > >A new version of I-D, draft-ibc-sipcore-sip-websocket-02.txt has been > >successfully submitted by I=F1aki Baz Castillo and posted to the IETF > >repository. > > > >Filename: draft-ibc-sipcore-sip-websocket > >Revision: 02 > >Title: The WebSocket Protocol as a Transport for the Session > >Initiation Protocol (SIP) > >Creation date: 2012-04-16 > >WG ID: Individual Submission > >Number of pages: 20 > > > >Abstract: > > The WebSocket protocol enables two-way realtime communication between > > clients and servers. This document specifies a new WebSocket sub- > > protocol as a reliable transport mechanism between SIP (Session > > Initiation Protocol) entities and enables usage of the SIP protocol > > in new scenarios. > > > > > >- http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02 > >- http://tools.ietf.org/id/draft-ibc-sipcore-sip-websocket-02.txt > > > > > >This new version incorporates improvements and changes based on the > >comments and reviews on the previous version, along with the consensus > >got in IETF 83 Paris. > > > > > >As usual, comments are welcome. Thanks a lot. > > > > > >-- > >I=F1aki Baz Castillo > > > >_______________________________________________ > >sipcore mailing list > >sipcore@ietf.org > >https://www.ietf.org/mailman/listinfo/sipcore > >_______________________________________________ > >sipcore mailing list > >sipcore@ietf.org > >https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore**** > > > > **** > > ** ** > > -- > Thanks,**** > > Nataraju A.B.**** > > ** ** > --=20 Thanks, Nataraju A.B. --f46d040122a33014d804bdef01fa Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Partha,= =A0

I was referring to scenario,=A0

=
UAC =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Proxy =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 UAS
=A0-----sips/tcp----> =A0 =A0 ------>sip/= udp --->

=
UAC requested for a secure connection. But assume proxy at the edg= e and can't guarantee secure connection towards UAS. hence It is sendin= g a request to UAS over simple udp without security.=A0

=
In this case, proxy must=A0behave=A0like a dialog stateful proxy. = stateless or transaction stateful proxy can't=A0inter work=A0in this sc= enario.=A0

=
This is my understanding. Others please share your opinion on the = same....

Thanks,
Nataraju A B

On Wed, Apr 18, 2012 at 12:32 PM, Ravindran, Parthasarathi <pravindran@sonusnet= .com> wrote:

Nataraju,

=A0<= /p>

As per Sec 18 of RFC 3261= in , =93All SIP elements MUST implement UDP and TCP.=94, so it is possible to have stateless or transacti= on stateful proxy routing with change in transport mechanism from UDP to TC= P and vice versa. The simple scenario like INVITE transaction over TCP whereas Re-INVITE over UDP based on contact SIP URI with UDP as a= transport should work as per RFC 3261. =A0

=A0<= /p>

In case of draft-ibc-sipc= ore-sip-websocket-02 draft, SIP UA over websocket (like browser) will not i= mplement either UDP or TCP transport which is a deviation from RFC 3261. This deviation leads to this limitation of not having state= less or Transaction stateful proxy in websocket transport.

=A0<= /p>

Thanks

Partha

=A0<= /p>

From: Nataraju= A.B [mailto:na= taraju.sip@gmail.com]
Sent: Wednesday, April 18, 2012 11:48 AM
To: Ravindran, Parthasarathi
Cc: SIPCORE Chairs; SIPCORE (Session Initiation Protocol Core) WG Subject: Re: [sipcore] Stateless or Transaction stateful proxy possi= ble in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-w= ebsocket-02]

=A0

Partha,=A0

=A0

I also feel the same. The scenario is very similar t= o proxy interfacing between UDP and TCP on different sides, where dialog st= ateful proxy functionality is required. stateless / transaction stateful pr= oxies would not work properly when requests are sent over different protocols.

=A0

Thanks,

Nataraju A B

On Wed, Apr 18, 2012 at 10:31 AM, Ravindran, Parthas= arathi <pra= vindran@sonusnet.com> wrote:

As per my current reading, The current draft assumes= about dialog-stateful proxy wherein all record-route header will be added = whenever Websocket to other transport routing happens in the proxy and prox= y will be involved in all the transaction within the dialog. So, it is not possible to have stateless or transaction= stateful proxy. It will be good in case this limitation is explicitly ment= ioned in the draft.

Thanks
Partha

>-----Original Message-----
>From: sip= core-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
>Behalf Of Adam Roach - SIPCORE Chair
>Sent: Monday, April 16, 2012 11:33 PM
>To: SIPCORE (Session Initiation Protocol Core) WG
>Subject: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-0= 2
>
>[as chair]
>
>SIPCORE Working Group:
>
>This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02 >document to satisfy our recently added milestone to define a WebSockets=
>transport for the SIP protocol. Interested parties should voice their >support and/or concerns on the SIPCORE mailing list. The chairs plan to=
>make a determination of consensus on Friday, April 27th.
>
>Thank you. The draft announcement follows.
>
>/a
>
>-------- Original Message --------
>Subject: [sipcore] New Version Notification for draft-ibc-sipcore-sip-<= br> >websocket-02.txt
>Date: Mon, 16 Apr 2012 18:49:38 +0200
>From: I=F1aki Baz Castillo <ibc@aliax.net>
>To: SIPCORE WG <sipcore@ietf.org>
>
>A new version of I-D, draft-ibc-sipcore-sip-websocket-02.txt has been >successfully submitted by I=F1aki Baz Castillo and posted to the IETF >repository.
>
>Filename: =A0 =A0 =A0 =A0draft-ibc-sipcore-sip-websocket
>Revision: =A0 =A0 =A0 =A002
>Title: =A0 =A0 =A0 =A0 =A0 The WebSocket Protocol as a Transport for th= e Session
>Initiation Protocol (SIP)
>Creation date: =A0 2012-04-16
>WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
>Number of pages: 20
>
>Abstract:
> =A0 The WebSocket protocol enables two-way realtime communication betw= een
> =A0 clients and servers. =A0This document specifies a new WebSocket su= b-
> =A0 protocol as a reliable transport mechanism between SIP (Session > =A0 Initiation Protocol) entities and enables usage of the SIP protoco= l
> =A0 in new scenarios.
>
>
>- http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02
>- http://tools.ietf.org/id/draft-ibc-sipcore-sip-websocket-02.txt
>
>
>This new version incorporates improvements and changes based on the
>comments and reviews on the previous version, along with the consensus<= br> >got in IETF 83 Paris.
>
>
>As usual, comments are welcome. Thanks a lot.
>
>
>--
>I=F1aki Baz Castillo
><ibc@aliax.net>
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/sipcore
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/sipcore
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore



=A0

--
Thanks,

Nataraju A.B.

=A0




--
Tha= nks,
Nataraju A.B.

--f46d040122a33014d804bdef01fa-- From ibc@aliax.net Wed Apr 18 01:17:12 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6104521F85AE for ; Wed, 18 Apr 2012 01:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=0.057, 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 Er8i85MlrviS for ; Wed, 18 Apr 2012 01:17:11 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38D1721F852E for ; Wed, 18 Apr 2012 01:17:11 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5537530vbb.31 for ; Wed, 18 Apr 2012 01:17:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=C2lvJ6awZkW6vDazmOhg9UPCpdDPa/56FcglXHTY+7U=; b=LP2ojV4urQAvspDmjG/YxbWUVnC59zy9hwaXiro2e0GGH72gROoLq/GlX3/MW94QM3 0jCcQw6/eThmWWNzcsNHq59IT/6PAmXYOksLfeC9MSdHXc2E2z87wYKIsknea8WnbpkK 8bP+gsPISGT/BypCMpHaIzpJErfID5nzD9zT9bDbSvKoxMH3DSGZfAVC6iD8c/g9Q7xm AzMKrU3Qw0kPMcOJlPkzDj46tUmOffr0PL9VkyrlUPyFrGL3xtkcw1G7zP06w6xryzVm 8vc9CAO9xhYNkIrgOY39oimqLOos8cyuFwkP0Ht/4eTRx0FQoyoXZ9f9R9pJdsM1pP3u gUbw== Received: by 10.52.91.72 with SMTP id cc8mr655580vdb.17.1334737030571; Wed, 18 Apr 2012 01:17:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 18 Apr 2012 01:16:50 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 18 Apr 2012 10:16:50 +0200 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnL33azgFpmf6L5m17Bg/uDfhWN9IIT71KuUbdZ0qxxtx9QqDYhTmiZCBSUVE7KM+Ap2xv3 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 08:17:12 -0000 2012/4/18 Ravindran, Parthasarathi : > As per my current reading, The current draft assumes about dialog-statefu= l proxy wherein all record-route header will be added whenever Websocket to= other transport routing happens in the proxy and proxy will be involved in= all the transaction within the dialog. Hi, the draft does not assume that. Perhaps you talk about the example scenario in the non-normative Appendix A?. Anyhow what you mean "dialog-stateful proxy" is incorrect (see below please= ). > So, it is not possible to have stateless or transaction stateful proxy. I= t will be good in case this limitation is explicitly mentioned in the draft= . AFAIR a proxy can be *transaction stateless* regardless it bridges different SIP transports. A stateless proxy is supposed to route responses based on Via header. In case of reliable transports, the first choice must be using the existing connection. If the *stateless* proxy adds ;received and ;rport to the Via in the incoming request, then it could later route responses to the UAC by inspecting those parameters in the responses and getting the associated connection. The proxy could also mantain a relationship between branch values and associated connections, but then it would be not so "stateless". Also, please don't mix "loose-routing" and "dialog-stateful". A pure SIP proxy performing loose-routing (in-dialog requests go through the proxy) can be a transaction stateful proxy but know nothing about "dialogs". Regards. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Wed Apr 18 01:23:37 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7C621F85FD for ; Wed, 18 Apr 2012 01:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.561 X-Spam-Level: X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 sTUjaI+02aMQ for ; Wed, 18 Apr 2012 01:23:32 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB9B21F866E for ; Wed, 18 Apr 2012 01:23:31 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKT456Ak8fRNNNLtTrQ+Di5GsSbo8arOoj@postini.com; Wed, 18 Apr 2012 01:23:31 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 18 Apr 2012 04:24:04 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 13:53:24 +0530 From: "Ravindran, Parthasarathi" To: Nataraju A.B Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: AQHNHSsWQiKr/IZJokCfX43Mp6RbG5agJJrA//+unYCAAGacsA== Date: Wed, 18 Apr 2012 08:23:23 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E227F98inbamail01sonus_" MIME-Version: 1.0 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 08:23:37 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E227F98inbamail01sonus_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Nataraju, As per Sec 20.42 of RFC 3261 SIPS URI indicates that the transport is TLS = (and not TCP) and the snippet is "When a request is sent to a SIPS URI, the protocol stil= l indicates "SIP", and the transport protocol is TLS." As per Sec 26.2.1 Para 7 of RFC 3261, TLS transport is hop-by-hop and not e= nd-to-end and RFC Snippet is as follows: "Note that transport mechanisms are specified on a hop-by-hop basis in SIP, thus a UA that sends requests over TLS to a proxy server has no assurance that TLS will be used end-to-end." Please note that SIP UA with TLS transport is not going to violate Sec 18 o= f RFC 3261 "All SIP elements MUST implement UDP and TCP.". In the below mentioned callflow, pr= oxy shall acts as stateless or transaction stateful proxy wherein UAC shall sent INVI= TE with SIPS URI towards proxy, proxy forwards INVITE in UDP/TCP towards UAS and receive con= tact with UDP/TCP as a transport in 2xx response from UAS, 2xx is forwarded towards UAC. Here= , UAC is expected to send RE-INVITE/BYE towards UAS with transport as UDP/TCP. So, it is possibl= e to interwork with TLS to UDP/TCP as per RFC 3261. In case you mention the same above logic of TLS applies to Websocket, anybo= dy implement SIP over websocket in browser using JavaScript violates RFC 3261 as it is not p= ossible for browser to send REINVITE/BYE using UDP/TCP transport towards UAS directly with statele= ss/Transaction stateful proxy as a first proxy hop. Thanks Partha From: Nataraju A.B [mailto:nataraju.sip@gmail.com] Sent: Wednesday, April 18, 2012 12:59 PM To: Ravindran, Parthasarathi Cc: SIPCORE Chairs; SIPCORE (Session Initiation Protocol Core) WG Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in = Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocke= t-02] Partha, I was referring to scenario, UAC Proxy UAS -----sips/tcp----> ------>sip/udp ---> UAC requested for a secure connection. But assume proxy at the edge and can= 't guarantee secure connection towards UAS. hence It is sending a request t= o UAS over simple udp without security. In this case, proxy must behave like a dialog stateful proxy. stateless or = transaction stateful proxy can't inter work in this scenario. This is my understanding. Others please share your opinion on the same.... Thanks, Nataraju A B On Wed, Apr 18, 2012 at 12:32 PM, Ravindran, Parthasarathi > wrote: Nataraju, As per Sec 18 of RFC 3261 in , "All SIP elements MUST implement UDP and TCP= .", so it is possible to have stateless or transaction stateful proxy routi= ng with change in transport mechanism from UDP to TCP and vice versa. The s= imple scenario like INVITE transaction over TCP whereas Re-INVITE over UDP = based on contact SIP URI with UDP as a transport should work as per RFC 326= 1. In case of draft-ibc-sipcore-sip-websocket-02 draft, SIP UA over websocket = (like browser) will not implement either UDP or TCP transport which is a de= viation from RFC 3261. This deviation leads to this limitation of not havin= g stateless or Transaction stateful proxy in websocket transport. Thanks Partha From: Nataraju A.B [mailto:nataraju.sip@gmail.com] Sent: Wednesday, April 18, 2012 11:48 AM To: Ravindran, Parthasarathi Cc: SIPCORE Chairs; SIPCORE (Session Initiation Protocol Core) WG Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in = Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocke= t-02] Partha, I also feel the same. The scenario is very similar to proxy interfacing bet= ween UDP and TCP on different sides, where dialog stateful proxy functional= ity is required. stateless / transaction stateful proxies would not work pr= operly when requests are sent over different protocols. Thanks, Nataraju A B On Wed, Apr 18, 2012 at 10:31 AM, Ravindran, Parthasarathi > wrote: As per my current reading, The current draft assumes about dialog-stateful = proxy wherein all record-route header will be added whenever Websocket to o= ther transport routing happens in the proxy and proxy will be involved in a= ll the transaction within the dialog. So, it is not possible to have statel= ess or transaction stateful proxy. It will be good in case this limitation = is explicitly mentioned in the draft. Thanks Partha >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:si= pcore-bounces@ietf.org] On >Behalf Of Adam Roach - SIPCORE Chair >Sent: Monday, April 16, 2012 11:33 PM >To: SIPCORE (Session Initiation Protocol Core) WG >Subject: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-02 > >[as chair] > >SIPCORE Working Group: > >This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02 >document to satisfy our recently added milestone to define a WebSockets >transport for the SIP protocol. Interested parties should voice their >support and/or concerns on the SIPCORE mailing list. The chairs plan to >make a determination of consensus on Friday, April 27th. > >Thank you. The draft announcement follows. > >/a > >-------- Original Message -------- >Subject: [sipcore] New Version Notification for draft-ibc-sipcore-sip- >websocket-02.txt >Date: Mon, 16 Apr 2012 18:49:38 +0200 >From: I=F1aki Baz Castillo > >To: SIPCORE WG > > >A new version of I-D, draft-ibc-sipcore-sip-websocket-02.txt has been >successfully submitted by I=F1aki Baz Castillo and posted to the IETF >repository. > >Filename: draft-ibc-sipcore-sip-websocket >Revision: 02 >Title: The WebSocket Protocol as a Transport for the Session >Initiation Protocol (SIP) >Creation date: 2012-04-16 >WG ID: Individual Submission >Number of pages: 20 > >Abstract: > The WebSocket protocol enables two-way realtime communication between > clients and servers. This document specifies a new WebSocket sub- > protocol as a reliable transport mechanism between SIP (Session > Initiation Protocol) entities and enables usage of the SIP protocol > in new scenarios. > > >- http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02 >- http://tools.ietf.org/id/draft-ibc-sipcore-sip-websocket-02.txt > > >This new version incorporates improvements and changes based on the >comments and reviews on the previous version, along with the consensus >got in IETF 83 Paris. > > >As usual, comments are welcome. Thanks a lot. > > >-- >I=F1aki Baz Castillo >> >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore -- Thanks, Nataraju A.B. -- Thanks, Nataraju A.B. --_000_387F9047F55E8C42850AD6B3A7A03C6C0E227F98inbamail01sonus_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Nataraju,

 <= /p>

As per Sec 20.42 of RFC 3= 261  SIPS URI indicates that the transport is TLS (and not TCP)

and the snippet is “= ;When a request is sent to a SIPS URI, the protocol still indicates "S= IP",

and the transport protoco= l is TLS.”

 <= /p>

As per Sec 26.2.1 Para 7 = of RFC 3261, TLS transport is hop-by-hop and not end-to-end and RFC

Snippet is as follows:

 <= /p>

“Note that

transport mechanisms are specified on a hop-by-hop basis i= n SIP, thus

a UA that sends requests over TLS to a proxy server has no= assurance

that TLS will be used end-to-end.”=

 

Please note that SIP UA w= ith TLS transport is not going to violate Sec 18 of RFC 3261 “= All SIP

elements MUST implement UDP and TCP.”.  <= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1F497D">In the below mentioned callflow, proxy shall=

acts as stateless or tran= saction stateful proxy wherein UAC shall sent INVITE with SIPS URI

towards proxy, proxy forw= ards INVITE in UDP/TCP towards UAS and receive contact with UDP/TCP

as a transport in 2xx res= ponse from UAS, 2xx is forwarded towards UAC. Here, UAC is expected to

send RE-INVITE/BYE toward= s UAS with transport as UDP/TCP. So, it is possible to interwork with

TLS to UDP/TCP as per RFC= 3261.

 <= /p>

In case you mention the s= ame above logic of TLS applies to Websocket, anybody implement SIP

over websocket in browser= using JavaScript violates RFC 3261 as it is not possible for browser to

send REINVITE/BYE using U= DP/TCP transport towards UAS directly with stateless/Transaction=

stateful proxy as a first= proxy hop.

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

 <= /p>

From: Nataraju= A.B [mailto:nataraju.sip@gmail.com]
Sent: Wednesday, April 18, 2012 12:59 PM
To: Ravindran, Parthasarathi
Cc: SIPCORE Chairs; SIPCORE (Session Initiation Protocol Core) WG Subject: Re: [sipcore] Stateless or Transaction stateful proxy possi= ble in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-w= ebsocket-02]

 

Partha, 

 

I was referring to scenario, 

 

UAC                 &= nbsp;Proxy                   U= AS

 -----sips/tcp---->     ------>sip/udp -= -->

 

UAC requested for a secure connection. But assume proxy at th= e edge and can't guarantee secure connection towards UAS. hence It is sendi= ng a request to UAS over simple udp without security. 

 

In this case, proxy must behave like a dialog state= ful proxy. stateless or transaction stateful proxy can't inter work&nb= sp;in this scenario. 

 

This is my understanding. Others please share your opinion on= the same....

Thanks,

Nataraju A B

 

On Wed, Apr 18, 2012 at 12:32 PM, Ravindran, Parthas= arathi <pravindran@sonusnet.c= om> wrote:

Nataraju,

 

As per Sec 18 of RFC 3261 in , “<= /span>All SIP elements MUST implement UDP and TCP.”, so it is possible to have stateless or transacti= on stateful proxy routing with change in transport mechanism from UDP to TC= P and vice versa. The simple scenario like INVITE transaction over TCP whereas Re-INVITE over UDP based on contact SIP URI with UDP as a= transport should work as per RFC 3261.  

 

In case of draft-ibc-sipcore-sip-websoc= ket-02 draft, SIP UA over websocket (like browser) will not implement either UDP or TCP transport which is a deviation from RFC 3261. = This deviation leads to this limitation of not having stateless or Transact= ion stateful proxy in websocket transport.

 

Thanks

Partha

 

From: Nataraju A.B [mailto:<= a href=3D"mailto:nataraju.sip@gmail.com" target=3D"_blank">nataraju.sip@gma= il.com]
Sent: Wednesday, April 18, 2012 11:48 AM
To: Ravindran, Parthasarathi
Cc: SIPCORE Chairs; SIPCORE (Session Initiation Protocol Core) WG Subject: Re: [sipcore] Stateless or Transaction stateful proxy possi= ble in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-w= ebsocket-02]

 

Partha, 

 

I also feel the same. The scenario is very similar to proxy interf= acing between UDP and TCP on different sides, where dialog stateful proxy f= unctionality is required. stateless / transaction stateful proxies would not work properly when requests are s= ent over different protocols.

 

Thanks,

Nataraju A B

On Wed, Apr 18, 2012 at 10:31 AM, Ravindran, Parthasarathi <pravindran@sonusn= et.com> wrote:

As per my current reading, The current draft assumes about dialog-= stateful proxy wherein all record-route header will be added whenever Webso= cket to other transport routing happens in the proxy and proxy will be involved in all the transaction within the = dialog. So, it is not possible to have stateless or transaction stateful pr= oxy. It will be good in case this limitation is explicitly mentioned in the= draft.

Thanks
Partha

>-----Original Message-----
>From: sip= core-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
>Behalf Of Adam Roach - SIPCORE Chair
>Sent: Monday, April 16, 2012 11:33 PM
>To: SIPCORE (Session Initiation Protocol Core) WG
>Subject: [sipcore] Call for Adoption: draft-ibc-sipcore-sip-websocket-0= 2
>
>[as chair]
>
>SIPCORE Working Group:
>
>This is a call for adoption of the draft-ibc-sipcore-sip-websocket-02 >document to satisfy our recently added milestone to define a WebSockets=
>transport for the SIP protocol. Interested parties should voice their >support and/or concerns on the SIPCORE mailing list. The chairs plan to=
>make a determination of consensus on Friday, April 27th.
>
>Thank you. The draft announcement follows.
>
>/a
>
>-------- Original Message --------
>Subject: [sipcore] New Version Notification for draft-ibc-sipcore-sip-<= br> >websocket-02.txt
>Date: Mon, 16 Apr 2012 18:49:38 +0200
>From: I=F1aki Baz Castillo <ibc@aliax.net>
>To: SIPCORE WG <sipcore@ietf.org>
>
>A new version of I-D, draft-ibc-sipcore-sip-websocket-02.txt has been >successfully submitted by I=F1aki Baz Castillo and posted to the IETF >repository.
>
>Filename:        draft-ibc-sipcore-sip-websocket >Revision:        02
>Title:           The WebSocket Protocol as a T= ransport for the Session
>Initiation Protocol (SIP)
>Creation date:   2012-04-16
>WG ID:           Individual Submission
>Number of pages: 20
>
>Abstract:
>   The WebSocket protocol enables two-way realtime communication b= etween
>   clients and servers.  This document specifies a new WebSoc= ket sub-
>   protocol as a reliable transport mechanism between SIP (Session=
>   Initiation Protocol) entities and enables usage of the SIP prot= ocol
>   in new scenarios.
>
>
>- http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02
>- http://tools.ietf.org/id/draft-ibc-sipcore-sip-websocket-02.txt
>
>
>This new version incorporates improvements and changes based on the
>comments and reviews on the previous version, along with the consensus<= br> >got in IETF 83 Paris.
>
>
>As usual, comments are welcome. Thanks a lot.
>
>
>--
>I=F1aki Baz Castillo
><ibc@aliax.net>
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/sipcore
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org<= /a>
>https://www.ietf.org/mailman/listinfo/sipcore
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore



 

--
Thanks,

Nataraju A.B.

 



 

--
Thanks,

Nataraju A.B.

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C0E227F98inbamail01sonus_-- From pravindran@sonusnet.com Wed Apr 18 01:35:20 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9554421F85DD for ; Wed, 18 Apr 2012 01:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 O3uQLHvG7nHC for ; Wed, 18 Apr 2012 01:35:20 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id AA59721F85D9 for ; Wed, 18 Apr 2012 01:35:19 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKT458x1FN/1IESP5Uv0GMVSrP9vI37Hs3@postini.com; Wed, 18 Apr 2012 01:35:19 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 18 Apr 2012 04:35:52 -0400 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.0355.002; Wed, 18 Apr 2012 14:05:13 +0530 From: "Ravindran, Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: AQHNHTupXihLS9X/ZUKRVp6Pv6bwkZagP0yg Date: Wed, 18 Apr 2012 08:35:12 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E227FB9@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 08:35:20 -0000 SW5ha2ksDQoNClBsZWFzZSBwcm92aWRlIFNJUCBvdmVyIFdlYmV4YW1wbGUgZXhhbXBsZSB3aXRo b3V0IHJlY29yZC1yb3V0ZSBhbmQgMnh4IHJlc3BvbnNlIGZyb20gVUFTIHdpdGggVURQL1RDUCB0 cmFuc3BvcnQgaW4gY29udGFjdCBoZWFkZXIsIHRoZW4gaXQgd2lsbCBiZSBvYnZpb3VzIHdoeSBp dCBpcyBub3QgcG9zc2libGUgdG8gYmUgdHJhbnNhY3Rpb24gc3RhdGVmdWwgcHJveHkgZm9yIFdl YnNvY2tldCB0byBVRFAvVENQIHRyYW5zcG9ydCBjb252ZXJzaW9uLiBJIGhhdmUgY2xhcmlmaWVk IHRob3NlIHNjZW5hcmlvIGluIHRoZSBhbm90aGVyIG1haWwgdGhyZWFkIHRvIE5hdGFyYWp1LiAN Cg0KVGhhbmtzDQpQYXJ0aGEgDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206 IEnDsWFraSBCYXogQ2FzdGlsbG8gW21haWx0bzppYmNAYWxpYXgubmV0XQ0KPlNlbnQ6IFdlZG5l c2RheSwgQXByaWwgMTgsIDIwMTIgMTo0NyBQTQ0KPlRvOiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0 aGkNCj5DYzogU0lQQ09SRSBDaGFpcnM7IFNJUENPUkUgKFNlc3Npb24gSW5pdGlhdGlvbiBQcm90 b2NvbCBDb3JlKSBXRw0KPlN1YmplY3Q6IFJlOiBbc2lwY29yZV0gU3RhdGVsZXNzIG9yIFRyYW5z YWN0aW9uIHN0YXRlZnVsIHByb3h5IHBvc3NpYmxlDQo+aW4gV2Vic29ja2V0IHRyYW5zcG9ydD8g W1JFOiBDYWxsIGZvciBBZG9wdGlvbjogZHJhZnQtaWJjLXNpcGNvcmUtc2lwLQ0KPndlYnNvY2tl dC0wMl0NCj4NCj4yMDEyLzQvMTggUmF2aW5kcmFuLCBQYXJ0aGFzYXJhdGhpIDxwcmF2aW5kcmFu QHNvbnVzbmV0LmNvbT46DQo+PiBBcyBwZXIgbXkgY3VycmVudCByZWFkaW5nLCBUaGUgY3VycmVu dCBkcmFmdCBhc3N1bWVzIGFib3V0IGRpYWxvZy0NCj5zdGF0ZWZ1bCBwcm94eSB3aGVyZWluIGFs bCByZWNvcmQtcm91dGUgaGVhZGVyIHdpbGwgYmUgYWRkZWQgd2hlbmV2ZXINCj5XZWJzb2NrZXQg dG8gb3RoZXIgdHJhbnNwb3J0IHJvdXRpbmcgaGFwcGVucyBpbiB0aGUgcHJveHkgYW5kIHByb3h5 IHdpbGwNCj5iZSBpbnZvbHZlZCBpbiBhbGwgdGhlIHRyYW5zYWN0aW9uIHdpdGhpbiB0aGUgZGlh bG9nLg0KPg0KPkhpLCB0aGUgZHJhZnQgZG9lcyBub3QgYXNzdW1lIHRoYXQuIFBlcmhhcHMgeW91 IHRhbGsgYWJvdXQgdGhlIGV4YW1wbGUNCj5zY2VuYXJpbyBpbiB0aGUgbm9uLW5vcm1hdGl2ZSBB cHBlbmRpeCBBPy4NCj4NCj5Bbnlob3cgd2hhdCB5b3UgbWVhbiAiZGlhbG9nLXN0YXRlZnVsIHBy b3h5IiBpcyBpbmNvcnJlY3QgKHNlZSBiZWxvdw0KPnBsZWFzZSkuDQo+DQo+DQo+DQo+PiBTbywg aXQgaXMgbm90IHBvc3NpYmxlIHRvIGhhdmUgc3RhdGVsZXNzIG9yIHRyYW5zYWN0aW9uIHN0YXRl ZnVsDQo+cHJveHkuIEl0IHdpbGwgYmUgZ29vZCBpbiBjYXNlIHRoaXMgbGltaXRhdGlvbiBpcyBl eHBsaWNpdGx5IG1lbnRpb25lZA0KPmluIHRoZSBkcmFmdC4NCj4NCj5BRkFJUiBhIHByb3h5IGNh biBiZSAqdHJhbnNhY3Rpb24gc3RhdGVsZXNzKiByZWdhcmRsZXNzIGl0IGJyaWRnZXMNCj5kaWZm ZXJlbnQgU0lQIHRyYW5zcG9ydHMuIEEgc3RhdGVsZXNzIHByb3h5IGlzIHN1cHBvc2VkIHRvIHJv dXRlDQo+cmVzcG9uc2VzIGJhc2VkIG9uIFZpYSBoZWFkZXIuIEluIGNhc2Ugb2YgcmVsaWFibGUg dHJhbnNwb3J0cywgdGhlIGZpcnN0DQo+Y2hvaWNlIG11c3QgYmUgdXNpbmcgdGhlIGV4aXN0aW5n IGNvbm5lY3Rpb24uIElmIHRoZSAqc3RhdGVsZXNzKiBwcm94eQ0KPmFkZHMgO3JlY2VpdmVkIGFu ZCA7cnBvcnQgdG8gdGhlIFZpYSBpbiB0aGUgaW5jb21pbmcgcmVxdWVzdCwgdGhlbiBpdA0KPmNv dWxkIGxhdGVyIHJvdXRlIHJlc3BvbnNlcyB0byB0aGUgVUFDIGJ5IGluc3BlY3RpbmcgdGhvc2Ug cGFyYW1ldGVycyBpbg0KPnRoZSByZXNwb25zZXMgYW5kIGdldHRpbmcgdGhlIGFzc29jaWF0ZWQg Y29ubmVjdGlvbi4gVGhlIHByb3h5IGNvdWxkDQo+YWxzbyBtYW50YWluIGEgcmVsYXRpb25zaGlw IGJldHdlZW4gYnJhbmNoIHZhbHVlcyBhbmQgYXNzb2NpYXRlZA0KPmNvbm5lY3Rpb25zLCBidXQg dGhlbiBpdCB3b3VsZCBiZSBub3Qgc28gInN0YXRlbGVzcyIuDQo+DQo+DQo+QWxzbywgcGxlYXNl IGRvbid0IG1peCAibG9vc2Utcm91dGluZyIgYW5kICJkaWFsb2ctc3RhdGVmdWwiLiBBIHB1cmUg U0lQDQo+cHJveHkgcGVyZm9ybWluZyBsb29zZS1yb3V0aW5nIChpbi1kaWFsb2cgcmVxdWVzdHMg Z28gdGhyb3VnaCB0aGUNCj5wcm94eSkgY2FuIGJlIGEgdHJhbnNhY3Rpb24gc3RhdGVmdWwgcHJv eHkgYnV0IGtub3cgbm90aGluZyBhYm91dA0KPiJkaWFsb2dzIi4NCj4NCj4NCj5SZWdhcmRzLg0K Pg0KPg0KPi0tDQo+ScOxYWtpIEJheiBDYXN0aWxsbw0KPjxpYmNAYWxpYXgubmV0Pg0K From pravindran@sonusnet.com Wed Apr 18 01:44:14 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9725821F8566 for ; Wed, 18 Apr 2012 01:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 N-PLKejmkEvJ for ; Wed, 18 Apr 2012 01:44:14 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with ESMTP id 960CA21F844A for ; Wed, 18 Apr 2012 01:44:13 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKT45+3QFUGK7r+FgWR82yAzoC8g7xsigS@postini.com; Wed, 18 Apr 2012 01:44:13 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 18 Apr 2012 04:44:45 -0400 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.0355.002; Wed, 18 Apr 2012 14:14:05 +0530 From: "Ravindran, Parthasarathi" To: "Ravindran, Parthasarathi" , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: AQHNHTupXihLS9X/ZUKRVp6Pv6bwkZagP0yggAAEdNA= Date: Wed, 18 Apr 2012 08:44:06 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E227FCA@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 08:44:14 -0000 T25lIG1pbm9yIGNvcnJlY3Rpb24sIEkgYWdyZWUgdGhhdCBkaWFsb2ctc3RhdGVmdWwgcHJveHkg aXMgbm90IG1hbmRhdG9yeSBidXQgdHJhbnNhY3Rpb24gc3RhdGVmdWwgcHJveHkgd2l0aCByZWNv cmQtcm91dGUgaGVhZGVyIGlzIG1hbmRhdG9yeSBmb3Igd2Vic29ja2V0IHRyYW5zcG9ydCBhbmQg c3RhdGVsZXNzIHByb3h5IGlzIG5vdCBwb3NzaWJsZS4gVGhpcyBoYXMgdG8gYmUgbWVudGlvbmVk IGluIHRoZSBkcmFmdC4NCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogUmF2 aW5kcmFuLCBQYXJ0aGFzYXJhdGhpDQo+U2VudDogV2VkbmVzZGF5LCBBcHJpbCAxOCwgMjAxMiAy OjA2IFBNDQo+VG86ICdJw7Fha2kgQmF6IENhc3RpbGxvJw0KPkNjOiBTSVBDT1JFIENoYWlyczsg U0lQQ09SRSAoU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIENvcmUpIFdHDQo+U3ViamVjdDog UkU6IFtzaXBjb3JlXSBTdGF0ZWxlc3Mgb3IgVHJhbnNhY3Rpb24gc3RhdGVmdWwgcHJveHkgcG9z c2libGUNCj5pbiBXZWJzb2NrZXQgdHJhbnNwb3J0PyBbUkU6IENhbGwgZm9yIEFkb3B0aW9uOiBk cmFmdC1pYmMtc2lwY29yZS1zaXAtDQo+d2Vic29ja2V0LTAyXQ0KPg0KPkluYWtpLA0KPg0KPlBs ZWFzZSBwcm92aWRlIFNJUCBvdmVyIFdlYmV4YW1wbGUgZXhhbXBsZSB3aXRob3V0IHJlY29yZC1y b3V0ZSBhbmQgMnh4DQo+cmVzcG9uc2UgZnJvbSBVQVMgd2l0aCBVRFAvVENQIHRyYW5zcG9ydCBp biBjb250YWN0IGhlYWRlciwgdGhlbiBpdCB3aWxsDQo+YmUgb2J2aW91cyB3aHkgaXQgaXMgbm90 IHBvc3NpYmxlIHRvIGJlIHRyYW5zYWN0aW9uIHN0YXRlZnVsIHByb3h5IGZvcg0KPldlYnNvY2tl dCB0byBVRFAvVENQIHRyYW5zcG9ydCBjb252ZXJzaW9uLiBJIGhhdmUgY2xhcmlmaWVkIHRob3Nl DQo+c2NlbmFyaW8gaW4gdGhlIGFub3RoZXIgbWFpbCB0aHJlYWQgdG8gTmF0YXJhanUuDQo+DQo+ VGhhbmtzDQo+UGFydGhhDQo+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206 IEnDsWFraSBCYXogQ2FzdGlsbG8gW21haWx0bzppYmNAYWxpYXgubmV0XQ0KPj5TZW50OiBXZWRu ZXNkYXksIEFwcmlsIDE4LCAyMDEyIDE6NDcgUE0NCj4+VG86IFJhdmluZHJhbiwgUGFydGhhc2Fy YXRoaQ0KPj5DYzogU0lQQ09SRSBDaGFpcnM7IFNJUENPUkUgKFNlc3Npb24gSW5pdGlhdGlvbiBQ cm90b2NvbCBDb3JlKSBXRw0KPj5TdWJqZWN0OiBSZTogW3NpcGNvcmVdIFN0YXRlbGVzcyBvciBU cmFuc2FjdGlvbiBzdGF0ZWZ1bCBwcm94eSBwb3NzaWJsZQ0KPj5pbiBXZWJzb2NrZXQgdHJhbnNw b3J0PyBbUkU6IENhbGwgZm9yIEFkb3B0aW9uOiBkcmFmdC1pYmMtc2lwY29yZS1zaXAtDQo+Pndl YnNvY2tldC0wMl0NCj4+DQo+PjIwMTIvNC8xOCBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkgPHBy YXZpbmRyYW5Ac29udXNuZXQuY29tPjoNCj4+PiBBcyBwZXIgbXkgY3VycmVudCByZWFkaW5nLCBU aGUgY3VycmVudCBkcmFmdCBhc3N1bWVzIGFib3V0IGRpYWxvZy0NCj4+c3RhdGVmdWwgcHJveHkg d2hlcmVpbiBhbGwgcmVjb3JkLXJvdXRlIGhlYWRlciB3aWxsIGJlIGFkZGVkIHdoZW5ldmVyDQo+ PldlYnNvY2tldCB0byBvdGhlciB0cmFuc3BvcnQgcm91dGluZyBoYXBwZW5zIGluIHRoZSBwcm94 eSBhbmQgcHJveHkNCj4+d2lsbCBiZSBpbnZvbHZlZCBpbiBhbGwgdGhlIHRyYW5zYWN0aW9uIHdp dGhpbiB0aGUgZGlhbG9nLg0KPj4NCj4+SGksIHRoZSBkcmFmdCBkb2VzIG5vdCBhc3N1bWUgdGhh dC4gUGVyaGFwcyB5b3UgdGFsayBhYm91dCB0aGUgZXhhbXBsZQ0KPj5zY2VuYXJpbyBpbiB0aGUg bm9uLW5vcm1hdGl2ZSBBcHBlbmRpeCBBPy4NCj4+DQo+PkFueWhvdyB3aGF0IHlvdSBtZWFuICJk aWFsb2ctc3RhdGVmdWwgcHJveHkiIGlzIGluY29ycmVjdCAoc2VlIGJlbG93DQo+PnBsZWFzZSku DQo+Pg0KPj4NCj4+DQo+Pj4gU28sIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBoYXZlIHN0YXRlbGVz cyBvciB0cmFuc2FjdGlvbiBzdGF0ZWZ1bA0KPj5wcm94eS4gSXQgd2lsbCBiZSBnb29kIGluIGNh c2UgdGhpcyBsaW1pdGF0aW9uIGlzIGV4cGxpY2l0bHkgbWVudGlvbmVkDQo+PmluIHRoZSBkcmFm dC4NCj4+DQo+PkFGQUlSIGEgcHJveHkgY2FuIGJlICp0cmFuc2FjdGlvbiBzdGF0ZWxlc3MqIHJl Z2FyZGxlc3MgaXQgYnJpZGdlcw0KPj5kaWZmZXJlbnQgU0lQIHRyYW5zcG9ydHMuIEEgc3RhdGVs ZXNzIHByb3h5IGlzIHN1cHBvc2VkIHRvIHJvdXRlDQo+PnJlc3BvbnNlcyBiYXNlZCBvbiBWaWEg aGVhZGVyLiBJbiBjYXNlIG9mIHJlbGlhYmxlIHRyYW5zcG9ydHMsIHRoZQ0KPj5maXJzdCBjaG9p Y2UgbXVzdCBiZSB1c2luZyB0aGUgZXhpc3RpbmcgY29ubmVjdGlvbi4gSWYgdGhlICpzdGF0ZWxl c3MqDQo+PnByb3h5IGFkZHMgO3JlY2VpdmVkIGFuZCA7cnBvcnQgdG8gdGhlIFZpYSBpbiB0aGUg aW5jb21pbmcgcmVxdWVzdCwNCj4+dGhlbiBpdCBjb3VsZCBsYXRlciByb3V0ZSByZXNwb25zZXMg dG8gdGhlIFVBQyBieSBpbnNwZWN0aW5nIHRob3NlDQo+PnBhcmFtZXRlcnMgaW4gdGhlIHJlc3Bv bnNlcyBhbmQgZ2V0dGluZyB0aGUgYXNzb2NpYXRlZCBjb25uZWN0aW9uLiBUaGUNCj4+cHJveHkg Y291bGQgYWxzbyBtYW50YWluIGEgcmVsYXRpb25zaGlwIGJldHdlZW4gYnJhbmNoIHZhbHVlcyBh bmQNCj4+YXNzb2NpYXRlZCBjb25uZWN0aW9ucywgYnV0IHRoZW4gaXQgd291bGQgYmUgbm90IHNv ICJzdGF0ZWxlc3MiLg0KPj4NCj4+DQo+PkFsc28sIHBsZWFzZSBkb24ndCBtaXggImxvb3NlLXJv dXRpbmciIGFuZCAiZGlhbG9nLXN0YXRlZnVsIi4gQSBwdXJlDQo+PlNJUCBwcm94eSBwZXJmb3Jt aW5nIGxvb3NlLXJvdXRpbmcgKGluLWRpYWxvZyByZXF1ZXN0cyBnbyB0aHJvdWdoIHRoZQ0KPj5w cm94eSkgY2FuIGJlIGEgdHJhbnNhY3Rpb24gc3RhdGVmdWwgcHJveHkgYnV0IGtub3cgbm90aGlu ZyBhYm91dA0KPj4iZGlhbG9ncyIuDQo+Pg0KPj4NCj4+UmVnYXJkcy4NCj4+DQo+Pg0KPj4tLQ0K Pj5Jw7Fha2kgQmF6IENhc3RpbGxvDQo+PjxpYmNAYWxpYXgubmV0Pg0K From ibc@aliax.net Wed Apr 18 01:45:12 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C88F21F84EE for ; Wed, 18 Apr 2012 01:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=0.056, 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 TitT8F1OqjDd for ; Wed, 18 Apr 2012 01:45:11 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B52C421F847A for ; Wed, 18 Apr 2012 01:45:11 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so992323vcb.31 for ; Wed, 18 Apr 2012 01:45:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=+wQMuueHi3vF0+0EAa/gkAxHYZ/SpMA0JMd6BvqRpf4=; b=TxuUJTsonmWjSE3zItP1pAii+SsswoALPQBm+WB0wcwWFEynPXkZeptmiqCbA7X9Cd 3YKSauvbb2s5O0Ira2rdK3DpVcBCorXuHLgtOgDlBSqEcSj42MK3aptJVlMcceYJHTXk lFEVNPFfSPmjh38Krt0h08fXBhNLpSCrINRq51Xm4AQPpoPnN3Bq4OOUlVPfSktRqaLN FX1M2qZg3Zk2cXsauEquXwMs9xxP4RFURzK81I2sBkM5RbyylsQJUpWeADEOQOdREKcO rQJLFzDaPuzx/OuRRNb/2FXEbQcXrW/Z+mHbzqWfrpnUPeUWJoxhJ5n4N5T8hPhweNhV DUGQ== Received: by 10.220.152.205 with SMTP id h13mr823161vcw.12.1334738711078; Wed, 18 Apr 2012 01:45:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 18 Apr 2012 01:44:50 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 18 Apr 2012 10:44:50 +0200 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlxQ37NuxMPMH7Me2a5nYIezRytxGtM8A/Xg0CeHIMt0h2j2xIUmcgbWmA2cTO8ZnnmM0mT Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs , "Nataraju A.B" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 08:45:12 -0000 2012/4/18 Ravindran, Parthasarathi : > anybody implement SIP over websocket in browser using JavaScript violates= RFC 3261 as it is not > possible for browser to send REINVITE/BYE using UDP/TCP transport towards= UAS directly with > stateless/Transaction stateful proxy as a first proxy hop. Then SIP UAs in Outbound (RFC 5626) scenarios also violate RFC 3261 since TCP UAs behind NAT cannot receive requests and responses via UDP, neither they can receive inbound TCP connections. But what is the exact problem? the draft is not for "web browsers", but for any SIP entity running a WebSocket client and/or server (along with other SIP transports). Does a SIP stack in JavaScrtip running in a web browser and making usage of WS transport violate RFC 3261 since it does not support UDP/TCP transports? probably. Is that a real problem? not at all if the SIP infrastucture applies other SIP standards (such as RFC 5626) or "propietary mechanisms" for ensuring that the web browser sends and receives all the SIP requests and responses through its opened WebSocket connection. Best regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Apr 18 01:46:40 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 477C321F85C4 for ; Wed, 18 Apr 2012 01:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.054, 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 lXyvYlQkoXAX for ; Wed, 18 Apr 2012 01:46:39 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B019F21F85C0 for ; Wed, 18 Apr 2012 01:46:39 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so993113vcb.31 for ; Wed, 18 Apr 2012 01:46:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=m+oKJWDM3TwOtlUR8xB3GWQtK8KkPWc14zNgvpc0t34=; b=KWNs0CjtRHuofFFtTCZZMcem8StJY1S6qU3Nz88Gkr+pVGwZeRnQHL8oJvkoWDD200 kSD1Vq2PTBHbwKwgvPpUL1RHqGDEMO4KwpmNQsDqNV6fsbi8DAtAW9zF0KfpDd52i9W/ OOYwWBCJTiXtPwegINvkla77OT3arcrbzSzWWBl5BuIRQoEPYF14g1HhMicINoVLGRKW FfIjL8BwhcB7Z+uRsnJ1meZMCR5I/XdQubk5f1BGwJ1NeD7QWmvNWP4V0ekgu8E/P3qP hoi7Uq2YDzfYs6m3FEUhyMOsR32ZJNlkZasXjN3ATP9wpbMqZyEKVI4Fy5aD0JRNxoxS 7ECw== Received: by 10.52.64.173 with SMTP id p13mr654040vds.51.1334738799153; Wed, 18 Apr 2012 01:46:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 18 Apr 2012 01:46:18 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E227FB9@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FB9@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 18 Apr 2012 10:46:18 +0200 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlR9NaWNJ5u7PWbTASrqXWvq2ctROPricMf14Kahc6XxtViNz1pHSuxenOyA5WhPm24Ik8L Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 08:46:40 -0000 2012/4/18 Ravindran, Parthasarathi : > Inaki, > > Please provide SIP over Webexample example without record-route and 2xx r= esponse from UAS with UDP/TCP transport in contact header, then it will be = obvious why it is not possible to be transaction stateful proxy for Websock= et to UDP/TCP transport conversion. Ravindran, please read my previous mail in which I explain that your concept of "transaction stateful proxy" is incorrect. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Wed Apr 18 01:57:07 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC7BF21F84D6 for ; Wed, 18 Apr 2012 01:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.385 X-Spam-Level: X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 2zKggHOSS6sQ for ; Wed, 18 Apr 2012 01:57:07 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id E050D21F84C3 for ; Wed, 18 Apr 2012 01:57:06 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKT46B4uaRuqXWc97DWYWxS5xDxD9tnw4F@postini.com; Wed, 18 Apr 2012 01:57:07 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 18 Apr 2012 04:57:39 -0400 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.0355.002; Wed, 18 Apr 2012 14:27:00 +0530 From: "Ravindran, Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: AQHNHSsWQiKr/IZJokCfX43Mp6RbG5agJJrA//+unYCAAGacsP//rqsAgABc8LA= Date: Wed, 18 Apr 2012 08:57:00 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs , "Nataraju A.B" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 08:57:07 -0000 SW4gY2FzZSB0aGUgaW50ZW50aW9uIG9mIHRoZSBkcmFmdCBpcyB0byB2aW9sYXRlIFJGQyAzMjYx LCANCklNTywgd2Ugd2lsbCBuZWVkIG1vcmUgYW5hbHlzaXMgYmVmb3JlIGFkb3B0aW5nIHRoaXMg ZHJhZnQuDQoNCkFGQUlLLCBSRkMgNTYyNiBjb25zaWRlcnMgVURQIHRyYW5zcG9ydCBhcyB3ZWxs IGFuZCBTZWMgMSBQYXJhIDMgZXhwbGFpbnMgYXMgDQoNCiIgICBUaGUga2V5IGlkZWEgb2YgdGhp cyBzcGVjaWZpY2F0aW9uIGlzIHRoYXQgd2hlbiBhIFVBIHNlbmRzIGEgUkVHSVNURVINCiAgIHJl cXVlc3Qgb3IgYSBkaWFsb2ctZm9ybWluZyByZXF1ZXN0LCB0aGUgcHJveHkgY2FuIGxhdGVyIHVz ZSB0aGlzDQogICBzYW1lIG5ldHdvcmsgImZsb3ciIC0tIHdoZXRoZXIgdGhpcyBpcyBhIGJpZGly ZWN0aW9uYWwgc3RyZWFtIG9mIFVEUA0KICAgZGF0YWdyYW1zLCBhIFRDUCBjb25uZWN0aW9uLCBv ciBhbiBhbmFsb2dvdXMgY29uY2VwdCBpbiBhbm90aGVyDQogICB0cmFuc3BvcnQgcHJvdG9jb2wg LS0gdG8gZm9yd2FyZCBhbnkgaW5jb21pbmcgcmVxdWVzdHMgdGhhdCBuZWVkIHRvDQogICBnbyB0 byB0aGlzIFVBIGluIHRoZSBjb250ZXh0IG9mIHRoZSByZWdpc3RyYXRpb24gb3IgZGlhbG9nLiIN Cg0KUGxlYXNlIGluZGljYXRlcyB3aGVyZSBSRkMgNTYyNiB2aW9sYXRlcyBSRkMgMzI2MS4NCg0K VGhhbmtzDQpQYXJ0aGENCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogScOx YWtpIEJheiBDYXN0aWxsbyBbbWFpbHRvOmliY0BhbGlheC5uZXRdDQo+U2VudDogV2VkbmVzZGF5 LCBBcHJpbCAxOCwgMjAxMiAyOjE1IFBNDQo+VG86IFJhdmluZHJhbiwgUGFydGhhc2FyYXRoaQ0K PkNjOiBOYXRhcmFqdSBBLkI7IFNJUENPUkUgKFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2NvbCBD b3JlKSBXRzsgU0lQQ09SRQ0KPkNoYWlycw0KPlN1YmplY3Q6IFJlOiBbc2lwY29yZV0gU3RhdGVs ZXNzIG9yIFRyYW5zYWN0aW9uIHN0YXRlZnVsIHByb3h5IHBvc3NpYmxlDQo+aW4gV2Vic29ja2V0 IHRyYW5zcG9ydD8gW1JFOiBDYWxsIGZvciBBZG9wdGlvbjogZHJhZnQtaWJjLXNpcGNvcmUtc2lw LQ0KPndlYnNvY2tldC0wMl0NCj4NCj4yMDEyLzQvMTggUmF2aW5kcmFuLCBQYXJ0aGFzYXJhdGhp IDxwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbT46DQo+PiBhbnlib2R5IGltcGxlbWVudCBTSVAgb3Zl ciB3ZWJzb2NrZXQgaW4gYnJvd3NlciB1c2luZyBKYXZhU2NyaXB0DQo+PiB2aW9sYXRlcyBSRkMg MzI2MSBhcyBpdCBpcyBub3QgcG9zc2libGUgZm9yIGJyb3dzZXIgdG8gc2VuZA0KPj4gUkVJTlZJ VEUvQllFIHVzaW5nIFVEUC9UQ1AgdHJhbnNwb3J0IHRvd2FyZHMgVUFTIGRpcmVjdGx5IHdpdGgN Cj5zdGF0ZWxlc3MvVHJhbnNhY3Rpb24gc3RhdGVmdWwgcHJveHkgYXMgYSBmaXJzdCBwcm94eSBo b3AuDQo+DQo+VGhlbiBTSVAgVUFzIGluIE91dGJvdW5kIChSRkMgNTYyNikgc2NlbmFyaW9zIGFs c28gdmlvbGF0ZSBSRkMgMzI2MQ0KPnNpbmNlIFRDUCBVQXMgYmVoaW5kIE5BVCBjYW5ub3QgcmVj ZWl2ZSByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIHZpYSBVRFAsDQo+bmVpdGhlciB0aGV5IGNhbiBy ZWNlaXZlIGluYm91bmQgVENQIGNvbm5lY3Rpb25zLg0KPg0KPkJ1dCB3aGF0IGlzIHRoZSBleGFj dCBwcm9ibGVtPyB0aGUgZHJhZnQgaXMgbm90IGZvciAid2ViIGJyb3dzZXJzIiwgYnV0DQo+Zm9y IGFueSBTSVAgZW50aXR5IHJ1bm5pbmcgYSBXZWJTb2NrZXQgY2xpZW50IGFuZC9vciBzZXJ2ZXIg KGFsb25nIHdpdGgNCj5vdGhlciBTSVAgdHJhbnNwb3J0cykuDQo+DQo+RG9lcyBhIFNJUCBzdGFj ayBpbiBKYXZhU2NydGlwIHJ1bm5pbmcgaW4gYSB3ZWIgYnJvd3NlciBhbmQgbWFraW5nIHVzYWdl DQo+b2YgV1MgdHJhbnNwb3J0IHZpb2xhdGUgUkZDIDMyNjEgc2luY2UgaXQgZG9lcyBub3Qgc3Vw cG9ydCBVRFAvVENQDQo+dHJhbnNwb3J0cz8gcHJvYmFibHkuIElzIHRoYXQgYSByZWFsIHByb2Js ZW0/IG5vdCBhdCBhbGwgaWYgdGhlIFNJUA0KPmluZnJhc3R1Y3R1cmUgYXBwbGllcyBvdGhlciBT SVAgc3RhbmRhcmRzIChzdWNoIGFzIFJGQyA1NjI2KSBvcg0KPiJwcm9waWV0YXJ5IG1lY2hhbmlz bXMiIGZvciBlbnN1cmluZyB0aGF0IHRoZSB3ZWIgYnJvd3NlciBzZW5kcyBhbmQNCj5yZWNlaXZl cyBhbGwgdGhlIFNJUCByZXF1ZXN0cyBhbmQgcmVzcG9uc2VzIHRocm91Z2ggaXRzIG9wZW5lZCBX ZWJTb2NrZXQNCj5jb25uZWN0aW9uLg0KPg0KPg0KPkJlc3QgcmVnYXJkcy4NCj4NCj4tLQ0KPknD sWFraSBCYXogQ2FzdGlsbG8NCj48aWJjQGFsaWF4Lm5ldD4NCg== From ibc@aliax.net Wed Apr 18 01:59:21 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA6121F863D for ; Wed, 18 Apr 2012 01:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.053, 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 54bJjga71X6j for ; Wed, 18 Apr 2012 01:59:21 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 33C1921F8565 for ; Wed, 18 Apr 2012 01:59:21 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so999616vcb.31 for ; Wed, 18 Apr 2012 01:59:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=lS70MYVibOmIbl0UZSXykwWsU358lsTApkvIAfPFRA0=; b=i/y84XyvdygQluAdoGs0LaQ+sDQqtWjbA+YM+i/fJONiIw+aF6FsuqL743od+AFgEO bd7Brhb7h/qwcTJY2nqIfjE1QexsWqtZSuHWf/HjH0IBzjv5febFch0+1aPjlSWBZbAr nvAAHEZkVuRx4lSs2X+rNuJUNIfknGpOHWBe0xCy9v2fPKFjk5hNY1qPdv7RgBF9M9MY znmf5eCjCgjNKgYNsOgKDMW2Yb+wY0315+d568JZ+y6gTdit/LKEgZWNSgyl0WX25dMQ 1h9uD/TfGplAwx/FSA1yQVQC6mS7hla9W9vJkLAKPRff/0bZN9Ws80g/dCgGkDJzD6v2 4j+Q== Received: by 10.52.64.173 with SMTP id p13mr668454vds.51.1334739560730; Wed, 18 Apr 2012 01:59:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 18 Apr 2012 01:59:00 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E227FCA@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FCA@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 18 Apr 2012 10:59:00 +0200 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmqvZpEaEH++5elzFpq/sSXp6xFRprLDzYSCa5UTjEjk7HgZwLUYo6+E2uVsPgypeQsqXW0 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 08:59:22 -0000 2012/4/18 Ravindran, Parthasarathi : > One minor correction, I agree that dialog-stateful proxy is not mandatory= but transaction stateful proxy with record-route header is mandatory for w= ebsocket transport That is just true in case the UA just implements a WebSocket client (so it's a SIP WebSocket Client according to "Definitions" section in the draft, but not a SIP WebSocket Server). This is true in the case of a web browser but the draft does NOT assume that clients are web browsers. > and stateless proxy is not possible. In a previous mail I've explained that a staless proxy can bridge different SIP transports. Please find a reference for your assertion (I could be wrong). > This has to be mentioned in the draft. Please check RFC 4168 (SIP SCTP transport), and let's imagine this scenario= : alice ----(SCTP)----- proxy -----(UDP)---- bob If bob does not implement SCTP transport (and alice announces a URI with ;transport=3Dstcp in her Contact), then the proxy needs to add Record-Route (loose-routing) thinkgs to work, am I right? Well, please look in RFC 4168 for keywords "proxy", "loose-routing", "record-route", "stateless", "stateful" and so. No matches. So, why should this draft solve all the problems of the world related to SIPS or transport bridging? That is not the purpose of this draft which just defines a new SIP transport. The issues you mean are not specific for this new transport, but for any other transport which is not UDP or TCP. There should be other drafts or places for solving or defining procedures for them. Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Apr 18 02:08:35 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A64A921F85ED for ; Wed, 18 Apr 2012 02:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.052, 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 EquoxsoKpWqs for ; Wed, 18 Apr 2012 02:08:35 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C69E21F85D7 for ; Wed, 18 Apr 2012 02:08:35 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1004879vcb.31 for ; Wed, 18 Apr 2012 02:08:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=UJymqeaZBS2QWDOJ55P2+RUnJ3KeghssVHgAOBW7pp0=; b=Oype2Y9ePifFJVlT9L8SOJZPVIg3yIBh2hDi60702UCg7qg56F/n1E2odvMcCESM14 BZyAgNqPOiFsiizQIiOYDUaiaZcABarT1LfODeD6jqgAKioD8dKUY589vMG8wUWOocGL Vo4j4f2fmpMUyC/uWYE2scIq1rg0QvUyO8nYZCIcK3G1M2v0rf+Y7n6Ou0qxXIhbmwMs aTj+lcooukdby9+zE0TR4P+pqOMmJkSRIxH74LdJ56UGAmk0877GlfIyxJp+Ihb8CI0d EEhrSXa4B9UHvEGxGRC64crsoPhGJhL1iwCWHmor8plb5dIl88++diTRBnupUzeYuo/f /WHA== Received: by 10.220.140.207 with SMTP id j15mr848183vcu.22.1334740114453; Wed, 18 Apr 2012 02:08:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 18 Apr 2012 02:08:14 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 18 Apr 2012 11:08:14 +0200 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmF59v4lN4WKAj/tn1lzp4YCxW+rnn+1pY8ntpUs9+rwKLe5mZF5IxvH+Z/IB90vcMZNZ0n Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs , "Nataraju A.B" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 09:08:35 -0000 2012/4/18 Ravindran, Parthasarathi : > In case the intention of the draft is to violate RFC 3261, > IMO, we will need more analysis before adopting this draft. Thanks a lot Partha. Please let us know where the draft violates RFC 3261. If you assume that a SIP UA implementing the WebSocket transport is a web browser (so can only make outbound connections and does not speak SIP UDP/TCP) then that is your assumption, but NOT the assumption of the draft. Now imagine that I code a SIP softphone for my smartphone, and such a softphone speaks SIP over UDP, TCP and WebSocket, and implements both a WebSocket client and a WebSocket server (so becomes a SIP WebSocket Client and a SIP WebSocket Server according to "Definitions" section in the draft). Does it violate RFC 3261? Best regards. --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Wed Apr 18 02:14:53 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DF321F8559 for ; Wed, 18 Apr 2012 02:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3] 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 xDBHN8jlGd-A for ; Wed, 18 Apr 2012 02:14:53 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 723FF21F8552 for ; Wed, 18 Apr 2012 02:14:53 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id C4C55B01A4; Wed, 18 Apr 2012 11:14:51 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 1BE63B0181; Wed, 18 Apr 2012 11:14:51 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> Date: Wed, 18 Apr 2012 11:14:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1084) Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs , "Nataraju A.B" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 09:14:54 -0000 Hi, On Apr 18, 2012, at 10:57 AM, Ravindran, Parthasarathi wrote: > In case the intention of the draft is to violate RFC 3261,=20 > IMO, we will need more analysis before adopting this draft. >=20 SIP clients implementing this draft may also implement UDP and TCP = transports, this draft doesn't say they shouldn't. Now lets assume we are using a JS SIP stack in a browser: UDP and TCP = can't be used, so why implement them in the first place? Also, the = client will register with WS transport and *use* transport=3Dws in the = Contat header so trying to reach him on TCP or UDP would be incorrect. Also, TCP and UDP are mandatory to implement as per RFC3261, not = mandatory to use. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From pravindran@sonusnet.com Wed Apr 18 02:35:49 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C55621F8554 for ; Wed, 18 Apr 2012 02:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6ghaslVXH3G for ; Wed, 18 Apr 2012 02:35:49 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8BD21F852E for ; Wed, 18 Apr 2012 02:35:48 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKT46K89PjsprhAQI1nUH6kGAsHaFzB0C1@postini.com; Wed, 18 Apr 2012 02:35:48 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 18 Apr 2012 05:36:21 -0400 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.0355.002; Wed, 18 Apr 2012 15:05:42 +0530 From: "Ravindran, Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: AQHNHSsWQiKr/IZJokCfX43Mp6RbG5agJJrA//+unYCAAGacsP//rqsAgABc8LD//6maAAAMSNZA Date: Wed, 18 Apr 2012 09:35:41 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs , "Nataraju A.B" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 09:35:49 -0000 QXMgcGVyIHlvdXIgYmVsb3cgc3RhdGVtZW50LCBKYXZhU2NyaXB0IHdpdGggU0lQIGFuZCBSVENX ZWIgQnJvd3NlciBNVVNUIE5PVCB1c2UgdGhpcyBkcmFmdCBhcyBpdCB2aW9sYXRlcyBSRkMgMzI2 MS4NCg0KQWxzbyBpbiBJRVRGLTgzIFNJUENvcmUgbWVldGluZywgSSBub3RpY2VkIHRoYXQgU0lQ IFVBIG92ZXIgd2Vic29ja2V0IHdpbGwgbm90IGxpc3RlbiBmb3IgdGhlIGluY29taW5nIGNhbGwg d2l0aG91dCByZWdpc3RyYXRpb24gYnV0IGluIGNhc2Ugb2YgeW91ciBkcmFmdCBpcyB3cml0dGVu IHdpdGggU0lQIHNvZnRwaG9uZSAoc21hcnRwaG9uZSkgaW4gbWluZCAsIGl0IGlzIHBvc3NpYmxl IHRvIGxpc3RlbiBpbiBQb3J0IDgwIG9yIGFueSBvdGhlciBXZWJzb2NrZXQgcG9ydCB3aGljaCBp cyBub3QgYWRkcmVzc2VkIGluIHRoaXMgZHJhZnQgdGlsbCBub3cuIFdlIG5lZWQgdG8gZGlzY3Vz cyBhbmQgc29ydCBpdCBvdXQuDQoNClRoYW5rcw0KUGFydGhhDQoNCj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPkZyb206IEnDsWFraSBCYXogQ2FzdGlsbG8gW21haWx0bzppYmNAYWxpYXgu bmV0XQ0KPlNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMTgsIDIwMTIgMjozOCBQTQ0KPlRvOiBSYXZp bmRyYW4sIFBhcnRoYXNhcmF0aGkNCj5DYzogTmF0YXJhanUgQS5COyBTSVBDT1JFIChTZXNzaW9u IEluaXRpYXRpb24gUHJvdG9jb2wgQ29yZSkgV0c7IFNJUENPUkUNCj5DaGFpcnMNCj5TdWJqZWN0 OiBSZTogW3NpcGNvcmVdIFN0YXRlbGVzcyBvciBUcmFuc2FjdGlvbiBzdGF0ZWZ1bCBwcm94eSBw b3NzaWJsZQ0KPmluIFdlYnNvY2tldCB0cmFuc3BvcnQ/IFtSRTogQ2FsbCBmb3IgQWRvcHRpb246 IGRyYWZ0LWliYy1zaXBjb3JlLXNpcC0NCj53ZWJzb2NrZXQtMDJdDQo+DQo+MjAxMi80LzE4IFJh dmluZHJhbiwgUGFydGhhc2FyYXRoaSA8cHJhdmluZHJhbkBzb251c25ldC5jb20+Og0KPj4gSW4g Y2FzZSB0aGUgaW50ZW50aW9uIG9mIHRoZSBkcmFmdCBpcyB0byB2aW9sYXRlIFJGQyAzMjYxLCBJ TU8sIHdlDQo+PiB3aWxsIG5lZWQgbW9yZSBhbmFseXNpcyBiZWZvcmUgYWRvcHRpbmcgdGhpcyBk cmFmdC4NCj4NCj5UaGFua3MgYSBsb3QgUGFydGhhLg0KPg0KPlBsZWFzZSBsZXQgdXMga25vdyB3 aGVyZSB0aGUgZHJhZnQgdmlvbGF0ZXMgUkZDIDMyNjEuIElmIHlvdSBhc3N1bWUgdGhhdA0KPmEg U0lQIFVBIGltcGxlbWVudGluZyB0aGUgV2ViU29ja2V0IHRyYW5zcG9ydCBpcyBhIHdlYiBicm93 c2VyIChzbyBjYW4NCj5vbmx5IG1ha2Ugb3V0Ym91bmQgY29ubmVjdGlvbnMgYW5kIGRvZXMgbm90 IHNwZWFrIFNJUCBVRFAvVENQKSB0aGVuIHRoYXQNCj5pcyB5b3VyIGFzc3VtcHRpb24sIGJ1dCBO T1QgdGhlIGFzc3VtcHRpb24gb2YgdGhlIGRyYWZ0Lg0KPg0KPk5vdyBpbWFnaW5lIHRoYXQgSSBj b2RlIGEgU0lQIHNvZnRwaG9uZSBmb3IgbXkgc21hcnRwaG9uZSwgYW5kIHN1Y2ggYQ0KPnNvZnRw aG9uZSBzcGVha3MgU0lQIG92ZXIgVURQLCBUQ1AgYW5kIFdlYlNvY2tldCwgYW5kIGltcGxlbWVu dHMgYm90aCBhDQo+V2ViU29ja2V0IGNsaWVudCBhbmQgYSBXZWJTb2NrZXQgc2VydmVyIChzbyBi ZWNvbWVzIGEgU0lQIFdlYlNvY2tldA0KPkNsaWVudCBhbmQgYSBTSVAgV2ViU29ja2V0IFNlcnZl ciBhY2NvcmRpbmcgdG8gIkRlZmluaXRpb25zIiBzZWN0aW9uIGluDQo+dGhlIGRyYWZ0KS4gRG9l cyBpdCB2aW9sYXRlIFJGQyAzMjYxPw0KPg0KPkJlc3QgcmVnYXJkcy4NCj4NCj4tLQ0KPknDsWFr aSBCYXogQ2FzdGlsbG8NCj48aWJjQGFsaWF4Lm5ldD4NCg== From saul@ag-projects.com Wed Apr 18 02:53:17 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0005821F8631 for ; Wed, 18 Apr 2012 02:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaZck1nWcA-v for ; Wed, 18 Apr 2012 02:53:16 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4D35421F860B for ; Wed, 18 Apr 2012 02:53:16 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id B17AFB01A4; Wed, 18 Apr 2012 11:53:14 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id E9B8EB019C; Wed, 18 Apr 2012 11:53:13 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> Date: Wed, 18 Apr 2012 11:53:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1084) Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs , "Nataraju A.B" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 09:53:17 -0000 On Apr 18, 2012, at 11:35 AM, Ravindran, Parthasarathi wrote: > As per your below statement, JavaScript with SIP and RTCWeb Browser = MUST NOT use this draft as it violates RFC 3261. >=20 It doesn't, see my previous email explaining why. > Also in IETF-83 SIPCore meeting, I noticed that SIP UA over websocket = will not listen for the incoming call without registration but in case = of your draft is written with SIP softphone (smartphone) in mind , it is = possible to listen in Port 80 or any other Websocket port which is not = addressed in this draft till now. We need to discuss and sort it out. >=20 The fact that a JS SIP client (running in a web browser) does not listen = for incoming connections is a limitation imposed by the WebSocket API, = not by this draft. This specification defines 2 entities: a SIP = WebSocket Client and a SIP WebSocket Server, so nobody stops you from = creating an entity that implements both and can accept incoming = WebSocket connections. Of course, such an application would not run in a = browser. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From pravindran@sonusnet.com Wed Apr 18 03:07:58 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBAA21F85D7 for ; Wed, 18 Apr 2012 03:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 9wLtIozrofNf for ; Wed, 18 Apr 2012 03:07:57 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAF421F85C5 for ; Wed, 18 Apr 2012 03:07:57 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKT46SfHC3l/bczNzmDIDGdi7HcvbZLnbk@postini.com; Wed, 18 Apr 2012 03:07:57 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 18 Apr 2012 06:08:29 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 15:37:50 +0530 From: "Ravindran, Parthasarathi" To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= , "SIPCORE (Session Initiation Protocol Core) WG" , "SIPCORE Chairs" Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: AQHNHSsWQiKr/IZJokCfX43Mp6RbG5agJJrA//+unYCAAGacsP//rqsAgABc8LD//6maAAAMSNZA//+qS4D//6NDQA== Date: Wed, 18 Apr 2012 10:07:50 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> In-Reply-To: <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "Nataraju A.B" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 10:07:58 -0000 Even if it is the limitations of websocket, SIP UA MUST listen in UDP & TCP as per RFC 3261 and not adhere to this requirement which MUST be considered as a violation of RFC 3261. In case you think that this draft does not violate any RFC 3261 for SIP UA, the Current text in the draft is = not clear enough, Please mention it explicitly in the draft that "As per this specification, SIP UA MUST support UDP, TCP transport apart=20 from Websocket as a transport" This information helps for the implementers who wish to use this draft for= =20 RTCWeb client to SIP Interop in the standard way. I'm writing this mail as= =20 most of the folks support this draft for interworking RTCWeb client to SIP= =20 in the standard manner as per my discussion in IETF-83.=20 I'll write the separate mail thread for discussing incoming SIP over websoc= ket as it is one another major open item in this draft. Thanks Partha >-----Original Message----- >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] >Sent: Wednesday, April 18, 2012 3:23 PM >To: Ravindran, Parthasarathi >Cc: I=F1aki Baz Castillo; SIPCORE (Session Initiation Protocol Core) WG; >SIPCORE Chairs; Nataraju A.B >Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible >in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip- >websocket-02] > > >On Apr 18, 2012, at 11:35 AM, Ravindran, Parthasarathi wrote: > >> As per your below statement, JavaScript with SIP and RTCWeb Browser >MUST NOT use this draft as it violates RFC 3261. >> > >It doesn't, see my previous email explaining why. > >> Also in IETF-83 SIPCore meeting, I noticed that SIP UA over websocket >will not listen for the incoming call without registration but in case >of your draft is written with SIP softphone (smartphone) in mind , it is >possible to listen in Port 80 or any other Websocket port which is not >addressed in this draft till now. We need to discuss and sort it out. >> > >The fact that a JS SIP client (running in a web browser) does not listen >for incoming connections is a limitation imposed by the WebSocket API, >not by this draft. This specification defines 2 entities: a SIP >WebSocket Client and a SIP WebSocket Server, so nobody stops you from >creating an entity that implements both and can accept incoming >WebSocket connections. Of course, such an application would not run in a >browser. > > >Regards, > >-- >Sa=FAl Ibarra Corretg=E9 >AG Projects > > From saul@ag-projects.com Wed Apr 18 03:14:29 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B552721F85C0 for ; Wed, 18 Apr 2012 03:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.588 X-Spam-Level: X-Spam-Status: No, score=-1.588 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMhrsx0kZMAF for ; Wed, 18 Apr 2012 03:14:29 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id D90C321F8542 for ; Wed, 18 Apr 2012 03:14:28 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 3F7E9B01A4; Wed, 18 Apr 2012 12:14:28 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 35B82B019C; Wed, 18 Apr 2012 12:14:15 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> Date: Wed, 18 Apr 2012 12:14:14 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1084) Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs , "Nataraju A.B" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 10:14:29 -0000 On Apr 18, 2012, at 12:07 PM, Ravindran, Parthasarathi wrote: > Even if it is the limitations of websocket, SIP UA MUST listen in > UDP & TCP as per RFC 3261 and not adhere to this requirement which = MUST > be considered as a violation of RFC 3261. In case you think that this = draft > does not violate any RFC 3261 for SIP UA, the Current text in the = draft is not > clear enough, Please mention it explicitly in the draft that >=20 "MUST implement" doesn't imply "MUST use" AFAIK. > "As per this specification, SIP UA MUST support UDP, TCP transport = apart=20 > from Websocket as a transport" >=20 It's not needed, 3261 sec 18 covers this: " All SIP elements MUST = implement UDP and TCP. SIP elements MAY implement other protocols." > This information helps for the implementers who wish to use this draft = for=20 > RTCWeb client to SIP Interop in the standard way. I'm writing this = mail as=20 > most of the folks support this draft for interworking RTCWeb client to = SIP=20 > in the standard manner as per my discussion in IETF-83.=20 >=20 > I'll write the separate mail thread for discussing incoming SIP over = websocket > as it is one another major open item in this draft. >=20 I don't think it's a "major open item", the draft specifies it, but t = can't be used in a RTCWeb context because browsers don't listen for = incoming WebSocket connections. Other endpoints implementing this draft = will be able to listen for incoming connections just fine. -- Sa=FAl Ibarra Corretg=E9 AG Projects From nataraju.sip@gmail.com Wed Apr 18 03:20:03 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF2221F8618 for ; Wed, 18 Apr 2012 03:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.579, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 rzihzB1j9w5j for ; Wed, 18 Apr 2012 03:20:02 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29D1821F85F9 for ; Wed, 18 Apr 2012 03:20:01 -0700 (PDT) Received: by lagj5 with SMTP id j5so6004499lag.31 for ; Wed, 18 Apr 2012 03:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rxYoQKSOf0qoy6r+70MZolWq8huab8frrjaO99yx/P8=; b=E554Kvr80c6GGlh0BbmD4ayF5wRtFE6x1x7dR8Yu5yyhlQYJdM3Dq51vDczaLfP0v4 qiL+mCZLkMMuSxGxHgYe91vMRtNzs/OSoYhM7VFoECJ4iWgfZS89EFunBsuRBq9233+z EnVowN9rAUMyjxmALKoGkKwmmeCn3HT9pM5+1QkskOrTrTtiI9098W4hgnMC8e2YtyO7 YINFTOV1iV6Ep6AALLWObK45eDcDR29f6Gzr119Q79qZHa77+ZseBz6fOTfkNVk/eLl2 lBLht4R4kUfzldCa9Jrz7CZIIaXb/kANmd5ZlCbJpUQhWsCB1wAtwZq2Xsnffz8og1yb CSfQ== MIME-Version: 1.0 Received: by 10.152.162.68 with SMTP id xy4mr6807lab.49.1334744401163; Wed, 18 Apr 2012 03:20:01 -0700 (PDT) Received: by 10.112.103.103 with HTTP; Wed, 18 Apr 2012 03:20:01 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> Date: Wed, 18 Apr 2012 15:50:01 +0530 Message-ID: From: "Nataraju A.B" To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=f46d04426822e5b69c04bdf16561 Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs , =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 10:20:03 -0000 --f46d04426822e5b69c04bdf16561 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Apr 18, 2012 at 3:37 PM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > Even if it is the limitations of websocket, SIP UA MUST listen in > UDP & TCP as per RFC 3261 and not adhere to this requirement which MUST > be considered as a violation of RFC 3261. In case you think that this dra= ft > does not violate any RFC 3261 for SIP UA, the Current text in the draft i= s > not > clear enough, Please mention it explicitly in the draft that > > "As per this specification, SIP UA MUST support UDP, TCP transport apart > from Websocket as a transport" > > This information helps for the implementers who wish to use this draft fo= r > RTCWeb client to SIP Interop in the standard way. I'm writing this mail a= s > most of the folks support this draft for interworking RTCWeb client to SI= P > in the standard manner as per my discussion in IETF-83. > > I'll write the separate mail thread for discussing incoming SIP over > websocket > as it is one another major open item in this draft. > [ABN] Partha, Can you name some scenario which need this incoming SIP requests @ the WebSocket client ???? > > Thanks > Partha > > >-----Original Message----- > >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] > >Sent: Wednesday, April 18, 2012 3:23 PM > >To: Ravindran, Parthasarathi > >Cc: I=F1aki Baz Castillo; SIPCORE (Session Initiation Protocol Core) WG; > >SIPCORE Chairs; Nataraju A.B > >Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible > >in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip- > >websocket-02] > > > > > >On Apr 18, 2012, at 11:35 AM, Ravindran, Parthasarathi wrote: > > > >> As per your below statement, JavaScript with SIP and RTCWeb Browser > >MUST NOT use this draft as it violates RFC 3261. > >> > > > >It doesn't, see my previous email explaining why. > > > >> Also in IETF-83 SIPCore meeting, I noticed that SIP UA over websocket > >will not listen for the incoming call without registration but in case > >of your draft is written with SIP softphone (smartphone) in mind , it is > >possible to listen in Port 80 or any other Websocket port which is not > >addressed in this draft till now. We need to discuss and sort it out. > >> > > > >The fact that a JS SIP client (running in a web browser) does not listen > >for incoming connections is a limitation imposed by the WebSocket API, > >not by this draft. This specification defines 2 entities: a SIP > >WebSocket Client and a SIP WebSocket Server, so nobody stops you from > >creating an entity that implements both and can accept incoming > >WebSocket connections. Of course, such an application would not run in a > >browser. > > > > > >Regards, > > > >-- > >Sa=FAl Ibarra Corretg=E9 > >AG Projects > > > > > > --=20 Thanks, Nataraju A.B. --f46d04426822e5b69c04bdf16561 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 18, 2012 at 3:37 PM, Ravindr= an, Parthasarathi <pravindran@sonusnet.com> wrote:
Even if it is the limitations of websocket, SIP UA MUST listen in
UDP & TCP as per RFC 3261 and not adhere to this requirement which MUST=
be considered as a violation of RFC 3261. In case you think that this draft=
does not violate any RFC 3261 for SIP UA, the Current text in the draft is = not
clear enough, Please mention it explicitly in the draft that

"As per this specification, SIP UA MUST support UDP, TCP transport apa= rt
from Websocket as a transport"

This information helps for the implementers who wish to use this draft for<= br> RTCWeb client to SIP Interop in the standard way. I'm writing this mail= as
most of the folks support this draft for interworking RTCWeb client to SIP<= br> in the standard manner as per my discussion in IETF-83.

I'll write the separate mail thread for discussing incoming SIP over we= bsocket
as it is one another major open item in this draft.
[A= BN] Partha,=A0
=A0 =A0 =A0 =A0 =A0 Can you name some scenario whi= ch need this incoming SIP requests @ the WebSocket client ????=A0

Thanks
Partha

>-----Original Message-----
>From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com]
>Sent: Wednesday, April 18, 2012 3:23 PM
>To: Ravindran, Parthasarathi
>Cc: I=F1aki Baz Castillo; SIPCORE (Session Init= iation Protocol Core) WG;
>SIPCORE Chairs; Nataraju A.B
>Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible=
>in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-<= br> >websocket-02]
>
>
>On Apr 18, 2012, at 11:35 AM, R= avindran, Parthasarathi wrote:
>
>> As per your below statement, JavaScript with SIP and RTCWeb Browse= r
>MUST NOT use this draft as it violates RFC 3261.
>>
>
>It doesn't, see my previous email explaining why.
>
>> Also in IETF-83 SIPCore meeting, I noticed that SIP UA over websoc= ket
>will not listen for the incoming call without registration but in case<= br> >of your draft is written with SIP softphone (smartphone) in mind , it i= s
>possible to listen in Port 80 or any other Websocket port which is not<= br> >addressed in this draft till now. We need to discuss and sort it out. >>
>
>The fact that a JS SIP client (running in a web browser) does not liste= n
>for incoming connections is a limitation imposed by the WebSocket API,<= br> >not by this draft. This specification defines 2 entities: a SIP
>WebSocket Client and a SIP WebSocket Server, so nobody stops you from >creating an entity that implements both and can accept incoming
>WebSocket connections. Of course, such an application would not run in = a
>browser.
>
>
>Regards,
>
>--
>Sa=FAl Ibarra Corretg=E9
>AG Projects
>
>




--
= Thanks,
Nataraju A.B.

--f46d04426822e5b69c04bdf16561-- From pravindran@sonusnet.com Wed Apr 18 03:27:12 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10F8721F858B for ; Wed, 18 Apr 2012 03:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 Z7xfS+S4bDh6 for ; Wed, 18 Apr 2012 03:27:11 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id 18A2D21F84BF for ; Wed, 18 Apr 2012 03:27:04 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKT46W+ISe9gUvHj5hu9aDncK2TJsZPk3r@postini.com; Wed, 18 Apr 2012 03:27:05 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 18 Apr 2012 06:27:38 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 15:56:59 +0530 From: "Ravindran, Parthasarathi" To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: AQHNHSsWQiKr/IZJokCfX43Mp6RbG5agJJrA//+unYCAAGacsP//rqsAgABc8LD//6maAAAMSNZA//+qS4D//6NDQIAAYpwA//+iOyA= Date: Wed, 18 Apr 2012 10:26:58 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs , "Nataraju A.B" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 10:27:12 -0000 Saul, I guess that you wish to see the requirement like "As per this specification, SIP UA MUST implement UDP, TCP transport apart from Websocket as a transport" Please note that my intention of the this mail thread is not to create this requirement but to clarify the implementers about proxy usage. Thanks Partha=20 >-----Original Message----- >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] >Sent: Wednesday, April 18, 2012 3:44 PM >To: Ravindran, Parthasarathi >Cc: SIPCORE (Session Initiation Protocol Core) WG; SIPCORE Chairs; I=F1aki >Baz Castillo; Nataraju A.B >Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible >in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip- >websocket-02] > > >On Apr 18, 2012, at 12:07 PM, Ravindran, Parthasarathi wrote: > >> Even if it is the limitations of websocket, SIP UA MUST listen in UDP >> & TCP as per RFC 3261 and not adhere to this requirement which MUST be >> considered as a violation of RFC 3261. In case you think that this >> draft does not violate any RFC 3261 for SIP UA, the Current text in >> the draft is not clear enough, Please mention it explicitly in the >> draft that >> > >"MUST implement" doesn't imply "MUST use" AFAIK. > >> "As per this specification, SIP UA MUST support UDP, TCP transport >> apart from Websocket as a transport" >> > >It's not needed, 3261 sec 18 covers this: " All SIP elements MUST >implement UDP and TCP. SIP elements MAY implement other protocols." > >> This information helps for the implementers who wish to use this draft >> for RTCWeb client to SIP Interop in the standard way. I'm writing this >> mail as most of the folks support this draft for interworking RTCWeb >> client to SIP in the standard manner as per my discussion in IETF-83. >> >> I'll write the separate mail thread for discussing incoming SIP over >> websocket as it is one another major open item in this draft. >> > >I don't think it's a "major open item", the draft specifies it, but t >can't be used in a RTCWeb context because browsers don't listen for >incoming WebSocket connections. Other endpoints implementing this draft >will be able to listen for incoming connections just fine. > >-- >Sa=FAl Ibarra Corretg=E9 >AG Projects > > From nataraju.sip@gmail.com Wed Apr 18 03:29:31 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1892921F8593 for ; Wed, 18 Apr 2012 03:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 cf9issrc9bmI for ; Wed, 18 Apr 2012 03:29:30 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF4AF21F858B for ; Wed, 18 Apr 2012 03:29:29 -0700 (PDT) Received: by lagj5 with SMTP id j5so6011755lag.31 for ; Wed, 18 Apr 2012 03:29:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gKxnkNsCkJwycqVGowLqr1+j9QAbcsj7BF+wR6nhATs=; b=t328ErfYE/7FLsjchAoj8pcPV00x3DzjvpwT2H0+CAx3oli6Niq5RXai3V8V/eYpe/ WuyOkGVJZX/ti29ir5+rRYgxq3JXWULa+uqFEYbOwzroiD9PYXMtWuwcku0quJGQryvQ KiGA49C2hOUEwnbqOLz17Ub4jjdAZhO+VmpdRQ5u+tEF6vrbQ8+S/bxl5ejBgD4gIZHi Pw4vVm+FSkrTUJl04iONkhiEuziksvevQa3g5yu5pt5vNbFRJQzypale8d2p3ekRRpPt vGOe6hU17KEicDNp2wytQLQP+hI8xlG9RkXKn2NnNHDLfqYnTlaZ6ygpy+vt+5PG8b3p P5CQ== MIME-Version: 1.0 Received: by 10.152.106.9 with SMTP id gq9mr1600331lab.14.1334744968777; Wed, 18 Apr 2012 03:29:28 -0700 (PDT) Received: by 10.112.103.103 with HTTP; Wed, 18 Apr 2012 03:29:28 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> Date: Wed, 18 Apr 2012 15:59:28 +0530 Message-ID: From: "Nataraju A.B" To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=f46d0408d3bfbad11204bdf187b4 Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs , =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 10:29:31 -0000 --f46d0408d3bfbad11204bdf187b4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Apr 18, 2012 at 3:37 PM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > Even if it is the limitations of websocket, SIP UA MUST listen in > UDP & TCP as per RFC 3261 and not adhere to this requirement which MUST > be considered as a violation of RFC 3261. In case you think that this dra= ft > does not violate any RFC 3261 for SIP UA, the Current text in the draft i= s > not > clear enough, Please mention it explicitly in the draft that > > [ABN] It may be overkill to ask Websocket client to support for TCP and UDP and listen for incoming connections, just to be inline / compatible with SIP. is it worth doing so ??? > "As per this specification, SIP UA MUST support UDP, TCP transport apart > from Websocket as a transport" > > This information helps for the implementers who wish to use this draft fo= r > RTCWeb client to SIP Interop in the standard way. I'm writing this mail a= s > most of the folks support this draft for interworking RTCWeb client to SI= P > in the standard manner as per my discussion in IETF-83. > > I'll write the separate mail thread for discussing incoming SIP over > websocket > as it is one another major open item in this draft. > > Thanks > Partha > > >-----Original Message----- > >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] > >Sent: Wednesday, April 18, 2012 3:23 PM > >To: Ravindran, Parthasarathi > >Cc: I=F1aki Baz Castillo; SIPCORE (Session Initiation Protocol Core) WG; > >SIPCORE Chairs; Nataraju A.B > >Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible > >in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip- > >websocket-02] > > > > > >On Apr 18, 2012, at 11:35 AM, Ravindran, Parthasarathi wrote: > > > >> As per your below statement, JavaScript with SIP and RTCWeb Browser > >MUST NOT use this draft as it violates RFC 3261. > >> > > > >It doesn't, see my previous email explaining why. > > > >> Also in IETF-83 SIPCore meeting, I noticed that SIP UA over websocket > >will not listen for the incoming call without registration but in case > >of your draft is written with SIP softphone (smartphone) in mind , it is > >possible to listen in Port 80 or any other Websocket port which is not > >addressed in this draft till now. We need to discuss and sort it out. > >> > > > >The fact that a JS SIP client (running in a web browser) does not listen > >for incoming connections is a limitation imposed by the WebSocket API, > >not by this draft. This specification defines 2 entities: a SIP > >WebSocket Client and a SIP WebSocket Server, so nobody stops you from > >creating an entity that implements both and can accept incoming > >WebSocket connections. Of course, such an application would not run in a > >browser. > > > > > >Regards, > > > >-- > >Sa=FAl Ibarra Corretg=E9 > >AG Projects > > > > > > --=20 Thanks, Nataraju A.B. --f46d0408d3bfbad11204bdf187b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 18, 2012 at 3:37 PM, Ravindran, = Parthasarathi <pravindran@sonusnet.com> wrote:
Even if it is the limitations of websocket, SIP UA MUST listen in
UDP & TCP as per RFC 3261 and not adhere to this requirement which MUST=
be considered as a violation of RFC 3261. In case you think that this draft=
does not violate any RFC 3261 for SIP UA, the Current text in the draft is = not
clear enough, Please mention it explicitly in the draft that

[ABN] It may be overkill to ask Websocket client to s= upport for TCP and UDP and listen for=A0incoming=A0connections, just to be = inline / compatible with SIP.

=A0 =A0 =A0 =A0 =A0 = is it worth doing so ???
=A0 =A0 =A0
"As per this specification, SIP UA MUST support UDP, TCP transport apa= rt
from Websocket as a transport"

This information helps for the implementers who wish to use this draft for<= br> RTCWeb client to SIP Interop in the standard way. I'm writing this mail= as
most of the folks support this draft for interworking RTCWeb client to SIP<= br> in the standard manner as per my discussion in IETF-83.

I'll write the separate mail thread for discussing incoming SIP over we= bsocket
as it is one another major open item in this draft.

Thanks
Partha

>-----Original Message-----
>From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com]
>Sent: Wednesday, April 18, 2012 3:23 PM
>To: Ravindran, Parthasarathi
>Cc: I=F1aki Baz Castillo; SIPCORE (Session Init= iation Protocol Core) WG;
>SIPCORE Chairs; Nataraju A.B
>Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible=
>in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-<= br> >websocket-02]
>
>
>On Apr 18, 2012, at 11:35 AM, R= avindran, Parthasarathi wrote:
>
>> As per your below statement, JavaScript with SIP and RTCWeb Browse= r
>MUST NOT use this draft as it violates RFC 3261.
>>
>
>It doesn't, see my previous email explaining why.
>
>> Also in IETF-83 SIPCore meeting, I noticed that SIP UA over websoc= ket
>will not listen for the incoming call without registration but in case<= br> >of your draft is written with SIP softphone (smartphone) in mind , it i= s
>possible to listen in Port 80 or any other Websocket port which is not<= br> >addressed in this draft till now. We need to discuss and sort it out. >>
>
>The fact that a JS SIP client (running in a web browser) does not liste= n
>for incoming connections is a limitation imposed by the WebSocket API,<= br> >not by this draft. This specification defines 2 entities: a SIP
>WebSocket Client and a SIP WebSocket Server, so nobody stops you from >creating an entity that implements both and can accept incoming
>WebSocket connections. Of course, such an application would not run in = a
>browser.
>
>
>Regards,
>
>--
>Sa=FAl Ibarra Corretg=E9
>AG Projects
>
>




--
= Thanks,
Nataraju A.B.

--f46d0408d3bfbad11204bdf187b4-- From saul@ag-projects.com Wed Apr 18 03:35:30 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B1D21F85A7 for ; Wed, 18 Apr 2012 03:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hgZb7-UtuJ9u for ; Wed, 18 Apr 2012 03:35:29 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 53A4321F85F8 for ; Wed, 18 Apr 2012 03:35:29 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 3A7AEB019C; Wed, 18 Apr 2012 12:35:27 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 83712B019C; Wed, 18 Apr 2012 12:35:27 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> Date: Wed, 18 Apr 2012 12:35:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9E57421D-1F08-4C36-9C9F-1B3F23702FED@ag-projects.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1084) Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs , "Nataraju A.B" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 10:35:30 -0000 Partha, On Apr 18, 2012, at 12:26 PM, Ravindran, Parthasarathi wrote: > Saul, >=20 > I guess that you wish to see the requirement like >=20 > "As per this specification, SIP UA MUST implement UDP, TCP transport > apart from Websocket as a transport" >=20 > Please note that my intention of the this mail thread is not to > create this requirement but to clarify the implementers about proxy = usage. >=20 No, I don't wish to see any of that. Have a look at RFC4168, it defines = SCTP and it doesn't say any of that, it's perfectly clear that that = specification (and this one) define *new* transports for the SIP = protocol. I don't see a need to remind people of what RFC3261 says. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Wed Apr 18 04:37:38 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B9E21F85B5 for ; Wed, 18 Apr 2012 04:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CGeZtmrfz+-Z for ; Wed, 18 Apr 2012 04:37:38 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2483621F84F0 for ; Wed, 18 Apr 2012 04:37:38 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5650815vbb.31 for ; Wed, 18 Apr 2012 04:37:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=MZLrvazrAsaZ9lJgF2RQ2AUsv1Blov2I4V/rVncKSww=; b=XLaFs97LoMplFuk1sUtQvdOssilmtJM5x2UK3ycNaTzFPfnoag8AmUa1SWq6Ul00La iB2iVWkqLqszm+/1vCdFb3YKLXihe7pkqNFHyzkM/4XxMfuDsZMd6+gnPqL5yavrd33m dEpEuE3Qs26zK1T2QZ8go3BPflO+6NXYDd0HcFfvYoa5ZbbTMxJT5XWW/uYpt++EOIfp t451V7EHKpaCUBqLwP66F/L3bXLELKNvwB1a0WcYs3WcYTTj3h7t8VgCyj5Kh6NPC+lY ynHjlxZfDy5bPikF9acmE0cWV1rIASB8CWspIWSlSQsrmmgLoXkEwzOJNCWjG4mE79ft 1i/w== Received: by 10.52.15.233 with SMTP id a9mr885316vdd.34.1334749057367; Wed, 18 Apr 2012 04:37:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 18 Apr 2012 04:37:16 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 18 Apr 2012 13:37:16 +0200 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmglVaB4aWDAtWVVcHUjgXRWiPa/DTr/ZwOuWpEtctM6RWrZ5mo2hnBrDrg3WH6q00k71Iw Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 11:37:38 -0000 2012/4/18 Ravindran, Parthasarathi : > I guess that you wish to see the requirement like > > "As per this specification, SIP UA MUST implement UDP, TCP transport > apart from Websocket as a transport" Please check RFC 4168 (SIP SCTP transport) and find a similar statement. > Please note that my intention of the this mail thread is not to > create this requirement but to clarify the implementers about proxy usage= . Thanks for clarifying it. If not, someone might think that what you claim is that a web browser can not be SIP compliant since it does not speak SIP UDP/TCP. Regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed Apr 18 06:40:22 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095DE21F85AD for ; Wed, 18 Apr 2012 06:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.039 X-Spam-Level: X-Spam-Status: No, score=-6.039 tagged_above=-999 required=5 tests=[AWL=-0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 AxXeWHmr665K for ; Wed, 18 Apr 2012 06:40:18 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 85AFB21F85AE for ; Wed, 18 Apr 2012 06:40:17 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-42-4f8ec4407e07 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1F.5D.03534.044CE8F4; Wed, 18 Apr 2012 15:40:16 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 18 Apr 2012 15:40:15 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Ravindran, Parthasarathi" Date: Wed, 18 Apr 2012 15:40:14 +0200 Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: Ac0dV67svO1YCScfS/a3+V9zCbXpDwAECDKA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , =?utf-8?B?U2HDumwgSWJhcnJhIENvcnJldGfDqQ==?= Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 13:40:22 -0000 SGksDQoNCkkgbWF5IGhhdmUgbWlzdW5kZXJzdG9vZCBzb21ldGhpbmcgaW4gdGhlIGNvbnZlcnNh dGlvbiwgYnV0IG15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gY29uc2lkZXIgKk5PVCogbWFuZGF0 aW5nIFNJUCBXZWJTb2NrZXQgY2xpZW50cyB0byBpbXBsZW1lbnQgU0lQIFVEUCBhbmQgVENQLg0K DQpFc3BlY2lhbGx5IGlmIEkgd3JpdGUgYSBKYXZhU2NyaXB0IFNJUCBicm93c2VyIGFwcCwgSSB2 ZXJ5IGxpa2VseSB3b3VsZCB3YW50IHRvIHN1cHBvcnQgb25seSBXZWJTb2NrZXQuDQoNCkFsc28s IEkgZG9uJ3QgdGhpbmsgd2UgY2FuIGRpcmVjdGx5IGNvbXBhcmUgd2l0aCBTQ1RQLCBzaW5jZSB0 aGUgdHlwaWNhbCB1c2UtY2FzZSBmb3IgV2ViU29ja2V0IGlzIGJyb3dzZXIgYXBwcyAoZXZlbnRo b3VnaCBhIG5hdGl2ZSBhcHAgY2FuIG9mIGNvdXJzZSBhbHNvIHVzZSBXUykuDQoNClJlZ2FyZHMs DQoNCkNocmlzdGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzaXBjb3Jl LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBJw7Fha2kgQmF6IENhc3RpbGxvDQpTZW50OiAxOC4gaHVodGlrdXV0YSAyMDEyIDE0 OjM3DQpUbzogUmF2aW5kcmFuLCBQYXJ0aGFzYXJhdGhpDQpDYzogU0lQQ09SRSAoU2Vzc2lvbiBJ bml0aWF0aW9uIFByb3RvY29sIENvcmUpIFdHOyBTYcO6bCBJYmFycmEgQ29ycmV0Z8OpDQpTdWJq ZWN0OiBSZTogW3NpcGNvcmVdIFN0YXRlbGVzcyBvciBUcmFuc2FjdGlvbiBzdGF0ZWZ1bCBwcm94 eSBwb3NzaWJsZSBpbiBXZWJzb2NrZXQgdHJhbnNwb3J0PyBbUkU6IENhbGwgZm9yIEFkb3B0aW9u OiBkcmFmdC1pYmMtc2lwY29yZS1zaXAtd2Vic29ja2V0LTAyXQ0KDQoyMDEyLzQvMTggUmF2aW5k cmFuLCBQYXJ0aGFzYXJhdGhpIDxwcmF2aW5kcmFuQHNvbnVzbmV0LmNvbT46DQo+IEkgZ3Vlc3Mg dGhhdCB5b3Ugd2lzaCB0byBzZWUgdGhlIHJlcXVpcmVtZW50IGxpa2UNCj4NCj4gIkFzIHBlciB0 aGlzIHNwZWNpZmljYXRpb24sIFNJUCBVQSBNVVNUIGltcGxlbWVudCBVRFAsIFRDUCB0cmFuc3Bv cnQgDQo+IGFwYXJ0IGZyb20gV2Vic29ja2V0IGFzIGEgdHJhbnNwb3J0Ig0KDQpQbGVhc2UgY2hl Y2sgUkZDIDQxNjggKFNJUCBTQ1RQIHRyYW5zcG9ydCkgYW5kIGZpbmQgYSBzaW1pbGFyIHN0YXRl bWVudC4NCg0KDQo+IFBsZWFzZSBub3RlIHRoYXQgbXkgaW50ZW50aW9uIG9mIHRoZSB0aGlzIG1h aWwgdGhyZWFkIGlzIG5vdCB0byBjcmVhdGUgDQo+IHRoaXMgcmVxdWlyZW1lbnQgYnV0IHRvIGNs YXJpZnkgdGhlIGltcGxlbWVudGVycyBhYm91dCBwcm94eSB1c2FnZS4NCg0KVGhhbmtzIGZvciBj bGFyaWZ5aW5nIGl0LiBJZiBub3QsIHNvbWVvbmUgbWlnaHQgdGhpbmsgdGhhdCB3aGF0IHlvdSBj bGFpbSBpcyB0aGF0IGEgd2ViIGJyb3dzZXIgY2FuIG5vdCBiZSBTSVAgY29tcGxpYW50IHNpbmNl IGl0IGRvZXMgbm90IHNwZWFrIFNJUCBVRFAvVENQLg0KDQoNClJlZ2FyZHMuDQoNCg0KLS0NCknD sWFraSBCYXogQ2FzdGlsbG8NCjxpYmNAYWxpYXgubmV0Pg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3Jl QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUN Cg== From salvatore.loreto@ericsson.com Wed Apr 18 07:11:22 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C2D21F854F for ; Wed, 18 Apr 2012 07:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.638 X-Spam-Level: X-Spam-Status: No, score=-106.638 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 iO0dsw0d-Haz for ; Wed, 18 Apr 2012 07:11:18 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D0CC321F849B for ; Wed, 18 Apr 2012 07:11:17 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-a5-4f8ecb84da1f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C2.DE.25560.48BCE8F4; Wed, 18 Apr 2012 16:11:16 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Wed, 18 Apr 2012 16:11:16 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 40F822325 for ; Wed, 18 Apr 2012 17:11:15 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2AFB8525D4 for ; Wed, 18 Apr 2012 17:11:15 +0300 (EEST) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D93BD51848 for ; Wed, 18 Apr 2012 17:11:14 +0300 (EEST) Message-ID: <4F8ECB82.7070805@ericsson.com> Date: Wed, 18 Apr 2012 17:11:14 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:11:22 -0000 On 4/18/12 4:40 PM, Christer Holmberg wrote: > Hi, > > I may have misunderstood something in the conversation, but my suggestion would be to consider *NOT* mandating SIP WebSocket clients to implement SIP UDP and TCP. > > Especially if I write a JavaScript SIP browser app, I very likely would want to support only WebSocket. > > Also, I don't think we can directly compare with SCTP, since the typical use-case for WebSocket is browser apps (eventhough a native app can of course also use WS). I think that in general we can not compare SCTP to WebSocket at all because the first is a pure Transport Protocol, the latter is an application protocol that is used as transport. From a pure WebSocket prospective, what you are going to define is SIP as a websocket sub-protocol that is transported on top of. The important thing to standardize from a SIPCore prospective is the interaction/translations that happens between the WebSocket server and the SIP proxy that are two different logical entities. my two cents Sal -- Salvatore Loreto, PhD www.sloreto.com From saul@ag-projects.com Wed Apr 18 07:24:11 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2244121F8549 for ; Wed, 18 Apr 2012 07:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.628 X-Spam-Level: X-Spam-Status: No, score=-1.628 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] 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 7NU5e89Pl+nO for ; Wed, 18 Apr 2012 07:24:10 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 69AC321F85C6 for ; Wed, 18 Apr 2012 07:24:08 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 9A91DB01A4; Wed, 18 Apr 2012 16:24:07 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id D6D6CB019C; Wed, 18 Apr 2012 16:24:06 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <4F8ECB82.7070805@ericsson.com> Date: Wed, 18 Apr 2012 16:24:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7C325C83-9C24-4051-9EC7-569D18C6561D@ag-projects.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1084) Cc: sipcore@ietf.org Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:24:11 -0000 Hi, On Apr 18, 2012, at 4:11 PM, Salvatore Loreto wrote: > On 4/18/12 4:40 PM, Christer Holmberg wrote: >> Hi, >>=20 >> I may have misunderstood something in the conversation, but my = suggestion would be to consider *NOT* mandating SIP WebSocket clients to = implement SIP UDP and TCP. >>=20 >> Especially if I write a JavaScript SIP browser app, I very likely = would want to support only WebSocket. >>=20 >> Also, I don't think we can directly compare with SCTP, since the = typical use-case for WebSocket is browser apps (eventhough a native app = can of course also use WS). >=20 > I think that in general we can not compare SCTP to WebSocket at all > because the first is a pure Transport Protocol, the latter is an = application protocol that is used as transport. >=20 > =46rom a pure WebSocket prospective, what you are going to define is = SIP as a websocket sub-protocol that is transported on top of. >=20 > The important thing to standardize from a SIPCore prospective is the = interaction/translations that happens between the WebSocket server and = the SIP proxy > that are two different logical entities. >=20 Sorry about the confusion, the only reason why I mentioned SCTP was to = illustrate that the suggested additions weren't IMHO necessary as they = weren't for SCTP. Just as an example. As I mentioned earlier, I would not mention anything regarding UDP and = TCP, 3261 applies. Even if browsers are not able to use TCP and UDP = directly I don't see a strong reason to forbid them. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Wed Apr 18 07:32:23 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A83021F85C7 for ; Wed, 18 Apr 2012 07:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=0.049, 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 kadukU390EvK for ; Wed, 18 Apr 2012 07:32:20 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F17421F85C5 for ; Wed, 18 Apr 2012 07:32:20 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5792761vbb.31 for ; Wed, 18 Apr 2012 07:32:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=arJvhOZauPxm3ikYIkzYDJXd1ig/Sh2HQpHcn5npyok=; b=gw+WAfmrTEXHh9uAYYZF1I0vK9qw5+4qDAbLAD84f7LrlVS1D04n4W7OjteDH52NPP sfHVAqVrhXpq1IgUjySixYE8yj0vdswYHpsKut00m50BxC6aesbApEp0riHeGj24u2ED vUBOSbX84QTwCQC2LkFfVZfWH0rPkhPaU6KJuRcH0gM/munlMhQLzAcHByAFPbYu88Na DcYUmCdCui9+k+P/0dfGQNGqtSC0v1pbWm4u59rBnxjCfPATRldtkIRqIU7f7Zz1BWGn Cq9PAKf04E3cUNXlMAT/ZoI7kR6EspEOQkz/7pokqkKgHmwTWO4x9RxCo5W1nertUbrF /WHg== Received: by 10.52.91.72 with SMTP id cc8mr1199793vdb.17.1334759539601; Wed, 18 Apr 2012 07:32:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 18 Apr 2012 07:31:59 -0700 (PDT) In-Reply-To: <7C325C83-9C24-4051-9EC7-569D18C6561D@ag-projects.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <7C325C83-9C24-4051-9EC7-569D18C6561D@ag-projects.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 18 Apr 2012 16:31:59 +0200 Message-ID: To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQltCbr2qUJGWZdO0HDnmFq6bFRQPryLHlDqvSRCb5cs6IgFPGpJ30btguNx8dYdBMwr6eMp Cc: sipcore@ietf.org Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:32:23 -0000 2012/4/18 Sa=C3=BAl Ibarra Corretg=C3=A9 : > As I mentioned earlier, I would not mention anything regarding UDP and TC= P, 3261 applies. Even if browsers are not able to use TCP and UDP directly = I don't see a strong reason to forbid them. Agreed. Let's imagine a SIP local network in which the administrator just wants SIP over TLS-TCP for security/privacy reasons, so SIP phones and the SIP proxy/PBX/server just talk TLS-TCP transport. Would we say that those SIP phones are violating the RFC 3261 since they are not listening into insecure UDP transport? I don't think so. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Apr 18 07:32:36 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF11C21F85BD for ; Wed, 18 Apr 2012 07:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.629 X-Spam-Level: X-Spam-Status: No, score=-2.629 tagged_above=-999 required=5 tests=[AWL=0.048, 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 rO7WWt9gl+Qs for ; Wed, 18 Apr 2012 07:32:36 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E3B0E21F855A for ; Wed, 18 Apr 2012 07:32:35 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1232398vcb.31 for ; Wed, 18 Apr 2012 07:32:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=g6oKqBiqFhxipIvkwAMjPCIK61/pDrHznsdm2O2VzrU=; b=Fu01DxL72iqatB39SYcC/LiD0urnr+1HP36brOtWNFj9uRsH5WHPCfqHPiX/aAt1kb ZEHhSgTi01QamMgQUCT9btZQMwElym90zlqVZ4gc/6cDaBIUASJV6VvfPLmKm7Qdx6qK vg6rTDnsuxKJ7NMvSKMeugSUs1iR9q/Hb3uBNHhilU4hUhDIaydXVgsi6tbEEb/0ZvlA JGWujjbGJ5z6O5Qljw6wPxwRPRiZIMIN9LyAr2wL1EzR3qCFkBHnSQMYBhWobQ6WfO69 zmXYYsORfMxL8gfiDuuhAiMglsU9FigvPqvzcGPEq5otwGkTTlwWmy6Qn45sJ5cWyg1f OeuQ== Received: by 10.220.140.207 with SMTP id j15mr1425885vcu.22.1334759555359; Wed, 18 Apr 2012 07:32:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 18 Apr 2012 07:24:13 -0700 (PDT) In-Reply-To: <4F8ECB82.7070805@ericsson.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 18 Apr 2012 16:24:13 +0200 Message-ID: To: Salvatore Loreto Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkyW3he3e/RcP5MmCfC2++s4iHGbfl5c5ncxHxyftafjbvPw4SjgdojXAVPqmBJcim6hLaD Cc: sipcore@ietf.org Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:32:36 -0000 2012/4/18 Salvatore Loreto : > The important thing to standardize from a SIPCore prospective is the > interaction/translations that happens between the WebSocket server and th= e > SIP proxy that are two different logical entities. Hi Salvatore, I don't consider them two different logical entities. The draft 02 states the following in "Definitions" section (which was added after your review): SIP WebSocket Server: A SIP entity capable of listening for inbound connections from WebSocket clients and speaking the WebSocket SIP Sub-Protocol as defined by this document. So when the WebSocket message/arrives to the WebSocket listening server, the application on top of it (a SIP proxy/UAS) should extract the SIP message from the WS message, parse it and process it in the same way that if the SIP message arrived via another SIP transport. Just it. And for sending responses the SIP proxy/UAS should reuse the existing WS connection (which implies creating a WS message and writting the SIP response inside). Just it. The same is true for a SIP WebSocket Client: SIP WebSocket Client: A SIP entity capable of opening outbound connections with WebSocket servers and speaking the WebSocket SIP Sub-Protocol as defined by this document. For example, if the SIP application is a JavaScript code running on a web browser, the SIP stack (JS code) sends and receives SIP messages to/from its transport layer (as in any other SIP transport), but in this case the transport layer is a WebSocket client interface which generates a WS message (using the JS WebSocket API) and sends it. Same occurs when receiving an incoming SIP request/response which is extracted by the JS app (the SIP stack) from the received WS message. So honestly I see no "interaction/translations that happens between the WebSocket server and the SIP proxy". Best regards. --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Wed Apr 18 07:47:56 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCE021F84DC for ; Wed, 18 Apr 2012 07:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 GKjrArGP3IyI for ; Wed, 18 Apr 2012 07:47:55 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5539B21F84BF for ; Wed, 18 Apr 2012 07:47:55 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta06.westchester.pa.mail.comcast.net with comcast id zRmu1i0081swQuc56Snvcb; Wed, 18 Apr 2012 14:47:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id zSnv1i01307duvL3bSnvyS; Wed, 18 Apr 2012 14:47:55 +0000 Message-ID: <4F8ED41A.6060703@alum.mit.edu> Date: Wed, 18 Apr 2012 10:47:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:47:56 -0000 On 4/18/12 4:23 AM, Ravindran, Parthasarathi wrote: > Please note that SIP UA with TLS transport is not going to violate Sec > 18 of RFC 3261 “All SIP elements MUST implement UDP and TCP.”. > In the below mentioned callflow, proxy shall > acts as stateless or transaction stateful proxy wherein UAC shall sent > INVITE with SIPS URI I think we need to bite the bullet here and decide to revise/clarify that statement in 3261. There is a note following that statement that is useful context for understanding it: All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols. Making TCP mandatory for the UA is a substantial change from RFC 2543. It has arisen out of the need to handle larger messages, which MUST use TCP, as discussed below. Thus, even if an element never sends large messages, it may receive one and needs to be able to handle them. Clearly there are some objectives that this normative statement is trying to solve: - a basic level of protocol interoperability - support for large messages I think we can find a way to achieve those objectives while loosening the requirements to support the sorts of constrained implementation environments we are seeing. Both the websocket transport and outbound rely upon a neighboring sip element to bridge the gap to interoperability. So rather than implementing UDP and TCP itself, the websocket client depends upon the websocket server to implement them on its behalf. I think it will take a bit work to craft new language that provides the needed additional flexibility while not giving license to create implementations that lack basic interoperability. Thanks, Paul From pkyzivat@alum.mit.edu Wed Apr 18 07:58:54 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 494AF21F8483 for ; Wed, 18 Apr 2012 07:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 fjs5RFno16On for ; Wed, 18 Apr 2012 07:58:53 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id AFB3221F84E4 for ; Wed, 18 Apr 2012 07:58:53 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by QMTA11.westchester.pa.mail.comcast.net with comcast id zNsx1i0031swQuc5BSyuzc; Wed, 18 Apr 2012 14:58:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id zSyu1i00907duvL3bSyuYv; Wed, 18 Apr 2012 14:58:54 +0000 Message-ID: <4F8ED6AC.3050602@alum.mit.edu> Date: Wed, 18 Apr 2012 10:58:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 14:58:54 -0000 There has already been a lot of discussion on this thread. But one fundamental point about the message below doesn't seem to have been mentioned. (Or did I miss it?) See inline. On 4/18/12 3:28 AM, Nataraju A.B wrote: > Partha, > > I was referring to scenario, > > UAC Proxy UAS > -----sips/tcp----> ------>sip/udp ---> > > UAC requested for a secure connection. But assume proxy at the edge and > can't guarantee secure connection towards UAS. hence It is sending a > request to UAS over simple udp *without security*. This was allowed by 3261, but that behavior was repealed by rfc5630 section 5.3. Thanks, Paul > In this case, proxy must behave like a dialog stateful proxy. stateless > or transaction stateful proxy can't inter work in this scenario. > > This is my understanding. Others please share your opinion on the same.... > > Thanks, > Nataraju A B From pravindran@sonusnet.com Wed Apr 18 08:10:56 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18D421F856A for ; Wed, 18 Apr 2012 08:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41EyzdKvrJ7Q for ; Wed, 18 Apr 2012 08:10:52 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC0221F85CD for ; Wed, 18 Apr 2012 08:10:51 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKT47Zes9Chz4KjwfW63yRpHgok2S4OECy@postini.com; Wed, 18 Apr 2012 08:10:51 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 18 Apr 2012 11:11:24 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 18 Apr 2012 20:40:44 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: AQHNHSsWQiKr/IZJokCfX43Mp6RbG5agJJrA//+unYCAAGacsIAAFBwAgABihBA= Date: Wed, 18 Apr 2012 15:10:44 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> In-Reply-To: <4F8ED41A.6060703@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 15:10:56 -0000 Hi Paul/Inaki, We are in the same page that there is no need of UDP and TCP transport whil= e websocket is used as a transport in SIP UA even though it is a deviation = from RFC 3261. As Nataraj/Christer mentioned in the other mail threads, UDP= & TCP is an overkill for SIP UA while using SIP UA with websocket and non-= starter for web-browsers with SIP based on Javascript.=20 Having said that, please indicate that Websocket (to any transport) Proxy M= UST include record-route header in all SIP messages and it is a mandatory h= eader for websocket proxy as per this specification. It may be preferable t= o provide the reason for this mandating. IMO, This information helps websoc= ket proxy implementers. Also indicates that, stateless proxy is not applic= able for this transport. I like to hear in case any other way to make SIP over websocket works witho= ut record-route header. Thanks Partha >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >Behalf Of Paul Kyzivat >Sent: Wednesday, April 18, 2012 8:18 PM >To: sipcore@ietf.org >Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible >in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip- >websocket-02] > >On 4/18/12 4:23 AM, Ravindran, Parthasarathi wrote: > >> Please note that SIP UA with TLS transport is not going to violate Sec >> 18 of RFC 3261 "All SIP elements MUST implement UDP and TCP.". >> In the below mentioned callflow, proxy shall acts as stateless or >> transaction stateful proxy wherein UAC shall sent INVITE with SIPS URI > >I think we need to bite the bullet here and decide to revise/clarify >that statement in 3261. There is a note following that statement that is >useful context for understanding it: > > All SIP elements MUST implement UDP and TCP. SIP elements MAY > implement other protocols. > > Making TCP mandatory for the UA is a substantial change from RFC > 2543. It has arisen out of the need to handle larger messages, > which MUST use TCP, as discussed below. Thus, even if an element > never sends large messages, it may receive one and needs to be > able to handle them. > >Clearly there are some objectives that this normative statement is >trying to solve: > >- a basic level of protocol interoperability >- support for large messages > >I think we can find a way to achieve those objectives while loosening >the requirements to support the sorts of constrained implementation >environments we are seeing. > >Both the websocket transport and outbound rely upon a neighboring sip >element to bridge the gap to interoperability. So rather than >implementing UDP and TCP itself, the websocket client depends upon the >websocket server to implement them on its behalf. > >I think it will take a bit work to craft new language that provides the >needed additional flexibility while not giving license to create >implementations that lack basic interoperability. > > Thanks, > Paul > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From dworley@avaya.com Wed Apr 18 08:48:34 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A801921F85B7 for ; Wed, 18 Apr 2012 08:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.219 X-Spam-Level: X-Spam-Status: No, score=-103.219 tagged_above=-999 required=5 tests=[AWL=0.380, 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 iUuqNdZQtyC4 for ; Wed, 18 Apr 2012 08:48:33 -0700 (PDT) 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 7F54C21F8534 for ; Wed, 18 Apr 2012 08:48:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAA3ijk+HCzI1/2dsb2JhbABEsT2BB4IJAQEBAQIBEig/BQsCAQgNCCEQMiUBAQQOBQgah2gFng2dLJAFYwScBIolgwM X-IronPort-AV: E=Sophos;i="4.75,442,1330923600"; d="scan'208";a="302494656" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 18 Apr 2012 11:48:29 -0400 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Apr 2012 11:31:57 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 18 Apr 2012 11:48:30 -0400 From: "Worley, Dale R (Dale)" To: Shida Schubert Date: Wed, 18 Apr 2012 11:48:28 -0400 Thread-Topic: [sipcore] draft-ietf-sipcore-rfc4244bis-07, sections 1 to 5 Thread-Index: Ac0c91NdxOkT/1B9Qn64g8kixaFwsgAgemy8 Message-ID: References: , <8A41EEBD-DE37-4E5A-9B01-41F1F0C46380@ntt-at.com> In-Reply-To: <8A41EEBD-DE37-4E5A-9B01-41F1F0C46380@ntt-at.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-07, sections 1 to 5 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 15:48:34 -0000 > From: Shida Schubert [shida@ntt-at.com] >=20 > > "np": The hi-targeted-to-URI represents that there was no > > change in Request-URI. This would apply for example when a > > proxy merely forwards a request to a next hop proxy and loose > > routing is used. > > > > Unlike the previous two cases, this case does not describe the > > function of the value of the np parameter. >=20 > Any suggestion for rewording? Assuming that the values of the three parameters are intended to carry the same information (that is, the index of the hi-entry from which this request-URI was derived), the value of "np" would be the index of the parent hi-entry of this hi-entry. As in the example in 5.1: | History-Info: ;index=3D1 | History-Info: ;np=3D1;index=3D1.1 Largely copying the wording of the entry for "rc", we can add: "np": The hi-targeted-to-URI represents that there was no change in Request-URI. This would apply for example when a proxy merely forwards a request to a next hop proxy and loose routing is used. >>>The "np" header field parameter contains the value of the hi-index in the hi-entry with an hi-targeted-to-uri that reflects the Request-URI that was copied unchanged into the request represented by this hi-entry. That value will usually be the hi-index of the parent hi-entry of this hi-entry.<<< While I was lookng at this, the entry for "mp" has some awkward wording that could be improved by copying the wording from "rc". Instead of The "mp" header field parameter contains the >>>value which represents the value<<< of the hi-index in the hi-entry ... perhaps The "mp" header field parameter contains the >>>value<<< of the hi-index in the hi-entry ... Dale From ibc@aliax.net Wed Apr 18 08:56:14 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6008521F85BD for ; Wed, 18 Apr 2012 08:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=0.047, 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 VqITSTA677CK for ; Wed, 18 Apr 2012 08:56:13 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9410421F85B9 for ; Wed, 18 Apr 2012 08:56:13 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1308780vcb.31 for ; Wed, 18 Apr 2012 08:56:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ACHlwg5oCpSQcPf1bGe+dJgf3iKHUGhz1p1tWTpc4hM=; b=Xew6aeBBpjEnQtum19Mwria5BgmK845/2fSrmoKlkyB1E51hJcLU/QvxRLRIrqsC4Z RATzzjnsQgkCCnl5Bi3Pr3TvQWM3Lk17bcVL4OO143xpMZ+N8/d46Zm7Q7Rcw5SDQdSi okeBHyAQ0WcQl9DV2G0MkS33BUctqNW9tsuO0ZYCJQxTtJS6OcpDYLvM/AAQvnYC4G8h iAahSpIRPfXlkkqjXuiTMxWgZxy+7N31OZQ9YQ7QPahJHXws5cbiuLWt9aavwy6xh+Vl 8sf2+gxMlWNN6qpHizOWsXtXImxcW240dCN+E89H6vut+caa7PGyLCidFvrbU2nvhYMF W8hw== Received: by 10.52.15.233 with SMTP id a9mr1302966vdd.34.1334764573031; Wed, 18 Apr 2012 08:56:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 18 Apr 2012 08:55:52 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 18 Apr 2012 17:55:52 +0200 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmjzl17va1U2u+N4gBHVqCgjaT0B6wAji5xs3VYGqFFvUEh/EvbcldTF9XZ7DRN7KdhpzjD Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 15:56:14 -0000 2012/4/18 Ravindran, Parthasarathi : > Having said that, please indicate that Websocket (to any transport) Proxy= MUST include record-route header in all SIP messages and it is a mandatory= header for websocket proxy as per this specification. It may be preferable= to provide the reason for this mandating. IMO, This information helps webs= ocket proxy implementers. Hi Ravindran. If a proxy behaves as an Outbound Edge Proxy (RFC 5626) then it adds Record-Route always (since NATted clients can only receive incoming requests from their Outbound proxy via TCP, UDP, or WebSocket). Implementing RFC 5626 "Outbound" was a MUST in previous draft version, but such a requirement was removed in IETF #83 after consensus by members of this WG, so the draft does NOT mandate RFC 5626 (which IMHO is a good decision since it "just defines a new SIP transport" rather than a complete SIP topology). Anyhow, Record-Route (Loose-Routing mechanism as defined in RFC 3261) is *NOT* required in *ALL* the cases in which a SIP WebSocket UA is involved, for example: - alice is a SIP UA implementing a SIP WS Client and a SIP WS Server (so it can open and accept WS connections). - The very same for bob, another SIP WS UA. But bob also speaks UDP and registers to P1 via UDP. - P1 is a proxy/registrar implementing a SIP WebSocket Server (so just listens for inbound WS connections) and also UDP. - P1 does NOT perform Loose-Routing (it does NOT add Record-Route headers). - alice, bob and P1 are located in the same network (or have public IP...). So: alice P1 bob F1 INVITE -----(WS)---------> F2 INVITE ----(UDP)-------> F3 <---(UDP)----------- 200 F4 <-----(WS)----------- 200 F5 ACK ---------------------(WS)----------------------> F6 <------------------------(WS)------------------- BYE F7 200 ---------------------(WS)----------------------> F1: INVITE from alice has a Contact URI with ;transport=3Dws. F2. P1 does NOT add Record-Route header. F3. 200 from bob contains a Contact URI with ;transport=3Dws (which is valid regardless the INVITE arrived via UDP transport). F5. alice opens a new WS connection to the Contact URI of bob (since ACK must be send end to end when there is no Record-Route in 200) and sends the ACK. F7. bob opens a new WS connection to the Contact URI of alice and sends the= BYE. This is perfectly valid according to RFC 3261 and there is NO need for Loose-Routing mechanism, so the draft MUST NOT mandate Loose-Routing mechanism. Again, you assume that the SIP WebSocket UA is a web browser that can only open outbound WS connections. The draft is not based on such an assumption (regardless we all know that this will be the scenario in 99% of cases). We leave the SIP topology open (this was recently discussed in this maillist before IETF #83). > Also indicates that, stateless proxy is not applicable for this transport= . Please read my previous replies. Stateless proxy CAN be used (please read my first reply in this thread in which I explain it). > I like to hear in case any other way to make SIP over websocket works wit= hout record-route header. See example above. Regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed Apr 18 09:09:30 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BC421F84D1 for ; Wed, 18 Apr 2012 09:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.033 X-Spam-Level: X-Spam-Status: No, score=-6.033 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 cpHgMkNGdsql for ; Wed, 18 Apr 2012 09:09:29 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B438421F8533 for ; Wed, 18 Apr 2012 09:09:26 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-f3-4f8ee735bb0f Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9E.CE.03534.537EE8F4; Wed, 18 Apr 2012 18:09:25 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Wed, 18 Apr 2012 18:09:25 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Wed, 18 Apr 2012 18:08:37 +0200 Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: Ac0dcESSbon/6yKjT6CJA4cSKMnSLAADT6U8 Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA3@ESESSCMS0356.eemea.ericsson.se> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <7C325C83-9C24-4051-9EC7-569D18C6561D@ag-projects.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:09:30 -0000 Hi, >> As I mentioned earlier, I would not mention anything regarding UDP and T= CP, 3261 applies. Even if >>browsers are not able to use TCP and UDP direct= ly I don't see a strong reason to forbid them. > > Agreed. Let's imagine a SIP local network in which the administrator > just wants SIP over TLS-TCP for security/privacy reasons, so SIP > phones and the SIP proxy/PBX/server just talk TLS-TCP transport. Would > we say that those SIP phones are violating the RFC 3261 since they are > not listening into insecure UDP transport? I don't think so. I agree that we shouldn't forbid. Regards, Christer= From ibc@aliax.net Wed Apr 18 09:13:47 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E500A21E8012 for ; Wed, 18 Apr 2012 09:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGEyCkli7qhY for ; Wed, 18 Apr 2012 09:13:47 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4373421E8011 for ; Wed, 18 Apr 2012 09:13:47 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so5883493vbb.31 for ; Wed, 18 Apr 2012 09:13:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=Qg7FKZbR5vVuA4SfUBwcDz/4IR9kEK+TkIHP+aVErts=; b=ePypkm0qsEC6mvMbwuVLBewPqWz/aNL+Zk3zl3QTfoByqx9u1W3gm012PyAFnklIrV mFglZEnehBb2mk4fD2HoyrArWDB/blr6ljxrXzuTB62UeFLlB7j1iGE0ZyeWnm6bYiwn GbDZccpICMnPzH20EDdeQ+Bb9SFBMDo2euRLarj3an98LUyVuihUz4sR9ID0TceHBhFu XJmcNy/Z527hYWcJ3jGEBaiTV5vsGyL938C1uCJKnkLRtf9izefNsoHoFrxNPXZ6wtzS WyUL3Wpy3fvBOOCjVnAUuXIUhwNDA85gkFeCsnKi9L5dJZVaNtTQ+wujTZQ8wGfjUMUt QyWw== Received: by 10.52.64.173 with SMTP id p13mr1317098vds.51.1334765626758; Wed, 18 Apr 2012 09:13:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 18 Apr 2012 09:13:25 -0700 (PDT) In-Reply-To: <4F8ED41A.6060703@alum.mit.edu> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 18 Apr 2012 18:13:25 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmbPsNokj2rgf38BILfO33G/e+lLaXjC7VwjhyNomiRET0pA/tjardPA1m+b9zq8Tx6QiIW Cc: sipcore@ietf.org Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:13:48 -0000 2012/4/18 Paul Kyzivat : > I think we can find a way to achieve those objectives while loosening the > requirements to support the sorts of constrained implementation environme= nts > we are seeing. > > Both the websocket transport and outbound rely upon a neighboring sip > element to bridge the gap to interoperability. So rather than implementin= g > UDP and TCP itself, the websocket client depends upon the websocket serve= r > to implement them on its behalf. > > I think it will take a bit work to craft new language that provides the > needed additional flexibility while not giving license to create > implementations that lack basic interoperability. Hi Paul, the scenario is similar to the one in which a SIP UA behind NAT registers using UDP through its Outbound Edge Proxy, so it can only receive incoming requests (from outside its local network) via its Outbound proxy. Neither it can receive inbound TCP connections. So, perhaps we could extract some related text from RFC 5626? But note that mandating RFC 5626 was removes in Paris due the got consensus. However, this discussion assumes that the SIP UA is a SIP WebSocket Client just capable of using WebSocket transport (so probably a web browser), and that the SIP WebSocket Server is a SIP proxy which cannot open outbound WS connections (and speaks other transports). This assumption does not exist in the draft. If a UA or a proxy implements both a SIP WebSocket Client and a SIP WebSocket Server then all this discussion becomes "invalid" since topology constrains are relaxed. So: - This draft does not assume network topology. - This draft does not assume clients and proxies/servers nature. - RFC 3261 mandates UDP and TCP. JavaScripts SIP stacks running in browsers will not implement SIP UDP/TCP. Are those SIP stacks "violating" RFC 3261? well, things change since 2002, and probably a SIP transport like WebSocket was not expected when RFC 3261 was written. But anyhow, from the point of view of the draft itself, IMHO the spec is not violating RFC 3261 since it does not assume the "web browser" scenario. Best regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed Apr 18 09:21:18 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5C121F8552 for ; Wed, 18 Apr 2012 09:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.028 X-Spam-Level: X-Spam-Status: No, score=-6.028 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 rQXB5zFGkfD5 for ; Wed, 18 Apr 2012 09:21:14 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8520F21F84FA for ; Wed, 18 Apr 2012 09:21:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-1a-4f8ee9f8245d Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id FE.FC.25560.8F9EE8F4; Wed, 18 Apr 2012 18:21:12 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 18 Apr 2012 18:21:12 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "Ravindran, Parthasarathi" Date: Wed, 18 Apr 2012 18:17:14 +0200 Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: Ac0de8rSvBg/7y99SAWy7ZhSsgL4GgAAuxeR Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:21:18 -0000 Hi, In general I agree that a transport mechanism specification shouldn't manda= te entities to Record-Route. But, as others have also indicated, in most cases it will be needed. The si= gnalling path between the UA and the "outbound proxy" will be established a= lready during registration (which means the proxy will also have to insert = Path), and will then be used for UA originating and terminating sessions. Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of I=F1= aki Baz Castillo [ibc@aliax.net] Sent: Wednesday, April 18, 2012 6:55 PM To: Ravindran, Parthasarathi Cc: sipcore@ietf.org Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in = Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocke= t-02] 2012/4/18 Ravindran, Parthasarathi : > Having said that, please indicate that Websocket (to any transport) Proxy= MUST include record-route header in all SIP messages and it is a mandatory= header for websocket proxy as per this specification. It may be preferable= to provide the reason for this mandating. IMO, This information helps webs= ocket proxy implementers. Hi Ravindran. If a proxy behaves as an Outbound Edge Proxy (RFC 5626) then it adds Record-Route always (since NATted clients can only receive incoming requests from their Outbound proxy via TCP, UDP, or WebSocket). Implementing RFC 5626 "Outbound" was a MUST in previous draft version, but such a requirement was removed in IETF #83 after consensus by members of this WG, so the draft does NOT mandate RFC 5626 (which IMHO is a good decision since it "just defines a new SIP transport" rather than a complete SIP topology). Anyhow, Record-Route (Loose-Routing mechanism as defined in RFC 3261) is *NOT* required in *ALL* the cases in which a SIP WebSocket UA is involved, for example: - alice is a SIP UA implementing a SIP WS Client and a SIP WS Server (so it can open and accept WS connections). - The very same for bob, another SIP WS UA. But bob also speaks UDP and registers to P1 via UDP. - P1 is a proxy/registrar implementing a SIP WebSocket Server (so just listens for inbound WS connections) and also UDP. - P1 does NOT perform Loose-Routing (it does NOT add Record-Route headers). - alice, bob and P1 are located in the same network (or have public IP...). So: alice P1 bob F1 INVITE -----(WS)---------> F2 INVITE ----(UDP)-------> F3 <---(UDP)----------- 200 F4 <-----(WS)----------- 200 F5 ACK ---------------------(WS)----------------------> F6 <------------------------(WS)------------------- BYE F7 200 ---------------------(WS)----------------------> F1: INVITE from alice has a Contact URI with ;transport=3Dws. F2. P1 does NOT add Record-Route header. F3. 200 from bob contains a Contact URI with ;transport=3Dws (which is valid regardless the INVITE arrived via UDP transport). F5. alice opens a new WS connection to the Contact URI of bob (since ACK must be send end to end when there is no Record-Route in 200) and sends the ACK. F7. bob opens a new WS connection to the Contact URI of alice and sends the= BYE. This is perfectly valid according to RFC 3261 and there is NO need for Loose-Routing mechanism, so the draft MUST NOT mandate Loose-Routing mechanism. Again, you assume that the SIP WebSocket UA is a web browser that can only open outbound WS connections. The draft is not based on such an assumption (regardless we all know that this will be the scenario in 99% of cases). We leave the SIP topology open (this was recently discussed in this maillist before IETF #83). > Also indicates that, stateless proxy is not applicable for this transport= . Please read my previous replies. Stateless proxy CAN be used (please read my first reply in this thread in which I explain it). > I like to hear in case any other way to make SIP over websocket works wit= hout record-route header. See example above. Regards. -- I=F1aki Baz Castillo _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From pkyzivat@alum.mit.edu Wed Apr 18 09:58:52 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B9F21F84EA for ; Wed, 18 Apr 2012 09:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 GHvvvhGSv-DE for ; Wed, 18 Apr 2012 09:58:51 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id B32C221F84D1 for ; Wed, 18 Apr 2012 09:58:50 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta14.westchester.pa.mail.comcast.net with comcast id zUb31i0011c6gX85EUyrng; Wed, 18 Apr 2012 16:58:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta23.westchester.pa.mail.comcast.net with comcast id zUyr1i01E07duvL3jUyrte; Wed, 18 Apr 2012 16:58:51 +0000 Message-ID: <4F8EF2C9.4030507@alum.mit.edu> Date: Wed, 18 Apr 2012 12:58:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 16:58:53 -0000 IƱaki, I agree that there is nothing in this draft that requires someone implementing it to violate 3261. However, as you mention below, a typical use case for this draft is javascript sip stacks running in a browser that would not be able to implement sip tcp and udp transports. AFAIK those would indeed be non-compliant to 3261. If we want to encourage such implementations, then we should do something so that they can be compliant. ISTM that this will require a revision to 3261. That could be done in a separate draft, or it could be done in this draft that is already revising 3261. One disadvantage to doing it in this draft is that then compliance to the revised language would be advertised by advertising support for *this* document. If the relaxation is to apply to other implementations of sip that don't want to implement the websocket transport, then it should be done separately. Thanks, Paul On 4/18/12 12:13 PM, IƱaki Baz Castillo wrote: > 2012/4/18 Paul Kyzivat: >> I think we can find a way to achieve those objectives while loosening the >> requirements to support the sorts of constrained implementation environments >> we are seeing. >> >> Both the websocket transport and outbound rely upon a neighboring sip >> element to bridge the gap to interoperability. So rather than implementing >> UDP and TCP itself, the websocket client depends upon the websocket server >> to implement them on its behalf. >> >> I think it will take a bit work to craft new language that provides the >> needed additional flexibility while not giving license to create >> implementations that lack basic interoperability. > > Hi Paul, the scenario is similar to the one in which a SIP UA behind > NAT registers using UDP through its Outbound Edge Proxy, so it can > only receive incoming requests (from outside its local network) via > its Outbound proxy. Neither it can receive inbound TCP connections. > > So, perhaps we could extract some related text from RFC 5626? But note > that mandating RFC 5626 was removes in Paris due the got consensus. > > > However, this discussion assumes that the SIP UA is a SIP WebSocket > Client just capable of using WebSocket transport (so probably a web > browser), and that the SIP WebSocket Server is a SIP proxy which > cannot open outbound WS connections (and speaks other transports). > This assumption does not exist in the draft. If a UA or a proxy > implements both a SIP WebSocket Client and a SIP WebSocket Server then > all this discussion becomes "invalid" since topology constrains are > relaxed. > > So: > > - This draft does not assume network topology. > - This draft does not assume clients and proxies/servers nature. > - RFC 3261 mandates UDP and TCP. > > > JavaScripts SIP stacks running in browsers will not implement SIP UDP/TCP. > Are those SIP stacks "violating" RFC 3261? well, things change since > 2002, and probably a SIP transport like WebSocket was not expected > when RFC 3261 was written. But anyhow, from the point of view of the > draft itself, IMHO the spec is not violating RFC 3261 since it does > not assume the "web browser" scenario. > > > Best regards. > > From ibc@aliax.net Wed Apr 18 10:07:27 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 303D721F84EC for ; Wed, 18 Apr 2012 10:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, 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 2tZJBLCK3ZjI for ; Wed, 18 Apr 2012 10:07:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 877E621F846D for ; Wed, 18 Apr 2012 10:07:26 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1368459vcb.31 for ; Wed, 18 Apr 2012 10:07:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=8UL9pTw33C1TQ78XYmsD9PNJsvVoKK2yiUSo6E8kpoU=; b=TCEqKJCVK2yty5AxSB4cxCcp72+7OekJi8amgKh/7G6UVEXO/Ti3DOTmV7LMa3zxFP 7ys08/R8wUm3Utf1EDmI0OqX4z9C9sA8xYMaC0MkN/7JcFLM0AoTDuZRBq4degzl+RaR 4lWpbocRPFtj227ufokqeZ9xn9J3lScffLMIt4ZysE+2lqHQ76vmXro9F84Cti9IGi1V rhFZUTKl7GTm5pW6QOs0ta6tdgH8/6hlVnC0mCkRUjBk0ALODCLnXa09FuLp9nmAHGSW GTm8SliNPrk1SMU6GZVeAWnIjVeVuoNJXTTcnNvoL0gCb85jYE7kNzmXqh8wE8/pKvcS 8uYg== Received: by 10.220.140.207 with SMTP id j15mr1740851vcu.22.1334768846015; Wed, 18 Apr 2012 10:07:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 18 Apr 2012 10:07:05 -0700 (PDT) In-Reply-To: <4F8EF2C9.4030507@alum.mit.edu> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <4F8EF2C9.4030507@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 18 Apr 2012 19:07:05 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmN9qXin/kplwgwdDXQOY7Ln+aujZry8f5/T/kEGzBTKkYoZ+3uXW1ZLyLk8xlKm6qRR1fv Cc: sipcore@ietf.org Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 17:07:27 -0000 2012/4/18 Paul Kyzivat : > However, as you mention below, a typical use case for this draft is > javascript sip stacks running in a browser that would not be able to > implement sip tcp and udp transports. AFAIK those would indeed be > non-compliant to 3261. If we want to encourage such implementations, then= we > should do something so that they can be compliant. ISTM that this will > require a revision to 3261. That could be done in a separate draft, or it > could be done in this draft that is already revising 3261. > > One disadvantage to doing it in this draft is that then compliance to the > revised language would be advertised by advertising support for *this* > document. If the relaxation is to apply to other implementations of sip t= hat > don't want to implement the websocket transport, then it should be done > separately. I agree. A new draft should address this issue by covering the following to= pics: - Scenarios in which just *secure* SIP transport is required (so UDP has no place). This could occur in local networks, providers networks or whatever. - Scenarios in which a single transport can be used (i.e. in Outbound topology in which UA's are behind different NAT's and connect to the same Edge Proxy using TCP or UDP, so they cannot receive requests via a different transport). - Special cases in which it's clear that ~100% of implementations are not able to support SIP UDP/TCP transports (as in this draft). Basically it would say "in certain cases a SIP entity MAY NOT implement UDP and/or TCP transports". --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Apr 18 10:52:24 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12E2421F84D8 for ; Wed, 18 Apr 2012 10:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.044, 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 VyVMXEyPUQID for ; Wed, 18 Apr 2012 10:52:20 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D0CAD21F84D0 for ; Wed, 18 Apr 2012 10:52:19 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1401593vcb.31 for ; Wed, 18 Apr 2012 10:52:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=V2jWh0aO831/1jO3YbHnfCT4z66JW6Bqj0+8pMNidBc=; b=HKlTE/hWxQA/0RaE5O7ctH2+o86lkyLpQwlpOLpaWY1tsuSagHXrp+q0rdDzj/BrZB Z4+s+kmAyUK9+TPTkOZjHPcLQ52rggwgQIj8bzf08sDOtSO4aYbwJSbi3oMglWCIZbOF E1z3saAGYKSf3y0bFajkGxLV971tBpBm9RMkK4490eDIzAOLJtsZLxqJrz0kWqmu+TV0 JpRUaalniweLAF01LZAKJQyrI9MR80UNlSVqeTkYeCO11AJcxqIrpYzRzgfBXUWP8Y5w ptAFQBpAJWZFWjtnq+J9NPazUF5Odtm75fB3eU7rY49dT4K4FbRGZcF6yJnAcfLV4vtb 7IHA== Received: by 10.52.91.72 with SMTP id cc8mr1525399vdb.17.1334771539093; Wed, 18 Apr 2012 10:52:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Wed, 18 Apr 2012 10:51:57 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 18 Apr 2012 19:51:57 +0200 Message-ID: To: "Nataraju A.B" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn0TCKo2gCNdnNpw1UxFjnogyXJ3ZB5yzkqtd/3LWI726E9ZBpQ7Oq6dI6upXtRt3AaxF4y Cc: vpascual@acmepacket.com, jmillan@aliax.net, sipcore@ietf.org Subject: Re: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - Review comments (Nataraju A B) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Apr 2012 17:52:24 -0000 2012/4/18 Nataraju A.B : > Hi Inaki, > > Please find some more comments inline... > > > Please let me know, the reasoning behind single transport parameter and t= wo > sent-protocol values. > sent-protocol : WS and WSS > transport =3D ws (only one new value) > > This might be confusing in future... Not really. In the same way that using SIP over TLS-TCP means ;transport=3Dtcp with sips schema, or sending SIP over TLS-SCTP means ;transport=3Dsctp with sips schema. So sending SIP over TLS-WebSocket must involve ;transport=3Dws as sips schema. Note that ;transport=3Dtls has never been defined (nor in RFC 2543) and it seems to appear in RFC 3261 due to dubious reasons, but it is not used in RFC 3261. Please check http://tools.ietf.org/html/rfc5630#section-3.1.4. > if we want to use SIP URI with any other secure communication mechanism l= ike > WSS, might require > update to RFC5630. like > sec=C2=A03.1.3. > > If one wants to use "best-effort TLS/WSS" for SIP, one just needs to u= se > a SIP URI, and send the request over TLS ** or any other secure transp= ort > mechanism like WSS** > > TLS is a extra-layer on top of TCP and also on top of WebSocket. When applied on top of TCP transport it is commonly named "TLS", but it should be better to call it "TLS-TCP" (in the same way that TLS over SCTP is named "TLS-SCTP" for Via transport value in RFC 4168. >> > =C2=A0 =C2=A0Extra closing double quote in contact header. >> >> Typo, thanks :) >> > [ABN] similar typo mistake in message F3 as well. Good catch. >> The example uses a secure WS connection (on top of TLS) but does not >> use SIPS schema. >> > > [ABN] Probably for the sake of clarity, we can give call flow for Secure = Web > Socket (WSS) > and non-secure Web Socket (WS). this content is already covered in differ= ent > sections (this doc and rfc6455 as well). But putting it together with a c= all > flow would make the concept more clearer. The problem is that, trying to include a full secure call would lead to multiple mail threads discussing SIPS stuf that is really difficult to understand and implement. There is a RFC trying to improve/explain it (RFC 5630). I don't think the mission of this draft is to clarify SIPS usage. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Wed Apr 18 18:56:16 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A172E11E80AF for ; Wed, 18 Apr 2012 18:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92Iyp2ekRiCk for ; Wed, 18 Apr 2012 18:56:12 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id 4C14C11E80B1 for ; Wed, 18 Apr 2012 18:56:12 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKT49wuxwif3T28UVCGHeFChVWL2H3pqZr@postini.com; Wed, 18 Apr 2012 18:56:12 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 18 Apr 2012 21:56:45 -0400 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.0355.002; Thu, 19 Apr 2012 07:26:05 +0530 From: "Ravindran, Parthasarathi" To: Christer Holmberg , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: AQHNHSsWQiKr/IZJokCfX43Mp6RbG5agJJrA//+unYCAAGacsIAAFBwAgABihBD//7B5AIAABfgAgAD3fzA= Date: Thu, 19 Apr 2012 01:56:04 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com>, <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 01:56:16 -0000 Inaki, I agree with Christer for mandating path in case REGISTER is the first mess= age and it is not required to be mandated in case INVITE is the first message. In the mentioned below callflow, P1 should be some prior knowledge about Bo= b that Bob supports websocket transport which is not always feasible through= =20 standard mechanism. Also, the callflow is not generic enough to handle=20 SIP entity which supports UDP & TCP transport only. Thanks Partha >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Wednesday, April 18, 2012 9:47 PM >To: I=F1aki Baz Castillo; Ravindran, Parthasarathi >Cc: sipcore@ietf.org >Subject: RE: [sipcore] Stateless or Transaction stateful proxy possible >in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip- >websocket-02] > >Hi, > >In general I agree that a transport mechanism specification shouldn't >mandate entities to Record-Route. > >But, as others have also indicated, in most cases it will be needed. The >signalling path between the UA and the "outbound proxy" will be >established already during registration (which means the proxy will also >have to insert Path), and will then be used for UA originating and >terminating sessions. > >Regards, > >Christer > > > > > >________________________________________ >From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of >I=F1aki Baz Castillo [ibc@aliax.net] >Sent: Wednesday, April 18, 2012 6:55 PM >To: Ravindran, Parthasarathi >Cc: sipcore@ietf.org >Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible >in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip- >websocket-02] > >2012/4/18 Ravindran, Parthasarathi : > >> Having said that, please indicate that Websocket (to any transport) >Proxy MUST include record-route header in all SIP messages and it is a >mandatory header for websocket proxy as per this specification. It may >be preferable to provide the reason for this mandating. IMO, This >information helps websocket proxy implementers. > > >Hi Ravindran. If a proxy behaves as an Outbound Edge Proxy (RFC 5626) >then it adds Record-Route always (since NATted clients can only receive >incoming requests from their Outbound proxy via TCP, UDP, or WebSocket). > >Implementing RFC 5626 "Outbound" was a MUST in previous draft version, >but such a requirement was removed in IETF #83 after consensus by >members of this WG, so the draft does NOT mandate RFC 5626 (which IMHO >is a good decision since it "just defines a new SIP transport" rather >than a complete SIP topology). > >Anyhow, Record-Route (Loose-Routing mechanism as defined in RFC 3261) is >*NOT* required in *ALL* the cases in which a SIP WebSocket UA is >involved, for example: > > >- alice is a SIP UA implementing a SIP WS Client and a SIP WS Server (so >it can open and accept WS connections). > >- The very same for bob, another SIP WS UA. But bob also speaks UDP and >registers to P1 via UDP. > >- P1 is a proxy/registrar implementing a SIP WebSocket Server (so just >listens for inbound WS connections) and also UDP. > >- P1 does NOT perform Loose-Routing (it does NOT add Record-Route >headers). > >- alice, bob and P1 are located in the same network (or have public >IP...). > > >So: > > > > alice P1 bob > >F1 INVITE -----(WS)---------> >F2 INVITE ----(UDP)-------> > >F3 <---(UDP)----------- 200 >F4 <-----(WS)----------- 200 > >F5 ACK ---------------------(WS)----------------------> > >F6 <------------------------(WS)------------------- BYE >F7 200 ---------------------(WS)----------------------> > > >F1: INVITE from alice has a Contact URI with ;transport=3Dws. > >F2. P1 does NOT add Record-Route header. > >F3. 200 from bob contains a Contact URI with ;transport=3Dws (which is >valid regardless the INVITE arrived via UDP transport). > >F5. alice opens a new WS connection to the Contact URI of bob (since ACK >must be send end to end when there is no Record-Route in 200) and sends >the ACK. > >F7. bob opens a new WS connection to the Contact URI of alice and sends >the BYE. > > >This is perfectly valid according to RFC 3261 and there is NO need for >Loose-Routing mechanism, so the draft MUST NOT mandate Loose-Routing >mechanism. > >Again, you assume that the SIP WebSocket UA is a web browser that can >only open outbound WS connections. The draft is not based on such an >assumption (regardless we all know that this will be the scenario in 99% >of cases). We leave the SIP topology open (this was recently discussed >in this maillist before IETF #83). > > > >> Also indicates that, stateless proxy is not applicable for this >transport. > >Please read my previous replies. Stateless proxy CAN be used (please >read my first reply in this thread in which I explain it). > > > > >> I like to hear in case any other way to make SIP over websocket works >without record-route header. > >See example above. > > > >Regards. > > > > >-- >I=F1aki Baz Castillo > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From pravindran@sonusnet.com Wed Apr 18 19:47:13 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC2C11E8089 for ; Wed, 18 Apr 2012 19:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 XGmsL7vWYub6 for ; Wed, 18 Apr 2012 19:47:12 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id EF50111E8086 for ; Wed, 18 Apr 2012 19:47:11 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKT498r5bScBnFL1o5ZrAGPihOmes+MDUG@postini.com; Wed, 18 Apr 2012 19:47:12 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 18 Apr 2012 22:47:45 -0400 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.0355.002; Thu, 19 Apr 2012 08:17:05 +0530 From: "Ravindran, Parthasarathi" To: Nataraju A.B Thread-Topic: Incoming call notification for websocket transport Thread-Index: AQHNHdbJfJCzdI+KQE+2AIFAn6luHw== Date: Thu, 19 Apr 2012 02:47:05 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E228359@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C0E228359inbamail01sonus_" MIME-Version: 1.0 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: [sipcore] Incoming call notification for websocket transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 02:47:13 -0000 --_000_387F9047F55E8C42850AD6B3A7A03C6C0E228359inbamail01sonus_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Nataraju, [ABN] Partha, Can you name some scenario which need this incoming SIP requests = @ the WebSocket client ???? There are two scenario which I could think of 1) Skype sort of websocket application in endpoint 2) B2BUA which listen on websocket to receive the calls without regist= ration Thanks Partha From: Nataraju A.B [mailto:nataraju.sip@gmail.com] Sent: Wednesday, April 18, 2012 3:50 PM To: Ravindran, Parthasarathi Cc: Sa=FAl Ibarra Corretg=E9; SIPCORE (Session Initiation Protocol Core) WG= ; SIPCORE Chairs; I=F1aki Baz Castillo Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in = Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocke= t-02] On Wed, Apr 18, 2012 at 3:37 PM, Ravindran, Parthasarathi > wrote: Even if it is the limitations of websocket, SIP UA MUST listen in UDP & TCP as per RFC 3261 and not adhere to this requirement which MUST be considered as a violation of RFC 3261. In case you think that this draft does not violate any RFC 3261 for SIP UA, the Current text in the draft is = not clear enough, Please mention it explicitly in the draft that "As per this specification, SIP UA MUST support UDP, TCP transport apart from Websocket as a transport" This information helps for the implementers who wish to use this draft for RTCWeb client to SIP Interop in the standard way. I'm writing this mail as most of the folks support this draft for interworking RTCWeb client to SIP in the standard manner as per my discussion in IETF-83. I'll write the separate mail thread for discussing incoming SIP over websoc= ket as it is one another major open item in this draft. [ABN] Partha, Can you name some scenario which need this incoming SIP requests = @ the WebSocket client ???? Thanks Partha >-----Original Message----- >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] >Sent: Wednesday, April 18, 2012 3:23 PM >To: Ravindran, Parthasarathi >Cc: I=F1aki Baz Castillo; SIPCORE (Session Initiation Protocol Core) WG; >SIPCORE Chairs; Nataraju A.B >Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible >in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip- >websocket-02] > > >On Apr 18, 2012, at 11:35 AM, Ravindran, Parthasarathi wrote: > >> As per your below statement, JavaScript with SIP and RTCWeb Browser >MUST NOT use this draft as it violates RFC 3261. >> > >It doesn't, see my previous email explaining why. > >> Also in IETF-83 SIPCore meeting, I noticed that SIP UA over websocket >will not listen for the incoming call without registration but in case >of your draft is written with SIP softphone (smartphone) in mind , it is >possible to listen in Port 80 or any other Websocket port which is not >addressed in this draft till now. We need to discuss and sort it out. >> > >The fact that a JS SIP client (running in a web browser) does not listen >for incoming connections is a limitation imposed by the WebSocket API, >not by this draft. This specification defines 2 entities: a SIP >WebSocket Client and a SIP WebSocket Server, so nobody stops you from >creating an entity that implements both and can accept incoming >WebSocket connections. Of course, such an application would not run in a >browser. > > >Regards, > >-- >Sa=FAl Ibarra Corretg=E9 >AG Projects > > -- Thanks, Nataraju A.B. --_000_387F9047F55E8C42850AD6B3A7A03C6C0E228359inbamail01sonus_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Nataraju,

 

[ABN] Partha, 

          Can you name some= scenario which need this incoming SIP requests @ the WebSocket client ????=  

 <= /p>

There are two scenario wh= ich I could think of

 <= /p>

1) = ;     Skype sort of web= socket application in endpoint

2) = ;     B2BUA which liste= n on websocket to receive the calls without registration<= /p>

 <= /p>

Thanks<= /p>

Partha<= /p>

 <= /p>

From: Nataraju= A.B [mailto:nataraju.sip@gmail.com]
Sent: Wednesday, April 18, 2012 3:50 PM
To: Ravindran, Parthasarathi
Cc: Sa=FAl Ibarra Corretg=E9; SIPCORE (Session Initiation Protocol C= ore) WG; SIPCORE Chairs; I=F1aki Baz Castillo
Subject: Re: [sipcore] Stateless or Transaction stateful proxy possi= ble in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-w= ebsocket-02]

 

 

On Wed, Apr 18, 2012 at 3:37 PM, Ravindran, Parthasa= rathi <pravindran@sonusnet.co= m> wrote:

Even if it is the limitations of websocket, SIP UA M= UST listen in
UDP & TCP as per RFC 3261 and not adhere to this requirement which MUST=
be considered as a violation of RFC 3261. In case you think that this draft=
does not violate any RFC 3261 for SIP UA, the Current text in the draft is = not
clear enough, Please mention it explicitly in the draft that

"As per this specification, SIP UA MUST support UDP, TCP transport apa= rt
from Websocket as a transport"

This information helps for the implementers who wish to use this draft for<= br> RTCWeb client to SIP Interop in the standard way. I'm writing this mail as<= br> most of the folks support this draft for interworking RTCWeb client to SIP<= br> in the standard manner as per my discussion in IETF-83.

I'll write the separate mail thread for discussing incoming SIP over websoc= ket
as it is one another major open item in this draft.

[ABN] Partha, 

          Can you name some= scenario which need this incoming SIP requests @ the WebSocket client ????=  


Thanks
Partha


>-----Original Message-----
>From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com]
>Sent: Wednesday, April 18, 2012 3:23 PM
>To: Ravindran, Parthasarathi

>Cc: I=F1aki Baz Castillo; SIPCORE (Session Initi= ation Protocol Core) WG;
>SIPCORE Chairs; Nataraju A.B
>Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible=
>in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-<= br> >websocket-02]
>
>

>On Apr 18, 2012, = at 11:35 AM, Ravindran, Parthasarathi wrote:
>
>> As per your below statement, JavaScript with SIP and RTCWeb Browse= r
>MUST NOT use this draft as it violates RFC 3261.
>>
>
>It doesn't, see my previous email explaining why.
>
>> Also in IETF-83 SIPCore meeting, I noticed that SIP UA over websoc= ket
>will not listen for the incoming call without registration but in case<= br> >of your draft is written with SIP softphone (smartphone) in mind , it i= s
>possible to listen in Port 80 or any other Websocket port which is not<= br> >addressed in this draft till now. We need to discuss and sort it out. >>
>
>The fact that a JS SIP client (running in a web browser) does not liste= n
>for incoming connections is a limitation imposed by the WebSocket API,<= br> >not by this draft. This specification defines 2 entities: a SIP
>WebSocket Client and a SIP WebSocket Server, so nobody stops you from >creating an entity that implements both and can accept incoming
>WebSocket connections. Of course, such an application would not run in = a
>browser.
>
>
>Regards,
>
>--
>Sa=FAl Ibarra Corretg=E9
>AG Projects
>
>



 

--
Thanks,

Nataraju A.B.

 

--_000_387F9047F55E8C42850AD6B3A7A03C6C0E228359inbamail01sonus_-- From dworley@avaya.com Wed Apr 18 20:44:21 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DAEF11E8089 for ; Wed, 18 Apr 2012 20:44:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.951 X-Spam-Level: X-Spam-Status: No, score=-102.951 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, 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 M723mlPyZSJ5 for ; Wed, 18 Apr 2012 20:44:20 -0700 (PDT) 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 085E111E8075 for ; Wed, 18 Apr 2012 20:44:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAD6Jj0/GmAcF/2dsb2JhbABDsUaBB4IQEihRARUpQicEGxqHbZkbhBqdPo9SYwScBIolgwOBOAY X-IronPort-AV: E=Sophos;i="4.75,445,1330923600"; d="scan'208";a="343153164" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Apr 2012 23:43:59 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 18 Apr 2012 23:42:08 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Wed, 18 Apr 2012 23:44:17 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Wed, 18 Apr 2012 23:43:17 -0400 Thread-Topic: Comments on draft-ietf-sipcore-rfc4244bis-07.txt, sections 6-9, 10.2, 10.3 Thread-Index: AQHNHd6ymDjyWdS950GG2I9oW6I7hw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-07.txt, sections 6-9, 10.2, 10.3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 03:44:21 -0000 NOTE: In my comments on sections 1-5, I was unaware of the (somewhat new) use of "0" to indicate a gap, so I incorrectly referred to "positive integer" instead of "nonnegative integer". NOTE: Should we add somewhere prominent toward the beginning: The hi-entries in the History-Info header field are always given in the preorder of their logical tree structure, which is the lexicographic ordering of their hi-indexes. This makes it clear that the ordering is always the same and avoids specifying the ordering in multiple places (as if it was somehow a special feature of certain steps of processing). 5. History-Info Header Field Protocol Structure index-val =3D 1*DIGIT *("." 1*DIGIT) Have we ever settled whether we allow leading zeros? Perhaps we should forbid leading zeros (except for "0"): index-val =3D number *("." number) number =3D [ %31-39 *DIGIT ] DIGIT And there probably should be a reference to 5234 Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed., P. Overell. January 2008. (Format: TXT=3D26359 bytes) (Obsoletes RFC4234) (Also STD0068) (Status: STANDARD) 6.1. User Agent Client (UAC) Behavior In the case of an initial request, except where the UAC is part of a B2BUA, there is no cache of hi- entries with which to populate the History-info header field and the hi-index is set to 1 per Section 10.3. I don't know if it needs to be stated or not, but there are a couple of cases where a UAC can generate requests with hi-entries whose hi-indexes start with 2 or a higher number: - the UAC acts on a 3xx response it has received, thus generating a request that is a sibling of the initial request - the UAC for some reason is generating a set of requests that are intended to be "forks" of an implicit original request=20 (This happens in draft-ietf-bliss-call-completion.) (An alternative would be for the UAC to use internal retargeting and label the forks 1.1, 1.2, etc. But that is more verbose.) I think that the first point is implicit in the description of 3xx response processing, but that the second point is probably not implied. This could be handled by adding the sentence: If the UAC generates further forks of the initial request (either due to acting on a 3xx response or internally-directed forking to multiple destinations), the successive requests will add hi-entries with hi-indexes of 2, 3, etc. 6.2. User Agent Server (UAS) Behavior When receiving a request, a UAS MUST follow the procedures defined in Section 9.2. Do you mean "Section 9.1", which is the one titled "Receiving a Request"? UAS MUST follows the procedures as defined in Section 9.4. When should be UAS MUST >>>follow<<< the >>>procedures in<<< Section 9.4. When 7. Proxy/Intermediary Handling of History-Info Header Fields Figure 1 provides an example of internal retargeting. I think this statement is incorrect -- the only figure 1 is in section 5.1, and does not show internal retargeting. I suspect this statement is left over from an earlier version. 9.2. Sending a Request with History-Info In addition, the SIP entity MUST add a new hi-entry to the outgoing request, but the SIP entity MUST NOT add the hi-entry to the outgoing request(but not the cache) populating the new hi-entry to the cache at this time. This sentence clearly has been damaged during editing. I think it should be In addition, the SIP entity MUST add a new hi-entry to the outgoing request, but the SIP entity MUST NOT add the hi-entry to the cache at this time. At this point, we need to specify the ordering of the hi-entries in the outgoing History-Info, since the ordering of the hi-entries in the cache isn't specified: The hi-entries in the outgoing request's History-Info header field is the preorder of the tree of hi-entries, that is, by the lexicographic ordering of the hi-indexes. This needs to be updated to add "np": rc/mp>>>/np<<<: The SIP entity MUST include an "rc", "mp" or "np" heade= r field parameter in the hi-entry, if applicable, per the procedures in Section 10.4. 9.4. Sending History-Info in Responses When sending a response other than a 100, a SIP entity MUST include all the cached hi-entries in the response, subject to the privacy consideration in Section 10.1.2 with the following exception: If the received request contained no hi-entries and there is no "histinfo" option tag in the Supported header field, the SIP entity MUST NOT include hi-entries in the response. I think this can be clarified by When sending a response other than a 100, a SIP entity MUST include all the cached hi-entries in the response, subject to the privacy consideration in Section 10.1.2>>>, and<<< with the following exception: If the received request contained no hi-entries and there is no "histinfo" option tag in the Supported header field, the SIP entity MUST NOT include >>>History-Info<<< in the response. 10.2. Reason in the History-info Header Field If a request has timed out (instead of being explicitly rejected), the SIP entity MUST include a Reason header field, containing a SIP error response code of 408 "Request Timeout". More exact would be to say If a request has timed out (instead of being explicitly rejected), the SIP entity MUST update the cache as if the request received a=20 SIP error response code of 408 "Request Timeout". That allows tel: URIs to be handled correctly, i.e., not receiving a Reason header. There needs to be some discussion of the fact that a request can receive multiple "non-100 non-2xx" responses, and that their Reason headers can have duplicate or non-duplicate reason-values. That could be done by adding at this point in 10.2 this paragraph: A request can receive multiple non-100 non-2xx responses which carry or imply (for responses without Reason headers, and for timeouts) multiple, possibly duplicated, reason-values to be applied to a non-tel hi-targeted-to-uri. In these situations, the SIP entity must accumulate without duplications all the distinct reason-values in the received or implied Reason header fields. ... or whatever rule we want to adopt. 10.3. Indexing in the History-Info Header Field Per the syntax in Section 5, the hi-index consists of a series of digits separated by dots (e.g., 1.1.2). As far as I can tell, "digit" should be replaced with "nonnegative integer" (or perhaps just "integer", since the BNF enforces nonnegativeness) everywhere in the document. The highest digit at each hop reflects the number of entities to which the request has been retargeted at the specific hop (i.e., the number of branches). This should be expanded by adding "at the time that the request represented by this hi-entry was generated", since the "number of entities to which..." changes over time, but of course, the integer in the sent request cannot. Thus, the indexing results in a logical tree representation for the history of the request. I think it would be useful to add "and the hi-entries are given in the preorder of the tree". In the case that a SIP entity (intermediary or UAS) adds an hi-entry on behalf of the previous hop, the hi-index MUST be set to 1. I'm not certain of the meaning of this, but I think it's incorrect as written. At the least, if the intermediary adds an additional hi-entry to an existing History-Info, then it has to follow the "0.1" rule. If a first-hop proxy adds History-Info on behalf of a UAC, then it can use index 1 for the initial hi-entry. If a non-first-hop proxy adds History-Info on behalf of the upstream entities, the situation is messier. In principle, it should probably apply the "0.1" rule, so the first hi-entry does not have index "1". However, in that case, the intermediary probably won't be sending History-Info upstream in the response, so there is no way that the upstream entities can get confused by receiving multiple replies with different History-Info trees that use the same root index (1). (Actually, a UAC that acts on 3xx or initially forks can cause the first-hop proxy to be in the same situation as a non-first-hop proxy. But the same analysis shows that always using an initial index of 1 won't confuse the UAC.) So I think the statement should be In the case that a SIP entity (intermediary or UAS) adds >>>a first<<< hi-entry on behalf of the previous hop, the hi-index MUST be set to 1. For each forward hop (i.e., each new level of indexing), the hi-index MUST start at 1. An increment of 1 MUST be used for advancing to a new branch. Actually, that should be "the last integers of the hi-indexes of the new requests MUST be generated starting at 1 and incrementing by 1 for each additional request". The hi-indexes *themselves* don't start at 1. Note, that in the case of parallel forking, only the hi-entry corresponding to the fork is included in the request. It might be useful to add "because no response can yet have been received for any of the parallel forked requests" -- that may not be obvious to the first-time reader. 6. Missing entity: If the request clearly has a gap in the hi-entry (e.g. by evaluating via header to the existing request history to see if it traversed a domain which doesn't exist in History-Info header field.), the entity adding an hi-entry MUST add an index a digit of "0" to the current index prior to adding appropriate index for the action to be taken. If the index of the last hi- entry in the request received was 1.1.2 and there was a missing hi-entry and the request was being forwarded to the next hop, the resulting index will be 1.1.2.0.1. This rule doesn't really belong here. Properly, it describes an additional condition that triggers the adding of an hi-entry described in section 9.1. It's also not clear to me that this trigger condition can be specified sufficiently accurately to allow this to become a MUST. If we are relaxed about this, the revision would be to delete this item 6 and update section 9.1: The entity MUST attempt, in the following manner, to determine if the previous SIP entity that sent the request did not add a hi-entry to the History-Info header field: 1. It MUST detect if the Request-URI of the incoming request does not match the hi-targeted-to-uri in the last hi-entry. 2. It MAY detect the condition via other means, for example,=20 if the topmost Via header shows traversing a domain which is different from the last hi-entry, or if the request was received from an address to which the last hi-targeted-to-uri could not have addressed the request. (I expect that border devices may often be able to apply the latter conditi= on.) When this condition is detected, the SIP entity MUST add a hi-entry to end of the cache, on behalf of the previous SIP entity, as follows: Dale From shida@ntt-at.com Wed Apr 18 23:28:18 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C974A21F852C for ; Wed, 18 Apr 2012 23:28:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.032 X-Spam-Level: X-Spam-Status: No, score=-102.032 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 IKSx39gydF0X for ; Wed, 18 Apr 2012 23:28:18 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 43E6F21F8527 for ; Wed, 18 Apr 2012 23:28:17 -0700 (PDT) Received: from [60.236.86.9] (port=57963 helo=[192.168.1.20]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SKkql-00048A-T8; Thu, 19 Apr 2012 01:28:16 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Thu, 19 Apr 2012 15:28:13 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: , <8A41EEBD-DE37-4E5A-9B01-41F1F0C46380@ntt-at.com> To: "Worley, Dale R (Dale)" X-Mailer: Apple Mail (2.1257) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: flh1adm009.tky.mesh.ad.jp ([192.168.1.20]) [60.236.86.9]:57963 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-07, sections 1 to 5 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 06:28:18 -0000 Dale; Thanks for the suggestion and the catch. Regards Shida On Apr 19, 2012, at 12:48 AM, Worley, Dale R (Dale) wrote: >> From: Shida Schubert [shida@ntt-at.com] >> >>> "np": The hi-targeted-to-URI represents that there was no >>> change in Request-URI. This would apply for example when a >>> proxy merely forwards a request to a next hop proxy and loose >>> routing is used. >>> >>> Unlike the previous two cases, this case does not describe the >>> function of the value of the np parameter. >> >> Any suggestion for rewording? > > Assuming that the values of the three parameters are intended to carry > the same information (that is, the index of the hi-entry from which > this request-URI was derived), the value of "np" would be the index of > the parent hi-entry of this hi-entry. As in the example in 5.1: > > | History-Info: ;index=1 > | History-Info: ;np=1;index=1.1 > > Largely copying the wording of the entry for "rc", we can add: > > "np": The hi-targeted-to-URI represents that there was no > change in Request-URI. This would apply for example when a > proxy merely forwards a request to a next hop proxy and loose > routing is used. >>>> The "np" > header field parameter contains the value of the hi-index in > the hi-entry with an hi-targeted-to-uri that reflects the > Request-URI that was copied unchanged into the request > represented by this hi-entry. That value will usually be the > hi-index of the parent hi-entry of this hi-entry.<<< > > While I was lookng at this, the entry for "mp" has some awkward > wording that could be improved by copying the wording from "rc". > Instead of > > The "mp" header field parameter contains the >>>> value which represents the value<<< of the hi-index in the > hi-entry ... > > perhaps > > The "mp" > header field parameter contains the >>>value<<< of the hi-index in > the hi-entry ... > > Dale From shida@ntt-at.com Thu Apr 19 03:44:29 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4598021F85D3 for ; Thu, 19 Apr 2012 03:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.791 X-Spam-Level: X-Spam-Status: No, score=-101.791 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_73=0.6, 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 H+cO-u0VgK3f for ; Thu, 19 Apr 2012 03:44:25 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 38C4F21F85B9 for ; Thu, 19 Apr 2012 03:44:25 -0700 (PDT) Received: from [60.236.86.9] (port=65532 helo=[192.168.1.20]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SKoqd-0001xD-Qy; Thu, 19 Apr 2012 05:44:24 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Thu, 19 Apr 2012 19:44:21 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Worley, Dale R (Dale)" X-Mailer: Apple Mail (2.1257) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: flh1adm009.tky.mesh.ad.jp ([192.168.1.20]) [60.236.86.9]:65532 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-07.txt, sections 6-9, 10.2, 10.3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 10:44:29 -0000 Hi Dale; Thanks again for your extensive review. My comments inline. On Apr 19, 2012, at 12:43 PM, Worley, Dale R (Dale) wrote: > NOTE: In my comments on sections 1-5, I was unaware of the (somewhat > new) use of "0" to indicate a gap, so I incorrectly referred to > "positive integer" instead of "nonnegative integer". >=20 > NOTE: Should we add somewhere prominent toward the beginning: >=20 > The hi-entries in the History-Info header field are always given in > the preorder of their logical tree structure, which is the > lexicographic ordering of their hi-indexes. >=20 > This makes it clear that the ordering is always the same and avoids > specifying the ordering in multiple places (as if it was somehow a > special feature of certain steps of processing). I thought the description of hi-index was sufficient but if you don't=20= think so, we can add this. Where do you recommend we add this?=20 In the Introduction??=20 >=20 >=20 > 5. History-Info Header Field Protocol Structure >=20 > index-val =3D 1*DIGIT *("." 1*DIGIT) >=20 > Have we ever settled whether we allow leading zeros? Perhaps we > should forbid leading zeros (except for "0"): >=20 > index-val =3D number *("." number) >=20 > number =3D [ %31-39 *DIGIT ] DIGIT >=20 > And there probably should be a reference to >=20 > 5234 Augmented BNF for Syntax Specifications: ABNF. D. Crocker, = Ed., > P. Overell. January 2008. (Format: TXT=3D26359 bytes) = (Obsoletes > RFC4234) (Also STD0068) (Status: STANDARD) DONE. >=20 > 6.1. User Agent Client (UAC) Behavior >=20 > In the case of an initial request, except > where the UAC is part of a B2BUA, there is no cache of hi- entries > with which to populate the History-info header field and the = hi-index > is set to 1 per Section 10.3. >=20 > I don't know if it needs to be stated or not, but there are a couple > of cases where a UAC can generate requests with hi-entries whose > hi-indexes start with 2 or a higher number: >=20 > - the UAC acts on a 3xx response it has received, thus generating a > request that is a sibling of the initial request >=20 > - the UAC for some reason is generating a set of requests that are > intended to be "forks" of an implicit original request=20 > (This happens in draft-ietf-bliss-call-completion.) > (An alternative would be for the UAC to use internal retargeting and > label the forks 1.1, 1.2, etc. But that is more verbose.) >=20 > I think that the first point is implicit in the description of 3xx > response processing, but that the second point is probably not > implied. >=20 > This could be handled by adding the sentence: >=20 > If the UAC generates further forks of the initial request (either > due to acting on a 3xx response or internally-directed forking to > multiple destinations), the successive requests will add hi-entries > with hi-indexes of 2, 3, etc. DONE. >=20 > 6.2. User Agent Server (UAS) Behavior >=20 > When receiving a request, a UAS MUST follow the procedures defined = in > Section 9.2. >=20 > Do you mean "Section 9.1", which is the one titled "Receiving a > Request"? That is the intent. >=20 > UAS MUST follows the procedures as defined in Section 9.4. When >=20 > should be >=20 > UAS MUST >>>follow<<< the >>>procedures in<<< Section 9.4. When DONE. >=20 > 7. Proxy/Intermediary Handling of History-Info Header Fields >=20 > Figure 1 provides an example of internal retargeting. >=20 > I think this statement is incorrect -- the only figure 1 is in section > 5.1, and does not show internal retargeting. I suspect this statement > is left over from an earlier version. REMOVED. >=20 > 9.2. Sending a Request with History-Info >=20 > In addition, the SIP entity MUST add a new > hi-entry to the outgoing request, but the SIP entity MUST NOT add = the > hi-entry to the outgoing request(but not the cache) populating the > new hi-entry to the cache at this time. >=20 > This sentence clearly has been damaged during editing. I think it > should be >=20 > In addition, the SIP entity MUST add a new hi-entry to the outgoing > request, but the SIP entity MUST NOT add the hi-entry to the cache > at this time. FIXED. >=20 > At this point, we need to specify the ordering of the hi-entries in > the outgoing History-Info, since the ordering of the hi-entries in the > cache isn't specified: >=20 > The hi-entries in the outgoing request's History-Info header field > is the preorder of the tree of hi-entries, that is, by the > lexicographic ordering of the hi-indexes. DONE. >=20 > This needs to be updated to add "np": >=20 > rc/mp>>>/np<<<: The SIP entity MUST include an "rc", "mp" or "np" = header > field parameter in the hi-entry, if applicable, per the = procedures > in Section 10.4. DONE. >=20 > 9.4. Sending History-Info in Responses >=20 > When sending a response other than a 100, a SIP entity MUST include > all the cached hi-entries in the response, subject to the privacy > consideration in Section 10.1.2 with the following exception: If the > received request contained no hi-entries and there is no "histinfo" > option tag in the Supported header field, the SIP entity MUST NOT > include hi-entries in the response. >=20 > I think this can be clarified by >=20 > When sending a response other than a 100, a SIP entity MUST include > all the cached hi-entries in the response, subject to the privacy > consideration in Section 10.1.2>>>, and<<< with the following > exception: If the > received request contained no hi-entries and there is no "histinfo" > option tag in the Supported header field, the SIP entity MUST NOT > include >>>History-Info<<< in the response. FIXED. >=20 > 10.2. Reason in the History-info Header Field >=20 > If a request has timed out (instead of being explicitly rejected), > the SIP entity MUST include a Reason header field, containing a SIP > error response code of 408 "Request Timeout". >=20 > More exact would be to say >=20 > If a request has timed out (instead of being explicitly rejected), > the SIP entity MUST update the cache as if the request received a=20 > SIP error response code of 408 "Request Timeout". FIXED. >=20 > That allows tel: URIs to be handled correctly, i.e., not receiving a > Reason header. >=20 > There needs to be some discussion of the fact that a request can > receive multiple "non-100 non-2xx" responses, and that their Reason > headers can have duplicate or non-duplicate reason-values. That could > be done by adding at this point in 10.2 this paragraph: >=20 > A request can receive multiple non-100 non-2xx responses which > carry or imply (for responses without Reason headers, and for > timeouts) multiple, possibly duplicated, reason-values to be > applied to a non-tel hi-targeted-to-uri. In these situations, the > SIP entity must accumulate without duplications all the distinct > reason-values in the received or implied Reason header fields. >=20 > ... or whatever rule we want to adopt. Added this with some modified text.=20 >=20 > 10.3. Indexing in the History-Info Header Field >=20 > Per the syntax in Section 5, the hi-index consists of a series of > digits separated by dots (e.g., 1.1.2). >=20 > As far as I can tell, "digit" should be replaced with "nonnegative > integer" (or perhaps just "integer", since the BNF enforces > nonnegativeness) everywhere in the document. FIXED. >=20 > The highest digit at each > hop reflects the number of entities to which the request has been > retargeted at the specific hop (i.e., the number of branches). >=20 > This should be expanded by adding "at the time that the request > represented by this hi-entry was generated", since the "number of > entities to which..." changes over time, but of course, the integer in > the sent request cannot. >=20 > Thus, > the indexing results in a logical tree representation for the = history > of the request. >=20 > I think it would be useful to add "and the hi-entries are given in the > preorder of the tree". FIXED. >=20 > In the case that a SIP entity (intermediary or UAS) adds an hi-entry > on behalf of the previous hop, the hi-index MUST be set to 1. >=20 > I'm not certain of the meaning of this, but I think it's incorrect as > written. At the least, if the intermediary adds an additional > hi-entry to an existing History-Info, then it has to follow the "0.1" > rule. >=20 > If a first-hop proxy adds History-Info on behalf of a UAC, then it can > use index 1 for the initial hi-entry. >=20 > If a non-first-hop proxy adds History-Info on behalf of the upstream > entities, the situation is messier. In principle, it should probably > apply the "0.1" rule, so the first hi-entry does not have index "1". >=20 > However, in that case, the intermediary probably won't be sending > History-Info upstream in the response, so there is no way that the > upstream entities can get confused by receiving multiple replies with > different History-Info trees that use the same root index (1). >=20 > (Actually, a UAC that acts on 3xx or initially forks can cause the > first-hop proxy to be in the same situation as a non-first-hop proxy. > But the same analysis shows that always using an initial index of 1 > won't confuse the UAC.) >=20 > So I think the statement should be >=20 > In the case that a SIP entity (intermediary or UAS) adds >>>a > first<<< hi-entry on behalf of the previous hop, the hi-index MUST > be set to 1. >=20 FIXED. > For > each forward hop (i.e., each new level of indexing), the hi-index > MUST start at 1. An increment of 1 MUST be used for advancing to a > new branch. >=20 > Actually, that should be "the last integers of the hi-indexes of the > new requests MUST be generated starting at 1 and incrementing by 1 for > each additional request". The hi-indexes *themselves* don't start at > 1. FIXED. >=20 > Note, that in the case of parallel forking, > only the hi-entry corresponding to the fork is included in the > request. >=20 > It might be useful to add "because no response can yet have been > received for any of the parallel forked requests" -- that may not be > obvious to the first-time reader. FIXED. >=20 > 6. Missing entity: If the request clearly has a gap in the hi-entry > (e.g. by evaluating via header to the existing request history = to > see if it traversed a domain which doesn't exist in History-Info > header field.), the entity adding an hi-entry MUST add an index = a > digit of "0" to the current index prior to adding appropriate > index for the action to be taken. If the index of the last hi- > entry in the request received was 1.1.2 and there was a missing > hi-entry and the request was being forwarded to the next hop, = the > resulting index will be 1.1.2.0.1. >=20 > This rule doesn't really belong here. Properly, it describes an > additional condition that triggers the adding of an hi-entry described > in section 9.1. Section 9.1 already describes the condition as to when it=20 adds hi-entry.=20 " If the Request-URI of the incoming request does not match the hi- targeted-to-uri in the last hi-entry (i.e., the previous SIP entity that sent the request did not include a History-Info header field), the SIP entity MUST add a hi-entry to end of the cache, on behalf of the previous SIP entity"=20 Above is strictly talking about condition when "0" is to be used for=20 index.=20 The fact that last hi-entry and R-URI doesn't match is a rule for=20 adding an hi-entry there is no additional rule for adding an=20 hi-entry on behalf of the previous hop.=20 >=20 > It's also not clear to me that this trigger condition can be specified > sufficiently accurately to allow this to become a MUST. If we are > relaxed about this, the revision would be to delete this item 6 and > update section 9.1: We can change it to SHOULD. =20 Regards Shida >=20 > The entity MUST attempt, in the following manner, to determine if = the > previous SIP entity that sent the request did not add a hi-entry to > the History-Info header field: >=20 > 1. It MUST detect if the Request-URI of the incoming request does > not match the hi-targeted-to-uri in the last hi-entry. >=20 > 2. It MAY detect the condition via other means, for example,=20 > if the topmost Via header shows traversing a domain which is > different from the last hi-entry, or if the request was received > from an address to which the last hi-targeted-to-uri could not have > addressed the request. >=20 > (I expect that border devices may often be able to apply the latter = condition.) >=20 > When this condition is detected, the SIP entity MUST add a hi-entry > to end of the cache, on behalf of the previous SIP entity, as > follows: >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nataraju.sip@gmail.com Thu Apr 19 07:22:31 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC58B21F84A6 for ; Thu, 19 Apr 2012 07:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.418 X-Spam-Level: X-Spam-Status: No, score=-1.418 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 R7ME8eALYuok for ; Thu, 19 Apr 2012 07:22:27 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id D2FE221F84FF for ; Thu, 19 Apr 2012 07:22:26 -0700 (PDT) Received: by lagj5 with SMTP id j5so7147814lag.31 for ; Thu, 19 Apr 2012 07:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tTh5PdYWXwKNrJSlU6HuLnhPeqQGspmI6BQ1TgywRwc=; b=pu5ldGFKih0MjgE+g238ttAkyUsiZE20plBs4WN7wi0W+MP4BFxz+/kEY4f9RrpZLu C3TPBuWdTf4OC8PjwwOakPg0SXDzxenM9aL5gjFC6F9jTmateofkLQJ6gLh/lhf9WYVT 7YjyiCgNgyEcVGT9hovVzRIy1Hs6ENoMLBsgqUVaTtywk5AR8BHjCHincG6TlRKcK+FQ bKKc8WPqzgf4CE0vxWDNCu/I+5Y9MEhaWvsBWr0wmMufRlbyG1puyyXqBR5tAVtV8Q+D i8klSovg8AFsL72t7f2qahMpWN98RXrYvqkwQawY+MKs/zi2chH2gue14VoFLu/xwPls I+lA== MIME-Version: 1.0 Received: by 10.112.101.162 with SMTP id fh2mr1114940lbb.20.1334845345804; Thu, 19 Apr 2012 07:22:25 -0700 (PDT) Received: by 10.112.23.163 with HTTP; Thu, 19 Apr 2012 07:22:25 -0700 (PDT) In-Reply-To: <4F8EF2C9.4030507@alum.mit.edu> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <4F8EF2C9.4030507@alum.mit.edu> Date: Thu, 19 Apr 2012 19:52:25 +0530 Message-ID: From: "Nataraju A.B" To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d04016a77aab15004be08e66a Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , sipcore@ietf.org Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 14:22:31 -0000 --f46d04016a77aab15004be08e66a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Apr 18, 2012 at 10:28 PM, Paul Kyzivat wrote= : > I=F1aki, > > I agree that there is nothing in this draft that requires someone > implementing it to violate 3261. > > However, as you mention below, a typical use case for this draft is > javascript sip stacks running in a browser that would not be able to > implement sip tcp and udp transports. AFAIK those would indeed be > non-compliant to 3261. If we want to encourage such implementations, then > we should do something so that they can be compliant. ISTM that this will > require a revision to 3261. That could be done in a separate draft, or it > could be done in this draft that is already revising 3261. > > One disadvantage to doing it in this draft is that then compliance to the > revised language would be advertised by advertising support for *this* > document. If the relaxation is to apply to other implementations of sip > that don't want to implement the websocket transport, then it should be > done separately. > [ABN] I agree, it is better to address these issues in a new draft to specify the deviations from 3261 due to web socket transport support. At least there should be a statement in this doc/draft mentioning the deviation from 3261 like, 5.4. Deviations from RFC 3261 These deviations shall be conditional, non support for UDP / TCP acceptable only when WebSocket transport or equivalent one is supported. In no other cases this relaxation applicable. > Thanks, > Paul > > > On 4/18/12 12:13 PM, I=F1aki Baz Castillo wrote: > >> 2012/4/18 Paul Kyzivat**: >> >>> I think we can find a way to achieve those objectives while loosening t= he >>> requirements to support the sorts of constrained implementation >>> environments >>> we are seeing. >>> >>> Both the websocket transport and outbound rely upon a neighboring sip >>> element to bridge the gap to interoperability. So rather than >>> implementing >>> UDP and TCP itself, the websocket client depends upon the websocket >>> server >>> to implement them on its behalf. >>> >>> I think it will take a bit work to craft new language that provides the >>> needed additional flexibility while not giving license to create >>> implementations that lack basic interoperability. >>> >> >> Hi Paul, the scenario is similar to the one in which a SIP UA behind >> NAT registers using UDP through its Outbound Edge Proxy, so it can >> only receive incoming requests (from outside its local network) via >> its Outbound proxy. Neither it can receive inbound TCP connections. >> >> So, perhaps we could extract some related text from RFC 5626? But note >> that mandating RFC 5626 was removes in Paris due the got consensus. >> >> >> However, this discussion assumes that the SIP UA is a SIP WebSocket >> Client just capable of using WebSocket transport (so probably a web >> browser), and that the SIP WebSocket Server is a SIP proxy which >> cannot open outbound WS connections (and speaks other transports). >> This assumption does not exist in the draft. If a UA or a proxy >> implements both a SIP WebSocket Client and a SIP WebSocket Server then >> all this discussion becomes "invalid" since topology constrains are >> relaxed. >> >> So: >> >> - This draft does not assume network topology. >> - This draft does not assume clients and proxies/servers nature. >> - RFC 3261 mandates UDP and TCP. >> >> >> JavaScripts SIP stacks running in browsers will not implement SIP UDP/TC= P. >> Are those SIP stacks "violating" RFC 3261? well, things change since >> 2002, and probably a SIP transport like WebSocket was not expected >> when RFC 3261 was written. But anyhow, from the point of view of the >> draft itself, IMHO the spec is not violating RFC 3261 since it does >> not assume the "web browser" scenario. >> >> >> Best regards. >> >> >> > ______________________________**_________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/**listinfo/sipcore > --=20 Thanks, Nataraju A.B. --f46d04016a77aab15004be08e66a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 18, 2012 at 10:28 PM, Paul K= yzivat <pkyzi= vat@alum.mit.edu> wrote:
I=F1aki,

I agree that there is nothing in this draft that requires someone implement= ing it to violate 3261.

However, as you mention below, a typical use case for this draft is javascr= ipt sip stacks running in a browser that would not be able to implement sip= tcp and udp transports. AFAIK those would indeed be non-compliant to 3261.= If we want to encourage such implementations, then we should do something = so that they can be compliant. ISTM that this will require a revision to 32= 61. That could be done in a separate draft, or it could be done in this dra= ft that is already revising 3261.

One disadvantage to doing it in this draft is that then compliance to the r= evised language would be advertised by advertising support for *this* docum= ent. If the relaxation is to apply to other implementations of sip that don= 't want to implement the websocket transport, then it should be done se= parately.

=A0 =A0[ABN] I agree, it is better to address these= issues in a new draft to specify the deviations from 3261 due to=A0web soc= ket=A0transport support.=A0At least=A0there should be a statement in this d= oc/draft mentioning the deviation from 3261 like,
   5.4.  Deviations fr=
om RFC 3261
=A0 =A0These deviations shall be conditional, non= support for UDP / TCP acceptable only when WebSocket transport or equivale= nt one is supported. In no other cases this relaxation applicable.


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


On 4/18/12 12:13 PM, I=F1aki Baz Castillo wrote:
2012/4/18 Paul Kyzivat<pkyzivat@alum.mit.edu>:
I think we can find a way to achieve those objectives while loosening the requirements to support the sorts of constrained implementation environment= s
we are seeing.

Both the websocket transport and outbound rely upon a neighboring sip
element to bridge the gap to interoperability. So rather than implementing<= br> UDP and TCP itself, the websocket client depends upon the websocket server<= br> to implement them on its behalf.

I think it will take a bit work to craft new language that provides the
needed additional flexibility while not giving license to create
implementations that lack basic interoperability.

Hi Paul, the scenario is similar to the one in which a SIP UA behind
NAT registers using UDP through its Outbound Edge Proxy, so it can
only receive incoming requests (from outside its local network) via
its Outbound proxy. Neither it can receive inbound TCP connections.

So, perhaps we could extract some related text from RFC 5626? But note
that mandating RFC 5626 was removes in Paris due the got consensus.


However, this discussion assumes that the SIP UA is a SIP WebSocket
Client just capable of using WebSocket transport (so probably a web
browser), and that the SIP WebSocket Server is a SIP proxy which
cannot open outbound WS connections (and speaks other transports).
This assumption does not exist in the draft. If a UA or a proxy
implements both a SIP WebSocket Client and a SIP WebSocket Server then
all this discussion becomes "invalid" since topology constrains a= re
relaxed.

So:

- This draft does not assume network topology.
- This draft does not assume clients and proxies/servers nature.
- RFC 3261 mandates UDP and TCP.


JavaScripts SIP stacks running in browsers will not implement SIP UDP/TCP.<= br> Are those SIP stacks "violating" RFC 3261? well, things change si= nce
2002, and probably a SIP transport like WebSocket was not expected
when RFC 3261 was written. But anyhow, from the point of view of the
draft itself, IMHO the spec is not violating RFC 3261 since it does
not assume the "web browser" scenario.


Best regards.



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



--
= Thanks,
Nataraju A.B.

--f46d04016a77aab15004be08e66a-- From nataraju.sip@gmail.com Thu Apr 19 07:34:09 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C5B21F863E for ; Thu, 19 Apr 2012 07:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.767 X-Spam-Level: X-Spam-Status: No, score=-1.767 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, 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 Y5152cW38p0Z for ; Thu, 19 Apr 2012 07:34:05 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9941121F84C5 for ; Thu, 19 Apr 2012 07:34:04 -0700 (PDT) Received: by lbgc1 with SMTP id c1so2274524lbg.31 for ; Thu, 19 Apr 2012 07:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SqLJmeyn13VKHXR9rN8Nf0IECiIu4pjjsLRBz8fyhCM=; b=Q6nLZr1MwQRs3Xth3eQCPVObjjzy9as2sx6//bqoqjcs7hGzDN97ivPzC68HCzcRtC g+Iz35WGwzrB//wn5qQjOrNvG+BwiCisr4vB2YPei9sRBVAqCrdm9umiwcOQAFgWVcCC D2UQIY8PPVtUyzwPly7bJ316KUF7PQzR6FNJUr+jtWwHyCIQP4g6S2tybr94qrVG+kSr FXD6lV2cOLvPOZ3U1W1XL/84vQE0AAYwsmi5QW/F3g4h6QiVrPM6aGb3H4b0dRX9bZ/V h3harWKWVkCQLmS0orj+YJvvYBHF0ULwvxsscEmLS+5czecmnhzYo32y+JdpBAlo70ox Z7iA== MIME-Version: 1.0 Received: by 10.112.44.225 with SMTP id h1mr1161937lbm.34.1334846043547; Thu, 19 Apr 2012 07:34:03 -0700 (PDT) Received: by 10.112.23.163 with HTTP; Thu, 19 Apr 2012 07:34:03 -0700 (PDT) In-Reply-To: References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <4F8EF2C9.4030507@alum.mit.edu> Date: Thu, 19 Apr 2012 20:04:03 +0530 Message-ID: From: "Nataraju A.B" To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=90e6ba308f0c4169d604be0910da Cc: sipcore@ietf.org Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 14:34:09 -0000 --90e6ba308f0c4169d604be0910da Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Apr 18, 2012 at 10:37 PM, I=F1aki Baz Castillo wrot= e: > 2012/4/18 Paul Kyzivat : > > However, as you mention below, a typical use case for this draft is > > javascript sip stacks running in a browser that would not be able to > > implement sip tcp and udp transports. AFAIK those would indeed be > > non-compliant to 3261. If we want to encourage such implementations, > then we > > should do something so that they can be compliant. ISTM that this will > > require a revision to 3261. That could be done in a separate draft, or = it > > could be done in this draft that is already revising 3261. > > > > One disadvantage to doing it in this draft is that then compliance to t= he > > revised language would be advertised by advertising support for *this* > > document. If the relaxation is to apply to other implementations of sip > that > > don't want to implement the websocket transport, then it should be done > > separately. > > I agree. A new draft should address this issue by covering the following > topics: > > - Scenarios in which just *secure* SIP transport is required (so UDP > has no place). This could occur in local networks, providers networks > or whatever. > > - Scenarios in which a single transport can be used (i.e. in Outbound > topology in which UA's are behind different NAT's and connect to the > same Edge Proxy using TCP or UDP, so they cannot receive requests via > a different transport). > > - Special cases in which it's clear that ~100% of implementations are > not able to support SIP UDP/TCP transports (as in this draft). > > > Basically it would say "in certain cases a SIP entity MAY NOT > implement UDP and/or TCP transports". > [ABN] In addition, we can also add the change for deprecated transport parameter, *transport=3Dtls*. transport-param =3D "transport=3D" ( "udp" / "tcp" / "sctp" / other-transport) --> "tls" removed This should have been taken care when rfc5630 was introduced (but some how missed). Atleast we can take care off through this new draft. > > -- > I=F1aki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --=20 Thanks, Nataraju A.B. --90e6ba308f0c4169d604be0910da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 18, 2012 at 10:37 PM, I=F1ak= i Baz Castillo <ibc@a= liax.net> wrote:
2012/4/18 Paul Kyzivat <pkyziva= t@alum.mit.edu>:
> However, as you mention below, a typical use case fo= r this draft is
> javascript sip stacks running in a browser that would not be able to > implement sip tcp and udp transports. AFAIK those would indeed be
> non-compliant to 3261. If we want to encourage such implementations, t= hen we
> should do something so that they can be compliant. ISTM that this will=
> require a revision to 3261. That could be done in a separate draft, or= it
> could be done in this draft that is already revising 3261.
>
> One disadvantage to doing it in this draft is that then compliance to = the
> revised language would be advertised by advertising support for *this*=
> document. If the relaxation is to apply to other implementations of si= p that
> don't want to implement the websocket transport, then it should be= done
> separately.

I agree. A new draft should address this issue by covering the follow= ing topics:

- Scenarios in which just *secure* SIP transport is required (so UDP
has no place). This could occur in local networks, providers networks
or whatever.

- Scenarios in which a single transport can be used (i.e. in Outbound
topology in which UA's are behind different NAT's and connect to th= e
same Edge Proxy using TCP or UDP, so they cannot receive requests via
a different transport).

- Special cases in which it's clear that ~100% of implementations are not able to support SIP UDP/TCP transports (as in this draft).


Basically it would say "in certain cases a SIP entity MAY NOT
implement UDP and/or TCP transports".
=A0
=A0 = =A0 [ABN] In addition, we can also add the change for deprecated transport = parameter, transport=3Dtls.

= 
=
transport=
-param   =3D  "transport=3D"
                     ( "udp" / "tcp" / "sctp"=
 / other-transport) =A0
     --> "tls" removed
This should have been taken=
 care when rfc5630 was introduced (but some how missed). Atleast we can tak=
e care off through this new draft.



--
I=F1aki Baz Castillo
<ibc@aliax.net>
_____________________________= __________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore



--
= Thanks,
Nataraju A.B.

--90e6ba308f0c4169d604be0910da-- From brett@broadsoft.com Thu Apr 19 08:01:25 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B729721F85D9 for ; Thu, 19 Apr 2012 08:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.133, 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 ekmTjrEpvgBl for ; Thu, 19 Apr 2012 08:01:24 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpedge01.chinookhosting.com [173.225.22.201]) by ietfa.amsl.com (Postfix) with ESMTP id CFF2421F8637 for ; Thu, 19 Apr 2012 08:01:24 -0700 (PDT) Received: from CASUMHUB02.citservers.local (172.16.98.58) by FW01.citservers.local (172.16.98.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 19 Apr 2012 08:03:20 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Thu, 19 Apr 2012 08:03:18 -0700 From: Brett Tate To: Nataraju A.B , "sipcore@ietf.org" Date: Thu, 19 Apr 2012 08:01:19 -0700 Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: Ac0eOcPDmd5XEoFpTZah0FU5jBLl+AAAl4TQ Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C25895889@EXMBXCLUS01.citservers.local> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <4F8EF2C9.4030507@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 15:01:25 -0000 >=A0[ABN] In addition, we can also add the change for deprecated=20 > transport parameter, transport=3Dtls. > > transport-param =3D "transport=3D" > ( "udp" / "tcp" / "sctp" / other-transport) =A0 > --> "tls" removed > This should have been taken care when rfc5630 was introduced=20 > (but some how missed). Atleast we can take care off through=20 > this new draft. RFC 5630 and RFC 3261 indicate why "tls" was not to removed from ABNF. RFC 5630: 3.1.4. Usage of the transport=3Dtls URI Parameter and the TLS Via Parameter [RFC3261], Section 26.2.2 deprecated the "transport=3Dtls" URI transport parameter in SIPS or SIP URIs: Note that in the SIPS URI scheme, transport is independent of TLS, and thus "sips:alice@atlanta.com;transport=3DTCP" and "sips:alice@atlanta.com;transport=3Dsctp" are both valid (although note that UDP is not a valid transport for SIPS). The use of "transport=3Dtls" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543. The "tls" parameter has not been eliminated from the ABNF in [RFC3261], Section 25, since the parameter needs to remain in the ABNF for backward compatibility in order for parsers to be able to process the parameter correctly. The transport=3Dtls parameter has never been defined in an RFC, but only in some of the Internet drafts between [RFC2543] and [RFC3261]. From kpfleming@digium.com Thu Apr 19 08:05:04 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17F121F8631 for ; Thu, 19 Apr 2012 08:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6mg-8YRrOtq for ; Thu, 19 Apr 2012 08:04:59 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 5054F21F85C3 for ; Thu, 19 Apr 2012 08:04:59 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SKsuo-0007OU-TE for sipcore@ietf.org; Thu, 19 Apr 2012 10:04:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id DAC661A2006 for ; Thu, 19 Apr 2012 10:04:58 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZkHOMYWPp4m for ; Thu, 19 Apr 2012 10:04:58 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 5CCA91A2001 for ; Thu, 19 Apr 2012 10:04:58 -0500 (CDT) Message-ID: <4F902995.4010002@digium.com> Date: Thu, 19 Apr 2012 10:04:53 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com>, <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 15:05:05 -0000 On 04/18/2012 08:56 PM, Ravindran, Parthasarathi wrote: > Inaki, > > I agree with Christer for mandating path in case REGISTER is the first message > and it is not required to be mandated in case INVITE is the first message. > > In the mentioned below callflow, P1 should be some prior knowledge about Bob > that Bob supports websocket transport which is not always feasible through > standard mechanism. Also, the callflow is not generic enough to handle > SIP entity which supports UDP& TCP transport only. This has already been covered extensively on the list; this document should not *normatively* make any such statements. The requirement to use Outbound, Path, or any other non-RFC 3261 mechanism is dependent on the architecture of the SIP deployment, and it's up to the implementor to determine whether any such mechanisms are necessary and how they should be used. The document describing the WebSocket transport has no place mandating such usage. In addition, whether these requests are the 'first message' over the WebSocket connection or not is not relevant. If a UA wants to open a SIP-over-WebSocket connection and then send four OPTIONS requests before sending a REGISTER, there's no reason for that to be a problem. If the informative sections of the document need to be expanded to include such guidance and recommendations that could be useful, but that's a separate discussion. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From nataraju.sip@gmail.com Thu Apr 19 08:17:34 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EAB21F85D0 for ; Thu, 19 Apr 2012 08:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.071 X-Spam-Level: X-Spam-Status: No, score=-2.071 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 AuKE99bLAVmK for ; Thu, 19 Apr 2012 08:17:30 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA47021F85E5 for ; Thu, 19 Apr 2012 08:17:29 -0700 (PDT) Received: by lbgc1 with SMTP id c1so2316127lbg.31 for ; Thu, 19 Apr 2012 08:17:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=o/hr9OYSAMereNLXURXwapX70hMNIawpsy2XmYyvhag=; b=Mhi8ON1EvZTDakMdbJRfkuaarUcugpMladpojAkqD+mP8QK0W354jNahjpODYD2kFy PZT8eDy5fmTqSFZ4ZNQlgoNiwSsRdj0JIfqvP5/dRqi1cbLBZqz2gH2vHo7NV26KUJ35 KFzYNx90dVNL7s/cvQqrUPPaAhzsjDxy1LRk1V8sDdWibITi4Oaq3kdfyLNQFAGZjLrZ 7ppAwdhJ15tWcigHRvt3H5AIa5x/v9bDY5fSZbOecN86b5szUNIudiYnymf1qkfTksNM y8ts0b7SoRT9/eLkmezS+LRatRV+XUV7GFw00Bi7jZBzdOH982723n4veSTPmB9i57G5 9nFA== MIME-Version: 1.0 Received: by 10.152.145.135 with SMTP id su7mr50478lab.5.1334848648622; Thu, 19 Apr 2012 08:17:28 -0700 (PDT) Received: by 10.112.23.163 with HTTP; Thu, 19 Apr 2012 08:17:28 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 Apr 2012 20:47:28 +0530 Message-ID: From: "Nataraju A.B" To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=e89a8f2348a787b1fa04be09ab43 Cc: vpascual@acmepacket.com, jmillan@aliax.net, sipcore@ietf.org Subject: Re: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - Review comments (Nataraju A B) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 15:17:34 -0000 --e89a8f2348a787b1fa04be09ab43 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Apr 18, 2012 at 11:21 PM, I=F1aki Baz Castillo wrot= e: > 2012/4/18 Nataraju A.B : > > Hi Inaki, > > > > Please find some more comments inline... > > > > > > Please let me know, the reasoning behind single transport parameter and > two > > sent-protocol values. > > sent-protocol : WS and WSS > > transport =3D ws (only one new value) > > > > This might be confusing in future... > > Not really. In the same way that using SIP over TLS-TCP means > ;transport=3Dtcp with sips schema, or sending SIP over TLS-SCTP means > ;transport=3Dsctp with sips schema. So sending SIP over TLS-WebSocket > must involve ;transport=3Dws as sips schema. > > Note that ;transport=3Dtls has never been defined (nor in RFC 2543) and > it seems to appear in RFC 3261 due to dubious reasons, but it is not > used in RFC 3261. > > Please check http://tools.ietf.org/html/rfc5630#section-3.1.4. > > > > > > > > if we want to use SIP URI with any other secure communication mechanism > like > > WSS, might require > > update to RFC5630. like > > sec 3.1.3. > > > > If one wants to use "best-effort TLS/WSS" for SIP, one just needs to > use > > a SIP URI, and send the request over TLS ** or any other secure > transport > > mechanism like WSS** > > > > > > TLS is a extra-layer on top of TCP and also on top of WebSocket. When > applied on top of TCP transport it is commonly named "TLS", but it > should be better to call it "TLS-TCP" (in the same way that TLS over > SCTP is named "TLS-SCTP" for Via transport value in RFC 4168. > > > > > > >> > Extra closing double quote in contact header. > >> > >> Typo, thanks :) > >> > > [ABN] similar typo mistake in message F3 as well. > > Good catch. > > > > > >> The example uses a secure WS connection (on top of TLS) but does not > >> use SIPS schema. > >> > > > > [ABN] Probably for the sake of clarity, we can give call flow for Secur= e > Web > > Socket (WSS) > > and non-secure Web Socket (WS). this content is already covered in > different > > sections (this doc and rfc6455 as well). But putting it together with a > call > > flow would make the concept more clearer. > > The problem is that, trying to include a full secure call would lead > to multiple mail threads discussing SIPS stuf that is really difficult > to understand and implement. There is a RFC trying to improve/explain > it (RFC 5630). I don't think the mission of this draft is to clarify > SIPS usage. > [ABN] Inaki, I understand your point. Anyway you would have analyzed thoroughly to address the secure and non-secure websocket scenarios. The same information can serve as a ready reference for people to use this draft. Not a problem, even if you drop this comment (rfc4168 don't do this....:) > > > > Thanks a lot. > > > > > -- > I=F1aki Baz Castillo > > --=20 Thanks, Nataraju A.B. --e89a8f2348a787b1fa04be09ab43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Apr 18, 2012 at 11:21 PM, I=F1ak= i Baz Castillo <ibc@aliax.net> wrote:
2012/4/18 Nataraju A.B <nataraju.sip@gmail.com>:
> Hi Inaki,
>
> Please find some more comments inline...
>
>
> Please let me know, the reasoning behind single transport parameter an= d two
> sent-protocol values.
> sent-protocol : WS and WSS
> transport =3D ws (only one new value)
>
> This might be confusing in future...

Not really. In the same way that using SIP over TLS-TCP means
;transport=3Dtcp with sips schema, or sending SIP over TLS-SCTP means
;transport=3Dsctp with sips schema. So sending SIP over TLS-WebSocket
must involve ;transport=3Dws as sips schema.

Note that ;transport=3Dtls has never been defined (nor in RFC 2543) and
it seems to appear in RFC 3261 due to dubious reasons, but it is not
used in RFC 3261.

Please check http://tools.ietf.org/html/rfc5630#section-3.1.4.






> if we want to use SIP URI with any other secure communication mechanis= m like
> WSS, might require
> update to RFC5630. like
> <rfc5630> sec=A03.1.3.
>
> =A0 =A0If one wants to use "best-effort TLS/WSS" for SIP, on= e just needs to use
> =A0 =A0a SIP URI, and send the request over TLS ** or any other secure= transport
> mechanism like WSS**
>
> </rfc5630>

TLS is a extra-layer on top of TCP and also on top of WebSocket. When=
applied on top of TCP transport it is commonly named "TLS", but i= t
should be better to call it "TLS-TCP" (in the same way that TLS o= ver
SCTP is named "TLS-SCTP" for Via transport value in RFC 4168.





>> > =A0 =A0Extra closing double quote in contact header.
>>
>> Typo, thanks :)
>>
> [ABN] similar typo mistake in message F3 as well.

Good catch.




>> The example uses a secure WS connection (on top of TLS) but does n= ot
>> use SIPS schema.
>>
>
> [ABN] Probably for the sake of clarity, we can give call flow for Secu= re Web
> Socket (WSS)
> and non-secure Web Socket (WS). this content is already covered in dif= ferent
> sections (this doc and rfc6455 as well). But putting it together with = a call
> flow would make the concept more clearer.

The problem is that, trying to include a full secure call would lead<= br> to multiple mail threads discussing SIPS stuf that is really difficult
to understand and implement. There is a RFC trying to improve/explain
it (RFC 5630). I don't think the mission of this draft is to clarify SIPS usage.
=A0
[ABN] Inaki, I understand yo= ur point. Anyway you would have analyzed thoroughly to address the secure a= nd non-secure websocket scenarios. The same information can serve as a read= y reference for people to use this draft.

Not a problem, even if you drop this comment (rfc4168 d= on't do this....:)



Thanks a lot.




--
I=F1aki Baz Castillo
<ibc@aliax.net>= ;



--
= Thanks,
Nataraju A.B.

--e89a8f2348a787b1fa04be09ab43-- From ibc@aliax.net Thu Apr 19 08:33:54 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D07A21F869E for ; Thu, 19 Apr 2012 08:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pd5vW0nXOqXO for ; Thu, 19 Apr 2012 08:33:49 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7069021F8698 for ; Thu, 19 Apr 2012 08:33:49 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2169306vcb.31 for ; Thu, 19 Apr 2012 08:33:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=utTKM18xymgzhPisO2QQHLHrrfUrqAB8395+SM8jm48=; b=oAUhMQbbfdZSByF2ZaobArGUgMJjBQpB0UmY4Ue7t6syzytdNyNyiSvj3/F5ALLpTI V+7wBgZlm1qdd6ajuXYUkS/KBy4PI41PxV0Ux4gBUj8Elk8Y3M+OnLUvjTBjdW66bWHE oKHMfPX4LfWgo5ObVjy5VtCVxgFcPRu8c1hCt/8imz/UO0QnYmxJTwt3B1DbOn7QP+lV HMrHRwdPD4mNdufwKGok1lOKk4sV/ytOdY+mZZNbrf/NNiFj1/9T6ibxuytt9h9t7WPz iZuyavzhB9oB4Uygawsb6xYk0To0lDSvK2B44YuTvhs5Q3+mOmQ6osbqHJ/dvJ8PtC/Z XLCQ== Received: by 10.220.241.12 with SMTP id lc12mr676994vcb.22.1334849628671; Thu, 19 Apr 2012 08:33:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 19 Apr 2012 08:33:28 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 19 Apr 2012 17:33:28 +0200 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmsIYaHxvptcdnLJaS+opx8ugST8HfWeFnJ8Aj6YhGKhDSbRUMJ5kE9kMDAnjwyHKSlwJ7E Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 15:33:54 -0000 2012/4/19 Ravindran, Parthasarathi : > I agree with Christer for mandating path in case REGISTER is the first me= ssage > and it is not required to be mandated in case INVITE is the first message= . Hi Partha, honestly I don't think it's a good idea to mandate SIP topology requirements in a draft describing a SIP transport (just it). We tryed to mandate Outbound RFC 5626 and such a requirement was removed in IETF #83 due to consensus. So mandating Path is mostly the same "error". It was clearly agreed in Paris that the draft should not assume a SIP network topology, but also that it should include a *informative* section for the most expected use case (clients like SIP browsers). This is already done in Appendix I which describes such an scenario and all the SIP standards (Outbound, Path, GRUU) that could help to make it to work. But *just* it. Again, the draft does NOT assume that clients are web browsers so please consider it for future suggestions about the draft. > In the mentioned below callflow, P1 should be some prior knowledge about = Bob > that Bob supports websocket transport which is not always feasible throug= h > standard mechanism. Also, the callflow is not generic enough to handle > SIP entity which supports UDP & TCP transport only. I don't agree. But if it is easier to understand imagine that alice, bob and the proxy/registrar all of them implement a WebSocket client and server, so alice can open a WS connection to proxy and also to bob, and the same for bob. So no Record-Route required. That's all. Regards. --=20 I=C3=B1aki Baz Castillo From nataraju.sip@gmail.com Thu Apr 19 09:04:54 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5E621F865E for ; Thu, 19 Apr 2012 09:04:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.247 X-Spam-Level: X-Spam-Status: No, score=-2.247 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 KcNDGkY5TOCJ for ; Thu, 19 Apr 2012 09:04:48 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 459D221F8615 for ; Thu, 19 Apr 2012 09:04:48 -0700 (PDT) Received: by lagj5 with SMTP id j5so7245847lag.31 for ; Thu, 19 Apr 2012 09:04:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mZKNdPY5qNZiLfCe43PEOuGIoC4ECMurSwtlgItyF40=; b=xS80lG8+YpypmZMLw14k/9W7NNR0qxIYIUzUj/u3KmI+BE2VAn9Ee4xUX72GQtWksI vPKMgR1mL3GoFuAiSiGnU7sPEt1CTUKIL6gMNFOnhLd3yJMvln6TTxu5YkZBUS/WQAPs Kwk40HRdYP80urW2aJqZ41fs8m0yghVlGcuukCbXWfT9pDaqQBO8qu77Xusx/thWqOG7 nNLc8DqfFfR+182rpp6foebCN6qcVp941+rEXVlHgXh6Oc5n63UuIB7fKezopkD7DsW0 NZ+GP3WzEaf8cLHJI9Ndtbc5Gl9AZSAEley74EcNB9L6JzQf5fbJFX+Ci94lbmJf6a9a 9hyw== MIME-Version: 1.0 Received: by 10.152.145.169 with SMTP id sv9mr207783lab.12.1334851487161; Thu, 19 Apr 2012 09:04:47 -0700 (PDT) Received: by 10.112.23.163 with HTTP; Thu, 19 Apr 2012 09:04:47 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E228359@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228359@inba-mail01.sonusnet.com> Date: Thu, 19 Apr 2012 21:34:47 +0530 Message-ID: From: "Nataraju A.B" To: "Ravindran, Parthasarathi" Content-Type: multipart/alternative; boundary=e89a8f235097b85d6104be0a543a Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Incoming call notification for websocket transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 16:04:54 -0000 --e89a8f235097b85d6104be0a543a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Partha, After some thinking, I also found we need incoming SIP requests @ websocket clients for presence services like gtalk, yahoo, skype messengers... On Thu, Apr 19, 2012 at 8:17 AM, Ravindran, Parthasarathi < pravindran@sonusnet.com> wrote: > Hi Nataraju,**** > > ** ** > > [ABN] Partha, **** > > Can you name some scenario which need this incoming SIP request= s > @ the WebSocket client ???? **** > > ** ** > > There are two scenario which I could think of**** > > ** ** > > **1) **Skype sort of websocket application in endpoint **** > > **2) **B2BUA which listen on websocket to receive the calls without > registration**** > > ** ** > > Thanks**** > > Partha**** > > ** ** > > *From:* Nataraju A.B [mailto:nataraju.sip@gmail.com] > *Sent:* Wednesday, April 18, 2012 3:50 PM > *To:* Ravindran, Parthasarathi > *Cc:* Sa=FAl Ibarra Corretg=E9; SIPCORE (Session Initiation Protocol Core= ) > WG; SIPCORE Chairs; I=F1aki Baz Castillo > *Subject:* Re: [sipcore] Stateless or Transaction stateful proxy possible > in Websocket transport? [RE: Call for Adoption: > draft-ibc-sipcore-sip-websocket-02]**** > > ** ** > > ** ** > > On Wed, Apr 18, 2012 at 3:37 PM, Ravindran, Parthasarathi < > pravindran@sonusnet.com> wrote:**** > > Even if it is the limitations of websocket, SIP UA MUST listen in > UDP & TCP as per RFC 3261 and not adhere to this requirement which MUST > be considered as a violation of RFC 3261. In case you think that this dra= ft > does not violate any RFC 3261 for SIP UA, the Current text in the draft i= s > not > clear enough, Please mention it explicitly in the draft that > > "As per this specification, SIP UA MUST support UDP, TCP transport apart > from Websocket as a transport" > > This information helps for the implementers who wish to use this draft fo= r > RTCWeb client to SIP Interop in the standard way. I'm writing this mail a= s > most of the folks support this draft for interworking RTCWeb client to SI= P > in the standard manner as per my discussion in IETF-83. > > I'll write the separate mail thread for discussing incoming SIP over > websocket > as it is one another major open item in this draft.**** > > [ABN] Partha, **** > > Can you name some scenario which need this incoming SIP request= s > @ the WebSocket client ???? **** > > > Thanks > Partha**** > > > >-----Original Message----- > >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] > >Sent: Wednesday, April 18, 2012 3:23 PM > >To: Ravindran, Parthasarathi**** > > >Cc: I=F1aki Baz Castillo; SIPCORE (Session Initiation Protocol Core) WG; > >SIPCORE Chairs; Nataraju A.B > >Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible > >in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip- > >websocket-02] > > > >**** > > >On Apr 18, 2012, at 11:35 AM, Ravindran, Parthasarathi wrote: > > > >> As per your below statement, JavaScript with SIP and RTCWeb Browser > >MUST NOT use this draft as it violates RFC 3261. > >> > > > >It doesn't, see my previous email explaining why. > > > >> Also in IETF-83 SIPCore meeting, I noticed that SIP UA over websocket > >will not listen for the incoming call without registration but in case > >of your draft is written with SIP softphone (smartphone) in mind , it is > >possible to listen in Port 80 or any other Websocket port which is not > >addressed in this draft till now. We need to discuss and sort it out. > >> > > > >The fact that a JS SIP client (running in a web browser) does not listen > >for incoming connections is a limitation imposed by the WebSocket API, > >not by this draft. This specification defines 2 entities: a SIP > >WebSocket Client and a SIP WebSocket Server, so nobody stops you from > >creating an entity that implements both and can accept incoming > >WebSocket connections. Of course, such an application would not run in a > >browser. > > > > > >Regards, > > > >-- > >Sa=FAl Ibarra Corretg=E9 > >AG Projects > > > >**** > > > > **** > > ** ** > > -- > Thanks,**** > > Nataraju A.B.**** > > ** ** > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --=20 Thanks, Nataraju A.B. --e89a8f235097b85d6104be0a543a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Partha,=A0
After some thinking, I also found we need incoming SIP reque= sts @ websocket clients for presence services like gtalk, yahoo, skype mess= engers...

On Thu, Apr 19, 2012 at = 8:17 AM, Ravindran, Parthasarathi <pravindran@sonusnet.com> wrote:

Hi Nataraju,

=A0

[ABN] Partha,=A0

=A0 =A0 =A0 =A0 =A0 Can you name some scenario which= need this incoming SIP requests @ the WebSocket client ????=A0

=A0<= /p>

There are two scenario wh= ich I could think of

=A0<= /p>

1)=A0=A0=A0=A0=A0 Skype sort of websoc= ket application in endpoint

2)=A0=A0=A0=A0=A0 B2BUA which listen o= n websocket to receive the calls without registration<= /p>

=A0<= /p>

Thanks

Partha

=A0<= /p>

From: Nataraju= A.B [mailto:na= taraju.sip@gmail.com]
Sent: Wednesday, April 18, 2012 3:50 PM
To: Ravindran, Parthasarathi
Cc: Sa=FAl Ibarra Corretg=E9; SIPCORE (Session Initiation Protocol C= ore) WG; SIPCORE Chairs; I=F1aki Baz Castillo
Subject: Re: [sipcore] Stateless or Transaction stateful proxy possi= ble in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-w= ebsocket-02]

=A0

=A0

On Wed, Apr 18, 2012 at 3:37 PM, Ravindran, Parthasa= rathi <prav= indran@sonusnet.com> wrote:

Even if it is the limitations of websocket, SIP UA M= UST listen in
UDP & TCP as per RFC 3261 and not adhere to this requirement which MUST=
be considered as a violation of RFC 3261. In case you think that this draft=
does not violate any RFC 3261 for SIP UA, the Current text in the draft is = not
clear enough, Please mention it explicitly in the draft that

"As per this specification, SIP UA MUST support UDP, TCP transport apa= rt
from Websocket as a transport"

This information helps for the implementers who wish to use this draft for<= br> RTCWeb client to SIP Interop in the standard way. I'm writing this mail= as
most of the folks support this draft for interworking RTCWeb client to SIP<= br> in the standard manner as per my discussion in IETF-83.

I'll write the separate mail thread for discussing incoming SIP over we= bsocket
as it is one another major open item in this draft.

[ABN] Partha,=A0

=A0 =A0 =A0 =A0 =A0 Can you name some scenario which= need this incoming SIP requests @ the WebSocket client ????=A0


Thanks
Partha


>-----Original Message-----
>From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com]
>Sent: Wednesday, April 18, 2012 3:23 PM
>To: Ravindran, Parthasarathi

>Cc: I=F1aki Baz Castillo; SIPCORE (Session Initi= ation Protocol Core) WG;
>SIPCORE Chairs; Nataraju A.B
>Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible=
>in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-<= br> >websocket-02]
>
>

>On Apr 18, 2012, = at 11:35 AM, Ravindran, Parthasarathi wrote:
>
>> As per your below statement, JavaScript with SIP and RTCWeb Browse= r
>MUST NOT use this draft as it violates RFC 3261.
>>
>
>It doesn't, see my previous email explaining why.
>
>> Also in IETF-83 SIPCore meeting, I noticed that SIP UA over websoc= ket
>will not listen for the incoming call without registration but in case<= br> >of your draft is written with SIP softphone (smartphone) in mind , it i= s
>possible to listen in Port 80 or any other Websocket port which is not<= br> >addressed in this draft till now. We need to discuss and sort it out. >>
>
>The fact that a JS SIP client (running in a web browser) does not liste= n
>for incoming connections is a limitation imposed by the WebSocket API,<= br> >not by this draft. This specification defines 2 entities: a SIP
>WebSocket Client and a SIP WebSocket Server, so nobody stops you from >creating an entity that implements both and can accept incoming
>WebSocket connections. Of course, such an application would not run in = a
>browser.
>
>
>Regards,
>
>--
>Sa=FAl Ibarra Corretg=E9
>AG Projects
>
>



=A0

--
Thanks,

Nataraju A.B.

=A0


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




--
= Thanks,
Nataraju A.B.

--e89a8f235097b85d6104be0a543a-- From ibc@aliax.net Thu Apr 19 09:11:21 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8F821F866E for ; Thu, 19 Apr 2012 09:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=0.042, 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 ahom+1SpVBV3 for ; Thu, 19 Apr 2012 09:11:19 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3B09A21F867C for ; Thu, 19 Apr 2012 09:11:19 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2202598vcb.31 for ; Thu, 19 Apr 2012 09:11:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=AJB8XKS3SqUY2tdFvZTeCv9ppTCiwQkYm7oUfnwNIq4=; b=Hr+lpqzb59jcD2qhgoIJ/pAdXNjkIOImnjSobrQ53yuy1Ft5ojHrpi/jgz2T5jfpBB A6i9J+t+8agUuxVVITqQIz1VxCNlSbnGi+NfmSwZkhjnYkgAV8b5D05f2X+D96UoTIN+ Q/YeTF5FerqcqUUc4elsy9lRFdJu6YCAxdNOTVknrzulYCiEDUDaYDw3c3+PQbG/8szK cxNo587ZAYcfHXIm7ngciqH66oCTfF+s5W0rJ4zWC/HY+k/tLMCgALz2VJEQEenNpStj JXh1nFdBjkRKMowO7/i4MdbcHqWY0yj7THPid5rqEisnMbv5gtsgm2wGgFko6exU8j/A 19Nw== Received: by 10.220.49.66 with SMTP id u2mr1604187vcf.2.1334851878706; Thu, 19 Apr 2012 09:11:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 19 Apr 2012 09:10:58 -0700 (PDT) In-Reply-To: References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228359@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 19 Apr 2012 18:10:58 +0200 Message-ID: To: "Nataraju A.B" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlHZK5aEdcXvoUsGVFJiBi5phMrPR8FPQjZz/q9vvO+Xs7ilD6GZWe+oosuoqXLrh1WbZry Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Incoming call notification for websocket transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 16:11:21 -0000 2012/4/19 Nataraju A.B : > After some thinking, I also found we need incoming SIP requests @ websock= et > clients for presence services like gtalk, yahoo, skype messengers... I don't understand. Presence in SIP is based on PUBLISH, SUBSCRIBE, NOTIFY. If the SIP client is connected to an Outbound proxy the SIP client would reuse the same connection for sending PUBLISH, SUBSCRIBES and so (since there is already a open connection open to the outbound proxy as RFC 3261 states) and therefore also for receiving NOTIFY requests (within the subscription dialog). But again, nothing prevents somebody to code a SIP WebSocket entity capable of creating outbound WS connections and listening for inbound WS connections. Please don't assume that the draft just talks about web browsers. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Apr 19 09:23:11 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C104221F86AD for ; Thu, 19 Apr 2012 09:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_71=0.6, 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 XjPGlhkxCQQF for ; Thu, 19 Apr 2012 09:23:07 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8493321F86A0 for ; Thu, 19 Apr 2012 09:23:07 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so2213292vcb.31 for ; Thu, 19 Apr 2012 09:23:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=7j9K9coplqDgnCs5mYwy6JO0HjVzajs9wTZLLgNB1Gk=; b=KSFWeGhYbrR5UcwkcHoi4dvc9WFUmIOby/l1xWRlKfDA0RL03+0ES5poU9p93LvL4H uAuR3awoklCUqjkwtBnfSbvADg2Ovu32+0Fb07sf6QQHsd15PazeIDy0xK6D3fkf/qQm rES0UBFQzF9+wMnYnaP+g9yDMA0HyV65qdDeeSjlpEfrK6nSB6ayRZ0eSZL0Bp3zWMOZ xMt5n3CfqQhlCiB4dlNaw/mBh7EvTOlZP8DAL7ay+ABKiXXoyWi4Nr8C6+8PnGBPGyrJ R9Ma0uPjIZQvQLl2ZA41rJUsjjjw10fn93JzIhZf5RUTZG2Km+aIp/pd0Q6fink3bnDU lntQ== Received: by 10.52.15.233 with SMTP id a9mr1312424vdd.34.1334852587013; Thu, 19 Apr 2012 09:23:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 19 Apr 2012 09:22:46 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 19 Apr 2012 18:22:46 +0200 Message-ID: To: "Nataraju A.B" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkjuS2sSXFUnMUaoue2yhHgWbBFPuFZ8ee3gSNPPwcaTnWIh6Q+9nV3sl8hrSq5T6VuqABT Cc: vpascual@acmepacket.com, jmillan@aliax.net, sipcore@ietf.org Subject: Re: [sipcore] Call flow for Secure Web Socket creation --- draft-ibc-sipcore-sip-websocket-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 16:23:11 -0000 2012/4/17 Nataraju A.B : > Hi All, > > I have written a call flow for the secure web socket usage with TCP. > > Please go through the same and share if any changes required. Hi Nataraju, I think the flow is ok, but honestly we wouldn't like to deal too much with SIPS stuf within the draft, is not the mission of the draft to clarify all the SIPS complexity and issues. IMHO RFC 5630 is the good place for that, and RFC 5630 is already referenced by RFC 3261 (it updates RFC 3261 in fact) so IMHO the draft does not need to mention it (we don't want to open Pandora'x box and I think we shouldn't). As said before in a previous mail, using a secure transport without SIPS schema is perfectly valid according to RFC 3261 and RFC 5630: - SIPS requires secure transport in all the path, - but a secure transport does not require SIPS schema. http://tools.ietf.org/html/rfc5630#section-3.1.3 Thanks a lot. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Apr 19 09:31:59 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D48C21F8688 for ; Thu, 19 Apr 2012 09:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue4crKLrgpyS for ; Thu, 19 Apr 2012 09:31:58 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 86D0B21F867C for ; Thu, 19 Apr 2012 09:31:58 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6773386vbb.31 for ; Thu, 19 Apr 2012 09:31:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=HpJ6hBh2oKk5L/Dnelv5yl/8NpcxHkZhxUzblm/qW+o=; b=MB7O7U0ua3JMW8yi3mzjoXv+B5ec4fjxYli2i8M+krkSjvGze/yR8MmTJwPqVTHvxa bcyq66DN97CV2hhLosIiBTMLA3PtZjxiPYSImWMq3FgDjccp2QTDx9+6104+7nwcNuY8 rLktkXZfO46uH2Aa4sNPoxJKJZcCnj+e67wRx+yNenqXjqZHFsaIdB4z2Ejtk+xxHlcg 37dGt7Qu0vkMv98Gf97svvatslBDj3QkLzwbUShhzIFjw6jSITjZwJZy6scbBp+Z+rrw aziajEgr6g2X7o+tZLpFPACi2K2q4Y+4EHBVYoT6DmOIy5Arbl+8iCWMtUJMSLEU2WlQ UqHg== Received: by 10.52.64.173 with SMTP id p13mr782167vds.51.1334853117969; Thu, 19 Apr 2012 09:31:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 19 Apr 2012 09:31:36 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 19 Apr 2012 18:31:36 +0200 Message-ID: To: "Nataraju A.B" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmM7K7VCzmGgWOLLwQi9g7qtQFGnUlivH9TnKLiz7X/v0C+ZQn39M+XNBa02vSYBFJb6YrY Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - Review comments (Nataraju A B) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Apr 2012 16:31:59 -0000 2012/4/19 Nataraju A.B : >> The problem is that, trying to include a full secure call would lead >> to multiple mail threads discussing SIPS stuf that is really difficult >> to understand and implement. There is a RFC trying to improve/explain >> it (RFC 5630). I don't think the mission of this draft is to clarify >> SIPS usage. > > > [ABN] Inaki, I understand your point. Anyway you would have analyzed > thoroughly to address the secure and non-secure websocket scenarios. The > same information can serve as a ready reference for people to use this > draft. In fact, examples in the draft use secure WebSocket connections, so IMHO we "help" people implementing secure SIP. But SIPS schema is another history nobody wants to deal with (that is my opinion after many threads about it). The most realistic scenario is that in which clients connect to their proxy/server using a secure transport and the proxy decides whether to use a secure or non-secure transport for communicating with other servers, gateways or SIP networks, and examples in the draft show that case. If somebody wants to use SIPS with WebSocket transport, then just use SIPS schema everywhere and WSS connections (and read RFC 5630) :) Regards. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Thu Apr 19 17:39:14 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F3521F8653 for ; Thu, 19 Apr 2012 17:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.374 X-Spam-Level: X-Spam-Status: No, score=-6.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjEmmZkV1j3H for ; Thu, 19 Apr 2012 17:39:13 -0700 (PDT) Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with ESMTP id 749AA21F8646 for ; Thu, 19 Apr 2012 17:39:12 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKT5CwMDaoJmxUZuV+rn69nN0xOboFT9Cm@postini.com; Thu, 19 Apr 2012 17:39:13 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 19 Apr 2012 20:39:46 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Fri, 20 Apr 2012 06:09:04 +0530 From: "Ravindran, Parthasarathi" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: AQHNHSsWQiKr/IZJokCfX43Mp6RbG5agJJrA//+unYCAAGacsIAAFBwAgABihBD//7B5AIAABfgAgAD3fzCAAI6cAIAA8TmA Date: Fri, 20 Apr 2012 00:39:03 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 00:39:14 -0000 SGkgSW5ha2ksDQoNClRoZXJlIGFyZSBvbmx5IHR3byBvcHRpb25zIHdoaWNoIEkgY291bGQgdGhp bmsgb2YgZm9yd2FyZCBmb3IgdGhpcyBkcmFmdA0KDQoxKSBBcyBJIGVhcmxpZXIgbWVudGlvbmVk LCBXZWJzb2NrZXQgdHJhbnNwb3J0IHdvcmtzIHdlbGwgb25seSBpbiBzcGVjaWZpYyBTSVAgdG9w b2xvZ3kgYW5kIG5vdCBpbiBhbGwgdG9wb2xvZ3kgYXMgaXQgaXMgbm90IGNhcGFibGUgb2Ygc3Vw cG9ydGluZyBVRFAvVENQIHRyYW5zcG9ydC4gSW4gY2FzZSB0aGUgZHJhZnQgaXMgb25seSBnb2lu ZyB0byBzcGVjaWZ5IHRyYW5zcG9ydCwgdGhlbiBTSVAgZW50aXRpZXMgc3VwcG9ydCB0aGlzIGRy YWZ0IGhhcyB0byBoYXZlIGNvbXBsaWFuY2Ugd2l0aCBSRkMgMzI2MSAoVURQLCBUQ1AgdHJhbnNw b3J0KSBhcyB3ZWxsIGFuZCBwYXJ0aWN1bGFybHkgeW91IGhhdmUgdG8gbWVudGlvbiBob3cgSmF2 YXNjcmlwdCBiYXNlZCBTSVAgc3RhY2sgd2lsbCBjb21wbGlhbmNlIHdpdGggUkZDIDMyNjEuDQoN CjIpIEFsdGVybmF0aXZlIGlzIHRvIHNwZWNpZnkgU0lQIHRvcG9sb2d5IHJlcXVpcmVtZW50IHdo ZXJlaW4gd2Vic29ja2V0IHJlYWxseSBhcHBsaWVzLiBJbmNsdWRlIHRoZSByZWxhdGVkIGhlYWRl ciBsaWtlIHJlY29yZC1yb3V0ZSAmIHBhdGggd2l0aCB0aGUgZGV0YWlsIGluZm9ybWF0aW9uIHdo ZXJlIHRoZXNlIGhlYWRlcnMgYXJlIG1hbmRhdGVkLg0KDQpJTUhPLCB0aGUgY3VycmVudCBkcmFm dCBpcyBub3QgY2xlYXIgZW5vdWdoIGFib3V0IFNJUCBvdmVyIFdlYnNvY2tldCB0cmFuc3BvcnQg dXNhZ2UuDQoNClRoYW5rcw0KUGFydGhhDQoNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+RnJvbTogScOxYWtpIEJheiBDYXN0aWxsbyBbbWFpbHRvOmliY0BhbGlheC5uZXRdDQo+U2Vu dDogVGh1cnNkYXksIEFwcmlsIDE5LCAyMDEyIDk6MDMgUE0NCj5UbzogUmF2aW5kcmFuLCBQYXJ0 aGFzYXJhdGhpDQo+Q2M6IENocmlzdGVyIEhvbG1iZXJnOyBzaXBjb3JlQGlldGYub3JnDQo+U3Vi amVjdDogUmU6IFtzaXBjb3JlXSBTdGF0ZWxlc3Mgb3IgVHJhbnNhY3Rpb24gc3RhdGVmdWwgcHJv eHkgcG9zc2libGUNCj5pbiBXZWJzb2NrZXQgdHJhbnNwb3J0PyBbUkU6IENhbGwgZm9yIEFkb3B0 aW9uOiBkcmFmdC1pYmMtc2lwY29yZS1zaXAtDQo+d2Vic29ja2V0LTAyXQ0KPg0KPjIwMTIvNC8x OSBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkgPHByYXZpbmRyYW5Ac29udXNuZXQuY29tPjoNCj4+ IEkgYWdyZWUgd2l0aCBDaHJpc3RlciBmb3IgbWFuZGF0aW5nIHBhdGggaW4gY2FzZSBSRUdJU1RF UiBpcyB0aGUgZmlyc3QNCj4+IG1lc3NhZ2UgYW5kIGl0IGlzIG5vdCByZXF1aXJlZCB0byBiZSBt YW5kYXRlZCBpbiBjYXNlIElOVklURSBpcyB0aGUNCj5maXJzdCBtZXNzYWdlLg0KPg0KPkhpIFBh cnRoYSwgaG9uZXN0bHkgSSBkb24ndCB0aGluayBpdCdzIGEgZ29vZCBpZGVhIHRvIG1hbmRhdGUg U0lQDQo+dG9wb2xvZ3kgcmVxdWlyZW1lbnRzIGluIGEgZHJhZnQgZGVzY3JpYmluZyBhIFNJUCB0 cmFuc3BvcnQgKGp1c3QgaXQpLg0KPldlIHRyeWVkIHRvIG1hbmRhdGUgT3V0Ym91bmQgUkZDIDU2 MjYgYW5kIHN1Y2ggYSByZXF1aXJlbWVudCB3YXMgcmVtb3ZlZA0KPmluIElFVEYgIzgzIGR1ZSB0 byBjb25zZW5zdXMuIFNvIG1hbmRhdGluZyBQYXRoIGlzIG1vc3RseSB0aGUgc2FtZQ0KPiJlcnJv ciIuDQo+DQo+SXQgd2FzIGNsZWFybHkgYWdyZWVkIGluIFBhcmlzIHRoYXQgdGhlIGRyYWZ0IHNo b3VsZCBub3QgYXNzdW1lIGEgU0lQDQo+bmV0d29yayB0b3BvbG9neSwgYnV0IGFsc28gdGhhdCBp dCBzaG91bGQgaW5jbHVkZSBhICppbmZvcm1hdGl2ZSoNCj5zZWN0aW9uIGZvciB0aGUgbW9zdCBl eHBlY3RlZCB1c2UgY2FzZSAoY2xpZW50cyBsaWtlIFNJUCBicm93c2VycykuDQo+VGhpcyBpcyBh bHJlYWR5IGRvbmUgaW4gQXBwZW5kaXggSSB3aGljaCBkZXNjcmliZXMgc3VjaCBhbiBzY2VuYXJp byBhbmQNCj5hbGwgdGhlIFNJUCBzdGFuZGFyZHMgKE91dGJvdW5kLCBQYXRoLCBHUlVVKSB0aGF0 IGNvdWxkIGhlbHAgdG8gbWFrZSBpdA0KPnRvIHdvcmsuIEJ1dCAqanVzdCogaXQuDQo+DQo+QWdh aW4sIHRoZSBkcmFmdCBkb2VzIE5PVCBhc3N1bWUgdGhhdCBjbGllbnRzIGFyZSB3ZWIgYnJvd3Nl cnMgc28gcGxlYXNlDQo+Y29uc2lkZXIgaXQgZm9yIGZ1dHVyZSBzdWdnZXN0aW9ucyBhYm91dCB0 aGUgZHJhZnQuDQo+DQo+DQo+PiBJbiB0aGUgbWVudGlvbmVkIGJlbG93IGNhbGxmbG93LCBQMSBz aG91bGQgYmUgc29tZSBwcmlvciBrbm93bGVkZ2UNCj4+IGFib3V0IEJvYiB0aGF0IEJvYiBzdXBw b3J0cyB3ZWJzb2NrZXQgdHJhbnNwb3J0IHdoaWNoIGlzIG5vdCBhbHdheXMNCj4+IGZlYXNpYmxl IHRocm91Z2ggc3RhbmRhcmQgbWVjaGFuaXNtLiBBbHNvLCB0aGUgY2FsbGZsb3cgaXMgbm90IGdl bmVyaWMNCj4+IGVub3VnaCB0byBoYW5kbGUgU0lQIGVudGl0eSB3aGljaCBzdXBwb3J0cyBVRFAg JiBUQ1AgdHJhbnNwb3J0IG9ubHkuDQo+DQo+SSBkb24ndCBhZ3JlZS4gQnV0IGlmIGl0IGlzIGVh c2llciB0byB1bmRlcnN0YW5kIGltYWdpbmUgdGhhdCBhbGljZSwgYm9iDQo+YW5kIHRoZSBwcm94 eS9yZWdpc3RyYXIgYWxsIG9mIHRoZW0gaW1wbGVtZW50IGEgV2ViU29ja2V0IGNsaWVudCBhbmQN Cj5zZXJ2ZXIsIHNvIGFsaWNlIGNhbiBvcGVuIGEgV1MgY29ubmVjdGlvbiB0byBwcm94eSBhbmQg YWxzbyB0byBib2IsIGFuZA0KPnRoZSBzYW1lIGZvciBib2IuIFNvIG5vIFJlY29yZC1Sb3V0ZSBy ZXF1aXJlZC4gVGhhdCdzIGFsbC4NCj4NCj4NCj4NCj5SZWdhcmRzLg0KPg0KPg0KPi0tDQo+ScOx YWtpIEJheiBDYXN0aWxsbw0KPjxpYmNAYWxpYXgubmV0Pg0K From dworley@avaya.com Thu Apr 19 19:34:06 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E426821E801F for ; Thu, 19 Apr 2012 19:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.243 X-Spam-Level: X-Spam-Status: No, score=-103.243 tagged_above=-999 required=5 tests=[AWL=0.356, 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 owjogi3ukJQq for ; Thu, 19 Apr 2012 19:34:06 -0700 (PDT) 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 EA9FB21E8025 for ; Thu, 19 Apr 2012 19:34:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF3KkE+HCzI1/2dsb2JhbABDsUyBB4IQEihRARUpQicEGxqHbZkyhBqdJpAEYwSLQZBFSoldgwM X-IronPort-AV: E=Sophos;i="4.75,450,1330923600"; d="scan'208";a="343364403" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 Apr 2012 22:33:43 -0400 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 Apr 2012 22:17:25 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 19 Apr 2012 22:34:01 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Thu, 19 Apr 2012 22:33:16 -0400 Thread-Topic: Comments on draft-ietf-sipcore-rfc4244bis-07 - sections 10.1 and 11-end Thread-Index: AQHNHp4LNYo/qC7tZEWmC3/r73nXYQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-07 - sections 10.1 and 11-end X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 02:34:07 -0000 Correction of my comments on 10.3: I proposed removing all of item 6: 6. Missing entity: If the request clearly has a gap in the hi-entry (e.g. by evaluating via header to the existing request history to see if it traversed a domain which doesn't exist in History-Info header field.), the entity adding an hi-entry MUST add an index a digit of "0" to the current index prior to adding appropriate index for the action to be taken. If the index of the last hi- entry in the request received was 1.1.2 and there was a missing hi-entry and the request was being forwarded to the next hop, the resulting index will be 1.1.2.0.1. But I should have restricted it to removing the "condition", namely "(e.g. by evaluating via header to the existing request history to see if it traversed a domain which doesn't exist in History-Info header field.)" 10.1.1. Indicating Privacy In this case, the intermediary MUST set a Privacy header field to a priv-value of "history" and include the Privacy header field in the hi-targeted-to- uri, for each new hi-entry added by the intermediary, as the request is retargeted within the domain for which the SIP entity is responsible. Note, that the hi-entries that are added to a request from the cache are excluded in this case since the appropriate privacy was set for those hi-entries when they were originally added to a request. The intermediary MUST NOT include any other priv- values in this Privacy header field. The phrasing here is awkward. I think this would be better: In this case, the intermediary MUST construct a Privacy header field with the single priv-value of "history" and include the Privacy header field in the hi-targeted-to-uri, for each new hi-entry created by the intermediary, as the request is retargeted within the domain for which the SIP entity is responsible. (Note that hi-entries that are added to a request from the cache are not modified by this process.) However, I'm uncertain of the phrase "is retargeted within the domain". Does that mean retargeting outside the domain of interest cannot have this process applied? Perhaps we want to leave the determination to the intermediary, since it is doing the modification on its own behalf. In that case, we would change the end of the sentence to: ... for each new hi-entry created by the intermediary whose hi-targeted-to-uri it wishes to privacy protect. Finally, the terminator of the request may not want to reveal the I think it would be more standard to say A UAS may not want to reveal the and replace "terminator" with "UAS" in the rest of the paragraph. 10.1.2. Applying Privacy When a request is retargeted to a URI associated with a domain for which the SIP intermediary is not responsible or a response is forwarded to a domain for which the SIP intermediary is not responsible, a Privacy Service at the boundary of the domain applies It would be shorter to say When a SIP message is forwarded to a domain for which the SIP intermediary is not responsible ... I think that has the same effect. which a SIP intermediary is responsible, are anonymized by the probably should be "which >>>the<<< SIP intermediary is responsible", referring to the intermediary discussed in the first paragraph. URIs containing a domain of anonymous.invalid (e.g., anonymous@anonymous.invalid). If there is a Privacy header field in Strictly, that should be "sip:anonymous@anonymous.invalid" and/or "sips:anonymous@anonymous.invalid". Perhaps it would be better to not describe the URI at all but just refer to RFC 3323. However, the algorithm requires that H-I processing can *recognize* entries that have already been anonymized, so we have to add a condition: The Privacy Service MUST change any hi-targeted-to-uris in >>>these<<< hi-entries that have not been anonymized (evidenced by their domain not being "anonymous.invalid") to anonymous URIs containing a domain of "anonymous.invalid" as described in RFC 3323 section 4.1. also: If there is a Privacy header field in the "headers" component of the hi-targeted-to-uri in >>>these<<< hi-entries(?), then the Privacy header field value MUST be removed from the hi-entry. Similarly in the next paragraph: If there is not a Privacy header field in the message header of the request or response that is being forwarded, but there is a Privacy header field with a priv-value of "history" in the "headers" component in any of the hi-targeted-uris in the hi-entries associated with the domain for which a SIP intermediary is responsible, then the Privacy Service MUST update those hi-targeted-to-uris >>>as described above.<<< Any other priv-values in the Privacy header field in the "headers" component of the hi-targeted-to-uris in the hi-entries MUST be ignored. >>>[Last sentence deleted, as it is included in the "as above" prescription.]<<< Maybe there is a better way to factor out the "anonymize and remove Privacy" operation. 11. Application Considerations The SIP entity MUST determine if there are gaps in the indices. This is strictly true, but I don't think it's the sense we want. There is also the problem that the two types of "gap" are distinctly different in what they reveal. Maybe something fuzzier like: The SIP entity MUST be prepared to process effectively messages whose hi-entries show evidence of "gaps", that is, situations that reveal that not all of the forks of the request have been recorded in the hi-entries. Gaps are possible if the request is forwarded through intermediaries that do not support the History-info header field and are reflected by the existence of multiple hi-entries with an digit of "0" e.g. "1.1.0.1". Replace "digit" with "integer" as discussed before, and change "an", or rather leave it as "an" because we're changing "digit" to integer. But "multiple" should be deleted. In particular, when a UAS receives a request whose request-URI does not match the last hi-entry, it adds a "gap" hi-entry, but since the UAS does not forward the request onward, it does not add any further hi-entries with "0"s. But in this case, the request *has* had a gap in H-I processing. Gaps are also possible in the case of parallel forking if there is an outstanding request at the time the SIP entity sends a response as described in Section 9.4, in which case the gap will not be visible as the branch responsible for the gap wasn't on the path of the request received. I think this sentence needs to be modified strongly: Gaps are also possible in the case of parallel forking if there is an outstanding request at the time the SIP entity sends a >>>message<<<. A gap (missing branch) due to an outstanding request can be revealed in both requests and responses. The final part of the sentence I can't understand. I wonder if there was a further sentence which was damaged and joined to this previous sentence. 12. Application Specific Usage It would be wise to mark this section as non-normative: Following are possible application-specific usages of History-Info. and we could add: See also the example call flows in Appendix B. Dale From dworley@avaya.com Thu Apr 19 19:35:21 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 516E621F84D8 for ; Thu, 19 Apr 2012 19:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.267 X-Spam-Level: X-Spam-Status: No, score=-103.267 tagged_above=-999 required=5 tests=[AWL=0.332, 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 j9PgPD6H9lOY for ; Thu, 19 Apr 2012 19:35:18 -0700 (PDT) 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 8F07421F84D6 for ; Thu, 19 Apr 2012 19:35:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF3KkE/GmAcF/2dsb2JhbABDsUyBB4IQEhUTLSQBFSlCJwQTCBqHagOZMoQanSaKbYUXYwSXAoUEiieDA4E5 X-IronPort-AV: E=Sophos;i="4.75,450,1330923600"; d="scan'208";a="343364468" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 19 Apr 2012 22:34:58 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Apr 2012 22:33:04 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Thu, 19 Apr 2012 22:35:16 -0400 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Thu, 19 Apr 2012 22:34:10 -0400 Thread-Topic: Comments on draft-ietf-sipcore-rfc4244bis-07 - substantival questions Thread-Index: AQHNHp43C0fa2Nnqz0qXnO3bNB4+Fg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-07 - substantival questions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 02:35:21 -0000 Here are a few questions about how 4244bis operates in certain situations. They may have been discussed already. If so, I hope that they have straightforward answers (which would show that the mechanism is clean and thought through). I. Numbering of gaps When an entity receives a request, it checks to see whether the last hi-entry matches the request-URI, and if not, adds an hi-entry to document the difference: 6. Missing entity: If the request clearly has a gap in the hi-entry (e.g. by evaluating via header to the existing request history to see if it traversed a domain which doesn't exist in History-Info header field.), the entity adding an hi-entry MUST add an index a digit of "0" to the current index prior to adding appropriate index for the action to be taken. If the index of the last hi- entry in the request received was 1.1.2 and there was a missing hi-entry and the request was being forwarded to the next hop, the resulting index will be 1.1.2.0.1. However, if in the un-logged processing of the request, the request forked, the two forks can then receive hi-entries with the *same* gap-indicating hi-index. These hi-entries can be carried upstream in responses and accumulate in the cache at some point upstream of the gap, resulting in two entries in the cache with the same hi-index. Modifying the example in Figure 1, assume that biloxi.example.com does not understand H-I. If I understand the details correctly, Bob@pc and Bob@phone will independently create hi-entries with hi-index 1.1.0. The two entries will be put into the cache at atlanta.exmple.com: Alice atlanta.example.com biloxi.example.com Bob@pc Bob@phone | | | | | | INVITE sip:bob@biloxi.example.com;p=3Dx | | |--------------->| | | | | Supported: histinfo | | | | | | | | | | INVITE sip:bob@biloxi.example.com;p=3Dx | | |--------------->| | | | History-Info: ;index=3D1 | | History-Info: ;np=3D1;index=3D1.1 | | | | | | | | INVITE sip:bob@192.0.2.3| | | |--------------->| | | History-Info: ;index=3D1 | | History-Info: ;np=3D1;index=3D1.1 | | | | | | As modified by Bob@pc due to section 9.1: | | | History-Info: ;index=3D1 | | History-Info: ;np=3D1;index=3D1.1 | History-Info: ;index=3D1.1.0 | | | | | | | | | | INVITE sip:bob@192.0.2.7| | | |-------------------------->| | History-Info: ;index=3D1 | History-Info: ;np=3D1;index=3D1.1 | | | | | | As modified by Bob@phone due to section 9.1: | | | History-Info: ;index=3D1 | | History-Info: ;np=3D1;index=3D1.1 | History-Info: ;index=3D1.1.0 | | | | | 4xx | | | | |<---------------| | | History-Info: ;index=3D1 | | History-Info: ;np=3D1;index=3D1.1 | History-Info: ;index=3D1.1.0 | | | | | | | | | 4xx | | | | |<---------------| | | | History-Info: ;index=3D1 | | History-Info: ;np=3D1;index=3D1.1 | History-Info: ;index=3D1.1.0 | | | | | | | | | | 200 | | | | |<--------------------------| | History-Info: ;index=3D1 | | History-Info: ;np=3D1;index=3D1.1 | History-Info: ;index=3D1.1.0 | | | | | | | | 200 | | | | |<---------------| | | | | History-Info: ;index=3D1 | | History-Info: ;np=3D1;index=3D1.1 | History-Info: ;index=3D1= .1.0 | History-Info: ;index=3D1.1.0 | | | | | | | | ACK | | | | |--------------->| ACK | | | | |--------------->| ACK | | | | |--------------->| | One way to avoid this problem is to add a random number after the "0", so the hi-entries created by the two UASs are (probably) different: History-Info: ;index=3D1.1.0.42949 History-Info: ;index=3D1.1.0.34317 To do this consistently and statelessly, one can hash the branch parameter of the topmost Via of the incoming request, extract 16 bits and add 1. By the Birthday Paradox, using 16 bits for the number, twenty forks can be accommodated with a low probability (0.3%) of collision. With this change, the final response would have this H-I: History-Info: ;index=3D1 History-Info: ;np=3D1;index=3D1.1 History-Info: ;index=3D1.1.0.34317 History-Info: ;index=3D1.1= .0.42949 This approach implies that H-I processing must allow index values of at least 65537; otherwise 100 would suffice in practice and the limit would not need to be specified. II. Reason headers added by processing provisional responses Looking at the example in section B.1 ... I don't see what I need, which is the H-I from the 180 Ringing response or the 200 OK response which is sent to Alice. It would be useful to have those shown. But based on section 10.2: If the SIP response does not contain a Reason header field, the SIP entity MUST include a Reason header field, containing the SIP Response Code, in the "headers" component of the hi-targeted-to-uri in the last hi-entry added to the cache, unless the hi-targeted-to-uri is a Tel-URI. there must be a "Reason=3DSIP%3Bcause%3D180" attached to the URI in hi-entry 1.2 because request 1.2 had a 180 response. I suspect that my error is that the above rule is only intended to be applied for (non-2xx) *final* responses. III. What is added to "Reason" elements? What gets added to "Reason" elements is: - "Reason" header values received in responses - SIP (final) failure response codes, if the response did not have a "Reason" header value Have we deliberately excluded "SIP 2xx" reason values and SIP response codes if an explicit Reason was provided? At first glance, it seems to me that a SIP failure final response code is always useful to know, even if there was an accompanying Reason value. But perhaps brevity is more valuable. IV. Locating the hi-entry corresponding to a message By the algorithms, in a request, the final hi-entry corresponds to the request and shows the request's position in the forking structure. (Or rather, it will correspond if all SIP entities support H-I.) But there is no such correspondence in a response, because a response can carry hi-entries from responses to requests generated after the request that generated the response. As a simple case, a 4xx response with History-Info: ;index=3D1 History-Info: ;index=3D1.1 History-Info: ;index=3D1= .2 could have ultimately been generated by either sip:bob@192.0.2.3 or sip:bob@10.11.12.13; there is no way to distinguish the two cases. There is no harm in this as long as we don't need the recipient of a response to be able to determine the ultimate source of a response. ---------------------------------------------------------------------------= ---------- That is the last of my review comments. Now I have to respond to the authors' comments on my review comments. Dale From saul@ag-projects.com Fri Apr 20 01:04:42 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2E521F8793 for ; Fri, 20 Apr 2012 01:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] 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 kMv39-t-NsVJ for ; Fri, 20 Apr 2012 01:04:42 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B397021F878E for ; Fri, 20 Apr 2012 01:04:41 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 2DA78B019E; Fri, 20 Apr 2012 10:04:38 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 5F195B019B; Fri, 20 Apr 2012 10:04:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> Date: Fri, 20 Apr 2012 10:04:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <436967A4-20DC-42A6-9BA2-578155B55FD9@ag-projects.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1084) Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 08:04:42 -0000 Hi Partha, On Apr 20, 2012, at 2:39 AM, Ravindran, Parthasarathi wrote: > Hi Inaki, >=20 > There are only two options which I could think of forward for this = draft >=20 > 1) As I earlier mentioned, Websocket transport works well only in = specific SIP topology and not in all topology as it is not capable of = supporting UDP/TCP transport. In case the draft is only going to specify = transport, then SIP entities support this draft has to have compliance = with RFC 3261 (UDP, TCP transport) as well and particularly you have to = mention how Javascript based SIP stack will compliance with RFC 3261. >=20 SIP over UDP also doesn't work on all topologies, just think about NAT. = IMO this draft should not target at using SIP in web browsers using = JavaScript, it should just define a new transport for the SIP protocol, = which is exactly what it does. There are, indeed, inherent limitations = when using SIP in a web browser, but these limitations are imposed by = the WebSocket API, *not* by this draft. Also note that there is no "IETF police", if I would implement this = draft for using a SIP client within a browser I would not implement UDP = or TCP support whatsoever, because they can't be used *in a browser*. = Sue me :-) > 2) Alternative is to specify SIP topology requirement wherein = websocket really applies. Include the related header like record-route & = path with the detail information where these headers are mandated. >=20 > IMHO, the current draft is not clear enough about SIP over Websocket = transport usage. >=20 I fail to understand what is not clear about it. Of course WebSockets = are used in browsers nearly 100% of the time, but this draft doesn't = restrict itself to that model. You could write a desktop SIP client = using WebSocket as a transport, and you could listen for incoming = connections since limitations such as those in web browsers wouldn't = apply. So, please, can you clarify *what* is it not clear about it? Thanks and regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From pravindran@sonusnet.com Fri Apr 20 01:59:06 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FA821F86A3 for ; Fri, 20 Apr 2012 01:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.353 X-Spam-Level: X-Spam-Status: No, score=-6.353 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 a6dmPEeYddmF for ; Fri, 20 Apr 2012 01:59:05 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id 11F3521F8568 for ; Fri, 20 Apr 2012 01:59:04 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKT5ElVkqoQ+1cRPs4jGxjBdxQRLEyxI+x@postini.com; Fri, 20 Apr 2012 01:59:05 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 20 Apr 2012 04:59:36 -0400 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.0355.002; Fri, 20 Apr 2012 14:28:55 +0530 From: "Ravindran, Parthasarathi" To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: AQHNHSsWQiKr/IZJokCfX43Mp6RbG5agJJrA//+unYCAAGacsIAAFBwAgABihBD//7B5AIAABfgAgAD3fzCAAI6cAIAA8TmAgAAjs4CAAGh4gA== Date: Fri, 20 Apr 2012 08:58:55 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E2289A3@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <436967A4-20DC-42A6-9BA2-578155B55FD9@ag-projects.com> In-Reply-To: <436967A4-20DC-42A6-9BA2-578155B55FD9@ag-projects.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 08:59:06 -0000 Saul, My reading of your statement "There are, indeed, inherent limitations when = using SIP in a web browser, but these limitations are imposed by the WebSoc= ket API, *not* by this draft." is that websocket does not qualify as a tran= sport for SIP as it is not possible to meet RFC 3261 requirement. NAT is not SIP endpoint issue but it is a network issue. All NAT are not co= nsidered as part of RFC 3261 design but it is resolved as part of Managing = Client-Initiated Connections in the Session Initiation Protocol (SIP) RFC (= 5626).=20 Thanks Partha Note: AFAIK, NAT issue in SIP is one of the reason for not selecting SIP as= part of signaling/transport protocol in RTCWeb. >-----Original Message----- >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] >Sent: Friday, April 20, 2012 1:35 PM >To: Ravindran, Parthasarathi >Cc: I=F1aki Baz Castillo; sipcore@ietf.org >Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible >in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip- >websocket-02] > >Hi Partha, > >On Apr 20, 2012, at 2:39 AM, Ravindran, Parthasarathi wrote: > >> Hi Inaki, >> >> There are only two options which I could think of forward for this >draft >> >> 1) As I earlier mentioned, Websocket transport works well only in >specific SIP topology and not in all topology as it is not capable of >supporting UDP/TCP transport. In case the draft is only going to specify >transport, then SIP entities support this draft has to have compliance >with RFC 3261 (UDP, TCP transport) as well and particularly you have to >mention how Javascript based SIP stack will compliance with RFC 3261. >> > >SIP over UDP also doesn't work on all topologies, just think about NAT. >IMO this draft should not target at using SIP in web browsers using >JavaScript, it should just define a new transport for the SIP protocol, >which is exactly what it does. There are, indeed, inherent limitations >when using SIP in a web browser, but these limitations are imposed by >the WebSocket API, *not* by this draft. > >Also note that there is no "IETF police", if I would implement this >draft for using a SIP client within a browser I would not implement UDP >or TCP support whatsoever, because they can't be used *in a browser*. >Sue me :-) > >> 2) Alternative is to specify SIP topology requirement wherein >websocket really applies. Include the related header like record-route & >path with the detail information where these headers are mandated. >> >> IMHO, the current draft is not clear enough about SIP over Websocket >transport usage. >> > >I fail to understand what is not clear about it. Of course WebSockets >are used in browsers nearly 100% of the time, but this draft doesn't >restrict itself to that model. You could write a desktop SIP client >using WebSocket as a transport, and you could listen for incoming >connections since limitations such as those in web browsers wouldn't >apply. So, please, can you clarify *what* is it not clear about it? > > >Thanks and regards, > >-- >Sa=FAl Ibarra Corretg=E9 >AG Projects > > From christer.holmberg@ericsson.com Fri Apr 20 02:01:47 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C9F21F8730 for ; Fri, 20 Apr 2012 02:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 Dn+QaVFtWORV for ; Fri, 20 Apr 2012 02:01:46 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id CCE6021F8568 for ; Fri, 20 Apr 2012 02:01:45 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-7b-4f9125f87850 Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 56.4F.26681.8F5219F4; Fri, 20 Apr 2012 11:01:44 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 20 Apr 2012 11:01:44 +0200 From: Christer Holmberg To: "Ravindran, Parthasarathi" , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Date: Fri, 20 Apr 2012 11:01:42 +0200 Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: AQHNHSsWQiKr/IZJokCfX43Mp6RbG5agJJrA//+unYCAAGacsIAAFBwAgABihBD//7B5AIAABfgAgAD3fzCAAI6cAIAA8TmAgAAjs4CAAGh4gIAAA2+Q Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C42E5A3C3@ESESSCMS0356.eemea.ericsson.se> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <436967A4-20DC-42A6-9BA2-578155B55FD9@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E2289A3@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E2289A3@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 09:01:47 -0000 Why not write a separate draft, which updates 3261 by saying that all trans= ports are optional... That's how the real world looks, anyway. Regards, Christer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Ravindran, Parthasarathi Sent: 20. huhtikuuta 2012 11:59 To: Sa=FAl Ibarra Corretg=E9 Cc: I=F1aki Baz Castillo; sipcore@ietf.org Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in = Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocke= t-02] Saul, My reading of your statement "There are, indeed, inherent limitations when = using SIP in a web browser, but these limitations are imposed by the WebSoc= ket API, *not* by this draft." is that websocket does not qualify as a tran= sport for SIP as it is not possible to meet RFC 3261 requirement. NAT is not SIP endpoint issue but it is a network issue. All NAT are not co= nsidered as part of RFC 3261 design but it is resolved as part of Managing = Client-Initiated Connections in the Session Initiation Protocol (SIP) RFC (= 5626).=20 Thanks Partha Note: AFAIK, NAT issue in SIP is one of the reason for not selecting SIP as= part of signaling/transport protocol in RTCWeb. >-----Original Message----- >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] >Sent: Friday, April 20, 2012 1:35 PM >To: Ravindran, Parthasarathi >Cc: I=F1aki Baz Castillo; sipcore@ietf.org >Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible=20 >in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-=20 >websocket-02] > >Hi Partha, > >On Apr 20, 2012, at 2:39 AM, Ravindran, Parthasarathi wrote: > >> Hi Inaki, >> >> There are only two options which I could think of forward for this >draft >> >> 1) As I earlier mentioned, Websocket transport works well only in >specific SIP topology and not in all topology as it is not capable of=20 >supporting UDP/TCP transport. In case the draft is only going to=20 >specify transport, then SIP entities support this draft has to have=20 >compliance with RFC 3261 (UDP, TCP transport) as well and particularly=20 >you have to mention how Javascript based SIP stack will compliance with RF= C 3261. >> > >SIP over UDP also doesn't work on all topologies, just think about NAT. >IMO this draft should not target at using SIP in web browsers using=20 >JavaScript, it should just define a new transport for the SIP protocol,=20 >which is exactly what it does. There are, indeed, inherent limitations=20 >when using SIP in a web browser, but these limitations are imposed by=20 >the WebSocket API, *not* by this draft. > >Also note that there is no "IETF police", if I would implement this=20 >draft for using a SIP client within a browser I would not implement UDP=20 >or TCP support whatsoever, because they can't be used *in a browser*. >Sue me :-) > >> 2) Alternative is to specify SIP topology requirement wherein >websocket really applies. Include the related header like record-route=20 >& path with the detail information where these headers are mandated. >> >> IMHO, the current draft is not clear enough about SIP over Websocket >transport usage. >> > >I fail to understand what is not clear about it. Of course WebSockets=20 >are used in browsers nearly 100% of the time, but this draft doesn't=20 >restrict itself to that model. You could write a desktop SIP client=20 >using WebSocket as a transport, and you could listen for incoming=20 >connections since limitations such as those in web browsers wouldn't=20 >apply. So, please, can you clarify *what* is it not clear about it? > > >Thanks and regards, > >-- >Sa=FAl Ibarra Corretg=E9 >AG Projects > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From saul@ag-projects.com Fri Apr 20 02:18:44 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3B121F8769 for ; Fri, 20 Apr 2012 02:18:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] 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 4RedjuFpqz5M for ; Fri, 20 Apr 2012 02:18:44 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id EB88021F8768 for ; Fri, 20 Apr 2012 02:18:43 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 03A73B01B2; Fri, 20 Apr 2012 11:18:42 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 711ADB019C; Fri, 20 Apr 2012 11:18:42 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C42E5A3C3@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 20 Apr 2012 11:18:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8E2B8FB7-BBD2-4846-973B-26BFBAC844ED@ag-projects.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <436967A4-20DC-42A6-9BA2-578155B55FD9@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C 6C0E2289A3@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A3C3@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1084) Cc: "Ravindran, Parthasarathi" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 09:18:44 -0000 On Apr 20, 2012, at 11:01 AM, Christer Holmberg wrote: > Why not write a separate draft, which updates 3261 by saying that all = transports are optional... That's how the real world looks, anyway. >=20 +1 -- Sa=FAl Ibarra Corretg=E9 AG Projects From jmillan@aliax.net Fri Apr 20 02:48:19 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C699F21F8744 for ; Fri, 20 Apr 2012 02:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rsurQVo03H1 for ; Fri, 20 Apr 2012 02:48:18 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C4A4A21F8736 for ; Fri, 20 Apr 2012 02:48:18 -0700 (PDT) Received: by iazz13 with SMTP id z13so16080462iaz.31 for ; Fri, 20 Apr 2012 02:48:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=c4nBPUryj6V2ATds2YDC5eJeOLXAdQ+WyHAoPQ5Pn+g=; b=L5KNJ9ikERnOwVn70noqtXAK8Y+vTTX99zqvQgFI7Xqs7XJ1VZTGVUiuaOhemlhEsQ NWBbM5tvg7Gsxj6l9UxFILC2fS4srdgBZKDMqVhCYgCQge+c/kBbU9+kHDhXNUFkW5N4 ojNzoHNwikm1S1scmQpz02oRgLb2vxy1h3S2E76tV88od6SajfSL//OjFFGNnj8jNeFy WruGLJLizB2XQxf2Kk/zezy+MAtS+ybl86ZIGLpKB9aZ68Wvh+x7i8EDPdjYA5mKjuDe EP4OhvuNEkFlIqNsX9PDfw8Tv5waZIBaHqrIfMmexAkZPqb9yNuMAOkXQk5JZAvO9ZcX 4JvQ== MIME-Version: 1.0 Received: by 10.50.237.101 with SMTP id vb5mr12941343igc.15.1334915298343; Fri, 20 Apr 2012 02:48:18 -0700 (PDT) Received: by 10.231.123.17 with HTTP; Fri, 20 Apr 2012 02:48:18 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E2289A3@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <436967A4-20DC-42A6-9BA2-578155B55FD9@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E2289A3@inba-mail01.sonusnet.com> Date: Fri, 20 Apr 2012 11:48:18 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkyj1NvEPI5xVRH0bmnO7CskoXVCoeeJFWxCd3jqNYxz90wYHFxSvSlAQ5USILEicTzUxq6 Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , "sipcore@ietf.org" , =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 09:48:19 -0000 Hi Pharta, El d=EDa 20 de abril de 2012 10:58, Ravindran, Parthasarathi escribi=F3: > Saul, > > My reading of your statement "There are, indeed, inherent limitations whe= n using SIP in a web browser, but these limitations are imposed by the WebS= ocket API, *not* by this draft." is that websocket does not qualify as a tr= ansport for SIP as it is not possible to meet RFC 3261 requirement. > Please, have a look at the response given by Paul in this thread . http://www.ietf.org/mail-archive/web/sipcore/current/msg04802.html > NAT is not SIP endpoint issue but it is a network issue. All NAT are not = considered as part of RFC 3261 design but it is resolved as part of Managin= g Client-Initiated Connections in the Session Initiation Protocol (SIP) RFC= (5626). > > Thanks > Partha > > Note: AFAIK, NAT issue in SIP is one of the reason for not selecting SIP = as part of signaling/transport protocol in RTCWeb. > >>-----Original Message----- >>From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] >>Sent: Friday, April 20, 2012 1:35 PM >>To: Ravindran, Parthasarathi >>Cc: I=F1aki Baz Castillo; sipcore@ietf.org >>Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible >>in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip- >>websocket-02] >> >>Hi Partha, >> >>On Apr 20, 2012, at 2:39 AM, Ravindran, Parthasarathi wrote: >> >>> Hi Inaki, >>> >>> There are only two options which I could think of forward for this >>draft >>> >>> 1) As I earlier mentioned, Websocket transport works well only in >>specific SIP topology and not in all topology as it is not capable of >>supporting UDP/TCP transport. In case the draft is only going to specify >>transport, then SIP entities support this draft has to have compliance >>with RFC 3261 (UDP, TCP transport) as well and particularly you have to >>mention how Javascript based SIP stack will compliance with RFC 3261. >>> >> >>SIP over UDP also doesn't work on all topologies, just think about NAT. >>IMO this draft should not target at using SIP in web browsers using >>JavaScript, it should just define a new transport for the SIP protocol, >>which is exactly what it does. There are, indeed, inherent limitations >>when using SIP in a web browser, but these limitations are imposed by >>the WebSocket API, *not* by this draft. >> >>Also note that there is no "IETF police", if I would implement this >>draft for using a SIP client within a browser I would not implement UDP >>or TCP support whatsoever, because they can't be used *in a browser*. >>Sue me :-) >> >>> 2) Alternative is to specify SIP topology requirement wherein >>websocket really applies. Include the related header like record-route & >>path with the detail information where these headers are mandated. >>> >>> IMHO, the current draft is not clear enough about SIP over Websocket >>transport usage. >>> >> >>I fail to understand what is not clear about it. Of course WebSockets >>are used in browsers nearly 100% of the time, but this draft doesn't >>restrict itself to that model. You could write a desktop SIP client >>using WebSocket as a transport, and you could listen for incoming >>connections since limitations such as those in web browsers wouldn't >>apply. So, please, can you clarify *what* is it not clear about it? >> >> >>Thanks and regards, >> >>-- >>Sa=FAl Ibarra Corretg=E9 >>AG Projects >> >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From saul@ag-projects.com Fri Apr 20 03:11:33 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B185721F8546 for ; Fri, 20 Apr 2012 03:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] 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 S7OlGR7f8Yec for ; Fri, 20 Apr 2012 03:11:33 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 982CA21F8542 for ; Fri, 20 Apr 2012 03:11:31 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id F3E91B01A4; Fri, 20 Apr 2012 12:11:30 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 54255B019C; Fri, 20 Apr 2012 12:11:30 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E2289A3@inba-mail01.sonusnet.com> Date: Fri, 20 Apr 2012 12:11:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <64E5739E-ED99-4EDC-809A-0C8DA8485C7E@ag-projects.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <436967A4-20DC-42A6-9BA2-578155B55FD9@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C 6C0E2289A3@inba-mail01.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1084) Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 10:11:33 -0000 Partha, On Apr 20, 2012, at 10:58 AM, Ravindran, Parthasarathi wrote: > Saul, >=20 > My reading of your statement "There are, indeed, inherent limitations = when using SIP in a web browser, but these limitations are imposed by = the WebSocket API, *not* by this draft." is that websocket does not = qualify as a transport for SIP as it is not possible to meet RFC 3261 = requirement. >=20 Your reading is incorrect. The fact that *a device* be it a browser, a = calculator or a softphone is unable to use a specific transport due to = environment limitations doesn't render the transport unqualifiable. Again, this is not the "SIP transport for web browsers" draft. > NAT is not SIP endpoint issue but it is a network issue. All NAT are = not considered as part of RFC 3261 design but it is resolved as part of = Managing Client-Initiated Connections in the Session Initiation Protocol = (SIP) RFC (5626).=20 >=20 Web browser limitations are not a SIP endpoint issue either. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From shida@ntt-at.com Fri Apr 20 04:05:57 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F25321F854C for ; Fri, 20 Apr 2012 04:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.065 X-Spam-Level: X-Spam-Status: No, score=-102.065 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 RzitpSETQVnR for ; Fri, 20 Apr 2012 04:05:56 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF9621F853D for ; Fri, 20 Apr 2012 04:05:56 -0700 (PDT) Received: from [60.236.86.9] (port=60913 helo=[192.168.1.12]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SLBf0-0002qP-Ja; Fri, 20 Apr 2012 06:05:55 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Fri, 20 Apr 2012 20:05:52 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <34EB8104-E380-4E35-B3FA-08F8C80CD60F@ntt-at.com> References: To: "Worley, Dale R (Dale)" X-Mailer: Apple Mail (2.1257) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: flh1adm009.tky.mesh.ad.jp ([192.168.1.12]) [60.236.86.9]:60913 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-07 - sections 10.1 and 11-end X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 11:05:57 -0000 Hi Dale; Thanks again for your comments.=20 My comments inline.. On Apr 20, 2012, at 11:33 AM, Worley, Dale R (Dale) wrote: > Correction of my comments on 10.3: I proposed removing all of item 6: >=20 > 6. Missing entity: If the request clearly has a gap in the hi-entry > (e.g. by evaluating via header to the existing request history = to > see if it traversed a domain which doesn't exist in History-Info > header field.), the entity adding an hi-entry MUST add an index = a > digit of "0" to the current index prior to adding appropriate > index for the action to be taken. If the index of the last hi- > entry in the request received was 1.1.2 and there was a missing > hi-entry and the request was being forwarded to the next hop, = the > resulting index will be 1.1.2.0.1. >=20 > But I should have restricted it to removing the "condition", namely > "(e.g. by evaluating via header to the existing request history to see > if it traversed a domain which doesn't exist in History-Info header > field.)" Okay, that is more clear but I still see no harm in leaving it in 10.3. The text could reside in 9.2 but I personally think it provides more = uses=20 by having it in 10.3. =20 >=20 > 10.1.1. Indicating Privacy >=20 > In this case, the > intermediary MUST set a Privacy header field to a priv-value of > "history" and include the Privacy header field in the = hi-targeted-to- > uri, for each new hi-entry added by the intermediary, as the request > is retargeted within the domain for which the SIP entity is > responsible. Note, that the hi-entries that are added to a request > from the cache are excluded in this case since the appropriate > privacy was set for those hi-entries when they were originally added > to a request. The intermediary MUST NOT include any other priv- > values in this Privacy header field. >=20 > The phrasing here is awkward. I think this would be better: >=20 > In this case, the intermediary MUST construct a Privacy header > field with the single priv-value of "history" and include the > Privacy header field in the hi-targeted-to-uri, for each new > hi-entry created by the intermediary, as the request is retargeted > within the domain for which the SIP entity is responsible. > (Note that hi-entries that are added to a request > from the cache are not modified by this process.) Looks good.=20 >=20 > However, I'm uncertain of the phrase "is retargeted within the > domain". Does that mean retargeting outside the domain of interest > cannot have this process applied? Perhaps we want to leave the > determination to the intermediary, since it is doing the modification > on its own behalf. In that case, we would change the end of the > sentence to: Well, for requests that are retargeted outside the domain, if the=20 intermediary want privacy, it should anonymize the hi-entries=20 before retargeting outside the domain of interest but following=20 modification does leave room for intermediary to make a choice,=20 so I will use your suggestion with the following modification.=20 >=20 > ... for each new hi-entry created by the intermediary whose > hi-targeted-to-uri it wishes to privacy protect. >=20 > Finally, the terminator of the request may not want to reveal the >=20 > I think it would be more standard to say >=20 > A UAS may not want to reveal the >=20 > and replace "terminator" with "UAS" in the rest of the paragraph. DONE. >=20 > 10.1.2. Applying Privacy >=20 > When a request is retargeted to a URI associated with a domain for > which the SIP intermediary is not responsible or a response is > forwarded to a domain for which the SIP intermediary is not > responsible, a Privacy Service at the boundary of the domain applies >=20 > It would be shorter to say >=20 > When a SIP message is forwarded to a domain for which the SIP > intermediary is not responsible ... >=20 > I think that has the same effect. FIXED. >=20 > which a SIP intermediary is responsible, are anonymized by the >=20 > probably should be "which >>>the<<< SIP intermediary is responsible", > referring to the intermediary discussed in the first paragraph. >=20 FIXED. > URIs containing a domain of anonymous.invalid (e.g., > anonymous@anonymous.invalid). If there is a Privacy header field in >=20 > Strictly, that should be "sip:anonymous@anonymous.invalid" and/or > "sips:anonymous@anonymous.invalid". Perhaps it would be better to not > describe the URI at all but just refer to RFC 3323. However, the > algorithm requires that H-I processing can *recognize* entries that > have already been anonymized, so we have to add a condition: >=20 > The Privacy Service MUST change any hi-targeted-to-uris in >>>> these<<< hi-entries that have not been anonymized (evidenced by > their domain not being "anonymous.invalid") to anonymous URIs > containing a domain of "anonymous.invalid" as described in RFC 3323 > section 4.1. FIXED. >=20 > also: >=20 > If there is a Privacy header field in the "headers" component of > the hi-targeted-to-uri in >>>these<<< hi-entries(?), then the > Privacy header field value MUST be removed from the hi-entry. I think it is fine as is.=20 >=20 > Similarly in the next paragraph: >=20 > If there is not a Privacy header field in the message header of the > request or response that is being forwarded, but there is a Privacy > header field with a priv-value of "history" in the "headers" > component in any of the hi-targeted-uris in the hi-entries > associated with the domain for which a SIP intermediary is > responsible, then the Privacy Service MUST update those > hi-targeted-to-uris >>>as described above.<<< Any other priv-values > in the Privacy header field in the "headers" component of the > hi-targeted-to-uris in the hi-entries MUST be ignored. >>>> [Last sentence deleted, as it is included in the "as above" > prescription.]<<< >=20 > Maybe there is a better way to factor out the "anonymize and remove > Privacy" operation. >=20 > 11. Application Considerations >=20 > The SIP entity MUST determine if there are gaps in the indices. >=20 > This is strictly true, but I don't think it's the sense we want. > There is also the problem that the two types of "gap" are distinctly > different in what they reveal. Maybe something fuzzier like: >=20 > The SIP entity MUST be prepared to process effectively messages > whose hi-entries show evidence of "gaps", that is, situations that > reveal that not all of the forks of the request have been recorded > in the hi-entries. >=20 > Gaps are possible if the request is forwarded through > intermediaries that do not support the History-info header field and > are reflected by the existence of multiple hi-entries with an digit > of "0" e.g. "1.1.0.1". >=20 > Replace "digit" with "integer" as discussed before, and change "an", > or rather leave it as "an" because we're changing "digit" to integer. FIXED. >=20 > But "multiple" should be deleted. In particular, when a UAS receives > a request whose request-URI does not match the last hi-entry, it adds > a "gap" hi-entry, but since the UAS does not forward the request > onward, it does not add any further hi-entries with "0"s. But in this > case, the request *has* had a gap in H-I processing. >=20 > Gaps are also possible in the case of > parallel forking if there is an outstanding request at the time the > SIP entity sends a response as described in Section 9.4, in which > case the gap will not be visible as the branch responsible for the > gap wasn't on the path of the request received. >=20 > I think this sentence needs to be modified strongly: >=20 > Gaps are also possible in the case of > parallel forking if there is an outstanding request at the time the > SIP entity sends a >>>message<<<. >=20 FIXED. > A gap (missing branch) due to an outstanding request can be revealed > in both requests and responses. The final part of the sentence I > can't understand. I wonder if there was a further sentence which was > damaged and joined to this previous sentence. >=20 We were just trying to describe how there could be an index missing=20 not a "0" but a branch can start from 2 instead of 1 due to parallel = forking.=20 Many Thanks indeed for all of your suggestions and comments. Regards Shida > 12. Application Specific Usage >=20 > It would be wise to mark this section as non-normative: >=20 > Following are possible application-specific usages of History-Info. >=20 > and we could add: >=20 > See also the example call flows in Appendix B. >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nataraju.sip@gmail.com Fri Apr 20 04:09:30 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C193121F872E for ; Fri, 20 Apr 2012 04:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.131 X-Spam-Level: X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 RZokdsDJiMG5 for ; Fri, 20 Apr 2012 04:09:30 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDDD21F854C for ; Fri, 20 Apr 2012 04:09:29 -0700 (PDT) Received: by lagj5 with SMTP id j5so7930247lag.31 for ; Fri, 20 Apr 2012 04:09:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=PY8n+4eZ8EN+CzQuoagFnK5F1HaB4zta4Eazhk7K5gE=; b=JC5hqON4fbpzzpt9CyhQrHQAVSdmp5lt3ugsVuQLvBCn7O81EfOTfZ+0y5kjpyDnJs CZbnsPv2UMAoElTTU4FS2rJmlNTn6BtxyAW3RA8AbH/CLeWdWGGW/AspgiB3NNXOeaQI tcLEn08jCAW3wc1B+sj7LNKKyNRpIIQRFV8BEhJzEflSQX0C1Qt1q7y/RJknjXNgQd7A y3sOmhxX79MXyPlMW3E491rxoC7J91iE/xycV4JlDfXlCIpbwZkzYBAJtBLts0k6PJfb l8Yg5A50KzDp4uEfZdr1IlSMKOmg8Z2+D5Xc/gfuLx3bIXtnPF8fIfuFrm1hJIUdzlKM iorg== MIME-Version: 1.0 Received: by 10.152.128.201 with SMTP id nq9mr5479762lab.26.1334920168354; Fri, 20 Apr 2012 04:09:28 -0700 (PDT) Received: by 10.112.36.104 with HTTP; Fri, 20 Apr 2012 04:09:28 -0700 (PDT) In-Reply-To: <64E5739E-ED99-4EDC-809A-0C8DA8485C7E@ag-projects.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <436967A4-20DC-42A6-9BA2-578155B55FD9@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E2289A3@inba-mail01.sonusnet.com> <64E5739E-ED99-4EDC-809A-0C8DA8485C7E@ag-projects.com> Date: Fri, 20 Apr 2012 16:39:28 +0530 Message-ID: From: "Nataraju A.B" To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Content-Type: multipart/alternative; boundary=f46d042d059670326804be1a5241 Cc: "Ravindran, Parthasarathi" , =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 11:09:30 -0000 --f46d042d059670326804be1a5241 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Apr 20, 2012 at 3:41 PM, Sa=FAl Ibarra Corretg=E9 wrote: > Partha, > > On Apr 20, 2012, at 10:58 AM, Ravindran, Parthasarathi wrote: > > > Saul, > > > > My reading of your statement "There are, indeed, inherent limitations > when using SIP in a web browser, but these limitations are imposed by the > WebSocket API, *not* by this draft." is that websocket does not qualify a= s > a transport for SIP as it is not possible to meet RFC 3261 requirement. > > > > Your reading is incorrect. The fact that *a device* be it a browser, a > calculator or a softphone is unable to use a specific transport due to > environment limitations doesn't render the transport unqualifiable. > > Again, this is not the "SIP transport for web browsers" draft. > [ABN] If that is the case, then it is illogical to compare sip over sctp / sip over ws / sip over tcp as equivalent in some of the earlier mail threads. isn't it ??? > > > NAT is not SIP endpoint issue but it is a network issue. All NAT are no= t > considered as part of RFC 3261 design but it is resolved as part of > Managing Client-Initiated Connections in the Session Initiation Protocol > (SIP) RFC (5626). > > > > Web browser limitations are not a SIP endpoint issue either. > > > Regards, > > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --=20 Thanks, Nataraju A.B. --f46d042d059670326804be1a5241 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Apr 20, 2012 at 3:41 PM, Sa=FAl = Ibarra Corretg=E9 <saul@ag-projects.com> wrote:
Partha,

On Apr 20, 2012, at 10:58 AM, Ravindran, Parthasarathi wrote:

> Saul,
>
> My reading of your statement "There are, indeed, inherent limitat= ions when using SIP in a web browser, but these limitations are imposed by = the WebSocket API, *not* by this draft." is that websocket does not qu= alify as a transport for SIP as it is not possible to meet RFC 3261 require= ment.
>

Your reading is incorrect. The fact that *a device* be it a browser, = a calculator or a softphone is unable to use a specific transport due to en= vironment limitations doesn't render the transport unqualifiable.

Again, this is not the "SIP transport for web browsers" draft.

[ABN] If that is the case, then it is ill= ogical to compare sip over sctp / =A0sip over ws =A0/ sip over tcp as equiv= alent in some of the earlier mail threads. isn't it ???



> NAT is not SIP endpoint issue but it is a network issue. All NAT are n= ot considered as part of RFC 3261 design but it is resolved as part of Mana= ging Client-Initiated Connections in the Session Initiation Protocol (SIP) = RFC (5626).
>

Web browser limitations are not a SIP endpoint issue either.


Regards,

--
Sa=FAl Ibarra Corretg=E9
AG Projects



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



--
= Thanks,
Nataraju A.B.

--f46d042d059670326804be1a5241-- From ibc@aliax.net Fri Apr 20 04:57:07 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34FAC21F8757 for ; Fri, 20 Apr 2012 04:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, 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 ezMBczugl8nH for ; Fri, 20 Apr 2012 04:57:06 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 498C621F8759 for ; Fri, 20 Apr 2012 04:57:06 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7456129vbb.31 for ; Fri, 20 Apr 2012 04:57:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=gNzLxuP5QW++TbOQiJjS6nxqG0ouz+WQQtmFOHsoRgA=; b=iUnePLX88nlKjuL7EIEj6xiXyH7seJrVE+YUU1YLxAcLwFMhlyKaDZc7qP99S+XJwm 138srjCLZBfQcQIdlsrUARDWBLN9VTN/pb+xI+H+1VpFu0sL8VBTfsvyffDsEB9FBk5F rQ+iW2YwNcg/Gi+j9Ycx6EapIa+ewXvIN9ll2UhjkwiExOwv2858hD0g9OL9BUJNSuRN dqa0FIg1rJ+LoO/N6Dw6hbperS3/P3T8Rp+mwTfOZEDMi4jeUw9dIhYC0j3ZfdZfwr+t Ywkpobgabz6mb7bQ5n7P9fIm8vIlsYhOR1J6bhk+6b6AEcMuRlqoiwOnLdxMYtv6STMI d42Q== Received: by 10.220.49.66 with SMTP id u2mr4618800vcf.2.1334923025441; Fri, 20 Apr 2012 04:57:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Fri, 20 Apr 2012 04:56:45 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 20 Apr 2012 13:56:45 +0200 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmxUiHhkLj0nkmyB6o97pPoQcmcY5gJtIPmhHMBMQwCSQDl9Ov5QFwFF5XtISOm4w/s0RTE Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 11:57:07 -0000 Hi Partha, I would like to comment you that there are other technologies that allow coding applications to be executed in web browsers (apart from JavaScript), those are Flash, Java, SilverLight... I'm not an expert in them but I do know that some of them gives the developer access to the TCP/UDP stack of the host, so you are able to code a SIP TCP/UDP stack with them (in fact there are SIP TCP/UDP implementations running as Java applets). Those technologies (regardless they are proprietary or not) also implement, or will implement soon, a WebSocket stack so they can connect to WebSocket servers. This means that you can build a SIP TCP/UDP/WebSocket client and run it in a web browser. And of course, there are WebSocket libraries available for many languages (C, C++, Java, Ruby, Python, Perl...). Somebody could implement SIP over WebSocket (along with other transports such a TCP/UDP) and code a SIP client to run as a desktop application or smartphone app or whatever. Unfortunately you insist on "The WebSocket API" [1] which is a W3C specification that enables WebSocket support in web browsers to be managed via a JavaScript API. You assume that the "SIP WebSocket Transport" is for web browsers and, not just it, but also that it is for implementing a SIP stack in JavaScript language. Please check the draft again and realize that all the references to web browsers, JavaScript and "The WebSocket API" are just informative and not normative. The draft MUST NOT mention that a web browser + JavaScript "is not SIP compliant since it cannot run SIP over TCP/UDP". The draft just defines a SIP transport and does not assume not web browsers scenarios neither JavaScript usage, and as said above, there are more technologies for developing web applications. In the other side, the draft does not define a signaling mechanism for WebRTC. rtcweb WG specifications define the media transport (audio, video, data channel) for web based applications but does not mandate a signaling protocol between browsers and servers, neither it mandates that such a protocol should be managed via JavaScript or that it should be carried on top of HTTP or WebSocket (you could implement your custom signaling protocol via RTMP or TCP by using Flash, Java applet, SilverLight or whatever web technology, and then make use of the WebRTC stak of the browser for enabling audio/video in your web app). So, summarizing: a) Our draft does not assume web browsers scenario. b) The web browser scenario must not assume JavaScript and "The WebSocket API" only ingredients. c) The limitation you mean (not SIP TCP/UDP transport) just applies in "web browsers + JavaScript + The WebSocket API". That is a very specific scope the draft does NOT assume. Best regards. [1] "The WebSocket API": http://dev.w3.org/html5/websockets/ PS: About "mandating" Path stuff in the draft, you were are ready replied by me in a previous mail. Please consider reading it. 2012/4/20 Ravindran, Parthasarathi : > Hi Inaki, > > There are only two options which I could think of forward for this draft > > 1) As I earlier mentioned, Websocket transport works well only in specifi= c SIP topology and not in all topology as it is not capable of supporting U= DP/TCP transport. In case the draft is only going to specify transport, the= n SIP entities support this draft has to have compliance with RFC 3261 (UDP= , TCP transport) as well and particularly you have to mention how Javascrip= t based SIP stack will compliance with RFC 3261. > > 2) Alternative is to specify SIP topology requirement wherein websocket r= eally applies. Include the related header like record-route & path with the= detail information where these headers are mandated. > > IMHO, the current draft is not clear enough about SIP over Websocket tran= sport usage. > > Thanks > Partha --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Fri Apr 20 05:00:35 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D1A621F875A for ; Fri, 20 Apr 2012 05:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 jXZs9mrBxNmj for ; Fri, 20 Apr 2012 05:00:35 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 717A921F84A1 for ; Fri, 20 Apr 2012 05:00:34 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-76-4f914fe0b51d Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 48.C7.25560.1EF419F4; Fri, 20 Apr 2012 14:00:33 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 20 Apr 2012 14:00:32 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "Ravindran, Parthasarathi" Date: Fri, 20 Apr 2012 14:00:30 +0200 Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: Ac0e7LUHBivyvYNcQhKRYqvIBwQ1GAAAB8dg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 12:00:35 -0000 SGksDQoNCkluIG15IG9waW5pb24sIHRoZSBpc3N1ZSBpcyBub3Qgd2hldGhlciBvbmUgaGFzIGFj Y2VzcyB0byBVRFAvVENQIG9yIG5vdCAtIGJ1dCB0aGUgZmFjdCB0aGF0IGl0IHdvdWxkIGJlIHN0 dXBpZCBhbmQgY29tcGxleCBiZWluZyBtYW5kYXRlZCB0byBpbXBsZW1lbnQgc28gbWFueSBkaWZm ZXJlbnQgdHJhbnNwb3J0cy4NCg0KU28sIGFnYWluLCBsZXQncyBtYWtlIGV2ZXJ5IHRyYW5zcG9y dCBvcHRpb25hbCwgYW5kIHBlb3BsZSB3aWxsIHRoZW4gaW1wbGVtZW50IGJhc2VkIG9uIGN1c3Rv bWVyIHJlcXVpcmVtZW50cywgbmV0d29yayBlbnZpcm9ubWVudHMsIHBsYXRmb3JtIGNoYXJhY3Rl cmlzdGljcywgZXRjIGV0YyBldGMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEnDsWFraSBCYXogQ2FzdGlsbG8gW21haWx0bzpp YmNAYWxpYXgubmV0XSANClNlbnQ6IDIwLiBodWh0aWt1dXRhIDIwMTIgMTQ6NTcNClRvOiBSYXZp bmRyYW4sIFBhcnRoYXNhcmF0aGkNCkNjOiBDaHJpc3RlciBIb2xtYmVyZzsgc2lwY29yZUBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBTdGF0ZWxlc3Mgb3IgVHJhbnNhY3Rpb24gc3Rh dGVmdWwgcHJveHkgcG9zc2libGUgaW4gV2Vic29ja2V0IHRyYW5zcG9ydD8gW1JFOiBDYWxsIGZv ciBBZG9wdGlvbjogZHJhZnQtaWJjLXNpcGNvcmUtc2lwLXdlYnNvY2tldC0wMl0NCg0KSGkgUGFy dGhhLA0KDQpJIHdvdWxkIGxpa2UgdG8gY29tbWVudCB5b3UgdGhhdCB0aGVyZSBhcmUgb3RoZXIg dGVjaG5vbG9naWVzIHRoYXQgYWxsb3cgY29kaW5nIGFwcGxpY2F0aW9ucyB0byBiZSBleGVjdXRl ZCBpbiB3ZWIgYnJvd3NlcnMgKGFwYXJ0IGZyb20gSmF2YVNjcmlwdCksIHRob3NlIGFyZSBGbGFz aCwgSmF2YSwgU2lsdmVyTGlnaHQuLi4NCg0KSSdtIG5vdCBhbiBleHBlcnQgaW4gdGhlbSBidXQg SSBkbyBrbm93IHRoYXQgc29tZSBvZiB0aGVtIGdpdmVzIHRoZSBkZXZlbG9wZXIgYWNjZXNzIHRv IHRoZSBUQ1AvVURQIHN0YWNrIG9mIHRoZSBob3N0LCBzbyB5b3UgYXJlIGFibGUgdG8gY29kZSBh IFNJUCBUQ1AvVURQIHN0YWNrIHdpdGggdGhlbSAoaW4gZmFjdCB0aGVyZSBhcmUgU0lQIFRDUC9V RFAgaW1wbGVtZW50YXRpb25zIHJ1bm5pbmcgYXMgSmF2YSBhcHBsZXRzKS4gVGhvc2UgdGVjaG5v bG9naWVzIChyZWdhcmRsZXNzIHRoZXkgYXJlIHByb3ByaWV0YXJ5IG9yIG5vdCkgYWxzbyBpbXBs ZW1lbnQsIG9yIHdpbGwgaW1wbGVtZW50IHNvb24sIGEgV2ViU29ja2V0IHN0YWNrIHNvIHRoZXkg Y2FuIGNvbm5lY3QgdG8gV2ViU29ja2V0IHNlcnZlcnMuDQoNClRoaXMgbWVhbnMgdGhhdCB5b3Ug Y2FuIGJ1aWxkIGEgU0lQIFRDUC9VRFAvV2ViU29ja2V0IGNsaWVudCBhbmQgcnVuIGl0IGluIGEg d2ViIGJyb3dzZXIuDQoNCkFuZCBvZiBjb3Vyc2UsIHRoZXJlIGFyZSBXZWJTb2NrZXQgbGlicmFy aWVzIGF2YWlsYWJsZSBmb3IgbWFueSBsYW5ndWFnZXMgKEMsIEMrKywgSmF2YSwgUnVieSwgUHl0 aG9uLCBQZXJsLi4uKS4gU29tZWJvZHkgY291bGQgaW1wbGVtZW50IFNJUCBvdmVyIFdlYlNvY2tl dCAoYWxvbmcgd2l0aCBvdGhlciB0cmFuc3BvcnRzIHN1Y2ggYQ0KVENQL1VEUCkgYW5kIGNvZGUg YSBTSVAgY2xpZW50IHRvIHJ1biBhcyBhIGRlc2t0b3AgYXBwbGljYXRpb24gb3Igc21hcnRwaG9u ZSBhcHAgb3Igd2hhdGV2ZXIuDQoNCg0KVW5mb3J0dW5hdGVseSB5b3UgaW5zaXN0IG9uICJUaGUg V2ViU29ja2V0IEFQSSIgWzFdIHdoaWNoIGlzIGEgVzNDIHNwZWNpZmljYXRpb24gdGhhdCBlbmFi bGVzIFdlYlNvY2tldCBzdXBwb3J0IGluIHdlYiBicm93c2VycyB0byBiZSBtYW5hZ2VkIHZpYSBh IEphdmFTY3JpcHQgQVBJLiBZb3UgYXNzdW1lIHRoYXQgdGhlICJTSVAgV2ViU29ja2V0IFRyYW5z cG9ydCIgaXMgZm9yIHdlYiBicm93c2VycyBhbmQsIG5vdCBqdXN0IGl0LCBidXQgYWxzbyB0aGF0 IGl0IGlzIGZvciBpbXBsZW1lbnRpbmcgYSBTSVAgc3RhY2sgaW4gSmF2YVNjcmlwdCBsYW5ndWFn ZS4gUGxlYXNlIGNoZWNrIHRoZSBkcmFmdCBhZ2FpbiBhbmQgcmVhbGl6ZSB0aGF0IGFsbCB0aGUg cmVmZXJlbmNlcyB0byB3ZWIgYnJvd3NlcnMsIEphdmFTY3JpcHQgYW5kICJUaGUgV2ViU29ja2V0 IEFQSSIgYXJlIGp1c3QgaW5mb3JtYXRpdmUgYW5kIG5vdCBub3JtYXRpdmUuDQoNClRoZSBkcmFm dCBNVVNUIE5PVCBtZW50aW9uIHRoYXQgYSB3ZWIgYnJvd3NlciArIEphdmFTY3JpcHQgImlzIG5v dCBTSVAgY29tcGxpYW50IHNpbmNlIGl0IGNhbm5vdCBydW4gU0lQIG92ZXIgVENQL1VEUCIuIFRo ZSBkcmFmdCBqdXN0IGRlZmluZXMgYSBTSVAgdHJhbnNwb3J0IGFuZCBkb2VzIG5vdCBhc3N1bWUg bm90IHdlYiBicm93c2VycyBzY2VuYXJpb3MgbmVpdGhlciBKYXZhU2NyaXB0IHVzYWdlLCBhbmQg YXMgc2FpZCBhYm92ZSwgdGhlcmUgYXJlIG1vcmUgdGVjaG5vbG9naWVzIGZvciBkZXZlbG9waW5n IHdlYiBhcHBsaWNhdGlvbnMuDQoNCg0KSW4gdGhlIG90aGVyIHNpZGUsIHRoZSBkcmFmdCBkb2Vz IG5vdCBkZWZpbmUgYSBzaWduYWxpbmcgbWVjaGFuaXNtIGZvciBXZWJSVEMuIHJ0Y3dlYiBXRyBz cGVjaWZpY2F0aW9ucyBkZWZpbmUgdGhlIG1lZGlhIHRyYW5zcG9ydCAoYXVkaW8sIHZpZGVvLCBk YXRhIGNoYW5uZWwpIGZvciB3ZWIgYmFzZWQgYXBwbGljYXRpb25zIGJ1dCBkb2VzIG5vdCBtYW5k YXRlIGEgc2lnbmFsaW5nIHByb3RvY29sIGJldHdlZW4gYnJvd3NlcnMgYW5kIHNlcnZlcnMsIG5l aXRoZXIgaXQgbWFuZGF0ZXMgdGhhdCBzdWNoIGEgcHJvdG9jb2wgc2hvdWxkIGJlIG1hbmFnZWQg dmlhIEphdmFTY3JpcHQgb3IgdGhhdCBpdCBzaG91bGQgYmUgY2FycmllZCBvbiB0b3Agb2YgSFRU UCBvciBXZWJTb2NrZXQgKHlvdSBjb3VsZCBpbXBsZW1lbnQgeW91ciBjdXN0b20gc2lnbmFsaW5n IHByb3RvY29sIHZpYSBSVE1QIG9yIFRDUCBieSB1c2luZyBGbGFzaCwgSmF2YSBhcHBsZXQsIFNp bHZlckxpZ2h0IG9yIHdoYXRldmVyIHdlYiB0ZWNobm9sb2d5LCBhbmQgdGhlbiBtYWtlIHVzZSBv ZiB0aGUgV2ViUlRDIHN0YWsgb2YgdGhlIGJyb3dzZXIgZm9yIGVuYWJsaW5nIGF1ZGlvL3ZpZGVv IGluIHlvdXIgd2ViIGFwcCkuDQoNCg0KU28sIHN1bW1hcml6aW5nOg0KDQphKSBPdXIgZHJhZnQg ZG9lcyBub3QgYXNzdW1lIHdlYiBicm93c2VycyBzY2VuYXJpby4NCg0KYikgVGhlIHdlYiBicm93 c2VyIHNjZW5hcmlvIG11c3Qgbm90IGFzc3VtZSBKYXZhU2NyaXB0IGFuZCAiVGhlIFdlYlNvY2tl dCBBUEkiIG9ubHkgaW5ncmVkaWVudHMuDQoNCmMpIFRoZSBsaW1pdGF0aW9uIHlvdSBtZWFuIChu b3QgU0lQIFRDUC9VRFAgdHJhbnNwb3J0KSBqdXN0IGFwcGxpZXMgaW4gIndlYiBicm93c2VycyAr IEphdmFTY3JpcHQgKyBUaGUgV2ViU29ja2V0IEFQSSIuIFRoYXQgaXMgYSB2ZXJ5IHNwZWNpZmlj IHNjb3BlIHRoZSBkcmFmdCBkb2VzIE5PVCBhc3N1bWUuDQoNCg0KDQpCZXN0IHJlZ2FyZHMuDQoN Cg0KDQpbMV0gIlRoZSBXZWJTb2NrZXQgQVBJIjogaHR0cDovL2Rldi53My5vcmcvaHRtbDUvd2Vi c29ja2V0cy8NCg0KDQpQUzogQWJvdXQgIm1hbmRhdGluZyIgUGF0aCBzdHVmZiBpbiB0aGUgZHJh ZnQsIHlvdSB3ZXJlIGFyZSByZWFkeSByZXBsaWVkIGJ5IG1lIGluIGEgcHJldmlvdXMgbWFpbC4g UGxlYXNlIGNvbnNpZGVyIHJlYWRpbmcgaXQuDQoNCg0KDQoNCg0KDQoNCjIwMTIvNC8yMCBSYXZp bmRyYW4sIFBhcnRoYXNhcmF0aGkgPHByYXZpbmRyYW5Ac29udXNuZXQuY29tPjoNCj4gSGkgSW5h a2ksDQo+DQo+IFRoZXJlIGFyZSBvbmx5IHR3byBvcHRpb25zIHdoaWNoIEkgY291bGQgdGhpbmsg b2YgZm9yd2FyZCBmb3IgdGhpcyANCj4gZHJhZnQNCj4NCj4gMSkgQXMgSSBlYXJsaWVyIG1lbnRp b25lZCwgV2Vic29ja2V0IHRyYW5zcG9ydCB3b3JrcyB3ZWxsIG9ubHkgaW4gc3BlY2lmaWMgU0lQ IHRvcG9sb2d5IGFuZCBub3QgaW4gYWxsIHRvcG9sb2d5IGFzIGl0IGlzIG5vdCBjYXBhYmxlIG9m IHN1cHBvcnRpbmcgVURQL1RDUCB0cmFuc3BvcnQuIEluIGNhc2UgdGhlIGRyYWZ0IGlzIG9ubHkg Z29pbmcgdG8gc3BlY2lmeSB0cmFuc3BvcnQsIHRoZW4gU0lQIGVudGl0aWVzIHN1cHBvcnQgdGhp cyBkcmFmdCBoYXMgdG8gaGF2ZSBjb21wbGlhbmNlIHdpdGggUkZDIDMyNjEgKFVEUCwgVENQIHRy YW5zcG9ydCkgYXMgd2VsbCBhbmQgcGFydGljdWxhcmx5IHlvdSBoYXZlIHRvIG1lbnRpb24gaG93 IEphdmFzY3JpcHQgYmFzZWQgU0lQIHN0YWNrIHdpbGwgY29tcGxpYW5jZSB3aXRoIFJGQyAzMjYx Lg0KPg0KPiAyKSBBbHRlcm5hdGl2ZSBpcyB0byBzcGVjaWZ5IFNJUCB0b3BvbG9neSByZXF1aXJl bWVudCB3aGVyZWluIHdlYnNvY2tldCByZWFsbHkgYXBwbGllcy4gSW5jbHVkZSB0aGUgcmVsYXRl ZCBoZWFkZXIgbGlrZSByZWNvcmQtcm91dGUgJiBwYXRoIHdpdGggdGhlIGRldGFpbCBpbmZvcm1h dGlvbiB3aGVyZSB0aGVzZSBoZWFkZXJzIGFyZSBtYW5kYXRlZC4NCj4NCj4gSU1ITywgdGhlIGN1 cnJlbnQgZHJhZnQgaXMgbm90IGNsZWFyIGVub3VnaCBhYm91dCBTSVAgb3ZlciBXZWJzb2NrZXQg dHJhbnNwb3J0IHVzYWdlLg0KPg0KPiBUaGFua3MNCj4gUGFydGhhDQoNCg0KDQoNCi0tDQpJw7Fh a2kgQmF6IENhc3RpbGxvDQo8aWJjQGFsaWF4Lm5ldD4NCg== From kpfleming@digium.com Fri Apr 20 05:44:37 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BAA21F872F for ; Fri, 20 Apr 2012 05:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJz4bqvkSRmZ for ; Fri, 20 Apr 2012 05:44:36 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6D99B21F86DD for ; Fri, 20 Apr 2012 05:44:36 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SLDCV-0002BP-2R for sipcore@ietf.org; Fri, 20 Apr 2012 07:44:35 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 1873F1A2006 for ; Fri, 20 Apr 2012 07:44:35 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQsPP+SM9ezj for ; Fri, 20 Apr 2012 07:44:34 -0500 (CDT) Received: from [192.168.1.10] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 743DB1A2001 for ; Fri, 20 Apr 2012 07:44:34 -0500 (CDT) Message-ID: <4F915A2C.1080506@digium.com> Date: Fri, 20 Apr 2012 07:44:28 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 12:44:37 -0000 On 04/20/2012 07:00 AM, Christer Holmberg wrote: > Hi, > > In my opinion, the issue is not whether one has access to UDP/TCP or not - but the fact that it would be stupid and complex being mandated to implement so many different transports. > > So, again, let's make every transport optional, and people will then implement based on customer requirements, network environments, platform characteristics, etc etc etc. Let's just get this started... it's already relevant since SCTP has been defined as a transport for SIP. A UA that wants to solely use SCTP should be allowed to do that without being labeled non-compliant with RFC 3261. How would this work? Would this just be a two-page document updating that one small section of RFC 3261? -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From kpfleming@digium.com Fri Apr 20 05:47:38 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1473C21F8766 for ; Fri, 20 Apr 2012 05:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uo3KYtOf8R62 for ; Fri, 20 Apr 2012 05:47:37 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 596B621F86DE for ; Fri, 20 Apr 2012 05:47:37 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SLDFR-0002DA-3L for sipcore@ietf.org; Fri, 20 Apr 2012 07:47:37 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 152D01A2006 for ; Fri, 20 Apr 2012 07:47:37 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1frI+jFuzMK for ; Fri, 20 Apr 2012 07:47:36 -0500 (CDT) Received: from [192.168.1.10] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 941F41A2001 for ; Fri, 20 Apr 2012 07:47:36 -0500 (CDT) Message-ID: <4F915AE2.9010803@digium.com> Date: Fri, 20 Apr 2012 07:47:30 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <436967A4-20DC-42A6-9BA2-578155B55FD9@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E2289A3@inba-mail01.sonusnet .com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E2289A3@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 12:47:38 -0000 On 04/20/2012 03:58 AM, Ravindran, Parthasarathi wrote: > My reading of your statement "There are, indeed, inherent limitations when using SIP in a web browser, but these limitations are imposed by the WebSocket API, *not* by this draft." is that websocket does not qualify as a transport for SIP as it is not possible to meet RFC 3261 requirement. This statement is not supported by any facts. It's completely possible and practical to use WebSocket between two *non-web-browser* UAs, if there is value in doing so. In fact, I can already see value in softphones and hardphones supporting SIP over WebSocket (in addition to, or instead of, UDP and plain TCP). -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From christer.holmberg@ericsson.com Fri Apr 20 05:50:25 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCBCA21F873E for ; Fri, 20 Apr 2012 05:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.166 X-Spam-Level: X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 xTGB+tTZmLeT for ; Fri, 20 Apr 2012 05:50:25 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0205721F86DD for ; Fri, 20 Apr 2012 05:50:24 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-8b-4f915b8f7ab4 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 69.40.03534.F8B519F4; Fri, 20 Apr 2012 14:50:23 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Fri, 20 Apr 2012 14:50:23 +0200 From: Christer Holmberg To: "Kevin P. Fleming" , "sipcore@ietf.org" Date: Fri, 20 Apr 2012 14:50:21 +0200 Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: Ac0e81qdRxiuCXdgSiiO5g4zUTCq3gAAKkRw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> In-Reply-To: <4F915A2C.1080506@digium.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 12:50:26 -0000 Hi, >> In my opinion, the issue is not whether one has access to UDP/TCP or not= - but the fact that it would be stupid and complex being mandated to imple= ment so many different transports. >> >> So, again, let's make every transport optional, and people will then imp= lement based on customer requirements, network environments, platform chara= cteristics, etc etc etc. > > Let's just get this started... it's already relevant since SCTP has been = defined as a transport for SIP. A UA that wants to solely use SCTP should b= e allowed to do that without being labeled non-compliant with RFC 3261. > > How would this work? Would this just be a two-page document updating that= one small section of RFC 3261? Pretty much, yes :) Of course, in addition to the actual update there would need to be some jus= tification text. Regards, Christer From ibc@aliax.net Fri Apr 20 05:55:18 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AED21F86D9 for ; Fri, 20 Apr 2012 05:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.044, 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 oVR1zQMw6Dh4 for ; Fri, 20 Apr 2012 05:55:18 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EC3A121F86A8 for ; Fri, 20 Apr 2012 05:55:17 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7505172vbb.31 for ; Fri, 20 Apr 2012 05:55:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=BUQifBE3BEnc5hJlS6AEgsuRERXmeW7wvqTvEPI8sCQ=; b=CS+faaJKnGcFieYNJGRo25YsB11MGjKtPngjHDDkBjJL+M6r3Nbt7MP4XsuNPcf5CM NN8HDAuv+VxcJJmP8dLoBMdqecgCxKEUiJwaThCTE6YCRKxzhEEhnKIhR16C9CfzUEh2 mXZ/6fhxg2nrpi1InxbZFRwQMRUlVv3y6b/7GE7+jekbKzxLCFJw7ev7e16+iwoqekm3 BWAo4j6S0vjXrl+CWZwxe05DbnahVhGB5pzSjrrf3Os884RNd12mft+tEY/uRpi270vw xbn2sEuqlV55RSRIEAJUwbA2vXKokTBXbofRQ65ULpxmXqP1xlHjgbAIDNHnY7dwGz9N DK4g== Received: by 10.52.64.173 with SMTP id p13mr1616690vds.51.1334926515926; Fri, 20 Apr 2012 05:55:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Fri, 20 Apr 2012 05:54:55 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 20 Apr 2012 14:54:55 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkjGWH728SP3iHkcm6uP0BFWo3oVT05t/mPDMGCDkLqnv4p6Pxib/6kCcniVouiJ/vl/yR/ Cc: "sipcore@ietf.org" , "Kevin P. Fleming" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 12:55:19 -0000 2012/4/20 Christer Holmberg : >>> So, again, let's make every transport optional, and people will then im= plement based on customer requirements, network environments, platform char= acteristics, etc etc etc. >> >> Let's just get this started... it's already relevant since SCTP has been= defined as a transport for SIP. A UA that wants to solely use SCTP should = be allowed to do that without being labeled non-compliant with RFC 3261. >> >> How would this work? Would this just be a two-page document updating tha= t one small section of RFC 3261? > > Pretty much, yes :) > > Of course, in addition to the actual update there would need to be some j= ustification text. Hi, in a previous mail I suggested some points for such a new work. This future draft could address this topic by covering the following cases: - Scenarios in which just *secure* SIP transport is required (so UDP has no place). This could occur in local networks, providers networks or whatever. - Scenarios in which just a single transport can be used due to network topology (i.e. in Outbound topology in which UA's are behind different NAT's and connect to the same Edge Proxy using TCP or UDP, so they cannot receive requests via a different transport than the one they use to connect to their Outbound proxy). - Special cases in which it's clear that, given enviroment/plattform constrains, some implementations are not able to support SIP UDP/TCP transports. Basically such a draft could state that "in certain cases (such as those described above) a SIP entity MAY NOT implement UDP and/or TCP transports, being this an update to RFC 3261". IMHO just one page :) --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Fri Apr 20 06:05:08 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F299C21F86DE for ; Fri, 20 Apr 2012 06:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 VP5mW-TwE4sL for ; Fri, 20 Apr 2012 06:05:07 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D4E8821F86E0 for ; Fri, 20 Apr 2012 06:05:06 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-d7-4f915f010c79 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id BA.82.03534.10F519F4; Fri, 20 Apr 2012 15:05:06 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 20 Apr 2012 15:05:04 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Fri, 20 Apr 2012 15:05:03 +0200 Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: Ac0e9NbvAOOlwOysSH+x42CqHvyo2QAAVBbw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C42E5A63A@ESESSCMS0356.eemea.ericsson.se> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" , "Kevin P. Fleming" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 13:05:08 -0000 WW91IGNhbiB1c2UgSVBTZWMgdG8gZ2V0IHNlY3VyZSBTSVAgdHJhZmZpYyB3aXRoIFVEUCA6KQ0K DQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogScOxYWtpIEJheiBDYXN0aWxsbyBbbWFpbHRvOmliY0BhbGlheC5uZXRdIA0KU2VudDogMjAu IGh1aHRpa3V1dGEgMjAxMiAxNTo1NQ0KVG86IENocmlzdGVyIEhvbG1iZXJnDQpDYzogS2V2aW4g UC4gRmxlbWluZzsgc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBTdGF0 ZWxlc3Mgb3IgVHJhbnNhY3Rpb24gc3RhdGVmdWwgcHJveHkgcG9zc2libGUgaW4gV2Vic29ja2V0 IHRyYW5zcG9ydD8gW1JFOiBDYWxsIGZvciBBZG9wdGlvbjogZHJhZnQtaWJjLXNpcGNvcmUtc2lw LXdlYnNvY2tldC0wMl0NCg0KMjAxMi80LzIwIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20+Og0KPj4+IFNvLCBhZ2FpbiwgbGV0J3MgbWFrZSBldmVyeSB0 cmFuc3BvcnQgb3B0aW9uYWwsIGFuZCBwZW9wbGUgd2lsbCB0aGVuIGltcGxlbWVudCBiYXNlZCBv biBjdXN0b21lciByZXF1aXJlbWVudHMsIG5ldHdvcmsgZW52aXJvbm1lbnRzLCBwbGF0Zm9ybSBj aGFyYWN0ZXJpc3RpY3MsIGV0YyBldGMgZXRjLg0KPj4NCj4+IExldCdzIGp1c3QgZ2V0IHRoaXMg c3RhcnRlZC4uLiBpdCdzIGFscmVhZHkgcmVsZXZhbnQgc2luY2UgU0NUUCBoYXMgYmVlbiBkZWZp bmVkIGFzIGEgdHJhbnNwb3J0IGZvciBTSVAuIEEgVUEgdGhhdCB3YW50cyB0byBzb2xlbHkgdXNl IFNDVFAgc2hvdWxkIGJlIGFsbG93ZWQgdG8gZG8gdGhhdCB3aXRob3V0IGJlaW5nIGxhYmVsZWQg bm9uLWNvbXBsaWFudCB3aXRoIFJGQyAzMjYxLg0KPj4NCj4+IEhvdyB3b3VsZCB0aGlzIHdvcms/ IFdvdWxkIHRoaXMganVzdCBiZSBhIHR3by1wYWdlIGRvY3VtZW50IHVwZGF0aW5nIHRoYXQgb25l IHNtYWxsIHNlY3Rpb24gb2YgUkZDIDMyNjE/DQo+DQo+IFByZXR0eSBtdWNoLCB5ZXMgOikNCj4N Cj4gT2YgY291cnNlLCBpbiBhZGRpdGlvbiB0byB0aGUgYWN0dWFsIHVwZGF0ZSB0aGVyZSB3b3Vs ZCBuZWVkIHRvIGJlIHNvbWUganVzdGlmaWNhdGlvbiB0ZXh0Lg0KDQoNCkhpLCBpbiBhIHByZXZp b3VzIG1haWwgSSBzdWdnZXN0ZWQgc29tZSBwb2ludHMgZm9yIHN1Y2ggYSBuZXcgd29yay4NClRo aXMgZnV0dXJlIGRyYWZ0IGNvdWxkIGFkZHJlc3MgdGhpcyB0b3BpYyBieSBjb3ZlcmluZyB0aGUg Zm9sbG93aW5nDQpjYXNlczoNCg0KLSBTY2VuYXJpb3MgaW4gd2hpY2gganVzdCAqc2VjdXJlKiBT SVAgdHJhbnNwb3J0IGlzIHJlcXVpcmVkIChzbyBVRFAgaGFzIG5vIHBsYWNlKS4gVGhpcyBjb3Vs ZCBvY2N1ciBpbiBsb2NhbCBuZXR3b3JrcywgcHJvdmlkZXJzIG5ldHdvcmtzIG9yIHdoYXRldmVy Lg0KDQotIFNjZW5hcmlvcyBpbiB3aGljaCBqdXN0IGEgc2luZ2xlIHRyYW5zcG9ydCBjYW4gYmUg dXNlZCBkdWUgdG8gbmV0d29yayB0b3BvbG9neSAoaS5lLiBpbiBPdXRib3VuZCB0b3BvbG9neSBp biB3aGljaCBVQSdzIGFyZSBiZWhpbmQgZGlmZmVyZW50IE5BVCdzIGFuZCBjb25uZWN0IHRvIHRo ZSBzYW1lIEVkZ2UgUHJveHkgdXNpbmcgVENQIG9yIFVEUCwgc28gdGhleSBjYW5ub3QgcmVjZWl2 ZSByZXF1ZXN0cyB2aWEgYSBkaWZmZXJlbnQgdHJhbnNwb3J0IHRoYW4gdGhlIG9uZSB0aGV5IHVz ZSB0byBjb25uZWN0IHRvIHRoZWlyIE91dGJvdW5kIHByb3h5KS4NCg0KLSBTcGVjaWFsIGNhc2Vz IGluIHdoaWNoIGl0J3MgY2xlYXIgdGhhdCwgZ2l2ZW4gZW52aXJvbWVudC9wbGF0dGZvcm0gY29u c3RyYWlucywgc29tZSBpbXBsZW1lbnRhdGlvbnMgYXJlIG5vdCBhYmxlIHRvIHN1cHBvcnQgU0lQ IFVEUC9UQ1AgdHJhbnNwb3J0cy4NCg0KQmFzaWNhbGx5IHN1Y2ggYSBkcmFmdCBjb3VsZCBzdGF0 ZSB0aGF0ICJpbiBjZXJ0YWluIGNhc2VzIChzdWNoIGFzIHRob3NlIGRlc2NyaWJlZCBhYm92ZSkg YSBTSVAgZW50aXR5IE1BWSBOT1QgaW1wbGVtZW50IFVEUCBhbmQvb3IgVENQIHRyYW5zcG9ydHMs IGJlaW5nIHRoaXMgYW4gdXBkYXRlIHRvIFJGQyAzMjYxIi4NCg0KSU1ITyBqdXN0IG9uZSBwYWdl IDopDQoNCg0KLS0NCknDsWFraSBCYXogQ2FzdGlsbG8NCjxpYmNAYWxpYXgubmV0Pg0K From ibc@aliax.net Fri Apr 20 06:11:30 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5657121F873B for ; Fri, 20 Apr 2012 06:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 5P+1jBMISkS2 for ; Fri, 20 Apr 2012 06:11:25 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 97B7421F85F2 for ; Fri, 20 Apr 2012 06:11:25 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7520787vbb.31 for ; Fri, 20 Apr 2012 06:11:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=bdT/JmJrlG5kHMvlhlSDrB5G686nb9OMNOhSyyz90dc=; b=h7mUAe0HP5uC1VthB0C7QiMIZH3iR0rF+S0L94DJ9tsoSNayXrCSWDyMrd24hCUMaA Lb7AcJYcEbmzdEBiSfnfsqRFSX5YEPYNLit1aEAIipcNMwR1lp6t7R0AKjDkA5NkUnYR QG2SaRotMGSgaLWNgmHFVmRck7rQ+eCEzixSgr7NGUvzUW0rQ/opbS9nwbPISymfrxb+ c1IUWcgXNwTw32njt0Q/4yLuUFMjPN3DE4fx9IUYna5cmY1/Odq65lSQJ5WW/fZZura7 TTt9MQ1d5kCVzl9tIyF+vYK0+GkwB5z3Fju9zuNRjUVvy78+iFT0ap2lEZsrJACvWHau kJEA== MIME-Version: 1.0 Received: by 10.52.91.72 with SMTP id cc8mr4239549vdb.17.1334927485101; Fri, 20 Apr 2012 06:11:25 -0700 (PDT) Received: by 10.52.170.165 with HTTP; Fri, 20 Apr 2012 06:11:24 -0700 (PDT) Received: by 10.52.170.165 with HTTP; Fri, 20 Apr 2012 06:11:24 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C42E5A63A@ESESSCMS0356.eemea.ericsson.se> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A63A@ESESSCMS0356.eemea.ericsson.se> Date: Fri, 20 Apr 2012 15:11:24 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Christer Holmberg Content-Type: multipart/alternative; boundary=20cf307ca4ba8ce6b804be1c065f X-Gm-Message-State: ALoCoQkvFKs2e2VR9NWYOlGeM/9mjK+byGZYZs9QVxq8oU8pMvA/Vb4yXQBudcZQqE2NoV7Jadnp Cc: "sipcore@ietf.org" , "Kevin P. Fleming" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 13:11:30 -0000 --20cf307ca4ba8ce6b804be1c065f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rigth. Then let me add this scenario: - Scenarios in which large SIP messages are required so UDP is no valid. ;) El 20/04/2012 15:05, "Christer Holmberg" escribi=C3=B3: > You can use IPSec to get secure SIP traffic with UDP :) > > Regards, > > Christer > > -----Original Message----- > From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net] > Sent: 20. huhtikuuta 2012 15:55 > To: Christer Holmberg > Cc: Kevin P. Fleming; sipcore@ietf.org > Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible i= n > Websocket transport? [RE: Call for Adoption: > draft-ibc-sipcore-sip-websocket-02] > > 2012/4/20 Christer Holmberg : > >>> So, again, let's make every transport optional, and people will then > implement based on customer requirements, network environments, platform > characteristics, etc etc etc. > >> > >> Let's just get this started... it's already relevant since SCTP has > been defined as a transport for SIP. A UA that wants to solely use SCTP > should be allowed to do that without being labeled non-compliant with RFC > 3261. > >> > >> How would this work? Would this just be a two-page document updating > that one small section of RFC 3261? > > > > Pretty much, yes :) > > > > Of course, in addition to the actual update there would need to be some > justification text. > > > Hi, in a previous mail I suggested some points for such a new work. > This future draft could address this topic by covering the following > cases: > > - Scenarios in which just *secure* SIP transport is required (so UDP has > no place). This could occur in local networks, providers networks or > whatever. > > - Scenarios in which just a single transport can be used due to network > topology (i.e. in Outbound topology in which UA's are behind different > NAT's and connect to the same Edge Proxy using TCP or UDP, so they cannot > receive requests via a different transport than the one they use to conne= ct > to their Outbound proxy). > > - Special cases in which it's clear that, given enviroment/plattform > constrains, some implementations are not able to support SIP UDP/TCP > transports. > > Basically such a draft could state that "in certain cases (such as those > described above) a SIP entity MAY NOT implement UDP and/or TCP transports= , > being this an update to RFC 3261". > > IMHO just one page :) > > > -- > I=C3=B1aki Baz Castillo > > --20cf307ca4ba8ce6b804be1c065f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Rigth. Then let me add this scenario:

- Scenarios in which large SIP messages are required so UDP is no valid.=

;)

El 20/04/2012 15:05, "Christer Holmberg&quo= t; <christer.holmberg@= ericsson.com> escribi=C3=B3:
You can use IPSec to get secure SIP traffic with UDP :)

Regards,

Christer

-----Original Message-----
From: I=C3=B1aki Baz Castillo [mailto:ibc@= aliax.net]
Sent: 20. huhtikuuta 2012 15:55
To: Christer Holmberg
Cc: Kevin P. Fleming; sipcore@ietf.org<= /a>
Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in = Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocke= t-02]

2012/4/20 Christer Holmberg <christer.holmberg@ericsson.com>:
>>> So, again, let's make every transport optional, and people= will then implement based on customer requirements, network environments, = platform characteristics, etc etc etc.
>>
>> Let's just get this started... it's already relevant since= SCTP has been defined as a transport for SIP. A UA that wants to solely us= e SCTP should be allowed to do that without being labeled non-compliant wit= h RFC 3261.
>>
>> How would this work? Would this just be a two-page document updati= ng that one small section of RFC 3261?
>
> Pretty much, yes :)
>
> Of course, in addition to the actual update there would need to be som= e justification text.


Hi, in a previous mail I suggested some points for such a new work.
This future draft could address this topic by covering the following
cases:

- Scenarios in which just *secure* SIP transport is required (so UDP has no= place). This could occur in local networks, providers networks or whatever= .

- Scenarios in which just a single transport can be used due to network top= ology (i.e. in Outbound topology in which UA's are behind different NAT= 's and connect to the same Edge Proxy using TCP or UDP, so they cannot = receive requests via a different transport than the one they use to connect= to their Outbound proxy).

- Special cases in which it's clear that, given enviroment/plattform co= nstrains, some implementations are not able to support SIP UDP/TCP transpor= ts.

Basically such a draft could state that "in certain cases (such as tho= se described above) a SIP entity MAY NOT implement UDP and/or TCP transport= s, being this an update to RFC 3261".

IMHO just one page :)


--
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
--20cf307ca4ba8ce6b804be1c065f-- From BPenfield@acmepacket.com Fri Apr 20 06:14:59 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254EE21F86F7 for ; Fri, 20 Apr 2012 06:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwltWXKHcbaT for ; Fri, 20 Apr 2012 06:14:58 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 16DD221F86EB for ; Fri, 20 Apr 2012 06:14:58 -0700 (PDT) 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; Fri, 20 Apr 2012 09:14:56 -0400 Received: from MAIL2.acmepacket.com ([169.254.2.74]) by Mail1.acmepacket.com ([169.254.1.36]) with mapi id 14.02.0283.003; Fri, 20 Apr 2012 09:14:56 -0400 From: Bob Penfield To: Christer Holmberg , "Ravindran, Parthasarathi" , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Thread-Topic: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] Thread-Index: AQHNHSsWRxiuCXdgSiiO5g4zUTCq3pagJJrA//+unYCAAGacsIAAFBwAgABihBD//7B5AIAABfgAgAD3fzCAAI6cAIAA8TmAgAAjs4CAAGh4gIAAA2+QgABDzLA= Date: Fri, 20 Apr 2012 13:14:55 +0000 Message-ID: <2BC1CD824C2D4F47A6F6EC2705F4F4D808A84E70@Mail2.acmepacket.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <436967A4-20DC-42A6-9BA2-578155B55FD9@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E2289A3@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A3C3@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C42E5A3C3@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.0.0.30] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 13:14:59 -0000 This is a going to be a Standards Track RFC, therefore it can "update" 3261= with text that relaxes the "UDP and TCP" requirement in circumstances wher= e it is not possible (e.g. in a browser) or not practical. I don't think yo= u need a separate draft. When we were working on 3261 about 10 years ago, we had discussions/debates= about whether UDP should be required. IIRC, there were some people advocat= ing UDP be deprecated altogether. There were also discussions about removin= g the requirement for UDP at some point in the future. The standards need t= o evolve with the state of the art. cheers, (-:bob -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: Friday, April 20, 2012 5:02 AM To: Ravindran, Parthasarathi; Sa=FAl Ibarra Corretg=E9 Cc: I=F1aki Baz Castillo; sipcore@ietf.org Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in = Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocke= t-02] Why not write a separate draft, which updates 3261 by saying that all trans= ports are optional... That's how the real world looks, anyway. Regards, Christer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Ravindran, Parthasarathi Sent: 20. huhtikuuta 2012 11:59 To: Sa=FAl Ibarra Corretg=E9 Cc: I=F1aki Baz Castillo; sipcore@ietf.org Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in = Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocke= t-02] Saul, My reading of your statement "There are, indeed, inherent limitations when = using SIP in a web browser, but these limitations are imposed by the WebSoc= ket API, *not* by this draft." is that websocket does not qualify as a tran= sport for SIP as it is not possible to meet RFC 3261 requirement. NAT is not SIP endpoint issue but it is a network issue. All NAT are not co= nsidered as part of RFC 3261 design but it is resolved as part of Managing = Client-Initiated Connections in the Session Initiation Protocol (SIP) RFC (= 5626).=20 Thanks Partha Note: AFAIK, NAT issue in SIP is one of the reason for not selecting SIP as= part of signaling/transport protocol in RTCWeb. >-----Original Message----- >From: Sa=FAl Ibarra Corretg=E9 [mailto:saul@ag-projects.com] >Sent: Friday, April 20, 2012 1:35 PM >To: Ravindran, Parthasarathi >Cc: I=F1aki Baz Castillo; sipcore@ietf.org >Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible=20 >in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-=20 >websocket-02] > >Hi Partha, > >On Apr 20, 2012, at 2:39 AM, Ravindran, Parthasarathi wrote: > >> Hi Inaki, >> >> There are only two options which I could think of forward for this >draft >> >> 1) As I earlier mentioned, Websocket transport works well only in >specific SIP topology and not in all topology as it is not capable of=20 >supporting UDP/TCP transport. In case the draft is only going to=20 >specify transport, then SIP entities support this draft has to have=20 >compliance with RFC 3261 (UDP, TCP transport) as well and particularly=20 >you have to mention how Javascript based SIP stack will compliance with RF= C 3261. >> > >SIP over UDP also doesn't work on all topologies, just think about NAT. >IMO this draft should not target at using SIP in web browsers using=20 >JavaScript, it should just define a new transport for the SIP protocol,=20 >which is exactly what it does. There are, indeed, inherent limitations=20 >when using SIP in a web browser, but these limitations are imposed by=20 >the WebSocket API, *not* by this draft. > >Also note that there is no "IETF police", if I would implement this=20 >draft for using a SIP client within a browser I would not implement UDP=20 >or TCP support whatsoever, because they can't be used *in a browser*. >Sue me :-) > >> 2) Alternative is to specify SIP topology requirement wherein >websocket really applies. Include the related header like record-route=20 >& path with the detail information where these headers are mandated. >> >> IMHO, the current draft is not clear enough about SIP over Websocket >transport usage. >> > >I fail to understand what is not clear about it. Of course WebSockets=20 >are used in browsers nearly 100% of the time, but this draft doesn't=20 >restrict itself to that model. You could write a desktop SIP client=20 >using WebSocket as a transport, and you could listen for incoming=20 >connections since limitations such as those in web browsers wouldn't=20 >apply. So, please, can you clarify *what* is it not clear about it? > > >Thanks and regards, > >-- >Sa=FAl Ibarra Corretg=E9 >AG Projects > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From ibc@aliax.net Fri Apr 20 07:04:02 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB1821F872F for ; Fri, 20 Apr 2012 07:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UOD3kgfLvlOJ for ; Fri, 20 Apr 2012 07:04:01 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BB87F21F872E for ; Fri, 20 Apr 2012 07:04:01 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so7572708vbb.31 for ; Fri, 20 Apr 2012 07:04:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=VYoV5JNZoTFYZjcq/yK9CwGRn2A/4mk3fuejFWlJ2lc=; b=UVprGf9VzxsoyxGJwGYkZ520Shv0pMlnp62qg3Qr4zQochnEygvnMwP1uv1b3XTkJq 0HI+bAT5Qkt6BUCx4pcVJTZF9cxMNjAdttkitLT+f5Zc2vhZjImrhfBswfphcg+vnOD3 qR9vop1YQjczcg7mFvReKvABrJUthejxD3X7kLnTBC9WkrwJLanJKpPVF6UGXPxb/GhI n0RjjdITwDg9eOg09sfGJ8zOvCZnAtgR/VU4hUcmDbWPwaP6q+WTdfIkRVUdymoPHwM1 7pZ2OIxVdxnxI4buKRwVK33UlVua0BbRhWefd5pDvOL595SMXuZjX6jhxaZ+25HFnaB4 C1dQ== Received: by 10.220.49.66 with SMTP id u2mr5101764vcf.2.1334930641264; Fri, 20 Apr 2012 07:04:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Fri, 20 Apr 2012 07:03:36 -0700 (PDT) In-Reply-To: <2BC1CD824C2D4F47A6F6EC2705F4F4D808A84E70@Mail2.acmepacket.com> References: <4F8C5EC6.8090202@nostrum.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227EAB@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <436967A4-20DC-42A6-9BA2-578155B55FD9@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E2289A3@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A3C3@ESESSCMS0356.eemea.ericsson.se> <2BC1CD824C2D4F47A6F6EC2705F4F4D808A84E70@Mail2.acmepacket.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 20 Apr 2012 16:03:36 +0200 Message-ID: To: Bob Penfield Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlxKmvtq5umDWlELRqTEe4udtoap1lXk8aOQhQxGJYAQamExZiJ2tOhuuJV7H50KuNU3hhJ Cc: "Ravindran, Parthasarathi" , "sipcore@ietf.org" , =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 14:04:02 -0000 2012/4/20 Bob Penfield : > This is a going to be a Standards Track RFC, therefore it can "update" 32= 61 with text that relaxes the "UDP and TCP" requirement in circumstances wh= ere it is not possible (e.g. in a browser) or not practical. I don't think = you need a separate draft. Hi Bob. Taking into account that new SIP transports could appear in the future, would not make more sense to write such an statement in a separate draft? Just wondering. As Paul said, otherwise each new SIP transport specification should include the same update to RFC 3261. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Fri Apr 20 08:03:51 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24D0F21F872A for ; Fri, 20 Apr 2012 08:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 HRGIs1CFucqF for ; Fri, 20 Apr 2012 08:03:50 -0700 (PDT) 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 3CF3521F8703 for ; Fri, 20 Apr 2012 08:03:50 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta04.westchester.pa.mail.comcast.net with comcast id 0DVZ1j0011wpRvQ54F3q3K; Fri, 20 Apr 2012 15:03:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id 0F3p1j01C07duvL3eF3p3Y; Fri, 20 Apr 2012 15:03:50 +0000 Message-ID: <4F917AD4.2040500@alum.mit.edu> Date: Fri, 20 Apr 2012 11:03:48 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 15:03:51 -0000 I've been looking for a suitable place to jump back into this thread. Maybe this is as good a place as any. I've changed the subject to reflect the current focus of the discussion. We have two ways forward on this - the narrow way, and the broad way. The narrow way it to craft a specific exemption for implementers of the websocket transport - that they aren't required to implement UDP and TCP. Such an exemption could be included in the websocket transport draft. The broad way is to do a standalone update to 3261 that removes/relaxes the requirement to implement UDP and TCP transports. The narrow way will be easier to achieve. Its impact is narrower and easier to understand. So there is likely to be much less objection to it. And of course it doesn't require a separate document. The broad way will cover many more cases all in one swipe of the pen. But that means that it will require much more scrutiny to avoid unintended consequences. As a result it will be harder to craft and harder to pass. My main concern is that it has to potential to erect new barriers to interoperability. The point of having some must-implement transports is to ensure some common basis for interop. This has the potential to lose that. I am myself uncertain if I would support such a change. This would depend on some very careful analysis. I can't promise that the chairs or the AD will even approve of the broad approach. (I guess there is a third way - to do *nothing* about the mandatory-to-implement transport requirement. Leave javascript-browser-based sip implementations that can't do UDP or TCP non-compliant. IMO that is an irresponsible direction that I don't want to consider.) Given all of that, I would like to have some discussion of which way the group would like to go. Please do more that vote - actually make the case for why you want to go the way you do. Thanks, Paul [as co-chair] On 4/20/12 8:54 AM, IƱaki Baz Castillo wrote: > 2012/4/20 Christer Holmberg: >>>> So, again, let's make every transport optional, and people will then implement based on customer requirements, network environments, platform characteristics, etc etc etc. >>> >>> Let's just get this started... it's already relevant since SCTP has been defined as a transport for SIP. A UA that wants to solely use SCTP should be allowed to do that without being labeled non-compliant with RFC 3261. >>> >>> How would this work? Would this just be a two-page document updating that one small section of RFC 3261? >> >> Pretty much, yes :) >> >> Of course, in addition to the actual update there would need to be some justification text. > > > Hi, in a previous mail I suggested some points for such a new work. > This future draft could address this topic by covering the following > cases: > > - Scenarios in which just *secure* SIP transport is required (so UDP > has no place). This could occur in local networks, providers networks > or whatever. > > - Scenarios in which just a single transport can be used due to > network topology (i.e. in Outbound topology in which UA's are behind > different NAT's and connect to the same Edge Proxy using TCP or UDP, > so they cannot receive requests via a different transport than the one > they use to connect to their Outbound proxy). > > - Special cases in which it's clear that, given enviroment/plattform > constrains, some implementations are not able to support SIP UDP/TCP > transports. > > Basically such a draft could state that "in certain cases (such as > those described above) a SIP entity MAY NOT implement UDP and/or TCP > transports, being this an update to RFC 3261". > > IMHO just one page :) > > From ibc@aliax.net Fri Apr 20 09:49:57 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA6B21F865F for ; Fri, 20 Apr 2012 09:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=0.042, 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 ZC6Xcla2oI3i for ; Fri, 20 Apr 2012 09:49:56 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1C2B921F8659 for ; Fri, 20 Apr 2012 09:49:56 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so3188474vcb.31 for ; Fri, 20 Apr 2012 09:49:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=7lf7VD1pMwvfFaAXf/ccCKiSVQynXWQabDn4/CAWEUo=; b=CGqP1I31PFw49iM6cUgKrYJmsHw5LIs/Ks4cghqeQ4u4iTgUYln7UrOqtpNKcH2G11 Mg7/nh1/Lkktj88oLBHP4lUaxLEyltp9B06z4bW6Bm3HzAgSvQEInStb2B3+JFADHrQN aQFH9rJs/WaK5V0F+jzPW1kTBKuHtdr7WOIy71docdR9uOEYqoy6tYd04Qqpm8zZXrHY xFceJFvXdIStEkLHaeuPnc2TIz3TCEpRUa/PVh6BAv2RfDhJNjl9m+nuZZlEEgBIb1BP PYddv3rdVruhPha2y3S6OBue5kbSn5lVlj9DqWI2HMnDyz6kSY5uMvuyp7UZWlIaas7K k9Xw== Received: by 10.220.241.12 with SMTP id lc12mr4966882vcb.22.1334940595496; Fri, 20 Apr 2012 09:49:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Fri, 20 Apr 2012 09:49:35 -0700 (PDT) In-Reply-To: <4F917AD4.2040500@alum.mit.edu> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 20 Apr 2012 18:49:35 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn5vCitL+pHhYSE6RBGEVf/JPyl1E5kJqSLhnR0y/n1xffNnmi+tA7wK6QgPP06+MP0zDft Cc: sipcore@ietf.org Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 16:49:57 -0000 2012/4/20 Paul Kyzivat : > We have two ways forward on this - the narrow way, and the broad way. > > The narrow way it to craft a specific exemption for implementers of the > websocket transport - that they aren't required to implement UDP and TCP. > Such an exemption could be included in the websocket transport draft. > > The broad way is to do a standalone update to 3261 that removes/relaxes t= he > requirement to implement UDP and TCP transports. > > The narrow way will be easier to achieve. Its impact is narrower and easi= er > to understand. So there is likely to be much less objection to it. And of > course it doesn't require a separate document. > > The broad way will cover many more cases all in one swipe of the pen. But > that means that it will require much more scrutiny to avoid unintended > consequences. As a result it will be harder to craft and harder to pass. = My > main concern is that it has to potential to erect new barriers to > interoperability. The point of having some must-implement transports is t= o > ensure some common basis for interop. This has the potential to lose that= . I > am myself uncertain if I would support such a change. This would depend o= n > some very careful analysis. > > I can't promise that the chairs or the AD will even approve of the broad > approach. > > (I guess there is a third way - to do *nothing* about the > mandatory-to-implement transport requirement. Leave javascript-browser-ba= sed > sip implementations that can't do UDP or TCP non-compliant. IMO that is a= n > irresponsible direction that I don't want to consider.) > > Given all of that, I would like to have some discussion of which way the > group would like to go. Please do more that vote - actually make the case > for why you want to go the way you do. Hi Paul, thanks for opening this thread. Here my opinion: IMHO there are cases enough to go for the broad way (a separate document updating RFC 3261), let me repeat them and include some new ones: - Scenarios in which just *secure* SIP transport is required and IPsec is not available (so UDP has no place). This could occur in local networks, providers networks or whatever. Note that UDP-DTLS for SIP is an expired draft. - Scenarios in which just a single transport can be used due to network topology (i.e. in Outbound scenarios in which UA's are behind different NAT's and connect to the same Edge Proxy using TCP or UDP, so they cannot receive requests via a different transport than the one they used to connect to their Outbound proxy). - Special cases in which it's clear that, given enviroment/plattform constrains, some implementations are not able to support SIP UDP/TCP transports (i.e. JavaScript SIP stacks in web browsers supporting The WebSocket API). - Scenarios in which large SIP messages are required. For example, when SIMPLE/XCAP presence is used, a NOTIFY with a long resource-list body would not fit into a UDP datagram. - Scenarios in which SIP interconnection is "private" or negotiated by other means (i.e. within a SIP PSTN provider infrastructure in which SIP over SCTP is used). *But* given you explanation about how hard would be this specification to be designed and approved, and given the fact that I don't expect so many new SIP transports to appear in next years, I vote for the narrow way (a text in our SIP WebSocket Transport draft updating RFC 3261). Such a text would be placed within "Updates to RFC 3261 section" and could state the following (text to be improved): -------------------------------------------------------------------- 5.2. Updates to RFC 3261 5.2.4 Relaxing TCP/UDP Implementation Requirement Section 18 "Transport" in RFC 3261 states that all SIP elements MUST implement UDP and TCP transports: All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols. It is expected that the one of the use cases for the SIP WebSocket transport will take place within web applications. JavaScript is one of the existing alternatives for developing applications that run within the browser, and "The WebSocket API" provides WebSocket access for JavaScript applications. However the JavaScript stack in web browsers does not allow direct access to the UDP and TCP layers so these SIP stacks cannot implement SIP UDP and TCP transports, and must rely on the WebSocket connection they have opened to the WebSocket server for sending and receiving SIP messages. Therefore this specification relaxes the requirement in section 18 of RFC 3261 by stating that a SIP WebSocket Client (as defined in section 2.1 "Definitions" of this document) MAY NOT implement UDP and TCP transports, and instead it MAY rely on the SIP WebSocket Server it connects to for communicating with other SIP entities implementing different SIP transports such as UDP and TCP. -------------------------------------------------------------------- So being pragmatic, my vote for the narrow way. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Fri Apr 20 10:26:53 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F368321F8587 for ; Fri, 20 Apr 2012 10:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 dozwhiCvOK4T for ; Fri, 20 Apr 2012 10:26:52 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1B17421F8575 for ; Fri, 20 Apr 2012 10:26:51 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta10.westchester.pa.mail.comcast.net with comcast id 0HSr1j0020cZkys5AHSsNt; Fri, 20 Apr 2012 17:26:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta10.westchester.pa.mail.comcast.net with comcast id 0HSp1j00L07duvL3WHSpGX; Fri, 20 Apr 2012 17:26:50 +0000 Message-ID: <4F919C59.1000604@alum.mit.edu> Date: Fri, 20 Apr 2012 13:26:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 17:26:53 -0000 IƱaki, Thanks for putting good arguments on the table. I could nit pick them, but that wouldn't enhance the discussion. I'd like to pose one more subject for discussion in this thread: Can the "broad way" be constrained in a way that minimizes abuse - failure to interoperate for lack of a common transport when there is no compelling reason why a common transport could not have been used. As that relates to your examples below: - is *no* communication always preferable to insecure communication? - how often are large sip messages universally required by a UA, rather than being required in certain contexts? I know cases can be contrived, but does that apply to a piece of equipment, or does it apply to the deployment of that equipment in a particular context? My point is to figure out if we can construct a revised requirement that provides sufficient flexibility where it is needed to create implementations, yet doesn't let implementers off the hook when its just easier for them to omit support. For instance, I think we would probably still want to say that a transport supporting large messages must always be supported. Thanks, Paul On 4/20/12 12:49 PM, IƱaki Baz Castillo wrote: > 2012/4/20 Paul Kyzivat: >> We have two ways forward on this - the narrow way, and the broad way. >> >> The narrow way it to craft a specific exemption for implementers of the >> websocket transport - that they aren't required to implement UDP and TCP. >> Such an exemption could be included in the websocket transport draft. >> >> The broad way is to do a standalone update to 3261 that removes/relaxes the >> requirement to implement UDP and TCP transports. >> >> The narrow way will be easier to achieve. Its impact is narrower and easier >> to understand. So there is likely to be much less objection to it. And of >> course it doesn't require a separate document. >> >> The broad way will cover many more cases all in one swipe of the pen. But >> that means that it will require much more scrutiny to avoid unintended >> consequences. As a result it will be harder to craft and harder to pass. My >> main concern is that it has to potential to erect new barriers to >> interoperability. The point of having some must-implement transports is to >> ensure some common basis for interop. This has the potential to lose that. I >> am myself uncertain if I would support such a change. This would depend on >> some very careful analysis. >> >> I can't promise that the chairs or the AD will even approve of the broad >> approach. >> >> (I guess there is a third way - to do *nothing* about the >> mandatory-to-implement transport requirement. Leave javascript-browser-based >> sip implementations that can't do UDP or TCP non-compliant. IMO that is an >> irresponsible direction that I don't want to consider.) >> >> Given all of that, I would like to have some discussion of which way the >> group would like to go. Please do more that vote - actually make the case >> for why you want to go the way you do. > > > Hi Paul, thanks for opening this thread. Here my opinion: > > > IMHO there are cases enough to go for the broad way (a separate > document updating RFC 3261), let me repeat them and include some new > ones: > > - Scenarios in which just *secure* SIP transport is required and IPsec > is not available (so UDP has no place). This could occur in local > networks, providers networks or whatever. Note that UDP-DTLS for SIP > is an expired draft. > > - Scenarios in which just a single transport can be used due to > network topology (i.e. in Outbound scenarios in which UA's are behind > different NAT's and connect to the same Edge Proxy using TCP or UDP, > so they cannot receive requests via a different transport than the one > they used to connect to their Outbound proxy). > > - Special cases in which it's clear that, given enviroment/plattform > constrains, some implementations are not able to support SIP UDP/TCP > transports (i.e. JavaScript SIP stacks in web browsers supporting The > WebSocket API). > > - Scenarios in which large SIP messages are required. For example, > when SIMPLE/XCAP presence is used, a NOTIFY with a long resource-list > body would not fit into a UDP datagram. > > - Scenarios in which SIP interconnection is "private" or negotiated by > other means (i.e. within a SIP PSTN provider infrastructure in which > SIP over SCTP is used). > > > > *But* given you explanation about how hard would be this specification > to be designed and approved, and given the fact that I don't expect so > many new SIP transports to appear in next years, I vote for the narrow > way (a text in our SIP WebSocket Transport draft updating RFC 3261). > Such a text would be placed within "Updates to RFC 3261 section" and > could state the following (text to be improved): > > > > > -------------------------------------------------------------------- > > 5.2. Updates to RFC 3261 > > > 5.2.4 Relaxing TCP/UDP Implementation Requirement > > > Section 18 "Transport" in RFC 3261 states that all SIP elements MUST > implement UDP and TCP transports: > > All SIP elements MUST implement UDP and TCP. SIP elements MAY > implement other protocols. > > It is expected that the one of the use cases for the SIP WebSocket > transport will take place within web applications. JavaScript is one > of the existing alternatives for developing applications that run > within the browser, and "The WebSocket API" provides WebSocket access > for JavaScript applications. However the JavaScript stack in web > browsers does not allow direct access to the UDP and TCP layers so > these SIP stacks cannot implement SIP UDP and TCP transports, and must > rely on the WebSocket connection they have opened to the WebSocket > server for sending and receiving SIP messages. > > Therefore this specification relaxes the requirement in section 18 of > RFC 3261 by stating that a SIP WebSocket Client (as defined in section > 2.1 "Definitions" of this document) MAY NOT implement UDP and TCP > transports, and instead it MAY rely on the SIP WebSocket Server it > connects to for communicating with other SIP entities implementing > different SIP transports such as UDP and TCP. > > -------------------------------------------------------------------- > > > > So being pragmatic, my vote for the narrow way. > > > Thanks a lot. > > From christer.holmberg@ericsson.com Fri Apr 20 14:08:16 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0C021F84F0 for ; Fri, 20 Apr 2012 14:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 I8FmJ5TpBZWC for ; Fri, 20 Apr 2012 14:08:15 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0380A21F84E6 for ; Fri, 20 Apr 2012 14:08:14 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-51-4f91d03d64ce Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA) Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1E.78.03534.D30D19F4; Fri, 20 Apr 2012 23:08:13 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 20 Apr 2012 23:08:12 +0200 From: Christer Holmberg To: Paul Kyzivat , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Fri, 20 Apr 2012 23:08:12 +0200 Thread-Topic: [sipcore] Should we change mandatory-to-implement transports? Thread-Index: Ac0fGsm26HaYa9OfTSqBh9YD4+fF4AAHhryi Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C428E2FAF@ESESSCMS0356.eemea.ericsson.se> References: <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> , <4F919C59.1000604@alum.mit.edu> In-Reply-To: <4F919C59.1000604@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2012 21:08:16 -0000 Hi, Eventhough I would give my hum for the broad way, if that is difficult to g= et accepted there is also a middle way: RFC 3261 mandates support of TCP an= d UDP, but is updated to explicitly allow specifications for new transports= (SCTP, WebSocket etc) to relax that requirement for implementations of tho= se specific transports. The fact would still exist, that there are cases (see Inaki's examples - ev= enthough I could also nit pick on some of them :) where an implementation = won't use, and/or cannot be reached using both TCP and UDP. Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@alum.mit.edu] Sent: Friday, April 20, 2012 8:26 PM To: I=F1aki Baz Castillo Cc: sipcore@ietf.org Subject: Re: [sipcore] Should we change mandatory-to-implement transports? I=F1aki, Thanks for putting good arguments on the table. I could nit pick them, but that wouldn't enhance the discussion. I'd like to pose one more subject for discussion in this thread: Can the "broad way" be constrained in a way that minimizes abuse - failure to interoperate for lack of a common transport when there is no compelling reason why a common transport could not have been used. As that relates to your examples below: - is *no* communication always preferable to insecure communication? - how often are large sip messages universally required by a UA, rather than being required in certain contexts? I know cases can be contrived, but does that apply to a piece of equipment, or does it apply to the deployment of that equipment in a particular context? My point is to figure out if we can construct a revised requirement that provides sufficient flexibility where it is needed to create implementations, yet doesn't let implementers off the hook when its just easier for them to omit support. For instance, I think we would probably still want to say that a transport supporting large messages must always be supported. Thanks, Paul On 4/20/12 12:49 PM, I=F1aki Baz Castillo wrote: > 2012/4/20 Paul Kyzivat: >> We have two ways forward on this - the narrow way, and the broad way. >> >> The narrow way it to craft a specific exemption for implementers of the >> websocket transport - that they aren't required to implement UDP and TCP= . >> Such an exemption could be included in the websocket transport draft. >> >> The broad way is to do a standalone update to 3261 that removes/relaxes = the >> requirement to implement UDP and TCP transports. >> >> The narrow way will be easier to achieve. Its impact is narrower and eas= ier >> to understand. So there is likely to be much less objection to it. And o= f >> course it doesn't require a separate document. >> >> The broad way will cover many more cases all in one swipe of the pen. Bu= t >> that means that it will require much more scrutiny to avoid unintended >> consequences. As a result it will be harder to craft and harder to pass.= My >> main concern is that it has to potential to erect new barriers to >> interoperability. The point of having some must-implement transports is = to >> ensure some common basis for interop. This has the potential to lose tha= t. I >> am myself uncertain if I would support such a change. This would depend = on >> some very careful analysis. >> >> I can't promise that the chairs or the AD will even approve of the broad >> approach. >> >> (I guess there is a third way - to do *nothing* about the >> mandatory-to-implement transport requirement. Leave javascript-browser-b= ased >> sip implementations that can't do UDP or TCP non-compliant. IMO that is = an >> irresponsible direction that I don't want to consider.) >> >> Given all of that, I would like to have some discussion of which way the >> group would like to go. Please do more that vote - actually make the cas= e >> for why you want to go the way you do. > > > Hi Paul, thanks for opening this thread. Here my opinion: > > > IMHO there are cases enough to go for the broad way (a separate > document updating RFC 3261), let me repeat them and include some new > ones: > > - Scenarios in which just *secure* SIP transport is required and IPsec > is not available (so UDP has no place). This could occur in local > networks, providers networks or whatever. Note that UDP-DTLS for SIP > is an expired draft. > > - Scenarios in which just a single transport can be used due to > network topology (i.e. in Outbound scenarios in which UA's are behind > different NAT's and connect to the same Edge Proxy using TCP or UDP, > so they cannot receive requests via a different transport than the one > they used to connect to their Outbound proxy). > > - Special cases in which it's clear that, given enviroment/plattform > constrains, some implementations are not able to support SIP UDP/TCP > transports (i.e. JavaScript SIP stacks in web browsers supporting The > WebSocket API). > > - Scenarios in which large SIP messages are required. For example, > when SIMPLE/XCAP presence is used, a NOTIFY with a long resource-list > body would not fit into a UDP datagram. > > - Scenarios in which SIP interconnection is "private" or negotiated by > other means (i.e. within a SIP PSTN provider infrastructure in which > SIP over SCTP is used). > > > > *But* given you explanation about how hard would be this specification > to be designed and approved, and given the fact that I don't expect so > many new SIP transports to appear in next years, I vote for the narrow > way (a text in our SIP WebSocket Transport draft updating RFC 3261). > Such a text would be placed within "Updates to RFC 3261 section" and > could state the following (text to be improved): > > > > > -------------------------------------------------------------------- > > 5.2. Updates to RFC 3261 > > > 5.2.4 Relaxing TCP/UDP Implementation Requirement > > > Section 18 "Transport" in RFC 3261 states that all SIP elements MUST > implement UDP and TCP transports: > > All SIP elements MUST implement UDP and TCP. SIP elements MAY > implement other protocols. > > It is expected that the one of the use cases for the SIP WebSocket > transport will take place within web applications. JavaScript is one > of the existing alternatives for developing applications that run > within the browser, and "The WebSocket API" provides WebSocket access > for JavaScript applications. However the JavaScript stack in web > browsers does not allow direct access to the UDP and TCP layers so > these SIP stacks cannot implement SIP UDP and TCP transports, and must > rely on the WebSocket connection they have opened to the WebSocket > server for sending and receiving SIP messages. > > Therefore this specification relaxes the requirement in section 18 of > RFC 3261 by stating that a SIP WebSocket Client (as defined in section > 2.1 "Definitions" of this document) MAY NOT implement UDP and TCP > transports, and instead it MAY rely on the SIP WebSocket Server it > connects to for communicating with other SIP entities implementing > different SIP transports such as UDP and TCP. > > -------------------------------------------------------------------- > > > > So being pragmatic, my vote for the narrow way. > > > Thanks a lot. > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From pravindran@sonusnet.com Sat Apr 21 19:55:57 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D8921F855B for ; Sat, 21 Apr 2012 19:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] 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 1rSKXCmmnxft for ; Sat, 21 Apr 2012 19:55:57 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9E621F855A for ; Sat, 21 Apr 2012 19:55:56 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKT5NzPH9SUolAa/Qa5xJjhB0UT1Hfzt+m@postini.com; Sat, 21 Apr 2012 19:55:56 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 21 Apr 2012 22:55:54 -0400 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.0355.002; Sun, 22 Apr 2012 08:25:50 +0530 From: "Ravindran, Parthasarathi" To: Salvatore Loreto , "sipcore@ietf.org" Thread-Topic: Websocket is a new transport or new URI? Thread-Index: AQHNIDOCuN/qLU9tjk656lTA6m0G8w== Date: Sun, 22 Apr 2012 02:55:49 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> In-Reply-To: <4F8ECB82.7070805@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 02:55:57 -0000 Sal & others, After reading lot of mails and thinking further, I agree with you that Webs= ocket is an application protocol that is used as an transport for SIP. TLS = is one another application protocol on top of TCP which was considered as t= ransport (transport=3Dtls) earlier and deprecated as part of RFC 3261 in Se= c 26.2.2. TLS and Websocket has some unique behavior like hop-by-hop protoc= ol rather than end-to-end.=20 TLS is adopted within SIP using new URI namely SIPS with transport=3Dtcp. I= n the same way, I'm proposing SIPWS which implies websocket over TCP, SIPWS= S which implies websocket over TLS over TCP. Please let me know your opinio= n on the same.=20 Thanks Partha >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >Behalf Of Salvatore Loreto >Sent: Wednesday, April 18, 2012 7:41 PM >To: sipcore@ietf.org >Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible >in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip- >websocket-02] > >On 4/18/12 4:40 PM, Christer Holmberg wrote: >> Hi, >> >> I may have misunderstood something in the conversation, but my >suggestion would be to consider *NOT* mandating SIP WebSocket clients to >implement SIP UDP and TCP. >> >> Especially if I write a JavaScript SIP browser app, I very likely >would want to support only WebSocket. >> >> Also, I don't think we can directly compare with SCTP, since the >typical use-case for WebSocket is browser apps (eventhough a native app >can of course also use WS). > >I think that in general we can not compare SCTP to WebSocket at all >because the first is a pure Transport Protocol, the latter is an >application protocol that is used as transport. > > From a pure WebSocket prospective, what you are going to define is SIP >as a websocket sub-protocol that is transported on top of. > >The important thing to standardize from a SIPCore prospective is the >interaction/translations that happens between the WebSocket server and >the SIP proxy that are two different logical entities. > >my two cents >Sal > >-- >Salvatore Loreto, PhD >www.sloreto.com > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From pravindran@sonusnet.com Sat Apr 21 20:01:37 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0309411E8080 for ; Sat, 21 Apr 2012 20:01:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Ou5HGk1LZkAj for ; Sat, 21 Apr 2012 20:01:36 -0700 (PDT) Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with ESMTP id D853E11E8073 for ; Sat, 21 Apr 2012 20:01:35 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKT5N0j+R4UDYucbTdWRVLnqmD4mc9cLRa@postini.com; Sat, 21 Apr 2012 20:01:35 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 21 Apr 2012 23:01:34 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Sun, 22 Apr 2012 08:31:29 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Should we change mandatory-to-implement transports? Thread-Index: AQHNHwbQaJhHKG8b4kOFcyf6nW/MOJamKTDg Date: Sun, 22 Apr 2012 03:01:28 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E228C33@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> In-Reply-To: <4F917AD4.2040500@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 03:01:37 -0000 UGF1bCwNCg0KRXZlbiBiZWZvcmUgcmVsYXhpbmcgdGhlIHRyYW5zcG9ydCBjcml0ZXJpYSwgbGV0 IHVzIGRpc2N1c3Mgd2hldGhlciB3ZWJzb2NrZXQgaXMgYSBuZXcgdHJhbnNwb3J0IG9yIG5ldyBV UkkgYXMgdGhlIHNpbWlsYXIgZGlzY3Vzc2lvbiBoYXBwZW5zIGZvciBUTFMgYXMgYSB0cmFuc3Bv cnQgb3ZlciBUQ1AgaW4gU2VjIDI2LjIuMi4gSSBoYXZlIGluaXRpYXRlZCB0aGUgbmV3IHRocmVh ZCB3aXRoIHRoZSBwcm9wb3NhbCBvZiB1c2luZyB3ZWJzb2NrZXQgYXMgYSBuZXcgVVJJIChTSVBX UywgU0lQV1NTKS4gSSdsbCBnZXQgYmFjayB0byB0aGlzIHRocmVhZCBpbiBjYXNlIGZvbGtzIHBy b3ZlcyB3ZWJzb2NrZXQgYXMgYSB0cmFuc3BvcnQuDQoNClRoYW5rcw0KUGFydGhhDQoNCj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj5CZWhhbGYgT2YgUGF1bCBLeXpp dmF0DQo+U2VudDogRnJpZGF5LCBBcHJpbCAyMCwgMjAxMiA4OjM0IFBNDQo+VG86IHNpcGNvcmVA aWV0Zi5vcmcNCj5TdWJqZWN0OiBbc2lwY29yZV0gU2hvdWxkIHdlIGNoYW5nZSBtYW5kYXRvcnkt dG8taW1wbGVtZW50IHRyYW5zcG9ydHM/DQo+DQo+SSd2ZSBiZWVuIGxvb2tpbmcgZm9yIGEgc3Vp dGFibGUgcGxhY2UgdG8ganVtcCBiYWNrIGludG8gdGhpcyB0aHJlYWQuDQo+TWF5YmUgdGhpcyBp cyBhcyBnb29kIGEgcGxhY2UgYXMgYW55LiBJJ3ZlIGNoYW5nZWQgdGhlIHN1YmplY3QgdG8NCj5y ZWZsZWN0IHRoZSBjdXJyZW50IGZvY3VzIG9mIHRoZSBkaXNjdXNzaW9uLg0KPg0KPldlIGhhdmUg dHdvIHdheXMgZm9yd2FyZCBvbiB0aGlzIC0gdGhlIG5hcnJvdyB3YXksIGFuZCB0aGUgYnJvYWQg d2F5Lg0KPg0KPlRoZSBuYXJyb3cgd2F5IGl0IHRvIGNyYWZ0IGEgc3BlY2lmaWMgZXhlbXB0aW9u IGZvciBpbXBsZW1lbnRlcnMgb2YgdGhlDQo+d2Vic29ja2V0IHRyYW5zcG9ydCAtIHRoYXQgdGhl eSBhcmVuJ3QgcmVxdWlyZWQgdG8gaW1wbGVtZW50IFVEUCBhbmQNCj5UQ1AuIFN1Y2ggYW4gZXhl bXB0aW9uIGNvdWxkIGJlIGluY2x1ZGVkIGluIHRoZSB3ZWJzb2NrZXQgdHJhbnNwb3J0DQo+ZHJh ZnQuDQo+DQo+VGhlIGJyb2FkIHdheSBpcyB0byBkbyBhIHN0YW5kYWxvbmUgdXBkYXRlIHRvIDMy NjEgdGhhdCByZW1vdmVzL3JlbGF4ZXMNCj50aGUgcmVxdWlyZW1lbnQgdG8gaW1wbGVtZW50IFVE UCBhbmQgVENQIHRyYW5zcG9ydHMuDQo+DQo+VGhlIG5hcnJvdyB3YXkgd2lsbCBiZSBlYXNpZXIg dG8gYWNoaWV2ZS4gSXRzIGltcGFjdCBpcyBuYXJyb3dlciBhbmQNCj5lYXNpZXIgdG8gdW5kZXJz dGFuZC4gU28gdGhlcmUgaXMgbGlrZWx5IHRvIGJlIG11Y2ggbGVzcyBvYmplY3Rpb24gdG8NCj5p dC4gQW5kIG9mIGNvdXJzZSBpdCBkb2Vzbid0IHJlcXVpcmUgYSBzZXBhcmF0ZSBkb2N1bWVudC4N Cj4NCj5UaGUgYnJvYWQgd2F5IHdpbGwgY292ZXIgbWFueSBtb3JlIGNhc2VzIGFsbCBpbiBvbmUg c3dpcGUgb2YgdGhlIHBlbi4NCj5CdXQgdGhhdCBtZWFucyB0aGF0IGl0IHdpbGwgcmVxdWlyZSBt dWNoIG1vcmUgc2NydXRpbnkgdG8gYXZvaWQNCj51bmludGVuZGVkIGNvbnNlcXVlbmNlcy4gQXMg YSByZXN1bHQgaXQgd2lsbCBiZSBoYXJkZXIgdG8gY3JhZnQgYW5kDQo+aGFyZGVyIHRvIHBhc3Mu IE15IG1haW4gY29uY2VybiBpcyB0aGF0IGl0IGhhcyB0byBwb3RlbnRpYWwgdG8gZXJlY3QgbmV3 DQo+YmFycmllcnMgdG8gaW50ZXJvcGVyYWJpbGl0eS4gVGhlIHBvaW50IG9mIGhhdmluZyBzb21l IG11c3QtaW1wbGVtZW50DQo+dHJhbnNwb3J0cyBpcyB0byBlbnN1cmUgc29tZSBjb21tb24gYmFz aXMgZm9yIGludGVyb3AuIFRoaXMgaGFzIHRoZQ0KPnBvdGVudGlhbCB0byBsb3NlIHRoYXQuIEkg YW0gbXlzZWxmIHVuY2VydGFpbiBpZiBJIHdvdWxkIHN1cHBvcnQgc3VjaCBhDQo+Y2hhbmdlLiBU aGlzIHdvdWxkIGRlcGVuZCBvbiBzb21lIHZlcnkgY2FyZWZ1bCBhbmFseXNpcy4NCj4NCj5JIGNh bid0IHByb21pc2UgdGhhdCB0aGUgY2hhaXJzIG9yIHRoZSBBRCB3aWxsIGV2ZW4gYXBwcm92ZSBv ZiB0aGUgYnJvYWQNCj5hcHByb2FjaC4NCj4NCj4oSSBndWVzcyB0aGVyZSBpcyBhIHRoaXJkIHdh eSAtIHRvIGRvICpub3RoaW5nKiBhYm91dCB0aGUgbWFuZGF0b3J5LXRvLQ0KPmltcGxlbWVudCB0 cmFuc3BvcnQgcmVxdWlyZW1lbnQuIExlYXZlIGphdmFzY3JpcHQtYnJvd3Nlci1iYXNlZCBzaXAN Cj5pbXBsZW1lbnRhdGlvbnMgdGhhdCBjYW4ndCBkbyBVRFAgb3IgVENQIG5vbi1jb21wbGlhbnQu IElNTyB0aGF0IGlzIGFuDQo+aXJyZXNwb25zaWJsZSBkaXJlY3Rpb24gdGhhdCBJIGRvbid0IHdh bnQgdG8gY29uc2lkZXIuKQ0KPg0KPkdpdmVuIGFsbCBvZiB0aGF0LCBJIHdvdWxkIGxpa2UgdG8g aGF2ZSBzb21lIGRpc2N1c3Npb24gb2Ygd2hpY2ggd2F5IHRoZQ0KPmdyb3VwIHdvdWxkIGxpa2Ug dG8gZ28uIFBsZWFzZSBkbyBtb3JlIHRoYXQgdm90ZSAtIGFjdHVhbGx5IG1ha2UgdGhlDQo+Y2Fz ZSBmb3Igd2h5IHlvdSB3YW50IHRvIGdvIHRoZSB3YXkgeW91IGRvLg0KPg0KPglUaGFua3MsDQo+ CVBhdWwgW2FzIGNvLWNoYWlyXQ0KPg0KPk9uIDQvMjAvMTIgODo1NCBBTSwgScOxYWtpIEJheiBD YXN0aWxsbyB3cm90ZToNCj4+IDIwMTIvNC8yMCBDaHJpc3RlciBIb2xtYmVyZzxjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20+Og0KPj4+Pj4gU28sIGFnYWluLCBsZXQncyBtYWtlIGV2ZXJ5 IHRyYW5zcG9ydCBvcHRpb25hbCwgYW5kIHBlb3BsZSB3aWxsDQo+dGhlbiBpbXBsZW1lbnQgYmFz ZWQgb24gY3VzdG9tZXIgcmVxdWlyZW1lbnRzLCBuZXR3b3JrIGVudmlyb25tZW50cywNCj5wbGF0 Zm9ybSBjaGFyYWN0ZXJpc3RpY3MsIGV0YyBldGMgZXRjLg0KPj4+Pg0KPj4+PiBMZXQncyBqdXN0 IGdldCB0aGlzIHN0YXJ0ZWQuLi4gaXQncyBhbHJlYWR5IHJlbGV2YW50IHNpbmNlIFNDVFAgaGFz DQo+YmVlbiBkZWZpbmVkIGFzIGEgdHJhbnNwb3J0IGZvciBTSVAuIEEgVUEgdGhhdCB3YW50cyB0 byBzb2xlbHkgdXNlIFNDVFANCj5zaG91bGQgYmUgYWxsb3dlZCB0byBkbyB0aGF0IHdpdGhvdXQg YmVpbmcgbGFiZWxlZCBub24tY29tcGxpYW50IHdpdGgNCj5SRkMgMzI2MS4NCj4+Pj4NCj4+Pj4g SG93IHdvdWxkIHRoaXMgd29yaz8gV291bGQgdGhpcyBqdXN0IGJlIGEgdHdvLXBhZ2UgZG9jdW1l bnQgdXBkYXRpbmcNCj50aGF0IG9uZSBzbWFsbCBzZWN0aW9uIG9mIFJGQyAzMjYxPw0KPj4+DQo+ Pj4gUHJldHR5IG11Y2gsIHllcyA6KQ0KPj4+DQo+Pj4gT2YgY291cnNlLCBpbiBhZGRpdGlvbiB0 byB0aGUgYWN0dWFsIHVwZGF0ZSB0aGVyZSB3b3VsZCBuZWVkIHRvIGJlDQo+c29tZSBqdXN0aWZp Y2F0aW9uIHRleHQuDQo+Pg0KPj4NCj4+IEhpLCBpbiBhIHByZXZpb3VzIG1haWwgSSBzdWdnZXN0 ZWQgc29tZSBwb2ludHMgZm9yIHN1Y2ggYSBuZXcgd29yay4NCj4+IFRoaXMgZnV0dXJlIGRyYWZ0 IGNvdWxkIGFkZHJlc3MgdGhpcyB0b3BpYyBieSBjb3ZlcmluZyB0aGUgZm9sbG93aW5nDQo+PiBj YXNlczoNCj4+DQo+PiAtIFNjZW5hcmlvcyBpbiB3aGljaCBqdXN0ICpzZWN1cmUqIFNJUCB0cmFu c3BvcnQgaXMgcmVxdWlyZWQgKHNvIFVEUA0KPj4gaGFzIG5vIHBsYWNlKS4gVGhpcyBjb3VsZCBv Y2N1ciBpbiBsb2NhbCBuZXR3b3JrcywgcHJvdmlkZXJzIG5ldHdvcmtzDQo+PiBvciB3aGF0ZXZl ci4NCj4+DQo+PiAtIFNjZW5hcmlvcyBpbiB3aGljaCBqdXN0IGEgc2luZ2xlIHRyYW5zcG9ydCBj YW4gYmUgdXNlZCBkdWUgdG8NCj4+IG5ldHdvcmsgdG9wb2xvZ3kgKGkuZS4gaW4gT3V0Ym91bmQg dG9wb2xvZ3kgaW4gd2hpY2ggVUEncyBhcmUgYmVoaW5kDQo+PiBkaWZmZXJlbnQgTkFUJ3MgYW5k IGNvbm5lY3QgdG8gdGhlIHNhbWUgRWRnZSBQcm94eSB1c2luZyBUQ1Agb3IgVURQLA0KPj4gc28g dGhleSBjYW5ub3QgcmVjZWl2ZSByZXF1ZXN0cyB2aWEgYSBkaWZmZXJlbnQgdHJhbnNwb3J0IHRo YW4gdGhlIG9uZQ0KPj4gdGhleSB1c2UgdG8gY29ubmVjdCB0byB0aGVpciBPdXRib3VuZCBwcm94 eSkuDQo+Pg0KPj4gLSBTcGVjaWFsIGNhc2VzIGluIHdoaWNoIGl0J3MgY2xlYXIgdGhhdCwgZ2l2 ZW4gZW52aXJvbWVudC9wbGF0dGZvcm0NCj4+IGNvbnN0cmFpbnMsIHNvbWUgaW1wbGVtZW50YXRp b25zIGFyZSBub3QgYWJsZSB0byBzdXBwb3J0IFNJUCBVRFAvVENQDQo+PiB0cmFuc3BvcnRzLg0K Pj4NCj4+IEJhc2ljYWxseSBzdWNoIGEgZHJhZnQgY291bGQgc3RhdGUgdGhhdCAiaW4gY2VydGFp biBjYXNlcyAoc3VjaCBhcw0KPj4gdGhvc2UgZGVzY3JpYmVkIGFib3ZlKSBhIFNJUCBlbnRpdHkg TUFZIE5PVCBpbXBsZW1lbnQgVURQIGFuZC9vciBUQ1ANCj4+IHRyYW5zcG9ydHMsIGJlaW5nIHRo aXMgYW4gdXBkYXRlIHRvIFJGQyAzMjYxIi4NCj4+DQo+PiBJTUhPIGp1c3Qgb25lIHBhZ2UgOikN Cj4+DQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+c2lwY29yZSBtYWlsaW5nIGxpc3QNCj5zaXBjb3JlQGlldGYub3JnDQo+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo= From pravindran@sonusnet.com Sat Apr 21 20:33:45 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48DD21E8024 for ; Sat, 21 Apr 2012 20:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8sjanbXTD3cy for ; Sat, 21 Apr 2012 20:33:44 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4D521E801C for ; Sat, 21 Apr 2012 20:33:44 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKT5N8FW7FQc5ABe5cy1Zthkn4sCiXszlI@postini.com; Sat, 21 Apr 2012 20:33:44 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 21 Apr 2012 23:33:39 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Sun, 22 Apr 2012 08:57:53 +0530 From: "Ravindran, Parthasarathi" To: Salvatore Loreto , "sipcore@ietf.org" Thread-Topic: Interaction between Websocket server & SIP entity Thread-Index: AQHNIDf9m3t7ssNkiEKLUwiKn7kQsQ== Date: Sun, 22 Apr 2012 03:27:52 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E228C51@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F5D@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> In-Reply-To: <4F8ECB82.7070805@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Interaction between Websocket server & SIP entity X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 03:33:45 -0000 Hi all, >The important thing to standardize from a SIPCore prospective is the >interaction/translations that happens between the WebSocket server and >the SIP proxy that are two different logical entities. Websocket server is capable of performing real time communication using RTC= Web Specification without using SIP. Websocket server will reuse SDP and fo= llowing the mechanism mentioned in JSEP (Updated RFC 3264 mechanism) in som= e form. =20 I'm of the same opinion as Sal that interworking functionality between webs= ocket server which is capable of performing real time communication & SIP e= ntities is the important part of standardization. draft-ibc-sipcore-sip-we= bsocket-02 does not address how JSEP to SIP interaction occurs as it focus = on the transport mechanism. I'll write new draft about the interworking bet= ween SIP and RTCWeb entity. Please let me other opinion on the same. Thanks Partha >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >Behalf Of Salvatore Loreto >Sent: Wednesday, April 18, 2012 7:41 PM >To: sipcore@ietf.org >Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible >in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip- >websocket-02] > >On 4/18/12 4:40 PM, Christer Holmberg wrote: >> Hi, >> >> I may have misunderstood something in the conversation, but my >suggestion would be to consider *NOT* mandating SIP WebSocket clients to >implement SIP UDP and TCP. >> >> Especially if I write a JavaScript SIP browser app, I very likely >would want to support only WebSocket. >> >> Also, I don't think we can directly compare with SCTP, since the >typical use-case for WebSocket is browser apps (eventhough a native app >can of course also use WS). > >I think that in general we can not compare SCTP to WebSocket at all >because the first is a pure Transport Protocol, the latter is an >application protocol that is used as transport. > > From a pure WebSocket prospective, what you are going to define is SIP >as a websocket sub-protocol that is transported on top of. > >The important thing to standardize from a SIPCore prospective is the >interaction/translations that happens between the WebSocket server and >the SIP proxy that are two different logical entities. > >my two cents >Sal > >-- >Salvatore Loreto, PhD >www.sloreto.com > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From ibc@aliax.net Sun Apr 22 06:21:09 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7B721F858F for ; Sun, 22 Apr 2012 06:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, 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 CaVidcuAo0xZ for ; Sun, 22 Apr 2012 06:21:09 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B94E121F852C for ; Sun, 22 Apr 2012 06:21:08 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4213068vcb.31 for ; Sun, 22 Apr 2012 06:21:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=CemDkL2/7wML+oDLGH3K6V8inrhIePceSyQVJwTSbXI=; b=Dg0Ah5sGIQqsNeB9aZr1YUjSi6gtRp63UBa5UFoOAp4KaGiI3RY6iExYbKUQu14RGP 06CowbHsmCeuKa/5verBOfPQgEW8OTySFackAYRjGeRtnReD4QDkM1pdsgHV2WhN4XLF PqfQThEy8aVFZGeqPpJKLNxY1rbuOl2gOf88dRPaEA60XI1XEFALn6iVt8HIrgfr2WSe xcyktOogM1cAVgt58g7kViiz4wsJnwrzqCozhVCDgQig99Uk146ruVMsZ7/djnqH8lEz vC1B/p0eD9Bp/MJCvRpSfPiI72nteVX2TBp7V05KcqsExbfDczY0Oy5oPTNmhMquK62/ pTSg== Received: by 10.52.15.233 with SMTP id a9mr10676224vdd.34.1335100868196; Sun, 22 Apr 2012 06:21:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Sun, 22 Apr 2012 06:20:47 -0700 (PDT) In-Reply-To: <4F919C59.1000604@alum.mit.edu> References: <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 22 Apr 2012 15:20:47 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQns/9F7QK1G/KKCmPP5rAbsnBwP0Jf1ZCbRRN41ePYq9eWVTIL/jxZqseJcT/8Cen9J3iwa Cc: sipcore@ietf.org Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 13:21:09 -0000 2012/4/20 Paul Kyzivat : > I=C3=B1aki, > > Thanks for putting good arguments on the table. > I could nit pick them, but that wouldn't enhance the discussion. Hi Paul, let me some comments inline: > I'd like to pose one more subject for discussion in this thread: > > Can the "broad way" be constrained in a way that minimizes abuse - failur= e > to interoperate for lack of a common transport when there is no compellin= g > reason why a common transport could not have been used. > > As that relates to your examples below: > > - is *no* communication always preferable to insecure communication? I could imagine a "like-Skype" service using SIP protocol and providing both the server infrastructure and the SIP client (i.e. a SIP softphone). Such a provider could be interested in secure communications so its SIP client would just implement TLS-TCP transport for signaling and SRTP (with DTLS or SDES) for media. The provider does not want and does not accept that their SIP clients are reachable via UDP, neither it accepts that their SIP clients communicate with SIP entities other than their "official" SIP proxies/servers. > - how often are large sip messages universally required by a UA, > =C2=A0rather than being required in certain contexts? A SIP UA typically just registers using a single transport and, in common scenarios, it is just reachable through the proxy it is connected to (i.e. Outbound scenarios). Therefore the UA would prefer to use TCP rather than UDP and then allow big SIP messages (in case they are needed, as for example when receiving a NOTIFY with a resource-list XML body). If a vendor or provider offers such a service, it might consider a waste of time to implement UDP transport. > I know cases can be contrived, but does that apply to a piece of equipmen= t, > or does it apply to the deployment of that equipment in a particular > context? IMHO it's more related to the network context and security requirements. UDP is not valid for all the SIP scenarios (it is not valid for big messages and it cannot provide security). If a client wants "security", why should its equipment support and listen into UDP transport? Also let me some questions coming to my mind: 1) If a SIP phone implements both UDP and TCP, but allows the user to disable UDP (so it no longer listens into a UDP socket), is that phone "violating" RFC 3261 or not? 2) If a SIP domain announces DNS NAPTR records just including SCTP transport or just SCTP and TCP, is it "violating" RFC 3261? Note that RFC 3263 states that, when NAPTR records are present, those are the options to reach the server. > My point is to figure out if we can construct a revised requirement that > provides sufficient flexibility where it is needed to create > implementations, yet doesn't let implementers off the hook when its just > easier for them to omit support. I understand your point in favour of interoperability. Maybe the following usecase seems a bit ironic: - A scenario in which *direct* interoperability with other SIP transports won't take place (i.e. a SIP stack in JavaScript using WebSocket transport, and whose SIP outbound proxy provides interoperability with other SIP transports when required). > For instance, I think we would probably still want to say that a transpor= t > supporting large messages must always be supported. I agree. Said that, I also consider that such a new document requires lot of work and analysis (as you predicted). Otherwise it could become a risk. So for now I would vote for the narrow way. IMHO nothing prevent the broad way to take place latter. Best regards. --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Sun Apr 22 12:49:04 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3727D21F85C3 for ; Sun, 22 Apr 2012 12:49:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=-0.236, 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 nbi4HpOOJ0eY for ; Sun, 22 Apr 2012 12:49:03 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 6105521F85BB for ; Sun, 22 Apr 2012 12:49:01 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta07.westchester.pa.mail.comcast.net with comcast id 17oV1j0010bG4ec577p2Ao; Sun, 22 Apr 2012 19:49:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta03.westchester.pa.mail.comcast.net with comcast id 17oz1j01E07duvL3P7oztg; Sun, 22 Apr 2012 19:48:59 +0000 Message-ID: <4F9460AC.2080605@alum.mit.edu> Date: Sun, 22 Apr 2012 15:49:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 19:49:04 -0000 Partha, IMO the main thing we learned about sips is that it was a bad idea. I don't support making that mistake again. Thanks, Paul On 4/21/12 10:55 PM, Ravindran, Parthasarathi wrote: > Sal& others, > > After reading lot of mails and thinking further, I agree with you that Websocket is an application protocol that is used as an transport for SIP. TLS is one another application protocol on top of TCP which was considered as transport (transport=tls) earlier and deprecated as part of RFC 3261 in Sec 26.2.2. TLS and Websocket has some unique behavior like hop-by-hop protocol rather than end-to-end. > > TLS is adopted within SIP using new URI namely SIPS with transport=tcp. In the same way, I'm proposing SIPWS which implies websocket over TCP, SIPWSS which implies websocket over TLS over TCP. Please let me know your opinion on the same. > > Thanks > Partha > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Salvatore Loreto >> Sent: Wednesday, April 18, 2012 7:41 PM >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible >> in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip- >> websocket-02] >> >> On 4/18/12 4:40 PM, Christer Holmberg wrote: >>> Hi, >>> >>> I may have misunderstood something in the conversation, but my >> suggestion would be to consider *NOT* mandating SIP WebSocket clients to >> implement SIP UDP and TCP. >>> >>> Especially if I write a JavaScript SIP browser app, I very likely >> would want to support only WebSocket. >>> >>> Also, I don't think we can directly compare with SCTP, since the >> typical use-case for WebSocket is browser apps (eventhough a native app >> can of course also use WS). >> >> I think that in general we can not compare SCTP to WebSocket at all >> because the first is a pure Transport Protocol, the latter is an >> application protocol that is used as transport. >> >> From a pure WebSocket prospective, what you are going to define is SIP >> as a websocket sub-protocol that is transported on top of. >> >> The important thing to standardize from a SIPCore prospective is the >> interaction/translations that happens between the WebSocket server and >> the SIP proxy that are two different logical entities. >> >> my two cents >> Sal >> >> -- >> Salvatore Loreto, PhD >> www.sloreto.com >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@alum.mit.edu Sun Apr 22 13:10:15 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E31F21F8552 for ; Sun, 22 Apr 2012 13:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.379 X-Spam-Level: X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 7iNaeh2o0EgJ for ; Sun, 22 Apr 2012 13:10:14 -0700 (PDT) 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 EFC5E21F854D for ; Sun, 22 Apr 2012 13:10:13 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta08.westchester.pa.mail.comcast.net with comcast id 16yd1j0051vXlb8588AEAh; Sun, 22 Apr 2012 20:10:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id 18AD1j00L07duvL3d8ADlZ; Sun, 22 Apr 2012 20:10:13 +0000 Message-ID: <4F9465A4.5070108@alum.mit.edu> Date: Sun, 22 Apr 2012 16:10:12 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 20:10:15 -0000 On 4/22/12 9:20 AM, IƱaki Baz Castillo wrote: > 2012/4/20 Paul Kyzivat: >> IƱaki, >> >> Thanks for putting good arguments on the table. >> I could nit pick them, but that wouldn't enhance the discussion. > > Hi Paul, let me some comments inline: > > > >> I'd like to pose one more subject for discussion in this thread: >> >> Can the "broad way" be constrained in a way that minimizes abuse - failure >> to interoperate for lack of a common transport when there is no compelling >> reason why a common transport could not have been used. >> >> As that relates to your examples below: >> >> - is *no* communication always preferable to insecure communication? > > I could imagine a "like-Skype" service using SIP protocol and > providing both the server infrastructure and the SIP client (i.e. a > SIP softphone). Such a provider could be interested in secure > communications so its SIP client would just implement TLS-TCP > transport for signaling and SRTP (with DTLS or SDES) for media. The > provider does not want and does not accept that their SIP clients are > reachable via UDP, neither it accepts that their SIP clients > communicate with SIP entities other than their "official" SIP > proxies/servers. A service such as you describe, where all the pieces are provided by a single provider, is a proprietary solution, even if it is built using public standards. The more interesting case is when the service is more open, allowing differing clients, and maybe differing servers as well. That allows tradeoffs to be made. For instance, maybe somebody wants to make a client for your service that can be used by prisoners in a prison. And then maybe there is a law forbidding encryption from being used. (And don't get all over me about the details of the example - it is just the first one that came to mind.) >> - how often are large sip messages universally required by a UA, >> rather than being required in certain contexts? > > A SIP UA typically just registers using a single transport and, in > common scenarios, it is just reachable through the proxy it is > connected to (i.e. Outbound scenarios). Therefore the UA would prefer > to use TCP rather than UDP and then allow big SIP messages (in case > they are needed, as for example when receiving a NOTIFY with a > resource-list XML body). But the UA *may* register with multiple addresses. Or it can register with an fqdn that has entries for multiple transports. But even if it only registers with one, which one to use could be decided at deployment time rather than at implementation time. > If a vendor or provider offers such a service, it might consider a > waste of time to implement UDP transport. I am certainly willing to have a debate of the pros and cons of this. Making support of UDP optional might help to phase it out. >> I know cases can be contrived, but does that apply to a piece of equipment, >> or does it apply to the deployment of that equipment in a particular >> context? > > IMHO it's more related to the network context and security requirements. > > UDP is not valid for all the SIP scenarios (it is not valid for big > messages and it cannot provide security). If a client wants > "security", why should its equipment support and listen into UDP > transport? > > > > Also let me some questions coming to my mind: > > 1) If a SIP phone implements both UDP and TCP, but allows the user to > disable UDP (so it no longer listens into a UDP socket), is that phone > "violating" RFC 3261 or not? This is a valid question to ask - 3261 isn't clear on what it means by "implement". IMO its currently mandatory to implement but not mandatory to use, so its valid to allow disabling it. > 2) If a SIP domain announces DNS NAPTR records just including SCTP > transport or just SCTP and TCP, is it "violating" RFC 3261? Note that > RFC 3263 states that, when NAPTR records are present, those are the > options to reach the server. Again I am inclined to think mandatory to implement, optional to use. So as long as the NAPTR config is a deployment-time decision its ok. >> My point is to figure out if we can construct a revised requirement that >> provides sufficient flexibility where it is needed to create >> implementations, yet doesn't let implementers off the hook when its just >> easier for them to omit support. > > I understand your point in favour of interoperability. Maybe the > following usecase seems a bit ironic: > > - A scenario in which *direct* interoperability with other SIP > transports won't take place (i.e. a SIP stack in JavaScript using > WebSocket transport, and whose SIP outbound proxy provides > interoperability with other SIP transports when required). ISTM that this is a good example of why relaxing the requirements in a careful way could still allow the sorts of interop we need. E.g. relax the requirements on UAs that connect using outbound. >> For instance, I think we would probably still want to say that a transport >> supporting large messages must always be supported. > > I agree. > > > Said that, I also consider that such a new document requires lot of > work and analysis (as you predicted). Otherwise it could become a > risk. So for now I would vote for the narrow way. IMHO nothing prevent > the broad way to take place latter. I'm generally in favor of general approaches to things rather than narrow ones. But I can also see why people might not want to expend the time and effort to sort out all the issues of the general issue, and so do the narrow way for now. And certainly doing that doesn't preclude doing something broader later. Thanks, Paul From nataraju.sip@gmail.com Sun Apr 22 21:58:44 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE58121F851D for ; Sun, 22 Apr 2012 21:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MANGLED_SAVELE=2.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 OeUt-NK7JGb0 for ; Sun, 22 Apr 2012 21:58:40 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A484B21F84EF for ; Sun, 22 Apr 2012 21:58:38 -0700 (PDT) Received: by lbgc1 with SMTP id c1so4401300lbg.31 for ; Sun, 22 Apr 2012 21:58:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Jr9SskABPGrijFcWOocj0Qn4j2J25GMoZweutdyCDgM=; b=sl0ptecpeHAjRWYL7exzoRj3hMnIDgtKVIz1+b6SGBAvCLokr8uPUOwC3u54/Quj5r +/oWWYbV4jNZatN81NAWATCEk9Plg9sSlixThuwXrh12umUZBZKbsMwxfkiyfFrVZgDK qvMijo2pgKQIqozdfk40NiOlJbkr++k0om4xTVv/36A+KJC1SNUqzEMbdrbu3dA3GElK tWVV7Be46GywJXNMCDIkr36PmPS20Kts7LD1bapS0+ph+gspe/2wCnTQ9s2v3B8Yi8a2 0QpQXpGwkl+fm6klrv+2glbVm5rwYH4vY+ukAsFTr6IEz+NEreudzDAqqzdS+RTSO4b6 39LA== MIME-Version: 1.0 Received: by 10.112.84.166 with SMTP id a6mr383631lbz.34.1335157117557; Sun, 22 Apr 2012 21:58:37 -0700 (PDT) Received: by 10.112.36.104 with HTTP; Sun, 22 Apr 2012 21:58:37 -0700 (PDT) Date: Mon, 23 Apr 2012 10:28:37 +0530 Message-ID: From: "Nataraju A.B" To: Adam Roach , "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: multipart/alternative; boundary=f46d0401fde7b61d7b04be517da3 Subject: [sipcore] comments on draft-ietf-sipcore-rfc3265bis-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 04:58:44 -0000 --f46d0401fde7b61d7b04be517da3 Content-Type: text/plain; charset=ISO-8859-1 All, Some logical comments on the draft-ietf-sipcore-rfc3265bis-08.txt. ----------------------------------------------------- 5.3.2. State Deltas CurrentText: If a NOTIFY request arrives that has a version number that is incremented by more than one, the subscriber knows that a state delta has been missed; it ignores the NOTIFY request containing the state delta (except for the version number, which it retains to detect message loss), and re-sends a SUBSCRIBE request to force a NOTIFY request containing a complete state snapshot. Comment: From this text, it infers that if any state delta lost, then subscriber sends refresh SUBSCRIBE (re-SUBSCRIBE) request. This re-SUBSCRIBE request inturn lead to fetching the complete state information. It may be a good diea to differentiate the re-SUBSCRIBE triggered by different scenarios. a) natural re-SUBSCRIBE request, which extends the SUBSCRIBE duration. In this case it is not necessary to fetch the complete state information b) re-SUBSCRIBE triggered because of lost NOTIFY request (ref sec 5.3.2. VERSION number in received NOTIFY is increased by greater than ONE). In this case subscriber wants to fetch the complete state information. If we don't differentiate these two cases, then natural re-SUBSCRIBE request unnecessarily fetch the complete state information, which may not be necessary / expected. But uses higher network bandwidth to fetch the complete state information. ----------------------------------------------------- ----------------------------------------------------- 4.4.1. Dialog Creation and Termination CurrentText: A subscriber may send a SUBSCRIBE request with an "Expires" header field of 0 in order to trigger the sending of such a NOTIFY request; however, for the purposes of subscription and dialog lifetime, the subscription is not considered terminated until the NOTIFY transaction with a "Subscription-State" of "terminated" completes. Comment: We may have to mention how long the dialog must be kept alive, before being cleaned up. Should we delete the dialog immediately after 200-SUB or wait till NOTIFY with "Subscription-State"="terminated". If we always wait till Last Notify for dialog termination, then 200-SUB don't have any impact on the dialog termination. Atleast some normative text is of necessity, for better understanding of the topic. ----------------------------------------------------- ----------------------------------------------------- 3.1.1. Subscription Duration CurrentText: SUBSCRIBE requests SHOULD contain an "Expires" header field (defined in [RFC3261]). This expires value indicates the duration of the subscription. In order to keep subscriptions effective beyond the duration communicated in the "Expires" header field, subscribers need to refresh subscriptions on a periodic basis using a new SUBSCRIBE request on the same dialog as defined in [RFC3261]. Comment: We can add a normative text saying, the refresh time will be normally 50% to 75% of subscription duration. ----------------------------------------------------- ----------------------------------------------------- 4.1.2.1. Requesting a Subscription CurrentText: [RFC3261]. For the sake of clarity: if a SUBSCRIBE request contains an "Accept" header field, but that field does not indicate a media type that the notifier is capable of generating in its NOTIFY requests, then the proper error response is 406 (Not Acceptable). COMMENT: It is better to mention it as a normative text (indented). ----------------------------------------------------- ----------------------------------------------------- 4.1.2. Creating and Maintaining Subscriptions CurrentText: From the subscriber's perspective, a subscription proceeds according to the following state diagram: Comment: Here it is better to mention, what happens to FSM when 200-SUBSCRIBE received in notify_wait state (because very often this is possible). If no change in state of FSM, then some normative text shall convey the same. It may be no-operation, but better to mention the same. ----------------------------------------------------- ----------------------------------------------------- 3.1.1. Subscription Duration CurrentText: In addition to being a request to unsubscribe, a SUBSCRIBE request with "Expires" of 0 also causes a fetch of state; see Section 4.4.3. Comment: The above text has been mentioned to be normative text. But I feel this shall be written as a regualr text in the draft/rfc. because this is the expected behavior from the notifier. ----------------------------------------------------- ----------------------------------------------------- 3.2.1. CurrentText: This body will contain either the state of the subscribed resource or a pointer to such state in the form of a URI (see Section 5.4.13). ReplacementText/Comment: This body **SHALL** contain either the state of the subscribed resource or a pointer to such state in the form of a **URL** (see Section 5.4.13). ----------------------------------------------------- ----------------------------------------------------- 4.2.1. Subscription Establishment and Maintenance CurrentText: inability to signal the success of a REFER request while signaling a problem with the subscription; and difficulty performing one action without the other. Additionally, the proper exchange of ReplacementText: inability to signal the success of a REFER request while signaling a problem with the subscription; and difficulty **in** performing one action without the other. Additionally, the proper exchange of ----------------------------------------------------- Thanks, Nataraju A B ---------- Forwarded message ---------- From: Nataraju A.B Date: Fri, Apr 13, 2012 at 10:53 PM Subject: draft-ietf-sipcore-rfc3265bis-08.txt - Review comments (Nataraju A B) To: Adam Roach , sipcore@ietf.org Adam, Please find some editorial comments on the draft "draft draft-ietf-sipcore-rfc3265bis-08.txt" For simplicity, I have mentioned both the current text and proposed text. The comments / corrective text can be found with prefix and suffix --- ** ----------------------------------------------------- 1.1. Overview of Operation CurrentText: The general concept is that entities in the network can subscribe to resource or call state for various resources or calls in the network, and those entities (or entities acting on their behalf) can send notifications when those states change. ReplacementText: The general concept is that entities in the network can subscribe to resource or call state **at / of** various resources or calls in the network, and those entities (or entities acting on their behalf) **who** can send notifications when those states change. ----------------------------------------------------- 1.1. Overview of Operation CurrentText: Subscriptions are expired and must be refreshed by subsequent SUBSCRIBE requests. ReplacementText: Subscriptions are expired and must be refreshed by subsequent SUBSCRIBE requests **before expiration**. ----------------------------------------------------- 2. Definitions CurrentText: Subscriber: A subscriber is a user agent which receives NOTIFY requests from notifiers; these NOTIFY requests contain information about the state of a resource in which the subscriber is interested. Subscribers typically also generate SUBSCRIBE requests and send them to notifiers to create subscriptions. Comment: After this information, we can add a normative text which indicates when a SIP entity might get NOTIFY messages without actually sending SUBSCRIBE request. For example, REFER request might end up with implicit subscription. Also mention any other requests which may lead to implicit subscriptions (other than REFER). ----------------------------------------------------- 2. Definitions CurrentText: Subscription: A subscription is a set of application state associated with a dialog. This application state includes a pointer to the associated dialog, the event package name, and possibly an identification token. Event packages will define additional subscription state information. By definition, subscriptions exist in both a subscriber and a notifier. ReplacementText: Subscription: A subscription is a set of application **states** associated with a dialog. **The** application state includes a pointer to the associated dialog, the event package name, and possibly an identification token. Event packages will define additional subscription state information. By definition, subscriptions exist in both a subscriber and a notifier. ----------------------------------------------------- 3.1.1. Subscription Duration CurrentText: subscription. In order to keep subscriptions effective beyond the duration communicated in the "Expires" header field, subscribers need to refresh subscriptions on a periodic basis using a new SUBSCRIBE request on the same dialog as defined in [RFC3261]. ReplacementText 3.1.1. Subscription Duration subscription. In order to keep subscriptions effective beyond the duration communicated in the "Expires" header field, subscribers need to refresh subscriptions **before expiration** on a periodic basis using a new SUBSCRIBE request on the same dialog as defined in [RFC3261]. ----------------------------------------------------- 3.1.1. Subscription Duration CurrentText: In addition to being a request to unsubscribe, a SUBSCRIBE request with "Expires" of 0 also causes a fetch of state; see Section 4.4.3. Comment: The above text has been mentioned to be normative text. But I feel this shall be written as a regualr text in the draft/rfc. because this is the expected behavior from the notifier. ----------------------------------------------------- 3.1.2. Identification of Subscribed Events and Event Classes CurrentText: Subscribers MUST include exactly one "Event" header field in SUBSCRIBE requests, indicating to which event or class of events they are subscribing. The "Event" header field will contain a token which indicates the type of state for which a subscription is being requested. This token will be registered with the IANA and will correspond to an event package which further describes the semantics of the event or event class. ReplacementText: Subscribers MUST include exactly one "Event" header field in SUBSCRIBE requests, indicating to which event or class of events they are subscribing. The "Event" header field **MUST** contain a token which indicates the type of state for which a subscription is being requested. This token will be registered with the IANA and will correspond to an event package which further describes the semantics of the event or event class. ----------------------------------------------------- 3.1. SUBSCRIBE CurrentText: The SUBSCRIBE method is used to request current state and state updates from a remote node. SUBSCRIBE requests are target refresh ReplacementText: The SUBSCRIBE method is used to request current state and **subsequent** state updates from a remote node. SUBSCRIBE requests are target refresh ----------------------------------------------------- 3.1.1. Subscription Duration CurrentText: SUBSCRIBE requests SHOULD contain an "Expires" header field (defined in [RFC3261]). This expires value indicates the duration of the subscription. In order to keep subscriptions effective beyond the duration communicated in the "Expires" header field, subscribers need to refresh subscriptions on a periodic basis using a new SUBSCRIBE request on the same dialog as defined in [RFC3261]. Comment: We can add a normative text saying, the refresh time will be normally 50% to 75% of subscription duration. ----------------------------------------------------- 3.2.1. CurrentText: This body will contain either the state of the subscribed resource or a pointer to such state in the form of a URI (see Section 5.4.13). ReplacementText/Comment: This body **SHALL** contain either the state of the subscribed resource or a pointer to such state in the form of a **URL** (see Section 5.4.13). ----------------------------------------------------- 4.1.2. Creating and Maintaining Subscriptions CurrentText: From the subscriber's perspective, a subscription proceeds according to the following state diagram: Comment: Here it is better to mention, what happens to FSM when 200-SUBSCRIBE received in notify_wait state (because very often this is possible). If no change in state of FSM, then some normative text shall convey the same. It may be no-operation, but better to mention the same. ----------------------------------------------------- 4.1.2.1. Requesting a Subscription CurrentText: When a subscriber wishes to subscribe to a particular state for a resource, it forms a SUBSCRIBE request. If the initial SUBSCRIBE ReplacementText: When a subscriber wishes to subscribe to a particular state **of** a resource, it forms a SUBSCRIBE request **according to sec 3.1 and send it across to notifier**. If the initial SUBSCRIBE ----------------------------------------------------- 4.1.2.1. Requesting a Subscription CurrentText: [RFC3261]. For the sake of clarity: if a SUBSCRIBE request contains an "Accept" header field, but that field does not indicate a media type that the notifier is capable of generating in its NOTIFY requests, then the proper error response is 406 (Not Acceptable). COMMENT: It is better to mention it as a normative text (indented). ----------------------------------------------------- 4.1.3. Receiving and Processing State Information CurrentText: If the "Subscription-State" value is "terminated", the subscriber MUST consider the subscription terminated. The "expires" parameter has no semantics for "terminated" -- notifiers SHOULD NOT include an ReplacementText: If the "Subscription-State" value is "terminated", the subscriber MUST consider the subscription terminated. The "expires" parameter has no semantics for "terminated" **state**. Notifiers SHOULD NOT include an ----------------------------------------------------- CurrentText: deactivated: The subscription has been terminated, but the subscriber SHOULD retry immediately with a new subscription. One ReplacementText: deactivated: The subscription has been terminated, but the subscriber SHOULD retry with a new subscription. One Is It mandatory to resubscribe immediately. if not remove the word "immediately". If it is delayed, what are the consequences ???? ----------------------------------------------------- 4.2.1. Subscription Establishment and Maintenance CurrentText: inability to signal the success of a REFER request while signaling a problem with the subscription; and difficulty performing one action without the other. Additionally, the proper exchange of ReplacementText: inability to signal the success of a REFER request while signaling a problem with the subscription; and difficulty **in** performing one action without the other. Additionally, the proper exchange of ----------------------------------------------------- 4.2.1.4. Refreshing of Subscriptions CurrentText: If no refresh for a notification address is received before its expiration time, the subscription is removed. When removing a ReplacementText: If no refresh for a notification is received before its expiration time, the subscription is removed. When removing a Comment: Word "address" needs to be removed. ----------------------------------------------------- 4.3. Proxy Behavior CurrentText: Proxies that did not add a Record-Route header field to the initial SUBSCRIBE request MUST NOT add a Record-Route header field to any of the associated NOTIFY requests. ReplacementText: Proxies that did not add a Record-Route header field to the initial SUBSCRIBE request MUST NOT add a Record-Route header field to any of the associated NOTIFY requests **or any SUBSCRIBE refresh requests**. ----------------------------------------------------- 4.4.1. Dialog Creation and Termination CurrentText: A subscriber may send a SUBSCRIBE request with an "Expires" header field of 0 in order to trigger the sending of such a NOTIFY request; however, for the purposes of subscription and dialog lifetime, the subscription is not considered terminated until the NOTIFY transaction with a "Subscription-State" of "terminated" completes. Comment: We may have to mention how long the dialog must be kept alive, before being cleaned up. Do we delete the dialog immediately after 200-SUB or wait till NOTIFY with "Subscription-State"="terminated". If we always wait till Last Notify for dialog termination, then 200-SUB don't have any impact on the dialog termination. Atleast some normative text is of necessity, for better understanding of the topic. ----------------------------------------------------- 4.4.3. Polling Resource State CurrentText: Note that the NOTIFY requests triggered by SUBSCRIBE requests with "Expires" header fields of 0 will contain a "Subscription-State" value of "terminated", and a "reason" parameter of "timeout". ReplacementText: Note that the NOTIFY requests triggered by SUBSCRIBE requests with "Expires" header fields of 0 **shall** contain a "Subscription-State" value of "terminated", and a "reason" parameter of "timeout". ----------------------------------------------------- 4.5.2. Sharing Dialogs CurrentText: for a dialog (e.g., route set handling). In particular, multiple subscriptions within a dialog are expire independently, and require independent subscription refreshes. ReplacementText: for a dialog (e.g., route set handling). In particular, multiple subscriptions within a dialog **operates** independently, and require independent subscription refreshes. ----------------------------------------------------- 4.5.2. Sharing Dialogs CurrentText: o Subscribers MAY include an "id" parameter in SUBSCRIBE request "Event" header field to allow differentiation between multiple ReplacementText: o Subscribers MAY include an "id" parameter in SUBSCRIBE **request's** "Event" header field to allow differentiation between multiple OR o Subscribers MAY include an "id" parameter in **"Event" header field of SUBSCRIBE request** to allow differentiation between multiple ----------------------------------------------------- 4.5.2. Sharing Dialogs CurrentText: o When a subscriber refreshes a the subscription timer, the SUBSCRIBE request MUST contain the same "Event" header field "id" parameter as was present in the SUBSCRIBE request that created the subscription. (Otherwise, the notifier will interpret the ReplacementText: o When a subscriber refreshes a the subscription timer, the SUBSCRIBE request MUST contain the same **"id" parameter in "Event" header field, which** was present in the SUBSCRIBE request that created the subscription. (Otherwise, the notifier will interpret the ----------------------------------------------------- 4.5.2. Sharing Dialogs CurrentText: o When a subscription is created in the notifier, it stores any "Event" header field "id" parameter as part of the subscription information (along with the event package name). ReplacementText: o When a subscription is created in the notifier, it stores **the** **"id" parameter in "Event" header field** as part of the subscription information (along with the event package name). ----------------------------------------------------- 4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions CurrentText: Neither SUBSCRIBE nor NOTIFY requests can be canceled. If a UAS receives a CANCEL request that matches a known SUBSCRIBE or NOTIFY transaction, it MUST respond to the CANCEL request, but otherwise ignore it. In particular, the CANCEL request MUST NOT affect processing of the SUBSCRIBE or NOTIFY request in any way. ReplacementText/Comment: What should be the response code for the CANCEL's reply ??? Preferably 200-OK shall be used. ----------------------------------------------------- 4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions CurrentText: UACs SHOULD NOT send CANCEL requests for SUBSCRIBE or NOTIFY transactions. ReplacementText: UACs **MUST** NOT send CANCEL requests for SUBSCRIBE or NOTIFY transactions. **UASs SHOULD send 200OK for CANCEL within NOTIFY or SUBSCRIBE transaction duration. As per sec 9 of [RFC3261]** ----------------------------------------------------- 5.3.2. State Deltas CurrentText: In the case that the state information to be conveyed is large, the event package may choose to detail a scheme by which NOTIFY requests contain state deltas instead of complete state. ReplacementText: In the case that the state information to be conveyed is large, the event package may choose a scheme by which NOTIFY requests contain state deltas instead of complete state. comment: deleted words "to detail" in 2nd line. ----------------------------------------------------- 5.3.2. State Deltas CurrentText: If a NOTIFY request arrives that has a version number that is incremented by more than one, the subscriber knows that a state delta has been missed; it ignores the NOTIFY request containing the state delta (except for the version number, which it retains to detect message loss), and re-sends a SUBSCRIBE request to force a NOTIFY request containing a complete state snapshot. Comment: From this text, it infers that if any state delta lost, then subscriber sends refresh SUBSCRIBE (re-SUBSCRIBE) request. This re-SUBSCRIBE request inturn lead to fetching the complete state information. It may be a good diea to differentiate the re-SUBSCRIBE triggered by different scenarios. a) natural re-SUBSCRIBE request, which extends the SUBSCRIBE duration. In this case it is *not *necessary to fetch the complete state information b) re-SUBSCRIBE triggered because of lost NOTIFY request (ref sec 5.3.2. VERSION number in received NOTIFY is increased by greater than ONE). In this case subscriber wants to fetch the complete state information. If we don't differentiate these two cases, then natural re-SUBSCRIBE request unnecessarily fetch the complete state information, which may not be necessary / expected. But uses higher network bandwidth to fetch the complete state information. ----------------------------------------------------- 5.4.7. Notifier generation of NOTIFY requests CurrentText: This section may optionally describe the behavior used to process the subsequent response. Comment: In this section 5.4.7, the above statement is not clear, what is really meant to be. ----------------------------------------------------- 5.4.13. Use of URIs to Retrieve State CurrentText: ReplacementText: In this context, I feel Use of "URLs" is more appropriate than "URIs". ----------------------------------------------------- Thanks, Nataraju A.B. E-ID : nataraju.ab@gmail.com / nataraju.sip@gmail.com +91-98455-95744 -- Thanks, Nataraju A.B. --f46d0401fde7b61d7b04be517da3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All,

<= div class=3D"gmail_extra">Some logical comments on the draft-ietf-sipcore-r= fc3265bis-08.txt.

------------------------------------------------= -----
5.3.2. =A0State Deltas

CurrentText:

=A0 =A0If a NOTIFY request arrives tha= t has a version number that is
=A0 =A0incre= mented by more than one, the subscriber knows that a state delta
=A0 =A0has been missed; it ignores the NOTIFY request containing the state<= /div>
=A0 =A0delta (except for the version number= , which it retains to detect
=A0 =A0message= loss), and re-sends a SUBSCRIBE request to force a NOTIFY
=A0 =A0request containing a complete state snaps= hot.

C= omment:
=A0 =A0From this text, it infers th= at if any state delta lost, then subscriber=A0
=A0 =A0sends refresh SUBSCRIBE (re-SUBSCRIBE) re= quest. This re-SUBSCRIBE request inturn lead=A0
=A0 =A0to fetching the complete state information.=A0

=A0 =A0It may be a good diea to differ= entiate the re-SUBSCRIBE triggered by different scenarios.
=A0 =A0a) natural re-SUBSCRIBE request, which extends the = SUBSCRIBE duration. In this=A0
=A0 =A0 =A0 case it is not necessary to fetch th= e complete state information
=A0 =A0b) re-S= UBSCRIBE triggered because of lost NOTIFY request (ref sec 5.3.2.=A0
<= div class=3D"gmail_extra"> =A0 =A0 =A0 VERSION number in received NOTIFY is increased by greater than = ONE).=A0
=A0 =A0 =A0 In this case subscribe= r wants to fetch the complete state information.

=A0 =A0If we don't differentiate these two c= ases, then natural re-SUBSCRIBE request
=A0= =A0unnecessarily fetch the complete state information, which may not be ne= cessary / expected.=A0
=A0 =A0But uses higher network bandwidth to fetc= h the complete state information.
---------= --------------------------------------------
-----------------------------------------------------
4.4.1. =A0Dialog Creation and Termination
<= div class=3D"gmail_extra">
CurrentText:=

=A0 = =A0 =A0 A subscriber may send a SUBSCRIBE request with an "Expires&quo= t; header
=A0 =A0 =A0 field of 0 in order to trigger the s= ending of such a NOTIFY
=A0 =A0 =A0 request= ; however, for the purposes of subscription and dialog
=A0 =A0 =A0 lifetime, the subscription is not considered termin= ated until the
=A0 =A0 =A0 NOTIFY transaction with a "Subs= cription-State" of "terminated"
=A0 =A0 =A0 completes.

Comment:
We may have to mention how long the dialog must be kept alive, b= efore=A0
being cleaned up. Should we delete the dialog immediately after = 200-SUB=A0
or = wait till NOTIFY with "Subscription-State"=3D"terminated&quo= t;. If we always=A0
wait till Last Notify for dialog termination, then 20= 0-SUB don't have any=A0
imp= act on the dialog termination. Atleast some normative text is of=A0
neces= sity, for better understanding of the topic.
------------------------------------------------= -----
-------------------------------------= ----------------
3.1.1. =A0Subscription Dur= ation

CurrentText= :

=A0 = =A0SUBSCRIBE requests SHOULD contain an "Expires" header field (d= efined
=A0 =A0in [RFC3261]). =A0This expires value indi= cates the duration of the
=A0 =A0subscripti= on. =A0In order to keep subscriptions effective beyond the
=A0 =A0duration communicated in the "Expires" header field, subsc= ribers need
=A0 =A0to refresh subscriptions= on a periodic basis using a new SUBSCRIBE
= =A0 =A0request on the same dialog as defined in [RFC3261].

Comment:
= We can add a normative text saying, the refresh time will be
nor= mally 50% to 75% of subscription duration.
=
--------------------------------------= ---------------
------------------------------------------------= -----
4.1.2.1. =A0Requesting a Subscription=

Curre= ntText:
=A0 =A0[RFC3261]. =A0For the sake of clarity: if= a SUBSCRIBE request contains
=A0 =A0an &qu= ot;Accept" header field, but that field does not indicate a media
=A0 =A0type that the notifier is capable of generating in its NOTIFY
<= div class=3D"gmail_extra">=A0 =A0requests, then the proper error response i= s 406 (Not Acceptable).

COMMENT:
It is better to mention it as a normative text (indented).
=

-----------------------------------------------------
-----------------------------------------------------
4.1.2. =A0Creating and Maintaining Subscriptions


C= urrentText:

=A0 =A0From the subscriber's perspective, a subscription proceeds= according
=A0 =A0to the following state diagram:

Comment:
<= div class=3D"gmail_extra"> Here= it is better to mention, what happens to FSM when 200-SUBSCRIBE=A0
rec= eived in notify_wait state (because very often this is possible).
If no c= hange in state of FSM, then some normative text shall convey the same.
=A0 =A0 =A0 =A0 It may be no-operation, but bett= er to mention the same.
-------------------= ----------------------------------
--------= ---------------------------------------------
3.1.1. =A0Subscription Duration

CurrentText:
=A0 =A0 =A0 In addition to being a request to unsub= scribe, a SUBSCRIBE request
=A0 =A0 =A0 with "Expires" of 0 also c= auses a fetch of state; see
=A0 =A0 =A0 Sec= tion 4.4.3.

Comment:
=A0 =A0 =A0The above text has been mentioned to = be normative text. But I feel this=A0
=A0 = =A0 =A0shall be written as a regualr text in the draft/rfc. because this is= the=A0
=A0 =A0 =A0expected behavior from the notifier.
-----------------------------------------------------
-----------------------------------------------------
3.2.1.=A0

CurrentText:
=A0 =A0This body will cont= ain either the state of the subscribed resource or
=A0 =A0a pointer to such state in the form of a URI (see Section 5.= 4.13).

Replacement= Text/Comment:
=A0 =A0This body **SHALL** co= ntain either the state of the subscribed resource or
=A0 =A0a pointer to such state in the form of a **URL** (see Section 5.4.13= ).
----------------------------------------= -------------
-----------------------------= ------------------------
4.2.1. =A0Subscription Establishment and Mainten= ance

C= urrentText:
=A0 =A0 =A0 inability to signal= the success of a REFER request while signaling
=A0 =A0 =A0 a problem with the subscription; and= difficulty performing one
=A0 =A0 =A0 acti= on without the other. =A0Additionally, the proper exchange of

ReplacementText:
=A0 =A0 =A0 inability to signal the success of a REFER request w= hile signaling
=A0 =A0 =A0 a problem with t= he subscription; and difficulty **in** performing one
=A0 =A0 =A0 action without the other. =A0Additio= nally, the proper exchange of

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

Thanks,
Nataraju A B

---------- Forwarded= message ----------
From: Nataraju A.B= <nataraju.sip@gmail.com>
Date: Fri, Apr 13, 2012 at 10:53 PM
Subject: draft-ietf-sipcore-rfc3265b= is-08.txt - Review comments (Nataraju A B)
To: Adam Roach <adam@nostrum.com>, sipcore@ietf.org


Adam,
Please find some editorial comm= ents on the draft "draft=A0draft-ietf-sipcore-rfc3265bis-08.txt"<= br clear=3D"all">

For simplicity, I have mentioned = both the current text and proposed text.

The comments / correct= ive text can be found with prefix and suffix =A0--- **

-----------------------------------------------------
1.1. =A0Overview of Operation
CurrentText:
=A0 =A0The general concept is that entities in= the network can subscribe to
=A0 =A0resource or call state for various reso= urces or calls in the network,
=A0= =A0and those entities (or entities acting on their behalf) can send=
=A0 =A0notifications when those states change.

ReplacementText:
=A0 =A0The general concept is that entities in the= network can subscribe to
=A0 =A0r= esource or call state **at / of** various resources or calls in the network= ,
=A0 =A0and those entities (or entities acting = on their behalf) **who** can send
=A0 =A0notifications when those states change.=
---------------------------------= --------------------

1.1. =A0Overview of Operation

CurrentTe= xt:
=A0 =A0Subscriptions are expir= ed and must be refreshed by subsequent
=A0 =A0SUBSCRIBE requests.

Replace= mentText:
=A0 =A0Subscriptions are= expired and must be refreshed by subsequent
=A0 =A0SUBSCRIBE requests **before expiration*= *.
-------------------------------= ----------------------

= 2. =A0Definitions

CurrentText:
=A0 =A0Subscriber: =A0A subscriber is a user agent which receives = NOTIFY
=A0 =A0 =A0 requests from notifiers; these NOT= IFY requests contain information
=A0 =A0 =A0 about the state of a resource in w= hich the subscriber is
=A0 =A0 =A0= interested. =A0Subscribers typically also generate SUBSCRIBE
<= div>=A0 =A0 =A0 requests and send them to notifiers= to create subscriptions.

= Comment:
After this information, we can add a normative text whi= ch indicates=A0
w= hen a SIP entity might get NOTIFY messages without actually=A0
s= ending SUBSCRIBE request. For example, REFER request might end up with=A0
implicit subscription. Also mention any other requests which may = lead to=A0
i= mplicit subscriptions (other than REFER).
-----------------------------------------------------
<= div> 2. =A0Definitions

CurrentText:
=A0 =A0Subscription: = =A0A subscription is a set of application state
=A0 =A0 =A0 associated with a dialog. =A0This application sta= te includes a
=A0 =A0 =A0 pointer to the associated dialog, = the event package name, and
=A0 =A0 =A0 possibly an identification token. = =A0Event packages will define
=A0 = =A0 =A0 additional subscription state information. =A0By definition,=
=A0 =A0 =A0 subscriptions exist in both = a subscriber and a notifier.

= ReplacementText:
=A0 =A0Subscripti= on: =A0A subscription is a set of application **states**
<= font color=3D"#000099">=A0 =A0 =A0 associated with a dialog. =A0**The** app= lication state includes a
=A0 =A0 =A0 pointer to the associated dialog, = the event package name, and
=A0 =A0 =A0 possibly an identification token. = =A0Event packages will define
=A0 = =A0 =A0 additional subscription state information. =A0By definition,=
=A0 =A0 =A0 subscriptions exist in both = a subscriber and a notifier.
----------------------------------------------= -------
3.1.1. =A0Subscription Dur= ation

CurrentText:

= =A0 =A0subscription. =A0In order to keep subscriptions effective beyond the=
=A0 =A0duration communicated in the "Expi= res" header field, subscribers need
=A0 =A0to refresh subscriptions on a periodic basis using a new SUBS= CRIBE
=A0 =A0request on the same dialog as defined i= n [RFC3261].

= ReplacementText
3.1.1. =A0Subscrip= tion Duration

=A0 =A0subscription. =A0In order to keep subscrip= tions effective beyond the
=A0 =A0duration communicated in the "Expi= res" header field, subscribers need
=A0 =A0to refresh subscriptions **before expir= ation** on a periodic basis using a new SUBSCRIBE
=A0 =A0request on the same dialog as defined in [RFC3261].<= /font>
----------------------------------------------= -------
3.1.1. =A0Subscription Duration

Cu= rrentText:
=A0 =A0 =A0 In addition= to being a request to unsubscribe, a SUBSCRIBE request
=A0 =A0 =A0 with "Expires" of 0 also= causes a fetch of state; see
=A0 =A0 =A0 Section 4.4.3.

Comment= :
=A0 =A0 =A0The above text has be= en mentioned to be normative text. But I feel this=A0
=A0 =A0 =A0shall be written as a regualr text = in the draft/rfc. because this is the=A0
=A0 =A0 =A0expected behavior from the notifier= .
--------------------------------= ---------------------
3.1.2. =A0Id= entification of Subscribed Events and Event Classes

= CurrentText:
=A0 =A0Subscribers MUST include exactly one &q= uot;Event" header field in
= =A0 =A0SUBSCRIBE requests, indicating to which event or class of events the= y
=A0 =A0are subscribing. =A0The "Event&quo= t; header field will contain a token which
=A0 =A0indicates the type of state for which a= subscription is being
=A0 =A0requ= ested. =A0This token will be registered with the IANA and will
=
=A0 =A0correspond to an event package which fu= rther describes the semantics
=A0 =A0of the event or event class.


ReplacementText:
=A0 =A0Subscribers MUST include exactly one "E= vent" header field in
=A0 =A0= SUBSCRIBE requests, indicating to which event or class of events they
=A0 =A0are subscribing. =A0The "Event&quo= t; header field **MUST** contain a token which
=A0 =A0indicates the type of state for which a subscription is= being
=A0 =A0requested. =A0This token will be regist= ered with the IANA and will
=A0 =A0correspond to an event package which fu= rther describes the semantics
=A0 = =A0of the event or event class.
--= ---------------------------------------------------
3.1. =A0SUBSCRIBE

CurrentText:
=A0 =A0The SUBSCRIBE method is used to request current= state and state
=A0 =A0updates fr= om a remote node. =A0SUBSCRIBE requests are target refresh

=
ReplacementText:
=A0 =A0The SUBSCR= IBE method is used to request current state and **subsequent** state=
=A0 =A0updates from a remote node. =A0SU= BSCRIBE requests are target refresh

=
----------------------------------------------= -------
3.1.1. =A0Subscription Dur= ation

CurrentText:

= =A0 =A0SUBSCRIBE requests SHOULD contain an "Expires" header fiel= d (defined
=A0 =A0in [RFC3261]). =A0This expires value in= dicates the duration of the
=A0 = =A0subscription. =A0In order to keep subscriptions effective beyond the
=A0 =A0duration communicated in the "Expires&q= uot; header field, subscribers need
=A0 =A0to refresh subscriptions on a periodic = basis using a new SUBSCRIBE
=A0 = =A0request on the same dialog as defined in [RFC3261].

Comment:
We can add a = normative text saying, the refresh time will be
n= ormally 50% to 75% of subscription duration.

----------------= -------------------------------------
3.2.1.=A0

CurrentText:
=A0 =A0This body will contain either the state of the = subscribed resource or
=A0 =A0a po= inter to such state in the form of a URI (see Section 5.4.13).

= ReplacementText/Comment:
=A0 =A0This body **SHALL** contain either the = state of the subscribed resource or
=A0 =A0a pointer to such state in the form of a **URL** (see Section 5.4.= 13).
----------------------------------------------= -------
4.1.2. =A0Creating and Maintaining Subscriptio= ns


CurrentText:

= =A0 =A0From the subscriber's perspective, a subscription proceeds accor= ding
=A0 =A0to the following state= diagram:

= Comment:
Here it is better to mention, what happens to FSM when = 200-SUBSCRIBE=A0
r= eceived in notify_wait state (because very often this is possible).<= /div>
I= f no change in state of FSM, then some normative text shall convey the same= .
=A0 =A0 =A0 =A0 It may be no-ope= ration, but better to mention the same.
----------------------------------------------= -------
4.1.2.1. =A0Requesting a S= ubscription

= CurrentText:
=A0 =A0When a subscri= ber wishes to subscribe to a particular state for a
=A0 =A0resource, it forms a SUBSCRIBE request. =A0If the = initial SUBSCRIBE

= ReplacementText:
=A0 =A0When a subscriber wishes to subscribe t= o a particular state **of** a
=A0 = =A0resource, it forms a SUBSCRIBE request **according to sec 3.1 and send i= t across to notifier**. =A0If the initial SUBSCRIBE

-----= ------------------------------------------------
4.1.2.1. =A0Requesting a Subscription

CurrentText:
=A0 =A0[RFC3261]. =A0For the sake of clarity: if a SUB= SCRIBE request contains
=A0 =A0an "Accept" header field, but= that field does not indicate a media
=A0 =A0type that the notifier is capable of generating in its NOTIFY
=A0 =A0requests, then the proper error respons= e is 406 (Not Acceptable).

= COMMENT:
It is better to mention it as a normative text (indente= d).

= -----------------------------------------------------
4.1.3. =A0Receiving and Processing State Infor= mation

CurrentText:
=A0 =A0If the "Subscription-State" v= alue is "terminated", the subscriber
=A0 =A0MUST consider the subscription terminated. =A0The "= ;expires" parameter
=A0 =A0has no semantics for "terminated&q= uot; -- notifiers SHOULD NOT include an

ReplacementText:=

= =A0 =A0If the "Subscription-State" value is "terminated"= ;, the subscriber
=A0 =A0MUST consider the subscription terminat= ed. =A0The "expires" parameter
=A0 =A0has no semantics for "terminated" **state**. Notifi= ers SHOULD NOT include an
----------------------------------------------= -------

= CurrentText:
=A0 =A0deactivated: = =A0The subscription has been terminated, but the
=A0 =A0 =A0 subscriber SHOULD retry immediately with a new s= ubscription. =A0One

= ReplacementText:
=A0 =A0deactivated: =A0The subscription has be= en terminated, but the
=A0 =A0 =A0= subscriber SHOULD retry with a new subscription. =A0One
<= font color=3D"#000099">
=A0 =A0Is It mandatory to resubsc= ribe immediately. if not remove the word "immediately".
=A0 =A0If it is delayed, what are the conseque= nces ????

-----------------------------------------------------=
4.2.1. =A0Subscription Establishment and Maint= enance

CurrentText:
= =A0 =A0 =A0 inability to signal the success of a REFER request while signal= ing
=A0 =A0 =A0 a problem with the subscription; a= nd difficulty performing one
=A0 = =A0 =A0 action without the other. =A0Additionally, the proper exchange of

Repla= cementText:
=A0 =A0 =A0 inability = to signal the success of a REFER request while signaling
=A0 =A0 =A0 a problem with the subscription; a= nd difficulty **in** performing one
=A0 =A0 =A0 action without the other. =A0Additionally, the proper exchang= e of

= -----------------------------------------------------
4.2.1.4. =A0Refreshing of Subscriptions=

CurrentText:
=A0 =A0If no re= fresh for a notification address is received before its
=A0 =A0expiration time, the subscription is re= moved. =A0When removing a

= ReplacementText:
=A0 =A0If no refr= esh for a notification is received before its
=A0 =A0expiration time, the subscription is removed. =A0When r= emoving a
<= /span>
Comment: = Word "address" needs to be removed.
-----------------------------------------------------
4.3. =A0Proxy Behavior

Curre= ntText:
=A0 =A0Proxies that did no= t add a Record-Route header field to the initial
=A0 =A0SUBSCRIBE request MUST NOT add a Record-Route header = field to any of
=A0 =A0the associated NOTIFY requests.<= /div>

= ReplacementText:
=A0 =A0Proxies th= at did not add a Record-Route header field to the initial
= =A0 =A0SUBSCRIBE request MUST NOT add a Record-Rout= e header field to any of
=A0 =A0the associated NOTIFY requests **or any= SUBSCRIBE refresh requests**.
----------------------------------------------= -------
4.4.1. =A0Dialog Creation = and Termination

<= div> CurrentText:

=A0 =A0 =A0 A subscriber m= ay send a SUBSCRIBE request with an "Expires" header
=A0 =A0 =A0 field of 0 in order to trigger the= sending of such a NOTIFY
=A0 =A0 = =A0 request; however, for the purposes of subscription and dialog
=A0 =A0 =A0 lifetime, the subscription is n= ot considered terminated until the
=A0 =A0 =A0 NOTIFY transaction with a "Su= bscription-State" of "terminated"
=A0 =A0 =A0 completes.

Comment:
We may have to mention how= long the dialog must be kept alive, before=A0
b= eing cleaned up. Do we delete the dialog immediately after 200-SUB=A0
<= /span>or wait till NOTIFY with "Subscription-State"=3D"termi= nated". If we always=A0
w= ait till Last Notify for dialog termination, then 200-SUB don't have an= y=A0
impact on the dialog termination. Atleast some normative te= xt is of=A0
n= ecessity, for better understanding of the topic.
-----------------------------------------------------=
4.4.3. =A0Polling Resource State

= CurrentText:

=A0 =A0Note that the NOTIFY requests triggered by = SUBSCRIBE requests with
=A0 =A0"Expires" header fields of 0 = will contain a "Subscription-State"
=A0 =A0value of "terminated", and a = "reason" parameter of "timeout".

Replacemen= tText:
=A0 =A0Note that the NOTIFY requests triggered= by SUBSCRIBE requests with
=A0 =A0"Expires" header fields of 0 = **shall** contain a "Subscription-State"
=A0 =A0value of "terminated", and a "reason= " parameter of "timeout".
----------------------------------------------= -------
4.5.2. =A0Sharing Dialogs

CurrentT= ext:
=A0 =A0 =A0 for a dialog (e.g= ., route set handling). =A0In particular, multiple
=A0 =A0 =A0 subscriptions within a dialog are = expire independently, and
=A0 =A0 =A0 require independent subscription r= efreshes.

ReplacementText:
=A0 =A0 =A0 for a dialog (e.g., route set handling). =A0In particular,= multiple
=A0 =A0 =A0 subscriptions within a dialog **op= erates** independently, and
=A0 =A0 =A0 require independent subscription r= efreshes.
------------------------= -----------------------------
4.5.= 2. =A0Sharing Dialogs

= CurrentText:
=A0 =A0o =A0Subscribe= rs MAY include an "id" parameter in SUBSCRIBE request
=A0 =A0 =A0 "Event" header field to = allow differentiation between multiple

ReplacementText:<= /div>
=A0 =A0o =A0Subscribers MAY include an "id&quo= t; parameter in SUBSCRIBE **request's**
=A0 =A0 =A0 "Event" header field to = allow differentiation between multiple
OR
=A0 =A0o =A0Subscribers MAY include an "id"= parameter in **"Event" header field
=A0 =A0 =A0 of SUBSCRIBE request** to allow di= fferentiation between multiple
---= --------------------------------------------------
4.5.2. =A0Sharing Dialogs

= CurrentText:
=A0 =A0o =A0When a subscriber refreshes a the subscription timer, the
=A0 =A0 =A0 SUBSCRIBE request MUST cont= ain the same "Event" header field "id"
=A0 =A0 =A0 parameter as was present in the SUBSCR= IBE request that created the
=A0 =A0 =A0 subscription. =A0(Otherwise, the n= otifier will interpret the

ReplacementText:
=A0 =A0o =A0When a subscriber refreshes a the subscri= ption timer, the
=A0 =A0 =A0 SUBSCRIBE request MUST contain the= same **"id" parameter in "Event"=A0
=A0 =A0 =A0 header field, which** was present = in the SUBSCRIBE request that created the
=A0 =A0 =A0 subscription. =A0(Otherwise, the notifier will interpre= t the
----------------------------------------------= -------
4.5.2. =A0Sharing Dialogs

CurrentT= ext:

=A0 =A0o =A0When a subscription is created in the notifier= , it stores any
=A0 =A0 =A0 "Event" header field &qu= ot;id" parameter as part of the subscription
=A0 =A0 =A0 information (along with the event = package name).

ReplacementText:
=A0 =A0o =A0When a subscription is created in the notifier, it st= ores **the**
=A0 =A0 =A0 **"id" parameter in &quo= t;Event" header field** as part of the subscription
=A0 =A0 =A0 information (along with the event = package name).
-------------------= ----------------------------------
4.6. =A0CANCEL Requests for SUBSCRIBE and NOTIFY Transactions

= CurrentText:

= =A0 =A0Neither SUBSCRIBE nor NOTIFY requests can be canceled. =A0If a UAS
=A0 =A0receives a CANCEL request th= at matches a known SUBSCRIBE or NOTIFY
=A0 =A0transaction, it MUST respond to the CAN= CEL request, but otherwise
=A0 =A0ignore it. =A0In particular, the CANCEL= request MUST NOT affect
=A0 =A0pr= ocessing of the SUBSCRIBE or NOTIFY request in any way.

ReplacementText/Comment:
What should be the response code for the CANCEL's reply ???
P= referably 200-OK shall be used.
--= ---------------------------------------------------
4.6. =A0CANCEL Requests for SUBSCRIBE and NOTIFY Transact= ions

= CurrentText:

=A0 =A0UACs SHOULD NOT send CANCEL requests for SU= BSCRIBE or NOTIFY
=A0 =A0transactions.

ReplacementTe= xt:
=A0 =A0UACs **MUST** NOT send = CANCEL requests for SUBSCRIBE or NOTIFY
=A0 =A0transactions. **UASs SHOULD send 200OK = for CANCEL within NOTIFY=A0
=A0 = =A0or SUBSCRIBE transaction duration. As per sec 9 of [RFC3261]**
-------------------------------------------= ----------
5.3.2. =A0State Deltas

= CurrentText:

=A0 =A0In the case that the state information to b= e conveyed is large, the
=A0 =A0event package may choose to detail a sc= heme by which NOTIFY requests
=A0 =A0contain state deltas instead of complete state.


ReplacementText:
=A0 =A0In the case that the state information to be co= nveyed is large, the
=A0 =A0event package may choose a scheme by wh= ich NOTIFY requests
=A0 =A0contain state deltas instead of complet= e state.

comment: d= eleted words "to detail" in 2nd line.

-----------------------------------------------------
5.3.2. =A0State Deltas

CurrentText:<= /div>

= =A0 =A0If a NOTIFY request arrives that has a version number that is=
=A0 =A0incremented by more than one, the subscriber knows that a state delt= a
=A0 =A0has been missed; it ignor= es the NOTIFY request containing the state
=A0 =A0delta (except for the version number, which it retains to d= etect
=A0 =A0message loss), and re-sends a SUBSCRIBE= request to force a NOTIFY
=A0 =A0= request containing a complete state snapshot.

Comment:
=A0 =A0From this text, it infers that if any state delta l= ost, then subscriber=A0
=A0 =A0sends refresh SUBSCRIBE (re-SUBSCRIBE) = request. This re-SUBSCRIBE request inturn lead=A0
=A0 =A0to fetching the complete state information.=A0

=A0 = =A0It may be a good diea to differentiate the re-SUBSCRIBE triggered by dif= ferent scenarios.
=A0 =A0a) natural re-SUBSCRIBE request, which = extends the SUBSCRIBE duration. In this=A0
=A0 =A0 =A0 case it is not necessary to fetch the complete = state information
=A0 =A0b) re-SUBSCRIBE triggered because of lo= st NOTIFY request (ref sec 5.3.2.=A0
=A0 =A0 =A0 VERSION number in received NOTIFY = is increased by greater than ONE).=A0
=A0 =A0 =A0 In this case subscriber wants to fetch the complete state i= nformation.

= =A0 =A0If we don't differentiate these two cases, then natural re-SUBSC= RIBE request
=A0 =A0unnecessarily fetch the complete state = information, which may not be necessary / expected.=A0
=A0 =A0But uses higher network bandwidth to fetch the = complete state information.
----------------------------------------------= -------
5.4.7. =A0Notifier generation of NOTIFY reques= ts

CurrentText:
=A0 = =A0This section may optionally describe the behavior used to process the
=A0 =A0subsequent response.
<= font color=3D"#000099">
Comment:
=A0 =A0In this section 5.4.7, the above statement is not c= lear, what is really meant to be.
=
----------------------------------------------= -------
5.4.13. =A0Use of URIs to = Retrieve State

= CurrentText:

ReplacementText:
=A0 =A0In this context, I feel Use of "URLs" is more appr= opriate than "URIs".=A0
----------------------------------------------= -------


Thanks,
Nataraju A.B.
+91-98455-95744



--
<= font face=3D"'courier new', monospace" size=3D"1">Thanks,
Nataraju A.B.

--f46d0401fde7b61d7b04be517da3-- From pravindran@sonusnet.com Sun Apr 22 22:32:27 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FA521F853B for ; Sun, 22 Apr 2012 22:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] 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 yYuXfSE3zf-e for ; Sun, 22 Apr 2012 22:32:24 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5C37621F8534 for ; Sun, 22 Apr 2012 22:32:23 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKT5TpZlt2thxTn7ZG/rmdYyg3nJH1fzR3@postini.com; Sun, 22 Apr 2012 22:32:23 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 23 Apr 2012 01:32:21 -0400 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.0355.002; Mon, 23 Apr 2012 11:02:17 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Websocket is a new transport or new URI? Thread-Index: AQHNIDOCuN/qLU9tjk656lTA6m0G85am5VEAgAD8KaA= Date: Mon, 23 Apr 2012 05:32:16 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> In-Reply-To: <4F9460AC.2080605@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 05:32:28 -0000 Paul, Could you please explain your view of why SIPS URI is a mistake for TLS tra= nsport. I'm interested in knowing as apart from RFC 3261, Sec 3.1.4 of RFC = 5630 (recent RFC) also recommends the usage of SIPS URI with TCP as a trans= port for TLS over TCP (http://tools.ietf.org/html/rfc5630#page-5) and there= is an explicit statement in the same para "This specification does not make use of the transport=3Dtls parameter." Thanks Partha >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >Behalf Of Paul Kyzivat >Sent: Monday, April 23, 2012 1:19 AM >To: sipcore@ietf.org >Subject: Re: [sipcore] Websocket is a new transport or new URI? > >Partha, > >IMO the main thing we learned about sips is that it was a bad idea. >I don't support making that mistake again. > > Thanks, > Paul > >On 4/21/12 10:55 PM, Ravindran, Parthasarathi wrote: >> Sal& others, >> >> After reading lot of mails and thinking further, I agree with you that >Websocket is an application protocol that is used as an transport for >SIP. TLS is one another application protocol on top of TCP which was >considered as transport (transport=3Dtls) earlier and deprecated as part >of RFC 3261 in Sec 26.2.2. TLS and Websocket has some unique behavior >like hop-by-hop protocol rather than end-to-end. >> >> TLS is adopted within SIP using new URI namely SIPS with >transport=3Dtcp. In the same way, I'm proposing SIPWS which implies >websocket over TCP, SIPWSS which implies websocket over TLS over TCP. >Please let me know your opinion on the same. >> >> Thanks >> Partha >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>> Behalf Of Salvatore Loreto >>> Sent: Wednesday, April 18, 2012 7:41 PM >>> To: sipcore@ietf.org >>> Subject: Re: [sipcore] Stateless or Transaction stateful proxy >>> possible in Websocket transport? [RE: Call for Adoption: >>> draft-ibc-sipcore-sip- websocket-02] >>> >>> On 4/18/12 4:40 PM, Christer Holmberg wrote: >>>> Hi, >>>> >>>> I may have misunderstood something in the conversation, but my >>> suggestion would be to consider *NOT* mandating SIP WebSocket clients >>> to implement SIP UDP and TCP. >>>> >>>> Especially if I write a JavaScript SIP browser app, I very likely >>> would want to support only WebSocket. >>>> >>>> Also, I don't think we can directly compare with SCTP, since the >>> typical use-case for WebSocket is browser apps (eventhough a native >>> app can of course also use WS). >>> >>> I think that in general we can not compare SCTP to WebSocket at all >>> because the first is a pure Transport Protocol, the latter is an >>> application protocol that is used as transport. >>> >>> From a pure WebSocket prospective, what you are going to define is >>> SIP as a websocket sub-protocol that is transported on top of. >>> >>> The important thing to standardize from a SIPCore prospective is the >>> interaction/translations that happens between the WebSocket server >>> and the SIP proxy that are two different logical entities. >>> >>> my two cents >>> Sal >>> >>> -- >>> Salvatore Loreto, PhD >>> www.sloreto.com >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From saul@ag-projects.com Mon Apr 23 00:48:21 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9ED21F85C6 for ; Mon, 23 Apr 2012 00:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.658 X-Spam-Level: X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] 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 YlR7JdKsqGKS for ; Mon, 23 Apr 2012 00:48:20 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 72F5921F8587 for ; Mon, 23 Apr 2012 00:48:20 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 72919B01B2; Mon, 23 Apr 2012 09:48:19 +0200 (CEST) Received: from [192.168.99.53] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id A9574B019C; Mon, 23 Apr 2012 09:48:18 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Mon, 23 Apr 2012 09:48:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) Cc: sipcore@ietf.org Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 07:48:21 -0000 >=20 >=20 >> - how often are large sip messages universally required by a UA, >> rather than being required in certain contexts? >=20 > A SIP UA typically just registers using a single transport and, in > common scenarios, it is just reachable through the proxy it is > connected to (i.e. Outbound scenarios). Therefore the UA would prefer > to use TCP rather than UDP and then allow big SIP messages (in case > they are needed, as for example when receiving a NOTIFY with a > resource-list XML body). >=20 > If a vendor or provider offers such a service, it might consider a > waste of time to implement UDP transport. >=20 Big payloads are often associated with presence but IIRC there is a = vendor who could not use UDP due to big payloads and it was just using = SDP. An imaginary example: a video streaming service built with SIP: = several video streams for different video qualities and profiles, = several audio streams for the different languages and several chat = streams for the subtitles in different languages. That could get big :-) -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Mon Apr 23 00:53:47 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9693821F85DF for ; Mon, 23 Apr 2012 00:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=0.039, 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 4w4I9DV16eJE for ; Mon, 23 Apr 2012 00:53:43 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF8121F85D9 for ; Mon, 23 Apr 2012 00:53:43 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4676298vcb.31 for ; Mon, 23 Apr 2012 00:53:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=KGUOijOv6uWCjGs8+NlximmD1zzrfQ2ndIEUiRXBR8s=; b=NdOu/IH8ywiFeUCmye+BWvAS5NpJ3Fd1vF7gZUntJMBFbDnMO5Wo8vH6Pg0v8caqt7 2PoszX+UdSXqdAgzU0pNJOttNO1lvnQg1u7UfdvjG5+sEBaGOjagIRSJsxnD3BzF88hE Hth5waWywtP2GZr0JEoU2XeH5egxY0dqGU4Ab10tHYYPf1bs2YlZGRZ7Rj+4ji0UVnCa 7Z0qlQN0dC4eHC7Qa312Yu0JQtYNKx9D8GLtYrFl8G4AMR1powZ1qAYAdZuvEn4JpjY7 bPVNLMOh2PWkJCJATHipPNRptl9CIuW1XlOOrAloGerEITAZsWV4ugJPPGoVSZj8A26p QIvw== Received: by 10.220.49.66 with SMTP id u2mr5049739vcf.2.1335167622875; Mon, 23 Apr 2012 00:53:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Mon, 23 Apr 2012 00:53:22 -0700 (PDT) In-Reply-To: <4F9465A4.5070108@alum.mit.edu> References: <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> <4F9465A4.5070108@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 23 Apr 2012 09:53:22 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlhbil9JNn1nQR0DJ4I8+H9qojlS0XhhRBHeZQkQ3Y7mg5JzPyZqiF9rZ1PhxK4KmssXQ5O Cc: sipcore@ietf.org Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 07:53:48 -0000 2012/4/22 Paul Kyzivat : >> I could imagine a "like-Skype" service using SIP protocol and >> providing both the server infrastructure and the SIP client (i.e. a >> SIP softphone). Such a provider could be interested in secure >> communications so its SIP client would just implement TLS-TCP >> transport for signaling and SRTP (with DTLS or SDES) for media. The >> provider does not want and does not accept that their SIP clients are >> reachable via UDP, neither it accepts that their SIP clients >> communicate with SIP entities other than their "official" SIP >> proxies/servers. > > > A service such as you describe, where all the pieces are provided by a > single provider, is a proprietary solution, even if it is built using pub= lic > standards. > > The more interesting case is when the service is more open, allowing > differing clients, and maybe differing servers as well. That allows > tradeoffs to be made. > > For instance, maybe somebody wants to make a client for your service that > can be used by prisoners in a prison. And then maybe there is a law > forbidding encryption from being used. (And don't get all over me about t= he > details of the example - it is just the first one that came to mind.) The example is good :) But it is still decision of the service provider whether to offer a transport other than a secure one. This is, the provider could let clients to use their own SIP clients but still require TLS-TCP as unique transport. But in that case we are indeed talking about service-agnostic SIP UA's that won't *use* some transports (UDP and insecure TCP) at deployment time. So there was no reason to *build* those SIP UA's with no support for those transports. Therefore I agree with you. >> 1) If a SIP phone implements both UDP and TCP, but allows the user to >> disable UDP (so it no longer listens into a UDP socket), is that phone >> "violating" RFC 3261 or not? > > > This is a valid question to ask - 3261 isn't clear on what it means by > "implement". > > IMO its currently mandatory to implement but not mandatory to use, so its > valid to allow disabling it. > > >> 2) If a SIP domain announces DNS NAPTR records just including SCTP >> transport or just SCTP and TCP, is it "violating" RFC 3261? Note that >> RFC 3263 states that, when NAPTR records are present, those are the >> options to reach the server. > > > Again I am inclined to think mandatory to implement, optional to use. So = as > long as the NAPTR config is a deployment-time decision its ok. After rethinking about those two questions I also consider that these cases don't violate RFC 3261. And it is unlikely to mandate people to *enable* all the mandatory-to-implement transports in any scenario. >> - A scenario in which *direct* interoperability with other SIP >> transports won't take place (i.e. a SIP stack in JavaScript using >> WebSocket transport, and whose SIP outbound proxy provides >> interoperability with other SIP transports when required). > > > ISTM that this is a good example of why relaxing the requirements in a > careful way could still allow the sorts of interop we need. E.g. relax th= e > requirements on UAs that connect using outbound. And I might add "...and the Outbound proxy/registrar server(s) provides interoperability with UDP and TCP transports". > I'm generally in favor of general approaches to things rather than narrow > ones. But I can also see why people might not want to expend the time and > effort to sort out all the issues of the general issue, and so do the nar= row > way for now. And certainly doing that doesn't preclude doing something > broader later. If in the future there was interest on the broad way (the separate document updating RFC 3261) I would like to help. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Mon Apr 23 00:54:43 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDD9B21F860B for ; Mon, 23 Apr 2012 00:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.661 X-Spam-Level: X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] 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 tCckZ7T6R1y8 for ; Mon, 23 Apr 2012 00:54:42 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 602F821F8603 for ; Mon, 23 Apr 2012 00:54:42 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 02C9DB01B4; Mon, 23 Apr 2012 09:54:40 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 56C26B019C; Mon, 23 Apr 2012 09:54:40 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <4F9465A4.5070108@alum.mit.edu> Date: Mon, 23 Apr 2012 09:54:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <22B393D6-9246-4AD6-8F64-1F6CF70D9E9A@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> <4F9465A4.5070108@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1084) Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , sipcore@ietf.org Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 07:54:44 -0000 Hi Paul, [snip] >>=20 >> Also let me some questions coming to my mind: >>=20 >> 1) If a SIP phone implements both UDP and TCP, but allows the user to >> disable UDP (so it no longer listens into a UDP socket), is that = phone >> "violating" RFC 3261 or not? >=20 > This is a valid question to ask - 3261 isn't clear on what it means by = "implement". >=20 > IMO its currently mandatory to implement but not mandatory to use, so = its valid to allow disabling it. >=20 That's my reading as well. Assuming that, how is disabling a transport = different from not implementing it? One can claim to implement transport = X but never allow you to use it. Is RFC-compliance the only difference? Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Mon Apr 23 01:11:03 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8006B21F8568 for ; Mon, 23 Apr 2012 01:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vVjE46hMXZM for ; Mon, 23 Apr 2012 01:11:01 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7A221F84E4 for ; Mon, 23 Apr 2012 01:11:01 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4687081vcb.31 for ; Mon, 23 Apr 2012 01:11:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=UrC1XoxNF0nk8Mol1+lH5I9v94cR5NkmiBc+fusbmC4=; b=m2sfcAK+F+e1riaScEH0TunzrboXxIVzmH4rgo1VkwLA/GER+yuudJX1ENGmAAMR2M g58EHDjv6BfA6EkmXKhwCNM69Vuia1UfZLf0ba2UDN2WMIP5/grCQEHvfaka7hjWf2h5 oOkUbvDE1StLyIswr0GiKCRfVQE3NbMN2U6e1aaMhaAEz6wWj6x4c8y09bOTyBiYQIWn oWYGKf1TNSyg8aN6Li8ncJlv5pgYwpRKRK+Eazwx+nbd02VvpH+K4JHFhrHXfSoh9gLz ZLX9Er2gx3jKW1NsaQyBKlI3oTQI77HMWaO2rsE0zad9wfyvYcEphBevUTPovXmIEtji rJ5w== Received: by 10.52.91.72 with SMTP id cc8mr13331334vdb.17.1335168660713; Mon, 23 Apr 2012 01:11:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Mon, 23 Apr 2012 01:10:40 -0700 (PDT) In-Reply-To: <22B393D6-9246-4AD6-8F64-1F6CF70D9E9A@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> <4F9465A4.5070108@alum.mit.edu> <22B393D6-9246-4AD6-8F64-1F6CF70D9E9A@ag-projects.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 23 Apr 2012 10:10:40 +0200 Message-ID: To: =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnNJcHpkl4wXiMsrgAsT9NDiPvWnvOR1gG3pOKZ6pf7FPq1Bz2OzEZVg+s2NmAgQ7e3086l Cc: sipcore@ietf.org Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 08:11:04 -0000 2012/4/23 Sa=C3=BAl Ibarra Corretg=C3=A9 : > That's my reading as well. Assuming that, how is disabling a transport di= fferent from not implementing it? One can claim to implement transport X bu= t never allow you to use it. Is RFC-compliance the only difference? If you buy a phone of vendor XXX which announces UDP transport in its specifications but there is no way to use it, then the vendor lied you :) IMHO the point here is about devices not designed for specific environments, but for "any" environment, so theorically it's good that they MUST implement basic SIP transports as a requirement for announcing a "SIP compliant" label. Whether certain transports are later used or not is a deployment decision which depends on each scenario requirements and topology. Regards. --=20 I=C3=B1aki Baz Castillo From andrew.hutton@siemens-enterprise.com Mon Apr 23 06:57:50 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B9921F85D9 for ; Mon, 23 Apr 2012 06:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_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 WuC2Lomp3oVV for ; Mon, 23 Apr 2012 06:57:48 -0700 (PDT) Received: from senmx12-mx.siemens-enterprise.com (senmx12-mx.siemens-enterprise.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9C2F421F85CC for ; Mon, 23 Apr 2012 06:57:48 -0700 (PDT) Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx.siemens-enterprise.com (Server) with ESMTP id 0603E23F048D; Mon, 23 Apr 2012 15:57:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 23 Apr 2012 15:57:46 +0200 From: "Hutton, Andrew" To: Paul Kyzivat , "sipcore@ietf.org" Date: Mon, 23 Apr 2012 15:53:03 +0200 Thread-Topic: [sipcore] Websocket is a new transport or new URI? Thread-Index: Ac0gwPzXkcOktjZzT9OCVymVcP9OjQAcRb5Q Message-ID: <101C6067BEC68246B0C3F6843BCCC1E3129917F282@MCHP058A.global-ad.net> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> In-Reply-To: <4F9460AC.2080605@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 Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 13:57:50 -0000 I am pretty sure we don't want to any new URI schemes for SIP we will howev= er have to think about sow SIPS applies to websockets if at all. Regards Andy > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: 22 April 2012 20:49 > To: sipcore@ietf.org > Subject: Re: [sipcore] Websocket is a new transport or new URI? >=20 > Partha, >=20 > IMO the main thing we learned about sips is that it was a bad idea. > I don't support making that mistake again. >=20 > Thanks, > Paul >=20 > On 4/21/12 10:55 PM, Ravindran, Parthasarathi wrote: > > Sal& others, > > > > After reading lot of mails and thinking further, I agree with you > that Websocket is an application protocol that is used as an transport > for SIP. TLS is one another application protocol on top of TCP which > was considered as transport (transport=3Dtls) earlier and deprecated as > part of RFC 3261 in Sec 26.2.2. TLS and Websocket has some unique > behavior like hop-by-hop protocol rather than end-to-end. > > > > TLS is adopted within SIP using new URI namely SIPS with > transport=3Dtcp. In the same way, I'm proposing SIPWS which implies > websocket over TCP, SIPWSS which implies websocket over TLS over TCP. > Please let me know your opinion on the same. > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > >> Behalf Of Salvatore Loreto > >> Sent: Wednesday, April 18, 2012 7:41 PM > >> To: sipcore@ietf.org > >> Subject: Re: [sipcore] Stateless or Transaction stateful proxy > possible > >> in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore- > sip- > >> websocket-02] > >> > >> On 4/18/12 4:40 PM, Christer Holmberg wrote: > >>> Hi, > >>> > >>> I may have misunderstood something in the conversation, but my > >> suggestion would be to consider *NOT* mandating SIP WebSocket > clients to > >> implement SIP UDP and TCP. > >>> > >>> Especially if I write a JavaScript SIP browser app, I very likely > >> would want to support only WebSocket. > >>> > >>> Also, I don't think we can directly compare with SCTP, since the > >> typical use-case for WebSocket is browser apps (eventhough a native > app > >> can of course also use WS). > >> > >> I think that in general we can not compare SCTP to WebSocket at all > >> because the first is a pure Transport Protocol, the latter is an > >> application protocol that is used as transport. > >> > >> From a pure WebSocket prospective, what you are going to define is > SIP > >> as a websocket sub-protocol that is transported on top of. > >> > >> The important thing to standardize from a SIPCore prospective is the > >> interaction/translations that happens between the WebSocket server > and > >> the SIP proxy that are two different logical entities. > >> > >> my two cents > >> Sal > >> > >> -- > >> Salvatore Loreto, PhD > >> www.sloreto.com > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Mon Apr 23 07:02:23 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8FF821F8642 for ; Mon, 23 Apr 2012 07:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[AWL=-1.399, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_SAVELE=2.3] 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 YgDYLRQvdtIO for ; Mon, 23 Apr 2012 07:02:22 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 097C021F84D3 for ; Mon, 23 Apr 2012 07:02:21 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta12.westchester.pa.mail.comcast.net with comcast id 1Rid1j0040bG4ec5CS2Nk8; Mon, 23 Apr 2012 14:02:22 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta03.westchester.pa.mail.comcast.net with comcast id 1S2J1j02A07duvL3PS2JAy; Mon, 23 Apr 2012 14:02:19 +0000 Message-ID: <4F9560EC.9030308@alum.mit.edu> Date: Mon, 23 Apr 2012 10:02:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] comments on draft-ietf-sipcore-rfc3265bis-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:02:24 -0000 Nataraju, Your comments would have been much more helpful if received some months ago when the document went through WGLC. This document is now *very* far down the process to publication, having already gone through IESG last call, IANA review, etc. and is now in final IESG Evaluation. Changes at this point are very disruptive. If you feel your suggestions are essential then you will have to go to extremes to pull this document back. I don't see anything below that convinces me to do that. AFAICT the comments below are all minor editorial except for the first, which suggests changing the mechanism. Thanks, Paul (as co-chair) On 4/23/12 12:58 AM, Nataraju A.B wrote: > All, > > Some logical comments on the draft-ietf-sipcore-rfc3265bis-08.txt. > > ----------------------------------------------------- > 5.3.2. State Deltas > > CurrentText: > > If a NOTIFY request arrives that has a version number that is > incremented by more than one, the subscriber knows that a state delta > has been missed; it ignores the NOTIFY request containing the state > delta (except for the version number, which it retains to detect > message loss), and re-sends a SUBSCRIBE request to force a NOTIFY > request containing a complete state snapshot. > > Comment: > From this text, it infers that if any state delta lost, then subscriber > sends refresh SUBSCRIBE (re-SUBSCRIBE) request. This re-SUBSCRIBE > request inturn lead > to fetching the complete state information. > > It may be a good diea to differentiate the re-SUBSCRIBE triggered by > different scenarios. > a) natural re-SUBSCRIBE request, which extends the SUBSCRIBE > duration. In this > case it is not necessary to fetch the complete state information > b) re-SUBSCRIBE triggered because of lost NOTIFY request (ref sec > 5.3.2. > VERSION number in received NOTIFY is increased by greater than ONE). > In this case subscriber wants to fetch the complete state > information. > > If we don't differentiate these two cases, then natural re-SUBSCRIBE > request > unnecessarily fetch the complete state information, which may not be > necessary / expected. > But uses higher network bandwidth to fetch the complete state > information. > ----------------------------------------------------- > ----------------------------------------------------- > 4.4.1. Dialog Creation and Termination > > CurrentText: > > A subscriber may send a SUBSCRIBE request with an "Expires" header > field of 0 in order to trigger the sending of such a NOTIFY > request; however, for the purposes of subscription and dialog > lifetime, the subscription is not considered terminated until the > NOTIFY transaction with a "Subscription-State" of "terminated" > completes. > > Comment: > We may have to mention how long the dialog must be kept alive, before > being cleaned up. Should we delete the dialog immediately after 200-SUB > or wait till NOTIFY with "Subscription-State"="terminated". If we always > wait till Last Notify for dialog termination, then 200-SUB don't have any > impact on the dialog termination. Atleast some normative text is of > necessity, for better understanding of the topic. > ----------------------------------------------------- > ----------------------------------------------------- > 3.1.1. Subscription Duration > > CurrentText: > > SUBSCRIBE requests SHOULD contain an "Expires" header field (defined > in [RFC3261]). This expires value indicates the duration of the > subscription. In order to keep subscriptions effective beyond the > duration communicated in the "Expires" header field, subscribers need > to refresh subscriptions on a periodic basis using a new SUBSCRIBE > request on the same dialog as defined in [RFC3261]. > > Comment: > We can add a normative text saying, the refresh time will be > normally 50% to 75% of subscription duration. > > ----------------------------------------------------- > ----------------------------------------------------- > 4.1.2.1. Requesting a Subscription > > CurrentText: > [RFC3261]. For the sake of clarity: if a SUBSCRIBE request contains > an "Accept" header field, but that field does not indicate a media > type that the notifier is capable of generating in its NOTIFY > requests, then the proper error response is 406 (Not Acceptable). > > COMMENT: > It is better to mention it as a normative text (indented). > > ----------------------------------------------------- > ----------------------------------------------------- > 4.1.2. Creating and Maintaining Subscriptions > > > CurrentText: > > From the subscriber's perspective, a subscription proceeds according > to the following state diagram: > > Comment: > Here it is better to mention, what happens to FSM when 200-SUBSCRIBE > received in notify_wait state (because very often this is possible). > If no change in state of FSM, then some normative text shall convey the > same. > It may be no-operation, but better to mention the same. > ----------------------------------------------------- > ----------------------------------------------------- > 3.1.1. Subscription Duration > > CurrentText: > In addition to being a request to unsubscribe, a SUBSCRIBE request > with "Expires" of 0 also causes a fetch of state; see > Section 4.4.3. > > Comment: > The above text has been mentioned to be normative text. But I feel > this > shall be written as a regualr text in the draft/rfc. because this > is the > expected behavior from the notifier. > ----------------------------------------------------- > ----------------------------------------------------- > 3.2.1. > > CurrentText: > This body will contain either the state of the subscribed resource or > a pointer to such state in the form of a URI (see Section 5.4.13). > > ReplacementText/Comment: > This body **SHALL** contain either the state of the subscribed > resource or > a pointer to such state in the form of a **URL** (see Section 5.4.13). > ----------------------------------------------------- > ----------------------------------------------------- > 4.2.1. Subscription Establishment and Maintenance > > CurrentText: > inability to signal the success of a REFER request while signaling > a problem with the subscription; and difficulty performing one > action without the other. Additionally, the proper exchange of > > ReplacementText: > inability to signal the success of a REFER request while signaling > a problem with the subscription; and difficulty **in** performing one > action without the other. Additionally, the proper exchange of > > ----------------------------------------------------- > > Thanks, > Nataraju A B > > ---------- Forwarded message ---------- > From: *Nataraju A.B* > > Date: Fri, Apr 13, 2012 at 10:53 PM > Subject: draft-ietf-sipcore-rfc3265bis-08.txt - Review comments > (Nataraju A B) > To: Adam Roach >, > sipcore@ietf.org > > > Adam, > > Please find some editorial comments on the draft > "draft draft-ietf-sipcore-rfc3265bis-08.txt" > > For simplicity, I have mentioned both the current text and proposed text. > > The comments / corrective text can be found with prefix and suffix --- ** > > ----------------------------------------------------- > 1.1. Overview of Operation > CurrentText: > The general concept is that entities in the network can subscribe to > resource or call state for various resources or calls in the network, > and those entities (or entities acting on their behalf) can send > notifications when those states change. > > ReplacementText: > The general concept is that entities in the network can subscribe to > resource or call state **at / of** various resources or calls in the > network, > and those entities (or entities acting on their behalf) **who** can send > notifications when those states change. > ----------------------------------------------------- > > 1.1. Overview of Operation > > CurrentText: > Subscriptions are expired and must be refreshed by subsequent > SUBSCRIBE requests. > > ReplacementText: > Subscriptions are expired and must be refreshed by subsequent > SUBSCRIBE requests **before expiration**. > ----------------------------------------------------- > > 2. Definitions > > CurrentText: > Subscriber: A subscriber is a user agent which receives NOTIFY > requests from notifiers; these NOTIFY requests contain information > about the state of a resource in which the subscriber is > interested. Subscribers typically also generate SUBSCRIBE > requests and send them to notifiers to create subscriptions. > > Comment: > After this information, we can add a normative text which indicates > when a SIP entity might get NOTIFY messages without actually > sending SUBSCRIBE request. For example, REFER request might end up with > implicit subscription. Also mention any other requests which may lead to > implicit subscriptions (other than REFER). > ----------------------------------------------------- > 2. Definitions > > CurrentText: > Subscription: A subscription is a set of application state > associated with a dialog. This application state includes a > pointer to the associated dialog, the event package name, and > possibly an identification token. Event packages will define > additional subscription state information. By definition, > subscriptions exist in both a subscriber and a notifier. > > ReplacementText: > Subscription: A subscription is a set of application **states** > associated with a dialog. **The** application state includes a > pointer to the associated dialog, the event package name, and > possibly an identification token. Event packages will define > additional subscription state information. By definition, > subscriptions exist in both a subscriber and a notifier. > ----------------------------------------------------- > 3.1.1. Subscription Duration > > CurrentText: > > subscription. In order to keep subscriptions effective beyond the > duration communicated in the "Expires" header field, subscribers need > to refresh subscriptions on a periodic basis using a new SUBSCRIBE > request on the same dialog as defined in [RFC3261]. > > ReplacementText > 3.1.1. Subscription Duration > > subscription. In order to keep subscriptions effective beyond the > duration communicated in the "Expires" header field, subscribers need > to refresh subscriptions **before expiration** on a periodic basis > using a new SUBSCRIBE > request on the same dialog as defined in [RFC3261]. > ----------------------------------------------------- > 3.1.1. Subscription Duration > > CurrentText: > In addition to being a request to unsubscribe, a SUBSCRIBE request > with "Expires" of 0 also causes a fetch of state; see > Section 4.4.3. > > Comment: > The above text has been mentioned to be normative text. But I feel > this > shall be written as a regualr text in the draft/rfc. because this > is the > expected behavior from the notifier. > ----------------------------------------------------- > 3.1.2. Identification of Subscribed Events and Event Classes > > CurrentText: > Subscribers MUST include exactly one "Event" header field in > SUBSCRIBE requests, indicating to which event or class of events they > are subscribing. The "Event" header field will contain a token which > indicates the type of state for which a subscription is being > requested. This token will be registered with the IANA and will > correspond to an event package which further describes the semantics > of the event or event class. > > > ReplacementText: > Subscribers MUST include exactly one "Event" header field in > SUBSCRIBE requests, indicating to which event or class of events they > are subscribing. The "Event" header field **MUST** contain a token > which > indicates the type of state for which a subscription is being > requested. This token will be registered with the IANA and will > correspond to an event package which further describes the semantics > of the event or event class. > ----------------------------------------------------- > 3.1. SUBSCRIBE > > CurrentText: > The SUBSCRIBE method is used to request current state and state > updates from a remote node. SUBSCRIBE requests are target refresh > > > ReplacementText: > The SUBSCRIBE method is used to request current state and > **subsequent** state > updates from a remote node. SUBSCRIBE requests are target refresh > > > ----------------------------------------------------- > 3.1.1. Subscription Duration > > CurrentText: > > SUBSCRIBE requests SHOULD contain an "Expires" header field (defined > in [RFC3261]). This expires value indicates the duration of the > subscription. In order to keep subscriptions effective beyond the > duration communicated in the "Expires" header field, subscribers need > to refresh subscriptions on a periodic basis using a new SUBSCRIBE > request on the same dialog as defined in [RFC3261]. > > Comment: > We can add a normative text saying, the refresh time will be > normally 50% to 75% of subscription duration. > > ----------------------------------------------------- > 3.2.1. > > CurrentText: > This body will contain either the state of the subscribed resource or > a pointer to such state in the form of a URI (see Section 5.4.13). > > ReplacementText/Comment: > This body **SHALL** contain either the state of the subscribed > resource or > a pointer to such state in the form of a **URL** (see Section 5.4.13). > ----------------------------------------------------- > 4.1.2. Creating and Maintaining Subscriptions > > > CurrentText: > > From the subscriber's perspective, a subscription proceeds according > to the following state diagram: > > Comment: > Here it is better to mention, what happens to FSM when 200-SUBSCRIBE > received in notify_wait state (because very often this is possible). > If no change in state of FSM, then some normative text shall convey the > same. > It may be no-operation, but better to mention the same. > ----------------------------------------------------- > 4.1.2.1. Requesting a Subscription > > CurrentText: > When a subscriber wishes to subscribe to a particular state for a > resource, it forms a SUBSCRIBE request. If the initial SUBSCRIBE > > ReplacementText: > When a subscriber wishes to subscribe to a particular state **of** a > resource, it forms a SUBSCRIBE request **according to sec 3.1 and > send it across to notifier**. If the initial SUBSCRIBE > > ----------------------------------------------------- > 4.1.2.1. Requesting a Subscription > > CurrentText: > [RFC3261]. For the sake of clarity: if a SUBSCRIBE request contains > an "Accept" header field, but that field does not indicate a media > type that the notifier is capable of generating in its NOTIFY > requests, then the proper error response is 406 (Not Acceptable). > > COMMENT: > It is better to mention it as a normative text (indented). > > ----------------------------------------------------- > 4.1.3. Receiving and Processing State Information > > CurrentText: > > If the "Subscription-State" value is "terminated", the subscriber > MUST consider the subscription terminated. The "expires" parameter > has no semantics for "terminated" -- notifiers SHOULD NOT include an > > ReplacementText: > > If the "Subscription-State" value is "terminated", the subscriber > MUST consider the subscription terminated. The "expires" parameter > has no semantics for "terminated" **state**. Notifiers SHOULD NOT > include an > ----------------------------------------------------- > > CurrentText: > deactivated: The subscription has been terminated, but the > subscriber SHOULD retry immediately with a new subscription. One > > ReplacementText: > deactivated: The subscription has been terminated, but the > subscriber SHOULD retry with a new subscription. One > > Is It mandatory to resubscribe immediately. if not remove the word > "immediately". > If it is delayed, what are the consequences ???? > > ----------------------------------------------------- > 4.2.1. Subscription Establishment and Maintenance > > CurrentText: > inability to signal the success of a REFER request while signaling > a problem with the subscription; and difficulty performing one > action without the other. Additionally, the proper exchange of > > ReplacementText: > inability to signal the success of a REFER request while signaling > a problem with the subscription; and difficulty **in** performing one > action without the other. Additionally, the proper exchange of > > ----------------------------------------------------- > 4.2.1.4. Refreshing of Subscriptions > > CurrentText: > If no refresh for a notification address is received before its > expiration time, the subscription is removed. When removing a > > ReplacementText: > If no refresh for a notification is received before its > expiration time, the subscription is removed. When removing a > Comment:Word "address" needs to be removed. > ----------------------------------------------------- > 4.3. Proxy Behavior > > CurrentText: > Proxies that did not add a Record-Route header field to the initial > SUBSCRIBE request MUST NOT add a Record-Route header field to any of > the associated NOTIFY requests. > > ReplacementText: > Proxies that did not add a Record-Route header field to the initial > SUBSCRIBE request MUST NOT add a Record-Route header field to any of > the associated NOTIFY requests **or any SUBSCRIBE refresh requests**. > ----------------------------------------------------- > 4.4.1. Dialog Creation and Termination > > CurrentText: > > A subscriber may send a SUBSCRIBE request with an "Expires" header > field of 0 in order to trigger the sending of such a NOTIFY > request; however, for the purposes of subscription and dialog > lifetime, the subscription is not considered terminated until the > NOTIFY transaction with a "Subscription-State" of "terminated" > completes. > > Comment: > We may have to mention how long the dialog must be kept alive, before > being cleaned up. Do we delete the dialog immediately after 200-SUB > or wait till NOTIFY with "Subscription-State"="terminated". If we always > wait till Last Notify for dialog termination, then 200-SUB don't have any > impact on the dialog termination. Atleast some normative text is of > necessity, for better understanding of the topic. > ----------------------------------------------------- > 4.4.3. Polling Resource State > > CurrentText: > > Note that the NOTIFY requests triggered by SUBSCRIBE requests with > "Expires" header fields of 0 will contain a "Subscription-State" > value of "terminated", and a "reason" parameter of "timeout". > > ReplacementText: > Note that the NOTIFY requests triggered by SUBSCRIBE requests with > "Expires" header fields of 0 **shall** contain a "Subscription-State" > value of "terminated", and a "reason" parameter of "timeout". > ----------------------------------------------------- > 4.5.2. Sharing Dialogs > > CurrentText: > for a dialog (e.g., route set handling). In particular, multiple > subscriptions within a dialog are expire independently, and > require independent subscription refreshes. > > ReplacementText: > for a dialog (e.g., route set handling). In particular, multiple > subscriptions within a dialog **operates** independently, and > require independent subscription refreshes. > ----------------------------------------------------- > 4.5.2. Sharing Dialogs > > CurrentText: > o Subscribers MAY include an "id" parameter in SUBSCRIBE request > "Event" header field to allow differentiation between multiple > > ReplacementText: > o Subscribers MAY include an "id" parameter in SUBSCRIBE **request's** > "Event" header field to allow differentiation between multiple > OR > o Subscribers MAY include an "id" parameter in **"Event" header field > of SUBSCRIBE request** to allow differentiation between multiple > ----------------------------------------------------- > 4.5.2. Sharing Dialogs > > CurrentText: > o When a subscriber refreshes a the subscription timer, the > SUBSCRIBE request MUST contain the same "Event" header field "id" > parameter as was present in the SUBSCRIBE request that created the > subscription. (Otherwise, the notifier will interpret the > > ReplacementText: > o When a subscriber refreshes a the subscription timer, the > SUBSCRIBE request MUST contain the same **"id" parameter in "Event" > header field, which** was present in the SUBSCRIBE request that > created the > subscription. (Otherwise, the notifier will interpret the > ----------------------------------------------------- > 4.5.2. Sharing Dialogs > > CurrentText: > > o When a subscription is created in the notifier, it stores any > "Event" header field "id" parameter as part of the subscription > information (along with the event package name). > > ReplacementText: > o When a subscription is created in the notifier, it stores **the** > **"id" parameter in "Event" header field** as part of the > subscription > information (along with the event package name). > ----------------------------------------------------- > 4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions > > CurrentText: > > Neither SUBSCRIBE nor NOTIFY requests can be canceled. If a UAS > receives a CANCEL request that matches a known SUBSCRIBE or NOTIFY > transaction, it MUST respond to the CANCEL request, but otherwise > ignore it. In particular, the CANCEL request MUST NOT affect > processing of the SUBSCRIBE or NOTIFY request in any way. > > ReplacementText/Comment: > What should be the response code for the CANCEL's reply ??? > Preferably 200-OK shall be used. > ----------------------------------------------------- > 4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions > > CurrentText: > > UACs SHOULD NOT send CANCEL requests for SUBSCRIBE or NOTIFY > transactions. > > ReplacementText: > UACs **MUST** NOT send CANCEL requests for SUBSCRIBE or NOTIFY > transactions. **UASs SHOULD send 200OK for CANCEL within NOTIFY > or SUBSCRIBE transaction duration. As per sec 9 of [RFC3261]** > ----------------------------------------------------- > 5.3.2. State Deltas > > CurrentText: > > In the case that the state information to be conveyed is large, the > event package may choose to detail a scheme by which NOTIFY requests > contain state deltas instead of complete state. > > > ReplacementText: > In the case that the state information to be conveyed is large, the > event package may choose a scheme by which NOTIFY requests > contain state deltas instead of complete state. > > comment:deleted words "to detail" in 2nd line. > > ----------------------------------------------------- > 5.3.2. State Deltas > > CurrentText: > > If a NOTIFY request arrives that has a version number that is > incremented by more than one, the subscriber knows that a state delta > has been missed; it ignores the NOTIFY request containing the state > delta (except for the version number, which it retains to detect > message loss), and re-sends a SUBSCRIBE request to force a NOTIFY > request containing a complete state snapshot. > > Comment: > From this text, it infers that if any state delta lost, then subscriber > sends refresh SUBSCRIBE (re-SUBSCRIBE) request. This re-SUBSCRIBE > request inturn lead > to fetching the complete state information. > > It may be a good diea to differentiate the re-SUBSCRIBE triggered by > different scenarios. > a) natural re-SUBSCRIBE request, which extends the SUBSCRIBE > duration. In this > case it is *not *necessary to fetch the complete state information > b) re-SUBSCRIBE triggered because of lost NOTIFY request (ref sec > 5.3.2. > VERSION number in received NOTIFY is increased by greater than ONE). > In this case subscriber wants to fetch the complete state > information. > > If we don't differentiate these two cases, then natural re-SUBSCRIBE > request > unnecessarily fetch the complete state information, which may not be > necessary / expected. > But uses higher network bandwidth to fetch the complete state > information. > ----------------------------------------------------- > 5.4.7. Notifier generation of NOTIFY requests > > CurrentText: > This section may optionally describe the behavior used to process the > subsequent response. > > Comment: > In this section 5.4.7, the above statement is not clear, what is > really meant to be. > > ----------------------------------------------------- > 5.4.13. Use of URIs to Retrieve State > > CurrentText: > > ReplacementText: > In this context, I feel Use of "URLs" is more appropriate than "URIs". > ----------------------------------------------------- > > > Thanks, > Nataraju A.B. > E-ID : nataraju.ab@gmail.com / > nataraju.sip@gmail.com > +91-98455-95744 > > > > -- > Thanks, > Nataraju A.B. > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Mon Apr 23 07:11:22 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B104D21F85CC for ; Mon, 23 Apr 2012 07:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 bKgtCSxAPzio for ; Mon, 23 Apr 2012 07:11:22 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id DF9B821F85B6 for ; Mon, 23 Apr 2012 07:11:21 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta15.westchester.pa.mail.comcast.net with comcast id 1SAV1j00B0Fqzac5FSBL1G; Mon, 23 Apr 2012 14:11:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta08.westchester.pa.mail.comcast.net with comcast id 1SBL1j00V07duvL3USBL7V; Mon, 23 Apr 2012 14:11:21 +0000 Message-ID: <4F956308.30200@alum.mit.edu> Date: Mon, 23 Apr 2012 10:11:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> <4F9465A4.5070108@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:11:22 -0000 On 4/23/12 3:53 AM, IƱaki Baz Castillo wrote: > 2012/4/22 Paul Kyzivat: >>> I could imagine a "like-Skype" service using SIP protocol and >>> providing both the server infrastructure and the SIP client (i.e. a >>> SIP softphone). Such a provider could be interested in secure >>> communications so its SIP client would just implement TLS-TCP >>> transport for signaling and SRTP (with DTLS or SDES) for media. The >>> provider does not want and does not accept that their SIP clients are >>> reachable via UDP, neither it accepts that their SIP clients >>> communicate with SIP entities other than their "official" SIP >>> proxies/servers. >> >> >> A service such as you describe, where all the pieces are provided by a >> single provider, is a proprietary solution, even if it is built using public >> standards. >> >> The more interesting case is when the service is more open, allowing >> differing clients, and maybe differing servers as well. That allows >> tradeoffs to be made. >> >> For instance, maybe somebody wants to make a client for your service that >> can be used by prisoners in a prison. And then maybe there is a law >> forbidding encryption from being used. (And don't get all over me about the >> details of the example - it is just the first one that came to mind.) > > The example is good :) > > But it is still decision of the service provider whether to offer a > transport other than a secure one. This is, the provider could let > clients to use their own SIP clients but still require TLS-TCP as > unique transport. But in that case we are indeed talking about > service-agnostic SIP UA's that won't *use* some transports (UDP and > insecure TCP) at deployment time. So there was no reason to *build* > those SIP UA's with no support for those transports. Therefore I agree > with you. That's good! :) >>> 1) If a SIP phone implements both UDP and TCP, but allows the user to >>> disable UDP (so it no longer listens into a UDP socket), is that phone >>> "violating" RFC 3261 or not? >> >> >> This is a valid question to ask - 3261 isn't clear on what it means by >> "implement". >> >> IMO its currently mandatory to implement but not mandatory to use, so its >> valid to allow disabling it. >> >> >>> 2) If a SIP domain announces DNS NAPTR records just including SCTP >>> transport or just SCTP and TCP, is it "violating" RFC 3261? Note that >>> RFC 3263 states that, when NAPTR records are present, those are the >>> options to reach the server. >> >> >> Again I am inclined to think mandatory to implement, optional to use. So as >> long as the NAPTR config is a deployment-time decision its ok. > > After rethinking about those two questions I also consider that these > cases don't violate RFC 3261. And it is unlikely to mandate people to > *enable* all the mandatory-to-implement transports in any scenario. > > > > > >>> - A scenario in which *direct* interoperability with other SIP >>> transports won't take place (i.e. a SIP stack in JavaScript using >>> WebSocket transport, and whose SIP outbound proxy provides >>> interoperability with other SIP transports when required). >> >> >> ISTM that this is a good example of why relaxing the requirements in a >> careful way could still allow the sorts of interop we need. E.g. relax the >> requirements on UAs that connect using outbound. > > And I might add "...and the Outbound proxy/registrar server(s) > provides interoperability with UDP and TCP transports". Yes. That is what I meant - relax requirement on the UA that supports outbound, but leave the requirement in place for the proxy/registrar. >> I'm generally in favor of general approaches to things rather than narrow >> ones. But I can also see why people might not want to expend the time and >> effort to sort out all the issues of the general issue, and so do the narrow >> way for now. And certainly doing that doesn't preclude doing something >> broader later. > > If in the future there was interest on the broad way (the separate > document updating RFC 3261) I would like to help. Thanks. I'll keep that in mind. Thanks, Paul From pkyzivat@alum.mit.edu Mon Apr 23 07:18:23 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1111E21F8661 for ; Mon, 23 Apr 2012 07:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.363 X-Spam-Level: X-Spam-Status: No, score=-2.363 tagged_above=-999 required=5 tests=[AWL=-0.064, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 NhcUaieGVppe for ; Mon, 23 Apr 2012 07:18:22 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA5221F864A for ; Mon, 23 Apr 2012 07:18:22 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 1SJN1j0050vyq2s5BSJPJ2; Mon, 23 Apr 2012 14:18:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta05.westchester.pa.mail.comcast.net with comcast id 1SJM1j00K07duvL3RSJM6F; Mon, 23 Apr 2012 14:18:22 +0000 Message-ID: <4F9564AB.8010508@alum.mit.edu> Date: Mon, 23 Apr 2012 10:18:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> <4F9465A4.5070108@alum.mit.edu> <22B393D6-9246-4AD6-8F64-1F6CF70D9E9A@ag-projects.com> In-Reply-To: <22B393D6-9246-4AD6-8F64-1F6CF70D9E9A@ag-projects.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , sipcore@ietf.org Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:18:23 -0000 On 4/23/12 3:54 AM, Saśl Ibarra Corretgé wrote: > Hi Paul, > > [snip] > >>> >>> Also let me some questions coming to my mind: >>> >>> 1) If a SIP phone implements both UDP and TCP, but allows the user to >>> disable UDP (so it no longer listens into a UDP socket), is that phone >>> "violating" RFC 3261 or not? >> >> This is a valid question to ask - 3261 isn't clear on what it means by "implement". >> >> IMO its currently mandatory to implement but not mandatory to use, so its valid to allow disabling it. >> > > That's my reading as well. Assuming that, how is disabling a transport different from not implementing it? One can claim to implement transport X but never allow you to use it. Is RFC-compliance the only difference? The difference is that the decision about use is put into the hands of the person deploying the equipment rather than the people writing the code that goes into the equipment. Then, if an interop problem arises due to the choices made during deployment, they can be fixed during deployment merely by reconfiguration. The conformance of the equipment the deployer already bought makes it possible to solve the problem without buying new equipment. Thanks, Paul From pkyzivat@alum.mit.edu Mon Apr 23 07:29:35 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0ADB21F86A4 for ; Mon, 23 Apr 2012 07:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 tGNw14+m3QvT for ; Mon, 23 Apr 2012 07:29:34 -0700 (PDT) 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 5D2DC21F869E for ; Mon, 23 Apr 2012 07:29:34 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta04.westchester.pa.mail.comcast.net with comcast id 1Pik1j00C1uE5Es54SVbDv; Mon, 23 Apr 2012 14:29:35 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id 1SVb1j00i07duvL3cSVbBE; Mon, 23 Apr 2012 14:29:36 +0000 Message-ID: <4F95674C.3020705@alum.mit.edu> Date: Mon, 23 Apr 2012 10:29:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , sipcore@ietf.org Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:29:35 -0000 On 4/23/12 3:48 AM, Saśl Ibarra Corretgé wrote: >> >> >>> - how often are large sip messages universally required by a UA, >>> rather than being required in certain contexts? Note that I am largely playing devil's advocate on this particular issue. >> A SIP UA typically just registers using a single transport and, in >> common scenarios, it is just reachable through the proxy it is >> connected to (i.e. Outbound scenarios). Therefore the UA would prefer >> to use TCP rather than UDP and then allow big SIP messages (in case >> they are needed, as for example when receiving a NOTIFY with a >> resource-list XML body). >> >> If a vendor or provider offers such a service, it might consider a >> waste of time to implement UDP transport. >> > > Big payloads are often associated with presence but IIRC there is a vendor who could not use UDP due to big payloads and it was just using SDP. An imaginary example: a video streaming service built with SIP: several video streams for different video qualities and profiles, several audio streams for the different languages and several chat streams for the subtitles in different languages. That could get big :-) The usual argument, which you seem to be making again, is that some vendor decides it only needs to support UDP because it doesn't anticipate being deployed in any situations where messages will exceed the PDU size. And the usual counter-argument is that it is nearly impossible to guarantee that this will always be the case, and hence the implementation MUST be prepared to use TCP. Here we are arguing the flip side - someone arguing that it NEEDS TCP in all its deployments because it will have *some* big messages in every deployment, and hence sees no reason to implement UDP. I'm just arguing that some deployer might have a usage in mind where UDP *would* work all the time, and hence decide to deploy with only UDP configured. Its a weak argument. But I can imagine someone making it. E.g. somebody might do so in order to optimize a benchmark. Thanks, Paul From pkyzivat@alum.mit.edu Mon Apr 23 07:37:39 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB76321F8686 for ; Mon, 23 Apr 2012 07:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=-0.211, 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 TJzoBVoTbl6v for ; Mon, 23 Apr 2012 07:37:39 -0700 (PDT) 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 D3F1821F867A for ; Mon, 23 Apr 2012 07:37:38 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta13.westchester.pa.mail.comcast.net with comcast id 1QMB1j0031wpRvQ5DSdf0l; Mon, 23 Apr 2012 14:37:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta18.westchester.pa.mail.comcast.net with comcast id 1Sdd1j02Y07duvL3eSddLm; Mon, 23 Apr 2012 14:37:38 +0000 Message-ID: <4F956931.7090404@alum.mit.edu> Date: Mon, 23 Apr 2012 10:37:37 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Ravindran, Parthasarathi" References: <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:37:40 -0000 On 4/23/12 1:32 AM, Ravindran, Parthasarathi wrote: > Paul, > > Could you please explain your view of why SIPS URI is a mistake for TLS transport. My view is that the *intent* of sips was to provide the sort of "guarantee" of security that https provides. But sips doesn't provide that guarantee, because it isn't e2e and a variety of other things. The end result is that with sips you have very little more confidence that you are securely talking to who you think than if you use best effort by using TLS on your first hop. In essence, sips provides a false sense of security to the naive, but little more than that. Thanks, Paul > I'm interested in knowing as apart from RFC 3261, Sec 3.1.4 of RFC 5630 (recent RFC) also recommends the usage of SIPS URI with TCP as a transport for TLS over TCP (http://tools.ietf.org/html/rfc5630#page-5) and there is an explicit statement in the same para > > "This specification does not make use of the transport=tls parameter." > > Thanks > Partha > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Monday, April 23, 2012 1:19 AM >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Websocket is a new transport or new URI? >> >> Partha, >> >> IMO the main thing we learned about sips is that it was a bad idea. >> I don't support making that mistake again. >> >> Thanks, >> Paul >> >> On 4/21/12 10:55 PM, Ravindran, Parthasarathi wrote: >>> Sal& others, >>> >>> After reading lot of mails and thinking further, I agree with you that >> Websocket is an application protocol that is used as an transport for >> SIP. TLS is one another application protocol on top of TCP which was >> considered as transport (transport=tls) earlier and deprecated as part >> of RFC 3261 in Sec 26.2.2. TLS and Websocket has some unique behavior >> like hop-by-hop protocol rather than end-to-end. >>> >>> TLS is adopted within SIP using new URI namely SIPS with >> transport=tcp. In the same way, I'm proposing SIPWS which implies >> websocket over TCP, SIPWSS which implies websocket over TLS over TCP. >> Please let me know your opinion on the same. >>> >>> Thanks >>> Partha >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>>> Behalf Of Salvatore Loreto >>>> Sent: Wednesday, April 18, 2012 7:41 PM >>>> To: sipcore@ietf.org >>>> Subject: Re: [sipcore] Stateless or Transaction stateful proxy >>>> possible in Websocket transport? [RE: Call for Adoption: >>>> draft-ibc-sipcore-sip- websocket-02] >>>> >>>> On 4/18/12 4:40 PM, Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>> I may have misunderstood something in the conversation, but my >>>> suggestion would be to consider *NOT* mandating SIP WebSocket clients >>>> to implement SIP UDP and TCP. >>>>> >>>>> Especially if I write a JavaScript SIP browser app, I very likely >>>> would want to support only WebSocket. >>>>> >>>>> Also, I don't think we can directly compare with SCTP, since the >>>> typical use-case for WebSocket is browser apps (eventhough a native >>>> app can of course also use WS). >>>> >>>> I think that in general we can not compare SCTP to WebSocket at all >>>> because the first is a pure Transport Protocol, the latter is an >>>> application protocol that is used as transport. >>>> >>>> From a pure WebSocket prospective, what you are going to define is >>>> SIP as a websocket sub-protocol that is transported on top of. >>>> >>>> The important thing to standardize from a SIPCore prospective is the >>>> interaction/translations that happens between the WebSocket server >>>> and the SIP proxy that are two different logical entities. >>>> >>>> my two cents >>>> Sal >>>> >>>> -- >>>> Salvatore Loreto, PhD >>>> www.sloreto.com >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From saul@ag-projects.com Mon Apr 23 07:56:30 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA25021F8698 for ; Mon, 23 Apr 2012 07:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.642 X-Spam-Level: X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] 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 VAx04z5v+GAN for ; Mon, 23 Apr 2012 07:56:30 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 17B5921F862A for ; Mon, 23 Apr 2012 07:56:29 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 8736FB01A1; Mon, 23 Apr 2012 16:56:28 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id B85F9B019C; Mon, 23 Apr 2012 16:56:26 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <4F9564AB.8010508@alum.mit.edu> Date: Mon, 23 Apr 2012 16:56:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4B16E110-53AE-4CBE-8603-B7CD9E33404B@ag-projects.com> References: <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> <4F9465A4.5070108@alum.mit.edu> <22B393D6-9246-4AD6-8F64-1F6CF70D9E9A@ag-projects.com> <4F9564AB.8010508@a lum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1084) Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , sipcore@ietf.org Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 14:56:30 -0000 >=20 > The difference is that the decision about use is put into the hands of = the person deploying the equipment rather than the people writing the = code that goes into the equipment. Then, if an interop problem arises = due to the choices made during deployment, they can be fixed during = deployment merely by reconfiguration. The conformance of the equipment = the deployer already bought makes it possible to solve the problem = without buying new equipment. >=20 Thanks for clarifying. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From saul@ag-projects.com Mon Apr 23 08:10:51 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CA521F85CD for ; Mon, 23 Apr 2012 08:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.645 X-Spam-Level: X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] 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 ZvXZ1yiNN7k6 for ; Mon, 23 Apr 2012 08:10:50 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC3321F85C6 for ; Mon, 23 Apr 2012 08:10:50 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 78E1FB01A1; Mon, 23 Apr 2012 17:10:49 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id AD781B019C; Mon, 23 Apr 2012 17:10:36 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <4F95674C.3020705@alum.mit.edu> Date: Mon, 23 Apr 2012 17:10:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> <4F95674C.3020705@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1084) Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , sipcore@ietf.org Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:10:51 -0000 Hi Paul, >>=20 >> Big payloads are often associated with presence but IIRC there is a = vendor who could not use UDP due to big payloads and it was just using = SDP. An imaginary example: a video streaming service built with SIP: = several video streams for different video qualities and profiles, = several audio streams for the different languages and several chat = streams for the subtitles in different languages. That could get big :-) >=20 > The usual argument, which you seem to be making again, is that some = vendor decides it only needs to support UDP because it doesn't = anticipate being deployed in any situations where messages will exceed = the PDU size. And the usual counter-argument is that it is nearly = impossible to guarantee that this will always be the case, and hence the = implementation MUST be prepared to use TCP. >=20 I was trying to expose an example of the opposite :-) This vendor had to = disable UDP support because their SDPs were really huge. > Here we are arguing the flip side - someone arguing that it NEEDS TCP = in all its deployments because it will have *some* big messages in every = deployment, and hence sees no reason to implement UDP. I'm just arguing = that some deployer might have a usage in mind where UDP *would* work all = the time, and hence decide to deploy with only UDP configured. >=20 > Its a weak argument. But I can imagine someone making it. E.g. = somebody might do so in order to optimize a benchmark. >=20 Sure, UDP-only deployments might be possible. It seems like allowing for implementors to disable transports completely = (or not even implement them) could open the can of worms, but at the = same time one could find that limiting in certain environments. I don't = even have a clear opinion on what would be best here :-S Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From pkyzivat@alum.mit.edu Mon Apr 23 08:19:31 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1A421F86F7 for ; Mon, 23 Apr 2012 08:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 NEyrAmNdA5CI for ; Mon, 23 Apr 2012 08:19:30 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE6321F86D4 for ; Mon, 23 Apr 2012 08:19:30 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta07.westchester.pa.mail.comcast.net with comcast id 1ScR1j0070vyq2s57TKXEk; Mon, 23 Apr 2012 15:19:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta05.westchester.pa.mail.comcast.net with comcast id 1TKV1j00V07duvL3RTKVSh; Mon, 23 Apr 2012 15:19:30 +0000 Message-ID: <4F957300.1080106@alum.mit.edu> Date: Mon, 23 Apr 2012 11:19:28 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> <4F95674C.3020705@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , sipcore@ietf.org Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:19:31 -0000 On 4/23/12 11:10 AM, Saśl Ibarra Corretgé wrote: > Hi Paul, > >>> >>> Big payloads are often associated with presence but IIRC there is a vendor who could not use UDP due to big payloads and it was just using SDP. An imaginary example: a video streaming service built with SIP: several video streams for different video qualities and profiles, several audio streams for the different languages and several chat streams for the subtitles in different languages. That could get big :-) >> >> The usual argument, which you seem to be making again, is that some vendor decides it only needs to support UDP because it doesn't anticipate being deployed in any situations where messages will exceed the PDU size. And the usual counter-argument is that it is nearly impossible to guarantee that this will always be the case, and hence the implementation MUST be prepared to use TCP. >> > > I was trying to expose an example of the opposite :-) This vendor had to disable UDP support because their SDPs were really huge. It should not be necessary to disable UDP because messages sometimes get big. As long as both are supported the proper one can be used based on message size. Of course there are some cases where that won't work - e.g. an offerless invite sent via UDP, leading to the need to send an offer in a reply. I suppose that in practice restricting use to TCP would avoid a number of nasty issues. >> Here we are arguing the flip side - someone arguing that it NEEDS TCP in all its deployments because it will have *some* big messages in every deployment, and hence sees no reason to implement UDP. I'm just arguing that some deployer might have a usage in mind where UDP *would* work all the time, and hence decide to deploy with only UDP configured. >> >> Its a weak argument. But I can imagine someone making it. E.g. somebody might do so in order to optimize a benchmark. >> > > Sure, UDP-only deployments might be possible. > > It seems like allowing for implementors to disable transports completely (or not even implement them) could open the can of worms, but at the same time one could find that limiting in certain environments. I don't even have a clear opinion on what would be best here :-S That is why we are discussing it. :) Thanks, Paul From kpfleming@digium.com Mon Apr 23 08:36:50 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB0E21F85B8 for ; Mon, 23 Apr 2012 08:36:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.507 X-Spam-Level: X-Spam-Status: No, score=-106.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 8TNtJaKap7x1 for ; Mon, 23 Apr 2012 08:36:49 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id E36BD21F8470 for ; Mon, 23 Apr 2012 08:36:47 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SMLJm-0004S6-Ll for sipcore@ietf.org; Mon, 23 Apr 2012 10:36:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id A4C12D8004 for ; Mon, 23 Apr 2012 10:36:46 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45GtL0iNcvNM for ; Mon, 23 Apr 2012 10:36:46 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 15437D8002 for ; Mon, 23 Apr 2012 10:36:45 -0500 (CDT) Message-ID: <4F957705.3070003@digium.com> Date: Mon, 23 Apr 2012 10:36:37 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> <4F95674C.3020705@alum.mit.edu> <4F957300.1080106@alum.mit.edu> In-Reply-To: <4F957300.1080106@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:36:51 -0000 On 04/23/2012 10:19 AM, Paul Kyzivat wrote: > On 4/23/12 11:10 AM, Sa=FAl Ibarra Corretg=E9 wrote: >> Hi Paul, >> >>>> >>>> Big payloads are often associated with presence but IIRC there is a >>>> vendor who could not use UDP due to big payloads and it was just >>>> using SDP. An imaginary example: a video streaming service built >>>> with SIP: several video streams for different video qualities and >>>> profiles, several audio streams for the different languages and >>>> several chat streams for the subtitles in different languages. That >>>> could get big :-) >>> >>> The usual argument, which you seem to be making again, is that some >>> vendor decides it only needs to support UDP because it doesn't >>> anticipate being deployed in any situations where messages will >>> exceed the PDU size. And the usual counter-argument is that it is >>> nearly impossible to guarantee that this will always be the case, and >>> hence the implementation MUST be prepared to use TCP. >>> >> >> I was trying to expose an example of the opposite :-) This vendor had >> to disable UDP support because their SDPs were really huge. > > It should not be necessary to disable UDP because messages sometimes ge= t > big. As long as both are supported the proper one can be used based on > message size. Of course there are some cases where that won't work - > e.g. an offerless invite sent via UDP, leading to the need to send an > offer in a reply. Wasn't that the purpose of RFC 3261 mandating support for both though?=20 The same could happen in a SUBSCRIBE dialog; the SUBSCRIBE request and=20 200 OK reply could be sent over UDP, but the first NOTIFY may have to be=20 sent over TCP due to its size. I think I'm in agreement with your 'narrow' approach, because it allows=20 the relaxation to be applied only in cases where an alternate 'large=20 message' transport (other than TCP or TLS/TCP) is being made available.=20 Granted, Asterisk survived for many years only supporting UDP, and it=20 was rare that a user ran into an problem due to message sizes, but with=20 SDPs growing (ICE support is on the way) and complex presence data being=20 transferred, it's clear that some sort of large message transport needs=20 to be supported too. --=20 Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpflemin= g 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From ibc@aliax.net Mon Apr 23 08:38:49 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D6A21F86FD for ; Mon, 23 Apr 2012 08:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, 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 bYZwhLreeso0 for ; Mon, 23 Apr 2012 08:38:48 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA6721F86FC for ; Mon, 23 Apr 2012 08:38:48 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so9591772vbb.31 for ; Mon, 23 Apr 2012 08:38:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=RYU14/u+ECY8ZXBYNat2YlUHSHdYnjTz27dHh17uRpQ=; b=cx2FJT6TWe4T69PhXMNIHSRoRAHhHE3AaLpQ6osqgKcm6iw8MwTbzV28VCFIJDdCPF nsmpyXiaxEZqSKMXq4P68Ba/UdR7UsEXoY5zHa4E7eZJhm+SUKprf0jZ58gE/yR65h0L ECCp99iE8m93xx6l+FpC6DFzkegVN386viu0zaQ/8tzQ6WwJoi+QfvrcRGbc3z5RZPsk 5Vd/ClFcHYPaSv4/hCr7KsrjBLKJaxuzev6Y99579Nyv0g5EaBfwSg55JJzZEJmas062 9VaZPtcbL41GnoxVDrDcN3pCekTXmQU6GpEn3kT67mcQayn/D+Bfk7pU7aK+oZ18MQ/a Fdgg== Received: by 10.52.64.173 with SMTP id p13mr11821916vds.51.1335195525434; Mon, 23 Apr 2012 08:38:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Mon, 23 Apr 2012 08:38:25 -0700 (PDT) In-Reply-To: <4F957300.1080106@alum.mit.edu> References: <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> <4F95674C.3020705@alum.mit.edu> <4F957300.1080106@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 23 Apr 2012 17:38:25 +0200 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlw8/bATJYHNuKO0k7vdpH5thtUxqk915ZVAuGAV7hYOJxgB7yhos1DJ8G5pokP8dJcR5QB Cc: sipcore@ietf.org, =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 15:38:49 -0000 2012/4/23 Paul Kyzivat : > It should not be necessary to disable UDP because messages sometimes get > big. As long as both are supported the proper one can be used based on > message size. Of course there are some cases where that won't work - e.g.= an > offerless invite sent via UDP, leading to the need to send an offer in a > reply. Hi Paul, that sounds a bit "theorical" for me. SIP phones usually perform a single registration using a single transport and binding a single Contact URI with same transport than the one used for sending the REGISTER. Indeed a SIP UA could register two URIs (one with ;transport=3Dudp and the other one with tcp), but then it would generate useless parallel forking for initial incoming-requests (and lot of merged requests and 482 responses from the UA). Well, the UA could set different "q" values and give more priority to the UDP binding, so the registrar would just use TCP if sending the request over UDP fails (internal 503). However that would not work for in-dialog requests since the RURI already indicates the transport. IMHO this would be more feasible in the case of proxy to proxy communication, in which proxy A could decide (based on request size) whether to select one or other transport regardless the priority of the NAPTR records, or selecting TCP regarless the RURI has an IP and no ;transport=3Dtcp param. But honestly, in the UA side I don't expect that dynamic selection of the transport could work in "real" scenarios (maybe I'm wrong). Regards. --=20 I=C3=B1aki Baz Castillo From nataraju.sip@gmail.com Mon Apr 23 09:32:29 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02E921F870B for ; Mon, 23 Apr 2012 09:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.057 X-Spam-Level: X-Spam-Status: No, score=0.057 tagged_above=-999 required=5 tests=[AWL=-1.795, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 XzzSwDeVIY4O for ; Mon, 23 Apr 2012 09:32:26 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B7E6621F864D for ; Mon, 23 Apr 2012 09:32:25 -0700 (PDT) Received: by lagj5 with SMTP id j5so9848134lag.31 for ; Mon, 23 Apr 2012 09:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vCZfYB4UoWDe6XCjt0N1wBgA5mY2T86SOpq4t9tIa7E=; b=ZoSAVcucv8JSTucFPFvnvuGbtRHnXfgFAHv+ooNWpguSUUdON9t9pcvvOCNe2uShc7 ziqy+hJuQ9kL0zoRi3H/wWCo1k9WIJgVn1GY8E5E7epIfDdbvRgcKC6he6388eWSLPn9 QLQPu+9ghsEGCQQZoQ3wmz2OFZi3/+g6+p+rAtZJ1PYGQNsp0QPGmA3qnH4uvp+WNqLb WQ7gD00QhwhRPtKuWQvnmLb9iAQhB9bDDvOk83QTEU0otaGBySyymkKFrgc1zzAcoLrG gH0ccUBT5lgzTqg0CJtrWGiIFo7//VEZAFGCHnEdmb53/A8CDWl9jybtScmjEMSd/vzc wdHA== MIME-Version: 1.0 Received: by 10.112.101.162 with SMTP id fh2mr7988874lbb.20.1335198744610; Mon, 23 Apr 2012 09:32:24 -0700 (PDT) Received: by 10.112.36.104 with HTTP; Mon, 23 Apr 2012 09:32:24 -0700 (PDT) In-Reply-To: <4F9560EC.9030308@alum.mit.edu> References: <4F9560EC.9030308@alum.mit.edu> Date: Mon, 23 Apr 2012 22:02:24 +0530 Message-ID: From: "Nataraju A.B" To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d04016a77e086d604be5b2e0b Cc: sipcore@ietf.org Subject: Re: [sipcore] comments on draft-ietf-sipcore-rfc3265bis-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 16:32:29 -0000 --f46d04016a77e086d604be5b2e0b Content-Type: text/plain; charset=ISO-8859-1 Paul, I understand, I was late into the party... :( The comment is more of an OPTIMIZATION issue. As a minimal change, can we add a normative text which provide some pointers for implementers to differentiate the re-SUBSCRIBE (to extend the subscription duration) and re-SUBSCRIBE (to fetch the complete state, due to lost NOTIFY). This might be of great concern for lossy networks (for example, wireless networks, ...), where all the subsequent refresh SUBSCRIBE requests would un-necessarily eats up more bandwidth for fetching the complete state which is not necessary. For non-lossy network this is of minor issue... Even if we decide to handle this optimization issue, we have to analyze thoroughly how to differentiate differentiate these requests, through some new header / header parameter / any other way. Need more analysis... You can take a call, based on the feasibility. Even if dropped it is fine.... Thanks, Nataraju A B On Mon, Apr 23, 2012 at 7:32 PM, Paul Kyzivat wrote: > Nataraju, > > Your comments would have been much more helpful if received some months > ago when the document went through WGLC. This document is now *very* far > down the process to publication, having already gone through IESG last > call, IANA review, etc. and is now in final IESG Evaluation. Changes at > this point are very disruptive. > > If you feel your suggestions are essential then you will have to go to > extremes to pull this document back. I don't see anything below that > convinces me to do that. AFAICT the comments below are all minor editorial > except for the first, which suggests changing the mechanism. > > Thanks, > Paul (as co-chair) > > > On 4/23/12 12:58 AM, Nataraju A.B wrote: > >> All, >> >> Some logical comments on the draft-ietf-sipcore-rfc3265bis-**08.txt. >> >> ------------------------------**----------------------- >> 5.3.2. State Deltas >> >> CurrentText: >> >> If a NOTIFY request arrives that has a version number that is >> incremented by more than one, the subscriber knows that a state delta >> has been missed; it ignores the NOTIFY request containing the state >> delta (except for the version number, which it retains to detect >> message loss), and re-sends a SUBSCRIBE request to force a NOTIFY >> request containing a complete state snapshot. >> >> Comment: >> From this text, it infers that if any state delta lost, then subscriber >> sends refresh SUBSCRIBE (re-SUBSCRIBE) request. This re-SUBSCRIBE >> request inturn lead >> to fetching the complete state information. >> >> It may be a good diea to differentiate the re-SUBSCRIBE triggered by >> different scenarios. >> a) natural re-SUBSCRIBE request, which extends the SUBSCRIBE >> duration. In this >> case it is not necessary to fetch the complete state information >> b) re-SUBSCRIBE triggered because of lost NOTIFY request (ref sec >> 5.3.2. >> VERSION number in received NOTIFY is increased by greater than ONE). >> In this case subscriber wants to fetch the complete state >> information. >> >> If we don't differentiate these two cases, then natural re-SUBSCRIBE >> request >> unnecessarily fetch the complete state information, which may not be >> necessary / expected. >> But uses higher network bandwidth to fetch the complete state >> information. >> ------------------------------**----------------------- >> ------------------------------**----------------------- >> 4.4.1. Dialog Creation and Termination >> >> CurrentText: >> >> A subscriber may send a SUBSCRIBE request with an "Expires" header >> field of 0 in order to trigger the sending of such a NOTIFY >> request; however, for the purposes of subscription and dialog >> lifetime, the subscription is not considered terminated until the >> NOTIFY transaction with a "Subscription-State" of "terminated" >> completes. >> >> Comment: >> We may have to mention how long the dialog must be kept alive, before >> being cleaned up. Should we delete the dialog immediately after 200-SUB >> or wait till NOTIFY with "Subscription-State"="**terminated". If we >> always >> wait till Last Notify for dialog termination, then 200-SUB don't have any >> impact on the dialog termination. Atleast some normative text is of >> necessity, for better understanding of the topic. >> ------------------------------**----------------------- >> ------------------------------**----------------------- >> 3.1.1. Subscription Duration >> >> CurrentText: >> >> SUBSCRIBE requests SHOULD contain an "Expires" header field (defined >> in [RFC3261]). This expires value indicates the duration of the >> subscription. In order to keep subscriptions effective beyond the >> duration communicated in the "Expires" header field, subscribers need >> to refresh subscriptions on a periodic basis using a new SUBSCRIBE >> request on the same dialog as defined in [RFC3261]. >> >> Comment: >> We can add a normative text saying, the refresh time will be >> normally 50% to 75% of subscription duration. >> >> ------------------------------**----------------------- >> ------------------------------**----------------------- >> 4.1.2.1. Requesting a Subscription >> >> CurrentText: >> [RFC3261]. For the sake of clarity: if a SUBSCRIBE request contains >> an "Accept" header field, but that field does not indicate a media >> type that the notifier is capable of generating in its NOTIFY >> requests, then the proper error response is 406 (Not Acceptable). >> >> COMMENT: >> It is better to mention it as a normative text (indented). >> >> ------------------------------**----------------------- >> ------------------------------**----------------------- >> 4.1.2. Creating and Maintaining Subscriptions >> >> >> CurrentText: >> >> From the subscriber's perspective, a subscription proceeds according >> to the following state diagram: >> >> Comment: >> Here it is better to mention, what happens to FSM when 200-SUBSCRIBE >> received in notify_wait state (because very often this is possible). >> If no change in state of FSM, then some normative text shall convey the >> same. >> It may be no-operation, but better to mention the same. >> ------------------------------**----------------------- >> ------------------------------**----------------------- >> 3.1.1. Subscription Duration >> >> CurrentText: >> In addition to being a request to unsubscribe, a SUBSCRIBE request >> with "Expires" of 0 also causes a fetch of state; see >> Section 4.4.3. >> >> Comment: >> The above text has been mentioned to be normative text. But I feel >> this >> shall be written as a regualr text in the draft/rfc. because this >> is the >> expected behavior from the notifier. >> ------------------------------**----------------------- >> ------------------------------**----------------------- >> 3.2.1. >> >> CurrentText: >> This body will contain either the state of the subscribed resource or >> a pointer to such state in the form of a URI (see Section 5.4.13). >> >> ReplacementText/Comment: >> This body **SHALL** contain either the state of the subscribed >> resource or >> a pointer to such state in the form of a **URL** (see Section 5.4.13). >> ------------------------------**----------------------- >> ------------------------------**----------------------- >> 4.2.1. Subscription Establishment and Maintenance >> >> CurrentText: >> inability to signal the success of a REFER request while signaling >> a problem with the subscription; and difficulty performing one >> action without the other. Additionally, the proper exchange of >> >> ReplacementText: >> inability to signal the success of a REFER request while signaling >> a problem with the subscription; and difficulty **in** performing >> one >> action without the other. Additionally, the proper exchange of >> >> ------------------------------**----------------------- >> >> Thanks, >> Nataraju A B >> >> ---------- Forwarded message ---------- >> From: *Nataraju A.B* > > >> Date: Fri, Apr 13, 2012 at 10:53 PM >> Subject: draft-ietf-sipcore-rfc3265bis-**08.txt - Review comments >> (Nataraju A B) >> To: Adam Roach >, >> sipcore@ietf.org >> >> >> Adam, >> >> Please find some editorial comments on the draft >> "draft draft-ietf-sipcore-rfc3265bis-**08.txt" >> >> For simplicity, I have mentioned both the current text and proposed text. >> >> The comments / corrective text can be found with prefix and suffix --- ** >> >> ------------------------------**----------------------- >> 1.1. Overview of Operation >> CurrentText: >> The general concept is that entities in the network can subscribe to >> resource or call state for various resources or calls in the network, >> and those entities (or entities acting on their behalf) can send >> notifications when those states change. >> >> ReplacementText: >> The general concept is that entities in the network can subscribe to >> resource or call state **at / of** various resources or calls in the >> network, >> and those entities (or entities acting on their behalf) **who** can >> send >> notifications when those states change. >> ------------------------------**----------------------- >> >> 1.1. Overview of Operation >> >> CurrentText: >> Subscriptions are expired and must be refreshed by subsequent >> SUBSCRIBE requests. >> >> ReplacementText: >> Subscriptions are expired and must be refreshed by subsequent >> SUBSCRIBE requests **before expiration**. >> ------------------------------**----------------------- >> >> 2. Definitions >> >> CurrentText: >> Subscriber: A subscriber is a user agent which receives NOTIFY >> requests from notifiers; these NOTIFY requests contain information >> about the state of a resource in which the subscriber is >> interested. Subscribers typically also generate SUBSCRIBE >> requests and send them to notifiers to create subscriptions. >> >> Comment: >> After this information, we can add a normative text which indicates >> when a SIP entity might get NOTIFY messages without actually >> sending SUBSCRIBE request. For example, REFER request might end up with >> implicit subscription. Also mention any other requests which may lead to >> implicit subscriptions (other than REFER). >> ------------------------------**----------------------- >> 2. Definitions >> >> CurrentText: >> Subscription: A subscription is a set of application state >> associated with a dialog. This application state includes a >> pointer to the associated dialog, the event package name, and >> possibly an identification token. Event packages will define >> additional subscription state information. By definition, >> subscriptions exist in both a subscriber and a notifier. >> >> ReplacementText: >> Subscription: A subscription is a set of application **states** >> associated with a dialog. **The** application state includes a >> pointer to the associated dialog, the event package name, and >> possibly an identification token. Event packages will define >> additional subscription state information. By definition, >> subscriptions exist in both a subscriber and a notifier. >> ------------------------------**----------------------- >> 3.1.1. Subscription Duration >> >> CurrentText: >> >> subscription. In order to keep subscriptions effective beyond the >> duration communicated in the "Expires" header field, subscribers need >> to refresh subscriptions on a periodic basis using a new SUBSCRIBE >> request on the same dialog as defined in [RFC3261]. >> >> ReplacementText >> 3.1.1. Subscription Duration >> >> subscription. In order to keep subscriptions effective beyond the >> duration communicated in the "Expires" header field, subscribers need >> to refresh subscriptions **before expiration** on a periodic basis >> using a new SUBSCRIBE >> request on the same dialog as defined in [RFC3261]. >> ------------------------------**----------------------- >> 3.1.1. Subscription Duration >> >> CurrentText: >> In addition to being a request to unsubscribe, a SUBSCRIBE request >> with "Expires" of 0 also causes a fetch of state; see >> Section 4.4.3. >> >> Comment: >> The above text has been mentioned to be normative text. But I feel >> this >> shall be written as a regualr text in the draft/rfc. because this >> is the >> expected behavior from the notifier. >> ------------------------------**----------------------- >> 3.1.2. Identification of Subscribed Events and Event Classes >> >> CurrentText: >> Subscribers MUST include exactly one "Event" header field in >> SUBSCRIBE requests, indicating to which event or class of events they >> are subscribing. The "Event" header field will contain a token which >> indicates the type of state for which a subscription is being >> requested. This token will be registered with the IANA and will >> correspond to an event package which further describes the semantics >> of the event or event class. >> >> >> ReplacementText: >> Subscribers MUST include exactly one "Event" header field in >> SUBSCRIBE requests, indicating to which event or class of events they >> are subscribing. The "Event" header field **MUST** contain a token >> which >> indicates the type of state for which a subscription is being >> requested. This token will be registered with the IANA and will >> correspond to an event package which further describes the semantics >> of the event or event class. >> ------------------------------**----------------------- >> 3.1. SUBSCRIBE >> >> CurrentText: >> The SUBSCRIBE method is used to request current state and state >> updates from a remote node. SUBSCRIBE requests are target refresh >> >> >> ReplacementText: >> The SUBSCRIBE method is used to request current state and >> **subsequent** state >> updates from a remote node. SUBSCRIBE requests are target refresh >> >> >> ------------------------------**----------------------- >> 3.1.1. Subscription Duration >> >> CurrentText: >> >> SUBSCRIBE requests SHOULD contain an "Expires" header field (defined >> in [RFC3261]). This expires value indicates the duration of the >> subscription. In order to keep subscriptions effective beyond the >> duration communicated in the "Expires" header field, subscribers need >> to refresh subscriptions on a periodic basis using a new SUBSCRIBE >> request on the same dialog as defined in [RFC3261]. >> >> Comment: >> We can add a normative text saying, the refresh time will be >> normally 50% to 75% of subscription duration. >> >> ------------------------------**----------------------- >> 3.2.1. >> >> CurrentText: >> This body will contain either the state of the subscribed resource or >> a pointer to such state in the form of a URI (see Section 5.4.13). >> >> ReplacementText/Comment: >> This body **SHALL** contain either the state of the subscribed >> resource or >> a pointer to such state in the form of a **URL** (see Section 5.4.13). >> ------------------------------**----------------------- >> 4.1.2. Creating and Maintaining Subscriptions >> >> >> CurrentText: >> >> From the subscriber's perspective, a subscription proceeds according >> to the following state diagram: >> >> Comment: >> Here it is better to mention, what happens to FSM when 200-SUBSCRIBE >> received in notify_wait state (because very often this is possible). >> If no change in state of FSM, then some normative text shall convey the >> same. >> It may be no-operation, but better to mention the same. >> ------------------------------**----------------------- >> 4.1.2.1. Requesting a Subscription >> >> CurrentText: >> When a subscriber wishes to subscribe to a particular state for a >> resource, it forms a SUBSCRIBE request. If the initial SUBSCRIBE >> >> ReplacementText: >> When a subscriber wishes to subscribe to a particular state **of** a >> resource, it forms a SUBSCRIBE request **according to sec 3.1 and >> send it across to notifier**. If the initial SUBSCRIBE >> >> ------------------------------**----------------------- >> 4.1.2.1. Requesting a Subscription >> >> CurrentText: >> [RFC3261]. For the sake of clarity: if a SUBSCRIBE request contains >> an "Accept" header field, but that field does not indicate a media >> type that the notifier is capable of generating in its NOTIFY >> requests, then the proper error response is 406 (Not Acceptable). >> >> COMMENT: >> It is better to mention it as a normative text (indented). >> >> ------------------------------**----------------------- >> 4.1.3. Receiving and Processing State Information >> >> CurrentText: >> >> If the "Subscription-State" value is "terminated", the subscriber >> MUST consider the subscription terminated. The "expires" parameter >> has no semantics for "terminated" -- notifiers SHOULD NOT include an >> >> ReplacementText: >> >> If the "Subscription-State" value is "terminated", the subscriber >> MUST consider the subscription terminated. The "expires" parameter >> has no semantics for "terminated" **state**. Notifiers SHOULD NOT >> include an >> ------------------------------**----------------------- >> >> CurrentText: >> deactivated: The subscription has been terminated, but the >> subscriber SHOULD retry immediately with a new subscription. One >> >> ReplacementText: >> deactivated: The subscription has been terminated, but the >> subscriber SHOULD retry with a new subscription. One >> >> Is It mandatory to resubscribe immediately. if not remove the word >> "immediately". >> If it is delayed, what are the consequences ???? >> >> ------------------------------**----------------------- >> 4.2.1. Subscription Establishment and Maintenance >> >> CurrentText: >> inability to signal the success of a REFER request while signaling >> a problem with the subscription; and difficulty performing one >> action without the other. Additionally, the proper exchange of >> >> ReplacementText: >> inability to signal the success of a REFER request while signaling >> a problem with the subscription; and difficulty **in** performing >> one >> action without the other. Additionally, the proper exchange of >> >> ------------------------------**----------------------- >> 4.2.1.4. Refreshing of Subscriptions >> >> CurrentText: >> If no refresh for a notification address is received before its >> expiration time, the subscription is removed. When removing a >> >> ReplacementText: >> If no refresh for a notification is received before its >> expiration time, the subscription is removed. When removing a >> Comment:Word "address" needs to be removed. >> ------------------------------**----------------------- >> 4.3. Proxy Behavior >> >> CurrentText: >> Proxies that did not add a Record-Route header field to the initial >> SUBSCRIBE request MUST NOT add a Record-Route header field to any of >> the associated NOTIFY requests. >> >> ReplacementText: >> Proxies that did not add a Record-Route header field to the initial >> SUBSCRIBE request MUST NOT add a Record-Route header field to any of >> the associated NOTIFY requests **or any SUBSCRIBE refresh requests**. >> ------------------------------**----------------------- >> 4.4.1. Dialog Creation and Termination >> >> CurrentText: >> >> A subscriber may send a SUBSCRIBE request with an "Expires" header >> field of 0 in order to trigger the sending of such a NOTIFY >> request; however, for the purposes of subscription and dialog >> lifetime, the subscription is not considered terminated until the >> NOTIFY transaction with a "Subscription-State" of "terminated" >> completes. >> >> Comment: >> We may have to mention how long the dialog must be kept alive, before >> being cleaned up. Do we delete the dialog immediately after 200-SUB >> or wait till NOTIFY with "Subscription-State"="**terminated". If we >> always >> wait till Last Notify for dialog termination, then 200-SUB don't have any >> impact on the dialog termination. Atleast some normative text is of >> necessity, for better understanding of the topic. >> ------------------------------**----------------------- >> 4.4.3. Polling Resource State >> >> CurrentText: >> >> Note that the NOTIFY requests triggered by SUBSCRIBE requests with >> "Expires" header fields of 0 will contain a "Subscription-State" >> value of "terminated", and a "reason" parameter of "timeout". >> >> ReplacementText: >> Note that the NOTIFY requests triggered by SUBSCRIBE requests with >> "Expires" header fields of 0 **shall** contain a "Subscription-State" >> value of "terminated", and a "reason" parameter of "timeout". >> ------------------------------**----------------------- >> 4.5.2. Sharing Dialogs >> >> CurrentText: >> for a dialog (e.g., route set handling). In particular, multiple >> subscriptions within a dialog are expire independently, and >> require independent subscription refreshes. >> >> ReplacementText: >> for a dialog (e.g., route set handling). In particular, multiple >> subscriptions within a dialog **operates** independently, and >> require independent subscription refreshes. >> ------------------------------**----------------------- >> 4.5.2. Sharing Dialogs >> >> CurrentText: >> o Subscribers MAY include an "id" parameter in SUBSCRIBE request >> "Event" header field to allow differentiation between multiple >> >> ReplacementText: >> o Subscribers MAY include an "id" parameter in SUBSCRIBE **request's** >> "Event" header field to allow differentiation between multiple >> OR >> o Subscribers MAY include an "id" parameter in **"Event" header field >> of SUBSCRIBE request** to allow differentiation between multiple >> ------------------------------**----------------------- >> 4.5.2. Sharing Dialogs >> >> CurrentText: >> o When a subscriber refreshes a the subscription timer, the >> SUBSCRIBE request MUST contain the same "Event" header field "id" >> parameter as was present in the SUBSCRIBE request that created the >> subscription. (Otherwise, the notifier will interpret the >> >> ReplacementText: >> o When a subscriber refreshes a the subscription timer, the >> SUBSCRIBE request MUST contain the same **"id" parameter in "Event" >> header field, which** was present in the SUBSCRIBE request that >> created the >> subscription. (Otherwise, the notifier will interpret the >> ------------------------------**----------------------- >> 4.5.2. Sharing Dialogs >> >> CurrentText: >> >> o When a subscription is created in the notifier, it stores any >> "Event" header field "id" parameter as part of the subscription >> information (along with the event package name). >> >> ReplacementText: >> o When a subscription is created in the notifier, it stores **the** >> **"id" parameter in "Event" header field** as part of the >> subscription >> information (along with the event package name). >> ------------------------------**----------------------- >> 4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions >> >> CurrentText: >> >> Neither SUBSCRIBE nor NOTIFY requests can be canceled. If a UAS >> receives a CANCEL request that matches a known SUBSCRIBE or NOTIFY >> transaction, it MUST respond to the CANCEL request, but otherwise >> ignore it. In particular, the CANCEL request MUST NOT affect >> processing of the SUBSCRIBE or NOTIFY request in any way. >> >> ReplacementText/Comment: >> What should be the response code for the CANCEL's reply ??? >> Preferably 200-OK shall be used. >> ------------------------------**----------------------- >> 4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions >> >> CurrentText: >> >> UACs SHOULD NOT send CANCEL requests for SUBSCRIBE or NOTIFY >> transactions. >> >> ReplacementText: >> UACs **MUST** NOT send CANCEL requests for SUBSCRIBE or NOTIFY >> transactions. **UASs SHOULD send 200OK for CANCEL within NOTIFY >> or SUBSCRIBE transaction duration. As per sec 9 of [RFC3261]** >> ------------------------------**----------------------- >> 5.3.2. State Deltas >> >> CurrentText: >> >> In the case that the state information to be conveyed is large, the >> event package may choose to detail a scheme by which NOTIFY requests >> contain state deltas instead of complete state. >> >> >> ReplacementText: >> In the case that the state information to be conveyed is large, the >> event package may choose a scheme by which NOTIFY requests >> contain state deltas instead of complete state. >> >> comment:deleted words "to detail" in 2nd line. >> >> ------------------------------**----------------------- >> 5.3.2. State Deltas >> >> CurrentText: >> >> If a NOTIFY request arrives that has a version number that is >> incremented by more than one, the subscriber knows that a state delta >> has been missed; it ignores the NOTIFY request containing the state >> delta (except for the version number, which it retains to detect >> message loss), and re-sends a SUBSCRIBE request to force a NOTIFY >> request containing a complete state snapshot. >> >> Comment: >> From this text, it infers that if any state delta lost, then subscriber >> sends refresh SUBSCRIBE (re-SUBSCRIBE) request. This re-SUBSCRIBE >> request inturn lead >> to fetching the complete state information. >> >> It may be a good diea to differentiate the re-SUBSCRIBE triggered by >> different scenarios. >> a) natural re-SUBSCRIBE request, which extends the SUBSCRIBE >> duration. In this >> case it is *not *necessary to fetch the complete state information >> >> b) re-SUBSCRIBE triggered because of lost NOTIFY request (ref sec >> 5.3.2. >> VERSION number in received NOTIFY is increased by greater than ONE). >> In this case subscriber wants to fetch the complete state >> information. >> >> If we don't differentiate these two cases, then natural re-SUBSCRIBE >> request >> unnecessarily fetch the complete state information, which may not be >> necessary / expected. >> But uses higher network bandwidth to fetch the complete state >> information. >> ------------------------------**----------------------- >> 5.4.7. Notifier generation of NOTIFY requests >> >> CurrentText: >> This section may optionally describe the behavior used to process the >> subsequent response. >> >> Comment: >> In this section 5.4.7, the above statement is not clear, what is >> really meant to be. >> >> ------------------------------**----------------------- >> 5.4.13. Use of URIs to Retrieve State >> >> CurrentText: >> >> ReplacementText: >> In this context, I feel Use of "URLs" is more appropriate than "URIs". >> ------------------------------**----------------------- >> >> >> Thanks, >> Nataraju A.B. >> E-ID : nataraju.ab@gmail.com / >> nataraju.sip@gmail.com >> >> +91-98455-95744 >> >> >> >> -- >> Thanks, >> Nataraju A.B. >> >> >> >> ______________________________**_________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/**listinfo/sipcore >> > > ______________________________**_________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/**listinfo/sipcore > -- Thanks, Nataraju A.B. --f46d04016a77e086d604be5b2e0b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Paul,=A0

I understand, I was late into the party... :(=

The c= omment is more of an OPTIMIZATION issue. As a minimal change,=A0can=A0we ad= d a normative text which provide some pointers for implementers to differen= tiate the re-SUBSCRIBE (to extend the subscription duration) and=A0re-SUBSC= RIBE (to fetch the complete state, due to lost NOTIFY).=A0

This might = be of great concern for lossy networks (for example, wireless networks, ...= ), where all the subsequent refresh SUBSCRIBE requests would un-necessarily= eats up more bandwidth for fetching the complete state which is not necess= ary. For non-lossy network this is of minor issue...

Even if we = decide to handle this optimization issue, we have to analyze thoroughly how= to differentiate differentiate these requests, through some new header / h= eader parameter / any other way. Need more analysis...

You can tak= e a call, based on the feasibility. Even if dropped it is fine....

Thanks,
<= div class=3D"gmail_extra"> Nataraju A B

On Mon, Apr 23, 2= 012 at 7:32 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wro= te:
Nataraju,

Your comments would have been much more helpful if received some months ago= when the document went through WGLC. This document is now *very* far down = the process to publication, having already gone through IESG last call, IAN= A review, etc. and is now in final IESG Evaluation. Changes at this point a= re very disruptive.

If you feel your suggestions are essential then you will have to go to extr= emes to pull this document back. I don't see anything below that convin= ces me to do that. AFAICT the comments below are all minor editorial except= for the first, which suggests changing the mechanism.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul (as co-chair)


On 4/23/12 12:58 AM, Nataraju A.B wrote:
All,

Some logical comments on the draft-ietf-sipcore-rfc3265bis-08.txt.
-----------------------------------------------------
5.3.2. =A0State Deltas

CurrentText:

=A0 =A0If a NOTIFY request arrives that has a version number that is
=A0 =A0incremented by more than one, the subscriber knows that a state del= ta
=A0 =A0has been missed; it ignores the NOTIFY request containing the state=
=A0 =A0delta (except for the version number, which it retains to detect =A0 =A0message loss), and re-sends a SUBSCRIBE request to force a NOTIFY =A0 =A0request containing a complete state snapshot.

Comment:
=A0 =A0From this text, it infers that if any state delta lost, then subscr= iber
=A0 =A0sends refresh SUBSCRIBE (re-SUBSCRIBE) request. This re-SUBSCRIBE request inturn lead
=A0 =A0to fetching the complete state information.

=A0 =A0It may be a good diea to differentiate the re-SUBSCRIBE triggered b= y
different scenarios.
=A0 =A0a) natural re-SUBSCRIBE request, which extends the SUBSCRIBE
duration. In this
=A0 =A0 =A0 case it is not necessary to fetch the complete state informati= on
=A0 =A0b) re-SUBSCRIBE triggered because of lost NOTIFY request (ref sec 5.3.2.
=A0 =A0 =A0 VERSION number in received NOTIFY is increased by greater than= ONE).
=A0 =A0 =A0 In this case subscriber wants to fetch the complete state
information.

=A0 =A0If we don't differentiate these two cases, then natural re-SUBS= CRIBE
request
=A0 =A0unnecessarily fetch the complete state information, which may not b= e
necessary / expected.
=A0 =A0But uses higher network bandwidth to fetch the complete state
information.
-----------------------------------------------------
-----------------------------------------------------
4.4.1. =A0Dialog Creation and Termination

CurrentText:

=A0 =A0 =A0 A subscriber may send a SUBSCRIBE request with an "Expire= s" header
=A0 =A0 =A0 field of 0 in order to trigger the sending of such a NOTIFY =A0 =A0 =A0 request; however, for the purposes of subscription and dialog<= br> =A0 =A0 =A0 lifetime, the subscription is not considered terminated until = the
=A0 =A0 =A0 NOTIFY transaction with a "Subscription-State" of &q= uot;terminated"
=A0 =A0 =A0 completes.

Comment:
We may have to mention how long the dialog must be kept alive, before
being cleaned up. Should we delete the dialog immediately after 200-SUB
or wait till NOTIFY with "Subscription-State"=3D"term= inated". If we always
wait till Last Notify for dialog termination, then 200-SUB don't have a= ny
impact on the dialog termination. Atleast some normative text is of
necessity, for better understanding of the topic.
-----------------------------------------------------
-----------------------------------------------------
3.1.1. =A0Subscription Duration

CurrentText:

=A0 =A0SUBSCRIBE requests SHOULD contain an "Expires" header fie= ld (defined
=A0 =A0in [RFC3261]). =A0This expires value indicates the duration of the<= br> =A0 =A0subscription. =A0In order to keep subscriptions effective beyond th= e
=A0 =A0duration communicated in the "Expires" header field, subs= cribers need
=A0 =A0to refresh subscriptions on a periodic basis using a new SUBSCRIBE<= br> =A0 =A0request on the same dialog as defined in [RFC3261].

Comment:
We can add a normative text saying, the refresh time will be
normally 50% to 75% of subscription duration.

-----------------------------------------------------
-----------------------------------------------------
4.1.2.1. =A0Requesting a Subscription

CurrentText:
=A0 =A0[RFC3261]. =A0For the sake of clarity: if a SUBSCRIBE request conta= ins
=A0 =A0an "Accept" header field, but that field does not indicat= e a media
=A0 =A0type that the notifier is capable of generating in its NOTIFY
=A0 =A0requests, then the proper error response is 406 (Not Acceptable).
COMMENT:
It is better to mention it as a normative text (indented).

-----------------------------------------------------
-----------------------------------------------------
4.1.2. =A0Creating and Maintaining Subscriptions


CurrentText:

=A0 =A0From the subscriber's perspective, a subscription proceeds acco= rding
=A0 =A0to the following state diagram:

Comment:
Here it is better to mention, what happens to FSM when 200-SUBSCRIBE
received in notify_wait state (because very often this is possible).
If no change in state of FSM, then some normative text shall convey the
same.
=A0 =A0 =A0 =A0 It may be no-operation, but better to mention the same. -----------------------------------------------------
-----------------------------------------------------
3.1.1. =A0Subscription Duration

CurrentText:
=A0 =A0 =A0 In addition to being a request to unsubscribe, a SUBSCRIBE req= uest
=A0 =A0 =A0 with "Expires" of 0 also causes a fetch of state; se= e
=A0 =A0 =A0 Section 4.4.3.

Comment:
=A0 =A0 =A0The above text has been mentioned to be normative text. But I f= eel
this
=A0 =A0 =A0shall be written as a regualr text in the draft/rfc. because th= is
is the
=A0 =A0 =A0expected behavior from the notifier.
-----------------------------------------------------
-----------------------------------------------------
3.2.1.

CurrentText:
=A0 =A0This body will contain either the state of the subscribed resource = or
=A0 =A0a pointer to such state in the form of a URI (see Section 5.4.13).<= br>
ReplacementText/Comment:
=A0 =A0This body **SHALL** contain either the state of the subscribed
resource or
=A0 =A0a pointer to such state in the form of a **URL** (see Section 5.4.1= 3).
-----------------------------------------------------
-----------------------------------------------------
4.2.1. =A0Subscription Establishment and Maintenance

CurrentText:
=A0 =A0 =A0 inability to signal the success of a REFER request while signa= ling
=A0 =A0 =A0 a problem with the subscription; and difficulty performing one=
=A0 =A0 =A0 action without the other. =A0Additionally, the proper exchange= of

ReplacementText:
=A0 =A0 =A0 inability to signal the success of a REFER request while signa= ling
=A0 =A0 =A0 a problem with the subscription; and difficulty **in** perform= ing one
=A0 =A0 =A0 action without the other. =A0Additionally, the proper exchange= of

-----------------------------------------------------

Thanks,
Nataraju A B

---------- Forwarded message ----------
From: *Nataraju A.B* <nataraju.sip@gmail.com
<mailto:nata= raju.sip@gmail.com>>
Date: Fri, Apr 13, 2012 at 10:53 PM
Subject: draft-ietf-sipcore-rfc3265bis-08.txt - Review comments
(Nataraju A B)
To: Adam Roach <ad= am@nostrum.com <mailto:adam@nostrum.com>>,
sipcore@ietf.org = <mailto:sipcore@ie= tf.org>


Adam,

Please find some editorial comments on the draft
"draft draft-ietf-sipcore-rfc3265bis-08.txt"

For simplicity, I have mentioned both the current text and proposed text.
The comments / corrective text can be found with prefix and suffix =A0--- *= *

-----------------------------------------------------
1.1. =A0Overview of Operation
CurrentText:
=A0 =A0The general concept is that entities in the network can subscribe t= o
=A0 =A0resource or call state for various resources or calls in the networ= k,
=A0 =A0and those entities (or entities acting on their behalf) can send =A0 =A0notifications when those states change.

ReplacementText:
=A0 =A0The general concept is that entities in the network can subscribe t= o
=A0 =A0resource or call state **at / of** various resources or calls in th= e
network,
=A0 =A0and those entities (or entities acting on their behalf) **who** can= send
=A0 =A0notifications when those states change.
-----------------------------------------------------

1.1. =A0Overview of Operation

CurrentText:
=A0 =A0Subscriptions are expired and must be refreshed by subsequent
=A0 =A0SUBSCRIBE requests.

ReplacementText:
=A0 =A0Subscriptions are expired and must be refreshed by subsequent
=A0 =A0SUBSCRIBE requests **before expiration**.
-----------------------------------------------------

2. =A0Definitions

CurrentText:
=A0 =A0Subscriber: =A0A subscriber is a user agent which receives NOTIFY =A0 =A0 =A0 requests from notifiers; these NOTIFY requests contain informa= tion
=A0 =A0 =A0 about the state of a resource in which the subscriber is
=A0 =A0 =A0 interested. =A0Subscribers typically also generate SUBSCRIBE =A0 =A0 =A0 requests and send them to notifiers to create subscriptions.
Comment:
After this information, we can add a normative text which indicates
when a SIP entity might get NOTIFY messages without actually
sending SUBSCRIBE request. For example, REFER request might end up with
implicit subscription. Also mention any other requests which may lead to implicit subscriptions (other than REFER).
-----------------------------------------------------
2. =A0Definitions

CurrentText:
=A0 =A0Subscription: =A0A subscription is a set of application state
=A0 =A0 =A0 associated with a dialog. =A0This application state includes a=
=A0 =A0 =A0 pointer to the associated dialog, the event package name, and<= br> =A0 =A0 =A0 possibly an identification token. =A0Event packages will defin= e
=A0 =A0 =A0 additional subscription state information. =A0By definition, =A0 =A0 =A0 subscriptions exist in both a subscriber and a notifier.

ReplacementText:
=A0 =A0Subscription: =A0A subscription is a set of application **states**<= br> =A0 =A0 =A0 associated with a dialog. =A0**The** application state include= s a
=A0 =A0 =A0 pointer to the associated dialog, the event package name, and<= br> =A0 =A0 =A0 possibly an identification token. =A0Event packages will defin= e
=A0 =A0 =A0 additional subscription state information. =A0By definition, =A0 =A0 =A0 subscriptions exist in both a subscriber and a notifier.
-----------------------------------------------------
3.1.1. =A0Subscription Duration

CurrentText:

=A0 =A0subscription. =A0In order to keep subscriptions effective beyond th= e
=A0 =A0duration communicated in the "Expires" header field, subs= cribers need
=A0 =A0to refresh subscriptions on a periodic basis using a new SUBSCRIBE<= br> =A0 =A0request on the same dialog as defined in [RFC3261].

ReplacementText
3.1.1. =A0Subscription Duration

=A0 =A0subscription. =A0In order to keep subscriptions effective beyond th= e
=A0 =A0duration communicated in the "Expires" header field, subs= cribers need
=A0 =A0to refresh subscriptions **before expiration** on a periodic basis<= br> using a new SUBSCRIBE
=A0 =A0request on the same dialog as defined in [RFC3261].
-----------------------------------------------------
3.1.1. =A0Subscription Duration

CurrentText:
=A0 =A0 =A0 In addition to being a request to unsubscribe, a SUBSCRIBE req= uest
=A0 =A0 =A0 with "Expires" of 0 also causes a fetch of state; se= e
=A0 =A0 =A0 Section 4.4.3.

Comment:
=A0 =A0 =A0The above text has been mentioned to be normative text. But I f= eel
this
=A0 =A0 =A0shall be written as a regualr text in the draft/rfc. because th= is
is the
=A0 =A0 =A0expected behavior from the notifier.
-----------------------------------------------------
3.1.2. =A0Identification of Subscribed Events and Event Classes

CurrentText:
=A0 =A0Subscribers MUST include exactly one "Event" header field= in
=A0 =A0SUBSCRIBE requests, indicating to which event or class of events th= ey
=A0 =A0are subscribing. =A0The "Event" header field will contain= a token which
=A0 =A0indicates the type of state for which a subscription is being
=A0 =A0requested. =A0This token will be registered with the IANA and will<= br> =A0 =A0correspond to an event package which further describes the semantic= s
=A0 =A0of the event or event class.


ReplacementText:
=A0 =A0Subscribers MUST include exactly one "Event" header field= in
=A0 =A0SUBSCRIBE requests, indicating to which event or class of events th= ey
=A0 =A0are subscribing. =A0The "Event" header field **MUST** con= tain a token
which
=A0 =A0indicates the type of state for which a subscription is being
=A0 =A0requested. =A0This token will be registered with the IANA and will<= br> =A0 =A0correspond to an event package which further describes the semantic= s
=A0 =A0of the event or event class.
-----------------------------------------------------
3.1. =A0SUBSCRIBE

CurrentText:
=A0 =A0The SUBSCRIBE method is used to request current state and state
=A0 =A0updates from a remote node. =A0SUBSCRIBE requests are target refres= h


ReplacementText:
=A0 =A0The SUBSCRIBE method is used to request current state and
**subsequent** state
=A0 =A0updates from a remote node. =A0SUBSCRIBE requests are target refres= h


-----------------------------------------------------
3.1.1. =A0Subscription Duration

CurrentText:

=A0 =A0SUBSCRIBE requests SHOULD contain an "Expires" header fie= ld (defined
=A0 =A0in [RFC3261]). =A0This expires value indicates the duration of the<= br> =A0 =A0subscription. =A0In order to keep subscriptions effective beyond th= e
=A0 =A0duration communicated in the "Expires" header field, subs= cribers need
=A0 =A0to refresh subscriptions on a periodic basis using a new SUBSCRIBE<= br> =A0 =A0request on the same dialog as defined in [RFC3261].

Comment:
We can add a normative text saying, the refresh time will be
normally 50% to 75% of subscription duration.

-----------------------------------------------------
3.2.1.

CurrentText:
=A0 =A0This body will contain either the state of the subscribed resource = or
=A0 =A0a pointer to such state in the form of a URI (see Section 5.4.13).<= br>
ReplacementText/Comment:
=A0 =A0This body **SHALL** contain either the state of the subscribed
resource or
=A0 =A0a pointer to such state in the form of a **URL** (see Section 5.4.1= 3).
-----------------------------------------------------
4.1.2. =A0Creating and Maintaining Subscriptions


CurrentText:

=A0 =A0From the subscriber's perspective, a subscription proceeds acco= rding
=A0 =A0to the following state diagram:

Comment:
Here it is better to mention, what happens to FSM when 200-SUBSCRIBE
received in notify_wait state (because very often this is possible).
If no change in state of FSM, then some normative text shall convey the
same.
=A0 =A0 =A0 =A0 It may be no-operation, but better to mention the same. -----------------------------------------------------
4.1.2.1. =A0Requesting a Subscription

CurrentText:
=A0 =A0When a subscriber wishes to subscribe to a particular state for a =A0 =A0resource, it forms a SUBSCRIBE request. =A0If the initial SUBSCRIBE=

ReplacementText:
=A0 =A0When a subscriber wishes to subscribe to a particular state **of** = a
=A0 =A0resource, it forms a SUBSCRIBE request **according to sec 3.1 and send it across to notifier**. =A0If the initial SUBSCRIBE

-----------------------------------------------------
4.1.2.1. =A0Requesting a Subscription

CurrentText:
=A0 =A0[RFC3261]. =A0For the sake of clarity: if a SUBSCRIBE request conta= ins
=A0 =A0an "Accept" header field, but that field does not indicat= e a media
=A0 =A0type that the notifier is capable of generating in its NOTIFY
=A0 =A0requests, then the proper error response is 406 (Not Acceptable).
COMMENT:
It is better to mention it as a normative text (indented).

-----------------------------------------------------
4.1.3. =A0Receiving and Processing State Information

CurrentText:

=A0 =A0If the "Subscription-State" value is "terminated&quo= t;, the subscriber
=A0 =A0MUST consider the subscription terminated. =A0The "expires&quo= t; parameter
=A0 =A0has no semantics for "terminated" -- notifiers SHOULD NOT= include an

ReplacementText:

=A0 =A0If the "Subscription-State" value is "terminated&quo= t;, the subscriber
=A0 =A0MUST consider the subscription terminated. =A0The "expires&quo= t; parameter
=A0 =A0has no semantics for "terminated" **state**. Notifiers SH= OULD NOT
include an
-----------------------------------------------------

CurrentText:
=A0 =A0deactivated: =A0The subscription has been terminated, but the
=A0 =A0 =A0 subscriber SHOULD retry immediately with a new subscription. = =A0One

ReplacementText:
=A0 =A0deactivated: =A0The subscription has been terminated, but the
=A0 =A0 =A0 subscriber SHOULD retry with a new subscription. =A0One

=A0 =A0Is It mandatory to resubscribe immediately. if not remove the word<= br> "immediately".
=A0 =A0If it is delayed, what are the consequences ????

-----------------------------------------------------
4.2.1. =A0Subscription Establishment and Maintenance

CurrentText:
=A0 =A0 =A0 inability to signal the success of a REFER request while signa= ling
=A0 =A0 =A0 a problem with the subscription; and difficulty performing one=
=A0 =A0 =A0 action without the other. =A0Additionally, the proper exchange= of

ReplacementText:
=A0 =A0 =A0 inability to signal the success of a REFER request while signa= ling
=A0 =A0 =A0 a problem with the subscription; and difficulty **in** perform= ing one
=A0 =A0 =A0 action without the other. =A0Additionally, the proper exchange= of

-----------------------------------------------------
4.2.1.4. =A0Refreshing of Subscriptions

CurrentText:
=A0 =A0If no refresh for a notification address is received before its
=A0 =A0expiration time, the subscription is removed. =A0When removing a
ReplacementText:
=A0 =A0If no refresh for a notification is received before its
=A0 =A0expiration time, the subscription is removed. =A0When removing a Comment:Word "address" needs to be removed.
-----------------------------------------------------
4.3. =A0Proxy Behavior

CurrentText:
=A0 =A0Proxies that did not add a Record-Route header field to the initial=
=A0 =A0SUBSCRIBE request MUST NOT add a Record-Route header field to any o= f
=A0 =A0the associated NOTIFY requests.

ReplacementText:
=A0 =A0Proxies that did not add a Record-Route header field to the initial=
=A0 =A0SUBSCRIBE request MUST NOT add a Record-Route header field to any o= f
=A0 =A0the associated NOTIFY requests **or any SUBSCRIBE refresh requests*= *.
-----------------------------------------------------
4.4.1. =A0Dialog Creation and Termination

CurrentText:

=A0 =A0 =A0 A subscriber may send a SUBSCRIBE request with an "Expire= s" header
=A0 =A0 =A0 field of 0 in order to trigger the sending of such a NOTIFY =A0 =A0 =A0 request; however, for the purposes of subscription and dialog<= br> =A0 =A0 =A0 lifetime, the subscription is not considered terminated until = the
=A0 =A0 =A0 NOTIFY transaction with a "Subscription-State" of &q= uot;terminated"
=A0 =A0 =A0 completes.

Comment:
We may have to mention how long the dialog must be kept alive, before
being cleaned up. Do we delete the dialog immediately after 200-SUB
or wait till NOTIFY with "Subscription-State"=3D"term= inated". If we always
wait till Last Notify for dialog termination, then 200-SUB don't have a= ny
impact on the dialog termination. Atleast some normative text is of
necessity, for better understanding of the topic.
-----------------------------------------------------
4.4.3. =A0Polling Resource State

CurrentText:

=A0 =A0Note that the NOTIFY requests triggered by SUBSCRIBE requests with<= br> "Expires" header fields of 0 will contain a "Subscription-St= ate"
=A0 =A0value of "terminated", and a "reason" parameter= of "timeout".

ReplacementText:
=A0 =A0Note that the NOTIFY requests triggered by SUBSCRIBE requests with<= br> "Expires" header fields of 0 **shall** contain a "Subscripti= on-State"
=A0 =A0value of "terminated", and a "reason" parameter= of "timeout".
-----------------------------------------------------
4.5.2. =A0Sharing Dialogs

CurrentText:
=A0 =A0 =A0 for a dialog (e.g., route set handling). =A0In particular, mul= tiple
=A0 =A0 =A0 subscriptions within a dialog are expire independently, and =A0 =A0 =A0 require independent subscription refreshes.

ReplacementText:
=A0 =A0 =A0 for a dialog (e.g., route set handling). =A0In particular, mul= tiple
=A0 =A0 =A0 subscriptions within a dialog **operates** independently, and<= br> =A0 =A0 =A0 require independent subscription refreshes.
-----------------------------------------------------
4.5.2. =A0Sharing Dialogs

CurrentText:
=A0 =A0o =A0Subscribers MAY include an "id" parameter in SUBSCRI= BE request
"Event" header field to allow differentiation between multiple
ReplacementText:
=A0 =A0o =A0Subscribers MAY include an "id" parameter in SUBSCRI= BE **request's**
"Event" header field to allow differentiation between multiple OR
=A0 =A0o =A0Subscribers MAY include an "id" parameter in **"= ;Event" header field
=A0 =A0 =A0 of SUBSCRIBE request** to allow differentiation between multip= le
-----------------------------------------------------
4.5.2. =A0Sharing Dialogs

CurrentText:
=A0 =A0o =A0When a subscriber refreshes a the subscription timer, the
=A0 =A0 =A0 SUBSCRIBE request MUST contain the same "Event" head= er field "id"
=A0 =A0 =A0 parameter as was present in the SUBSCRIBE request that created= the
=A0 =A0 =A0 subscription. =A0(Otherwise, the notifier will interpret the
ReplacementText:
=A0 =A0o =A0When a subscriber refreshes a the subscription timer, the
=A0 =A0 =A0 SUBSCRIBE request MUST contain the same **"id" param= eter in "Event"
=A0 =A0 =A0 header field, which** was present in the SUBSCRIBE request tha= t
created the
=A0 =A0 =A0 subscription. =A0(Otherwise, the notifier will interpret the -----------------------------------------------------
4.5.2. =A0Sharing Dialogs

CurrentText:

=A0 =A0o =A0When a subscription is created in the notifier, it stores any<= br> "Event" header field "id" parameter as part of the subs= cription
=A0 =A0 =A0 information (along with the event package name).

ReplacementText:
=A0 =A0o =A0When a subscription is created in the notifier, it stores **th= e**
=A0 =A0 =A0 **"id" parameter in "Event" header field**= as part of the
subscription
=A0 =A0 =A0 information (along with the event package name).
-----------------------------------------------------
4.6. =A0CANCEL Requests for SUBSCRIBE and NOTIFY Transactions

CurrentText:

=A0 =A0Neither SUBSCRIBE nor NOTIFY requests can be canceled. =A0If a UAS<= br> =A0 =A0receives a CANCEL request that matches a known SUBSCRIBE or NOTIFY<= br> =A0 =A0transaction, it MUST respond to the CANCEL request, but otherwise =A0 =A0ignore it. =A0In particular, the CANCEL request MUST NOT affect
=A0 =A0processing of the SUBSCRIBE or NOTIFY request in any way.

ReplacementText/Comment:
What should be the response code for the CANCEL's reply ???
Preferably 200-OK shall be used.
-----------------------------------------------------
4.6. =A0CANCEL Requests for SUBSCRIBE and NOTIFY Transactions

CurrentText:

=A0 =A0UACs SHOULD NOT send CANCEL requests for SUBSCRIBE or NOTIFY
=A0 =A0transactions.

ReplacementText:
=A0 =A0UACs **MUST** NOT send CANCEL requests for SUBSCRIBE or NOTIFY
=A0 =A0transactions. **UASs SHOULD send 200OK for CANCEL within NOTIFY
=A0 =A0or SUBSCRIBE transaction duration. As per sec 9 of [RFC3261]**
-----------------------------------------------------
5.3.2. =A0State Deltas

CurrentText:

=A0 =A0In the case that the state information to be conveyed is large, the=
=A0 =A0event package may choose to detail a scheme by which NOTIFY request= s
=A0 =A0contain state deltas instead of complete state.


ReplacementText:
=A0 =A0In the case that the state information to be conveyed is large, the=
=A0 =A0event package may choose a scheme by which NOTIFY requests
=A0 =A0contain state deltas instead of complete state.

comment:deleted words "to detail" in 2nd line.

-----------------------------------------------------
5.3.2. =A0State Deltas

CurrentText:

=A0 =A0If a NOTIFY request arrives that has a version number that is
=A0 =A0incremented by more than one, the subscriber knows that a state del= ta
=A0 =A0has been missed; it ignores the NOTIFY request containing the state=
=A0 =A0delta (except for the version number, which it retains to detect =A0 =A0message loss), and re-sends a SUBSCRIBE request to force a NOTIFY =A0 =A0request containing a complete state snapshot.

Comment:
=A0 =A0From this text, it infers that if any state delta lost, then subscr= iber
=A0 =A0sends refresh SUBSCRIBE (re-SUBSCRIBE) request. This re-SUBSCRIBE request inturn lead
=A0 =A0to fetching the complete state information.

=A0 =A0It may be a good diea to differentiate the re-SUBSCRIBE triggered b= y
different scenarios.
=A0 =A0a) natural re-SUBSCRIBE request, which extends the SUBSCRIBE
duration. In this
=A0 =A0 =A0 case it is *not *necessary to fetch the complete state informa= tion

=A0 =A0b) re-SUBSCRIBE triggered because of lost NOTIFY request (ref sec 5.3.2.
=A0 =A0 =A0 VERSION number in received NOTIFY is increased by greater than= ONE).
=A0 =A0 =A0 In this case subscriber wants to fetch the complete state
information.

=A0 =A0If we don't differentiate these two cases, then natural re-SUBS= CRIBE
request
=A0 =A0unnecessarily fetch the complete state information, which may not b= e
necessary / expected.
=A0 =A0But uses higher network bandwidth to fetch the complete state
information.
-----------------------------------------------------
5.4.7. =A0Notifier generation of NOTIFY requests

CurrentText:
=A0 =A0This section may optionally describe the behavior used to process t= he
=A0 =A0subsequent response.

Comment:
=A0 =A0In this section 5.4.7, the above statement is not clear, what is really meant to be.

-----------------------------------------------------
5.4.13. =A0Use of URIs to Retrieve State

CurrentText:

ReplacementText:
=A0 =A0In this context, I feel Use of "URLs" is more appropriate= than "URIs".
-----------------------------------------------------


Thanks,
Nataraju A.B.
E-ID : nataraju.= ab@gmail.com <mailto:nataraju.ab@gmail.com> /
nataraju.sip@gm= ail.com <mailto:nataraju.sip@gmail.com>

+91-98455-95744



--
Thanks,
Nataraju A.B.



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

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



--
Tha= nks,
Nataraju A.B.

--f46d04016a77e086d604be5b2e0b-- From adam@nostrum.com Mon Apr 23 12:23:46 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD2521E801B for ; Mon, 23 Apr 2012 12:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, SPF_PASS=-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 34Pwb1eMKIo1 for ; Mon, 23 Apr 2012 12:23:46 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CACDE21F85D3 for ; Mon, 23 Apr 2012 12:23:45 -0700 (PDT) Received: from dn3-110.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q3NJNg8Z058435 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 23 Apr 2012 14:23:43 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4F95AC3E.9030100@nostrum.com> Date: Mon, 23 Apr 2012 14:23:42 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Nataraju A.B" References: <4F9560EC.9030308@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] comments on draft-ietf-sipcore-rfc3265bis-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2012 19:23:46 -0000 On 4/23/12 11:32 AM, Nataraju A.B wrote: > > The comment is more of an OPTIMIZATION issue. As a minimal > change, can we add a normative text which provide some pointers for > implementers to differentiate the re-SUBSCRIBE (to extend the > subscription duration) and re-SUBSCRIBE (to fetch the complete state, > due to lost NOTIFY). That's what RFC 5839 is for. /a From christer.holmberg@ericsson.com Tue Apr 24 02:45:15 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48AF21F8773 for ; Tue, 24 Apr 2012 02:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.011 X-Spam-Level: X-Spam-Status: No, score=-6.011 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 63e1nyqn-Snn for ; Tue, 24 Apr 2012 02:45:14 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1E40621F876E for ; Tue, 24 Apr 2012 02:45:13 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-c2-4f967628f127 Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA) Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id AC.7C.25560.826769F4; Tue, 24 Apr 2012 11:45:13 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 24 Apr 2012 11:45:11 +0200 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Paul Kyzivat Date: Tue, 24 Apr 2012 11:45:11 +0200 Thread-Topic: [sipcore] Should we change mandatory-to-implement transports? Thread-Index: Ac0hZy/D/MYToKnVTCGi5H/mSM0HgwAlqARA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C43EFE6CD@ESESSCMS0356.eemea.ericsson.se> References: <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> <4F95674C.3020705@alum.mit.edu> <4F957300.1080106@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" , =?utf-8?B?U2HDumwgSWJhcnJhIENvcnJldGfDqQ==?= Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 09:45:15 -0000 SGksDQoNCj4+IEl0IHNob3VsZCBub3QgYmUgbmVjZXNzYXJ5IHRvIGRpc2FibGUgVURQIGJlY2F1 c2UgbWVzc2FnZXMgc29tZXRpbWVzIA0KPj4gZ2V0IGJpZy4gQXMgbG9uZyBhcyBib3RoIGFyZSBz dXBwb3J0ZWQgdGhlIHByb3BlciBvbmUgY2FuIGJlIHVzZWQgDQo+PiBiYXNlZCBvbiBtZXNzYWdl IHNpemUuIE9mIGNvdXJzZSB0aGVyZSBhcmUgc29tZSBjYXNlcyB3aGVyZSB0aGF0IHdvbid0IA0K Pj4gd29yayAtIGUuZy4gYW4gb2ZmZXJsZXNzIGludml0ZSBzZW50IHZpYSBVRFAsIGxlYWRpbmcg dG8gdGhlIG5lZWQgdG8gDQo+PiBzZW5kIGFuIG9mZmVyIGluIGEgcmVwbHkuDQo+DQo+IEhpIFBh dWwsIHRoYXQgc291bmRzIGEgYml0ICJ0aGVvcmljYWwiIGZvciBtZS4gU0lQIHBob25lcyB1c3Vh bGx5IHBlcmZvcm0gYSBzaW5nbGUgcmVnaXN0cmF0aW9uIHVzaW5nIGEgc2luZ2xlIHRyYW5zcG9y dCBhbmQgYmluZGluZyBhIHNpbmdsZSBDb250YWN0IFVSSSB3aXRoIHNhbWUgdHJhbnNwb3J0IHRo YW4gdGhlIG9uZSB1c2VkIGZvciBzZW5kaW5nIHRoZSBSRUdJU1RFUi4NCj4NCj4gSW5kZWVkIGEg U0lQIFVBIGNvdWxkIHJlZ2lzdGVyIHR3byBVUklzIChvbmUgd2l0aCA7dHJhbnNwb3J0PXVkcCBh bmQgdGhlIG90aGVyIG9uZSB3aXRoIHRjcCksIGJ1dCB0aGVuIGl0IHdvdWxkIGdlbmVyYXRlIHVz ZWxlc3MgcGFyYWxsZWwgZm9ya2luZyBmb3IgaW5pdGlhbCBpbmNvbWluZy1yZXF1ZXN0cyAoYW5k IGxvdCBvZiBtZXJnZWQgcmVxdWVzdHMgYW5kDQo+IDQ4MiByZXNwb25zZXMgZnJvbSB0aGUgVUEp LiBXZWxsLCB0aGUgVUEgY291bGQgc2V0IGRpZmZlcmVudCAicSINCj4gdmFsdWVzIGFuZCBnaXZl IG1vcmUgcHJpb3JpdHkgdG8gdGhlIFVEUCBiaW5kaW5nLCBzbyB0aGUgcmVnaXN0cmFyIHdvdWxk IGp1c3QgdXNlIFRDUCBpZiBzZW5kaW5nIHRoZSByZXF1ZXN0IG92ZXIgVURQIGZhaWxzIChpbnRl cm5hbCA1MDMpLiBIb3dldmVyIHRoYXQgd291bGQgbm90IHdvcmsgZm9yIGluLWRpYWxvZyByZXF1 ZXN0cyBzaW5jZSB0aGUgUlVSSSBhbHJlYWR5IGluZGljYXRlcyB0aGUgdHJhbnNwb3J0Lg0KDQpB IHdlbGwgaW1wbGVtZW50ZWQgcmVnaXN0cmFyIGNvdWxkIHVzZSBzZXJpYWwgZm9ya2luZyBpbiB0 aGlzIGNhc2UuIEJ1dCwgYXMgeW91IHNheSwgaWYgdGhlIHJlZ2lzdHJhdGlvbnMgdXNlIGRpZmZl cmVudCByb3V0ZSBzZXRzLCB5b3UgY2FuJ3Qgc3dpdGNoIGZyb20gb25lIHRvIGFub3RoZXIgbWlk LXNlc3Npb24uIEluIHJlYWxpdHksIGhvd2V2ZXIsIHRoZSBJTlZJVEUgcmVxdWVzdC9yZXNwb25z ZSBpcyBnb2luZyB0byBiZSB0aGUgbGFyZ2VzdCByZXF1ZXN0IHdpdGhpbiBhIGRpYWxvZyAodW5s ZXNzIHlvdSBlLmcuIHVzZSBhbiBJbmZvLVBhY2thZ2Ugd2l0aCBhIGxhcmdlIGNvbnRlbnQpLg0K DQpCdXQsIGV2ZW4gaWYgYSBVQSByZWdpc3RlcnMgYm90aCB1c2luZyBUQ1AsIGlmIHRoZXJlIGFy ZSBwcm94aWVzIGJldHdlZW4gdGhlIFVBIGFuZCB0aGUgcmVnaXN0cmFyIEkgZG9uJ3QgdGhpbmsg aXQgY2FuIGJlIGd1YXJhbnRlZWQgdGhhdCB0aGVyZSB3aWxsIGJlIFRDUCBhbGwgdGhlIHdheSAo c2ltaWxhciBpc3N1ZSBhcyBmb3IgdHJhbnNwb3J0PXRscykuIE9yLCBpcyB0aGVyZSBhIHJ1bGUg c2F5aW5nIHRoYXQgYSBwcm94eSBtdXN0IG5vdCBkb3duZ3JhZGUgZnJvbSBUQ1AgdG8gVURQPw0K DQo+IElNSE8gdGhpcyB3b3VsZCBiZSBtb3JlIGZlYXNpYmxlIGluIHRoZSBjYXNlIG9mIHByb3h5 IHRvIHByb3h5IGNvbW11bmljYXRpb24sIGluIHdoaWNoIHByb3h5IEEgY291bGQgZGVjaWRlIChi YXNlZCBvbiByZXF1ZXN0IHNpemUpIHdoZXRoZXIgdG8gc2VsZWN0IG9uZSBvciBvdGhlciB0cmFu c3BvcnQgcmVnYXJkbGVzcyB0aGUgcHJpb3JpdHkgb2YgdGhlIE5BUFRSIHJlY29yZHMsIG9yIHNl bGVjdGluZyBUQ1AgcmVnYXJsZXNzIHRoZSANCj4gUlVSSSBoYXMgYW4gSVAgYW5kIG5vIDt0cmFu c3BvcnQ9dGNwIHBhcmFtLg0KPg0KPiBCdXQgaG9uZXN0bHksIGluIHRoZSBVQSBzaWRlIEkgZG9u J3QgZXhwZWN0IHRoYXQgZHluYW1pYyBzZWxlY3Rpb24gb2YgdGhlIHRyYW5zcG9ydCBjb3VsZCB3 b3JrIGluICJyZWFsIiBzY2VuYXJpb3MgKG1heWJlIEknbSB3cm9uZykuDQoNCkkgYWdyZWUuIFBy b3h5LXRvLXByb3h5IGlzIG5vdCBhIHByb2JsZW0uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= From ibc@aliax.net Tue Apr 24 03:07:28 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A16021F8786 for ; Tue, 24 Apr 2012 03:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.332 X-Spam-Level: X-Spam-Status: No, score=-2.332 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, 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 GrzNGknDrYvj for ; Tue, 24 Apr 2012 03:07:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8024A21F8782 for ; Tue, 24 Apr 2012 03:07:26 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so421263vcb.31 for ; Tue, 24 Apr 2012 03:07:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=9j1IvUNsRFUuIOv5hi6ySUqWTx9GhepzAkT6zj0P2p8=; b=QXCOyjxNy7S3SNAq97jdb4wHFtWIesHXCkJEHikpPfy9+oR3wf9nnPjwJhkj38SpkK H3yYXtxmpxb6iio7nlLmrajlpHEdCcuMr87UZRCTzxwUIifFqxf66vJkd29C0xch5mFf vHMptt2vQrMtvawHriPw3w2Z+MWfH2+S+Hy2RWWfpxEB5K60z9vABZa8D0+f4rx67oCm 6kFpePy9LC1iEVV1lnua5VbheflKqSp3i9Esz3Sh2NRC6rpeVs+cfwroMgKrI3O+DtqL RPrnvD7rU6rVp/MYE+3IY3u3aLyLDd9pZRcy1NWa/XSDWsmgQawRssCvaPiChfcOsBvh HEhA== Received: by 10.220.49.66 with SMTP id u2mr3444141vcf.2.1335262045973; Tue, 24 Apr 2012 03:07:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 24 Apr 2012 03:07:05 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C43EFE6CD@ESESSCMS0356.eemea.ericsson.se> References: <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> <4F919C59.1000604@alum.mit.edu> <4F95674C.3020705@alum.mit.edu> <4F957300.1080106@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C43EFE6CD@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 24 Apr 2012 12:07:05 +0200 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmJpkfQWnHtLEKiAlVPpHapqxKuIyHM3+tHGrdXLv9cLMevD0fFKXNK1moLXOwKnURuqcA1 Cc: "sipcore@ietf.org" , =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 10:07:28 -0000 2012/4/24 Christer Holmberg : > A well implemented registrar could use serial forking in this case. But, = as you say, if the registrations use different route sets, you can't switch= from one to another mid-session. In reality, however, the INVITE request/r= esponse is going to be the largest request within a dialog (unless you e.g.= use an Info-Package with a large content). But take also into account that a re-INVITE could be bigger than an initial INVITE due to Route headers, and typically the RURI in a re-INVITE maps to a specific IP:port and transport. > But, even if a UA registers both using TCP, if there are proxies between = the UA and the registrar I don't think it can be guaranteed that there will= be TCP all the way (similar issue as for transport=3Dtls). Or, is there a = rule saying that a proxy must not downgrade from TCP to UDP? Is not. But as said before, I expect that changing to TCP in case of a big message is easier in proxy-to-proxy communication. The real problem I see is when a UA uses UDP for common stuf (registration and so). BTW I don't think we should care too much about this irresolvable problem. Instead let's encourage TCP transport in new deployments regardless UDP "might" be valid. Regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue Apr 24 03:14:31 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15F821F85F8 for ; Tue, 24 Apr 2012 03:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.158 X-Spam-Level: X-Spam-Status: No, score=-6.158 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 nZVWJRVbhuw6 for ; Tue, 24 Apr 2012 03:14:31 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8588F21F85F0 for ; Tue, 24 Apr 2012 03:14:30 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-6a-4f967d055055 Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 83.59.26681.50D769F4; Tue, 24 Apr 2012 12:14:29 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 24 Apr 2012 12:14:29 +0200 From: Christer Holmberg To: Christer Holmberg , "sipcore@ietf.org" Date: Tue, 24 Apr 2012 12:14:29 +0200 Thread-Topic: Draft new version: draft-ietf-sipcore-proxy-feature-01 Thread-Index: Ac0caEiaRgfiaTJVS+GeAzxkM0LILwFmnRjw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C43EFE714@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C42DF52F5@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C42DF52F5@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A05852C43EFE714ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 10:14:31 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C43EFE714ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In order to progress the proxy-feature work, I would ask those who requeste= d a new IANA registry to take a look at the latest version of the draft, wh= ich creates such registry. Others are of course also welcome to read/comment the draft :) Currently there should be no documented open issues. Thanks! Regards, Christer From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: 17. huhtikuuta 2012 10:05 To: sipcore@ietf.org Subject: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01 Hi, I've submitted a new version (-01) of the proxy-feature draft. Based on the discussions in Paris, instead of using feature tags the draft = now creates a new IANA "feature cap" registry. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05852C43EFE714ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In order to progress the proxy-feature work, I would ask= those who requested a new IANA registry to take a look at the latest versi= on of the draft, which creates such registry.

 

Others are of course also we= lcome to read/comment the draft J

 

Currently there sho= uld be no documented open issues.

 

Thanks!

 

Regards,

<= p class=3DMsoNormal> <= /p>

Christer

 

From: sipcore-bounces@ietf.or= g [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer HolmbergSent: 17. huhtikuuta 2012 10:05
To: sipcore@ietf.org
= Subject: [sipcore] Draft new version: draft-ietf-sipcore-proxy-featu= re-01

 

Hi,

 

I’ve submitted a new version (-01) of the proxy-feature draft.

 

= Based on the discussions in Paris, instead of using feature tags the draft = now creates a new IANA “feature cap” registry.

 

Regards,<= /o:p>

 

Chr= ister

= --_000_7F2072F1E0DE894DA4B517B93C6A05852C43EFE714ESESSCMS0356e_-- From pravindran@sonusnet.com Tue Apr 24 05:05:01 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C007C21F87BA for ; Tue, 24 Apr 2012 05:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.192 X-Spam-Level: X-Spam-Status: No, score=-6.192 tagged_above=-999 required=5 tests=[AWL=-0.193, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] 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 gs5ss1ZwDGjW for ; Tue, 24 Apr 2012 05:05:00 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id 29D7B21F8794 for ; Tue, 24 Apr 2012 05:04:51 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKT5aW4+94PdPmoC4kuUncLl09QtpG7+ni@postini.com; Tue, 24 Apr 2012 05:05:00 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 24 Apr 2012 08:04:51 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 17:34:45 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat Thread-Topic: [sipcore] Websocket is a new transport or new URI? Thread-Index: AQHNIDOCuN/qLU9tjk656lTA6m0G85am5VEAgAD8KaCAAD8sgIABv2aw Date: Tue, 24 Apr 2012 12:04:44 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> In-Reply-To: <4F956931.7090404@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 12:05:01 -0000 Paul, Thanks for clarify your view. In case your view is correct, then Usage of S= IPS Scheme (Sec 9.2) of draft-ibc-sipcore-sip-websocket-02 draft should for= bid the usage of SIPS URI for websocket transport (WSS, WS) as SIPS URI is = mistake for TLS, the mistake *MUST NOT* be repeated and the draft text has = to be updated as "SIPS URI MUST NOT be used for WS, WSS transport as the end-to-end security= is not assured" Please let me know your opinion on the above recommendation. I added the ex= act current text of the draft as a note of this mail for your reference. Thanks Partha Note: Current text of draft-ibc-sipcore-sip-websocket-02 9.2. Usage of SIPS Scheme SIPS scheme within a SIP request dictates that the entire request path to the target be secured. If such a path includes a WebSocket node it MUST be a secure WebSocket connection.=20 >-----Original Message----- >From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >Sent: Monday, April 23, 2012 8:08 PM >To: Ravindran, Parthasarathi >Cc: sipcore@ietf.org >Subject: Re: [sipcore] Websocket is a new transport or new URI? > >On 4/23/12 1:32 AM, Ravindran, Parthasarathi wrote: >> Paul, >> >> Could you please explain your view of why SIPS URI is a mistake for >TLS transport. > >My view is that the *intent* of sips was to provide the sort of >"guarantee" of security that https provides. But sips doesn't provide >that guarantee, because it isn't e2e and a variety of other things. The >end result is that with sips you have very little more confidence that >you are securely talking to who you think than if you use best effort by >using TLS on your first hop. In essence, sips provides a false sense of >security to the naive, but little more than that. > > Thanks, > Paul > >> I'm interested in knowing as apart from RFC 3261, Sec 3.1.4 of RFC >> 5630 (recent RFC) also recommends the usage of SIPS URI with TCP as a >> transport for TLS over TCP (http://tools.ietf.org/html/rfc5630#page-5) >> and there is an explicit statement in the same para >> >> "This specification does not make use of the transport=3Dtls parameter." >> >> Thanks >> Partha >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>> Behalf Of Paul Kyzivat >>> Sent: Monday, April 23, 2012 1:19 AM >>> To: sipcore@ietf.org >>> Subject: Re: [sipcore] Websocket is a new transport or new URI? >>> >>> Partha, >>> >>> IMO the main thing we learned about sips is that it was a bad idea. >>> I don't support making that mistake again. >>> >>> Thanks, >>> Paul >>> >>> On 4/21/12 10:55 PM, Ravindran, Parthasarathi wrote: >>>> Sal& others, >>>> >>>> After reading lot of mails and thinking further, I agree with you >>>> that >>> Websocket is an application protocol that is used as an transport for >>> SIP. TLS is one another application protocol on top of TCP which was >>> considered as transport (transport=3Dtls) earlier and deprecated as >>> part of RFC 3261 in Sec 26.2.2. TLS and Websocket has some unique >>> behavior like hop-by-hop protocol rather than end-to-end. >>>> >>>> TLS is adopted within SIP using new URI namely SIPS with >>> transport=3Dtcp. In the same way, I'm proposing SIPWS which implies >>> websocket over TCP, SIPWSS which implies websocket over TLS over TCP. >>> Please let me know your opinion on the same. >>>> >>>> Thanks >>>> Partha >>>> >>>>> -----Original Message----- >>>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>>>> Behalf Of Salvatore Loreto >>>>> Sent: Wednesday, April 18, 2012 7:41 PM >>>>> To: sipcore@ietf.org >>>>> Subject: Re: [sipcore] Stateless or Transaction stateful proxy >>>>> possible in Websocket transport? [RE: Call for Adoption: >>>>> draft-ibc-sipcore-sip- websocket-02] >>>>> >>>>> On 4/18/12 4:40 PM, Christer Holmberg wrote: >>>>>> Hi, >>>>>> >>>>>> I may have misunderstood something in the conversation, but my >>>>> suggestion would be to consider *NOT* mandating SIP WebSocket >>>>> clients to implement SIP UDP and TCP. >>>>>> >>>>>> Especially if I write a JavaScript SIP browser app, I very likely >>>>> would want to support only WebSocket. >>>>>> >>>>>> Also, I don't think we can directly compare with SCTP, since the >>>>> typical use-case for WebSocket is browser apps (eventhough a native >>>>> app can of course also use WS). >>>>> >>>>> I think that in general we can not compare SCTP to WebSocket at all >>>>> because the first is a pure Transport Protocol, the latter is an >>>>> application protocol that is used as transport. >>>>> >>>>> From a pure WebSocket prospective, what you are going to define >>>>> is SIP as a websocket sub-protocol that is transported on top of. >>>>> >>>>> The important thing to standardize from a SIPCore prospective is >>>>> the interaction/translations that happens between the WebSocket >>>>> server and the SIP proxy that are two different logical entities. >>>>> >>>>> my two cents >>>>> Sal >>>>> >>>>> -- >>>>> Salvatore Loreto, PhD >>>>> www.sloreto.com >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> From kpfleming@digium.com Tue Apr 24 05:28:58 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692A221F8751 for ; Tue, 24 Apr 2012 05:28:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFA48mTTfOu4 for ; Tue, 24 Apr 2012 05:28:57 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id B553621F8726 for ; Tue, 24 Apr 2012 05:28:57 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SMerY-0007tj-HW for sipcore@ietf.org; Tue, 24 Apr 2012 07:28:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 83B7DD8004 for ; Tue, 24 Apr 2012 07:28:56 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r58gFlMDEPBQ for ; Tue, 24 Apr 2012 07:28:56 -0500 (CDT) Received: from [192.168.1.5] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 1A3E4D8002 for ; Tue, 24 Apr 2012 07:28:56 -0500 (CDT) Message-ID: <4F969C7E.3070107@digium.com> Date: Tue, 24 Apr 2012 07:28:46 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 12:28:58 -0000 On 04/24/2012 07:04 AM, Ravindran, Parthasarathi wrote: > Paul, > > Thanks for clarify your view. In case your view is correct, then Usage of SIPS Scheme (Sec 9.2) of draft-ibc-sipcore-sip-websocket-02 draft should forbid the usage of SIPS URI for websocket transport (WSS, WS) as SIPS URI is mistake for TLS, the mistake *MUST NOT* be repeated and the draft text has to be updated as > > "SIPS URI MUST NOT be used for WS, WSS transport as the end-to-end security is not assured" How did you reach this conclusion? In this context, WebSocket-over-TLS-over-TCP is no different than TLS-over-TCP; usage of WebSocket on the first hop does not change the ability of the path to be end-to-end secure at all. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From pravindran@sonusnet.com Tue Apr 24 05:34:55 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3471B21F87EE for ; Tue, 24 Apr 2012 05:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 BKOJsG3SLINh for ; Tue, 24 Apr 2012 05:34:54 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id 50BD721F87EB for ; Tue, 24 Apr 2012 05:34:52 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKT5ad6zimWB+8cSugrZce7JOP2pdq7t4F@postini.com; Tue, 24 Apr 2012 05:34:52 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 24 Apr 2012 08:34:52 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 18:04:45 +0530 From: "Ravindran, Parthasarathi" To: "Kevin P. Fleming" , "sipcore@ietf.org" Thread-Topic: [sipcore] Websocket is a new transport or new URI? Thread-Index: AQHNIDOCuN/qLU9tjk656lTA6m0G85am5VEAgAD8KaCAAD8sgIABv2aw//+u7wCAAFyvAA== Date: Tue, 24 Apr 2012 12:34:45 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E2380E6@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> In-Reply-To: <4F969C7E.3070107@digium.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 12:34:55 -0000 Kevin, Please look into earlier mail of Paul's view on SIPS URI that SIPS URI (TLS= over TCP) is not end-to-end (http://www.ietf.org/mail-archive/web/sipcore/= current/msg04870.html). I asked the subsequent question to Paul based on his view on SIPS URI. Hope= this clarifies how I come to the below conclusion. Thanks Partha >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >Behalf Of Kevin P. Fleming >Sent: Tuesday, April 24, 2012 5:59 PM >To: sipcore@ietf.org >Subject: Re: [sipcore] Websocket is a new transport or new URI? > >On 04/24/2012 07:04 AM, Ravindran, Parthasarathi wrote: >> Paul, >> >> Thanks for clarify your view. In case your view is correct, then Usage >> of SIPS Scheme (Sec 9.2) of draft-ibc-sipcore-sip-websocket-02 draft >> should forbid the usage of SIPS URI for websocket transport (WSS, WS) >> as SIPS URI is mistake for TLS, the mistake *MUST NOT* be repeated and >> the draft text has to be updated as >> >> "SIPS URI MUST NOT be used for WS, WSS transport as the end-to-end >security is not assured" > >How did you reach this conclusion? In this context, WebSocket-over-TLS- >over-TCP is no different than TLS-over-TCP; usage of WebSocket on the >first hop does not change the ability of the path to be end-to-end >secure at all. > >-- >Kevin P. Fleming >Digium, Inc. | Director of Software Technologies >Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: >kpfleming >445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at >www.digium.com & www.asterisk.org >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From kpfleming@digium.com Tue Apr 24 05:44:29 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE3821F87F1 for ; Tue, 24 Apr 2012 05:44:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.953 X-Spam-Level: X-Spam-Status: No, score=-105.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, 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 w6EdCd5KCFh4 for ; Tue, 24 Apr 2012 05:44:28 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 79CD021F87C7 for ; Tue, 24 Apr 2012 05:44:28 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SMf6a-00088M-7C for sipcore@ietf.org; Tue, 24 Apr 2012 07:44:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 36D62D8004 for ; Tue, 24 Apr 2012 07:44:28 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV07Xnl9pyFe for ; Tue, 24 Apr 2012 07:44:27 -0500 (CDT) Received: from [192.168.1.5] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id B4CE7D8002 for ; Tue, 24 Apr 2012 07:44:27 -0500 (CDT) Message-ID: <4F96A022.9030403@digium.com> Date: Tue, 24 Apr 2012 07:44:18 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 CC: "sipcore@ietf.org" References: <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> <387F9047F55E8C42850AD6B3A7A03C6C0E2380E6@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E2380E6@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 12:44:29 -0000 On 04/24/2012 07:34 AM, Ravindran, Parthasarathi wrote: > Kevin, > > Please look into earlier mail of Paul's view on SIPS URI that SIPS URI (TLS over TCP) is not end-to-end (http://www.ietf.org/mail-archive/web/sipcore/current/msg04870.html). > > I asked the subsequent question to Paul based on his view on SIPS URI. Hope this clarifies how I come to the below conclusion. His point was that SIPS itself has design flaws. Usage of WebSocket instead of TLS doesn't change that, and there's no reason that the WebSocket protocol specification should disallow usage of SIPS URIs over WebSocket connections. If an implementor wishes to use SIPS URIs and understands the consequences, they should be free to use them. If you feel that *nobody* should use SIPS URIs under any circumstances (whether the transport is TLS, WebSocket, DTLS-SCTP or any other), then that's a totally different issue and should be addressed in a separate I-D that updates RFC3261. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From pravindran@sonusnet.com Tue Apr 24 06:18:22 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D443321F8808 for ; Tue, 24 Apr 2012 06:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.486 X-Spam-Level: X-Spam-Status: No, score=-6.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 7VJppfXJLSvy for ; Tue, 24 Apr 2012 06:18:22 -0700 (PDT) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE5221F8805 for ; Tue, 24 Apr 2012 06:18:21 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKT5aoHLUUCQWPfTimQAKtwdR6W12HD2UN@postini.com; Tue, 24 Apr 2012 06:18:21 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 24 Apr 2012 09:18:21 -0400 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.0355.002; Tue, 24 Apr 2012 18:48:15 +0530 From: "Ravindran, Parthasarathi" To: "Kevin P. Fleming" Thread-Topic: [sipcore] Websocket is a new transport or new URI? Thread-Index: AQHNIDOCuN/qLU9tjk656lTA6m0G85am5VEAgAD8KaCAAD8sgIABv2aw//+u7wCAAFyvAP//p6gAgABiPnA= Date: Tue, 24 Apr 2012 13:18:13 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E23811E@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> <387F9047F55E8C42850AD6B3A7A03C6C0E2380E6@inba-mail01.sonusnet.com> <4F96A022.9030403@digium.com> In-Reply-To: <4F96A022.9030403@digium.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 13:18:23 -0000 Kevin, Could you please let me know whether you agree that SIPS URI usage in Webso= cket over TLS over TCP (new design) has design flaw as TLS over TCP? Pleas= e note that the issue is not to implementer but the (SIPS) information misl= ead the user.=20 I'm not asking to forbid SIPS for all transport but atleast, SIPS MUST NOT = be permitted for all the new transport which will be introduced in SIP in c= ase it accepted as a known design flaw. OTOH, I proposed to use new SIPWSS URI which shall indicate explicitly that= first hop is secured by this mechanism. Thanks Partha >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >Behalf Of Kevin P. Fleming >Sent: Tuesday, April 24, 2012 6:14 PM >Cc: sipcore@ietf.org >Subject: Re: [sipcore] Websocket is a new transport or new URI? > >On 04/24/2012 07:34 AM, Ravindran, Parthasarathi wrote: >> Kevin, >> >> Please look into earlier mail of Paul's view on SIPS URI that SIPS URI >(TLS over TCP) is not end-to-end (http://www.ietf.org/mail- >archive/web/sipcore/current/msg04870.html). >> >> I asked the subsequent question to Paul based on his view on SIPS URI. >Hope this clarifies how I come to the below conclusion. > >His point was that SIPS itself has design flaws. Usage of WebSocket >instead of TLS doesn't change that, and there's no reason that the >WebSocket protocol specification should disallow usage of SIPS URIs over >WebSocket connections. If an implementor wishes to use SIPS URIs and >understands the consequences, they should be free to use them. > >If you feel that *nobody* should use SIPS URIs under any circumstances >(whether the transport is TLS, WebSocket, DTLS-SCTP or any other), then >that's a totally different issue and should be addressed in a separate >I-D that updates RFC3261. > >-- >Kevin P. Fleming >Digium, Inc. | Director of Software Technologies >Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: >kpfleming >445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at >www.digium.com & www.asterisk.org >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From kpfleming@digium.com Tue Apr 24 06:24:29 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2447B21F8824 for ; Tue, 24 Apr 2012 06:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.791 X-Spam-Level: X-Spam-Status: No, score=-105.791 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, 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 EdVuHxkoOf0l for ; Tue, 24 Apr 2012 06:24:28 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6266E21F8821 for ; Tue, 24 Apr 2012 06:24:28 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SMfjI-0000HQ-2f for sipcore@ietf.org; Tue, 24 Apr 2012 08:24:28 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 1565ED8004 for ; Tue, 24 Apr 2012 08:24:28 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dy7urmweorWN for ; Tue, 24 Apr 2012 08:24:27 -0500 (CDT) Received: from [192.168.1.5] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 8C881D8002 for ; Tue, 24 Apr 2012 08:24:27 -0500 (CDT) Message-ID: <4F96A982.8080500@digium.com> Date: Tue, 24 Apr 2012 08:24:18 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 CC: "sipcore@ietf.org" References: <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> <387F9047F55E8C42850AD6B3A7A03C6C0E2380E6@inba-mail01.sonusnet.com> <4F96A022.9030403@digium.com> <387F9047F55E8C42850AD6B3A7A03C6C0E23811E@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E23811E@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 13:24:29 -0000 On 04/24/2012 08:18 AM, Ravindran, Parthasarathi wrote: > Could you please let me know whether you agree that SIPS URI usage in Websocket over TLS over TCP (new design) has design flaw as TLS over TCP? Please note that the issue is not to implementer but the (SIPS) information mislead the user. > > I'm not asking to forbid SIPS for all transport but atleast, SIPS MUST NOT be permitted for all the new transport which will be introduced in SIP in case it accepted as a known design flaw. The 'design flaws' that have been discussed for SIPS URIs have nothing at all to do with the transport mechanism that is chosen. If WebSocket as a transport was unable to provide an appropriate level of security to meet the SIPS URI requirements/expectations, then I'd agree that the WebSocket transport specification should disallow usage of WebSocket for SIPS Request URIs. However, that is not the case: WebSocket provides nearly identical security properties to those provided by TLS. Given that, there is no reason to disallow usage of WebSocket for SIPS URIs, unless TLS is also going to be disallowed. Just like the previous discussion about Path and Outbound, these are implementation choices that should be left up to the implementor. Usage of SIPS URIs over WebSocket transport is not fundamentally broken, any more than it is fundamentally broken on any other secure transport. If the WG wants to make a statement about usage of SIPS URIs, then it should be done directly, for all transports, not just for WebSocket. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From pkyzivat@alum.mit.edu Tue Apr 24 09:10:33 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A78E21E8024 for ; Tue, 24 Apr 2012 09:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] 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 Xiv-wi9NHUaM for ; Tue, 24 Apr 2012 09:10:28 -0700 (PDT) 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 D043211E80A5 for ; Tue, 24 Apr 2012 09:10:27 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta08.westchester.pa.mail.comcast.net with comcast id 1rpc1j0010cZkys58sAU7q; Tue, 24 Apr 2012 16:10:28 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta10.westchester.pa.mail.comcast.net with comcast id 1sAP1j00k07duvL3WsAPQJ; Tue, 24 Apr 2012 16:10:23 +0000 Message-ID: <4F96D072.5010102@alum.mit.edu> Date: Tue, 24 Apr 2012 12:10:26 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852C42DF52F5@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C42DF52F5@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 16:10:33 -0000 Christer, [I'm sorry not getting this out sooner. I wrote it several days ago but somehow I never sent it.] Thanks for getting this update in. In general this looks good. I have some comments about details: Much of the syntax (ABNF - section 4.2.2) is a replica of what is in RFC3840. IMO this relationship should be acknowledged. My preference would be to formally reference the abnf definitions from 3840 and use the same names for them. E.g. feature-cap = ["+"] fcap-name [EQUAL LDQUOT (fcap-value-list / fcap-string-value ) RDQUOT] fcap-name = ftag-name fcap-value-list = tag-value-list fcap-string-value = string-value ;; ftag-name, tag-value-list, string-value defined in RFC3840 Also, I am inclined to make the "+" mandatory, even though it really serves no purpose. The reason I propose this is to minimize confusion with the usage rules in 3840. In 3840 the "+" is mandatory except for the "grandfathered" tags. And we have had trouble getting people to follow that. If we make it optional here it will further confuse things. OTOH, the reason for the + is so that feature tags can be distinguished from other contact parameters that are not feature tags. That need doesn't apply here, which is why the "+" is logically unnecessary. An alternative would be to *never* use the "+" here. But I'm inclined to require the "+" because there may be some tags defined for use as both feature tags and proxy features, and then I'd rather not use the "+" in place and not in the other. I also find it some what confusing that part of the syntax is in this section while more of it is in section 5.4. I'd prefer to see these consolidated into a single syntax section. Re Registration Trees: There is no mention of an IETF tree, analogous to that defined in 2506 for feature tags. Given the history, and a desire to provide a similar structure, I agree it makes sense that we aren't planning on defining anything of that sort. But I think it is confusing to anyone who has looked at 2506 that there is no mention of names that have only one facet. So, I think it would be helpful to explicitly state that names consisting of only a single facet, as well as names with initial facets other than "g" and "sip" are out of scope for this draft. I'm undecided if it would be good to define an IETF tree without any content, or if it would be better not to define it. The statements: The tree definitions are based on the global tree and sip tree defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3841 [RFC3841]. and The SIP feature cap global tree is based on the media feature tag global tree defined in RFC 2506 [RFC2506]. and The SIP feature cap sip tree is based on the media feature tag sip tree defined in RFC 3840 [RFC3840]. seem a little confusing to me, because its not clear what "based on" means. I suggest changing this to "similar to". As far as defining new trees, the current text is: Additional feature caps trees can be created by IANA, following the same rules and procedures as defined for media feature tags in section 3.1.4 of RFC 2506 [RFC2506]. This in effect makes a normative dependency between this document and RFC2506. I think it would be better to sever the formal tie. Instead, this can be accomplished by adding something similar to section 3.1.4 of 2506. Regarding the IANA Registration Template: | The reference MUST contain the information listed in | section XX of XXXX (IANA: Replace XXXX with assigned | RFC number of this specification I think this should say: | The referenced specification MUST contain the information listed | in section XX of XXXX (IANA: Replace XXXX with assigned | RFC number of this specification In addition there may be some redundancy between the "SIP feature cap specification reference" and the "Related standards or documents". Do you think we need both? Are there other things in there that are just baggage being carried over from 2506 that are not useful to us? (E.g. do we need the publication delay?) Section 4.5.2 says: The SIP feature cap specification MUST contain an overall description of the SIP feature cap: how it is used to indicate support of a feature, a description of the feature associated with the SIP feature cap, and a description of any additional information (conveyed using one or more SIP feature cap values) that can be conveyed together with the SIP feature cap. What this doesn't talk about is how the feature associated with the feature cap is exercised/invoked. So I would suggest something like: The SIP feature cap specification MUST contain an overall description of the SIP feature cap: how it is used to indicate support of a feature, a description of the feature associated with the SIP feature cap, a description of any additional information (conveyed using one or more SIP feature cap values) that can be conveyed together with the SIP feature cap, and a description of how the associated feature may be exercised/invoked. Section 4.5.3: The rules described here sound to me like ones suitable for the name of a parameter (e.g. a parameter bound to an event or a mime type, or to a sip header.) It doesn't seem very appropriate when discussing the representation of a *value* of a parameter/feature. For example, when values are enumerations, we might find things like "true" and "false" or "yes" and "no". Even if they are "red" / "green" / "blue", the same values might well make sense associated with other features. Can you please think this through further? It may indeed make sense to say *something* here, but I imagine something weaker. Section 4.5.5 says: NOTE: Sometimes a SIP feature cap designer might choose to not reveal the implementation details of a SIP feature cap. However, in order to allow multiple implementations to support the SIP feature cap, designers are strongly encouraged to provide the implementation details. I recognize that people may not want to publish implementation details. But that is different from providing enough specification to all independent but interoperable implementations to be developed. The amount that needs to be disclosed might vary based on which registration tree is used. I would expect that the sip tree would require sufficient spec to support an independent implementation. If you were instituting a URI tree then I can see that it might be considered entirely proprietary and hence might not require this. (But you have omitted the URI tree, which thus sidesteps this issue.) ISTM that the global tree should still require a definition of how to create an interoperable implementation. The difference between the global tree and the sip tree in this regard might be that in the case of the sip tree the referenced specification must be an IETF document, while in the case of the global tree it could be some external document. Section 5.2.1 says: When the UA receives the SIP request or the response, the SIP feature caps in the topmost Feature-Caps header field will represent the supported features "closest" to the UA. I don't think this is quite what you mean. I think you mean: When the UA receives the SIP request or the response, the SIP feature caps in the first fc-value will represent the supported features "closest" to the UA. Section 5.2.2 says: The procedures in this section applies to UAs that are part of B2BUAs, but where the URI in the Contact header field does not represent the UA, because the B2BUA is also acting as a proxy and inserts its URI e.g. in a Record-Route header field. IMO this covers some controversial ground, but probably only in ways that many will consider pedantic. We are in quite under specified territory when we talk about B2BUAs that act as Proxies. Does this mean that it was a proxy when the dialog was established, but later the same entity redeclares itself as a UA for some subsequent transaction within the dialog? Or was it acting as a UA when the dialog was established, but still chose to use a Contact URI that doesn't identify itself? As much as I would like to have an extended discussion on this, doing so while working on this draft is probably counterproductive. Perhaps you can humor my sensitivities and just change this to: The procedures in this section applies to UAs that are part of B2BUAs that are referenced in the message by a Record-Route header field rather than by the Contact URI. Section 5.2.2 then says: When a UA sends a SIP request, if the UA wants to indicate support of features towards its downstream SIP entities, it adds a Feature-Caps header field to the request, together with one or more Feature Caps associated with the supported features, before it forwards the request. This says "adds" but doesn't say whether to be beginning or the end. Also, it isn't strictly necessary to add another header field, it can add to an existing header field. So I suggest: When a UA sends a SIP request, if the UA wants to indicate support of features towards its downstream SIP entities, before it forwards the request it adds a fc-value with the supported features to the request, after any others that may be present. This may be added to the last existing Feature-Caps header field or as a new Feature-Caps header field after any others. Something similar applies a couple more times in this section and in sections 5.2.3 and 5.2.4. I realize this is a bit cumbersome - perhaps there is a more straightforward way to say it. Section 5.3.3 says: If a SIP feature cap is inserted in a Feature-Caps header field of a SIP REGISTER request, or within a response of such request, it indicates to the receivers of the request (or response) that the feature associated with the SIP feature cap is supported for the duration of the registration, and for all SIP transactions associated with the registration, until the registration is re-freshed or terminated. There are some cases we need to discuss here. When a UA sends a REGISTER request, it could have no contacts, one contact, or several. What do the feature caps mean in these cases? - if there are no contacts in the register, are feature-caps irrelevant? - if there is more than one contact in the register, do the feature-caps apply to all of them? Then the response should contain all the registered contacts, not just those mentioned in the request. So do the feature caps mentioned in the reply apply until the last of those contacts expire? Or should the requester assume they only apply until *its* contacts expire? Unless a SIP feature cap is inserted in a Feature-Caps header field or a re-registration, or within a response of such request, it indicates to the receivers of the request (or response) that the feature is no long supported for the registration. Suppose a UA registers with a contact and some feature caps. Then later it sends a register poll (register with no contacts). Can I assume that this will not affect the feature caps associated with the registered contact? Do the enhanced registrar behaviors in outbound require any special treatment relative to feature caps? Section 6: There are a lot of missing IANA considerations - the establishment of the new trees as defined in 4.3 and 4.4. That is all for now. Thanks, Paul On 4/17/12 3:05 AM, Christer Holmberg wrote: > Hi, > > IĀ’ve submitted a new version (-01) of the proxy-feature draft. > > Based on the discussions in Paris, instead of using feature tags the > draft now creates a new IANA Ā“feature capĀ” registry. > > Regards, > > Christer > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dworley@avaya.com Tue Apr 24 10:57:36 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4311111E80B7 for ; Tue, 24 Apr 2012 10:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.337 X-Spam-Level: X-Spam-Status: No, score=-103.337 tagged_above=-999 required=5 tests=[AWL=0.262, 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 zNbCs7ckCVLI for ; Tue, 24 Apr 2012 10:57:35 -0700 (PDT) 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 4E1C911E808F for ; Tue, 24 Apr 2012 10:57:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABzplk/GmAcF/2dsb2JhbABEsXmBB4IJAQEBAQIBEig/BQsCAQgNCAMeEDIlAQEEDgUIGodoBZ1KnUqQbmMEnBCKKIMF X-IronPort-AV: E=Sophos;i="4.75,475,1330923600"; d="scan'208";a="344072456" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Apr 2012 13:56:57 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Apr 2012 13:54:47 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Tue, 24 Apr 2012 13:57:15 -0400 From: "Worley, Dale R (Dale)" To: Shida Schubert Date: Tue, 24 Apr 2012 13:57:16 -0400 Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-07 - sections 10.1 and 11-end Thread-Index: Ac0e5ZJxAwpr/pKLTH21KhrGHurIiQDVvq2g Message-ID: References: , <34EB8104-E380-4E35-B3FA-08F8C80CD60F@ntt-at.com> In-Reply-To: <34EB8104-E380-4E35-B3FA-08F8C80CD60F@ntt-at.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-07 - sections 10.1 and 11-end X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 17:57:36 -0000 > From: Shida Schubert [shida@ntt-at.com] >=20 > On Apr 20, 2012, at 11:33 AM, Worley, Dale R (Dale) wrote: >=20 > > Correction of my comments on 10.3: I proposed removing all of item 6: > > > > 6. Missing entity: If the request clearly has a gap in the hi-entry > > (e.g. by evaluating via header to the existing request history to > > see if it traversed a domain which doesn't exist in History-Info > > header field.), the entity adding an hi-entry MUST add an index a > > digit of "0" to the current index prior to adding appropriate > > index for the action to be taken. If the index of the last hi- > > entry in the request received was 1.1.2 and there was a missing > > hi-entry and the request was being forwarded to the next hop, the > > resulting index will be 1.1.2.0.1. > > > > But I should have restricted it to removing the "condition", namely > > "(e.g. by evaluating via header to the existing request history to see > > if it traversed a domain which doesn't exist in History-Info header > > field.)" >=20 > Okay, that is more clear but I still see no harm in leaving it in 10.3. >=20 > The text could reside in 9.2 but I personally think it provides more uses > by having it in 10.3. Let me reconstitute what I should have said, and then let's see if we still disagree: In 9.1, "Receiving a Request" (not 9.2 as I said above), is: If the Request-URI of the incoming request does not match the hi- targeted-to-uri in the last hi-entry (i.e., the previous SIP entity that sent the request did not include a History-Info header field), the SIP entity MUST add a hi-entry to end of the cache, on behalf of the previous SIP entity, as follows: The condition in section 10.3 item 6 (as shown above) is: If the request clearly has a gap in the hi-entry (e.g. by evaluating via header to the existing request history to see if it traversed a domain which doesn't exist in History-Info header field.),=20 I think this condition should be added to the condition in 9.1 as an alternative situation in which the procedures of 9.1 should be performed. I think we agree that we *intend* the procedures of 9.1 to be applied in the conditions described in item 6, but I am emphasizing that 9.1 is the "procedural" text that specifies when in processing these procedures are done, and 9.1 should list *all* the conditions that trigger it. Now that I read 10.3 again, I see that 10.3 is not procedural, but rather gives in one place all the rules for constructing hi-indexes of new hi-entries. And from that point of view, item 6 is proper as written. I might suggest that item 6 should refer to 9.1 as 9.1 is the the implementation of the rules in item 6, but I see that no other item in 10.3 refers to "procedural" sections; all the references are in the reverse direction. So I stand by my recommended change to section 9.1, but 10.3 does not need to be changed. Let me try to update 9.1 in a less messy way than my last attempt: The SIP entity MUST detect whether the request clearly has a gap in the hi-entries, mandatorily by testing if the Request-URI of the incoming request does not match the hi-targeted-to-uri in the last hi-entry, and optionally by other tests, e.g. by comparing the Via header to the existing request history to see if it traversed a domain which doesn't exist in History-Info header field. If a gap is detected, the SIP entity MUST add a hi-entry to end of the cache, on behalf of the previous SIP entity, as follows: The original text referred to by the following remarks is: | Gaps are also possible in the case of | parallel forking if there is an outstanding request at the time the | SIP entity sends a response as described in Section 9.4, in which | case the gap will not be visible as the branch responsible for the | gap wasn't on the path of the request received. > > A gap (missing branch) due to an outstanding request can be revealed > > in both requests and responses. The final part of the sentence I > > can't understand. I wonder if there was a further sentence which was > > damaged and joined to this previous sentence. >=20 > We were just trying to describe how there could be an index missing > not a "0" but a branch can start from 2 instead of 1 due to parallel fork= ing. One problem is that "gap" is being used in two senses throughout this draft. One sense is "a branch of parallel forking that is not recorded in this History-Info header, but is revealed by non-sequential numbering of the children of an entry". Another sense is "an ancester of this request did not add an hi-entry". Another is the phrase "gap will not be visible" -- the *gap* is visible, I think you mean "the hi-entries whose absence constitute the gap are not present". I've tried to revise that sentence but I don't grasp exactly what situation you are describing. It seems to be some case of the general rule that branches of the overall hi-entry tree can be missing at any point, due to the timings of requests and responses in the propagation of the request. Dale From pkyzivat@alum.mit.edu Tue Apr 24 12:35:53 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C3521F8751 for ; Tue, 24 Apr 2012 12:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 JRFfsNno3gLC for ; Tue, 24 Apr 2012 12:35:52 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF1D21F86D0 for ; Tue, 24 Apr 2012 12:35:52 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id 1ufs1j0031ap0As55vbtzX; Tue, 24 Apr 2012 19:35:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id 1vbu1j00C07duvL3ivbuL5; Tue, 24 Apr 2012 19:35:54 +0000 Message-ID: <4F970097.5020002@alum.mit.edu> Date: Tue, 24 Apr 2012 15:35:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> In-Reply-To: <4F969C7E.3070107@digium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 19:35:53 -0000 On 4/24/12 8:28 AM, Kevin P. Fleming wrote: > On 04/24/2012 07:04 AM, Ravindran, Parthasarathi wrote: >> Paul, >> >> Thanks for clarify your view. In case your view is correct, then Usage >> of SIPS Scheme (Sec 9.2) of draft-ibc-sipcore-sip-websocket-02 draft >> should forbid the usage of SIPS URI for websocket transport (WSS, WS) >> as SIPS URI is mistake for TLS, the mistake *MUST NOT* be repeated and >> the draft text has to be updated as >> >> "SIPS URI MUST NOT be used for WS, WSS transport as the end-to-end >> security is not assured" > > How did you reach this conclusion? In this context, > WebSocket-over-TLS-over-TCP is no different than TLS-over-TCP; usage of > WebSocket on the first hop does not change the ability of the path to be > end-to-end secure at all. It may be that WebSocket-over-TLS-over-TCP is *conceptually* no different than TLS-over-TCP. But its far from clear that this is so with the current wording of 3261 and 5630. I expect that a careful review of these needs to be done and some normative updates done. I went through 3261 looking at discussions of sips for things that might be problematic or at least need some consideration. Here are some of them: Any implementation that supports TLS MUST support the SIPS URI scheme. The To header field allows for a display name. If the request arrived over TLS, and the Request-URI contained a SIPS URI, the "secure" flag is set to TRUE. If the request was sent over TLS, and the Request-URI contained a SIPS URI, the "secure" flag is set to TRUE. Furthermore, if the Request-URI contains a SIPS URI, TLS MUST be used to communicate with that proxy. For a SIPS URI, the transport parameter MUST indicate a reliable transport. When a request is sent to a SIPS URI, the protocol still indicates "SIP", and the transport protocol is TLS. When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request-URI, must be secured with TLS The use of SIPS in particular entails that mutual TLS authentication SHOULD be employed, as SHOULD the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. Note that in the SIPS URI scheme, transport is independent of TLS, and thus "sips:alice@atlanta.com;transport=tcp" and "sips:alice@atlanta.com;transport=sctp" are both valid (although note that UDP is not a valid transport for SIPS). The use of "transport=tls" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543. All SIP elements that support TLS MUST also support the SIPS URI scheme. I'm not suggesting exactly *what* needs to be done - just that it needs to be figured out. As a consequence, I would expect that it would be possible to use sips with websockets, but no requirement to do so. Whether its helpful, or wise, to use sips is a separate question. Thanks, Paul From pkyzivat@alum.mit.edu Tue Apr 24 12:42:03 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5073B21F8807 for ; Tue, 24 Apr 2012 12:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=-1.347, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, MANGLED_SAVELE=2.3] 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 u5qB6o8U6Tkj for ; Tue, 24 Apr 2012 12:42:01 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 40EE321F87F8 for ; Tue, 24 Apr 2012 12:42:01 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta10.westchester.pa.mail.comcast.net with comcast id 1v0E1j00717dt5G5Avi2Nl; Tue, 24 Apr 2012 19:42:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta13.westchester.pa.mail.comcast.net with comcast id 1vi21j01C07duvL3Zvi2DM; Tue, 24 Apr 2012 19:42:03 +0000 Message-ID: <4F970207.3020903@alum.mit.edu> Date: Tue, 24 Apr 2012 15:41:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Nataraju A.B" References: <4F9560EC.9030308@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] comments on draft-ietf-sipcore-rfc3265bis-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 19:42:03 -0000 Nataraju, On 4/23/12 12:32 PM, Nataraju A.B wrote: > Paul, > > I understand, I was late into the party... :( > > The comment is more of an OPTIMIZATION issue. As a minimal > change, can we add a normative text which provide some pointers for > implementers to differentiate the re-SUBSCRIBE (to extend the > subscription duration) and re-SUBSCRIBE (to fetch the complete state, > due to lost NOTIFY). > > This might be of great concern for lossy networks (for example, wireless > networks, ...), where all the subsequent refresh SUBSCRIBE requests > would un-necessarily eats up more bandwidth for fetching the complete > state which is not necessary. For non-lossy network this is of minor > issue... > > Even if we decide to handle this optimization issue, we have to analyze > thoroughly how to differentiate differentiate these requests, through > some new header / header parameter / any other way. Need more analysis... > > You can take a call, based on the feasibility. Even if dropped it is > fine.... > > Thanks, > Nataraju A B Adam already responded that there exists a mechanism to optimize the redundant notifications away. We definitely won't embark on any functional changes to this draft at this late stage. Regarding the editorial comments - its again very late, and I don't find any of them compelling. In the future please try to get your reviews in no later than WGLC. Thanks, Paul > On Mon, Apr 23, 2012 at 7:32 PM, Paul Kyzivat > wrote: > > Nataraju, > > Your comments would have been much more helpful if received some > months ago when the document went through WGLC. This document is now > *very* far down the process to publication, having already gone > through IESG last call, IANA review, etc. and is now in final IESG > Evaluation. Changes at this point are very disruptive. > > If you feel your suggestions are essential then you will have to go > to extremes to pull this document back. I don't see anything below > that convinces me to do that. AFAICT the comments below are all > minor editorial except for the first, which suggests changing the > mechanism. > > Thanks, > Paul (as co-chair) > > > On 4/23/12 12:58 AM, Nataraju A.B wrote: > > All, > > Some logical comments on the draft-ietf-sipcore-rfc3265bis-__08.txt. > > ------------------------------__----------------------- > 5.3.2. State Deltas > > CurrentText: > > If a NOTIFY request arrives that has a version number that is > incremented by more than one, the subscriber knows that a > state delta > has been missed; it ignores the NOTIFY request containing > the state > delta (except for the version number, which it retains to detect > message loss), and re-sends a SUBSCRIBE request to force a > NOTIFY > request containing a complete state snapshot. > > Comment: > From this text, it infers that if any state delta lost, then > subscriber > sends refresh SUBSCRIBE (re-SUBSCRIBE) request. This > re-SUBSCRIBE > request inturn lead > to fetching the complete state information. > > It may be a good diea to differentiate the re-SUBSCRIBE > triggered by > different scenarios. > a) natural re-SUBSCRIBE request, which extends the SUBSCRIBE > duration. In this > case it is not necessary to fetch the complete state > information > b) re-SUBSCRIBE triggered because of lost NOTIFY request > (ref sec > 5.3.2. > VERSION number in received NOTIFY is increased by greater > than ONE). > In this case subscriber wants to fetch the complete state > information. > > If we don't differentiate these two cases, then natural > re-SUBSCRIBE > request > unnecessarily fetch the complete state information, which > may not be > necessary / expected. > But uses higher network bandwidth to fetch the complete state > information. > ------------------------------__----------------------- > ------------------------------__----------------------- > 4.4.1. Dialog Creation and Termination > > CurrentText: > > A subscriber may send a SUBSCRIBE request with an > "Expires" header > field of 0 in order to trigger the sending of such a NOTIFY > request; however, for the purposes of subscription and dialog > lifetime, the subscription is not considered terminated > until the > NOTIFY transaction with a "Subscription-State" of > "terminated" > completes. > > Comment: > We may have to mention how long the dialog must be kept alive, > before > being cleaned up. Should we delete the dialog immediately after > 200-SUB > or wait till NOTIFY with "Subscription-State"="__terminated". If > we always > wait till Last Notify for dialog termination, then 200-SUB don't > have any > impact on the dialog termination. Atleast some normative text is of > necessity, for better understanding of the topic. > ------------------------------__----------------------- > ------------------------------__----------------------- > 3.1.1. Subscription Duration > > CurrentText: > > SUBSCRIBE requests SHOULD contain an "Expires" header field > (defined > in [RFC3261]). This expires value indicates the duration of the > subscription. In order to keep subscriptions effective > beyond the > duration communicated in the "Expires" header field, > subscribers need > to refresh subscriptions on a periodic basis using a new > SUBSCRIBE > request on the same dialog as defined in [RFC3261]. > > Comment: > We can add a normative text saying, the refresh time will be > normally 50% to 75% of subscription duration. > > ------------------------------__----------------------- > ------------------------------__----------------------- > 4.1.2.1. Requesting a Subscription > > CurrentText: > [RFC3261]. For the sake of clarity: if a SUBSCRIBE request > contains > an "Accept" header field, but that field does not indicate a > media > type that the notifier is capable of generating in its NOTIFY > requests, then the proper error response is 406 (Not > Acceptable). > > COMMENT: > It is better to mention it as a normative text (indented). > > ------------------------------__----------------------- > ------------------------------__----------------------- > 4.1.2. Creating and Maintaining Subscriptions > > > CurrentText: > > From the subscriber's perspective, a subscription proceeds > according > to the following state diagram: > > Comment: > Here it is better to mention, what happens to FSM when 200-SUBSCRIBE > received in notify_wait state (because very often this is possible). > If no change in state of FSM, then some normative text shall > convey the > same. > It may be no-operation, but better to mention the same. > ------------------------------__----------------------- > ------------------------------__----------------------- > 3.1.1. Subscription Duration > > CurrentText: > In addition to being a request to unsubscribe, a > SUBSCRIBE request > with "Expires" of 0 also causes a fetch of state; see > Section 4.4.3. > > Comment: > The above text has been mentioned to be normative text. > But I feel > this > shall be written as a regualr text in the draft/rfc. > because this > is the > expected behavior from the notifier. > ------------------------------__----------------------- > ------------------------------__----------------------- > 3.2.1. > > CurrentText: > This body will contain either the state of the subscribed > resource or > a pointer to such state in the form of a URI (see Section > 5.4.13). > > ReplacementText/Comment: > This body **SHALL** contain either the state of the subscribed > resource or > a pointer to such state in the form of a **URL** (see > Section 5.4.13). > ------------------------------__----------------------- > ------------------------------__----------------------- > 4.2.1. Subscription Establishment and Maintenance > > CurrentText: > inability to signal the success of a REFER request while > signaling > a problem with the subscription; and difficulty > performing one > action without the other. Additionally, the proper > exchange of > > ReplacementText: > inability to signal the success of a REFER request while > signaling > a problem with the subscription; and difficulty **in** > performing one > action without the other. Additionally, the proper > exchange of > > ------------------------------__----------------------- > > Thanks, > Nataraju A B > > ---------- Forwarded message ---------- > From: *Nataraju A.B* > __>> > Date: Fri, Apr 13, 2012 at 10:53 PM > Subject: draft-ietf-sipcore-rfc3265bis-__08.txt - Review comments > (Nataraju A B) > To: Adam Roach > >>, > sipcore@ietf.org > > > > > Adam, > > Please find some editorial comments on the draft > "draft draft-ietf-sipcore-rfc3265bis-__08.txt" > > For simplicity, I have mentioned both the current text and > proposed text. > > The comments / corrective text can be found with prefix and > suffix --- ** > > ------------------------------__----------------------- > 1.1. Overview of Operation > CurrentText: > The general concept is that entities in the network can > subscribe to > resource or call state for various resources or calls in the > network, > and those entities (or entities acting on their behalf) can send > notifications when those states change. > > ReplacementText: > The general concept is that entities in the network can > subscribe to > resource or call state **at / of** various resources or > calls in the > network, > and those entities (or entities acting on their behalf) > **who** can send > notifications when those states change. > ------------------------------__----------------------- > > 1.1. Overview of Operation > > CurrentText: > Subscriptions are expired and must be refreshed by subsequent > SUBSCRIBE requests. > > ReplacementText: > Subscriptions are expired and must be refreshed by subsequent > SUBSCRIBE requests **before expiration**. > ------------------------------__----------------------- > > 2. Definitions > > CurrentText: > Subscriber: A subscriber is a user agent which receives NOTIFY > requests from notifiers; these NOTIFY requests contain > information > about the state of a resource in which the subscriber is > interested. Subscribers typically also generate SUBSCRIBE > requests and send them to notifiers to create subscriptions. > > Comment: > After this information, we can add a normative text which indicates > when a SIP entity might get NOTIFY messages without actually > sending SUBSCRIBE request. For example, REFER request might end > up with > implicit subscription. Also mention any other requests which may > lead to > implicit subscriptions (other than REFER). > ------------------------------__----------------------- > 2. Definitions > > CurrentText: > Subscription: A subscription is a set of application state > associated with a dialog. This application state includes a > pointer to the associated dialog, the event package name, and > possibly an identification token. Event packages will define > additional subscription state information. By definition, > subscriptions exist in both a subscriber and a notifier. > > ReplacementText: > Subscription: A subscription is a set of application **states** > associated with a dialog. **The** application state > includes a > pointer to the associated dialog, the event package name, and > possibly an identification token. Event packages will define > additional subscription state information. By definition, > subscriptions exist in both a subscriber and a notifier. > ------------------------------__----------------------- > 3.1.1. Subscription Duration > > CurrentText: > > subscription. In order to keep subscriptions effective > beyond the > duration communicated in the "Expires" header field, > subscribers need > to refresh subscriptions on a periodic basis using a new > SUBSCRIBE > request on the same dialog as defined in [RFC3261]. > > ReplacementText > 3.1.1. Subscription Duration > > subscription. In order to keep subscriptions effective > beyond the > duration communicated in the "Expires" header field, > subscribers need > to refresh subscriptions **before expiration** on a periodic > basis > using a new SUBSCRIBE > request on the same dialog as defined in [RFC3261]. > ------------------------------__----------------------- > 3.1.1. Subscription Duration > > CurrentText: > In addition to being a request to unsubscribe, a > SUBSCRIBE request > with "Expires" of 0 also causes a fetch of state; see > Section 4.4.3. > > Comment: > The above text has been mentioned to be normative text. > But I feel > this > shall be written as a regualr text in the draft/rfc. > because this > is the > expected behavior from the notifier. > ------------------------------__----------------------- > 3.1.2. Identification of Subscribed Events and Event Classes > > CurrentText: > Subscribers MUST include exactly one "Event" header field in > SUBSCRIBE requests, indicating to which event or class of > events they > are subscribing. The "Event" header field will contain a > token which > indicates the type of state for which a subscription is being > requested. This token will be registered with the IANA and will > correspond to an event package which further describes the > semantics > of the event or event class. > > > ReplacementText: > Subscribers MUST include exactly one "Event" header field in > SUBSCRIBE requests, indicating to which event or class of > events they > are subscribing. The "Event" header field **MUST** contain > a token > which > indicates the type of state for which a subscription is being > requested. This token will be registered with the IANA and will > correspond to an event package which further describes the > semantics > of the event or event class. > ------------------------------__----------------------- > 3.1. SUBSCRIBE > > CurrentText: > The SUBSCRIBE method is used to request current state and state > updates from a remote node. SUBSCRIBE requests are target > refresh > > > ReplacementText: > The SUBSCRIBE method is used to request current state and > **subsequent** state > updates from a remote node. SUBSCRIBE requests are target > refresh > > > ------------------------------__----------------------- > 3.1.1. Subscription Duration > > CurrentText: > > SUBSCRIBE requests SHOULD contain an "Expires" header field > (defined > in [RFC3261]). This expires value indicates the duration of the > subscription. In order to keep subscriptions effective > beyond the > duration communicated in the "Expires" header field, > subscribers need > to refresh subscriptions on a periodic basis using a new > SUBSCRIBE > request on the same dialog as defined in [RFC3261]. > > Comment: > We can add a normative text saying, the refresh time will be > normally 50% to 75% of subscription duration. > > ------------------------------__----------------------- > 3.2.1. > > CurrentText: > This body will contain either the state of the subscribed > resource or > a pointer to such state in the form of a URI (see Section > 5.4.13). > > ReplacementText/Comment: > This body **SHALL** contain either the state of the subscribed > resource or > a pointer to such state in the form of a **URL** (see > Section 5.4.13). > ------------------------------__----------------------- > 4.1.2. Creating and Maintaining Subscriptions > > > CurrentText: > > From the subscriber's perspective, a subscription proceeds > according > to the following state diagram: > > Comment: > Here it is better to mention, what happens to FSM when 200-SUBSCRIBE > received in notify_wait state (because very often this is possible). > If no change in state of FSM, then some normative text shall > convey the > same. > It may be no-operation, but better to mention the same. > ------------------------------__----------------------- > 4.1.2.1. Requesting a Subscription > > CurrentText: > When a subscriber wishes to subscribe to a particular state > for a > resource, it forms a SUBSCRIBE request. If the initial > SUBSCRIBE > > ReplacementText: > When a subscriber wishes to subscribe to a particular state > **of** a > resource, it forms a SUBSCRIBE request **according to sec > 3.1 and > send it across to notifier**. If the initial SUBSCRIBE > > ------------------------------__----------------------- > 4.1.2.1. Requesting a Subscription > > CurrentText: > [RFC3261]. For the sake of clarity: if a SUBSCRIBE request > contains > an "Accept" header field, but that field does not indicate a > media > type that the notifier is capable of generating in its NOTIFY > requests, then the proper error response is 406 (Not > Acceptable). > > COMMENT: > It is better to mention it as a normative text (indented). > > ------------------------------__----------------------- > 4.1.3. Receiving and Processing State Information > > CurrentText: > > If the "Subscription-State" value is "terminated", the > subscriber > MUST consider the subscription terminated. The "expires" > parameter > has no semantics for "terminated" -- notifiers SHOULD NOT > include an > > ReplacementText: > > If the "Subscription-State" value is "terminated", the > subscriber > MUST consider the subscription terminated. The "expires" > parameter > has no semantics for "terminated" **state**. Notifiers > SHOULD NOT > include an > ------------------------------__----------------------- > > CurrentText: > deactivated: The subscription has been terminated, but the > subscriber SHOULD retry immediately with a new > subscription. One > > ReplacementText: > deactivated: The subscription has been terminated, but the > subscriber SHOULD retry with a new subscription. One > > Is It mandatory to resubscribe immediately. if not remove > the word > "immediately". > If it is delayed, what are the consequences ???? > > ------------------------------__----------------------- > 4.2.1. Subscription Establishment and Maintenance > > CurrentText: > inability to signal the success of a REFER request while > signaling > a problem with the subscription; and difficulty > performing one > action without the other. Additionally, the proper > exchange of > > ReplacementText: > inability to signal the success of a REFER request while > signaling > a problem with the subscription; and difficulty **in** > performing one > action without the other. Additionally, the proper > exchange of > > ------------------------------__----------------------- > 4.2.1.4. Refreshing of Subscriptions > > CurrentText: > If no refresh for a notification address is received before its > expiration time, the subscription is removed. When removing a > > ReplacementText: > If no refresh for a notification is received before its > expiration time, the subscription is removed. When removing a > Comment:Word "address" needs to be removed. > ------------------------------__----------------------- > 4.3. Proxy Behavior > > CurrentText: > Proxies that did not add a Record-Route header field to the > initial > SUBSCRIBE request MUST NOT add a Record-Route header field > to any of > the associated NOTIFY requests. > > ReplacementText: > Proxies that did not add a Record-Route header field to the > initial > SUBSCRIBE request MUST NOT add a Record-Route header field > to any of > the associated NOTIFY requests **or any SUBSCRIBE refresh > requests**. > ------------------------------__----------------------- > 4.4.1. Dialog Creation and Termination > > CurrentText: > > A subscriber may send a SUBSCRIBE request with an > "Expires" header > field of 0 in order to trigger the sending of such a NOTIFY > request; however, for the purposes of subscription and dialog > lifetime, the subscription is not considered terminated > until the > NOTIFY transaction with a "Subscription-State" of > "terminated" > completes. > > Comment: > We may have to mention how long the dialog must be kept alive, > before > being cleaned up. Do we delete the dialog immediately after 200-SUB > or wait till NOTIFY with "Subscription-State"="__terminated". If > we always > wait till Last Notify for dialog termination, then 200-SUB don't > have any > impact on the dialog termination. Atleast some normative text is of > necessity, for better understanding of the topic. > ------------------------------__----------------------- > 4.4.3. Polling Resource State > > CurrentText: > > Note that the NOTIFY requests triggered by SUBSCRIBE > requests with > "Expires" header fields of 0 will contain a "Subscription-State" > value of "terminated", and a "reason" parameter of "timeout". > > ReplacementText: > Note that the NOTIFY requests triggered by SUBSCRIBE > requests with > "Expires" header fields of 0 **shall** contain a > "Subscription-State" > value of "terminated", and a "reason" parameter of "timeout". > ------------------------------__----------------------- > 4.5.2. Sharing Dialogs > > CurrentText: > for a dialog (e.g., route set handling). In particular, > multiple > subscriptions within a dialog are expire independently, and > require independent subscription refreshes. > > ReplacementText: > for a dialog (e.g., route set handling). In particular, > multiple > subscriptions within a dialog **operates** independently, and > require independent subscription refreshes. > ------------------------------__----------------------- > 4.5.2. Sharing Dialogs > > CurrentText: > o Subscribers MAY include an "id" parameter in SUBSCRIBE > request > "Event" header field to allow differentiation between multiple > > ReplacementText: > o Subscribers MAY include an "id" parameter in SUBSCRIBE > **request's** > "Event" header field to allow differentiation between multiple > OR > o Subscribers MAY include an "id" parameter in **"Event" > header field > of SUBSCRIBE request** to allow differentiation between > multiple > ------------------------------__----------------------- > 4.5.2. Sharing Dialogs > > CurrentText: > o When a subscriber refreshes a the subscription timer, the > SUBSCRIBE request MUST contain the same "Event" header > field "id" > parameter as was present in the SUBSCRIBE request that > created the > subscription. (Otherwise, the notifier will interpret the > > ReplacementText: > o When a subscriber refreshes a the subscription timer, the > SUBSCRIBE request MUST contain the same **"id" parameter > in "Event" > header field, which** was present in the SUBSCRIBE > request that > created the > subscription. (Otherwise, the notifier will interpret the > ------------------------------__----------------------- > 4.5.2. Sharing Dialogs > > CurrentText: > > o When a subscription is created in the notifier, it stores any > "Event" header field "id" parameter as part of the subscription > information (along with the event package name). > > ReplacementText: > o When a subscription is created in the notifier, it stores > **the** > **"id" parameter in "Event" header field** as part of the > subscription > information (along with the event package name). > ------------------------------__----------------------- > 4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions > > CurrentText: > > Neither SUBSCRIBE nor NOTIFY requests can be canceled. If a UAS > receives a CANCEL request that matches a known SUBSCRIBE or > NOTIFY > transaction, it MUST respond to the CANCEL request, but > otherwise > ignore it. In particular, the CANCEL request MUST NOT affect > processing of the SUBSCRIBE or NOTIFY request in any way. > > ReplacementText/Comment: > What should be the response code for the CANCEL's reply ??? > Preferably 200-OK shall be used. > ------------------------------__----------------------- > 4.6. CANCEL Requests for SUBSCRIBE and NOTIFY Transactions > > CurrentText: > > UACs SHOULD NOT send CANCEL requests for SUBSCRIBE or NOTIFY > transactions. > > ReplacementText: > UACs **MUST** NOT send CANCEL requests for SUBSCRIBE or NOTIFY > transactions. **UASs SHOULD send 200OK for CANCEL within NOTIFY > or SUBSCRIBE transaction duration. As per sec 9 of [RFC3261]** > ------------------------------__----------------------- > 5.3.2. State Deltas > > CurrentText: > > In the case that the state information to be conveyed is > large, the > event package may choose to detail a scheme by which NOTIFY > requests > contain state deltas instead of complete state. > > > ReplacementText: > In the case that the state information to be conveyed is > large, the > event package may choose a scheme by which NOTIFY requests > contain state deltas instead of complete state. > > comment:deleted words "to detail" in 2nd line. > > ------------------------------__----------------------- > 5.3.2. State Deltas > > CurrentText: > > If a NOTIFY request arrives that has a version number that is > incremented by more than one, the subscriber knows that a > state delta > has been missed; it ignores the NOTIFY request containing > the state > delta (except for the version number, which it retains to detect > message loss), and re-sends a SUBSCRIBE request to force a > NOTIFY > request containing a complete state snapshot. > > Comment: > From this text, it infers that if any state delta lost, then > subscriber > sends refresh SUBSCRIBE (re-SUBSCRIBE) request. This > re-SUBSCRIBE > request inturn lead > to fetching the complete state information. > > It may be a good diea to differentiate the re-SUBSCRIBE > triggered by > different scenarios. > a) natural re-SUBSCRIBE request, which extends the SUBSCRIBE > duration. In this > case it is *not *necessary to fetch the complete state > information > > b) re-SUBSCRIBE triggered because of lost NOTIFY request > (ref sec > 5.3.2. > VERSION number in received NOTIFY is increased by greater > than ONE). > In this case subscriber wants to fetch the complete state > information. > > If we don't differentiate these two cases, then natural > re-SUBSCRIBE > request > unnecessarily fetch the complete state information, which > may not be > necessary / expected. > But uses higher network bandwidth to fetch the complete state > information. > ------------------------------__----------------------- > 5.4.7. Notifier generation of NOTIFY requests > > CurrentText: > This section may optionally describe the behavior used to > process the > subsequent response. > > Comment: > In this section 5.4.7, the above statement is not clear, what is > really meant to be. > > ------------------------------__----------------------- > 5.4.13. Use of URIs to Retrieve State > > CurrentText: > > ReplacementText: > In this context, I feel Use of "URLs" is more appropriate > than "URIs". > ------------------------------__----------------------- > > > Thanks, > Nataraju A.B. > E-ID : nataraju.ab@gmail.com > > / > nataraju.sip@gmail.com > __> > > +91-98455-95744 > > > > -- > Thanks, > Nataraju A.B. > > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > > _________________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/__listinfo/sipcore > > > > > > -- > Thanks, > Nataraju A.B. > From dworley@avaya.com Tue Apr 24 12:46:17 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0714B21E8024 for ; Tue, 24 Apr 2012 12:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.35 X-Spam-Level: X-Spam-Status: No, score=-103.35 tagged_above=-999 required=5 tests=[AWL=0.249, 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 VPTAcLyTWc9n for ; Tue, 24 Apr 2012 12:46:16 -0700 (PDT) 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 EE0C621E8013 for ; Tue, 24 Apr 2012 12:46:15 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EABoCl0/GmAcF/2dsb2JhbABEsXmBB4IJAQEBAQIBEihPAgEIDSkQMiUBAQQBGhqHaAWdHp1BkA9jBJwQiiiDBYE4Bg X-IronPort-AV: E=Sophos;i="4.75,476,1330923600"; d="scan'208";a="303446690" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Apr 2012 15:46:05 -0400 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Apr 2012 15:42:36 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Tue, 24 Apr 2012 15:45:05 -0400 From: "Worley, Dale R (Dale)" To: Shida Schubert , "sipcore@ietf.org" Date: Tue, 24 Apr 2012 15:44:41 -0400 Thread-Topic: New diff for rfc4244bis Thread-Index: Ac0eHM2W8bDjon80S8GvgVl19aHGGwENeMzf Message-ID: References: <5DFA254E-EF1F-4B16-868C-8E241C9EDA6D@ntt-at.com> In-Reply-To: <5DFA254E-EF1F-4B16-868C-8E241C9EDA6D@ntt-at.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] New diff for rfc4244bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2012 19:46:17 -0000 Trying to get all the issues cleaned up... Comments relative to draft-ietf-sipcore-rfc4244bis-08-04-ss.txt: Of course, "Comments on draft-ietf-sipcore-rfc4244bis-07 - substantival questions" remains to be discussed. In 10.2 is the sentence "That allows Tel-URIs to be handled correctly, i.e., not receiving a Reason header." But I wrote that sentence as a comment on the text I was providing, I don't think it helps the draft itself! It probably got copied into the draft by mistake. > > NOTE: In my comments on sections 1-5, I was unaware of the (somewhat > > new) use of "0" to indicate a gap, so I incorrectly referred to > > "positive integer" instead of "nonnegative integer". > > > > NOTE: Should we add somewhere prominent toward the beginning: > > > > The hi-entries in the History-Info header field are always given in > > the preorder of their logical tree structure, which is the > > lexicographic ordering of their hi-indexes. > > > > This makes it clear that the ordering is always the same and avoids > > specifying the ordering in multiple places (as if it was somehow a > > special feature of certain steps of processing). >=20 > I thought the description of hi-index was sufficient but if you don't > think so, we can add this. Where do you recommend we add this? > In the Introduction?? I might be having some sort of conceptual confusion here. My understanding is that the hi-entries are intrinsically organized into a tree by their hi-indexes, and as a consequence, whenever they are written as one or more History-Info headers, the hi-entries are in tree preorder by their hi-indexes. So the first question is whether everybody agrees with my understanding. Within that understanding, there are various places in processing where any implementation will have to go to the effort of correctly ordering the hi-entries. The proper understanding of that effort is not "sort the hi-entries because that is what you do at this point" but rather "sort the hi-entries because that is what you do at any point where you express them as History-Info". So there should be a statement of this global principle (contstraint, invariant) somewhere. It might be that it should be expressed in section 10.3, which seems to be the location for all the general or global principles for hi-entries. > > 6. Missing entity: If the request clearly has a gap in the hi-entry > > (e.g. by evaluating via header to the existing request history to > > see if it traversed a domain which doesn't exist in History-Info > > header field.), the entity adding an hi-entry MUST add an index a > > digit of "0" to the current index prior to adding appropriate > > index for the action to be taken. If the index of the last hi- > > entry in the request received was 1.1.2 and there was a missing > > hi-entry and the request was being forwarded to the next hop, the > > resulting index will be 1.1.2.0.1. > > > > This rule doesn't really belong here. Properly, it describes an > > additional condition that triggers the adding of an hi-entry described > > in section 9.1. >=20 > Section 9.1 already describes the condition as to when it > adds hi-entry. >=20 > " If the Request-URI of the incoming request does not match the hi- > targeted-to-uri in the last hi-entry (i.e., the previous SIP entity > that sent the request did not include a History-Info header field), > the SIP entity MUST add a hi-entry to end of the cache, on behalf of > the previous SIP entity" >=20 > Above is strictly talking about condition when "0" is to be used for > index. >=20 > The fact that last hi-entry and R-URI doesn't match is a rule for > adding an hi-entry there is no additional rule for adding an > hi-entry on behalf of the previous hop. Are you saying that these two processes are not essentially the same? If so, I have some misunderstanding as to what the difference is. Can you clarify what the difference between the two is? Dale From shida@ntt-at.com Tue Apr 24 22:26:56 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF2B21F8665 for ; Tue, 24 Apr 2012 22:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Gxd2qPRD4ChJ for ; Tue, 24 Apr 2012 22:26:55 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 683F121F8659 for ; Tue, 24 Apr 2012 22:26:55 -0700 (PDT) Received: from [119.242.40.242] (port=56645 helo=[192.168.1.19]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SMukf-0000vq-Pj; Wed, 25 Apr 2012 00:26:54 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Wed, 25 Apr 2012 14:26:51 +0900 Content-Transfer-Encoding: 7bit Message-Id: <55E8FB66-F52A-490F-82D5-774B7F613B08@ntt-at.com> References: <5DFA254E-EF1F-4B16-868C-8E241C9EDA6D@ntt-at.com> To: "Worley, Dale R (Dale)" X-Mailer: Apple Mail (2.1257) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: fl1-119-242-40-242.tky.mesh.ad.jp ([192.168.1.19]) [119.242.40.242]:56645 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org" Subject: Re: [sipcore] New diff for rfc4244bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 05:26:56 -0000 Dale; My comments inline.. On Apr 25, 2012, at 4:44 AM, Worley, Dale R (Dale) wrote: > Trying to get all the issues cleaned up... > > Comments relative to draft-ietf-sipcore-rfc4244bis-08-04-ss.txt: > > Of course, "Comments on draft-ietf-sipcore-rfc4244bis-07 - > substantival questions" remains to be discussed. > > In 10.2 is the sentence "That allows Tel-URIs to be handled correctly, > i.e., not receiving a Reason header." But I wrote that sentence as a > comment on the text I was providing, I don't think it helps the draft > itself! It probably got copied into the draft by mistake. Will remove it.. Thanks. > >>> NOTE: In my comments on sections 1-5, I was unaware of the (somewhat >>> new) use of "0" to indicate a gap, so I incorrectly referred to >>> "positive integer" instead of "nonnegative integer". >>> >>> NOTE: Should we add somewhere prominent toward the beginning: >>> >>> The hi-entries in the History-Info header field are always given in >>> the preorder of their logical tree structure, which is the >>> lexicographic ordering of their hi-indexes. >>> >>> This makes it clear that the ordering is always the same and avoids >>> specifying the ordering in multiple places (as if it was somehow a >>> special feature of certain steps of processing). >> >> I thought the description of hi-index was sufficient but if you don't >> think so, we can add this. Where do you recommend we add this? >> In the Introduction?? > > I might be having some sort of conceptual confusion here. My > understanding is that the hi-entries are intrinsically organized into > a tree by their hi-indexes, and as a consequence, whenever they are > written as one or more History-Info headers, the hi-entries are in > tree preorder by their hi-indexes. Correct. > > So the first question is whether everybody agrees with my > understanding. Yes. > > Within that understanding, there are various places in processing > where any implementation will have to go to the effort of correctly > ordering the hi-entries. The proper understanding of that effort is > not "sort the hi-entries because that is what you do at this point" > but rather "sort the hi-entries because that is what you do at any > point where you express them as History-Info". So there should be a > statement of this global principle (contstraint, invariant) > somewhere. It might be that it should be expressed in section 10.3, > which seems to be the location for all the general or global > principles for hi-entries. I am still having a difficult time understanding what type of description you are desiring in section 10.3. I agree that if we are to add something that it will be in section 10.3, but I am still unclear what you want to see added. Are you referring to mentioning the potential gap(s) (restriction) ? > >>> 6. Missing entity: If the request clearly has a gap in the hi-entry >>> (e.g. by evaluating via header to the existing request history to >>> see if it traversed a domain which doesn't exist in History-Info >>> header field.), the entity adding an hi-entry MUST add an index a >>> digit of "0" to the current index prior to adding appropriate >>> index for the action to be taken. If the index of the last hi- >>> entry in the request received was 1.1.2 and there was a missing >>> hi-entry and the request was being forwarded to the next hop, the >>> resulting index will be 1.1.2.0.1. >>> >>> This rule doesn't really belong here. Properly, it describes an >>> additional condition that triggers the adding of an hi-entry described >>> in section 9.1. >> >> Section 9.1 already describes the condition as to when it >> adds hi-entry. >> >> " If the Request-URI of the incoming request does not match the hi- >> targeted-to-uri in the last hi-entry (i.e., the previous SIP entity >> that sent the request did not include a History-Info header field), >> the SIP entity MUST add a hi-entry to end of the cache, on behalf of >> the previous SIP entity" >> >> Above is strictly talking about condition when "0" is to be used for >> index. >> >> The fact that last hi-entry and R-URI doesn't match is a rule for >> adding an hi-entry there is no additional rule for adding an >> hi-entry on behalf of the previous hop. > > Are you saying that these two processes are not essentially the same? > If so, I have some misunderstanding as to what the difference is. Can > you clarify what the difference between the two is? I will comment on this in the other e-mail you sent out. Anyway, I agree that the behavior described in the (e.g. ...) can be moved or copied to section 9.1. Regards Shida > > Dale From shida@ntt-at.com Tue Apr 24 22:48:58 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531EB21F86F8 for ; Tue, 24 Apr 2012 22:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 SPivaF0oSOjZ for ; Tue, 24 Apr 2012 22:48:57 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 9E09621F86F6 for ; Tue, 24 Apr 2012 22:48:57 -0700 (PDT) Received: from [119.242.40.242] (port=62617 helo=[192.168.1.19]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SMv60-0002Td-2n; Wed, 25 Apr 2012 00:48:56 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Wed, 25 Apr 2012 14:48:54 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: , <34EB8104-E380-4E35-B3FA-08F8C80CD60F@ntt-at.com> To: "Worley, Dale R (Dale)" X-Mailer: Apple Mail (2.1257) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: fl1-119-242-40-242.tky.mesh.ad.jp ([192.168.1.19]) [119.242.40.242]:62617 X-Source-Auth: shida@agnada.com X-Email-Count: 3 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-07 - sections 10.1 and 11-end X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 05:48:58 -0000 Hi Dale; Many thanks for your feedbacks. My comments inline. On Apr 25, 2012, at 2:57 AM, Worley, Dale R (Dale) wrote: >> From: Shida Schubert [shida@ntt-at.com] >>=20 >> On Apr 20, 2012, at 11:33 AM, Worley, Dale R (Dale) wrote: >>=20 >>> Correction of my comments on 10.3: I proposed removing all of item = 6: >>>=20 >>> 6. Missing entity: If the request clearly has a gap in the = hi-entry >>> (e.g. by evaluating via header to the existing request history = to >>> see if it traversed a domain which doesn't exist in = History-Info >>> header field.), the entity adding an hi-entry MUST add an index = a >>> digit of "0" to the current index prior to adding appropriate >>> index for the action to be taken. If the index of the last hi- >>> entry in the request received was 1.1.2 and there was a missing >>> hi-entry and the request was being forwarded to the next hop, = the >>> resulting index will be 1.1.2.0.1. >>>=20 >>> But I should have restricted it to removing the "condition", namely >>> "(e.g. by evaluating via header to the existing request history to = see >>> if it traversed a domain which doesn't exist in History-Info header >>> field.)" >>=20 >> Okay, that is more clear but I still see no harm in leaving it in = 10.3. >>=20 >> The text could reside in 9.2 but I personally think it provides more = uses >> by having it in 10.3. >=20 > Let me reconstitute what I should have said, and then let's see if we > still disagree: >=20 > In 9.1, "Receiving a Request" (not 9.2 as I said above), is: >=20 > If the Request-URI of the incoming request does not match the hi- > targeted-to-uri in the last hi-entry (i.e., the previous SIP entity > that sent the request did not include a History-Info header field), > the SIP entity MUST add a hi-entry to end of the cache, on behalf of > the previous SIP entity, as follows: >=20 > The condition in section 10.3 item 6 (as shown above) is: >=20 > If the request clearly has a gap in the hi-entry > (e.g. by evaluating via header to the existing request history = to > see if it traversed a domain which doesn't exist in History-Info > header field.),=20 >=20 > I think this condition should be added to the condition in 9.1 as an > alternative situation in which the procedures of 9.1 should be > performed. I think we agree that we *intend* the procedures of 9.1 to > be applied in the conditions described in item 6, but I am emphasizing > that 9.1 is the "procedural" text that specifies when in processing > these procedures are done, and 9.1 should list *all* the conditions > that trigger it. I agree.=20 >=20 > Now that I read 10.3 again, I see that 10.3 is not procedural, but > rather gives in one place all the rules for constructing hi-indexes of > new hi-entries. And from that point of view, item 6 is proper as > written. I might suggest that item 6 should refer to 9.1 as 9.1 is > the the implementation of the rules in item 6, but I see that no other > item in 10.3 refers to "procedural" sections; all the references are > in the reverse direction. >=20 > So I stand by my recommended change to section 9.1, but 10.3 does not > need to be changed. Let me try to update 9.1 in a less messy way than > my last attempt: >=20 > The SIP entity MUST detect whether the request clearly has a gap in > the hi-entries, mandatorily by testing if the Request-URI of the > incoming request does not match the hi-targeted-to-uri in the last > hi-entry, and optionally by other tests, e.g. by comparing the Via > header to the existing request history to see if it traversed a > domain which doesn't exist in History-Info header field. If a gap > is detected, the SIP entity MUST add a hi-entry to end of the > cache, on behalf of the previous SIP entity, as follows: This looks good.=20 Although may be simply removing the condition in 10.3=20 (evaluating via etc.) alone may be sufficient.=20 Comparing via header is probably unnecessary as receiving a=20 request with hi-entry which doesn't match the R-URI is enough=20 to detect a gap. =20 >=20 > The original text referred to by the following remarks is: > | Gaps are also possible in the case of > | parallel forking if there is an outstanding request at the time = the > | SIP entity sends a response as described in Section 9.4, in which > | case the gap will not be visible as the branch responsible for the > | gap wasn't on the path of the request received. >=20 >>> A gap (missing branch) due to an outstanding request can be revealed >>> in both requests and responses. The final part of the sentence I >>> can't understand. I wonder if there was a further sentence which = was >>> damaged and joined to this previous sentence. >>=20 >> We were just trying to describe how there could be an index missing >> not a "0" but a branch can start from 2 instead of 1 due to parallel = forking. >=20 > One problem is that "gap" is being used in two senses throughout this > draft. One sense is "a branch of parallel forking that is not > recorded in this History-Info header, but is revealed by > non-sequential numbering of the children of an entry". Another sense > is "an ancester of this request did not add an hi-entry". The referenced text refers to the gap in the sense that "a branch of=20 parallel forking that is not recorded"=20 >=20 > Another is the phrase "gap will not be visible" -- the *gap* is > visible, I think you mean "the hi-entries whose absence constitute the > gap are not present". The gap in this sense (parallel forking) may not be visible if you=20 are received a request from the first branch.=20 Let's say it forked at the third hop and you were the fourth hop the=20 hi-indexes would look like. 1.1.1.1 =20 Now if you were on the second fork it would look like: 1.1.2.1 without=20= the 1.1.1 entry, so then you know that forking likely happened and=20 gap is visible.=20 >=20 > I've tried to revise that sentence but I don't grasp exactly what > situation you are describing. It seems to be some case of the general > rule that branches of the overall hi-entry tree can be missing at any > point, due to the timings of requests and responses in the propagation > of the request. I hope above comments clarify this.=20 Regards Shida =20 >=20 > Dale From christer.holmberg@ericsson.com Wed Apr 25 02:06:28 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A33021F8684 for ; Wed, 25 Apr 2012 02:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.256 X-Spam-Level: X-Spam-Status: No, score=-5.256 tagged_above=-999 required=5 tests=[AWL=-0.819, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] 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 PlKG1aEvDrMK for ; Wed, 25 Apr 2012 02:06:26 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 416ED21F8655 for ; Wed, 25 Apr 2012 02:06:26 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-5d-4f97be918342 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 13.15.25560.19EB79F4; Wed, 25 Apr 2012 11:06:25 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 25 Apr 2012 11:06:25 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Date: Wed, 25 Apr 2012 11:06:24 +0200 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01 Thread-Index: Ac0iNMjugE4+XjTDSoStwhDW3FMajwAbgVpg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C441F09A8@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C42DF52F5@ESESSCMS0356.eemea.ericsson.se> <4F96D072.5010102@alum.mit.edu> In-Reply-To: <4F96D072.5010102@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 09:06:28 -0000 SGkgUGF1bCwNCg0KPiBNdWNoIG9mIHRoZSBzeW50YXggKEFCTkYgLSBzZWN0aW9uIDQuMi4yKSBp cyBhIHJlcGxpY2Egb2Ygd2hhdCBpcyBpbiBSRkMzODQwLiBJTU8gdGhpcyByZWxhdGlvbnNoaXAg c2hvdWxkIGJlIGFja25vd2xlZGdlZC4gTXkgcHJlZmVyZW5jZSB3b3VsZCBiZSB0byBmb3JtYWxs eSByZWZlcmVuY2UgdGhlIGFibmYgZGVmaW5pdGlvbnMgZnJvbSAzODQwIGFuZCB1c2UgdGhlIHNh bWUgbmFtZXMgZm9yIHRoZW0uDQo+DQo+IEUuZy4NCj4NCj4gICBmZWF0dXJlLWNhcCAgICAgICA9 ICBbIisiXSBmY2FwLW5hbWUgW0VRVUFMIExEUVVPVCAoZmNhcC12YWx1ZS1saXN0DQo+ICAgICAg ICAgICAgICAgICAgICAgICAgIC8gZmNhcC1zdHJpbmctdmFsdWUgKSBSRFFVT1RdDQo+ICAgIGZj YXAtbmFtZSAgICAgICAgID0gIGZ0YWctbmFtZQ0KPiAgICBmY2FwLXZhbHVlLWxpc3QgICA9ICB0 YWctdmFsdWUtbGlzdA0KPiAgICBmY2FwLXN0cmluZy12YWx1ZSA9ICBzdHJpbmctdmFsdWUNCj4g ICAgOzsgZnRhZy1uYW1lLCB0YWctdmFsdWUtbGlzdCwgc3RyaW5nLXZhbHVlIGRlZmluZWQgaW4g UkZDMzg0MA0KDQpJIGNhbiBkbyB0aGF0Lg0KDQpJIHdhcyBhY3R1YWxseSBhbHJlYWR5IHBsYW5u aW5nIHRvIGRvIHRoYXQsIGJ1dCBJIHRob3VnaHQgdGhhdCBwZW9wbGUgd291bGQgbm90IHdhbnQg dG8gcmVmZXJlbmNlIHRoZSBSRkMzODQwIEFCTkYgOikNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KDQo+IEFsc28sIEkgYW0gaW5jbGluZWQgdG8gbWFrZSB0aGUgIisiIG1hbmRhdG9yeSwg ZXZlbiB0aG91Z2ggaXQgcmVhbGx5IHNlcnZlcyBubyBwdXJwb3NlLiBUaGUgcmVhc29uIEkgcHJv cG9zZSB0aGlzIGlzIHRvIG1pbmltaXplIGNvbmZ1c2lvbiB3aXRoIHRoZSB1c2FnZSBydWxlcyBp biAzODQwLiBJbiAzODQwIHRoZSAiKyIgaXMgbWFuZGF0b3J5IGV4Y2VwdCBmb3IgdGhlICJncmFu ZGZhdGhlcmVkIiB0YWdzLiBBbmQgd2UgaGF2ZSBoYWQNCj4gdHJvdWJsZSBnZXR0aW5nIHBlb3Bs ZSB0byBmb2xsb3cgdGhhdC4gSWYgd2UgbWFrZSBpdCBvcHRpb25hbCBoZXJlIGl0IHdpbGwgZnVy dGhlciBjb25mdXNlIHRoaW5ncy4NCj4NCj4gT1RPSCwgdGhlIHJlYXNvbiBmb3IgdGhlICsgaXMg c28gdGhhdCBmZWF0dXJlIHRhZ3MgY2FuIGJlIGRpc3Rpbmd1aXNoZWQgZnJvbSBvdGhlciBjb250 YWN0IHBhcmFtZXRlcnMgdGhhdCBhcmUgbm90IGZlYXR1cmUgdGFncy4gVGhhdCBuZWVkIGRvZXNu J3QgYXBwbHkgaGVyZSwgd2hpY2ggaXMgd2h5IHRoZSAiKyIgaXMgbG9naWNhbGx5IHVubmVjZXNz YXJ5LiBBbiBhbHRlcm5hdGl2ZSB3b3VsZCBiZSB0byAqbmV2ZXIqIHVzZSB0aGUgIisiDQo+IGhl cmUuIEJ1dCBJJ20gaW5jbGluZWQgdG8gcmVxdWlyZSB0aGUgIisiIGJlY2F1c2UgdGhlcmUgbWF5 IGJlIHNvbWUgdGFncyBkZWZpbmVkIGZvciB1c2UgYXMgYm90aCBmZWF0dXJlIHRhZ3MgYW5kIHBy b3h5IGZlYXR1cmVzLCBhbmQgdGhlbiBJJ2QgcmF0aGVyIG5vdCB1c2UgdGhlICIrIiBpbiBwbGFj ZSBhbmQgbm90IGluIHRoZSBvdGhlci4NCg0KSSBjYW4gbWFrZSBpdCBtYW5kYXRvcnkgZm9yIGZl YXR1cmUtY2FwcywgYW5kIGUuZy4gYWRkIGEgbm90ZSB3aGljaCBwb2ludHMgb3V0IHRoZSBkaWZm ZXJlbmNlIGJldHdlZW4gZmVhdHVyZS10YWdzLg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQoNCj4gSSBhbHNvIGZpbmQgaXQgc29tZSB3aGF0IGNvbmZ1c2luZyB0aGF0IHBhcnQgb2YgdGhl IHN5bnRheCBpcyBpbiB0aGlzIHNlY3Rpb24gd2hpbGUgbW9yZSBvZiBpdCBpcyBpbiBzZWN0aW9u IDUuNC4gSSdkIHByZWZlciB0byBzZWUgdGhlc2UgY29uc29saWRhdGVkIGludG8gYSBzaW5nbGUg c3ludGF4IHNlY3Rpb24uDQoNCkkgdGhpbmsgdGhlIEZlYXR1cmUtQ2FwcyBoZWFkZXIgZmllbGQg c3ludGF4LCBhbmQgdGhlIGZlYXR1cmUtY2FwcyBzeW50YXgsIHNoYWxsIGJlIHNlcGFyYXRlZCwg YnV0IEkgY2FuIHB1dCB0aGVtIGluIHRoZSBzYW1lIHNlY3Rpb24uDQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0NCg0KDQo+IFJlIFJlZ2lzdHJhdGlvbiBUcmVlczoNCj4NCj4gVGhlcmUgaXMg bm8gbWVudGlvbiBvZiBhbiBJRVRGIHRyZWUsIGFuYWxvZ291cyB0byB0aGF0IGRlZmluZWQgaW4g MjUwNiBmb3IgZmVhdHVyZSB0YWdzLiBHaXZlbiB0aGUgaGlzdG9yeSwgYW5kIGEgZGVzaXJlIHRv IHByb3ZpZGUgYSBzaW1pbGFyIHN0cnVjdHVyZSwgSSBhZ3JlZSBpdCBtYWtlcyBzZW5zZSB0aGF0 IHdlIGFyZW4ndCBwbGFubmluZyBvbiBkZWZpbmluZyBhbnl0aGluZyBvZiB0aGF0IHNvcnQuIEJ1 dCBJIHRoaW5rIGl0IGlzIGNvbmZ1c2luZw0KPiB0byBhbnlvbmUgd2hvIGhhcyBsb29rZWQgYXQg MjUwNiB0aGF0IHRoZXJlIGlzIG5vIG1lbnRpb24gb2YgbmFtZXMgdGhhdCBoYXZlIG9ubHkgb25l IGZhY2V0Lg0KPg0KPiBTbywgSSB0aGluayBpdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGV4cGxpY2l0 bHkgc3RhdGUgdGhhdCBuYW1lcyBjb25zaXN0aW5nIG9mIG9ubHkgYSBzaW5nbGUgZmFjZXQsIGFz IHdlbGwgYXMgbmFtZXMgd2l0aCBpbml0aWFsIGZhY2V0cyBvdGhlciB0aGFuICJnIiBhbmQgInNp cCIgYXJlIG91dCBvZiBzY29wZSBmb3IgdGhpcyBkcmFmdC4gSSdtIHVuZGVjaWRlZCBpZiBpdCB3 b3VsZCBiZSBnb29kIHRvIGRlZmluZSBhbiBJRVRGIHRyZWUgd2l0aG91dCBhbnkNCj4gY29udGVu dCwgb3IgaWYgaXQgd291bGQgYmUgYmV0dGVyIG5vdCB0byBkZWZpbmUgaXQuDQoNCkkgYWN0dWFs bHkgaGFkIHNvbWUgdGV4dCBhYm91dCB0aGF0LCBzYXlpbmcgdGhhdCB0aGUgcmVhc29uIHdlIG9u bHkgZGVmaW5lICJnIiBhbmQgInNpcCIgaXMgIHRob3NlIGFyZSB0aGUgb25seSBvbmVzIHVzZWQg Zm9yIFNJUCByZWxhdGVkIGZlYXR1cmUtdGFncyB0b2RheSAoYW5kLCBjb21wYXJlZCB0byBmZWF0 dXJlLXRhZ3MsIHRoZSBmZWF0dXJlLWNhcHMgbWVjaGFuaXNtIGlzIG9ubHkgZGVmaW5lZCBmb3Ig U0lQKS4NCg0KRm9yIHNvbWUgcmVhc29uIHRoYXQgdGV4dCBkaWRuJ3QgZ2V0IGludG8gdGhlIC0w MSBkcmFmdCwgYnV0IEkgd2lsbCBhZGQgaXQgdG8gdGhlIG5leHQgdmVyc2lvbi4NCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo+IFRoZSBzdGF0ZW1lbnRzOg0KPg0KPiAgICBUaGUgdHJl ZSBkZWZpbml0aW9ucyBhcmUgYmFzZWQgb24gdGhlIGdsb2JhbCB0cmVlIGFuZCBzaXAgdHJlZQ0K PiAgICBkZWZpbmVkIGZvciBtZWRpYSBmZWF0dXJlIHRhZ3MsIGluIFJGQyAyNTA2IFtSRkMyNTA2 XSBhbmQgUkZDIDM4NDENCj4gICAgW1JGQzM4NDFdLg0KPiBhbmQNCj4gICAgVGhlIFNJUCBmZWF0 dXJlIGNhcCBnbG9iYWwgdHJlZSBpcyBiYXNlZCBvbiB0aGUgbWVkaWEgZmVhdHVyZSB0YWcNCj4g ICAgZ2xvYmFsIHRyZWUgZGVmaW5lZCBpbiBSRkMgMjUwNiBbUkZDMjUwNl0uDQo+IGFuZA0KPiAg ICBUaGUgU0lQIGZlYXR1cmUgY2FwIHNpcCB0cmVlIGlzIGJhc2VkIG9uIHRoZSBtZWRpYSBmZWF0 dXJlIHRhZyBzaXANCj4gICAgdHJlZSBkZWZpbmVkIGluIFJGQyAzODQwIFtSRkMzODQwXS4NCj4N Cj4gc2VlbSBhIGxpdHRsZSBjb25mdXNpbmcgdG8gbWUsIGJlY2F1c2UgaXRzIG5vdCBjbGVhciB3 aGF0ICJiYXNlZCBvbiINCj4gbWVhbnMuIEkgc3VnZ2VzdCBjaGFuZ2luZyB0aGlzIHRvICJzaW1p bGFyIHRvIi4NCg0KT2suDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KPiBBcyBmYXIg YXMgZGVmaW5pbmcgbmV3IHRyZWVzLCB0aGUgY3VycmVudCB0ZXh0IGlzOg0KPg0KPiAgICBBZGRp dGlvbmFsIGZlYXR1cmUgY2FwcyB0cmVlcyBjYW4gYmUgY3JlYXRlZCBieSBJQU5BLCBmb2xsb3dp bmcgdGhlDQo+ICAgIHNhbWUgcnVsZXMgYW5kIHByb2NlZHVyZXMgYXMgZGVmaW5lZCBmb3IgbWVk aWEgZmVhdHVyZSB0YWdzIGluDQo+ICAgIHNlY3Rpb24gMy4xLjQgb2YgUkZDIDI1MDYgW1JGQzI1 MDZdLg0KPg0KPiBUaGlzIGluIGVmZmVjdCBtYWtlcyBhIG5vcm1hdGl2ZSBkZXBlbmRlbmN5IGJl dHdlZW4gdGhpcyBkb2N1bWVudCBhbmQgUkZDMjUwNi4gSSB0aGluayBpdCB3b3VsZCBiZSBiZXR0 ZXIgdG8gc2V2ZXIgdGhlIGZvcm1hbCB0aWUuIEluc3RlYWQsIHRoaXMgY2FuIGJlIGFjY29tcGxp c2hlZCBieSBhZGRpbmcgc29tZXRoaW5nIHNpbWlsYXIgdG8gc2VjdGlvbiAzLjEuNCBvZiAyNTA2 Lg0KDQpPay4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo+IFJlZ2FyZGluZyB0aGUg SUFOQSBSZWdpc3RyYXRpb24gVGVtcGxhdGU6DQo+DQo+ICAgIHwgVGhlIHJlZmVyZW5jZSBNVVNU IGNvbnRhaW4gdGhlIGluZm9ybWF0aW9uIGxpc3RlZCBpbg0KPiAgICB8IHNlY3Rpb24gWFggb2Yg WFhYWCAoSUFOQTogUmVwbGFjZSBYWFhYIHdpdGggYXNzaWduZWQNCj4gICAgfCBSRkMgbnVtYmVy IG9mIHRoaXMgc3BlY2lmaWNhdGlvbg0KPg0KPiBJIHRoaW5rIHRoaXMgc2hvdWxkIHNheToNCj4N Cj4gICAgfCBUaGUgcmVmZXJlbmNlZCBzcGVjaWZpY2F0aW9uIE1VU1QgY29udGFpbiB0aGUgaW5m b3JtYXRpb24gbGlzdGVkDQo+ICAgIHwgaW4gc2VjdGlvbiBYWCBvZiBYWFhYIChJQU5BOiBSZXBs YWNlIFhYWFggd2l0aCBhc3NpZ25lZA0KPiAgICB8IFJGQyBudW1iZXIgb2YgdGhpcyBzcGVjaWZp Y2F0aW9uDQoNCkNvcnJlY3QuDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KPiBJbiBh ZGRpdGlvbiB0aGVyZSBtYXkgYmUgc29tZSByZWR1bmRhbmN5IGJldHdlZW4gdGhlICJTSVAgZmVh dHVyZSBjYXAgc3BlY2lmaWNhdGlvbiByZWZlcmVuY2UiIGFuZCB0aGUgIlJlbGF0ZWQgc3RhbmRh cmRzIG9yIGRvY3VtZW50cyIuIERvIHlvdSB0aGluayB3ZSBuZWVkIGJvdGg/DQoNClByb2JhYmx5 IG5vdCwgYmVjYXVzZSBpdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRoZSBTSVAgZmVhdHVyZSBjYXAg c3BlY2lmaWNhdGlvbiBjb250YWlucyByZWZlcmVuY2VzIHRvIHVzYWdlcyBhbmQgZXhhbXBsZXMu DQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KPiBBcmUgdGhlcmUgb3RoZXIgdGhpbmdz IGluIHRoZXJlIHRoYXQgYXJlIGp1c3QgYmFnZ2FnZSBiZWluZyBjYXJyaWVkIG92ZXIgZnJvbSAy NTA2IHRoYXQgYXJlIG5vdCB1c2VmdWwgdG8gdXM/IChFLmcuIGRvIHdlIG5lZWQgdGhlIHB1Ymxp Y2F0aW9uDQo+IGRlbGF5PykNCg0KSSBkb24ndCBrbm93LiBVbmxlc3Mgc29tZW9uZSB3YW50cyBp dCwgSSBjYW4gcmVtb3ZlIGl0Lg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCj4gU2Vj dGlvbiA0LjUuMiBzYXlzOg0KPg0KPiAgICBUaGUgU0lQIGZlYXR1cmUgY2FwIHNwZWNpZmljYXRp b24gTVVTVCBjb250YWluIGFuIG92ZXJhbGwgZGVzY3JpcHRpb24NCj4gICAgb2YgdGhlIFNJUCBm ZWF0dXJlIGNhcDogaG93IGl0IGlzIHVzZWQgdG8gaW5kaWNhdGUgc3VwcG9ydCBvZiBhDQo+ICAg IGZlYXR1cmUsIGEgZGVzY3JpcHRpb24gb2YgdGhlIGZlYXR1cmUgYXNzb2NpYXRlZCB3aXRoIHRo ZSBTSVAgZmVhdHVyZQ0KPiAgICBjYXAsIGFuZCBhIGRlc2NyaXB0aW9uIG9mIGFueSBhZGRpdGlv bmFsIGluZm9ybWF0aW9uIChjb252ZXllZCB1c2luZw0KPiAgICBvbmUgb3IgbW9yZSBTSVAgZmVh dHVyZSBjYXAgdmFsdWVzKSB0aGF0IGNhbiBiZSBjb252ZXllZCB0b2dldGhlcg0KPiAgICB3aXRo IHRoZSBTSVAgZmVhdHVyZSBjYXAuDQoNCldoYXQgdGhpcyBkb2Vzbid0IHRhbGsgYWJvdXQgaXMg aG93IHRoZSBmZWF0dXJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgZmVhdHVyZSBjYXAgaXMgZXhlcmNp c2VkL2ludm9rZWQuIFNvIEkgd291bGQgc3VnZ2VzdCBzb21ldGhpbmcgbGlrZToNCg0KPiAgICBU aGUgU0lQIGZlYXR1cmUgY2FwIHNwZWNpZmljYXRpb24gTVVTVCBjb250YWluIGFuIG92ZXJhbGwg ZGVzY3JpcHRpb24NCj4gICAgb2YgdGhlIFNJUCBmZWF0dXJlIGNhcDogaG93IGl0IGlzIHVzZWQg dG8gaW5kaWNhdGUgc3VwcG9ydCBvZiBhDQo+ICAgIGZlYXR1cmUsIGEgZGVzY3JpcHRpb24gb2Yg dGhlIGZlYXR1cmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBTSVAgZmVhdHVyZQ0KPiAgICBjYXAsIGEg ZGVzY3JpcHRpb24gb2YgYW55IGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gKGNvbnZleWVkIHVzaW5n DQo+ICAgIG9uZSBvciBtb3JlIFNJUCBmZWF0dXJlIGNhcCB2YWx1ZXMpIHRoYXQgY2FuIGJlIGNv bnZleWVkIHRvZ2V0aGVyDQo+ICAgIHdpdGggdGhlIFNJUCBmZWF0dXJlIGNhcCwgYW5kIGEgZGVz Y3JpcHRpb24gb2YgaG93IHRoZSBhc3NvY2lhdGVkDQo+ICAgIGZlYXR1cmUgbWF5IGJlIGV4ZXJj aXNlZC9pbnZva2VkLg0KDQpMb29rcyBnb29kLg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K DQoNCj4gU2VjdGlvbiA0LjUuMzoNCj4NCj4gVGhlIHJ1bGVzIGRlc2NyaWJlZCBoZXJlIHNvdW5k IHRvIG1lIGxpa2Ugb25lcyBzdWl0YWJsZSBmb3IgdGhlIG5hbWUgb2YgYSBwYXJhbWV0ZXIgKGUu Zy4gYSBwYXJhbWV0ZXIgYm91bmQgdG8gYW4gZXZlbnQgb3IgYSBtaW1lIHR5cGUsIG9yIHRvIGEg c2lwIGhlYWRlci4pIEl0IGRvZXNuJ3Qgc2VlbSB2ZXJ5IGFwcHJvcHJpYXRlIHdoZW4gZGlzY3Vz c2luZyB0aGUgcmVwcmVzZW50YXRpb24gb2YgYSAqdmFsdWUqIG9mIGENCj4gcGFyYW1ldGVyL2Zl YXR1cmUuIEZvciBleGFtcGxlLCB3aGVuIHZhbHVlcyBhcmUgZW51bWVyYXRpb25zLCB3ZSBtaWdo dCBmaW5kIHRoaW5ncyBsaWtlICJ0cnVlIiBhbmQgImZhbHNlIiBvciAieWVzIiBhbmQgIm5vIi4g RXZlbiBpZiB0aGV5IGFyZSAicmVkIiAvICJncmVlbiIgLyAiYmx1ZSIsIHRoZSBzYW1lIHZhbHVl cyBtaWdodCB3ZWxsIG1ha2Ugc2Vuc2UgYXNzb2NpYXRlZCB3aXRoIG90aGVyIGZlYXR1cmVzLiBD YW4geW91DQo+IHBsZWFzZSB0aGluayB0aGlzIHRocm91Z2ggZnVydGhlcj8gSXQgbWF5IGluZGVl ZCBtYWtlIHNlbnNlIHRvIHNheSAqc29tZXRoaW5nKiBoZXJlLCBidXQgSSBpbWFnaW5lIHNvbWV0 aGluZyB3ZWFrZXIuDQoNCk1heWJlIHdlIHNob3VsZCBzaW1wbHkgc2F5IHRoYXQgdGhlIHZhbHVl IGlzIG9ubHkgYXBwbGljYWJsZSBmb3IgdGhlIGZlYXR1cmUtY2FwIGZvciB3aGljaCBpdCBoYXMg YmVlbiBkZWZpbmVkLiBGb3Igb3RoZXIgZmVhdHVyZS1jYXBzLCB0aGUgdmFsdWUgaGFzIHRvIGJl IGRlZmluZWQgZXhwbGljaXRseSBmb3IgdGhvc2UsIGV2ZW4gaWYgdGhlIG5hbWUgYW5kL29yIHNl bWFudGljcyB3b3VsZCBiZSB0aGUgc2FtZS4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K DQo+U2VjdGlvbiA0LjUuNSBzYXlzOg0KPg0KPiAgICBOT1RFOiBTb21ldGltZXMgYSBTSVAgZmVh dHVyZSBjYXAgZGVzaWduZXIgbWlnaHQgY2hvb3NlIHRvIG5vdCByZXZlYWwNCj4gICAgdGhlIGlt cGxlbWVudGF0aW9uIGRldGFpbHMgb2YgYSBTSVAgZmVhdHVyZSBjYXAuICBIb3dldmVyLCBpbiBv cmRlcg0KPiAgICB0byBhbGxvdyBtdWx0aXBsZSBpbXBsZW1lbnRhdGlvbnMgdG8gc3VwcG9ydCB0 aGUgU0lQIGZlYXR1cmUgY2FwLA0KPiAgICBkZXNpZ25lcnMgYXJlIHN0cm9uZ2x5IGVuY291cmFn ZWQgdG8gcHJvdmlkZSB0aGUgaW1wbGVtZW50YXRpb24NCj4gICAgZGV0YWlscy4NCj4NCj4gSSBy ZWNvZ25pemUgdGhhdCBwZW9wbGUgbWF5IG5vdCB3YW50IHRvIHB1Ymxpc2ggaW1wbGVtZW50YXRp b24gZGV0YWlscy4NCj4gQnV0IHRoYXQgaXMgZGlmZmVyZW50IGZyb20gcHJvdmlkaW5nIGVub3Vn aCBzcGVjaWZpY2F0aW9uIHRvIGFsbCBpbmRlcGVuZGVudCBidXQgaW50ZXJvcGVyYWJsZSBpbXBs ZW1lbnRhdGlvbnMgdG8gYmUgZGV2ZWxvcGVkLg0KPg0KPiBUaGUgYW1vdW50IHRoYXQgbmVlZHMg dG8gYmUgZGlzY2xvc2VkIG1pZ2h0IHZhcnkgYmFzZWQgb24gd2hpY2ggcmVnaXN0cmF0aW9uIHRy ZWUgaXMgdXNlZC4gSSB3b3VsZCBleHBlY3QgdGhhdCB0aGUgc2lwIHRyZWUgd291bGQgcmVxdWly ZSBzdWZmaWNpZW50IHNwZWMgdG8gc3VwcG9ydCBhbiBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlv bi4gSWYgeW91IHdlcmUgaW5zdGl0dXRpbmcgYSBVUkkgdHJlZSB0aGVuIEkgY2FuIHNlZSB0aGF0 IGl0ID4gbWlnaHQgYmUgY29uc2lkZXJlZCBlbnRpcmVseSBwcm9wcmlldGFyeSBhbmQgaGVuY2Ug bWlnaHQgbm90IHJlcXVpcmUgdGhpcy4gKEJ1dCB5b3UgaGF2ZSBvbWl0dGVkIHRoZSBVUkkgdHJl ZSwgd2hpY2ggdGh1cyBzaWRlc3RlcHMgdGhpcyBpc3N1ZS4pIElTVE0gdGhhdCB0aGUgZ2xvYmFs IHRyZWUgc2hvdWxkIHN0aWxsIHJlcXVpcmUgYSBkZWZpbml0aW9uIG9mIGhvdyB0byBjcmVhdGUg YW4gaW50ZXJvcGVyYWJsZSBpbXBsZW1lbnRhdGlvbi4gPiBUaGUgZGlmZmVyZW5jZSBiZXR3ZWVu IHRoZSBnbG9iYWwgdHJlZSBhbmQgdGhlIHNpcCB0cmVlIGluIHRoaXMgcmVnYXJkIG1pZ2h0IGJl IHRoYXQgaW4gdGhlIGNhc2Ugb2YgdGhlIHNpcCB0cmVlIHRoZSByZWZlcmVuY2VkIHNwZWNpZmlj YXRpb24gbXVzdCBiZSBhbiBJRVRGIGRvY3VtZW50LCB3aGlsZSBpbiB0aGUgY2FzZSBvZiB0aGUg Z2xvYmFsIHRyZWUgaXQgY291bGQgYmUgc29tZSBleHRlcm5hbCBkb2N1bWVudC4NCg0KSSB0b29r IHRoZSB0ZXh0IGZyb20gdGhlIEluZm8tUGFja2FnZSBSRkMuDQoNClRvIGJlIGhvbmVzdCwgaG93 ZXZlciwgSSBoYXZlIHNvbWUgdHJvdWJsZXMgdG8gdW5kZXJzdGFuZCB3aGF0IGlzIHJlYWxseSBt ZWFudCBieSAiaW1wbGVtZW50YXRpb24gZGV0YWlscyIuIEFzIGRlc2NyaWJlZCBpbiBzZWN0aW9u IDQuNS4yLCB5b3UgRE8gaGF2ZSB0byBkZXNjcmliZSBob3cgdGhlIGZlYXR1cmUtY2FwIGlzIHVz ZWQgZXRjLCBzbyBJIGFtIG5vdCBzdXJlIHdoYXQgZXh0cmEgImltcGxlbWVudGF0aW9uIGRldGFp bHMiIHdvdWxkIGJyaW5nLg0KDQpTbywgbWF5YmUgd2UgY291bGQgc2ltcGx5IHJlbW92ZSBzZWN0 aW9uIDQuNS41Pw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCj4gU2VjdGlvbiA1LjIu MSBzYXlzOg0KPg0KPiAgICBXaGVuIHRoZSBVQSByZWNlaXZlcyB0aGUgU0lQIHJlcXVlc3Qgb3Ig dGhlIHJlc3BvbnNlLCB0aGUgU0lQIGZlYXR1cmUNCj4gICAgY2FwcyBpbiB0aGUgdG9wbW9zdCBG ZWF0dXJlLUNhcHMgaGVhZGVyIGZpZWxkIHdpbGwgcmVwcmVzZW50IHRoZQ0KPiAgICBzdXBwb3J0 ZWQgZmVhdHVyZXMgImNsb3Nlc3QiIHRvIHRoZSBVQS4NCj4NCj4gSSBkb24ndCB0aGluayB0aGlz IGlzIHF1aXRlIHdoYXQgeW91IG1lYW4uIEkgdGhpbmsgeW91IG1lYW46DQo+DQo+ICAgIFdoZW4g dGhlIFVBIHJlY2VpdmVzIHRoZSBTSVAgcmVxdWVzdCBvciB0aGUgcmVzcG9uc2UsIHRoZSBTSVAg ZmVhdHVyZQ0KPiAgICBjYXBzIGluIHRoZSBmaXJzdCBmYy12YWx1ZSB3aWxsIHJlcHJlc2VudCB0 aGUgc3VwcG9ydGVkIGZlYXR1cmVzDQo+ICAgICJjbG9zZXN0IiB0byB0aGUgVUEuDQoNClllcy4N Cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQpTZWN0aW9uIDUuMi4yIHNheXM6DQoNCj4g ICAgVGhlIHByb2NlZHVyZXMgaW4gdGhpcyBzZWN0aW9uIGFwcGxpZXMgdG8gVUFzIHRoYXQgYXJl IHBhcnQgb2YNCj4gICAgQjJCVUFzLCBidXQgd2hlcmUgdGhlIFVSSSBpbiB0aGUgQ29udGFjdCBo ZWFkZXIgZmllbGQgZG9lcyBub3QNCj4gICByZXByZXNlbnQgdGhlIFVBLCBiZWNhdXNlIHRoZSBC MkJVQSBpcyBhbHNvIGFjdGluZyBhcyBhIHByb3h5IGFuZA0KPiAgICBpbnNlcnRzIGl0cyBVUkkg ZS5nLiBpbiBhIFJlY29yZC1Sb3V0ZSBoZWFkZXIgZmllbGQuDQo+DQo+IElNTyB0aGlzIGNvdmVy cyBzb21lIGNvbnRyb3ZlcnNpYWwgZ3JvdW5kLCBidXQgcHJvYmFibHkgb25seSBpbiB3YXlzIHRo YXQgbWFueSB3aWxsIGNvbnNpZGVyIHBlZGFudGljLiBXZSBhcmUgaW4gcXVpdGUgdW5kZXIgc3Bl Y2lmaWVkIHRlcnJpdG9yeSB3aGVuIHdlIHRhbGsgYWJvdXQgQjJCVUFzIHRoYXQgYWN0IGFzIFBy b3hpZXMuIERvZXMgdGhpcyBtZWFuIHRoYXQgaXQgd2FzIGEgcHJveHkgd2hlbiB0aGUgZGlhbG9n IHdhcw0KPiBlc3RhYmxpc2hlZCwgYnV0IGxhdGVyIHRoZSBzYW1lIGVudGl0eSByZWRlY2xhcmVz IGl0c2VsZiBhcyBhIFVBIGZvciBzb21lIHN1YnNlcXVlbnQgdHJhbnNhY3Rpb24gd2l0aGluIHRo ZSBkaWFsb2c/IE9yIHdhcyBpdCBhY3RpbmcgYXMgYSBVQSB3aGVuIHRoZSBkaWFsb2cgd2FzIGVz dGFibGlzaGVkLCBidXQgc3RpbGwgY2hvc2UgdG8gdXNlIGEgQ29udGFjdCBVUkkgdGhhdCBkb2Vz bid0IGlkZW50aWZ5IGl0c2VsZj8NCj4NCj4gQXMgbXVjaCBhcyBJIHdvdWxkIGxpa2UgdG8gaGF2 ZSBhbiBleHRlbmRlZCBkaXNjdXNzaW9uIG9uIHRoaXMsIGRvaW5nIHNvIHdoaWxlIHdvcmtpbmcg b24gdGhpcyBkcmFmdCBpcyBwcm9iYWJseSBjb3VudGVycHJvZHVjdGl2ZS4gUGVyaGFwcyB5b3Ug Y2FuIGh1bW9yIG15IHNlbnNpdGl2aXRpZXMgYW5kIGp1c3QgY2hhbmdlIHRoaXMgdG86DQo+DQo+ ICAgIFRoZSBwcm9jZWR1cmVzIGluIHRoaXMgc2VjdGlvbiBhcHBsaWVzIHRvIFVBcyB0aGF0IGFy ZSBwYXJ0IG9mDQo+ICAgIEIyQlVBcyB0aGF0IGFyZSByZWZlcmVuY2VkIGluIHRoZSBtZXNzYWdl IGJ5IGEgUmVjb3JkLVJvdXRlIGhlYWRlcg0KPiAgICBmaWVsZCByYXRoZXIgdGhhbiBieSB0aGUg Q29udGFjdCBVUkkuDQoNCkxvb2tzIGdvb2QuDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN Cg0KPiBTZWN0aW9uIDUuMi4yIHRoZW4gc2F5czoNCj4NCj4gICAgV2hlbiBhIFVBIHNlbmRzIGEg U0lQIHJlcXVlc3QsIGlmIHRoZSBVQSB3YW50cyB0byBpbmRpY2F0ZSBzdXBwb3J0IG9mDQo+ICAg IGZlYXR1cmVzIHRvd2FyZHMgaXRzIGRvd25zdHJlYW0gU0lQIGVudGl0aWVzLCBpdCBhZGRzIGEg RmVhdHVyZS1DYXBzDQo+ICAgIGhlYWRlciBmaWVsZCB0byB0aGUgcmVxdWVzdCwgdG9nZXRoZXIg d2l0aCBvbmUgb3IgbW9yZSBGZWF0dXJlIENhcHMNCj4gICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBz dXBwb3J0ZWQgZmVhdHVyZXMsIGJlZm9yZSBpdCBmb3J3YXJkcyB0aGUNCj4gICByZXF1ZXN0Lg0K Pg0KPiBUaGlzIHNheXMgImFkZHMiIGJ1dCBkb2Vzbid0IHNheSB3aGV0aGVyIHRvIGJlIGJlZ2lu bmluZyBvciB0aGUgZW5kLg0KPiBBbHNvLCBpdCBpc24ndCBzdHJpY3RseSBuZWNlc3NhcnkgdG8g YWRkIGFub3RoZXIgaGVhZGVyIGZpZWxkLCBpdCBjYW4gYWRkIHRvIGFuIGV4aXN0aW5nIGhlYWRl ciBmaWVsZC4gU28gSSBzdWdnZXN0Og0KPg0KPiAgICBXaGVuIGEgVUEgc2VuZHMgYSBTSVAgcmVx dWVzdCwgaWYgdGhlIFVBIHdhbnRzIHRvIGluZGljYXRlIHN1cHBvcnQgb2YNCj4gICAgZmVhdHVy ZXMgdG93YXJkcyBpdHMgZG93bnN0cmVhbSBTSVAgZW50aXRpZXMsIGJlZm9yZSBpdCBmb3J3YXJk cyB0aGUNCj4gICByZXF1ZXN0IGl0IGFkZHMgYSBmYy12YWx1ZSB3aXRoIHRoZSBzdXBwb3J0ZWQg ZmVhdHVyZXMgdG8NCj4gICAgdGhlIHJlcXVlc3QsIGFmdGVyIGFueSBvdGhlcnMgdGhhdCBtYXkg YmUgcHJlc2VudC4gVGhpcyBtYXkgYmUgYWRkZWQNCj4gICAgdG8gdGhlIGxhc3QgZXhpc3Rpbmcg RmVhdHVyZS1DYXBzIGhlYWRlciBmaWVsZCBvciBhcyBhIG5ldw0KPiAgICBGZWF0dXJlLUNhcHMg aGVhZGVyIGZpZWxkIGFmdGVyIGFueSBvdGhlcnMuDQo+DQo+IFNvbWV0aGluZyBzaW1pbGFyIGFw cGxpZXMgYSBjb3VwbGUgbW9yZSB0aW1lcyBpbiB0aGlzIHNlY3Rpb24gYW5kIGluIHNlY3Rpb25z IDUuMi4zIGFuZCA1LjIuNC4gSSByZWFsaXplIHRoaXMgaXMgYSBiaXQgY3VtYmVyc29tZSAtIHBl cmhhcHMgdGhlcmUgaXMgYSBtb3JlIHN0cmFpZ2h0Zm9yd2FyZCB3YXkgdG8gc2F5IGl0Lg0KDQpJ IHdpbGwgZG91YmxlIGNoZWNrLCBidXQgSSBUSElOSyB3ZSBub3JtYWxseSBvbmx5IHRhbGsgYWJv dXQgYWRkaW5nIGEgdmFsdWUgdG8gYW4gZXhpc3RpbmcgaGVhZGVyIGZpZWxkLiBUaGUgQUJORiBy dWxlcyB0aGVuIHNob3dzIHdoZXRoZXIgbXVsdGlwbGUgaW5zdGFuY2VzIG9mIHRoZSBoZWFkZXIg ZmllbGQgaXMgYWxsb3dlZC4NCg0KV2UganVzdCBuZWVkIHRvIGJlIHN1cmUgdGhhdCB0aGUgdGV4 dCBpcyBjbGVhciBvbiB3aGljaCBmZWF0dXJlcyBhcmUgImNsb3Nlc3QiIHRvIHRoZSBVQSwgbm8g bWF0dGVyIHdoZXRoZXIgdGhleSBhcmUgaW5kaWNhdGVkIGluIGEgc2luZ2xlIGhlYWRlciBmaWVs ZCwgb3IgaW4gbXVsdGlwbGUgaGVhZGVyIGZpZWxkcy4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0NCg0KDQo+IFNlY3Rpb24gNS4zLjMgc2F5czoNCj4NCj4gICAgSWYgYSBTSVAgZmVhdHVyZSBj YXAgaXMgaW5zZXJ0ZWQgaW4gYSBGZWF0dXJlLUNhcHMgaGVhZGVyIGZpZWxkIG9mIGENCj4gICAg U0lQIFJFR0lTVEVSIHJlcXVlc3QsIG9yIHdpdGhpbiBhIHJlc3BvbnNlIG9mIHN1Y2ggcmVxdWVz dCwgaXQNCj4gICAgaW5kaWNhdGVzIHRvIHRoZSByZWNlaXZlcnMgb2YgdGhlIHJlcXVlc3QgKG9y IHJlc3BvbnNlKSB0aGF0IHRoZQ0KPiAgICBmZWF0dXJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgU0lQ IGZlYXR1cmUgY2FwIGlzIHN1cHBvcnRlZCBmb3IgdGhlDQo+ICAgIGR1cmF0aW9uIG9mIHRoZSBy ZWdpc3RyYXRpb24sIGFuZCBmb3IgYWxsIFNJUCB0cmFuc2FjdGlvbnMgYXNzb2NpYXRlZA0KPiAg ICB3aXRoIHRoZSByZWdpc3RyYXRpb24sIHVudGlsIHRoZSByZWdpc3RyYXRpb24gaXMgcmUtZnJl c2hlZCBvcg0KPiAgICB0ZXJtaW5hdGVkLg0KPg0KPiBUaGVyZSBhcmUgc29tZSBjYXNlcyB3ZSBu ZWVkIHRvIGRpc2N1c3MgaGVyZS4gV2hlbiBhIFVBIHNlbmRzIGEgUkVHSVNURVIgcmVxdWVzdCwg aXQgY291bGQgaGF2ZSBubyBjb250YWN0cywgb25lIGNvbnRhY3QsIG9yIHNldmVyYWwuIFdoYXQg ZG8gdGhlIGZlYXR1cmUgY2FwcyBtZWFuIGluIHRoZXNlIGNhc2VzPw0KPg0KPiAtIGlmIHRoZXJl IGFyZSBubyBjb250YWN0cyBpbiB0aGUgcmVnaXN0ZXIsIGFyZSBmZWF0dXJlLWNhcHMgaXJyZWxl dmFudD8NCj4gLSBpZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25lIGNvbnRhY3QgaW4gdGhlIHJlZ2lz dGVyLCBkbyB0aGUgZmVhdHVyZS1jYXBzDQo+ICAgYXBwbHkgdG8gYWxsIG9mIHRoZW0/DQo+DQo+ IFRoZW4gdGhlIHJlc3BvbnNlIHNob3VsZCBjb250YWluIGFsbCB0aGUgcmVnaXN0ZXJlZCBjb250 YWN0cywgbm90IGp1c3QgdGhvc2UgbWVudGlvbmVkIGluIHRoZSByZXF1ZXN0LiBTbyBkbyB0aGUg ZmVhdHVyZSBjYXBzIG1lbnRpb25lZCBpbiB0aGUgcmVwbHkgYXBwbHkgdW50aWwgdGhlIGxhc3Qg b2YgdGhvc2UgY29udGFjdHMgZXhwaXJlPyBPciBzaG91bGQgdGhlIHJlcXVlc3RlciBhc3N1bWUg dGhleSBvbmx5IGFwcGx5IHVudGlsICppdHMqDQo+IGNvbnRhY3RzIGV4cGlyZT8NCj4NCj4gICAg VW5sZXNzIGEgU0lQIGZlYXR1cmUgY2FwIGlzIGluc2VydGVkIGluIGEgRmVhdHVyZS1DYXBzIGhl YWRlciBmaWVsZA0KPiAgICBvciBhIHJlLXJlZ2lzdHJhdGlvbiwgb3Igd2l0aGluIGEgcmVzcG9u c2Ugb2Ygc3VjaCByZXF1ZXN0LCBpdA0KPiAgICBpbmRpY2F0ZXMgdG8gdGhlIHJlY2VpdmVycyBv ZiB0aGUgcmVxdWVzdCAob3IgcmVzcG9uc2UpIHRoYXQgdGhlDQo+ICAgIGZlYXR1cmUgaXMgbm8g bG9uZyBzdXBwb3J0ZWQgZm9yIHRoZSByZWdpc3RyYXRpb24uDQo+DQo+IFN1cHBvc2UgYSBVQSBy ZWdpc3RlcnMgd2l0aCBhIGNvbnRhY3QgYW5kIHNvbWUgZmVhdHVyZSBjYXBzLiBUaGVuIGxhdGVy IGl0IHNlbmRzIGEgcmVnaXN0ZXIgcG9sbCAocmVnaXN0ZXIgd2l0aCBubyBjb250YWN0cykuIENh biBJIGFzc3VtZSB0aGF0IHRoaXMgd2lsbCBub3QgYWZmZWN0IHRoZSBmZWF0dXJlIGNhcHMgYXNz b2NpYXRlZCB3aXRoIHRoZSByZWdpc3RlcmVkIGNvbnRhY3Q/DQoNCkl0J3MgdXAgdG8gdGhlIGVu dGl0aWVzIHRoYXQgcHJldmlvdXNseSBpbnNlcnRlZCB0aGUgZmVhdHVyZS1jYXBzIHRvIGRlY2lk ZSB3aGV0aGVyIHRoZXkgd2lsbCBjb250aW51ZSB0byBpbmRpY2F0ZSBzdXBwb3J0IHdoZW4gdGhl eSByZWNlaXZlIGEgcmUtcmVnaXN0cmF0aW9uIHJlcXVlc3QvcmVzcG9uc2UgLSBubyBtYXR0ZXIg d2hldGhlciBpdCdzIGEgcG9sbCwgYWRkaXRpb24gb2YgY29udGFjdHMgZXRjLg0KDQpQZXJzb25h bGx5IEkgc2VlIG5vIHJlYXNvbiB3aHkgdGhleSBzaG91bGQgKm5vdCogaW5zZXJ0IHRoZSBzYW1l IGZlYXR1cmUtY2FwcyBpbiBhIHB1cmUgcG9sbCByZXF1ZXN0L3Jlc3BvbnNlLCBidXQgd2Ugc2hv dWxkIGFsbG93IGZvciBjYXNlcyB3aGVyZSB0aGUgZmVhdHVyZSBpcyBubyBsb25nZXIgc3VwcG9y dGVkIHdoZW4gdGhlIHBvbGwgcmVxdWVzdC9yZXNwb25zZSBpcyByZWNlaXZlZC4NCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KDQo+IERvIHRoZSBlbmhhbmNlZCByZWdpc3RyYXIgYmVoYXZp b3JzIGluIG91dGJvdW5kIHJlcXVpcmUgYW55IHNwZWNpYWwgdHJlYXRtZW50IHJlbGF0aXZlIHRv IGZlYXR1cmUgY2Fwcz8NCg0KTm8sIEkgZG9uJ3QgdGhpbmsgc28uDQoNCkhvd2V2ZXIsIEkgZ3Vl c3Mgd2UgY291bGQgYWRkIGEgY2xhcmlmaWNhdGlvbiBub3RlIHNheWluZyB0aGF0IGZlYXR1cmVz IGFyZSBvbmx5IHN1cHBvcnRlZCBmb3IgdGhlIHNwZWNpZmljIG91dGJvdW5kIHJlZ2lzdHJhdGlv biBmbG93IHdoZXJlIHN1cHBvcnQgaGFzIGJlZW4gZXhwbGljaXRseSBpbmRpY2F0ZWQuDQoNCg0K PiBTZWN0aW9uIDY6DQo+DQo+IFRoZXJlIGFyZSBhIGxvdCBvZiBtaXNzaW5nIElBTkEgY29uc2lk ZXJhdGlvbnMgLSB0aGUgZXN0YWJsaXNobWVudCBvZiB0aGUgbmV3IHRyZWVzIGFzIGRlZmluZWQg aW4gNC4zIGFuZCA0LjQuDQoNCkkgdXNlZCBSRkMgMjUwNiBhcyBiYXNlLCB3aGVyZSB0aGUgdHJl ZXMgYXJlIGRlZmluZWQgbW9yZSBvciBsZXNzIGluIHRoZSBzYW1lIHdheSBhcyBpbiB0aGUgZHJh ZnQuIEJ1dCwgSSBndWVzcyBpdCdzIGJldHRlciB0byBkbyBpdCBpbiB0aGUgc2FtZSB3YXkgYXMg aW4gUkZDIDM4NDAuDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KPiBUaGF0IGlzIGFs bCBmb3Igbm93Lg0KDQpUaGFuayBZb3UgdmVyeSBtdWNoIQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQo= From pravindran@sonusnet.com Wed Apr 25 02:18:17 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEE521F8775 for ; Wed, 25 Apr 2012 02:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.493 X-Spam-Level: X-Spam-Status: No, score=-6.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 qC6r95bDoZ1g for ; Wed, 25 Apr 2012 02:18:16 -0700 (PDT) Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id D7EDA21F876E for ; Wed, 25 Apr 2012 02:18:15 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKT5fBV2/7gJsDgPjiiMeB2mwl+ynZzLff@postini.com; Wed, 25 Apr 2012 02:18:15 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 25 Apr 2012 05:18:15 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Wed, 25 Apr 2012 14:48:02 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Websocket is a new transport or new URI? Thread-Index: AQHNIDOCuN/qLU9tjk656lTA6m0G85am5VEAgAD8KaCAAD8sgIABv2aw//+u7wCAAHdUgIABOZfA Date: Wed, 25 Apr 2012 09:18:02 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E239306@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> <4F970097.5020002@alum.mit.edu> In-Reply-To: <4F970097.5020002@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 09:18:17 -0000 Paul, As you mentioned, it is possible to use SIPS URI even for the new=20 transport like websocket with some normative changes and those=20 changes needs to be figured out. As a result, SIPS URI is not going to be mistake in the new transport as well. My intent of this mail is to make consistent mechanism for all SIP=20 application layer transport protocol over TCP. "Websocket=20 over TCP" is same like "TLS over TCP" and has some of similar=20 behavior like 1) Hop by hop behavior.=20 2) Running on top of TCP transport 3) No port management This mechanism has other added advantages like even if extension=20 of websocket for new transport like SCTP will not impact SIP mechanism. In case SIPWS URI looks like sipws:alice@example.com;transport=3Dtcp As a theory, if websocket is extended for SCTP transport and then=20 SIPWS URI will looks like sipws:alice@example.com;transport=3Dsctp Please note that TLS over SCTP exists already as RFC3436.=20 As we discussed, there was debate in RFC 3261 whether TLS is a transport=20 or URI in SIP, it was decided as URI mechanism, TLS transport is=20 deprecated and also there is no plan to change this stance as per=20 this mail thread. So IMO, it is more appropriate to define new URI=20 scheme like SIPWS rather than defining websocket as a transport.=20 Please let me know your opinion on the same. Thanks Partha >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >Behalf Of Paul Kyzivat >Sent: Wednesday, April 25, 2012 1:06 AM >To: sipcore@ietf.org >Subject: Re: [sipcore] Websocket is a new transport or new URI? > >On 4/24/12 8:28 AM, Kevin P. Fleming wrote: >> On 04/24/2012 07:04 AM, Ravindran, Parthasarathi wrote: >>> Paul, >>> >>> Thanks for clarify your view. In case your view is correct, then >>> Usage of SIPS Scheme (Sec 9.2) of draft-ibc-sipcore-sip-websocket-02 >>> draft should forbid the usage of SIPS URI for websocket transport >>> (WSS, WS) as SIPS URI is mistake for TLS, the mistake *MUST NOT* be >>> repeated and the draft text has to be updated as >>> >>> "SIPS URI MUST NOT be used for WS, WSS transport as the end-to-end >>> security is not assured" >> >> How did you reach this conclusion? In this context, >> WebSocket-over-TLS-over-TCP is no different than TLS-over-TCP; usage >> of WebSocket on the first hop does not change the ability of the path >> to be end-to-end secure at all. > >It may be that WebSocket-over-TLS-over-TCP is *conceptually* no >different than TLS-over-TCP. But its far from clear that this is so with >the current wording of 3261 and 5630. I expect that a careful review of >these needs to be done and some normative updates done. I went through >3261 looking at discussions of sips for things that might be problematic >or at least need some consideration. Here are some of them: > > > Any > implementation that supports TLS MUST support the SIPS URI scheme. > The To header field allows for a display name. > > If the request arrived over TLS, and the Request-URI contained a >SIPS > URI, the "secure" flag is set to TRUE. > > If the request was sent over TLS, and the Request-URI contained a > SIPS URI, the "secure" flag is set to TRUE. > > Furthermore, if the Request-URI contains a SIPS URI, TLS MUST > be used to communicate with that proxy. > > For a SIPS URI, the transport parameter MUST > indicate a reliable transport. > > When a request is sent to a SIPS URI, the > protocol still indicates "SIP", and the transport protocol is TLS. > > When used as the Request-URI of a > request, the SIPS scheme signifies that each hop over which the > request is forwarded, until the request reaches the SIP entity > responsible for the domain portion of the Request-URI, must be > secured with TLS > > The use of SIPS in particular entails that mutual TLS authentication > SHOULD be employed, as SHOULD the ciphersuite > TLS_RSA_WITH_AES_128_CBC_SHA. > > Note that in the SIPS URI scheme, transport is independent of TLS, > and thus "sips:alice@atlanta.com;transport=3Dtcp" and > "sips:alice@atlanta.com;transport=3Dsctp" are both valid (although > note that UDP is not a valid transport for SIPS). The use of > "transport=3Dtls" has consequently been deprecated, partly because > it was specific to a single hop of the request. This is a change > since RFC 2543. > > All SIP elements that support TLS MUST also support the SIPS URI > scheme. > >I'm not suggesting exactly *what* needs to be done - just that it needs >to be figured out. > >As a consequence, I would expect that it would be possible to use sips >with websockets, but no requirement to do so. Whether its helpful, or >wise, to use sips is a separate question. > > Thanks, > Paul >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From saul@ag-projects.com Wed Apr 25 03:36:37 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE79421F85D0 for ; Wed, 25 Apr 2012 03:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] 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 t3e-dUvGk6+G for ; Wed, 25 Apr 2012 03:36:37 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC4721F85AE for ; Wed, 25 Apr 2012 03:36:36 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id B237DB01C1; Wed, 25 Apr 2012 12:36:34 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id E0A79B019C; Wed, 25 Apr 2012 12:36:33 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E239306@inba-mail01.sonusnet.com> Date: Wed, 25 Apr 2012 12:36:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5522E7CB-78FF-4582-8E39-0E8E43301650@ag-projects.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> <4F970097.5020002@alum.mit.edu> <387F9047F55E8C4285 0AD6B3A7A03C6C0E239306@inba-mail01.sonusnet.com> To: "Ravindran, Parthasarathi" X-Mailer: Apple Mail (2.1084) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 10:36:37 -0000 Partha, On Apr 25, 2012, at 11:18 AM, Ravindran, Parthasarathi wrote: > Paul, >=20 > As you mentioned, it is possible to use SIPS URI even for the new=20 > transport like websocket with some normative changes and those=20 > changes needs to be figured out. As a result, SIPS URI is not going > to be mistake in the new transport as well. >=20 > My intent of this mail is to make consistent mechanism for all SIP=20 > application layer transport protocol over TCP. "Websocket=20 > over TCP" is same like "TLS over TCP" and has some of similar=20 > behavior like >=20 Can you elaborate on what consistent mechanism is needed and why? > 1) Hop by hop behavior.=20 > 2) Running on top of TCP transport > 3) No port management >=20 > This mechanism has other added advantages like even if extension=20 > of websocket for new transport like SCTP will not impact SIP = mechanism. > In case SIPWS URI looks like >=20 > sipws:alice@example.com;transport=3Dtcp >=20 So, what does this mean, that we need to reach alice through a WebSocket = connection? Should alice be able to register using such contact? > As a theory, if websocket is extended for SCTP transport and then=20 > SIPWS URI will looks like >=20 > sipws:alice@example.com;transport=3Dsctp >=20 > Please note that TLS over SCTP exists already as RFC3436.=20 >=20 > As we discussed, there was debate in RFC 3261 whether TLS is a = transport=20 > or URI in SIP, it was decided as URI mechanism, TLS transport is=20 > deprecated and also there is no plan to change this stance as per=20 > this mail thread. So IMO, it is more appropriate to define new URI=20 > scheme like SIPWS rather than defining websocket as a transport.=20 > Please let me know your opinion on the same. >=20 What should we do if tomorrow I send a draft specifying pseudo-TCP = transport (TCP implemented over UDP) for SIP? Yet another URI scheme? = Not to mention that all equipment out there would go nuts os most likely = just ignore URI schemes which are not 'sip' or 'sips'. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From pkyzivat@alum.mit.edu Wed Apr 25 07:55:05 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B38021F86EB for ; Wed, 25 Apr 2012 07:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 bCmDGjAa+P8Z for ; Wed, 25 Apr 2012 07:55:04 -0700 (PDT) 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 85C6021F86D6 for ; Wed, 25 Apr 2012 07:55:03 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id 2Es81j00416LCl053Ev4oR; Wed, 25 Apr 2012 14:55:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta06.westchester.pa.mail.comcast.net with comcast id 2Ev51j00E07duvL3SEv5uo; Wed, 25 Apr 2012 14:55:05 +0000 Message-ID: <4F981046.6010508@alum.mit.edu> Date: Wed, 25 Apr 2012 10:55:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> <4F970097.5020002@alum.mit.edu> <387F9047F55E8C4285 0AD6B3A7A03C6C0E239306@inba-mail01.sonusnet.com> <5522E7CB-78FF-4582-8E39-0E8E43301650@ag-projects.com> In-Reply-To: <5522E7CB-78FF-4582-8E39-0E8E43301650@ag-projects.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Ravindran, Parthasarathi" , "sipcore@ietf.org" Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 14:55:06 -0000 I agree with Saśl here. I don't really understand what it is that Partha is proposing. As I already stated, I think sips turned out to be a mistake - that it doesn't provide enough of a guarantee to be able to promise anything to an end user. But we investigated this ad nauseum and couldn't come up with anything substantially better. So I'm ok to extend the applicability of sips to other transports that can provide at least as much security as TLS over TCP provides, for those that find that to be of *some* utility. Thanks, Paul On 4/25/12 6:36 AM, Saśl Ibarra Corretgé wrote: > Partha, > > On Apr 25, 2012, at 11:18 AM, Ravindran, Parthasarathi wrote: > >> Paul, >> >> As you mentioned, it is possible to use SIPS URI even for the new >> transport like websocket with some normative changes and those >> changes needs to be figured out. As a result, SIPS URI is not going >> to be mistake in the new transport as well. >> >> My intent of this mail is to make consistent mechanism for all SIP >> application layer transport protocol over TCP. "Websocket >> over TCP" is same like "TLS over TCP" and has some of similar >> behavior like >> > > Can you elaborate on what consistent mechanism is needed and why? > >> 1) Hop by hop behavior. >> 2) Running on top of TCP transport >> 3) No port management >> >> This mechanism has other added advantages like even if extension >> of websocket for new transport like SCTP will not impact SIP mechanism. >> In case SIPWS URI looks like >> >> sipws:alice@example.com;transport=tcp >> > > So, what does this mean, that we need to reach alice through a WebSocket connection? Should alice be able to register using such contact? > >> As a theory, if websocket is extended for SCTP transport and then >> SIPWS URI will looks like >> >> sipws:alice@example.com;transport=sctp >> >> Please note that TLS over SCTP exists already as RFC3436. >> >> As we discussed, there was debate in RFC 3261 whether TLS is a transport >> or URI in SIP, it was decided as URI mechanism, TLS transport is >> deprecated and also there is no plan to change this stance as per >> this mail thread. So IMO, it is more appropriate to define new URI >> scheme like SIPWS rather than defining websocket as a transport. >> Please let me know your opinion on the same. >> > > What should we do if tomorrow I send a draft specifying pseudo-TCP transport (TCP implemented over UDP) for SIP? Yet another URI scheme? Not to mention that all equipment out there would go nuts os most likely just ignore URI schemes which are not 'sip' or 'sips'. > > > Regards, > > -- > Saśl Ibarra Corretgé > AG Projects > > > > From frankwmiller@frankwmiller.net Wed Apr 25 08:37:17 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E186621F87B0 for ; Wed, 25 Apr 2012 08:37:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJ2Bsh7tqU9J for ; Wed, 25 Apr 2012 08:37:16 -0700 (PDT) Received: from smtpauth02.mfg.siteprotect.com (smtpauth02.mfg.siteprotect.com [64.26.60.136]) by ietfa.amsl.com (Postfix) with ESMTP id 8D51421F87AE for ; Wed, 25 Apr 2012 08:37:16 -0700 (PDT) Received: from FrankWMillerPC (unknown [174.51.92.116]) (Authenticated sender: frankwmiller@frankwmiller.net) by smtpauth02.mfg.siteprotect.com (Postfix) with ESMTPA id BE85AC5F4 for ; Wed, 25 Apr 2012 10:37:15 -0500 (CDT) From: "Frank W. Miller" To: References: <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com><387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com><387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com><7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se><4F8ECB82.7070805@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com><4F9460AC.2080605@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com><4F956931.7090404@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com><4F969C7E.3070107@digium.com> <4F970097.5020002@alum.mit.edu><387F9047F55E8C42850AD6B3A7A03C6C0E239306@inba-mail01.sonusnet.com><5522E7CB-78FF-4582-8E39-0E8E43301650@ag-projects.com> <4F981046.6010508@alum.mit.edu> In-Reply-To: <4F981046.6010508@alum.mit.edu> Date: Wed, 25 Apr 2012 09:37:07 -0600 Message-ID: <3A6F8060C39240D4B9A27CFB1AA9225C@FrankWMillerPC> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 Thread-Index: Ac0i82m8+BgqW2vLR5qsZCZyoGUFqAABUVFQ X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.17609 X-CTCH-Spam: Unknown X-CTCH-RefID: str=0001.0A02020B.4F981A2B.01EE,ss=1,re=0.000,fgs=0 Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 15:37:18 -0000 Jeez, with all due respect, I've been following these hundreds of = messages that seem to be necessary to add support for Websocket as a transport. Is this really what the original developers intended when they made the statement that SIP is transport independent? Doesn't seem very = independent to me. In my mind independent to me means I switch from SOCK_DGRAM or SOCK_STREAM to SOCK_WEBSOCKET (or whatever) in my socket() call and I'm done. FM =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf Of Paul Kyzivat Sent: Wednesday, April 25, 2012 8:55 AM To: Sa=FAl Ibarra Corretg=E9 Cc: Ravindran, Parthasarathi; sipcore@ietf.org Subject: Re: [sipcore] Websocket is a new transport or new URI? I agree with Sa=FAl here. I don't really understand what it is that = Partha is proposing. As I already stated, I think sips turned out to be a mistake - that it doesn't provide enough of a guarantee to be able to promise anything to = an end user. But we investigated this ad nauseum and couldn't come up with anything substantially better. So I'm ok to extend the applicability of sips to other transports that = can provide at least as much security as TLS over TCP provides, for those = that find that to be of *some* utility. Thanks, Paul On 4/25/12 6:36 AM, Sa=FAl Ibarra Corretg=E9 wrote: > Partha, > > On Apr 25, 2012, at 11:18 AM, Ravindran, Parthasarathi wrote: > >> Paul, >> >> As you mentioned, it is possible to use SIPS URI even for the new=20 >> transport like websocket with some normative changes and those=20 >> changes needs to be figured out. As a result, SIPS URI is not going=20 >> to be mistake in the new transport as well. >> >> My intent of this mail is to make consistent mechanism for all SIP=20 >> application layer transport protocol over TCP. "Websocket over TCP"=20 >> is same like "TLS over TCP" and has some of similar behavior like >> > > Can you elaborate on what consistent mechanism is needed and why? > >> 1) Hop by hop behavior. >> 2) Running on top of TCP transport >> 3) No port management >> >> This mechanism has other added advantages like even if extension of=20 >> websocket for new transport like SCTP will not impact SIP mechanism. >> In case SIPWS URI looks like >> >> sipws:alice@example.com;transport=3Dtcp >> > > So, what does this mean, that we need to reach alice through a = WebSocket connection? Should alice be able to register using such contact? > >> As a theory, if websocket is extended for SCTP transport and then=20 >> SIPWS URI will looks like >> >> sipws:alice@example.com;transport=3Dsctp >> >> Please note that TLS over SCTP exists already as RFC3436. >> >> As we discussed, there was debate in RFC 3261 whether TLS is a=20 >> transport or URI in SIP, it was decided as URI mechanism, TLS=20 >> transport is deprecated and also there is no plan to change this=20 >> stance as per this mail thread. So IMO, it is more appropriate to=20 >> define new URI scheme like SIPWS rather than defining websocket as a transport. >> Please let me know your opinion on the same. >> > > What should we do if tomorrow I send a draft specifying pseudo-TCP transport (TCP implemented over UDP) for SIP? Yet another URI scheme? = Not to mention that all equipment out there would go nuts os most likely just ignore URI schemes which are not 'sip' or 'sips'. > > > Regards, > > -- > Sa=FAl Ibarra Corretg=E9 > AG Projects > > > > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From vkg@bell-labs.com Wed Apr 25 09:05:03 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B8B21F87D2 for ; Wed, 25 Apr 2012 09:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.666 X-Spam-Level: X-Spam-Status: No, score=-109.666 tagged_above=-999 required=5 tests=[AWL=0.933, 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 zSQp8F+pUOtP for ; Wed, 25 Apr 2012 09:05:02 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id CE3F521F87CC for ; Wed, 25 Apr 2012 09:05:01 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q3PG4tu3013041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Apr 2012 11:04:55 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q3PG4s8w023958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Apr 2012 11:04:54 -0500 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 q3PG4rJ7002263; Wed, 25 Apr 2012 11:04:53 -0500 (CDT) Message-ID: <4F9821D7.6030908@bell-labs.com> Date: Wed, 25 Apr 2012 11:09:59 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> <4F970097.5020002@alum.mit.edu> <387F9047F55E8C4285 0AD6B3A7A03C6C0E239306@inba-mail01.sonusnet.com> <5522E7CB-78FF-4582-8E39-0E8E43301650@ag-projects.com> <4F981046.6010508@alum.mit.edu> In-Reply-To: <4F981046.6010508@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: "Ravindran, Parthasarathi" , "sipcore@ietf.org" , =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:05:03 -0000 On 04/25/2012 09:55 AM, Paul Kyzivat wrote: > I agree with Saśl here. I don't really understand what it is that Partha > is proposing. > > As I already stated, I think sips turned out to be a mistake - that it > doesn't provide enough of a guarantee to be able to promise anything to > an end user. But we investigated this ad nauseum and couldn't come up > with anything substantially better. Time for institutional memory, perhaps? The long discussions (May - June 2006) on why sips failed and ideas to come up with new URI schemes to replace it and attendant problems (upcasting URIs, downcasting URIs without user consent, hop-by-hop semantics versus end-to-end, etc.) is summarized in http://www.ietf.org/mail-archive/web/sip/current/msg24047.html - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From pkyzivat@alum.mit.edu Wed Apr 25 09:21:15 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D07B21F866A for ; Wed, 25 Apr 2012 09:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.564 X-Spam-Level: X-Spam-Status: No, score=-1.564 tagged_above=-999 required=5 tests=[AWL=-0.777, BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] 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 elk1zjcRkNtY for ; Wed, 25 Apr 2012 09:21:14 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 39BE621F864B for ; Wed, 25 Apr 2012 09:21:13 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 2BtN1j0021uE5Es5BGMDxV; Wed, 25 Apr 2012 16:21:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id 2GME1j02l07duvL3cGMEl3; Wed, 25 Apr 2012 16:21:15 +0000 Message-ID: <4F982477.7010506@alum.mit.edu> Date: Wed, 25 Apr 2012 12:21:11 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C42DF52F5@ESESSCMS0356.eemea.ericsson.se> <4F96D072.5010102@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C441F09A8@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C441F09A8@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:21:15 -0000 Hi Christer, We are in agreement on many things. I have inserted further comments where I had something more to say. On 4/25/12 5:06 AM, Christer Holmberg wrote: > Hi Paul, > >> Much of the syntax (ABNF - section 4.2.2) is a replica of what is in RFC3840. IMO this relationship should be acknowledged. My preference would be to formally reference the abnf definitions from 3840 and use the same names for them. >> >> E.g. >> >> feature-cap = ["+"] fcap-name [EQUAL LDQUOT (fcap-value-list >> / fcap-string-value ) RDQUOT] >> fcap-name = ftag-name >> fcap-value-list = tag-value-list >> fcap-string-value = string-value >> ;; ftag-name, tag-value-list, string-value defined in RFC3840 > > I can do that. > > I was actually already planning to do that, but I thought that people would not want to reference the RFC3840 ABNF :) Its a judgment call. In this case I think your intent is to keep the syntax the same, and the best way to ensure that is to have the syntax defined in only one place. > --------------------- > > >> Also, I am inclined to make the "+" mandatory, even though it really serves no purpose. The reason I propose this is to minimize confusion with the usage rules in 3840. In 3840 the "+" is mandatory except for the "grandfathered" tags. And we have had >> trouble getting people to follow that. If we make it optional here it will further confuse things. >> >> OTOH, the reason for the + is so that feature tags can be distinguished from other contact parameters that are not feature tags. That need doesn't apply here, which is why the "+" is logically unnecessary. An alternative would be to *never* use the "+" >> here. But I'm inclined to require the "+" because there may be some tags defined for use as both feature tags and proxy features, and then I'd rather not use the "+" in place and not in the other. > > I can make it mandatory for feature-caps, and e.g. add a note which points out the difference between feature-tags. > > > --------------------- > > >> I also find it some what confusing that part of the syntax is in this section while more of it is in section 5.4. I'd prefer to see these consolidated into a single syntax section. > > I think the Feature-Caps header field syntax, and the feature-caps syntax, shall be separated, but I can put them in the same section. I don't see any particular reason to keep them separated, especially if the syntax is simplified by reference to 3840. But I don't have a problem with separating it into two subsections, as long as they are together in the document. > --------------------- > > >> Re Registration Trees: >> >> There is no mention of an IETF tree, analogous to that defined in 2506 for feature tags. Given the history, and a desire to provide a similar structure, I agree it makes sense that we aren't planning on defining anything of that sort. But I think it is confusing >> to anyone who has looked at 2506 that there is no mention of names that have only one facet. >> >> So, I think it would be helpful to explicitly state that names consisting of only a single facet, as well as names with initial facets other than "g" and "sip" are out of scope for this draft. I'm undecided if it would be good to define an IETF tree without any >> content, or if it would be better not to define it. > > I actually had some text about that, saying that the reason we only define "g" and "sip" is those are the only ones used for SIP related feature-tags today (and, compared to feature-tags, the feature-caps mechanism is only defined for SIP). > > For some reason that text didn't get into the -01 draft, but I will add it to the next version. > > > --------------------- > > >> The statements: >> >> The tree definitions are based on the global tree and sip tree >> defined for media feature tags, in RFC 2506 [RFC2506] and RFC 3841 >> [RFC3841]. >> and >> The SIP feature cap global tree is based on the media feature tag >> global tree defined in RFC 2506 [RFC2506]. >> and >> The SIP feature cap sip tree is based on the media feature tag sip >> tree defined in RFC 3840 [RFC3840]. >> >> seem a little confusing to me, because its not clear what "based on" >> means. I suggest changing this to "similar to". > > Ok. > > > --------------------- > > >> As far as defining new trees, the current text is: >> >> Additional feature caps trees can be created by IANA, following the >> same rules and procedures as defined for media feature tags in >> section 3.1.4 of RFC 2506 [RFC2506]. >> >> This in effect makes a normative dependency between this document and RFC2506. I think it would be better to sever the formal tie. Instead, this can be accomplished by adding something similar to section 3.1.4 of 2506. > > Ok. > > > --------------------- > > >> Regarding the IANA Registration Template: >> >> | The reference MUST contain the information listed in >> | section XX of XXXX (IANA: Replace XXXX with assigned >> | RFC number of this specification >> >> I think this should say: >> >> | The referenced specification MUST contain the information listed >> | in section XX of XXXX (IANA: Replace XXXX with assigned >> | RFC number of this specification > > Correct. > > > --------------------- > > >> In addition there may be some redundancy between the "SIP feature cap specification reference" and the "Related standards or documents". Do you think we need both? > > Probably not, because it is recommended that the SIP feature cap specification contains references to usages and examples. > > > --------------------- > > >> Are there other things in there that are just baggage being carried over from 2506 that are not useful to us? (E.g. do we need the publication >> delay?) > > I don't know. Unless someone wants it, I can remove it. Please also consider if there are any others that make no sense here and can be removed. > --------------------- > > >> Section 4.5.2 says: >> >> The SIP feature cap specification MUST contain an overall description >> of the SIP feature cap: how it is used to indicate support of a >> feature, a description of the feature associated with the SIP feature >> cap, and a description of any additional information (conveyed using >> one or more SIP feature cap values) that can be conveyed together >> with the SIP feature cap. > > What this doesn't talk about is how the feature associated with the feature cap is exercised/invoked. So I would suggest something like: > >> The SIP feature cap specification MUST contain an overall description >> of the SIP feature cap: how it is used to indicate support of a >> feature, a description of the feature associated with the SIP feature >> cap, a description of any additional information (conveyed using >> one or more SIP feature cap values) that can be conveyed together >> with the SIP feature cap, and a description of how the associated >> feature may be exercised/invoked. > > Looks good. > > > --------------------- > > >> Section 4.5.3: >> >> The rules described here sound to me like ones suitable for the name of a parameter (e.g. a parameter bound to an event or a mime type, or to a sip header.) It doesn't seem very appropriate when discussing the representation of a *value* of a >> parameter/feature. For example, when values are enumerations, we might find things like "true" and "false" or "yes" and "no". Even if they are "red" / "green" / "blue", the same values might well make sense associated with other features. Can you >> please think this through further? It may indeed make sense to say *something* here, but I imagine something weaker. > > Maybe we should simply say that the value is only applicable for the feature-cap for which it has been defined. For other feature-caps, the value has to be defined explicitly for those, even if the name and/or semantics would be the same. > > > --------------------- > > >> Section 4.5.5 says: >> >> NOTE: Sometimes a SIP feature cap designer might choose to not reveal >> the implementation details of a SIP feature cap. However, in order >> to allow multiple implementations to support the SIP feature cap, >> designers are strongly encouraged to provide the implementation >> details. >> >> I recognize that people may not want to publish implementation details. >> But that is different from providing enough specification to all independent but interoperable implementations to be developed. >> >> The amount that needs to be disclosed might vary based on which registration tree is used. I would expect that the sip tree would require sufficient spec to support an independent implementation. If you were instituting a URI tree then I can see that it> might be considered entirely proprietary and hence might not require this. (But you have omitted the URI tree, which thus sidesteps this issue.) ISTM that the global tree should still require a definition of how to create an interoperable implementation.> The difference between the global tree and the sip tree in this regard might be that in the case of the sip tree the referenced specification must be an IETF document, while in the case of the global tree it could be some external document. > > I took the text from the Info-Package RFC. > > To be honest, however, I have some troubles to understand what is really meant by "implementation details". As described in section 4.5.2, you DO have to describe how the feature-cap is used etc, so I am not sure what extra "implementation details" would bring. I was about to suggest we consult the authors of the Info-Package RFC, but then I realized that you are one of the authors. :-) So, what did you mean? In the case of Info packages the point is that you are delivering an identified package of information, and so I would think that the implementation details would include any sort of "protocol" layered on top of that data - e.g. when I send certain info to you I expect that you will send back another info with an ack/nack. IOW, whatever is needed to successfully use this. (In some cases it may be very simple - send anything syntactically valid for the package whenever you want, with receiver free to do anything or nothing with it. > So, maybe we could simply remove section 4.5.5? Lets not give up just yet, before we understand. Again, my point is to specify enough so that independent developers can create interoperable implementations. > --------------------- > > >> Section 5.2.1 says: >> >> When the UA receives the SIP request or the response, the SIP feature >> caps in the topmost Feature-Caps header field will represent the >> supported features "closest" to the UA. >> >> I don't think this is quite what you mean. I think you mean: >> >> When the UA receives the SIP request or the response, the SIP feature >> caps in the first fc-value will represent the supported features >> "closest" to the UA. > > Yes. > > > --------------------- > > > Section 5.2.2 says: > >> The procedures in this section applies to UAs that are part of >> B2BUAs, but where the URI in the Contact header field does not >> represent the UA, because the B2BUA is also acting as a proxy and >> inserts its URI e.g. in a Record-Route header field. >> >> IMO this covers some controversial ground, but probably only in ways that many will consider pedantic. We are in quite under specified territory when we talk about B2BUAs that act as Proxies. Does this mean that it was a proxy when the dialog was >> established, but later the same entity redeclares itself as a UA for some subsequent transaction within the dialog? Or was it acting as a UA when the dialog was established, but still chose to use a Contact URI that doesn't identify itself? >> >> As much as I would like to have an extended discussion on this, doing so while working on this draft is probably counterproductive. Perhaps you can humor my sensitivities and just change this to: >> >> The procedures in this section applies to UAs that are part of >> B2BUAs that are referenced in the message by a Record-Route header >> field rather than by the Contact URI. > > Looks good. > > > --------------------- > > >> Section 5.2.2 then says: >> >> When a UA sends a SIP request, if the UA wants to indicate support of >> features towards its downstream SIP entities, it adds a Feature-Caps >> header field to the request, together with one or more Feature Caps >> associated with the supported features, before it forwards the >> request. >> >> This says "adds" but doesn't say whether to be beginning or the end. >> Also, it isn't strictly necessary to add another header field, it can add to an existing header field. So I suggest: >> >> When a UA sends a SIP request, if the UA wants to indicate support of >> features towards its downstream SIP entities, before it forwards the >> request it adds a fc-value with the supported features to >> the request, after any others that may be present. This may be added >> to the last existing Feature-Caps header field or as a new >> Feature-Caps header field after any others. >> >> Something similar applies a couple more times in this section and in sections 5.2.3 and 5.2.4. I realize this is a bit cumbersome - perhaps there is a more straightforward way to say it. > > I will double check, but I THINK we normally only talk about adding a value to an existing header field. The ABNF rules then shows whether multiple instances of the header field is allowed. > > We just need to be sure that the text is clear on which features are "closest" to the UA, no matter whether they are indicated in a single header field, or in multiple header fields. Yes, I think we do usually do that, even though it is imprecise. Within reason I'm ok with you following precedent of something with similar behavior. Record-Route comes to mind. > --------------------- > > >> Section 5.3.3 says: >> >> If a SIP feature cap is inserted in a Feature-Caps header field of a >> SIP REGISTER request, or within a response of such request, it >> indicates to the receivers of the request (or response) that the >> feature associated with the SIP feature cap is supported for the >> duration of the registration, and for all SIP transactions associated >> with the registration, until the registration is re-freshed or >> terminated. >> >> There are some cases we need to discuss here. When a UA sends a REGISTER request, it could have no contacts, one contact, or several. What do the feature caps mean in these cases? >> >> - if there are no contacts in the register, are feature-caps irrelevant? >> - if there is more than one contact in the register, do the feature-caps >> apply to all of them? >> >> Then the response should contain all the registered contacts, not just those mentioned in the request. So do the feature caps mentioned in the reply apply until the last of those contacts expire? Or should the requester assume they only apply until *its* >> contacts expire? >> >> Unless a SIP feature cap is inserted in a Feature-Caps header field >> or a re-registration, or within a response of such request, it >> indicates to the receivers of the request (or response) that the >> feature is no long supported for the registration. >> >> Suppose a UA registers with a contact and some feature caps. Then later it sends a register poll (register with no contacts). Can I assume that this will not affect the feature caps associated with the registered contact? > > It's up to the entities that previously inserted the feature-caps to decide whether they will continue to indicate support when they receive a re-registration request/response - no matter whether it's a poll, addition of contacts etc. > > Personally I see no reason why they should *not* insert the same feature-caps in a pure poll request/response, but we should allow for cases where the feature is no longer supported when the poll request/response is received. I think you missed my point. Its really the same point as my question of what it means to put feature caps into a polling register. Since you want the registrar to consider the received feature caps to be stateful for the duration of the register, I want to know what that state is attached to. ISTM that it must be attached to particular contacts. Then, a polling register would presumably not update the state of any registered contact since it doesn't update any of them. On the flip side of that, if the registrar returns feature caps, what does the recipient attach that state to? The only thing it could attach it to that has a lifetime is the registration of a particular contact, since the registered contacts can expire independently. > --------------------- > > >> Do the enhanced registrar behaviors in outbound require any special treatment relative to feature caps? > > No, I don't think so. > > However, I guess we could add a clarification note saying that features are only supported for the specific outbound registration flow where support has been explicitly indicated. I'm only asking that you look at it. If nothing is needed, that is fine. The clarification sounds good if it is true. (I don't know if it is true.) >> Section 6: >> >> There are a lot of missing IANA considerations - the establishment of the new trees as defined in 4.3 and 4.4. > > I used RFC 2506 as base, where the trees are defined more or less in the same way as in the draft. But, I guess it's better to do it in the same way as in RFC 3840. Again, we are establishing a new IANA registry here. I think it unwise to couple it to the definition of a different registry in a document we don't control. (Some day 2506 may be updated, and we wouldn't want that to affect *this* registry.) In any case, IANA needs to be given explicit instructions to establish the new registry, and couple it to the template. Thanks, Paul From pkyzivat@alum.mit.edu Wed Apr 25 09:38:39 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B485A21F87BF for ; Wed, 25 Apr 2012 09:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQ1g9LV7xwA6 for ; Wed, 25 Apr 2012 09:38:38 -0700 (PDT) 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 982B121F87BA for ; Wed, 25 Apr 2012 09:38:38 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta03.westchester.pa.mail.comcast.net with comcast id 2GJi1j00C1ei1Bg53Gefbw; Wed, 25 Apr 2012 16:38:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta24.westchester.pa.mail.comcast.net with comcast id 2Geh1j00R07duvL3kGehvA; Wed, 25 Apr 2012 16:38:41 +0000 Message-ID: <4F98288C.9020405@alum.mit.edu> Date: Wed, 25 Apr 2012 12:38:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Vijay K. Gurbani" References: <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> <4F970097.5020002@alum.mit.edu> <387F9047F55E8C4285 0AD6B3A7A03C6C0E239306@inba-mail01.sonusnet.com> <5522E7CB-78FF-4582-8E39-0E8E43301650@ag-projects.com> <4F981046.6010508@alum.mit.edu> <4F9821D7.6030908@bell-labs.com> In-Reply-To: <4F9821D7.6030908@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: "Ravindran, Parthasarathi" , "sipcore@ietf.org" , =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 16:38:39 -0000 Vijay, Thanks for this reference! Its one thing to have a recollection of a discussion long ago, but something else to have the minutes of that discussion! Thanks, Paul On 4/25/12 12:09 PM, Vijay K. Gurbani wrote: > On 04/25/2012 09:55 AM, Paul Kyzivat wrote: >> I agree with Saśl here. I don't really understand what it is that Partha >> is proposing. >> >> As I already stated, I think sips turned out to be a mistake - that it >> doesn't provide enough of a guarantee to be able to promise anything to >> an end user. But we investigated this ad nauseum and couldn't come up >> with anything substantially better. > > Time for institutional memory, perhaps? The long discussions (May - > June 2006) on why sips failed and ideas to come up with new URI schemes > to replace it and attendant problems (upcasting URIs, downcasting URIs > without user consent, hop-by-hop semantics versus end-to-end, etc.) is > summarized in > http://www.ietf.org/mail-archive/web/sip/current/msg24047.html > > - vijay From ibc@aliax.net Wed Apr 25 10:25:36 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3EA21F8817 for ; Wed, 25 Apr 2012 10:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=0.049, 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 f1skHXHRb6dk for ; Wed, 25 Apr 2012 10:25:35 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5283321F880E for ; Wed, 25 Apr 2012 10:25:35 -0700 (PDT) Received: by yhkk25 with SMTP id k25so378796yhk.31 for ; Wed, 25 Apr 2012 10:25:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=oX9udNNUtH+LG3Fswo8b+E7Tisx8n82Zf28KdNMJd6w=; b=N0fY/fo6RPmF1vFL3V9t/LcWHYBXC9Q69Zn7VKr9Q5qG1agORq7y8SGWLpJIrAHeUQ BGTn/Y1nc/PZekgnZR4e7G8yfELvC+WF6K30s7Ejbyz2cA4bw9H3XSMZJFHwt7SB/z61 /Z8YT6Kgg3y4jQr060JOdvstmTvPhPrODZDbrgAaNrMTYmdO5tIzWH/4SKqWtPWrm7HN VoCSWmGUBFne7yNZN49PKXQRmQD6LKCrXcNUCrB6rxSpzmuSCN4g2yRC4VeEozflBBon pJAkNDc3rZRhPM8sXCwRz4voMsq8S8PPwFSzTvE4qO0lDj7eZAy6kKfaOEEZsVoMYUvi 319g== Received: by 10.236.176.167 with SMTP id b27mr3257423yhm.55.1335374734819; Wed, 25 Apr 2012 10:25:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.216.8 with HTTP; Wed, 25 Apr 2012 10:25:14 -0700 (PDT) In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E239306@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> <4F970097.5020002@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E239306@inba-mail01.sonusnet.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 25 Apr 2012 19:25:14 +0200 Message-ID: To: "Ravindran, Parthasarathi" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmiYH/NJwH89mphYExugRVHLwKPIkmp/YwbH3housqrW8o9GopJ9iUL/kAvja6E/jOo+XQx Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 17:25:36 -0000 Hi Partha, 2012/4/25 Ravindran, Parthasarathi : > So IMO, it is more appropriate to define new URI > scheme like SIPWS rather than defining websocket as a transport. The SIP transport defined by this draft is WebSocket, instead of TCP. WebSocket (RFC 6455) is defined to work on top of TCP but, even if a future spec defines WebSocket to run over SCTP, the SIP transport would still be "WebSocket" (or perhaps "WebSocket-SCTP" but that something in which I won't waste time now given the fact that RFC 6455 *mandates* TCP layer-3 transport and does not leave the door open for other layer-3 transports). WebSocket is, indeed, a layer on top of a network transport (layer 3) but it's designed to work as a *transport* layer since it defines a framing mechanism to send application messages and control mesages in both directions. Applications (i.e. JavaScript scripts, PHP/Java web apps) use WebSocket as a transport layer. You can find lot of cases in which a transport runs on top of other transports. For example, in the recent IETF #83 the RTCWEB WG approved (or discussed) SCTP-over-DTLS-over-ICE-over-UDP as the transport for the WebRTC Data-Channel mechanism. A "transport" does not necessarily mean "layer 3 network transport". About SIPS, the last S in SIPS stands for "secure" regardless of the undelying SIP transport used. AFAIK it does not necessarily mean "TLS". Take for example draft-jennings-sip-dtls-05 [1] which defines SIP over DTLS over UDP. The draf is expired, but anyhow, it defines a secure SIP transport which does not use TLS but DTLS (which is similar but NOT the same). The draft also allows SIPS messages through DTLS over UDP. [1] http://tools.ietf.org/html/draft-jennings-sip-dtls-05 When a SIPS message is carried on top of a secure WebSocket connection (which means SIP over WebSocket over TLS over TCP) the security level is basically the same as if it was SIP over TLS over TCP. Therefore I consider that a secure WebSocket connection fits the requirements of the SIPS mechanism, thus secure WebSocket should be considered as a secure SIP transport. About the SIPWS and SIPWSS schemas you propose, don't take me wrong but I consider that the worst possible idea. First of all because I don't agree with your rationale (I insist that, from the point of view of a SIP stack, WebSocket is the ***SIP transport***, instead of TCP). Secondly, because adding new URI schemas would just break the existing SIP world (there are still some SIP entities that don't understand SIPS schema and you are proposing two new ones?). Thanks a lot for your comments. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Wed Apr 25 13:17:38 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F6C21F88F5 for ; Wed, 25 Apr 2012 13:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.982 X-Spam-Level: X-Spam-Status: No, score=-5.982 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 fmEvhthUJYgp for ; Wed, 25 Apr 2012 13:17:38 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 85AEF21F8910 for ; Wed, 25 Apr 2012 13:17:37 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-df-4f985bde9b4b Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C9.D9.25560.FDB589F4; Wed, 25 Apr 2012 22:17:35 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 25 Apr 2012 22:17:34 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "Ravindran, Parthasarathi" Date: Wed, 25 Apr 2012 22:17:34 +0200 Thread-Topic: [sipcore] Websocket is a new transport or new URI? Thread-Index: Ac0jCHX93F1n4ssFTA2hwyO6X81KXQAFwsQT Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4400131D@ESESSCMS0356.eemea.ericsson.se> References: <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> <4F970097.5020002@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E239306@inba-mail01.sonusnet.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:17:38 -0000 Hi, I agree with Inaki. Whatever "layer" we consider the WebSocket to be, in my opinion the URI sch= eme is used for addressing (either as an AOR or a contact), and should be i= ndependent of the transport. For what would the new scheme be needed anyway? Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of I=F1= aki Baz Castillo [ibc@aliax.net] Sent: Wednesday, April 25, 2012 8:25 PM To: Ravindran, Parthasarathi Cc: sipcore@ietf.org Subject: Re: [sipcore] Websocket is a new transport or new URI? Hi Partha, 2012/4/25 Ravindran, Parthasarathi : > So IMO, it is more appropriate to define new URI > scheme like SIPWS rather than defining websocket as a transport. The SIP transport defined by this draft is WebSocket, instead of TCP. WebSocket (RFC 6455) is defined to work on top of TCP but, even if a future spec defines WebSocket to run over SCTP, the SIP transport would still be "WebSocket" (or perhaps "WebSocket-SCTP" but that something in which I won't waste time now given the fact that RFC 6455 *mandates* TCP layer-3 transport and does not leave the door open for other layer-3 transports). WebSocket is, indeed, a layer on top of a network transport (layer 3) but it's designed to work as a *transport* layer since it defines a framing mechanism to send application messages and control mesages in both directions. Applications (i.e. JavaScript scripts, PHP/Java web apps) use WebSocket as a transport layer. You can find lot of cases in which a transport runs on top of other transports. For example, in the recent IETF #83 the RTCWEB WG approved (or discussed) SCTP-over-DTLS-over-ICE-over-UDP as the transport for the WebRTC Data-Channel mechanism. A "transport" does not necessarily mean "layer 3 network transport". About SIPS, the last S in SIPS stands for "secure" regardless of the undelying SIP transport used. AFAIK it does not necessarily mean "TLS". Take for example draft-jennings-sip-dtls-05 [1] which defines SIP over DTLS over UDP. The draf is expired, but anyhow, it defines a secure SIP transport which does not use TLS but DTLS (which is similar but NOT the same). The draft also allows SIPS messages through DTLS over UDP. [1] http://tools.ietf.org/html/draft-jennings-sip-dtls-05 When a SIPS message is carried on top of a secure WebSocket connection (which means SIP over WebSocket over TLS over TCP) the security level is basically the same as if it was SIP over TLS over TCP. Therefore I consider that a secure WebSocket connection fits the requirements of the SIPS mechanism, thus secure WebSocket should be considered as a secure SIP transport. About the SIPWS and SIPWSS schemas you propose, don't take me wrong but I consider that the worst possible idea. First of all because I don't agree with your rationale (I insist that, from the point of view of a SIP stack, WebSocket is the ***SIP transport***, instead of TCP). Secondly, because adding new URI schemas would just break the existing SIP world (there are still some SIP entities that don't understand SIPS schema and you are proposing two new ones?). Thanks a lot for your comments. -- I=F1aki Baz Castillo _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From christer.holmberg@ericsson.com Wed Apr 25 13:57:56 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7676E11E8074 for ; Wed, 25 Apr 2012 13:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.225 X-Spam-Level: X-Spam-Status: No, score=-5.225 tagged_above=-999 required=5 tests=[AWL=-0.788, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_SPEC_REPLICA_OBFU=1.812] 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 V1EMw0ql8Bms for ; Wed, 25 Apr 2012 13:57:55 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E850011E8072 for ; Wed, 25 Apr 2012 13:57:54 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-0e-4f986551be16 Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA) Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B3.95.26681.155689F4; Wed, 25 Apr 2012 22:57:53 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 25 Apr 2012 22:57:53 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 25 Apr 2012 22:57:52 +0200 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01 Thread-Index: Ac0i/27PyO3F7QQUQGmJwGCKTJFUhgAIgTfU Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4400131E@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C42DF52F5@ESESSCMS0356.eemea.ericsson.se> <4F96D072.5010102@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C441F09A8@ESESSCMS0356.eemea.ericsson.se>, <4F982477.7010506@alum.mit.edu> In-Reply-To: <4F982477.7010506@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-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 20:57:56 -0000 Hi Paul, Comments, and a correction to one of my own previous comments, inline. >>> Much of the syntax (ABNF - section 4.2.2) is a replica of what is in RF= C3840. IMO this relationship should be acknowledged. My preference would be= to formally reference the abnf definitions from 3840 and use the same name= s for them. >>> >>> E.g. >>> >>> feature-cap =3D ["+"] fcap-name [EQUAL LDQUOT (fcap-value-lis= t >>> / fcap-string-value ) RDQUOT] >>> fcap-name =3D ftag-name >>> fcap-value-list =3D tag-value-list >>> fcap-string-value =3D string-value >>> ;; ftag-name, tag-value-list, string-value defined in RFC3840 >> >> I can do that. >> >> I was actually already planning to do that, but I thought that people wo= uld not want to reference the RFC3840 ABNF :) > > Its a judgment call. In this case I think your intent is to keep the > syntax the same, and the best way to ensure that is to have the syntax > defined in only one place. Ok. --------------------- >>> I also find it some what confusing that part of the syntax is in this s= ection while more of it is in section 5.4. I'd prefer to see these consolid= ated into a single syntax section. >> >> I think the Feature-Caps header field syntax, and the feature-caps synta= x, shall be separated, but I can put them in the same section. > > I don't see any particular reason to keep them separated, especially if > the syntax is simplified by reference to 3840. But I don't have a > problem with separating it into two subsections, as long as they are > together in the document. I'll keep them separate for now, but move them to the same place. --------------------- >>> Are there other things in there that are just baggage being carried ove= r from 2506 that are not useful to us? (E.g. do we need the publication >>> delay?) >> >> I don't know. Unless someone wants it, I can remove it. > > Please also consider if there are any others that make no sense here and = can be removed. I did already remove some in -01, but I'll check whether there is something= else that could also be removed. --------------------- >>> Section 4.5.5 says: >>> >>> NOTE: Sometimes a SIP feature cap designer might choose to not reve= al >>> the implementation details of a SIP feature cap. However, in order >>> to allow multiple implementations to support the SIP feature cap, >>> designers are strongly encouraged to provide the implementation >>> details. >>> >>> I recognize that people may not want to publish implementation details. >>> But that is different from providing enough specification to all indepe= ndent but interoperable implementations to be developed. >>> >>> The amount that needs to be disclosed might vary based on which registr= ation tree is used. I would expect that the sip tree would require sufficie= nt spec to support an=20 >>> independent implementation. If you were instituting a URI tree then I c= an see that it might be considered entirely proprietary and hence might=20 >>> not require this. (But you have omitted the URI tree, which thus sidest= eps this issue.) ISTM that the global tree should still require a definitio= n of how to create an interoperable implementation. >>> The difference between the global tree and the sip tree in this regard = might be that in the case of the sip tree the >>> referenced specification = must be an IETF=20 >>> document, while in the case of the global tree it could be some externa= l document. >> >> I took the text from the Info-Package RFC. >> >> To be honest, however, I have some troubles to understand what is really= meant by "implementation details". As described in section 4.5.2, you DO h= ave to describe how the feature-cap is >> used etc, so I am not sure what extra "implementation details" would bri= ng. > > I was about to suggest we consult the authors of the Info-Package RFC, > but then I realized that you are one of the authors. :-) > So, what did you mean? > > In the case of Info packages the point is that you are delivering an > identified package of information, and so I would think that the > implementation details would include any sort of "protocol" layered on > top of that data - e.g. when I send certain info to you I expect that > you will send back another info with an ack/nack. IOW, whatever is > needed to successfully use this. (In some cases it may be very simple - > send anything syntactically valid for the package whenever you want, > with receiver free to do anything or nothing with it. > >> So, maybe we could simply remove section 4.5.5? > > Lets not give up just yet, before we understand. > Again, my point is to specify enough so that independent developers can > create interoperable implementations. When looking at RFC 6086, I think the "Implementation Details" part contain= s stuff that we have put in the "General Description" part. The "General De= scription" part of=20 RFC 6086 does not talk about providing details on how an Info-Package is us= ed, only what type of information it carries, and what type of applications= are using it. --------------------- >>> Section 5.2.2 then says: >>> >>> When a UA sends a SIP request, if the UA wants to indicate support = of >>> features towards its downstream SIP entities, it adds a Feature-Cap= s >>> header field to the request, together with one or more Feature Caps >>> associated with the supported features, before it forwards the >>> request. >>> >>> This says "adds" but doesn't say whether to be beginning or the end. >>> Also, it isn't strictly necessary to add another header field, it can a= dd to an existing header field. So I suggest: >>> >>> When a UA sends a SIP request, if the UA wants to indicate support = of >>> features towards its downstream SIP entities, before it forwards th= e >>> request it adds a fc-value with the supported features to >>> the request, after any others that may be present. This may be adde= d >>> to the last existing Feature-Caps header field or as a new >>> Feature-Caps header field after any others. >> >>> Something similar applies a couple more times in this section and in se= ctions 5.2.3 and 5.2.4. I realize this is a bit cumbersome - perhaps there = is a more straightforward way to say it. >> >> I will double check, but I THINK we normally only talk about adding a va= lue to an existing header field. The ABNF rules then shows whether multiple= instances of the header field is allowed. >> >> We just need to be sure that the text is clear on which features are "cl= osest" to the UA, no matter whether they are indicated in a single header f= ield, or in multiple header fields. > >Yes, I think we do usually do that, even though it is imprecise. >Within reason I'm ok with you following precedent of something with > similar behavior. Record-Route comes to mind. Yes, and this is where I need to correct myself. When a proxy adds Record-Route (or Via), it adds its value *before* any exi= sting values, and the idea is the same for feature-caps. That is indicated = in section 5.2.4 (see below), but=20 I guess should be in a general section. "When a proxy adds a Feature-Caps header field to a SIP message, it MUST place the header field before any existing Feature-Caps header fields in the request." (s/request/message) --------------------- >>> Section 5.3.3 says: >>> >>> If a SIP feature cap is inserted in a Feature-Caps header field of = a >>> SIP REGISTER request, or within a response of such request, it >>> indicates to the receivers of the request (or response) that the >>> feature associated with the SIP feature cap is supported for the >>> duration of the registration, and for all SIP transactions associat= ed >>> with the registration, until the registration is re-freshed or >>> terminated. >>> >>> There are some cases we need to discuss here. When a UA sends a REGISTE= R request, it could have no contacts, one contact, or several. What do the = feature caps mean in these cases? >>> >>> - if there are no contacts in the register, are feature-caps irrelevant= ? >>> - if there is more than one contact in the register, do the feature-cap= s >>> apply to all of them? >>> >>> Then the response should contain all the registered contacts, not just = those mentioned in the request. So do the feature caps mentioned in the rep= ly apply until the last of those=20 >>> contacts expire? Or should the requester assume they only apply until *= its* contacts expire? >>> >>> Unless a SIP feature cap is inserted in a Feature-Caps header field >>> or a re-registration, or within a response of such request, it >>> indicates to the receivers of the request (or response) that the >>> feature is no long supported for the registration. >>> >>> Suppose a UA registers with a contact and some feature caps. Then later= it sends a register poll (register with no contacts). Can I assume that th= is will not affect the feature caps associated with the registered contact? >> >> It's up to the entities that previously inserted the feature-caps to dec= ide whether they will continue to indicate support when they receive a re-r= egistration request/response - no matter whether it's a poll, addition of c= ontacts etc. >> >> Personally I see no reason why they should *not* insert the same feature= -caps in a pure poll request/response, but we should allow for cases where = the feature is no longer supported when the poll request/response is receiv= ed. > > I think you missed my point. Its really the same point as my question of >what it means to put feature caps into a polling register. > > Since you want the registrar to consider the received feature caps to be > stateful for the duration of the register, I want to know what that > state is attached to. ISTM that it must be attached to particular > contacts. Then, a polling register would presumably not update the state > of any registered contact since it doesn't update any of them. > > On the flip side of that, if the registrar returns feature caps, what > does the recipient attach that state to? The only thing it could attach > it to that has a lifetime is the registration of a particular contact, > since the registered contacts can expire independently. Ok, I think I understand. I need to think a little about it. --------------------- >>> Do the enhanced registrar behaviors in outbound require any special tre= atment relative to feature caps? >> >> No, I don't think so. >> >> However, I guess we could add a clarification note saying that features = are only supported for the specific outbound registration flow where suppor= t has been explicitly indicated. > > I'm only asking that you look at it. If nothing is needed, that is fine. > The clarification sounds good if it is true. (I don't know if it is true.= ) I guess this is related to the issue above. --------------------- >>> Section 6: >>> >>> There are a lot of missing IANA considerations - the establishment of t= he new trees as defined in 4.3 and 4.4. >> >> I used RFC 2506 as base, where the trees are defined more or less in the= same way as in the draft. But, I guess it's better to do it in the same wa= y as in RFC 3840. > > Again, we are establishing a new IANA registry here. > I think it unwise to couple it to the definition of a different registry > in a document we don't control. (Some day 2506 may be updated, and we > wouldn't want that to affect *this* registry.) What I meant was that RFC 2506 does not define its registry in an IANA Cons= iderations sections. > In any case, IANA needs to be given explicit instructions to establish th= e new registry, and couple it to the template. Yes. Regards, Christer= From pkyzivat@alum.mit.edu Wed Apr 25 14:20:02 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF0A11E809F for ; Wed, 25 Apr 2012 14:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599, SARE_SPEC_REPLICA_OBFU=1.812] 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 YlsFiLuQkqML for ; Wed, 25 Apr 2012 14:20:01 -0700 (PDT) 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 7EB1711E809C for ; Wed, 25 Apr 2012 14:19:44 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta04.westchester.pa.mail.comcast.net with comcast id 2M9Z1j0051GhbT854MKl2e; Wed, 25 Apr 2012 21:19:45 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta07.westchester.pa.mail.comcast.net with comcast id 2MKm1j00c07duvL3TMKm10; Wed, 25 Apr 2012 21:19:47 +0000 Message-ID: <4F986A6E.8000802@alum.mit.edu> Date: Wed, 25 Apr 2012 17:19:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C42DF52F5@ESESSCMS0356.eemea.ericsson.se> <4F96D072.5010102@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C441F09A8@ESESSCMS0356.eemea.ericsson.se>, <4F982477.7010506@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C4400131E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4400131E@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Apr 2012 21:20:02 -0000 This all seems good to me. Thanks, Paul On 4/25/12 4:57 PM, Christer Holmberg wrote: > Hi Paul, > > Comments, and a correction to one of my own previous comments, inline. > >>>> Much of the syntax (ABNF - section 4.2.2) is a replica of what is in RFC3840. IMO this relationship should be acknowledged. My preference would be to formally reference the abnf definitions from 3840 and use the same names for them. >>>> >>>> E.g. >>>> >>>> feature-cap = ["+"] fcap-name [EQUAL LDQUOT (fcap-value-list >>>> / fcap-string-value ) RDQUOT] >>>> fcap-name = ftag-name >>>> fcap-value-list = tag-value-list >>>> fcap-string-value = string-value >>>> ;; ftag-name, tag-value-list, string-value defined in RFC3840 >>> >>> I can do that. >>> >>> I was actually already planning to do that, but I thought that people would not want to reference the RFC3840 ABNF :) >> >> Its a judgment call. In this case I think your intent is to keep the >> syntax the same, and the best way to ensure that is to have the syntax >> defined in only one place. > > Ok. > > > --------------------- > > >>>> I also find it some what confusing that part of the syntax is in this section while more of it is in section 5.4. I'd prefer to see these consolidated into a single syntax section. >>> >>> I think the Feature-Caps header field syntax, and the feature-caps syntax, shall be separated, but I can put them in the same section. >> >> I don't see any particular reason to keep them separated, especially if >> the syntax is simplified by reference to 3840. But I don't have a >> problem with separating it into two subsections, as long as they are >> together in the document. > > I'll keep them separate for now, but move them to the same place. > > > --------------------- > > >>>> Are there other things in there that are just baggage being carried over from 2506 that are not useful to us? (E.g. do we need the publication >>>> delay?) >>> >>> I don't know. Unless someone wants it, I can remove it. >> >> Please also consider if there are any others that make no sense here and can be removed. > > I did already remove some in -01, but I'll check whether there is something else that could also be removed. > > > --------------------- > > >>>> Section 4.5.5 says: >>>> >>>> NOTE: Sometimes a SIP feature cap designer might choose to not reveal >>>> the implementation details of a SIP feature cap. However, in order >>>> to allow multiple implementations to support the SIP feature cap, >>>> designers are strongly encouraged to provide the implementation >>>> details. >>>> >>>> I recognize that people may not want to publish implementation details. >>>> But that is different from providing enough specification to all independent but interoperable implementations to be developed. >>>> >>>> The amount that needs to be disclosed might vary based on which registration tree is used. I would expect that the sip tree would require sufficient spec to support an >>>> independent implementation. If you were instituting a URI tree then I can see that it might be considered entirely proprietary and hence might >>>> not require this. (But you have omitted the URI tree, which thus sidesteps this issue.) ISTM that the global tree should still require a definition of how to create an interoperable implementation. >>>> The difference between the global tree and the sip tree in this regard might be that in the case of the sip tree the>>> referenced specification must be an IETF >>>> document, while in the case of the global tree it could be some external document. >>> >>> I took the text from the Info-Package RFC. >>> >>> To be honest, however, I have some troubles to understand what is really meant by "implementation details". As described in section 4.5.2, you DO have to describe how the feature-cap is >>> used etc, so I am not sure what extra "implementation details" would bring. >> >> I was about to suggest we consult the authors of the Info-Package RFC, >> but then I realized that you are one of the authors. :-) >> So, what did you mean? >> >> In the case of Info packages the point is that you are delivering an >> identified package of information, and so I would think that the >> implementation details would include any sort of "protocol" layered on >> top of that data - e.g. when I send certain info to you I expect that >> you will send back another info with an ack/nack. IOW, whatever is >> needed to successfully use this. (In some cases it may be very simple - >> send anything syntactically valid for the package whenever you want, >> with receiver free to do anything or nothing with it. >> >>> So, maybe we could simply remove section 4.5.5? >> >> Lets not give up just yet, before we understand. >> Again, my point is to specify enough so that independent developers can >> create interoperable implementations. > > > When looking at RFC 6086, I think the "Implementation Details" part contains stuff that we have put in the "General Description" part. The "General Description" part of > RFC 6086 does not talk about providing details on how an Info-Package is used, only what type of information it carries, and what type of applications are using it. > > > --------------------- > > >>>> Section 5.2.2 then says: >>>> >>>> When a UA sends a SIP request, if the UA wants to indicate support of >>>> features towards its downstream SIP entities, it adds a Feature-Caps >>>> header field to the request, together with one or more Feature Caps >>>> associated with the supported features, before it forwards the >>>> request. >>>> >>>> This says "adds" but doesn't say whether to be beginning or the end. >>>> Also, it isn't strictly necessary to add another header field, it can add to an existing header field. So I suggest: >>>> >>>> When a UA sends a SIP request, if the UA wants to indicate support of >>>> features towards its downstream SIP entities, before it forwards the >>>> request it adds a fc-value with the supported features to >>>> the request, after any others that may be present. This may be added >>>> to the last existing Feature-Caps header field or as a new >>>> Feature-Caps header field after any others. >>> >>>> Something similar applies a couple more times in this section and in sections 5.2.3 and 5.2.4. I realize this is a bit cumbersome - perhaps there is a more straightforward way to say it. >>> >>> I will double check, but I THINK we normally only talk about adding a value to an existing header field. The ABNF rules then shows whether multiple instances of the header field is allowed. >>> >>> We just need to be sure that the text is clear on which features are "closest" to the UA, no matter whether they are indicated in a single header field, or in multiple header fields. >> >> Yes, I think we do usually do that, even though it is imprecise. >> Within reason I'm ok with you following precedent of something with >> similar behavior. Record-Route comes to mind. > > Yes, and this is where I need to correct myself. > > When a proxy adds Record-Route (or Via), it adds its value *before* any existing values, and the idea is the same for feature-caps. That is indicated in section 5.2.4 (see below), but > I guess should be in a general section. > > "When a proxy adds a Feature-Caps header field to a SIP message, it > MUST place the header field before any existing Feature-Caps header > fields in the request." > > (s/request/message) > > > --------------------- > > >>>> Section 5.3.3 says: >>>> >>>> If a SIP feature cap is inserted in a Feature-Caps header field of a >>>> SIP REGISTER request, or within a response of such request, it >>>> indicates to the receivers of the request (or response) that the >>>> feature associated with the SIP feature cap is supported for the >>>> duration of the registration, and for all SIP transactions associated >>>> with the registration, until the registration is re-freshed or >>>> terminated. >>>> >>>> There are some cases we need to discuss here. When a UA sends a REGISTER request, it could have no contacts, one contact, or several. What do the feature caps mean in these cases? >>>> >>>> - if there are no contacts in the register, are feature-caps irrelevant? >>>> - if there is more than one contact in the register, do the feature-caps >>>> apply to all of them? >>>> >>>> Then the response should contain all the registered contacts, not just those mentioned in the request. So do the feature caps mentioned in the reply apply until the last of those >>>> contacts expire? Or should the requester assume they only apply until *its* contacts expire? >>>> >>>> Unless a SIP feature cap is inserted in a Feature-Caps header field >>>> or a re-registration, or within a response of such request, it >>>> indicates to the receivers of the request (or response) that the >>>> feature is no long supported for the registration. >>>> >>>> Suppose a UA registers with a contact and some feature caps. Then later it sends a register poll (register with no contacts). Can I assume that this will not affect the feature caps associated with the registered contact? >>> >>> It's up to the entities that previously inserted the feature-caps to decide whether they will continue to indicate support when they receive a re-registration request/response - no matter whether it's a poll, addition of contacts etc. >>> >>> Personally I see no reason why they should *not* insert the same feature-caps in a pure poll request/response, but we should allow for cases where the feature is no longer supported when the poll request/response is received. >> >> I think you missed my point. Its really the same point as my question of >> what it means to put feature caps into a polling register. >> >> Since you want the registrar to consider the received feature caps to be >> stateful for the duration of the register, I want to know what that >> state is attached to. ISTM that it must be attached to particular >> contacts. Then, a polling register would presumably not update the state >> of any registered contact since it doesn't update any of them. >> >> On the flip side of that, if the registrar returns feature caps, what >> does the recipient attach that state to? The only thing it could attach >> it to that has a lifetime is the registration of a particular contact, >> since the registered contacts can expire independently. > > Ok, I think I understand. I need to think a little about it. > > > --------------------- > > >>>> Do the enhanced registrar behaviors in outbound require any special treatment relative to feature caps? >>> >>> No, I don't think so. >>> >>> However, I guess we could add a clarification note saying that features are only supported for the specific outbound registration flow where support has been explicitly indicated. >> >> I'm only asking that you look at it. If nothing is needed, that is fine. >> The clarification sounds good if it is true. (I don't know if it is true.) > > I guess this is related to the issue above. > > > --------------------- > > >>>> Section 6: >>>> >>>> There are a lot of missing IANA considerations - the establishment of the new trees as defined in 4.3 and 4.4. >>> >>> I used RFC 2506 as base, where the trees are defined more or less in the same way as in the draft. But, I guess it's better to do it in the same way as in RFC 3840. >> >> Again, we are establishing a new IANA registry here. >> I think it unwise to couple it to the definition of a different registry >> in a document we don't control. (Some day 2506 may be updated, and we >> wouldn't want that to affect *this* registry.) > > What I meant was that RFC 2506 does not define its registry in an IANA Considerations sections. > >> In any case, IANA needs to be given explicit instructions to establish the new registry, and couple it to the template. > > Yes. > > Regards, > > Christer From pravindran@sonusnet.com Wed Apr 25 18:46:03 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144D421F85C5 for ; Wed, 25 Apr 2012 18:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gd0HMu0bsUC for ; Wed, 25 Apr 2012 18:46:02 -0700 (PDT) Received: from na3sys010aog107.obsmtp.com (na3sys010aog107.obsmtp.com [74.125.245.82]) by ietfa.amsl.com (Postfix) with ESMTP id D13FF21F85C6 for ; Wed, 25 Apr 2012 18:46:01 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob107.postini.com ([74.125.244.12]) with SMTP ID DSNKT5io1fO40NwrizjrxA1tVbLVoyTQV7ib@postini.com; Wed, 25 Apr 2012 18:46:01 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 25 Apr 2012 21:45:58 -0400 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.0355.002; Thu, 26 Apr 2012 07:15:52 +0530 From: "Ravindran, Parthasarathi" To: "Vijay K. Gurbani" , Paul Kyzivat , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [sipcore] Websocket is a new transport or new URI? Thread-Index: AQHNIDOCuN/qLU9tjk656lTA6m0G85am5VEAgAD8KaCAAD8sgIABv2aw//+u7wCAAHdUgIABOZfA///CEICAAEg4AIAAFPGAgAD4/DA= Date: Thu, 26 Apr 2012 01:45:51 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E23A768@inba-mail01.sonusnet.com> References: <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> <4F970097.5020002@alum.mit.edu> <387F9047F55E8C4285 0AD6B3A7A03C6C0E239306@inba-mail01.sonusnet.com> <5522E7CB-78FF-4582-8E39-0E8E43301650@ag-projects.com> <4F981046.6010508@alum.mit.edu> <4F9821D7.6030908@bell-labs.com> In-Reply-To: <4F9821D7.6030908@bell-labs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 01:46:03 -0000 Vijay, Thanks for forwarding the fruitful information. Now I understand why Paul is saying that SIPS URI is a mistake in RFC 3261. The point to be noted is= =20 that there is no IETF document to clarify this. Hi all, I agree that it is better to proceed websokcet as a transport rather than=20 new URI to avoid earlier mistake now. SIPS is not deprecated for TLS over TCP as it is widely deployed. Having said that, I'm not fully convinced with SIPS usage for websocket as IMO, it is extending the mistake to the new transport as well. Knowing that it is a mistake in the base RFC 3261, it is not the right thing to be= =20 allowed for new transport introduced. Let us discuss this open item in=20 this thread or other thread. >From the TCP/IP protocol stack perspective, TLS as URI and WebSocket=20 as transport is not the right thing as it is confusing as follows. sips:alice@example.com;transport=3Dws The better approach will be=20 sip:alice@example.com;transport=3Dwss Thanks Partha >-----Original Message----- >From: Vijay K. Gurbani [mailto:vkg@bell-labs.com] >Sent: Wednesday, April 25, 2012 9:40 PM >To: Paul Kyzivat >Cc: Sa=FAl Ibarra Corretg=E9; Ravindran, Parthasarathi; sipcore@ietf.org >Subject: Re: [sipcore] Websocket is a new transport or new URI? > >On 04/25/2012 09:55 AM, Paul Kyzivat wrote: >> I agree with Sa=FAl here. I don't really understand what it is that >> Partha is proposing. >> >> As I already stated, I think sips turned out to be a mistake - that it >> doesn't provide enough of a guarantee to be able to promise anything >> to an end user. But we investigated this ad nauseum and couldn't come >> up with anything substantially better. > >Time for institutional memory, perhaps? The long discussions (May - >June 2006) on why sips failed and ideas to come up with new URI schemes >to replace it and attendant problems (upcasting URIs, downcasting URIs >without user consent, hop-by-hop semantics versus end-to-end, etc.) is >summarized in http://www.ietf.org/mail- >archive/web/sip/current/msg24047.html > >- vijay >-- >Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) >Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com >Web: http://ect.bell-labs.com/who/vkg/ From christer.holmberg@ericsson.com Thu Apr 26 00:57:54 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DBA21F8663 for ; Thu, 26 Apr 2012 00:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.104 X-Spam-Level: X-Spam-Status: No, score=-6.104 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 oEmLxX5-tYaT for ; Thu, 26 Apr 2012 00:57:52 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A9BF921F865F for ; Thu, 26 Apr 2012 00:57:51 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-3e-4f98fffe7275 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0247"; auth=fail (cipher=AES128-SHA) Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0247", Issuer "esessmw0247" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5C.14.03534.EFFF89F4; Thu, 26 Apr 2012 09:57:50 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Thu, 26 Apr 2012 09:57:49 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Thu, 26 Apr 2012 09:57:46 +0200 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01 Thread-Index: Ac0jgixZL0gbSUu7R8umL2kyIdjW2Q== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C441F0EF7@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 07:57:55 -0000 Hi Paul, Some thinking on the contact issue. >>>> Section 5.3.3 says: >>>> >>>> If a SIP feature cap is inserted in a Feature-Caps header field o= f a >>>> SIP REGISTER request, or within a response of such request, it >>>> indicates to the receivers of the request (or response) that the >>>> feature associated with the SIP feature cap is supported for the >>>> duration of the registration, and for all SIP transactions associ= ated >>>> with the registration, until the registration is re-freshed or >>>> terminated. >>>> >>>> There are some cases we need to discuss here. When a UA sends a REGIST= ER request, it could have no contacts, one contact, or several. What do the= feature caps mean in these cases? >>>> >>>> - if there are no contacts in the register, are feature-caps irrelevan= t? >>>> - if there is more than one contact in the register, do the feature-ca= ps >>>> apply to all of them? >>>> >>>> Then the response should contain all the registered contacts, not=20 >>>> just those mentioned in the request. So do the feature caps mentioned = in the reply apply until the last of those contacts expire? Or should the r= equester assume they only apply until *its* contacts expire? >>>> >>>> Unless a SIP feature cap is inserted in a Feature-Caps header fie= ld >>>> or a re-registration, or within a response of such request, it >>>> indicates to the receivers of the request (or response) that the >>>> feature is no long supported for the registration. >>>> >>>> Suppose a UA registers with a contact and some feature caps. Then late= r it sends a register poll (register with no contacts). Can I assume that t= his will not affect the feature caps associated with the registered contact= ? >>> >>> It's up to the entities that previously inserted the feature-caps to de= cide whether they will continue to indicate support when they receive a re-= registration request/response - no matter whether it's a poll, addition of = contacts etc. >>> >>> Personally I see no reason why they should *not* insert the same featur= e-caps in a pure poll request/response, but we should allow for cases where= the feature is no longer supported when the poll request/response is recei= ved. >> >> I think you missed my point. Its really the same point as my question=20 >> of what it means to put feature caps into a polling register. >> >> Since you want the registrar to consider the received feature caps to=20 >> be stateful for the duration of the register, I want to know what=20 >> that state is attached to. ISTM that it must be attached to=20 >> particular contacts. Then, a polling register would presumably not=20 >> update the state of any registered contact since it doesn't update any o= f them. >> >> On the flip side of that, if the registrar returns feature caps, what=20 >> does the recipient attach that state to? The only thing it could=20 >> attach it to that has a lifetime is the registration of a particular=20 >> contact, since the registered contacts can expire independently. > > Ok, I think I understand. I need to think a little about it. My suggestion would be: - When outbound is *not* used, if support of feature F9 is indicated when c= ontact C1 is registered, the feature is supported until C1 expires, is expl= icitly removed, or explicitly refreshed. - When outbound *is* used, the same as above applies, but only for the spec= ific C1 registration flow for which support of F9 has been indicated. Example: If I register C1, using two outbound flows (O1 and O2), and suppo= rt of F9 is indicated for O1, when O1 is expired/removed/refreshed F9 is no= longer supported. - Whenever a contact is explicitly refreshed, entities MUST insert Feature-= Caps if they still want to indicate support of the feature. - For pure poll messages, where the REGISTER request does *not* contain a c= ontact, my suggestion is that we say that the document does not define any = semantics for usage of Feature-Caps in such requests/responses. If no seman= tics is defined, poll messages will not have any impact on previously indic= ated support of features, and entities MUST NOT insert a Feature-Caps heade= r field in such requests, or their associated responses. How does that sound? :) Regards, Christer From pravindran@sonusnet.com Thu Apr 26 01:52:32 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B92C21F86FC for ; Thu, 26 Apr 2012 01:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 MuIzh1bzq8R1 for ; Thu, 26 Apr 2012 01:52:31 -0700 (PDT) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with ESMTP id 71C1921F8621 for ; Thu, 26 Apr 2012 01:52:31 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKT5kMzm8x6nZRRV6vGEYZDFpqVZZoAbe0@postini.com; Thu, 26 Apr 2012 01:52:31 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 26 Apr 2012 04:52:32 -0400 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.0355.002; Thu, 26 Apr 2012 14:22:23 +0530 From: "Ravindran, Parthasarathi" To: Christer Holmberg , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Thread-Topic: [sipcore] Websocket is a new transport or new URI? Thread-Index: AQHNIDOCuN/qLU9tjk656lTA6m0G85am5VEAgAD8KaCAAD8sgIABv2aw//+u7wCAAHdUgIABOZfAgAA0PwCAADAmAIABKHSQ Date: Thu, 26 Apr 2012 08:52:22 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E23A7FF@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> <4F970097.5020002@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E239306@inba-mail01.sonusnet.com>, <7F2072F1E0DE894DA4B517B93C6A05852C4400131D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4400131D@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 08:52:32 -0000 Hi Christer, When I argued for new URI, the contact shall use new URI with=20 the existing TCP transport like sipws:alice@example.com;transport=3Dtcp "sipws" URI shall be compare with "ws" URI in Websocket protocol=20 (Sec 3 of RFC 6455).=20 Thanks Partha >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Thursday, April 26, 2012 1:48 AM >To: I=F1aki Baz Castillo; Ravindran, Parthasarathi >Cc: sipcore@ietf.org >Subject: RE: [sipcore] Websocket is a new transport or new URI? > >Hi, > >I agree with Inaki. > >Whatever "layer" we consider the WebSocket to be, in my opinion the URI >scheme is used for addressing (either as an AOR or a contact), and >should be independent of the transport. > >For what would the new scheme be needed anyway? > >Regards, > >Christer > > > > >________________________________________ >From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of >I=F1aki Baz Castillo [ibc@aliax.net] >Sent: Wednesday, April 25, 2012 8:25 PM >To: Ravindran, Parthasarathi >Cc: sipcore@ietf.org >Subject: Re: [sipcore] Websocket is a new transport or new URI? > >Hi Partha, > > >2012/4/25 Ravindran, Parthasarathi : >> So IMO, it is more appropriate to define new URI scheme like SIPWS >> rather than defining websocket as a transport. > > >The SIP transport defined by this draft is WebSocket, instead of TCP. >WebSocket (RFC 6455) is defined to work on top of TCP but, even if a >future spec defines WebSocket to run over SCTP, the SIP transport would >still be "WebSocket" (or perhaps "WebSocket-SCTP" but that something in >which I won't waste time now given the fact that RFC 6455 >*mandates* TCP layer-3 transport and does not leave the door open for >other layer-3 transports). > >WebSocket is, indeed, a layer on top of a network transport (layer 3) >but it's designed to work as a *transport* layer since it defines a >framing mechanism to send application messages and control mesages in >both directions. Applications (i.e. JavaScript scripts, PHP/Java web >apps) use WebSocket as a transport layer. > >You can find lot of cases in which a transport runs on top of other >transports. For example, in the recent IETF #83 the RTCWEB WG approved >(or discussed) SCTP-over-DTLS-over-ICE-over-UDP as the transport for the >WebRTC Data-Channel mechanism. A "transport" does not necessarily mean >"layer 3 network transport". > > > >About SIPS, the last S in SIPS stands for "secure" regardless of the >undelying SIP transport used. AFAIK it does not necessarily mean "TLS". >Take for example draft-jennings-sip-dtls-05 [1] which defines SIP over >DTLS over UDP. The draf is expired, but anyhow, it defines a secure SIP >transport which does not use TLS but DTLS (which is similar but NOT the >same). The draft also allows SIPS messages through DTLS over UDP. > >[1] http://tools.ietf.org/html/draft-jennings-sip-dtls-05 > > >When a SIPS message is carried on top of a secure WebSocket connection >(which means SIP over WebSocket over TLS over TCP) the security level is >basically the same as if it was SIP over TLS over TCP. Therefore I >consider that a secure WebSocket connection fits the requirements of the >SIPS mechanism, thus secure WebSocket should be considered as a secure >SIP transport. > > > >About the SIPWS and SIPWSS schemas you propose, don't take me wrong but >I consider that the worst possible idea. First of all because I don't >agree with your rationale (I insist that, from the point of view of a >SIP stack, WebSocket is the ***SIP transport***, instead of TCP). >Secondly, because adding new URI schemas would just break the existing >SIP world (there are still some SIP entities that don't understand SIPS >schema and you are proposing two new ones?). > > >Thanks a lot for your comments. > > >-- >I=F1aki Baz Castillo > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From rick@openfortress.nl Thu Apr 26 02:19:06 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB42E21F87C5; Thu, 26 Apr 2012 02:19:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.61 X-Spam-Level: X-Spam-Status: No, score=0.61 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_NL=1.545] 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 stxEaMmmFAyi; Thu, 26 Apr 2012 02:19:06 -0700 (PDT) Received: from fame.vanrein.org (openfortress.nl [213.189.19.244]) by ietfa.amsl.com (Postfix) with ESMTP id F103121F87B6; Thu, 26 Apr 2012 02:19:05 -0700 (PDT) Received: from phantom.vanrein.org (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTP id 89C1E4040D1; Thu, 26 Apr 2012 10:19:04 +0100 (BST) Received: by phantom.vanrein.org (Postfix, from userid 1000) id 3DBB42255C; Thu, 26 Apr 2012 09:27:25 +0000 (CEST) Date: Thu, 26 Apr 2012 09:27:25 +0000 From: Rick van Rein To: uri-review@ietf.org, sipcore@ietf.org Message-ID: <20120426092725.GC27002@newphantom.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [sipcore] Proposal: sip6 URI scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:19:07 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I am developing to get better support for SIP over IPv6. One of the problems that I have encountered is the interoperability between endpoints that run only IPv4 or IPv6. To solve this situations prior to call setup, I am proposing a sip6 URI scheme. Using this, end users and their tools should have an easier time deciding whether or not to use the URI. A similar thing applies to enforced ZRTP --being sure before calling that the call will be private-- and I combined that with the URI scheme proposal, so as not to register more URI schemes than required. Your feedback is kindly welcomed. Best wishes, Rick van Rein OpenFortress --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="sip6-uri-proposal.txt" URI scheme name. sip6 Status. permanent URI scheme syntax. sip6:[:]@[:][;][?] The scheme is the same as for sip: with the exception of the URI scheme. URI scheme semantics. SIP entities [RFC3261] that process the sip6 scheme URI ensure that the following additional constraints for the sip6 URI scheme are not broken, by implementing them inasfar as it concerns their processing: * All SIP, media descriptive and media traffic that follows from a sip6 URI scheme MUST be communicated over IPv6, and describe IPv6-capable resources. * All RTP traffic that follows from a a sip6 URI MUST support ZRTP [RFC6189] and actively attempt to establish ZRTP. Descriptions of such RTP communications SHOULD offer ZRTP. These additional requirements describe a method of deploying SIP that brings it nearer to its ideal configuration; namely, without any need for an intermediate party in the media path. There are advantages to deploying configurations that only work within these constraints, but with only a sip URI scheme such configurations would not be discovered until a call setup was being attempted, leading to potential end-user experiences of broken calls. The sip6 URI scheme is intended to avoid that problematic behavior. Applications/protocols that use this URI scheme name. The Session Initiation Protocol can be used with the sip6 URI scheme. With the exception that the aforementioned additional requirements apply, the processing is not in any way different. Specifically, the protocol continues to be named SIP in transport descriptions, and _sip._udp continues to be used a DNS name for SRV records. The syntactic declaration of support of this scheme can help to make an early selection of the proper tools, either by an end-user who can be properly informed, or by generic browsing tools that start different handling agents for the sip and sip6 URI schemes. A SIP phone that dials a sip6 URI can be certain that IPv6-only communication suffices; the phone can refuse attempts to dial such a number if IPv6 is not available, and prefer a sip URI alternative if it is available. On the other hand, current SIP phones that only support IPv4 will not recognise the sip6: URI scheme, and as a result skip attempts to contact them. There is no prohibition on translating proxies that map the sip6 URI sphere to the sip URI sphere, provided that the sip6 side of such proxies conceals the parts of the sip side that are not compliant to the additional requirements on the sip6 side. Interoperability considerations. The sip URI suggests a capability to communicate over IPv4 and IPv6, but in practice these protocols are incompatible. The result of having both address schemes under the same URI scheme can lead to interoperability problems. The introduction of a separate URI scheme for SIP over IPv6 improves this situation, by reflecting the incompability of the IPv4 and IPv6 spaces in an easily processed form. The required support for ZRTP implies that any implementations that use RTP but do not implement ZRTP facilities are inoperable with the sip6 URI format. This too is a deliberate choice that leads to more certainty to be derived from the connections being setup. Security considerations. The usual security considerations for SIP apply, with the exception that the requirement of ZRTP support reduces the risks of phone tapping and man-in-the-middle attacks. Contact. Rick van Rein Author/Change controller. Rick van Rein References. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC6189] Zimmermann, P., Zfone Project, Johnston, E., Ayaya and Calls, J., "ZRTP: Media Path Key Agreement for Unicast Secure RTP", April 2011. --Q68bSM7Ycu6FN28Q-- From oej@edvina.net Thu Apr 26 02:22:39 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95C9521F865C; Thu, 26 Apr 2012 02:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzdKpz6tzXWf; Thu, 26 Apr 2012 02:22:32 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 486E721F85C6; Thu, 26 Apr 2012 02:22:30 -0700 (PDT) Received: from [10.1.27.118] (office.ipvision.dk [94.127.50.104]) by smtp7.webway.se (Postfix) with ESMTPA id 97CF3754A8A2; Thu, 26 Apr 2012 09:22:28 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <20120426092725.GC27002@newphantom.local> Date: Thu, 26 Apr 2012 11:22:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120426092725.GC27002@newphantom.local> To: Rick van Rein X-Mailer: Apple Mail (2.1257) Cc: uri-review@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] Proposal: sip6 URI scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:22:39 -0000 26 apr 2012 kl. 11:27 skrev Rick van Rein: > Hello, >=20 > I am developing to get better support for SIP over IPv6. One of the > problems that I have encountered is the interoperability between > endpoints that run only IPv4 or IPv6. To solve this situations prior > to call setup, I am proposing a sip6 URI scheme. Using this, end = users > and their tools should have an easier time deciding whether or not to > use the URI. >=20 A new URI scheme doesn't make any sense, since a SIP uri can be resolved = to many different hosts using NAPTR/SRV records. A phone that is dual stack can register with two contacts, one for each = address family. ICE will take care of media handling. /O= From rick@openfortress.nl Thu Apr 26 02:29:03 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4CB21F86E1; Thu, 26 Apr 2012 02:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.347 X-Spam-Level: X-Spam-Status: No, score=0.347 tagged_above=-999 required=5 tests=[AWL=0.790, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_NL=1.545] 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 yvw-ypCTxy77; Thu, 26 Apr 2012 02:29:02 -0700 (PDT) Received: from fame.vanrein.org (openfortress.nl [213.189.19.244]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD8E21F86DA; Thu, 26 Apr 2012 02:28:48 -0700 (PDT) Received: from phantom.vanrein.org (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTP id E3F764040D1; Thu, 26 Apr 2012 10:28:46 +0100 (BST) Received: by phantom.vanrein.org (Postfix, from userid 1000) id 90ECA2255C; Thu, 26 Apr 2012 09:37:07 +0000 (CEST) Date: Thu, 26 Apr 2012 09:37:07 +0000 From: Rick van Rein To: "Olle E. Johansson" Message-ID: <20120426093707.GE27002@newphantom.local> References: <20120426092725.GC27002@newphantom.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM User-Agent: Mutt/1.5.20 (2009-06-14) Cc: uri-review@ietf.org, Rick van Rein , sipcore@ietf.org Subject: Re: [sipcore] Proposal: sip6 URI scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:29:03 -0000 Hello Olle, > A new URI scheme doesn't make any sense, since a SIP uri can be resolved to many different hosts using NAPTR/SRV records. This only helps with the SIP communication -- but it gives no certainty about RTP. Interoperability between IPv4-only and IPv6-only relating to media can only be found when trying to setup a call, right? > A phone that is dual stack can register with two contacts, one for each address family. ICE will take care of media handling. There is no formal relation between the IP version used for SIP and used for RTP. This is what I am proposing to solve with sip6: Thanks, -Rick From ibc@aliax.net Thu Apr 26 02:31:13 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E492321F8566 for ; Thu, 26 Apr 2012 02:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.63 X-Spam-Level: X-Spam-Status: No, score=-2.63 tagged_above=-999 required=5 tests=[AWL=0.047, 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 iYfdLFMxl53j for ; Thu, 26 Apr 2012 02:31:13 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 450DE21F8567 for ; Thu, 26 Apr 2012 02:31:13 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so848483vcb.31 for ; Thu, 26 Apr 2012 02:31:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=IpIxdypSgTToCzKKR0ihGFP73kDdG7ytFL4LPKsE4oI=; b=NV/B5k4F2nGXCQ0LfgRzFYHUDV+wvSJAZxxZzawWRLLTg3iG+AUDGd0G1g6zIHrcUO Wrs3erYHGpODh5QrH6UhX7XM3UbjdyhghcM6FFoeRz8oxOuk7cPJiODHWAsfyLsqox2w z21zvJadwU9TiGxtTdGfezPW2eMrxChvRVNYvzjEq86if/V0VAhBStbzdFrhqBR/Xyg2 06XMuvPaB/FEGhcDyDatGwFP+S71IWelykYXfPmh03UBH07oY/WvmcINa4PCcuTOEO93 W7SVR2puUU2qIoacdMGlZg0UioisCmPObQRlm1yuJYR/jSZJTo5nTabViRIGGEuDikcC otTQ== Received: by 10.52.15.233 with SMTP id a9mr5435290vdd.34.1335432672636; Thu, 26 Apr 2012 02:31:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.199 with HTTP; Thu, 26 Apr 2012 02:30:52 -0700 (PDT) In-Reply-To: <20120426092725.GC27002@newphantom.local> References: <20120426092725.GC27002@newphantom.local> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 26 Apr 2012 11:30:52 +0200 Message-ID: To: Rick van Rein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkSh6JfuLJTGwQwpk6Jwrtq+1CK0Tinfv2vA7yDRBCikL028qgXBBf0tDgJCX4zeGxj9pa9 Cc: uri-review@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] Proposal: sip6 URI scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:31:14 -0000 2012/4/26 Rick van Rein : > I am developing to get better support for SIP over IPv6. =C2=A0One of the > problems that I have encountered is the interoperability between > endpoints that run only IPv4 or IPv6. =C2=A0To solve this situations prio= r > to call setup, I am proposing a sip6 URI scheme. Hi Rick, I'm pretty sure that's not the way to go. As Olle pointed out a SIP URI with domain could point, after RFC 3263 resolution, to many transport:address:port, some of them could be IPv4 and others IPv6. Your proposal would indeed break existing implementations. If for example alice uses just IPv4 and bob just IPv6, and both use and register in a proxy/registrar with IP dual stack, alice should be able to call bob's AoR (sip:bob@example.net) without knowing that bob is using IPv6 or not. This is already possible with current specs but it would be not possible with your proposal. Regards. --=20 I=C3=B1aki Baz Castillo From oej@edvina.net Thu Apr 26 02:32:55 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86D621F87DC; Thu, 26 Apr 2012 02:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wifgj+J2T1F7; Thu, 26 Apr 2012 02:32:55 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE3B21F87D8; Thu, 26 Apr 2012 02:32:55 -0700 (PDT) Received: from [10.1.27.118] (office.ipvision.dk [94.127.50.104]) by smtp7.webway.se (Postfix) with ESMTPA id 619CC754A8AA; Thu, 26 Apr 2012 09:32:54 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: "Olle E. Johansson" In-Reply-To: <20120426093707.GE27002@newphantom.local> Date: Thu, 26 Apr 2012 11:32:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120426092725.GC27002@newphantom.local> <20120426093707.GE27002@newphantom.local> To: Rick van Rein X-Mailer: Apple Mail (2.1257) Cc: uri-review@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] Proposal: sip6 URI scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:32:55 -0000 26 apr 2012 kl. 11:37 skrev Rick van Rein: > Hello Olle, >=20 >> A new URI scheme doesn't make any sense, since a SIP uri can be = resolved to many different hosts using NAPTR/SRV records. >=20 > This only helps with the SIP communication -- but it gives no = certainty > about RTP. Interoperability between IPv4-only and IPv6-only relating = to > media can only be found when trying to setup a call, right? But a URI scheme doesn't help here. My softphone keeps moving between networks, some dual stack and some = not. >=20 >> A phone that is dual stack can register with two contacts, one for = each address family. ICE will take care of media handling. >=20 > There is no formal relation between the IP version used for SIP and = used > for RTP. This is what I am proposing to solve with sip6: The URI scheme is still WRONG. YOu might want to add a UA capability to = the Contact registred. That's something we should look into. Especially if you have a situation = where a server needs to decide whether to force an RTP proxy or not. According to the RFC the client should organize this itself with a TURN = server, but in reality we might need to know on the server. There's a separate SIPv6 mailing list operated by the SIP forum and a = SIPv6 forum on Facebook if you want to join the discussion there too :-) /O= From ibc@aliax.net Thu Apr 26 02:33:05 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160CD21F87E5 for ; Thu, 26 Apr 2012 02:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HACgIf7hJ7zS for ; Thu, 26 Apr 2012 02:33:04 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8018521F86E5 for ; Thu, 26 Apr 2012 02:33:04 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so849616vcb.31 for ; Thu, 26 Apr 2012 02:33:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=PDfUQB2UxYUxP/FRsvdXoXYrLlDzoYSMMz6qDBQ16gM=; b=FsrJ9lC1mKpcV8nTBT4XD+p018h3O14F0KVMSHvclQjZbRxYLYhN2r6IPV6ulSXMe+ pevYCyLRkm1O/W1Tq1922XXC5w6TfdLNzpeZqJcmLgnkbMcq9qHbmdnYz3qs8Lh7HrmQ E/qsyqLimtb51kQFhAeljk01+nvko7g27+pNYZ5/l6b7L8EvmhrWJjkMGPhU9ocBn/er lUgs9CpgLYF2DOSKY4K8vBTDJ4abzFZvg2iLiSJnT6Yo8CholejSYQXISkUGKr4cD2G6 y0rRSyYj3p9I4FKMRtnpScPqVv6KhMwp4HPhQSdrWfZoPPMwwfRmHcxzQJixZcW+Xh+H NfOQ== Received: by 10.52.91.72 with SMTP id cc8mr5589492vdb.17.1335432784013; Thu, 26 Apr 2012 02:33:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.199 with HTTP; Thu, 26 Apr 2012 02:32:43 -0700 (PDT) In-Reply-To: <20120426093707.GE27002@newphantom.local> References: <20120426092725.GC27002@newphantom.local> <20120426093707.GE27002@newphantom.local> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 26 Apr 2012 11:32:43 +0200 Message-ID: To: Rick van Rein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkrcTbQ3SvO7Nch1v/UjV9KO+ImauIafkZQkYUVJNK41wzgP6khO9VI3qnOBkYHqF5tNLBP Cc: uri-review@ietf.org, sipcore@ietf.org, "Olle E. Johansson" Subject: Re: [sipcore] Proposal: sip6 URI scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:33:05 -0000 2012/4/26 Rick van Rein : > There is no formal relation between the IP version used for SIP and used > for RTP. =C2=A0This is what I am proposing to solve with sip6: A SIP UA could just use IPv4 for signaling and IPv4 and IPv6 for media. SIP gateways usually use different address for signaling and media. --=20 I=C3=B1aki Baz Castillo From saul@ag-projects.com Thu Apr 26 02:36:32 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A982821F87D8; Thu, 26 Apr 2012 02:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] 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 oPax107vMr5c; Thu, 26 Apr 2012 02:36:32 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0AD8621F87C1; Thu, 26 Apr 2012 02:36:31 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 560ABB01C0; Thu, 26 Apr 2012 11:36:29 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id C4F84B019B; Thu, 26 Apr 2012 11:36:29 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <20120426093707.GE27002@newphantom.local> Date: Thu, 26 Apr 2012 11:36:29 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120426092725.GC27002@newphantom.local> <20120426093707.GE27002@newphantom.local> To: Rick van Rein X-Mailer: Apple Mail (2.1084) Cc: uri-review@ietf.org, sipcore@ietf.org, "Olle E. Johansson" Subject: Re: [sipcore] Proposal: sip6 URI scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 09:36:32 -0000 Hi Rick, [snip] >=20 > There is no formal relation between the IP version used for SIP and = used > for RTP. This is what I am proposing to solve with sip6: >=20 Why would you need that? If running in a dual stacked environment maybe = some firewall policy won't allow your RTP packets to go out through IPv6 = but they could go out through IPv4, ICE can pick the best path for media = regardless of signaling. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From christer.holmberg@ericsson.com Thu Apr 26 03:17:08 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9718521F871C; Thu, 26 Apr 2012 03:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.109 X-Spam-Level: X-Spam-Status: No, score=-6.109 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 vz0icsOmGv2y; Thu, 26 Apr 2012 03:17:08 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B254221F86F2; Thu, 26 Apr 2012 03:17:07 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-db-4f9920a2f334 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 04.CC.03534.2A0299F4; Thu, 26 Apr 2012 12:17:06 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 26 Apr 2012 12:17:06 +0200 From: Christer Holmberg To: Rick van Rein , "uri-review@ietf.org" , "sipcore@ietf.org" Date: Thu, 26 Apr 2012 12:17:03 +0200 Thread-Topic: [sipcore] Proposal: sip6 URI scheme Thread-Index: Ac0jja8cJzUwloUpTjKg2kzNHWWfnAAB6CYg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C441F106E@ESESSCMS0356.eemea.ericsson.se> References: <20120426092725.GC27002@newphantom.local> In-Reply-To: <20120426092725.GC27002@newphantom.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Proposal: sip6 URI scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 10:17:08 -0000 Hi, Maybe you could describe the use-case you have in mind, and what you want t= o achieve, and then we can look at possible solutions. Regards, Christer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Rick van Rein Sent: 26. huhtikuuta 2012 12:27 To: uri-review@ietf.org; sipcore@ietf.org Subject: [sipcore] Proposal: sip6 URI scheme Hello, I am developing to get better support for SIP over IPv6. One of the proble= ms that I have encountered is the interoperability between endpoints that r= un only IPv4 or IPv6. To solve this situations prior to call setup, I am p= roposing a sip6 URI scheme. Using this, end users and their tools should h= ave an easier time deciding whether or not to use the URI. A similar thing applies to enforced ZRTP --being sure before calling that t= he call will be private-- and I combined that with the URI scheme proposal,= so as not to register more URI schemes than required. Your feedback is kindly welcomed. Best wishes, Rick van Rein OpenFortress From keith.drage@alcatel-lucent.com Thu Apr 26 03:26:03 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3302821F8663 for ; Thu, 26 Apr 2012 03:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.944 X-Spam-Level: X-Spam-Status: No, score=-109.944 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, 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 zdNfkkZ4Y8aD for ; Thu, 26 Apr 2012 03:26:02 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 110EF21F8620 for ; Thu, 26 Apr 2012 03:26:01 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3QAOkoX001286 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Apr 2012 12:25:51 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 26 Apr 2012 12:25:43 +0200 From: "DRAGE, Keith (Keith)" To: "Ravindran, Parthasarathi" , "Gurbani, Vijay K (Vijay)" , Paul Kyzivat , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Thu, 26 Apr 2012 12:25:41 +0200 Thread-Topic: [sipcore] Websocket is a new transport or new URI? Thread-Index: AQHNIDOCuN/qLU9tjk656lTA6m0G85am5VEAgAD8KaCAAD8sgIABv2aw//+u7wCAAHdUgIABOZfA///CEICAAEg4AIAAFPGAgAD4/DCAAIyW8A== Message-ID: References: <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228C1B@inba-mail01.sonusnet.com> <4F9460AC.2080605@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E231B57@inba-mail01.sonusnet.com> <4F956931.7090404@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2380B2@inba-mail01.sonusnet.com> <4F969C7E.3070107@digium.com> <4F970097.5020002@alum.mit.edu> <387F9047F55E8C4285 0AD6B3A7A03C6C0E239306@inba-mail01.sonusnet.com> <5522E7CB-78FF-4582-8E39-0E8E43301650@ag-projects.com> <4F981046.6010508@alum.mit.edu> <4F9821D7.6030908@bell-labs.com> <387F9047F55E8C42850AD6B3A7A03C6C0E23A768@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E23A768@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "sipcore@ietf.org" , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Subject: Re: [sipcore] Websocket is a new transport or new URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 10:26:03 -0000 I thought RFC 5630 went a long way to explaining exactly what you got when = you specified SIPS. It is up to the reader to work out how useful it is as a result - not exact= ly a great leap. Keith -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Ravindran, Parthasarathi Sent: 26 April 2012 02:46 To: Gurbani, Vijay K (Vijay); Paul Kyzivat; I=F1aki Baz Castillo Cc: sipcore@ietf.org; Sa=FAl Ibarra Corretg=E9 Subject: Re: [sipcore] Websocket is a new transport or new URI? Vijay, Thanks for forwarding the fruitful information. Now I understand why Paul is saying that SIPS URI is a mistake in RFC 3261. The point to be noted is= =20 that there is no IETF document to clarify this. Hi all, I agree that it is better to proceed websokcet as a transport rather than=20 new URI to avoid earlier mistake now. SIPS is not deprecated for TLS over TCP as it is widely deployed. Having said that, I'm not fully convinced with SIPS usage for websocket as IMO, it is extending the mistake to the new transport as well. Knowing that it is a mistake in the base RFC 3261, it is not the right thing to be= =20 allowed for new transport introduced. Let us discuss this open item in=20 this thread or other thread. >From the TCP/IP protocol stack perspective, TLS as URI and WebSocket=20 as transport is not the right thing as it is confusing as follows. sips:alice@example.com;transport=3Dws The better approach will be=20 sip:alice@example.com;transport=3Dwss Thanks Partha >-----Original Message----- >From: Vijay K. Gurbani [mailto:vkg@bell-labs.com] >Sent: Wednesday, April 25, 2012 9:40 PM >To: Paul Kyzivat >Cc: Sa=FAl Ibarra Corretg=E9; Ravindran, Parthasarathi; sipcore@ietf.org >Subject: Re: [sipcore] Websocket is a new transport or new URI? > >On 04/25/2012 09:55 AM, Paul Kyzivat wrote: >> I agree with Sa=FAl here. I don't really understand what it is that >> Partha is proposing. >> >> As I already stated, I think sips turned out to be a mistake - that it >> doesn't provide enough of a guarantee to be able to promise anything >> to an end user. But we investigated this ad nauseum and couldn't come >> up with anything substantially better. > >Time for institutional memory, perhaps? The long discussions (May - >June 2006) on why sips failed and ideas to come up with new URI schemes >to replace it and attendant problems (upcasting URIs, downcasting URIs >without user consent, hop-by-hop semantics versus end-to-end, etc.) is >summarized in http://www.ietf.org/mail- >archive/web/sip/current/msg24047.html > >- vijay >-- >Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) >Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com >Web: http://ect.bell-labs.com/who/vkg/ _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nataraju.sip@gmail.com Thu Apr 26 03:49:19 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF0121F882C; Thu, 26 Apr 2012 03:49:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 NP3N-2pcYyWg; Thu, 26 Apr 2012 03:49:18 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE6B21F881C; Thu, 26 Apr 2012 03:49:17 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so739662lbb.31 for ; Thu, 26 Apr 2012 03:49:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Fk8HROz7Op7jRyiKrI4qwN9+35UZLbMpHz0T60xuS6M=; b=GIgGNCw/SnQVQJLIj+4xSpn0xDfTAmcrzwMCQd6qY3pNt6eAAnf0HfNFb8PM3u8z1k Vs2NDu153NV+UFWUznKQ4KxgdefnjLapdgQ2fCsrsYsRV0tUbmnZ/OZTCYSX0/TuxCyo iSM4+k/Dw1r07/PzJ/bPiL0/hsYivyWzS3/SZux3FALQLjKfs0fe/+HroEqimDXIJS3p gM03LVIU/q8HCMeNp62x0MMKay2IgpxykUA/9hbsdS44DEF/KNgTs4I9ZYsdU7A2nh7k J6RFhEXmYgdLl8LiRlLwb+QpyGx7y0FPTLr4XeRZq0h8uHBaLRXuGpXdoR7TaWcuFmou IGzw== MIME-Version: 1.0 Received: by 10.152.145.169 with SMTP id sv9mr959726lab.12.1335437356994; Thu, 26 Apr 2012 03:49:16 -0700 (PDT) Received: by 10.112.36.104 with HTTP; Thu, 26 Apr 2012 03:49:16 -0700 (PDT) In-Reply-To: <20120426093707.GE27002@newphantom.local> References: <20120426092725.GC27002@newphantom.local> <20120426093707.GE27002@newphantom.local> Date: Thu, 26 Apr 2012 16:19:16 +0530 Message-ID: From: "Nataraju A.B" To: Rick van Rein Content-Type: multipart/alternative; boundary=e89a8f23509748907904be92bd9f Cc: uri-review@ietf.org, sipcore@ietf.org, "Olle E. Johansson" Subject: Re: [sipcore] Proposal: sip6 URI scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 10:49:19 -0000 --e89a8f23509748907904be92bd9f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 26, 2012 at 3:07 PM, Rick van Rein wrote: > Hello Olle, > > > A new URI scheme doesn't make any sense, since a SIP uri can be resolved > to many different hosts using NAPTR/SRV records. > > This only helps with the SIP communication -- but it gives no certainty > about RTP. Interoperability between IPv4-only and IPv6-only relating to > media can only be found when trying to setup a call, right? > > > A phone that is dual stack can register with two contacts, one for each > address family. ICE will take care of media handling. > > There is no formal relation between the IP version used for SIP and used > for RTP. This is what I am proposing to solve with sip6: > [ABN] There is no need for any formal relation between signalling and media. if you can share your use case you can get the useful replies. Theoretically, it is acceptable to use different addressing schemes for signalling and media. AFAIK, There is no constraint to use same IP version for both media and signalling. It is very well possible to publish the IPV6 media address (in SDP) whereas IPv4 is being used for SIP signalling purposes. > > > Thanks, > -Rick > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > -- Thanks, Nataraju A.B. --e89a8f23509748907904be92bd9f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 2= 6, 2012 at 3:07 PM, Rick van Rein <rick@openfortress.nl> = wrote:
Hello Olle,

> A new URI scheme doesn't make any sense, since a SIP uri can be re= solved to many different hosts using NAPTR/SRV records.

This only helps with the SIP communication -- but it gives no certain= ty
about RTP. =A0Interoperability between IPv4-only and IPv6-only relating to<= br> media can only be found when trying to setup a call, right?

> A phone that is dual stack can register with two contacts, one for eac= h address family. ICE will take care of media handling.

There is no formal relation between the IP version used for SIP and u= sed
for RTP. =A0This is what I am proposing to solve with sip6:
=A0
[ABN] There is no need for any formal relation between = signalling and media. if you can share your use case you can get the useful= replies.

Theoretically, it is acceptable to use different addres= sing schemes for signalling and media. AFAIK, There is no constraint to use= same IP version for both media and signalling.

It is very well possible to publish the IPV6 media address (in SDP) whereas= IPv4 is being used for SIP signalling purposes.
=A0


Thanks,
=A0-Rick
___________________________________= ____________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore



--
= Thanks,
Nataraju A.B.

--e89a8f23509748907904be92bd9f-- From rick@openfortress.nl Thu Apr 26 04:08:22 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F175421F86EE; Thu, 26 Apr 2012 04:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.189 X-Spam-Level: X-Spam-Status: No, score=0.189 tagged_above=-999 required=5 tests=[AWL=0.632, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_NL=1.545] 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 mnjRYe2WvMVQ; Thu, 26 Apr 2012 04:08:19 -0700 (PDT) Received: from fame.vanrein.org (openfortress.nl [213.189.19.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9A30C21F869E; Thu, 26 Apr 2012 04:08:19 -0700 (PDT) Received: from phantom.vanrein.org (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTP id 5D6824040D1; Thu, 26 Apr 2012 12:08:14 +0100 (BST) Received: by phantom.vanrein.org (Postfix, from userid 1000) id 616722255C; Thu, 26 Apr 2012 11:16:35 +0000 (CEST) Date: Thu, 26 Apr 2012 11:16:35 +0000 From: Rick van Rein To: Christer Holmberg Message-ID: <20120426111635.GA27786@newphantom.local> References: <20120426092725.GC27002@newphantom.local> <7F2072F1E0DE894DA4B517B93C6A05852C441F106E@ESESSCMS0356.eemea.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C441F106E@ESESSCMS0356.eemea.ericsson.se> X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM User-Agent: Mutt/1.5.20 (2009-06-14) Cc: "uri-review@ietf.org" , Rick van Rein , "sipcore@ietf.org" Subject: Re: [sipcore] Proposal: sip6 URI scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 11:08:22 -0000 Hello all, Thanks for your feedback. > Maybe you could describe the use-case you have in mind, and what you want > to achieve, and then we can look at possible solutions. I am thinking of direct media connections between SIP callers, after setup of a call from ENUM entries, or perhaps freenum.org, or to one's hosted SIP proxy under a domain name, e.g. sip:rick@openfortress.nl -- these schemes are part of the promise that SIP holds for telephony over the Internet. Direct calls are ideally served with IPv6. But as long as there is no way to infer if a service is IPv6-only, there will be a practical need to support IPv4 as well, so as to avoid failed call setups due to inavailability of a caller-assumed transport. With IPv4 as an always-present fallback, there is no real reason to implement IPv6 as well. Specifically, for IPv6 as the connecting protocol between the caller's side and the callee's side. Everyone is waiting for everyone else. IPv6 however, is very useful for direct calls over the Internet, as it has no problems with NAT (only with firewalls, which is easily solved) and so it never requires an RTP proxy. RTP proxies are potentially problematic for a number of reasons: - efficiency: RTP traffic may pass through more hops than needed - quality: Call quality may suffer from extra media indirections - complexity: setting up a private RTP proxy is not straightforward - freedom: most end-users will be dependent on an external party's RTP proxy - facilities: external RTP proxies may not support all media wishes (think of high-bandwidth video or the deaf's realtime-text protocol) - privacy: external RTP proxies are often regulated into tapping phone calls Having a separate indication of SIP over IPv6 clearly states the opposite situation; there is no need to attempt IPv4 on setups, and so it makes no sense to use such URIs on any implementation but an IPv6-capable one. This may include tools that setup IPv6 over a tunnel to create the call. Please note that nothing prohibits proxies to handle both sip6: and sip: URIs, and perhaps translate them to each other's format. The only thing that would be required, is that such a proxy would use IPv6 only on the sip6: side, so it may end up being an RTP proxy as well -- but only for the local end, where a peer has not implemented SIP over IPv6 yet. The lookup of a sip6: party is an IPv6-only process, which means that the default has shifted from SIP over IPv4 to SIP over IPv6, whenever possible. A new URI scheme is not the only way to accomplish this; in fact, anything in the syntax of a sip: URI would do it. The reason why I proposed a URI scheme is that it works well in browsers etc. that generally choose a handler application based on the URI scheme; it would not start a sip: handler if it failed to recognise a ?transport=udp-ipv6 annotation, and it could usually be configured to start a different handler for sip6: without knowing anything about the SIP protocol (a protocol handler could register for handling the sip6: URI and another could register for the sip: URI, in case of a mobile platform). These are pragmatic considerations only, but they made me wish for a URI scheme. FWIW, I've engineered beta-level solutions that make it possible in all common usecases to use SIP over IPv6, and IPv6 alone. Information on that can be found on http://devel.0cpm.org/ -- mostly work in progress. Thanks to all for your feedback, Best wishes, Rick van Rein OpenFortress From pkyzivat@alum.mit.edu Thu Apr 26 07:37:57 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB5121E8043 for ; Thu, 26 Apr 2012 07:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.445 X-Spam-Level: X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 o12vzETkdnBc for ; Thu, 26 Apr 2012 07:37:56 -0700 (PDT) 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 8537F21F8646 for ; Thu, 26 Apr 2012 07:37:56 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta13.westchester.pa.mail.comcast.net with comcast id 2e2o1j00617dt5G5DedxpZ; Thu, 26 Apr 2012 14:37:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta13.westchester.pa.mail.comcast.net with comcast id 2edx1j02b07duvL3ZedxQS; Thu, 26 Apr 2012 14:37:58 +0000 Message-ID: <4F995DC2.30203@alum.mit.edu> Date: Thu, 26 Apr 2012 10:37:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C441F0EF7@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C441F0EF7@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 14:37:57 -0000 Christer, I *think* this sounds right. But I'm not certain in the case of outbound. It seems like it might depend on the particulars of the feature. I say this because features are still so fuzzy. In some cases it might be that the behavior of the feature is coupled to the flow. In others it might not. Perhaps if I understood proxy-features better I wouldn't have that doubt. Thanks, Paul On 4/26/12 3:57 AM, Christer Holmberg wrote: > Hi Paul, > > Some thinking on the contact issue. > >>>>> Section 5.3.3 says: >>>>> >>>>> If a SIP feature cap is inserted in a Feature-Caps header field of a >>>>> SIP REGISTER request, or within a response of such request, it >>>>> indicates to the receivers of the request (or response) that the >>>>> feature associated with the SIP feature cap is supported for the >>>>> duration of the registration, and for all SIP transactions associated >>>>> with the registration, until the registration is re-freshed or >>>>> terminated. >>>>> >>>>> There are some cases we need to discuss here. When a UA sends a REGISTER request, it could have no contacts, one contact, or several. What do the feature caps mean in these cases? >>>>> >>>>> - if there are no contacts in the register, are feature-caps irrelevant? >>>>> - if there is more than one contact in the register, do the feature-caps >>>>> apply to all of them? >>>>> >>>>> Then the response should contain all the registered contacts, not >>>>> just those mentioned in the request. So do the feature caps mentioned in the reply apply until the last of those contacts expire? Or should the requester assume they only apply until *its* contacts expire? >>>>> >>>>> Unless a SIP feature cap is inserted in a Feature-Caps header field >>>>> or a re-registration, or within a response of such request, it >>>>> indicates to the receivers of the request (or response) that the >>>>> feature is no long supported for the registration. >>>>> >>>>> Suppose a UA registers with a contact and some feature caps. Then later it sends a register poll (register with no contacts). Can I assume that this will not affect the feature caps associated with the registered contact? >>>> >>>> It's up to the entities that previously inserted the feature-caps to decide whether they will continue to indicate support when they receive a re-registration request/response - no matter whether it's a poll, addition of contacts etc. >>>> >>>> Personally I see no reason why they should *not* insert the same feature-caps in a pure poll request/response, but we should allow for cases where the feature is no longer supported when the poll request/response is received. >>> >>> I think you missed my point. Its really the same point as my question >>> of what it means to put feature caps into a polling register. >>> >>> Since you want the registrar to consider the received feature caps to >>> be stateful for the duration of the register, I want to know what >>> that state is attached to. ISTM that it must be attached to >>> particular contacts. Then, a polling register would presumably not >>> update the state of any registered contact since it doesn't update any of them. >>> >>> On the flip side of that, if the registrar returns feature caps, what >>> does the recipient attach that state to? The only thing it could >>> attach it to that has a lifetime is the registration of a particular >>> contact, since the registered contacts can expire independently. >> >> Ok, I think I understand. I need to think a little about it. > > My suggestion would be: > > - When outbound is *not* used, if support of feature F9 is indicated when contact C1 is registered, the feature is supported until C1 expires, is explicitly removed, or explicitly refreshed. > > - When outbound *is* used, the same as above applies, but only for the specific C1 registration flow for which support of F9 has been indicated. > > Example: If I register C1, using two outbound flows (O1 and O2), and support of F9 is indicated for O1, when O1 is expired/removed/refreshed F9 is no longer supported. > > - Whenever a contact is explicitly refreshed, entities MUST insert Feature-Caps if they still want to indicate support of the feature. > > - For pure poll messages, where the REGISTER request does *not* contain a contact, my suggestion is that we say that the document does not define any semantics for usage of Feature-Caps in such requests/responses. If no semantics is defined, poll messages will not have any impact on previously indicated support of features, and entities MUST NOT insert a Feature-Caps header field in such requests, or their associated responses. > > > How does that sound? :) > > > Regards, > > Christer > > > > > > > From christer.holmberg@ericsson.com Thu Apr 26 09:31:31 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1711821F86D9 for ; Thu, 26 Apr 2012 09:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.113 X-Spam-Level: X-Spam-Status: No, score=-6.113 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 qW4uhCQNTPmr for ; Thu, 26 Apr 2012 09:31:30 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id DBDBF21F86C6 for ; Thu, 26 Apr 2012 09:31:29 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-85-4f99785fa2c6 Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 74.69.26681.068799F4; Thu, 26 Apr 2012 18:31:28 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 26 Apr 2012 18:31:27 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Thu, 26 Apr 2012 18:31:26 +0200 Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01 Thread-Index: Ac0juiulmkmWaHUySMi+K8dP1ApT0wADjtZn Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4400131F@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C441F0EF7@ESESSCMS0356.eemea.ericsson.se>, <4F995DC2.30203@alum.mit.edu> In-Reply-To: <4F995DC2.30203@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-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 16:31:31 -0000 Hi, > I *think* this sounds right. > > But I'm not certain in the case of outbound. It seems like it might > depend on the particulars of the feature. I say this because features > are still so fuzzy. In some cases it might be that the behavior of the > feature is coupled to the flow. In others it might not. Perhaps if I > understood proxy-features better I wouldn't have that doubt. I don't think that a feature, explicitly indicated for flow O1, can be impl= icitly applied also for O2. The support has to be explicitly indicated on e= ach flow for which it applies. Because, O2 may not even traverse the entity which indicates the support of= the feature for O1, which means that when O2 is refreshed there will be no= support indication - which would mean that the feature is no longer suppor= ted (at least not until O1 is refreshed, and the indication might be added = again...). (Probably that could be fixed, e.g. by saying that only the flow where supp= ort has been indicated can later refresh/remove that support. But, I think = that would be too messy, e.g. if that flow expires etc.) So, my suggestion would be that the support is indicated per flow. That's h= ow it works in the 3GPP, where support is sometimes indicated based on the = type of access network associated with a flow. Regards, Christer On 4/26/12 3:57 AM, Christer Holmberg wrote: > Hi Paul, > > Some thinking on the contact issue. > >>>>> Section 5.3.3 says: >>>>> >>>>> If a SIP feature cap is inserted in a Feature-Caps header field= of a >>>>> SIP REGISTER request, or within a response of such request, it >>>>> indicates to the receivers of the request (or response) that th= e >>>>> feature associated with the SIP feature cap is supported for th= e >>>>> duration of the registration, and for all SIP transactions asso= ciated >>>>> with the registration, until the registration is re-freshed or >>>>> terminated. >>>>> >>>>> There are some cases we need to discuss here. When a UA sends a REGIS= TER request, it could have no contacts, one contact, or several. What do th= e feature caps mean in these cases? >>>>> >>>>> - if there are no contacts in the register, are feature-caps irreleva= nt? >>>>> - if there is more than one contact in the register, do the feature-c= aps >>>>> apply to all of them? >>>>> >>>>> Then the response should contain all the registered contacts, not >>>>> just those mentioned in the request. So do the feature caps mentioned= in the reply apply until the last of those contacts expire? Or should the = requester assume they only apply until *its* contacts expire? >>>>> >>>>> Unless a SIP feature cap is inserted in a Feature-Caps header f= ield >>>>> or a re-registration, or within a response of such request, it >>>>> indicates to the receivers of the request (or response) that th= e >>>>> feature is no long supported for the registration. >>>>> >>>>> Suppose a UA registers with a contact and some feature caps. Then lat= er it sends a register poll (register with no contacts). Can I assume that = this will not affect the feature caps associated with the registered contac= t? >>>> >>>> It's up to the entities that previously inserted the feature-caps to d= ecide whether they will continue to indicate support when they receive a re= -registration request/response - no matter whether it's a poll, addition of= contacts etc. >>>> >>>> Personally I see no reason why they should *not* insert the same featu= re-caps in a pure poll request/response, but we should allow for cases wher= e the feature is no longer supported when the poll request/response is rece= ived. >>> >>> I think you missed my point. Its really the same point as my question >>> of what it means to put feature caps into a polling register. >>> >>> Since you want the registrar to consider the received feature caps to >>> be stateful for the duration of the register, I want to know what >>> that state is attached to. ISTM that it must be attached to >>> particular contacts. Then, a polling register would presumably not >>> update the state of any registered contact since it doesn't update any = of them. >>> >>> On the flip side of that, if the registrar returns feature caps, what >>> does the recipient attach that state to? The only thing it could >>> attach it to that has a lifetime is the registration of a particular >>> contact, since the registered contacts can expire independently. >> >> Ok, I think I understand. I need to think a little about it. > > My suggestion would be: > > - When outbound is *not* used, if support of feature F9 is indicated when= contact C1 is registered, the feature is supported until C1 expires, is ex= plicitly removed, or explicitly refreshed. > > - When outbound *is* used, the same as above applies, but only for the sp= ecific C1 registration flow for which support of F9 has been indicated. > > Example: If I register C1, using two outbound flows (O1 and O2), an= d support of F9 is indicated for O1, when O1 is expired/removed/refreshed F= 9 is no longer supported. > > - Whenever a contact is explicitly refreshed, entities MUST insert Featur= e-Caps if they still want to indicate support of the feature. > > - For pure poll messages, where the REGISTER request does *not* contain a= contact, my suggestion is that we say that the document does not define an= y semantics for usage of Feature-Caps in such requests/responses. If no sem= antics is defined, poll messages will not have any impact on previously ind= icated support of features, and entities MUST NOT insert a Feature-Caps hea= der field in such requests, or their associated responses. > > > How does that sound? :) > > > Regards, > > Christer > > > > > > >= From pkyzivat@alum.mit.edu Thu Apr 26 09:46:44 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2126111E809D for ; Thu, 26 Apr 2012 09:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.151, 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 RCmNfbNFMfdQ for ; Thu, 26 Apr 2012 09:46:43 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8A421E808B for ; Thu, 26 Apr 2012 09:46:42 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 2gX51j0050bG4ec5Bgmdta; Thu, 26 Apr 2012 16:46:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta03.westchester.pa.mail.comcast.net with comcast id 2gmY1j00E07duvL3PgmYva; Thu, 26 Apr 2012 16:46:32 +0000 Message-ID: <4F997BEB.5000309@alum.mit.edu> Date: Thu, 26 Apr 2012 12:46:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852C441F0EF7@ESESSCMS0356.eemea.ericsson.se>, <4F995DC2.30203@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C4400131F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4400131F@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-proxy-feature-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Apr 2012 16:46:44 -0000 OK. Thanks, Paul On 4/26/12 12:31 PM, Christer Holmberg wrote: > Hi, > >> I *think* this sounds right. >> >> But I'm not certain in the case of outbound. It seems like it might >> depend on the particulars of the feature. I say this because features >> are still so fuzzy. In some cases it might be that the behavior of the >> feature is coupled to the flow. In others it might not. Perhaps if I >> understood proxy-features better I wouldn't have that doubt. > > I don't think that a feature, explicitly indicated for flow O1, can be implicitly applied also for O2. The support has to be explicitly indicated on each flow for which it applies. > > Because, O2 may not even traverse the entity which indicates the support of the feature for O1, which means that when O2 is refreshed there will be no support indication - which would mean that the feature is no longer supported (at least not until O1 is refreshed, and the indication might be added again...). > > (Probably that could be fixed, e.g. by saying that only the flow where support has been indicated can later refresh/remove that support. But, I think that would be too messy, e.g. if that flow expires etc.) > > So, my suggestion would be that the support is indicated per flow. That's how it works in the 3GPP, where support is sometimes indicated based on the type of access network associated with a flow. > > Regards, > > Christer > > > > > > > On 4/26/12 3:57 AM, Christer Holmberg wrote: >> Hi Paul, >> >> Some thinking on the contact issue. >> >>>>>> Section 5.3.3 says: >>>>>> >>>>>> If a SIP feature cap is inserted in a Feature-Caps header field of a >>>>>> SIP REGISTER request, or within a response of such request, it >>>>>> indicates to the receivers of the request (or response) that the >>>>>> feature associated with the SIP feature cap is supported for the >>>>>> duration of the registration, and for all SIP transactions associated >>>>>> with the registration, until the registration is re-freshed or >>>>>> terminated. >>>>>> >>>>>> There are some cases we need to discuss here. When a UA sends a REGISTER request, it could have no contacts, one contact, or several. What do the feature caps mean in these cases? >>>>>> >>>>>> - if there are no contacts in the register, are feature-caps irrelevant? >>>>>> - if there is more than one contact in the register, do the feature-caps >>>>>> apply to all of them? >>>>>> >>>>>> Then the response should contain all the registered contacts, not >>>>>> just those mentioned in the request. So do the feature caps mentioned in the reply apply until the last of those contacts expire? Or should the requester assume they only apply until *its* contacts expire? >>>>>> >>>>>> Unless a SIP feature cap is inserted in a Feature-Caps header field >>>>>> or a re-registration, or within a response of such request, it >>>>>> indicates to the receivers of the request (or response) that the >>>>>> feature is no long supported for the registration. >>>>>> >>>>>> Suppose a UA registers with a contact and some feature caps. Then later it sends a register poll (register with no contacts). Can I assume that this will not affect the feature caps associated with the registered contact? >>>>> >>>>> It's up to the entities that previously inserted the feature-caps to decide whether they will continue to indicate support when they receive a re-registration request/response - no matter whether it's a poll, addition of contacts etc. >>>>> >>>>> Personally I see no reason why they should *not* insert the same feature-caps in a pure poll request/response, but we should allow for cases where the feature is no longer supported when the poll request/response is received. >>>> >>>> I think you missed my point. Its really the same point as my question >>>> of what it means to put feature caps into a polling register. >>>> >>>> Since you want the registrar to consider the received feature caps to >>>> be stateful for the duration of the register, I want to know what >>>> that state is attached to. ISTM that it must be attached to >>>> particular contacts. Then, a polling register would presumably not >>>> update the state of any registered contact since it doesn't update any of them. >>>> >>>> On the flip side of that, if the registrar returns feature caps, what >>>> does the recipient attach that state to? The only thing it could >>>> attach it to that has a lifetime is the registration of a particular >>>> contact, since the registered contacts can expire independently. >>> >>> Ok, I think I understand. I need to think a little about it. >> >> My suggestion would be: >> >> - When outbound is *not* used, if support of feature F9 is indicated when contact C1 is registered, the feature is supported until C1 expires, is explicitly removed, or explicitly refreshed. >> >> - When outbound *is* used, the same as above applies, but only for the specific C1 registration flow for which support of F9 has been indicated. >> >> Example: If I register C1, using two outbound flows (O1 and O2), and support of F9 is indicated for O1, when O1 is expired/removed/refreshed F9 is no longer supported. >> >> - Whenever a contact is explicitly refreshed, entities MUST insert Feature-Caps if they still want to indicate support of the feature. >> >> - For pure poll messages, where the REGISTER request does *not* contain a contact, my suggestion is that we say that the document does not define any semantics for usage of Feature-Caps in such requests/responses. If no semantics is defined, poll messages will not have any impact on previously indicated support of features, and entities MUST NOT insert a Feature-Caps header field in such requests, or their associated responses. >> >> >> How does that sound? :) >> >> >> Regards, >> >> Christer >> >> >> >> >> >> >> From dwing@cisco.com Thu Apr 26 17:47:26 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA2021F8796; Thu, 26 Apr 2012 17:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.759 X-Spam-Level: X-Spam-Status: No, score=-109.759 tagged_above=-999 required=5 tests=[AWL=0.840, 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 eQvcDaiERCcL; Thu, 26 Apr 2012 17:47:25 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFB621F8794; Thu, 26 Apr 2012 17:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1672; q=dns/txt; s=iport; t=1335487645; x=1336697245; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=8fWJG2Lw4Nr1xFfeMltKn0xfLthnkF03m+7WA7pdJl4=; b=QXpZ4fZdVGIZmM46f1LryL0gMb+NQs8jyj3k6ShrezCU2/Z0Kg0qima9 +s6gzNagSPWipJpHRFZLYMllSCaG6qRoiLODLmKUpoI5TaL2Ocy3vcNzp 29tM8pYFnCDbsN0XOaNBE4hEp5e+krl1Y0G+bgU+LRra5Ar7Ip5J7vH9c A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFADPsmU+rRDoH/2dsb2JhbABFoVGQI4EHggkBAQEECAoBFxBLAQMCCQ8CBAEBKAcZIwoJCAEBBAESCxeHagybWaAckT4EiGOFFokVjUaBaYMI X-IronPort-AV: E=Sophos;i="4.75,489,1330905600"; d="scan'208";a="42273731" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 27 Apr 2012 00:47:07 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q3R0l6ae026410; Fri, 27 Apr 2012 00:47:07 GMT From: "Dan Wing" To: "'Rick van Rein'" , , References: <20120426092725.GC27002@newphantom.local> In-Reply-To: <20120426092725.GC27002@newphantom.local> Date: Thu, 26 Apr 2012 17:47:06 -0700 Message-ID: <0d9801cd240f$456579c0$d0306d40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0jjaNCT9EjXWBlQmqg/w7aKj3zBAAgSOjA Content-Language: en-us Subject: Re: [sipcore] Proposal: sip6 URI scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 00:47:26 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Rick van Rein > Sent: Thursday, April 26, 2012 2:27 AM > To: uri-review@ietf.org; sipcore@ietf.org > Subject: [sipcore] Proposal: sip6 URI scheme > > Hello, > > I am developing to get better support for SIP over IPv6. One of the > problems that I have encountered is the interoperability between > endpoints that run only IPv4 or IPv6. To solve this situations prior > to call setup, I am proposing a sip6 URI scheme. Using this, end users > and their tools should have an easier time deciding whether or not to > use the URI. > > A similar thing applies to enforced ZRTP --being sure before calling > that the call will be private-- and I combined that with the URI scheme > proposal, so as not to register more URI schemes than required. > > Your feedback is kindly welcomed. It's a layering violation, and -- worse -- will cause far more harm than it could possibly help. Please don't do this. http://tools.ietf.org/html/rfc6157 describes how SIP is expected to support IPv6, and transition from IPv4-only to dual-stack to IPv6-only with the least amount of harm. It works over NAT64 and NAT46, too (SIP6, if deployed, can't), and NAT64 will be necessary for IPv6-only endpoints to access IPv4-only endpoints, such as being deployed by T-Mobile USA's IPv6-only service, Swisscom's IPv6-only trial, and probably other mobile operators and, some day, eventually wireline operators. If RFC6157 fails, which is why you are proposing SIP6, you need to back up and explain to everybody the failure of RFC6157. -d From rick@openfortress.nl Thu Apr 26 22:21:13 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3954E21F8615; Thu, 26 Apr 2012 22:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.828 X-Spam-Level: X-Spam-Status: No, score=0.828 tagged_above=-999 required=5 tests=[AWL=-0.218, BAYES_05=-1.11, HELO_MISMATCH_ORG=0.611, HOST_EQ_NL=1.545] 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 20D7rIMDF2dH; Thu, 26 Apr 2012 22:21:12 -0700 (PDT) Received: from fame.vanrein.org (openfortress.nl [213.189.19.244]) by ietfa.amsl.com (Postfix) with ESMTP id 9A17E21F861B; Thu, 26 Apr 2012 22:21:12 -0700 (PDT) Received: from phantom.vanrein.org (phantom.vanrein.org [83.161.146.46]) by fame.vanrein.org (Postfix) with ESMTP id 4CA8A4040D1; Fri, 27 Apr 2012 06:21:09 +0100 (BST) Received: by phantom.vanrein.org (Postfix, from userid 1000) id EA9E92255C; Fri, 27 Apr 2012 05:29:33 +0000 (CEST) Date: Fri, 27 Apr 2012 05:29:33 +0000 From: Rick van Rein To: Dan Wing Message-ID: <20120427052933.GA31576@newphantom.local> References: <20120426092725.GC27002@newphantom.local> <0d9801cd240f$456579c0$d0306d40$@com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0d9801cd240f$456579c0$d0306d40$@com> X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM User-Agent: Mutt/1.5.20 (2009-06-14) Cc: uri-review@ietf.org, 'Rick van Rein' , sipcore@ietf.org Subject: Re: [sipcore] Proposal: sip6 URI scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 05:21:13 -0000 Hello, > > Your feedback is kindly welcomed. > > It's a layering violation, and -- worse -- will cause far more harm > than it could possibly help. Please don't do this. Thanks all for looking into this proposal. It is clear that it will not gain wide acceptance, and should not be taken any further. I'm withdrawing the proposal. Best wishes, -Rick From nataraju.sip@gmail.com Fri Apr 27 01:39:23 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C55021F86DB for ; Fri, 27 Apr 2012 01:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 7gGiMOOCbxTN for ; Fri, 27 Apr 2012 01:39:22 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA3821F8634 for ; Fri, 27 Apr 2012 01:39:21 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so357711lbb.31 for ; Fri, 27 Apr 2012 01:39:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=r7eBfYLE/+abKAyVOPKlH2vWpXbPd2rtxjXKKUQmhx8=; b=rC9uhNORgEjxqCPq/kAnSfy5LnX8f5Y02KEEqf6JWMMBLB6AsZ6DG4dahNkcCgGngJ s+6d0fHnrZxHtGQjm4zwqpKYQDrdwUJSK3y5pMQtmde3tlDkD0ImMdlU/Y2jbxUNYq4k bK/orOj56+0VuuzXheWs5lNLQdeHmVtuizom7Eo98FgjH/Z7K28juFmlVfcYpg5lwADF 7TacKLVyNVU7mJvUbrrYtcrU8mOwHWF4p361NQLhvjZs+W+smCXP92lkLmPXJrfPam4M KR9xhE7TcR3IZN2yfmNxiDgx3ncl/cGshUMK/K6Q2u67asy7ZpZ78XUsekA17M1SvBM/ CiBQ== MIME-Version: 1.0 Received: by 10.112.8.5 with SMTP id n5mr4969217lba.48.1335515960992; Fri, 27 Apr 2012 01:39:20 -0700 (PDT) Received: by 10.112.36.104 with HTTP; Fri, 27 Apr 2012 01:39:20 -0700 (PDT) Date: Fri, 27 Apr 2012 14:09:20 +0530 Message-ID: From: "Nataraju A.B" To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: multipart/alternative; boundary=90e6ba30952a72651f04bea50a10 Subject: [sipcore] RFC 6455 - conflicting statements X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 08:39:23 -0000 --90e6ba30952a72651f04bea50a10 Content-Type: text/plain; charset=ISO-8859-1 Hi All, Following is the snippet from the RFC6455. 2. Conformance Requirements All diagrams, examples, and notes in this specification are non- normative, as are all sections explicitly marked non-normative. *Everything *else in this specification is normative. 1.9. Subprotocols Using the WebSocket Protocol _This section is non-normative._ The client can request that the server use a specific subprotocol by including the |Sec-WebSocket-Protocol| field in its handshake. If it is specified, the server needs to include the same field and one of the selected subprotocol values in its response for the connection to be established. 3. WebSocket URIs This specification defines two URI schemes, using the ABNF syntax defined in RFC 5234 [RFC5234], and terminology and ABNF productions defined by the URI specification RFC 3986 [RFC3986]. ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ] wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ] host = port = path = query = *Comment*: According to statement in sec 2, section 3 - WebSocket URIs (for example) is normative. But I don't think that it correct. Section 3, similarly sec 4, 5, 6, 7, 8 must be changed as non-normative text. Am I missing something here in basic understanding ??? Thanks, Nataraju A.B. --90e6ba30952a72651f04bea50a10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi All,

Following is the snippet from the RFC6455.

=
<RFC6455>
2.  Conformance Requir=
ements

   All diagrams, examples, and notes in this specification are non-
   normative, as are all sections explicitly marked non-normative.
   Everything else in this specification is normative.=


1.9.  Sub=
protocols Using the WebSocket Protocol

   _This section is non-normative._

   The client can request that the server use a specific subprotocol by
   including the |Sec-WebSocket-Protocol| field in its handshake.  If it
   is specified, the server needs to include the same field and one of
   the selected subprotocol values in its response for the connection to
   be established.

3.  WebSo=
cket URIs

   This specification defines two URI schemes, using the ABNF syntax
   defined in RFC 5234 [RFC5234], and terminology and ABNF productions
   defined by the URI specification RFC 3986 [RFC3986].

          ws-URI =3D "ws:" "//" host [ ":" po=
rt ] path [ "?" query ]
          wss-URI =3D "wss:" "//" host [ ":" =
port ] path [ "?" query ]

          host =3D <host, defined in [RFC3986], Section 3.2.2>
          port =3D <port, defined in [RFC3986], Section 3.2.3>
          path =3D <path-abempty, defined in [RFC3986], Section 3.3>
          query =3D <query, defined in [RFC3986], Section 3.4>
</RFC6455>

Comment: According to statement in sec 2= , section 3 -=A0WebSocket URIs (for example= )=A0is normative. But I don't think that it correct.=A0Section 3, similarly sec 4, 5, 6, 7, 8 must be changed as non-normati= ve text.

Am I missing something here in basic understanding ???
Thanks,
Nataraju A.B.
--90e6ba30952a72651f04bea50a10-- From ibc@aliax.net Fri Apr 27 01:50:22 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863C521F8716 for ; Fri, 27 Apr 2012 01:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, 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 fMkTmXTP4HXm for ; Fri, 27 Apr 2012 01:50:20 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 72AAC21F8623 for ; Fri, 27 Apr 2012 01:50:20 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so420808vcb.31 for ; Fri, 27 Apr 2012 01:50:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=9+7kX08yjTQEF8tG1X3tuHzsGG8EHLeKDecCuhAwT7o=; b=MbweWE8i2qqvpnCTUtxkQIvTsBLZRJzq0XMNER9rBs15h8HGNYris181k7AEC6Ikbt raKz7XrT1sVky+o8CZq3nkG1jf/O0bkTpHNvdnn1JEqtR3S8++Ttp5M59XHXwLKfECXQ brKaYfbPTNis7VLs3o/TQSTxqQYIIPrLfVCNA7mI8XpbzWJycv0xXGU7vGBYY7ZIFtMq ZtbUBclBBVPPwRI/hWXeTU6Ya+dqEo2THiK28SXWM935Equ9Nrxux4AfGNRBO6ZsFqNx Vccy+wUzsjNzNBEOHHTimjyPVtxmxcKe+2FI7YS+GsQ0hE97/UM6nCYOPTMdEfFaEAEV jEiA== Received: by 10.220.157.18 with SMTP id z18mr772009vcw.2.1335516619873; Fri, 27 Apr 2012 01:50:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.199 with HTTP; Fri, 27 Apr 2012 01:49:59 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 27 Apr 2012 10:49:59 +0200 Message-ID: To: "Nataraju A.B" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmRHejkyxOmNIB8WBD/3GJluEOyBibQqgf3URkY1qZSs+4iP376sWFFyESS0OlF7SQZcrPs Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] RFC 6455 - conflicting statements X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 08:50:22 -0000 2012/4/27 Nataraju A.B : > Comment: According to statement in sec 2, section 3 -=C2=A0WebSocket URIs= (for > example)=C2=A0is normative. But I don't think that it correct.=C2=A0Secti= on 3, > similarly sec 4, 5, 6, 7, 8 must be changed as non-normative text. > > Am I missing something here in basic understanding ??? Nataraju, RFC 6455 belongs to HYBI Working Group, and not to SIPCORE WG. Anyhow, it's too late to fix/improve an already published RFC, so I suggest you to report an issue in the IETF tracker for RFC 6455. Regards. --=20 I=C3=B1aki Baz Castillo From nataraju.sip@gmail.com Fri Apr 27 01:55:40 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F7E21F874C for ; Fri, 27 Apr 2012 01:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[AWL=0.504, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 JnHbQfD9LNGO for ; Fri, 27 Apr 2012 01:55:39 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id E469021F8748 for ; Fri, 27 Apr 2012 01:55:38 -0700 (PDT) Received: by lagj5 with SMTP id j5so368498lag.31 for ; Fri, 27 Apr 2012 01:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=C57LyzEUWyS4tgz/CEPPat/qvLxAJDJaOHbyiNdOFA8=; b=ZKoCURMBCdToyHIgVIOv3kImGBug5G5B/Q+ryUJ6wjr7PDKmMt86t3o6x1wdvUDw57 TJbld5p/xOzXNPiK4AtZkvFu6cEp7po3HQYMwUgDe6b1ofMaTxaWQi7EzTr7NDd49iqu LeaV0ibuBn/2Dr+8kZbxVpKwTeVLxMSZRePOhkAtE+Hmne1PrENDab0cI/OdjMEcrFB8 V8ReMZ/gwUtTeEXtgumiF1hJhZ007ywUfrGxUpDu5pmtvnRJj2rOtkAHOkfgib1N0eJj ZjE2VVXlTh//wVeDZLClkjTUI9OKLtEv+vN9QfCRfTWOZRu3BMvNaYgLAdXQE5yfWEqc fl1w== MIME-Version: 1.0 Received: by 10.152.111.41 with SMTP id if9mr9586342lab.19.1335516937058; Fri, 27 Apr 2012 01:55:37 -0700 (PDT) Received: by 10.112.36.104 with HTTP; Fri, 27 Apr 2012 01:55:37 -0700 (PDT) Date: Fri, 27 Apr 2012 14:25:37 +0530 Message-ID: From: "Nataraju A.B" To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: multipart/alternative; boundary=f46d040715299ffa1304bea544ca Subject: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - editorial comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 08:55:40 -0000 --f46d040715299ffa1304bea544ca Content-Type: text/plain; charset=ISO-8859-1 Hi All, Following is the snippet of text from rfc6455 and "draft-ibc-sipcore-sip-websocket-02.txt". 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Conformance Requirements All diagrams, examples, and notes in this specification are non- normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Usage of text "_This section is non-normative._" will not convey same meaning in both the documents. Please add the first paragraph of sec.2,rfc6455 to sec.2 of this draft. Otherwise the draft would be confusing about usage of the text "_This section is non-normative._" I know this is minor comment, but required to make the draft clearer. Thanks, *Nataraju A.B.* --f46d040715299ffa1304bea544ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi A= ll,

Following is the snippet of text from rfc6455 and= "draft-ibc-sipcore-sip-websocket-02.txt".

=
<draft-ibc-sipcore-sip-websocket-02.txt>=A0
2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED&quo=
t;, "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", &qu=
ot;MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].
<draft-ibc-sipcore-sip-websocket-02.txt>

<rfc6455>
2.  Confo=
rmance Requirements

   All diagrams, examples, and notes in this specification are non-
   normative, as are all sections explicitly marked non-normative.
   Everything else in this specification is normative.

   The key words "MUST", "MUST NOT", "REQUIRED&quo=
t;, "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", &qu=
ot;MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].
</rfc6455>

Usage of text "_This section is non-normative._" will not convey same mean= ing in both the documents.

=
Please add the first paragraph of sec.2,rfc6455 to sec.2 of this d= raft. Otherwise the draft would be confusing about usage of the text "= _This section is non-normative._"=

I know this is minor comment, but required to make the draft= clearer.

Thanks,=
= Nataraju A.B.

--f46d040715299ffa1304bea544ca-- From ibc@aliax.net Fri Apr 27 02:21:29 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A460221F870E for ; Fri, 27 Apr 2012 02:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.044, 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 33isXVlIMoa8 for ; Fri, 27 Apr 2012 02:21:29 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2684421F86F6 for ; Fri, 27 Apr 2012 02:21:29 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so435335vbb.31 for ; Fri, 27 Apr 2012 02:21:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=rlBujQADWeKo94fPSu+op3oM71X11iXQWnzhFotndWw=; b=BDdtNwyHqHLFNRSTQY6xhmlBmzJ7iG4b31CuPjsh1D9LrCnloOYgGmJ1ZdwdQjoNRo Bo3lzl3eA98v1AuWfDWiNhciY+rpK1U6rpv4ZL4gSCjn//dr+vsZp+0k9K6Z4MaPhXYu lpw52liNoAv7zSpJx9xz99Bc30kRDdGgFaVcRRGOWuhh/ugm1WVOWI1cMZw5bek9AAu9 yqhxte3H+1HKRXwPEFQirZtl3DJU/GvENO74HKUswQ6rsrODM9DidoZLmry0vgCczvMZ 1O+FL5VktjFoT7y+iZCOuob+R11LlJ1HjSLLDCJTc3+0IzDH4iaCrQan4zDHRizV0a0n t/RQ== Received: by 10.52.91.72 with SMTP id cc8mr9567316vdb.17.1335518488566; Fri, 27 Apr 2012 02:21:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.199 with HTTP; Fri, 27 Apr 2012 02:21:08 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 27 Apr 2012 11:21:08 +0200 Message-ID: To: "Nataraju A.B" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnH0r7T9cjFIwZBI0L5cn+ImU+yVuiI3H2aRjtRV3TjTAAk+1RuKUTtjwT+JW1vfsUmX3SS Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - editorial comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 09:21:29 -0000 2012/4/27 Nataraju A.B : > Usage of text "_This section is non-normative._" will not convey same > meaning in both the documents. > > Please add the first paragraph of sec.2,rfc6455 to sec.2 of this draft. > Otherwise the draft would be confusing about usage of the text "_This > section is non-normative._" > > I know this is minor comment, but required to make the draft clearer. Hi Nataraju, we will add it in next revision of the draft. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From dwing@cisco.com Fri Apr 27 07:50:40 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F4021F86E8; Fri, 27 Apr 2012 07:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.899 X-Spam-Level: X-Spam-Status: No, score=-109.899 tagged_above=-999 required=5 tests=[AWL=0.700, 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 xrcO9wr1mSMV; Fri, 27 Apr 2012 07:50:39 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C6B0B21F86E4; Fri, 27 Apr 2012 07:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=1005; q=dns/txt; s=iport; t=1335538240; x=1336747840; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=S0IMkFRaj6x4gCW7DbfiSuiuiY+VW0cwbRSxyLRyB6A=; b=a4e+GaBWlsn8gZ4lqbf6aRx4st7doODo/BDy4U785wDolWDwa5/teVAl x8hYESGRbGa2riH49evzv+wjTSErMYZQEOJr2gDpryuj6vpK7f21b9cSy DdF5hRMyQ7P7PQp4h4oNmBIJb6YVokvoLXz+EeinGenuhvf+EGg+gZV4V U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAJmxmk+rRDoI/2dsb2JhbABEoVeQE4EHggkBAQEECAoBFxAyCgMMAQMCCQ8CBAEBKAcZIwoJCAEBBBMLF4dqnEugMpFDBIhjhRaWW4Fpgwg X-IronPort-AV: E=Sophos;i="4.75,491,1330905600"; d="scan'208";a="39899881" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 27 Apr 2012 14:50:39 +0000 Received: from dwingWS ([10.32.240.194]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3REodvi001640; Fri, 27 Apr 2012 14:50:39 GMT From: "Dan Wing" To: "'Rick van Rein'" References: <20120426092725.GC27002@newphantom.local> <0d9801cd240f$456579c0$d0306d40$@com> <20120427052933.GA31576@newphantom.local> In-Reply-To: <20120427052933.GA31576@newphantom.local> Date: Fri, 27 Apr 2012 07:50:39 -0700 Message-ID: <0ee101cd2485$1ca77800$55f66800$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac0kNY/qfUzLnZlFRXq/i/jariHSOwAT0h1A Content-Language: en-us Cc: uri-review@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] Proposal: sip6 URI scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 14:50:40 -0000 > -----Original Message----- > From: Rick van Rein [mailto:rick@openfortress.nl] > Sent: Thursday, April 26, 2012 10:30 PM > To: Dan Wing > Cc: 'Rick van Rein'; uri-review@ietf.org; sipcore@ietf.org > Subject: Re: [sipcore] Proposal: sip6 URI scheme > > Hello, > > > > Your feedback is kindly welcomed. > > > > It's a layering violation, and -- worse -- will cause far more harm > > than it could possibly help. Please don't do this. > > Thanks all for looking into this proposal. It is clear that it will > not > gain wide acceptance, and should not be taken any further. > > I'm withdrawing the proposal. I do like the attention to IPv6, though -- don't get me wrong! I expect ICE is sufficient to find a working IPv6 or working IPv4 media path, and choosing between them. If it is deficient, please point it out, as ICE is being used by WEBRTC on the Internet (where the IPv4/IPv6 address selection problem will be more severe than within controlled networks). -d From pravindran@sonusnet.com Fri Apr 27 19:22:56 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D4711E809F for ; Fri, 27 Apr 2012 19:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.53 X-Spam-Level: X-Spam-Status: No, score=-6.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 khtUWD3P87jj for ; Fri, 27 Apr 2012 19:22:55 -0700 (PDT) Received: from na3sys010aog111.obsmtp.com (na3sys010aog111.obsmtp.com [74.125.245.90]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5ED11E809C for ; Fri, 27 Apr 2012 19:22:55 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob111.postini.com ([74.125.244.12]) with SMTP ID DSNKT5tUfmZCq7h0BFJHwGX1V2Yc9ag4UQui@postini.com; Fri, 27 Apr 2012 19:22:55 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 27 Apr 2012 22:22:57 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Sat, 28 Apr 2012 07:52:49 +0530 From: "Ravindran, Parthasarathi" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Should we change mandatory-to-implement transports? Thread-Index: AQHNHwbQaJhHKG8b4kOFcyf6nW/MOJamKTDggAliv9A= Date: Sat, 28 Apr 2012 02:22:49 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E23AD64@inba-mail01.sonusnet.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 02:22:56 -0000 UGF1bCwNCg0KSSBwcmVmZXIgbmFycm93IHdheSBhcyBJIGRvdWJ0IHdoZXRoZXIgaXQgaXMgcG9z c2libGUgdG8gZ2VuZXJhbGl6ZSBpbiByZWxheGluZyB0aGUgdHJhbnNwb3J0LiBCdXQgdGhlIG5h cnJvdyB3YXkgaGFzIHRvIGNvbnNpZGVyIHRoZSBzaWRlIGVmZmVjdCBvZiB0aGUgcmVsYXhpbmcg IG9mICJVRFAsIFRDUCIgdHJhbnNwb3J0IG1hbmRhdGUgbm9ybWF0aXZlIHN0YXRlbWVudC4gU2Vj IDcgb2YgUkZDIDU2MzAgcHJvdmlkZXMgdGhvc2UgY29uc2lkZXJhdGlvbnMgZm9yIFNJUCB1c2Fn ZSAmIFRMUyB0cmFuc3BvcnQuIFRoZSBtYWluIGNvbnNpZGVyYXRpb24gd2hpY2ggSSdtIHRoaW5r aW5nIGZvciB3ZWJzb2NrZXQgYXMgYSB0cmFuc3BvcnQgYXMgb2Ygbm93IGFyZSByZWNvcmQtcm91 dGUsIHBhdGggaGFuZGxpbmcgaW4gd2Vic29ja2V0Lg0KDQpUaGFua3MNClBhcnRoYQ0KDQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBSYXZpbmRyYW4sIFBhcnRoYXNhcmF0aGkN Cj5TZW50OiBTdW5kYXksIEFwcmlsIDIyLCAyMDEyIDg6MzIgQU0NCj5UbzogJ1BhdWwgS3l6aXZh dCc7IHNpcGNvcmVAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSRTogW3NpcGNvcmVdIFNob3VsZCB3ZSBj aGFuZ2UgbWFuZGF0b3J5LXRvLWltcGxlbWVudA0KPnRyYW5zcG9ydHM/DQo+DQo+UGF1bCwNCj4N Cj5FdmVuIGJlZm9yZSByZWxheGluZyB0aGUgdHJhbnNwb3J0IGNyaXRlcmlhLCBsZXQgdXMgZGlz Y3VzcyB3aGV0aGVyDQo+d2Vic29ja2V0IGlzIGEgbmV3IHRyYW5zcG9ydCBvciBuZXcgVVJJIGFz IHRoZSBzaW1pbGFyIGRpc2N1c3Npb24NCj5oYXBwZW5zIGZvciBUTFMgYXMgYSB0cmFuc3BvcnQg b3ZlciBUQ1AgaW4gU2VjIDI2LjIuMi4gSSBoYXZlIGluaXRpYXRlZA0KPnRoZSBuZXcgdGhyZWFk IHdpdGggdGhlIHByb3Bvc2FsIG9mIHVzaW5nIHdlYnNvY2tldCBhcyBhIG5ldyBVUkkgKFNJUFdT LA0KPlNJUFdTUykuIEknbGwgZ2V0IGJhY2sgdG8gdGhpcyB0aHJlYWQgaW4gY2FzZSBmb2xrcyBw cm92ZXMgd2Vic29ja2V0IGFzDQo+YSB0cmFuc3BvcnQuDQo+DQo+VGhhbmtzDQo+UGFydGhhDQo+ DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IHNpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4+QmVoYWxmIE9m IFBhdWwgS3l6aXZhdA0KPj5TZW50OiBGcmlkYXksIEFwcmlsIDIwLCAyMDEyIDg6MzQgUE0NCj4+ VG86IHNpcGNvcmVAaWV0Zi5vcmcNCj4+U3ViamVjdDogW3NpcGNvcmVdIFNob3VsZCB3ZSBjaGFu Z2UgbWFuZGF0b3J5LXRvLWltcGxlbWVudCB0cmFuc3BvcnRzPw0KPj4NCj4+SSd2ZSBiZWVuIGxv b2tpbmcgZm9yIGEgc3VpdGFibGUgcGxhY2UgdG8ganVtcCBiYWNrIGludG8gdGhpcyB0aHJlYWQu DQo+Pk1heWJlIHRoaXMgaXMgYXMgZ29vZCBhIHBsYWNlIGFzIGFueS4gSSd2ZSBjaGFuZ2VkIHRo ZSBzdWJqZWN0IHRvDQo+PnJlZmxlY3QgdGhlIGN1cnJlbnQgZm9jdXMgb2YgdGhlIGRpc2N1c3Np b24uDQo+Pg0KPj5XZSBoYXZlIHR3byB3YXlzIGZvcndhcmQgb24gdGhpcyAtIHRoZSBuYXJyb3cg d2F5LCBhbmQgdGhlIGJyb2FkIHdheS4NCj4+DQo+PlRoZSBuYXJyb3cgd2F5IGl0IHRvIGNyYWZ0 IGEgc3BlY2lmaWMgZXhlbXB0aW9uIGZvciBpbXBsZW1lbnRlcnMgb2YgdGhlDQo+PndlYnNvY2tl dCB0cmFuc3BvcnQgLSB0aGF0IHRoZXkgYXJlbid0IHJlcXVpcmVkIHRvIGltcGxlbWVudCBVRFAg YW5kDQo+PlRDUC4gU3VjaCBhbiBleGVtcHRpb24gY291bGQgYmUgaW5jbHVkZWQgaW4gdGhlIHdl YnNvY2tldCB0cmFuc3BvcnQNCj4+ZHJhZnQuDQo+Pg0KPj5UaGUgYnJvYWQgd2F5IGlzIHRvIGRv IGEgc3RhbmRhbG9uZSB1cGRhdGUgdG8gMzI2MSB0aGF0IHJlbW92ZXMvcmVsYXhlcw0KPj50aGUg cmVxdWlyZW1lbnQgdG8gaW1wbGVtZW50IFVEUCBhbmQgVENQIHRyYW5zcG9ydHMuDQo+Pg0KPj5U aGUgbmFycm93IHdheSB3aWxsIGJlIGVhc2llciB0byBhY2hpZXZlLiBJdHMgaW1wYWN0IGlzIG5h cnJvd2VyIGFuZA0KPj5lYXNpZXIgdG8gdW5kZXJzdGFuZC4gU28gdGhlcmUgaXMgbGlrZWx5IHRv IGJlIG11Y2ggbGVzcyBvYmplY3Rpb24gdG8NCj4+aXQuIEFuZCBvZiBjb3Vyc2UgaXQgZG9lc24n dCByZXF1aXJlIGEgc2VwYXJhdGUgZG9jdW1lbnQuDQo+Pg0KPj5UaGUgYnJvYWQgd2F5IHdpbGwg Y292ZXIgbWFueSBtb3JlIGNhc2VzIGFsbCBpbiBvbmUgc3dpcGUgb2YgdGhlIHBlbi4NCj4+QnV0 IHRoYXQgbWVhbnMgdGhhdCBpdCB3aWxsIHJlcXVpcmUgbXVjaCBtb3JlIHNjcnV0aW55IHRvIGF2 b2lkDQo+PnVuaW50ZW5kZWQgY29uc2VxdWVuY2VzLiBBcyBhIHJlc3VsdCBpdCB3aWxsIGJlIGhh cmRlciB0byBjcmFmdCBhbmQNCj4+aGFyZGVyIHRvIHBhc3MuIE15IG1haW4gY29uY2VybiBpcyB0 aGF0IGl0IGhhcyB0byBwb3RlbnRpYWwgdG8gZXJlY3QNCj4+bmV3IGJhcnJpZXJzIHRvIGludGVy b3BlcmFiaWxpdHkuIFRoZSBwb2ludCBvZiBoYXZpbmcgc29tZQ0KPj5tdXN0LWltcGxlbWVudCB0 cmFuc3BvcnRzIGlzIHRvIGVuc3VyZSBzb21lIGNvbW1vbiBiYXNpcyBmb3IgaW50ZXJvcC4NCj4+ VGhpcyBoYXMgdGhlIHBvdGVudGlhbCB0byBsb3NlIHRoYXQuIEkgYW0gbXlzZWxmIHVuY2VydGFp biBpZiBJIHdvdWxkDQo+PnN1cHBvcnQgc3VjaCBhIGNoYW5nZS4gVGhpcyB3b3VsZCBkZXBlbmQg b24gc29tZSB2ZXJ5IGNhcmVmdWwgYW5hbHlzaXMuDQo+Pg0KPj5JIGNhbid0IHByb21pc2UgdGhh dCB0aGUgY2hhaXJzIG9yIHRoZSBBRCB3aWxsIGV2ZW4gYXBwcm92ZSBvZiB0aGUNCj4+YnJvYWQg YXBwcm9hY2guDQo+Pg0KPj4oSSBndWVzcyB0aGVyZSBpcyBhIHRoaXJkIHdheSAtIHRvIGRvICpu b3RoaW5nKiBhYm91dCB0aGUgbWFuZGF0b3J5LXRvLQ0KPj5pbXBsZW1lbnQgdHJhbnNwb3J0IHJl cXVpcmVtZW50LiBMZWF2ZSBqYXZhc2NyaXB0LWJyb3dzZXItYmFzZWQgc2lwDQo+PmltcGxlbWVu dGF0aW9ucyB0aGF0IGNhbid0IGRvIFVEUCBvciBUQ1Agbm9uLWNvbXBsaWFudC4gSU1PIHRoYXQg aXMgYW4NCj4+aXJyZXNwb25zaWJsZSBkaXJlY3Rpb24gdGhhdCBJIGRvbid0IHdhbnQgdG8gY29u c2lkZXIuKQ0KPj4NCj4+R2l2ZW4gYWxsIG9mIHRoYXQsIEkgd291bGQgbGlrZSB0byBoYXZlIHNv bWUgZGlzY3Vzc2lvbiBvZiB3aGljaCB3YXkNCj4+dGhlIGdyb3VwIHdvdWxkIGxpa2UgdG8gZ28u IFBsZWFzZSBkbyBtb3JlIHRoYXQgdm90ZSAtIGFjdHVhbGx5IG1ha2UNCj4+dGhlIGNhc2UgZm9y IHdoeSB5b3Ugd2FudCB0byBnbyB0aGUgd2F5IHlvdSBkby4NCj4+DQo+PglUaGFua3MsDQo+PglQ YXVsIFthcyBjby1jaGFpcl0NCj4+DQo+Pk9uIDQvMjAvMTIgODo1NCBBTSwgScOxYWtpIEJheiBD YXN0aWxsbyB3cm90ZToNCj4+PiAyMDEyLzQvMjAgQ2hyaXN0ZXIgSG9sbWJlcmc8Y2hyaXN0ZXIu aG9sbWJlcmdAZXJpY3Nzb24uY29tPjoNCj4+Pj4+PiBTbywgYWdhaW4sIGxldCdzIG1ha2UgZXZl cnkgdHJhbnNwb3J0IG9wdGlvbmFsLCBhbmQgcGVvcGxlIHdpbGwNCj4+dGhlbiBpbXBsZW1lbnQg YmFzZWQgb24gY3VzdG9tZXIgcmVxdWlyZW1lbnRzLCBuZXR3b3JrIGVudmlyb25tZW50cywNCj4+ cGxhdGZvcm0gY2hhcmFjdGVyaXN0aWNzLCBldGMgZXRjIGV0Yy4NCj4+Pj4+DQo+Pj4+PiBMZXQn cyBqdXN0IGdldCB0aGlzIHN0YXJ0ZWQuLi4gaXQncyBhbHJlYWR5IHJlbGV2YW50IHNpbmNlIFND VFAgaGFzDQo+PmJlZW4gZGVmaW5lZCBhcyBhIHRyYW5zcG9ydCBmb3IgU0lQLiBBIFVBIHRoYXQg d2FudHMgdG8gc29sZWx5IHVzZSBTQ1RQDQo+PnNob3VsZCBiZSBhbGxvd2VkIHRvIGRvIHRoYXQg d2l0aG91dCBiZWluZyBsYWJlbGVkIG5vbi1jb21wbGlhbnQgd2l0aA0KPj5SRkMgMzI2MS4NCj4+ Pj4+DQo+Pj4+PiBIb3cgd291bGQgdGhpcyB3b3JrPyBXb3VsZCB0aGlzIGp1c3QgYmUgYSB0d28t cGFnZSBkb2N1bWVudA0KPj4+Pj4gdXBkYXRpbmcNCj4+dGhhdCBvbmUgc21hbGwgc2VjdGlvbiBv ZiBSRkMgMzI2MT8NCj4+Pj4NCj4+Pj4gUHJldHR5IG11Y2gsIHllcyA6KQ0KPj4+Pg0KPj4+PiBP ZiBjb3Vyc2UsIGluIGFkZGl0aW9uIHRvIHRoZSBhY3R1YWwgdXBkYXRlIHRoZXJlIHdvdWxkIG5l ZWQgdG8gYmUNCj4+c29tZSBqdXN0aWZpY2F0aW9uIHRleHQuDQo+Pj4NCj4+Pg0KPj4+IEhpLCBp biBhIHByZXZpb3VzIG1haWwgSSBzdWdnZXN0ZWQgc29tZSBwb2ludHMgZm9yIHN1Y2ggYSBuZXcg d29yay4NCj4+PiBUaGlzIGZ1dHVyZSBkcmFmdCBjb3VsZCBhZGRyZXNzIHRoaXMgdG9waWMgYnkg Y292ZXJpbmcgdGhlIGZvbGxvd2luZw0KPj4+IGNhc2VzOg0KPj4+DQo+Pj4gLSBTY2VuYXJpb3Mg aW4gd2hpY2gganVzdCAqc2VjdXJlKiBTSVAgdHJhbnNwb3J0IGlzIHJlcXVpcmVkIChzbyBVRFAN Cj4+PiBoYXMgbm8gcGxhY2UpLiBUaGlzIGNvdWxkIG9jY3VyIGluIGxvY2FsIG5ldHdvcmtzLCBw cm92aWRlcnMgbmV0d29ya3MNCj4+PiBvciB3aGF0ZXZlci4NCj4+Pg0KPj4+IC0gU2NlbmFyaW9z IGluIHdoaWNoIGp1c3QgYSBzaW5nbGUgdHJhbnNwb3J0IGNhbiBiZSB1c2VkIGR1ZSB0bw0KPj4+ IG5ldHdvcmsgdG9wb2xvZ3kgKGkuZS4gaW4gT3V0Ym91bmQgdG9wb2xvZ3kgaW4gd2hpY2ggVUEn cyBhcmUgYmVoaW5kDQo+Pj4gZGlmZmVyZW50IE5BVCdzIGFuZCBjb25uZWN0IHRvIHRoZSBzYW1l IEVkZ2UgUHJveHkgdXNpbmcgVENQIG9yIFVEUCwNCj4+PiBzbyB0aGV5IGNhbm5vdCByZWNlaXZl IHJlcXVlc3RzIHZpYSBhIGRpZmZlcmVudCB0cmFuc3BvcnQgdGhhbiB0aGUNCj4+PiBvbmUgdGhl eSB1c2UgdG8gY29ubmVjdCB0byB0aGVpciBPdXRib3VuZCBwcm94eSkuDQo+Pj4NCj4+PiAtIFNw ZWNpYWwgY2FzZXMgaW4gd2hpY2ggaXQncyBjbGVhciB0aGF0LCBnaXZlbiBlbnZpcm9tZW50L3Bs YXR0Zm9ybQ0KPj4+IGNvbnN0cmFpbnMsIHNvbWUgaW1wbGVtZW50YXRpb25zIGFyZSBub3QgYWJs ZSB0byBzdXBwb3J0IFNJUCBVRFAvVENQDQo+Pj4gdHJhbnNwb3J0cy4NCj4+Pg0KPj4+IEJhc2lj YWxseSBzdWNoIGEgZHJhZnQgY291bGQgc3RhdGUgdGhhdCAiaW4gY2VydGFpbiBjYXNlcyAoc3Vj aCBhcw0KPj4+IHRob3NlIGRlc2NyaWJlZCBhYm92ZSkgYSBTSVAgZW50aXR5IE1BWSBOT1QgaW1w bGVtZW50IFVEUCBhbmQvb3IgVENQDQo+Pj4gdHJhbnNwb3J0cywgYmVpbmcgdGhpcyBhbiB1cGRh dGUgdG8gUkZDIDMyNjEiLg0KPj4+DQo+Pj4gSU1ITyBqdXN0IG9uZSBwYWdlIDopDQo+Pj4NCj4+ Pg0KPj4NCj4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+c2lwY29yZSBtYWlsaW5nIGxpc3QNCj4+c2lwY29yZUBpZXRmLm9yZw0KPj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From nataraju.sip@gmail.com Fri Apr 27 21:26:07 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9D221F860F for ; Fri, 27 Apr 2012 21:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.123 X-Spam-Level: X-Spam-Status: No, score=-2.123 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 Hrocp-jGYRTq for ; Fri, 27 Apr 2012 21:26:06 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 49C0E21F8601 for ; Fri, 27 Apr 2012 21:26:03 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so1022841lbb.31 for ; Fri, 27 Apr 2012 21:26:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=THnI38bIHekiVg6NSeXCWiAlBaedWRLU5wRjVK2fSD8=; b=0yDsV2ohaZRmR2wC5lAtIfJO2ZDmKI8jEVdep+9iYZDrzKALzBovRI5m5KKtjeoPIp /v49GmSnGpQzl+G/th5tS3qY0r9cGNSPNizfJmV+W08At6O92aRtJowBCAkF2yp/Oegl H1CBF9FxchpLdQOb4mRcLJmZzrIgxvgCv8IKOQoxY6vk/U1+VhHGaStjbm2XTDir0s9A GhBfsjYdmncQHlO+HleBh+NwToESgk9eR8B4JT8lFMRb3ivy5dP3jJUn1jxiOuZ4YqAA vpFd3XHNrzWsKgCuKR2QRa/W7l0lai8AbGCF9NSgAklfj/1VgV+VdcvLuLE0ddEqIPCo XA2g== MIME-Version: 1.0 Received: by 10.112.101.162 with SMTP id fh2mr6488958lbb.20.1335587162264; Fri, 27 Apr 2012 21:26:02 -0700 (PDT) Received: by 10.112.36.104 with HTTP; Fri, 27 Apr 2012 21:26:02 -0700 (PDT) In-Reply-To: References: Date: Sat, 28 Apr 2012 09:56:02 +0530 Message-ID: From: "Nataraju A.B" To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=f46d04016a775f94df04beb59e67 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - editorial comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 04:26:07 -0000 --f46d04016a775f94df04beb59e67 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A better option is to use the default notion used in most of the rfc's. That is, by default consider complete text/information in draft/rfc is non-normative (mandatory to follow, but with different strength based on SHOULD, MUST, etc....) and normative (informative) text is specified by an indented TAB (this is optional to satisfy) 5.3. Locating a SIP Server RFC 3263 [RFC3263] specifies the procedures which should be followed by SIP entities for locating SIP servers. This specification defines the NAPTR service value "SIP+D2W" for SIP WebSocket Servers that support plain WebSocket transport and "SIPS+D2W" for SIP WebSocket Servers that support secure WebSocket transport. Unfortunately neither JavaScript stacks nor WebSocket stacks running in current web browsers are capable of performing DNS NAPTR/SRV queries. Here the 2nd paragraph is normative text, hence it is only information to implementer. But would not lead to any inter-operability issue, if not followed religiously. On Fri, Apr 27, 2012 at 2:51 PM, I=F1aki Baz Castillo wrote= : > 2012/4/27 Nataraju A.B : > > Usage of text "_This section is non-normative._" will not convey same > > meaning in both the documents. > > > > Please add the first paragraph of sec.2,rfc6455 to sec.2 of this draft. > > Otherwise the draft would be confusing about usage of the text "_This > > section is non-normative._" > > > > I know this is minor comment, but required to make the draft clearer. > > Hi Nataraju, we will add it in next revision of the draft. > > Thanks a lot. > > -- > I=F1aki Baz Castillo > > --=20 Thanks, Nataraju A.B. --f46d04016a775f94df04beb59e67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
A better option is to use the default notion use= d in most of the rfc's. That is, by default consider complete text/info= rmation in draft/rfc is non-normative (mandatory to follow, but with differ= ent strength based on SHOULD, MUST, etc....) and normative (informative) te= xt is specified by an indented TAB (this is optional to satisfy)

<websocket-02.txt>
5.3.  Locating a SIP Server

   RFC 3263 [RFC3263] specifies the procedures which should be followed
   by SIP entities for locating SIP servers.  This specification defines
   the NAPTR service value "SIP+D2W" for SIP WebSocket Servers th=
at
   support plain WebSocket transport and "SIPS+D2W" for SIP WebSo=
cket
   Servers that support secure WebSocket transport.

      Unfortunately neither JavaScript stacks nor WebSocket stacks
      running in current web browsers are capable of performing DNS
      NAPTR/SRV queries.
</websocket-02.txt>

Here the 2nd paragraph is normative text, hence = it is only information to=A0implementer. But would not lead to any inter-op= erability issue, if not=A0followed=A0religiously.


On Fri, Apr 27, 2012 at 2:51 PM, I=F1aki Baz Castill= o <= ibc@aliax.net> wrote:
2012/4/27 Nataraju A.B <nataraju.sip@gmail.com>:
> Usage of text "_This section is non-normative._= " will not convey same
> meaning in both the documents.
>
> Please add the first paragraph of sec.2,rfc6455 to sec.2 of this draft= .
> Otherwise the draft would be confusing about usage of the text "_= This
> section is non-normative._"
>
> I know this is minor comment, but required to make the draft clearer.<= br>
Hi Nataraju, we will add it in next revision of the draft.

Thanks a lot.

--
I=F1aki Baz Castillo
<ibc@aliax.net>



-- Thanks,
Nataraju A.B.
--f46d04016a775f94df04beb59e67-- From ibc@aliax.net Sat Apr 28 07:56:27 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EA7E21F8620 for ; Sat, 28 Apr 2012 07:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFWLbgcP3IUv for ; Sat, 28 Apr 2012 07:56:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B047621F8619 for ; Sat, 28 Apr 2012 07:56:26 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1434784vcb.31 for ; Sat, 28 Apr 2012 07:56:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=tICCtqKiIHSuLEakAIkGQS4yRDKgKR02cN4sFxSuwEo=; b=pdB37AJm6npFwphdltL3sxm4ggdJd9IBNo3Bh+/gQyAvh3aV9FE9KnfmO8UE8EFdYZ A4u/+c2NGmAWeTM4zdb5tnjLvXiqrhQWWbZMIxNt2O5zk7Nfh9aAUPUVACvcrjPmQBkN eShz3NwnuuEHYcLqrX6cQN0TKCBqLenT+DgmOf5cMJ5vvnjsiC6kb0llBXm8ZCNc4Syi B2DZiDoVRS3F3/qtGIC+bMVRRRO2hlnxbZOdmaS570ggJDjfKgOLXrFzNGpDOMw6clHG w4VUWn0l/FTFObzGVuNvwuty1YbHfWkclafw4DRbHzO+4CcUmQ1m8KU89uF7zN4M8GYk gfKg== Received: by 10.52.94.34 with SMTP id cz2mr2581027vdb.100.1335624985780; Sat, 28 Apr 2012 07:56:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.199 with HTTP; Sat, 28 Apr 2012 07:56:05 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 28 Apr 2012 16:56:05 +0200 Message-ID: To: "Nataraju A.B" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlxnl3pymnazgQmfT5hBk4lFaNZAMPeQrnIm66WluTth9gIE4/m6mtfPd1Uyp66+Chp1IkB Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - editorial comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2012 14:56:27 -0000 Hi Nataraju, After reading various mails from you about this topic I think that you are confusing the meaning of "normative" and "informative" words (hope I'm not wrong). - "normative" text is a text that creates rules. - "informative" text does not create rules but just helps or adds some useful information. But by reading your text: 2012/4/28 Nataraju A.B : > consider complete text/information in draft/rfc is > non-normative (mandatory to follow, but with different strength based on > SHOULD, MUST, etc....) That is "normative" instead of "non-normative". > and normative (informative) text is specified by an > indented TAB (this is optional to satisfy) That is "informative" and therefore also "non-normative". Regards. --=20 I=C3=B1aki Baz Castillo From salvatore.loreto@ericsson.com Sat Apr 28 23:56:30 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDAC11E8072 for ; Sat, 28 Apr 2012 23:56:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.966 X-Spam-Level: X-Spam-Status: No, score=-105.966 tagged_above=-999 required=5 tests=[AWL=-0.709, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, 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 BaMaWC5BdV55 for ; Sat, 28 Apr 2012 23:56:30 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id EF5C711E8074 for ; Sat, 28 Apr 2012 23:56:29 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-27-4f9ce61b22d2 Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id EA.D9.03534.B16EC9F4; Sun, 29 Apr 2012 08:56:27 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Sun, 29 Apr 2012 08:56:27 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D4F862325 for ; Sun, 29 Apr 2012 09:56:26 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id CC28A523B1 for ; Sun, 29 Apr 2012 09:56:26 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5B25651BC7 for ; Sun, 29 Apr 2012 09:56:26 +0300 (EEST) Message-ID: <4F9C0B48.4020606@ericsson.com> Date: Sat, 28 Apr 2012 18:22:48 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - Review comments (Nataraju A B) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 06:56:31 -0000 On 4/18/12 8:51 PM, IƱaki Baz Castillo wrote: >> > if we want to use SIP URI with any other secure communication mechanism like >> > WSS, might require >> > update to RFC5630. like >> > sec 3.1.3. >> > >> > If one wants to use "best-effort TLS/WSS" for SIP, one just needs to use >> > a SIP URI, and send the request over TLS ** or any other secure transport >> > mechanism like WSS** >> > >> > > TLS is a extra-layer on top of TCP and also on top of WebSocket. TLS is not on top of WebSocket, but it is the other way around. Once again: WebSocket is not a transport protocol, but a protocol that is used to transport content as HTTP is. WebSocket can run on top of TCP (WS) or on top of TLC (WSS). So once again please do not say WebSocket is a transport protocol because it is not! /Salvatore -- Salvatore Loreto, PhD www.sloreto.com > When > applied on top of TCP transport it is commonly named "TLS", but it > should be better to call it "TLS-TCP" (in the same way that TLS over > SCTP is named "TLS-SCTP" for Via transport value in RFC 4168. > > > > > From salvatore.loreto@ericsson.com Sat Apr 28 23:56:33 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB67511E8081 for ; Sat, 28 Apr 2012 23:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.788 X-Spam-Level: X-Spam-Status: No, score=-105.788 tagged_above=-999 required=5 tests=[AWL=-0.832, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 CB5S1abXtZ6D for ; Sat, 28 Apr 2012 23:56:32 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8F32311E8072 for ; Sat, 28 Apr 2012 23:56:31 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-7c-4f9ce61d4bd2 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8E.27.25560.E16EC9F4; Sun, 29 Apr 2012 08:56:30 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Sun, 29 Apr 2012 08:56:29 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9B2B82325; Sun, 29 Apr 2012 09:56:29 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A9F35523B1; Sun, 29 Apr 2012 09:56:29 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 206AD51BC7; Sun, 29 Apr 2012 09:56:29 +0300 (EEST) Message-ID: <4F9C12BC.8080203@ericsson.com> Date: Sat, 28 Apr 2012 18:54:36 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040305000808070601050001" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 06:56:33 -0000 --------------040305000808070601050001 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit On 4/18/12 5:24 PM, IƱaki Baz Castillo wrote: > 2012/4/18 Salvatore Loreto: >> The important thing to standardize from a SIPCore prospective is the >> interaction/translations that happens between the WebSocket server and the >> SIP proxy that are two different logical entities. > Hi Salvatore, I don't consider them two different logical entities. > The draft 02 states the following in "Definitions" section (which was > added after your review): > > SIP WebSocket Server: A SIP entity capable of listening for inbound > connections from WebSocket clients and speaking the WebSocket > SIP Sub-Protocol as defined by this document. > > > So when the WebSocket message/arrives to the WebSocket listening > server, the application on top of it (a SIP proxy/UAS) should extract > the SIP message from the WS message, parse it and process it in the > same way that if the SIP message arrived via another SIP transport. I understand clearly your point, but perhaps I wasn't able to express so good mine. Once more: I could use your argument with almost all the protocols and say for example XMPP (just s/XMPP/SIP in your above text): when a XMPP message/arrives to the WebSocket listening server, the application on top of it (a SIP proxy/UAS) should extract the SIP message from the XMPP message, parse it and process it in the same way that is the SIP message message arrived via another SIP transport. BTW: "SIP transport" is also an interesting definition, indeed WebSocket is not a transport protocol but can be used to transport SIP message as well as other stuff. I would hear the opinion of the Chairs about this, if they are OK to define (and talk in this draft of) WebSocket I will shut up! Chairs? > Just it. And for sending responses the SIP proxy/UAS should reuse the > existing WS connection (which implies creating a WS message and > writting the SIP response inside). Just it. > > > The same is true for a SIP WebSocket Client: > > SIP WebSocket Client: A SIP entity capable of opening outbound > connections with WebSocket servers and speaking the WebSocket > SIP Sub-Protocol as defined by this document. > > > For example, if the SIP application is a JavaScript code running on a > web browser, the SIP stack (JS code) sends and receives SIP messages > to/from its transport layer (as in any other SIP transport), but in > this case the transport layer is a WebSocket client interface which > generates a WS message (using the JS WebSocket API) and sends it. Same > occurs when receiving an incoming SIP request/response which is > extracted by the JS app (the SIP stack) from the received WS message. > > > So honestly I see no "interaction/translations that happens between > the WebSocket server and the SIP proxy". So honestly I don't buy your explanation. Salvatore -- Salvatore Loreto, PhD www.sloreto.com --------------040305000808070601050001 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit On 4/18/12 5:24 PM, IƱaki Baz Castillo wrote: 
2012/4/18 Salvatore Loreto <salvatore.loreto@ericsson.com>:

The important thing to standardize from a SIPCore prospective is the
interaction/translations that happens between the WebSocket server and the
SIP proxy that are two different logical entities.

Hi Salvatore, I don't consider them two different logical entities.
The draft 02 states the following in "Definitions" section (which was
added after your review):

   SIP WebSocket Server:  A SIP entity capable of listening for inbound
         connections from WebSocket clients and speaking the WebSocket
         SIP Sub-Protocol as defined by this document.


So when the WebSocket message/arrives to the WebSocket listening
server, the application on top of it (a SIP proxy/UAS) should extract
the SIP message from the WS message, parse it and process it in the
same way that if the SIP message arrived via another SIP transport.
I understand clearly your point, but perhaps I wasn't able to express so good mine.
Once more: I could use your argument with almost all the protocols and say
for example XMPP (just s/XMPP/SIP in your above text):
when a XMPP message/arrives to the WebSocket listening server, the application
on top of it (a SIP proxy/UAS) should extract the SIP message from the XMPP message,
parse it and process it in the same way that is the SIP message message arrived via another
SIP transport.
BTW: "SIP transport" is also an interesting definition, indeed WebSocket is not a transport protocol
but can be used to transport SIP message as well as other stuff.

I would hear the opinion of the Chairs about this,
if they are OK to define (and talk in this draft of) WebSocket I will shut up!
Chairs?
Ā 
Just it. And for sending responses the SIP proxy/UAS should reuse the
existing WS connection (which implies creating a WS message and
writting the SIP response inside). Just it.


The same is true for a SIP WebSocket Client:

   SIP WebSocket Client:  A SIP entity capable of opening outbound
         connections with WebSocket servers and speaking the WebSocket
         SIP Sub-Protocol as defined by this document.


For example, if the SIP application is a JavaScript code running on a
web browser, the SIP stack (JS code) sends and receives SIP messages
to/from its transport layer (as in any other SIP transport), but in
this case the transport layer is a WebSocket client interface which
generates a WS message (using the JS WebSocket API) and sends it. Same
occurs when receiving an incoming SIP request/response which is
extracted by the JS app (the SIP stack) from the received WS message.


So honestly I see no "interaction/translations that happens between
the WebSocket server and the SIP proxy".
So honestly I don't buy your explanation.

Salvatore
-- 
Salvatore Loreto, PhD
www.sloreto.com

--------------040305000808070601050001-- From salvatore.loreto@ericsson.com Sat Apr 28 23:56:33 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E2811E8072 for ; Sat, 28 Apr 2012 23:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.907 X-Spam-Level: X-Spam-Status: No, score=-105.907 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 Nuwy1GiWB6KC for ; Sat, 28 Apr 2012 23:56:32 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 546D411E807F for ; Sat, 28 Apr 2012 23:56:32 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-38-4f9ce61f669b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4C.D9.03534.F16EC9F4; Sun, 29 Apr 2012 08:56:32 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Sun, 29 Apr 2012 08:56:31 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 47EFB2325 for ; Sun, 29 Apr 2012 09:56:31 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 56EEF523B1 for ; Sun, 29 Apr 2012 09:56:31 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id DD72851BC7 for ; Sun, 29 Apr 2012 09:56:30 +0300 (EEST) Message-ID: <4F9C2416.3060302@ericsson.com> Date: Sat, 28 Apr 2012 20:08:38 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <4F8ED41A.6060703@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E2281EE@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C428E2FA4@ESESSCMS0356.eemea.ericsson.se> <387F9047F55E8C42850AD6B3A7A03C6C0E228315@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E22882A@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A5A7@ESESSCMS0356.eemea.ericsson.se> <4F915A2C.1080506@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C42E5A609@ESESSCMS0356.eemea.ericsson.se> <4F917AD4.2040500@alum.mit.edu> In-Reply-To: <4F917AD4.2040500@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------090807000104040101030603" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Should we change mandatory-to-implement transports? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 06:56:33 -0000 --------------090807000104040101030603 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit On 4/20/12 6:03 PM, Paul Kyzivat wrote: > I've been looking for a suitable place to jump back into this thread. > Maybe this is as good a place as any. I've changed the subject to > reflect the current focus of the discussion. > > We have two ways forward on this - the narrow way, and the broad way. > > The narrow way it to craft a specific exemption for implementers of the > websocket transport - that they aren't required to implement UDP and > TCP. Such an exemption could be included in the websocket transport draft. I would go for the narrow, at least from a WebSocket prospective. From a WebSocket point of view, what we are defining in SIPCore is ***SIP as a WebSocket subprotocol*** indeed we are going also to register into IANA a value for it. If we take this approach, everything will become simpler. my 2 cents /Sal > > The broad way is to do a standalone update to 3261 that removes/relaxes > the requirement to implement UDP and TCP transports. > > The narrow way will be easier to achieve. Its impact is narrower and > easier to understand. So there is likely to be much less objection to > it. And of course it doesn't require a separate document. > > The broad way will cover many more cases all in one swipe of the pen. > But that means that it will require much more scrutiny to avoid > unintended consequences. As a result it will be harder to craft and > harder to pass. My main concern is that it has to potential to erect new > barriers to interoperability. The point of having some must-implement > transports is to ensure some common basis for interop. This has the > potential to lose that. I am myself uncertain if I would support such a > change. This would depend on some very careful analysis. > > I can't promise that the chairs or the AD will even approve of the broad > approach. > > (I guess there is a third way - to do*nothing* about the > mandatory-to-implement transport requirement. Leave > javascript-browser-based sip implementations that can't do UDP or TCP > non-compliant. IMO that is an irresponsible direction that I don't want > to consider.) > > Given all of that, I would like to have some discussion of which way the > group would like to go. Please do more that vote - actually make the > case for why you want to go the way you do. > > Thanks, > Paul [as co-chair] --------------090807000104040101030603 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit On 4/20/12 6:03 PM, Paul Kyzivat wrote: 
I've been looking for a suitable place to jump back into this thread.
Maybe this is as good a place as any. I've changed the subject to 
reflect the current focus of the discussion.

We have two ways forward on this - the narrow way, and the broad way.

The narrow way it to craft a specific exemption for implementers of the 
websocket transport - that they aren't required to implement UDP and 
TCP. Such an exemption could be included in the websocket transport draft.

I would go for the narrow, at least from a WebSocket prospective.

From a WebSocket point of view,
what we are defining in SIPCore is ***SIP as a WebSocket subprotocol***
indeed we are going also to register into IANA a value for it.

If we take this approach, everything will become simpler.

my 2 cents

/Sal


The broad way is to do a standalone update to 3261 that removes/relaxes 
the requirement to implement UDP and TCP transports.

The narrow way will be easier to achieve. Its impact is narrower and 
easier to understand. So there is likely to be much less objection to 
it. And of course it doesn't require a separate document.

The broad way will cover many more cases all in one swipe of the pen. 
But that means that it will require much more scrutiny to avoid 
unintended consequences. As a result it will be harder to craft and 
harder to pass. My main concern is that it has to potential to erect new 
barriers to interoperability. The point of having some must-implement 
transports is to ensure some common basis for interop. This has the 
potential to lose that. I am myself uncertain if I would support such a 
change. This would depend on some very careful analysis.

I can't promise that the chairs or the AD will even approve of the broad 
approach.

(I guess there is a third way - to do *nothing* about the 
mandatory-to-implement transport requirement. Leave 
javascript-browser-based sip implementations that can't do UDP or TCP 
non-compliant. IMO that is an irresponsible direction that I don't want 
to consider.)

Given all of that, I would like to have some discussion of which way the 
group would like to go. Please do more that vote - actually make the 
case for why you want to go the way you do.

	Thanks,
	Paul [as co-chair]


--------------090807000104040101030603-- From nataraju.sip@gmail.com Sun Apr 29 02:12:22 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3C1821F84EF for ; Sun, 29 Apr 2012 02:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, 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 vyY8YX5ek-Er for ; Sun, 29 Apr 2012 02:12:22 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8904A21F84D0 for ; Sun, 29 Apr 2012 02:12:21 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so1478059lbb.31 for ; Sun, 29 Apr 2012 02:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mTzImTRO44RhmNZC/5J1n3d13xxHA+XdhlRr2dOe9LA=; b=xbB1hDxwnsOdp3bLKR2K4dIzcCbqpjaPa9KrF4qHtduX/g8ha1er2hasWYiUNTS9Zd BkabHwf+/XoggdedmuEyt2skoqJVk/ZGEE3EejjXidgQsB8fqAwIT+467yJuiQq6U/Ss CFr11OGAb5SJpQ+Ubo97/T8GBfHr8hkRA/g2FiRWkasbd1LjFdpHBD1UznVDADTZxO+5 zY3pHnPtnWz4OudSApi2hPr9IfejWes2qYBTg2gzuWUzd85Xfyzphu45CJzwdnw2A4YX sfJoOFwx2dhWqcZTqUeGL8ZuzCv4Qxs68eDKIMY8DngSHdjo3Iqr1FkS77vfVJ1qglq/ K6uQ== MIME-Version: 1.0 Received: by 10.152.145.169 with SMTP id sv9mr1050596lab.12.1335690740422; Sun, 29 Apr 2012 02:12:20 -0700 (PDT) Received: by 10.112.36.104 with HTTP; Sun, 29 Apr 2012 02:12:20 -0700 (PDT) In-Reply-To: References: Date: Sun, 29 Apr 2012 14:42:20 +0530 Message-ID: From: "Nataraju A.B" To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=e89a8f2350971cd74104becdbc6d Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - editorial comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 09:12:23 -0000 --e89a8f2350971cd74104becdbc6d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Inaki, You are right, I was wrong while using the words normative and informative. On Sat, Apr 28, 2012 at 8:26 PM, I=F1aki Baz Castillo wrote= : > Hi Nataraju, > > After reading various mails from you about this topic I think that you > are confusing the meaning of "normative" and "informative" words (hope > I'm not wrong). > > - "normative" text is a text that creates rules. > - "informative" text does not create rules but just helps or adds some > useful information. > > > But by reading your text: > > > 2012/4/28 Nataraju A.B : > > consider complete text/information in draft/rfc is > > non-normative (mandatory to follow, but with different strength based o= n > > SHOULD, MUST, etc....) > > That is "normative" instead of "non-normative". > > > > > and normative (informative) text is specified by an > > indented TAB (this is optional to satisfy) > > That is "informative" and therefore also "non-normative". > > > > Regards. > > > -- > I=F1aki Baz Castillo > > --=20 Thanks, Nataraju A.B. --e89a8f2350971cd74104becdbc6d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Inaki,

You are right, I was wrong while using the words = normative and informative.=A0

On Sat, Apr 28, 2012 at 8:26 PM, I=F1aki Baz Castillo <= ;ibc@aliax.net> wrote:
Hi Nataraju,

After reading various mails from you about this topic I think that you
are confusing the meaning of "normative" and "informative&qu= ot; words (hope
I'm not wrong).

- "normative" text is a text that creates rules.
- "informative" text does not create rules but just helps or adds= some
useful information.


But by reading your text:


2012/4/28 Nataraju A.B <nataraju.sip@gmail.com>:
> consider complete text/information in draft/rfc is
> non-normative (mandatory to follow, but with different strength based = on
> SHOULD, MUST, etc....)

That is "normative" instead of "non-normative".



> and normative (informative) text is specified by an
> indented TAB (this is optional to satisfy)

That is "informative" and therefore also "non-normativ= e".



Regards.


--
I=F1aki Baz Castillo
<ibc@aliax.net>= ;



--
= Thanks,
Nataraju A.B.

--e89a8f2350971cd74104becdbc6d-- From ibc@aliax.net Sun Apr 29 10:07:46 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0643221F856D for ; Sun, 29 Apr 2012 10:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.334 X-Spam-Level: X-Spam-Status: No, score=-2.334 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_93=0.6, 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 6YacVaRLSR-i for ; Sun, 29 Apr 2012 10:07:45 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 79D0F21F848C for ; Sun, 29 Apr 2012 10:07:45 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1904474vcb.31 for ; Sun, 29 Apr 2012 10:07:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=6Y13J8xp6ypiW0xSP3PZQCCKyq7VCaxF1ZR2Q2jByxs=; b=LmEeGCgIrhxgz+ACLW6OgGSa6NmFCiaVWjhWgSf1x+xONJ0mburXT1Wqmk0HRabaLX fndHD4HzUEC2XSDs7LKJWnYeXoZ7I63eU4Nc8ilWxF7pP9k2PvV9eBRcxz10iNwYxXoC SWaAK5huBt9zl9ziHY9aNq+Dg7zagkH3wdIufwweoofSMywZ8qHSf4y5IKplxmdJbqqa UKjnIWT0MTVHCQuDhaqQKNxLrKRnQgCTRNAvZIl+bpPT10SCs52ItNdb3AlNzTZOe0Ue roIQNtQICTlrn91dcq1y2FXV4ceJ81w5TBHGRTa0j97ngUwXtaxeo+NVMVzW5T32ab08 oabA== Received: by 10.52.94.34 with SMTP id cz2mr1535460vdb.100.1335719264809; Sun, 29 Apr 2012 10:07:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.199 with HTTP; Sun, 29 Apr 2012 10:07:24 -0700 (PDT) In-Reply-To: <4F9C0B48.4020606@ericsson.com> References: <4F9C0B48.4020606@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 29 Apr 2012 19:07:24 +0200 Message-ID: To: Salvatore Loreto Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmNZISlNw7ClOi1rfr0qSGmKs0btx54QB1J3up19kRTiQhmzOl2mGBu/qKzLj1Y8XFGFKDg Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - Review comments (Nataraju A B) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 17:07:46 -0000 2012/4/28 Salvatore Loreto : > WebSocket is not a transport protocol, but a protocol that is used to > transport content as HTTP is. > WebSocket can run on top of TCP (WS) or on top of TLC (WSS). > > So once again please do not say WebSocket is a transport protocol because= it > is not! Hi Salvatore,let me clarify this subject. The draft defines two things: 1) A WebSocket Sub-Protocol called "sip". 2) A new SIP transport called "WebSocket". The SIP transport defined by this draft is WebSocket. WebSocket is, indeed, a layer on top of a network transport (layer 3) but it's designed to work as a *transport* layer since it defines a framing mechanism to send application messages and control mesages in both directions. Applications (i.e. JavaScript scripts, PHP/Java web apps) use WebSocket as a transport layer. There are other cases in which a transport runs on top of other transports. For example, in the recent IETF #83 the RTCWEB WG approved (or discussed) SCTP-over-DTLS-over-ICE-over-UDP as the transport for the WebRTC Data-Channel mechanism. In some cases a "transport" does not necessarily mean "layer 3 network transport". So, regardless WebSocket is not a layer 3 transport, it's used as a transport by this specification and therefore it's considered a "SIP transport". Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Sun Apr 29 10:24:08 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1112521F8549 for ; Sun, 29 Apr 2012 10:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nw1KeeYZfoLH for ; Sun, 29 Apr 2012 10:24:07 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 620C221F84EC for ; Sun, 29 Apr 2012 10:24:07 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1891100vbb.31 for ; Sun, 29 Apr 2012 10:24:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=i2ZhRbH1h/s7/ZT9U1smNdhAP2C9K9cLmYWm+J26478=; b=SGBdsjf7H7zt3s9/hoqU3x/a6s2qZGduYyC36MUXSFs1qI4+tvPcHW4QdgAL0wIF1R 6Cs2KPi76ILvHKX88bHdyZe+eZw+4rQ3tRr6sHkEqatlCJ+aHlgJ3MDufubbFGesV1wm U+FK5xlqTvwIE6s7BbIARB7EoJk1sxnPcg2K1GYsuS7RXZntHh51OEhO/svbcG/GmJ2M TQEITDVRbvFOAt/WDNA5wTwFcBxNWjGK5l6jFpW0yIc8kf6ABtsv4O0aftIDgCzo9DvU UopAzioXhQfQ4BS4aZlGALtJDAF8sKYp6HT3Gmv9RhTnT2IVajKqQaGahrC03gWkPNB4 YwSw== Received: by 10.52.67.208 with SMTP id p16mr15751203vdt.93.1335720246661; Sun, 29 Apr 2012 10:24:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.199 with HTTP; Sun, 29 Apr 2012 10:23:46 -0700 (PDT) In-Reply-To: <4F9C12BC.8080203@ericsson.com> References: <387F9047F55E8C42850AD6B3A7A03C6C0E227F98@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E227FFD@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228035@inba-mail01.sonusnet.com> <52EA773E-0FA0-4625-8E1F-6D10E543137A@ag-projects.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228062@inba-mail01.sonusnet.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228098@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C42DF5E46@ESESSCMS0356.eemea.ericsson.se> <4F8ECB82.7070805@ericsson.com> <4F9C12BC.8080203@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 29 Apr 2012 19:23:46 +0200 Message-ID: To: Salvatore Loreto Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnukiFTsXPm+BFwQPO+RU39n/1V8lEwohjsFgwFCmedn6aPPofilkRXNwSRs6yPTudJe5+G Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Stateless or Transaction stateful proxy possible in Websocket transport? [RE: Call for Adoption: draft-ibc-sipcore-sip-websocket-02] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 17:24:08 -0000 2012/4/28 Salvatore Loreto : > BTW: "SIP transport" is also an interesting definition, indeed WebSocket = is > not a transport protocol > but can be used to transport SIP message as well as other stuff. > > I would hear the opinion of the Chairs about this, > if they are OK to define (and talk in this draft of) WebSocket I will shu= t > up! > Chairs? Hi Salvatore, I expect that this subject has been already taked into account by chairs since they declared (after IETF 83) a new SIPCORE WG milestone: Apr 2013 WebSockets transport definition for SIP to the IESG (proposed standard) :) > > So honestly I see no "interaction/translations that happens between > > the WebSocket server and the SIP proxy". > So honestly I don't buy your explanation. Without more arguments I cannot give a better explanation. However I would like to clarify that this is not about having a Apache web server with "mod_websocket" enabled, and passing SIP messages received via the WebSocket connection to a "real" SIP proxy using some proprietary/custom communication. This is not what this specification attempts to achieve. The draft states (in "Definitions" section): SIP WebSocket Server: A SIP entity capable of listening for inbound connections from WebSocket clients and speaking the WebSocket SIP Sub-Protocol as defined by this document. So, this SIP entity includes a WebSocket server for SIP-over-WebSocket in the same way it includes a TCP server for SIP-over-TCP or a UDP socket for SIP-over-UDP. And therefore the SIP entity and the WebSocket server are not two logical independent entities (not when we are speaking about a "SIP WebSocket Client" or a "SIP WebSocket Server"). This is what the draft talks about, and not about communication between WebSocket servers and SIP entities. Best regards. --=20 I=C3=B1aki Baz Castillo From salvatore.loreto@ericsson.com Sun Apr 29 10:44:55 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FBC21F854A for ; Sun, 29 Apr 2012 10:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.93 X-Spam-Level: X-Spam-Status: No, score=-105.93 tagged_above=-999 required=5 tests=[AWL=-0.581, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 YWVdYcd6VrVh for ; Sun, 29 Apr 2012 10:44:55 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id D233421F852E for ; Sun, 29 Apr 2012 10:44:54 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-c9-4f9d7e150184 Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0256"; auth=fail (cipher=AES128-SHA) Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0256", Issuer "esessmw0256" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 17.AB.26681.51E7D9F4; Sun, 29 Apr 2012 19:44:53 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Sun, 29 Apr 2012 19:44:53 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 41F222323; Sun, 29 Apr 2012 20:44:53 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2933B52960; Sun, 29 Apr 2012 20:44:53 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8AE6752871; Sun, 29 Apr 2012 20:44:52 +0300 (EEST) Message-ID: <4F9D7E13.3080809@ericsson.com> Date: Sun, 29 Apr 2012 19:44:51 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4F9C0B48.4020606@ericsson.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - Review comments (Nataraju A B) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 17:44:55 -0000 On 4/29/12 7:07 PM, IƱaki Baz Castillo wrote: > 2012/4/28 Salvatore Loreto: >> WebSocket is not a transport protocol, but a protocol that is used to >> transport content as HTTP is. >> WebSocket can run on top of TCP (WS) or on top of TLC (WSS). >> >> So once again please do not say WebSocket is a transport protocol because it >> is not! > Hi Salvatore,let me clarify this subject. The draft defines two things: > > 1) A WebSocket Sub-Protocol called "sip". that is OK and I am not arguing against point 1. > > 2) A new SIP transport called "WebSocket". I am not comfortable with this point, but maybe it is just me be a purist > > > The SIP transport defined by this draft is WebSocket. WebSocket is, > indeed, a layer on top of a network transport (layer 3) but it's > designed to work as a *transport* layer since it defines a framing > mechanism to send application messages and control mesages in both > directions. Applications (i.e. JavaScript scripts, PHP/Java web apps) > use WebSocket as a transport layer. my point is that there is a difference between an application transport layer and a transport protocol! > > There are other cases in which a transport runs on top of other > transports. For example, in the recent IETF #83 the RTCWEB WG approved > (or discussed) SCTP-over-DTLS-over-ICE-over-UDP as the transport for > the WebRTC Data-Channel mechanism. In some cases a "transport" does > not necessarily mean "layer 3 network transport". this is slightly different in RTCWeb the Data-Channel all the stack if formed by different transport protocols however the fact the part of them run in the user-land space and then encapsulated in UDP introduce some limitation to the SCTP futures etc. but the UDP is still used in the full way on each side there is a huge list of examples in literature of transport protocols designed and run on top of UDP due to the flexibility of this transport protocol (e.g. pseud TCP protocols etc.) > > So, regardless WebSocket is not a layer 3 transport, it's used as a > transport by this specification and therefore it's considered a "SIP > transport". > > Regards. > > > From salvatore.loreto@ericsson.com Sun Apr 29 11:02:35 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCB421F84D5 for ; Sun, 29 Apr 2012 11:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.36 X-Spam-Level: X-Spam-Status: No, score=-106.36 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 nEPc0sH-tcJk for ; Sun, 29 Apr 2012 11:02:34 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 55A3221F8472 for ; Sun, 29 Apr 2012 11:02:33 -0700 (PDT) X-AuditID: c1b4fb30-b7b07ae000006839-be-4f9d8238a106 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A1.8C.26681.8328D9F4; Sun, 29 Apr 2012 20:02:33 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Sun, 29 Apr 2012 20:02:31 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 278492323 for ; Sun, 29 Apr 2012 21:02:32 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1E1A352960 for ; Sun, 29 Apr 2012 21:02:32 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A2B0952871 for ; Sun, 29 Apr 2012 21:02:31 +0300 (EEST) Message-ID: <4F9D8236.80005@ericsson.com> Date: Sun, 29 Apr 2012 20:02:30 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="------------000604080400040109030903" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] WebSocket in a Browser and outside it (was Re: draft-ibc-sipcore-sip-websocket-02.txt ) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 18:02:35 -0000 --------------000604080400040109030903 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 5.2.3. Sending Responses This specification updates the section 18.2.2 "Sending Responses" in [RFC3261] by adding the following: o If the Via "sent-protocol" is "WS" or "WSS" the response MUST be sent using the existing WebSocket connection to the source of the original request that created the transaction, if that connection is still open. If that connection is no longer open, the server SHOULD NOT attempt to open a WebSocket connection for sending the response. This is due to the nature of the WebSocket protocol in which just the WebSocket client can establish a connection with the WebSocket server. Typically a WebSocket client does not listen for inbound connections and WebSocket servers do not open outbound connections. The last paragraph of this section confuses the limitation of the WebSocketProtocol implemented in a Browser as a general limitation. It is tautological saying that a WebSocket Client can act only as a client, however in theory a UA (outside a Browser sandbox) could act as both a WebSocket client and WebSocket server. As the authors have several time claimed that they want define the usage of SIP on top of WebSocket for the most general scenario and not only for the Browser/JavaScript, I would invite to be more clear /Salvatore --------------000604080400040109030903 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit 
5.2.3.  Sending Responses

   This specification updates the section 18.2.2 "Sending Responses" in
   [RFC3261] by adding the following:

   o  If the Via "sent-protocol" is "WS" or "WSS" the response MUST be
      sent using the existing WebSocket connection to the source of the
      original request that created the transaction, if that connection
      is still open.  If that connection is no longer open, the server
      SHOULD NOT attempt to open a WebSocket connection for sending the
      response.


      This is due to the nature of the WebSocket protocol in which just
      the WebSocket client can establish a connection with the WebSocket
      server.  Typically a WebSocket client does not listen for inbound
      connections and WebSocket servers do not open outbound
      connections.
The last paragraph of this section confuses the limitation of the WebSocketProtocol
implemented in a Browser as a general limitation.
It is tautological saying that a WebSocket Client can act only as a client,
however in theory a UA (outside a Browser sandbox) could act as both a WebSocket client and WebSocket server.

As the authors have several time claimed that they want define the usage of SIP on top of WebSocket for the most
general scenario and not only for the Browser/JavaScript, I would invite to be more clear

/Salvatore

--------------000604080400040109030903-- From ibc@aliax.net Sun Apr 29 11:08:45 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF6F21F84EE for ; Sun, 29 Apr 2012 11:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXdar1AUEjLA for ; Sun, 29 Apr 2012 11:08:44 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DEDC621F84EC for ; Sun, 29 Apr 2012 11:08:37 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1924415vcb.31 for ; Sun, 29 Apr 2012 11:08:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=fHsZM1DSSZn2dhYJtkulSqvuKLriiPYvmCGw44ZuxuM=; b=DBeRuaHjs7Aor103Oks7qT+X60lxchInsQW+5Q29b5YJctc/haSQtdfyWPZxfzXZYQ Elq3kThXum0C9VuOxaSfPftBY+94PeW8Af9YDF7F9E3bCOivVeMlrnCZlqDowuyVx3Jn 5uMd8n9F7k3VYLR0vz0W6Jy17fJCmKrDykj2E+JKLWWTVO0xaPpJUbt1EtBjiFf8vRj1 Y9NAemWF3nXk2zKv+NKwPEKMbDOrE7fWSsvFdzl48ED10NX9eVTO4lY1P4mwWJb+qu9U EsoM/xHe4J6uohxllLZhKhVSdgOgrBb/njIxafX8xFokfjDwMJT/+ww3XXF8YK2whEVA fnfA== Received: by 10.52.94.34 with SMTP id cz2mr1658513vdb.100.1335722917228; Sun, 29 Apr 2012 11:08:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.199 with HTTP; Sun, 29 Apr 2012 11:08:17 -0700 (PDT) In-Reply-To: <4F9D7E13.3080809@ericsson.com> References: <4F9C0B48.4020606@ericsson.com> <4F9D7E13.3080809@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 29 Apr 2012 20:08:17 +0200 Message-ID: To: Salvatore Loreto Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk6pU7/vawJWhGmhLWeWTgYXFAERhKYAzYdYTHXdhWNryATs0qF4u0Czqqfc0DeKdFT8s6+ Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ibc-sipcore-sip-websocket-02.txt - Review comments (Nataraju A B) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 18:08:45 -0000 2012/4/29 Salvatore Loreto : >> 2) A new SIP transport called "WebSocket". > > I am not comfortable with this point, but maybe it is just me be a purist A "SIP transport" involves VIA transport values, SIP URI's transport parameter value, DNS resolution (locating servers, NAPTR/SRV records, default ports), secure or not secure transport, reliable transport or not (so different timers in RFC 3261 are taken depending on that), and so on. That is what I mean with "SIP transport", and not just the layer through which messages are transmitted/carried/transported. Is it ok with this definition? :) --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Sun Apr 29 11:14:06 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E69E21F852D for ; Sun, 29 Apr 2012 11:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, 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 D6n40S1PV4LZ for ; Sun, 29 Apr 2012 11:14:06 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D0DCF21F84EE for ; Sun, 29 Apr 2012 11:14:05 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1926183vcb.31 for ; Sun, 29 Apr 2012 11:14:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=HlTc4uHTw65GK8G4bXg0PVoncukiqqzSZOd+bPxqJPQ=; b=OO28xFt1H2efVd7WjEfoljMQHnTeXA+ZVfLZ/SHS+zpzVw3vYWthCjc97KfESL911j o9Ko5IfK+0+VAeIvPFI4wx6VjW3MLBnVTVPf4QHVzp3IhXyOtz3LWEEXE0q8bwYM4f21 0THtBGt4ZF3r9vzHnTW0IYtm7Bk6ejT8wHiNbfrNN1OQWzgWQZU70hU/nTPa3akymNhK UJFDyck6Br+kQCsCihwhCY7/yF1QRcTFLDvEVT2X9xmd5Ct5h0Pc5+gQpiTubQ91RGKA hLy4hIo+oDqNkWL6dKLnCN5dEXaFIvbnbIP3dx0g9jyTidBnEbrd53iLNcSRCGDLtyHx 2OfQ== Received: by 10.220.215.203 with SMTP id hf11mr14504645vcb.0.1335723245032; Sun, 29 Apr 2012 11:14:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.199 with HTTP; Sun, 29 Apr 2012 11:13:44 -0700 (PDT) In-Reply-To: <4F9D8236.80005@ericsson.com> References: <4F9D8236.80005@ericsson.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 29 Apr 2012 20:13:44 +0200 Message-ID: To: Salvatore Loreto Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl7HeQe7RVIJxYIZEuRUqab1enpbbcUXsJsuGxMdxEyyeJjQyVHRXuLtL2FS9kXc94qeeTa Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WebSocket in a Browser and outside it (was Re: draft-ibc-sipcore-sip-websocket-02.txt ) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 18:14:06 -0000 2012/4/29 Salvatore Loreto : > 5.2.3. Sending Responses > > This specification updates the section 18.2.2 "Sending Responses" in > [RFC3261] by adding the following: > > o If the Via "sent-protocol" is "WS" or "WSS" the response MUST be > sent using the existing WebSocket connection to the source of the > original request that created the transaction, if that connection > is still open. If that connection is no longer open, the server > SHOULD NOT attempt to open a WebSocket connection for sending the > response. > > > This is due to the nature of the WebSocket protocol in which just > the WebSocket client can establish a connection with the WebSocket > server. Typically a WebSocket client does not listen for inbound > connections and WebSocket servers do not open outbound > connections. > > > > The last paragraph of this section confuses the limitation of the > WebSocketProtocol > implemented in a Browser as a general limitation. > It is tautological saying that a WebSocket Client can act only as a clien= t, > however in theory a UA (outside a Browser sandbox) could act as both a > WebSocket client and WebSocket server. > > As the authors have several time claimed that they want define the usage = of > SIP on top of WebSocket for the most > general scenario and not only for the Browser/JavaScript, I would invite = to > be more clear Very good point, the authors already discussed about that exact point and decided to keep it for now until further discussion takes place. IMHO you are right and the best I can suggest is just removing section 5.2.3. As you say, if a SIP UA implements a WebSocket client and server, it has no problems in receiving responses in a new inbound WS connection. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From internet-drafts@ietf.org Mon Apr 30 12:28:37 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADF321F88CA; Mon, 30 Apr 2012 12:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, 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 7dDI1MmBQ6DO; Mon, 30 Apr 2012 12:28:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AEB21F8764; Mon, 30 Apr 2012 12:28:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120430192836.5254.54014.idtracker@ietfa.amsl.com> Date: Mon, 30 Apr 2012 12:28:36 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc3265bis-09.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 19:28:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Work= ing Group of the IETF. Title : SIP-Specific Event Notification Author(s) : Adam Roach Filename : draft-ietf-sipcore-rfc3265bis-09.txt Pages : 53 Date : 2012-04-30 This document describes an extension to the Session Initiation Protocol (SIP) defined by RFC 3261. The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-09.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc3265bis/ From adam@nostrum.com Mon Apr 30 12:28:46 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC9221E802B for ; Mon, 30 Apr 2012 12:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, SPF_PASS=-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 lJ+4NhLzD3Cp for ; Mon, 30 Apr 2012 12:28:45 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 995D921E8025 for ; Mon, 30 Apr 2012 12:28:45 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q3UJShwR048295 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Apr 2012 14:28:43 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4F9EE7EB.5030109@nostrum.com> Date: Mon, 30 Apr 2012 14:28:43 -0500 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" References: <4F870EAC.3030900@nostrum.com> In-Reply-To: <4F870EAC.3030900@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Robert Sparks Subject: Re: [sipcore] RFC3265bis: reason code registration policy X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 19:28:46 -0000 [as chair] Lacking any feedback on this topic, the document has been revised according to IESG feedback. The new text appears in section 7.2 of draft-ietf-sipcore-rfc3265bis-09: Registrations with the IANA include the reason code being registered and a reference to a published document which describes the event package. Insertion of such values takes place as part of the RFC publication process or as the result of inter-SDO liaison activity, the result of which will be publication of an associated RFC. New reason codes must conform to the syntax of the ABNF "token" element defined in [RFC3261]. At this point, any objections to the text should be brought to the attention of the SIPCORE chairs and our RAI AD (presently Robert Sparks). Thank you. /a On 4/12/12 12:19 PM, Adam Roach wrote: > [as document author] > > As you probably know, RFC3265bis has been handed off to the IESG for > pre-publication evaluation. > > Section 7.2 of the RFC3265bis document discusses the new IANA registry > for the "reason" code. The gen-art review of this document turned up > the following discrepancy: > > * 'Following the policies outlined in "Guidelines for Writing an IANA > Considerations Section in RFCs" [RFC5226], new reason codes require > a Standards Action.' > > * ' Insertion of such values takes place as part of the RFC > publication process or as the result of inter-SDO liaison activity.' > > > The problem is that the "Standards Action" requirement is defined: > "Values are assigned only for Standards Track RFCs approved by the > IESG," which implies that inter-SDO liaising isn't sufficient for > adding values. > > I can't find any relic of this issue being discussed on the mailing > list, and have no specific recollection how we arrived at the current > text. Keep in mind that the need to expand these reason codes should > be very slight (we've only had one in nine years since 3265 was > published), and will almost certainly be paired with protocol changes > that RFC 5727 would require an RFC for anyway. > > Based on those two factors (and especially the second one), I think > what we probably want to do is remove the phrase "of as the result of > inter-SDO liaison activity," and leave the policy "Standards Action" > as currently stated. > > Please raise any objections to this proposed course of action on the > SIPCORE mailing list. I will make sure the results of any on-list > discussion are brought to the attention of the IESG. > > /a > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Mon Apr 30 12:35:50 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FFB21E8025 for ; Mon, 30 Apr 2012 12:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.856 X-Spam-Level: X-Spam-Status: No, score=-101.856 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, MISSING_HEADERS=1.292, SPF_PASS=-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 p5o6z-wLzRgW for ; Mon, 30 Apr 2012 12:35:50 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EF43921E8024 for ; Mon, 30 Apr 2012 12:35:49 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q3UJZnEW049673 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 30 Apr 2012 14:35:49 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4F9EE994.20003@nostrum.com> Date: Mon, 30 Apr 2012 14:35:48 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 CC: sipcore@ietf.org References: <20120430192836.5254.54014.idtracker@ietfa.amsl.com> In-Reply-To: <20120430192836.5254.54014.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rfc3265bis-09.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Apr 2012 19:35:50 -0000 [as a draft author] This version represents revisions due to IESG feedback. See for specific IESG comments leading to the changes. See for the actual draft changes. Thank you. /a On 4/30/12 2:28 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. > > Title : SIP-Specific Event Notification > Author(s) : Adam Roach > Filename : draft-ietf-sipcore-rfc3265bis-09.txt > Pages : 53 > Date : 2012-04-30 > > This document describes an extension to the Session Initiation > Protocol (SIP) defined by RFC 3261. The purpose of this extension is > to provide an extensible framework by which SIP nodes can request > notification from remote nodes indicating that certain events have > occurred. > > Note that the event notification mechanisms defined herein are NOT > intended to be a general-purpose infrastructure for all classes of > event subscription and notification. > > This document represents a backwards-compatible improvement on the > original mechanism described by RFC 3265, taking into account several > years of implementation experience. Accordingly, this document > obsoletes RFC 3265. This document also updates RFC 4660 slightly to > accommodate some small changes to the mechanism that were discussed > in that document. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-09.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-09.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc3265bis/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From internet-drafts@ietf.org Mon Apr 30 19:14:57 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5698521F8737; Mon, 30 Apr 2012 19:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, 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 0QCDQvneXJSm; Mon, 30 Apr 2012 19:14:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F52F21F8721; Mon, 30 Apr 2012 19:14:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120501021456.29980.42006.idtracker@ietfa.amsl.com> Date: Mon, 30 Apr 2012 19:14:56 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 02:14:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Work= ing Group of the IETF. Title : An Extension to the Session Initiation Protocol (SIP) fo= r Request History Information Author(s) : Mary Barnes Francois Audet Shida Schubert Detecon International Gmbh Christer Holmberg Filename : draft-ietf-sipcore-rfc4244bis-08.txt Pages : 67 Date : 2012-04-30 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this specification defines a value for the Privacy header field that directs the anonymization of values in the History-Info header field This document obsoletes RFC 4244. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-08.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc4244bis/