From stpeter@stpeter.im Tue Jun 11 12:22:43 2013 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 2EE9721F99D9 for ; Tue, 11 Jun 2013 12:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dit9CM-BxFos for ; Tue, 11 Jun 2013 12:22:38 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3509121F99D3 for ; Tue, 11 Jun 2013 12:22:38 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5311740393; Tue, 11 Jun 2013 13:36:03 -0600 (MDT) Message-ID: <51B778F5.4010703@stpeter.im> Date: Tue, 11 Jun 2013 13:22:29 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: sipcore@ietf.org References: <51AE771F.6080005@stpeter.im> In-Reply-To: <51AE771F.6080005@stpeter.im> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <51AE771F.6080005@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [sipcore] Fwd: [POSH] PKIX Over Secure HTTP (POSH) 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, 11 Jun 2013 19:22:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Perhaps of interest here given recent discussions about server identity checking in SIP... - -------- Original Message -------- Subject: [POSH] PKIX Over Secure HTTP (POSH) Date: Tue, 04 Jun 2013 17:24:15 -0600 From: Peter Saint-Andre To: posh@ietf.org Matt Miller and I have been working on a specification for "PKIX Over Secure HTTP" (POSH), which aims to make it easier to ensure proper TLS server identity checking in multi-tenanted environments (where it's basically impossible right now): https://datatracker.ietf.org/doc/draft-miller-posh/ As the abstract says: This document defines two methods that make it easier to deploy certificates for proper server identity checking in application protocols. The first method enables a TLS client to obtain a TLS server's end-entity certificate over secure HTTP as an alternative to standard Public Key Infrastructure using X.509 (PKIX) and DNS-Based Authentication of Named Entities (DANE). The second method enables a source domain to securely delegate an application to a derived domain using HTTPS redirects. We love PKIX (really!), we love DNSSEC, and we love DANE (which solves some of the same problems for some application protocols as POSH does). However, we want a technology that can be deployed more quickly than DANE in order to solve pressing operational security issues with standard PKIX in multi-tenanted environments. This effort emerged from the XMPP community, but we have heard from folks working on other application technologies that it might be useful for things like IMAP and SMTP, thus the more generalized version of POSH that we published today (superseding draft-miller-xmpp-posh-prooftype). We are planning to hold a BoF on this topic in Berlin, but in the meantime comments are very much welcome. Please post your feedback to the new posh@ietf.org list: https://www.ietf.org/mailman/listinfo/posh Thanks! Peter _______________________________________________ posh mailing list posh@ietf.org https://www.ietf.org/mailman/listinfo/posh -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRt3j1AAoJEOoGpJErxa2pZLAP/3iaWo6yiMRfndWYDs2xytng hHwzukYQGiwzHsKYBDdmB15QzquaslVEHj1nSzR6S4JGZtEQj8as0/N9LuHinZr8 UjWDPs3iBwV0RjKyUxfIwksTbJ6K0BWj7gwOhtCHxWTd4ElCKz3tzSB93gTT1Aos pdaU/5nKCfmZfwM6rcTi2vKk8Q4lyNIXLRCWXtZbSqWD36AR9OARncgKAvb+VMdT w0DD1YnZSIRl/P6bXVZWPOvJ6Pr6PHw4L/BCuIwB6h0GZYLhqRb7qbQeAVFHLfQw LrZTIDyeLWQORqmHvVC1Ri6cuUOw2jJkh0mLKVZAv2wl+H6c4+BuDpdKV4xEHEKK clt8woGtQGbkccZrieC0Yr6Yn8K9od2ID4REB/sGllRHW3sQVIpDwKQXxw5j8+16 AzvkFaiOYDMjFXxVHHSIUY2kCTzgxxIYlcU1TfUwXWd6b1v3aJyRpFv+xGfii7TK wIOY3rGF8unlrVCV53A1/7LIV0nLrZbt7uEorjxYHab68ybEAHplroXi+szvAOmP dTUTijEZETgLzg6/HmdNexT2/4kI4Qihj8kis2EaUlGtFrkLxGm44UMxzz33TuiU YOlOIYSaPyGU6v0qrFloAHHVvv6nWCzcmEgxYQQxqE3Yb05/0di4+Gk8VkwSwTeJ A4jgYEdvkvif2SYy41aG =9S40 -----END PGP SIGNATURE----- From internet-drafts@ietf.org Wed Jun 12 18:17:11 2013 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 8BF7021F8F87; Wed, 12 Jun 2013 18:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POin1Se8B0ip; Wed, 12 Jun 2013 18:17:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B635721F8ECB; Wed, 12 Jun 2013 18:17:08 -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.51.p2 Message-ID: <20130613011708.18316.28106.idtracker@ietfa.amsl.com> Date: Wed, 12 Jun 2013 18:17:08 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-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: Thu, 13 Jun 2013 01:17:11 -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 Working = Group of the IETF. Title : The WebSocket Protocol as a Transport for the Session In= itiation Protocol (SIP) Author(s) : Inaki Baz Castillo Jose Luis Millan Villegas Victor Pascual Filename : draft-ietf-sipcore-sip-websocket-09.txt Pages : 25 Date : 2013-06-12 Abstract: The WebSocket protocol enables two-way realtime communication between clients and servers in web-based applications. This document specifies a WebSocket sub-protocol as a reliable transport mechanism between SIP (Session Initiation Protocol) entities to enable usage of SIP in web-oriented deployments. This document normatively updates RFC 3261. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ibc@aliax.net Wed Jun 12 18:23:11 2013 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 91B7B21E8095 for ; Wed, 12 Jun 2013 18:23:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-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 0lv1jOW3plc3 for ; Wed, 12 Jun 2013 18:23:09 -0700 (PDT) Received: from mail-qa0-x22c.google.com (mail-qa0-x22c.google.com [IPv6:2607:f8b0:400d:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D122321E8056 for ; Wed, 12 Jun 2013 18:23:04 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id j8so756142qah.3 for ; Wed, 12 Jun 2013 18:23: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 :content-type:content-transfer-encoding:x-gm-message-state; bh=VkRkHOjvanusaQS4me0rGXJVPMPvdcfgILsSvoIoNYk=; b=TFQppvWarn8dp5hnL+aIqVp0u1zlTCSuRXD8udR1FmcOchh2qtFeDTCOhdp4b4Faqb Czq+Czka5KO8r5g43+ZjdALhCuxwR1cuzS4dx6DbXBCybqs+7xIIOOi6rqwS+sXFKO2O M564t4G5FUC3OZJFsVxi2Kury3g+/NBjFQr/vVEmypN6HBLfR47U0kvobYKGoe2GXAyE PsNHmpRTc/WoEQ23xFeb5VeFZxNacUM4dF3P9B0gZilIaH4bw6xg2gZUSbC2dbp/CRi/ aj5ibEwTSRoJd3O2xQ8JH0o6hiX+PwdqFmQRQ+cQxwkrQgnEBuQfxd3XAXkU271yOwq+ bEYw== X-Received: by 10.224.178.200 with SMTP id bn8mr636302qab.50.1371086583883; Wed, 12 Jun 2013 18:23:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 12 Jun 2013 18:22:43 -0700 (PDT) In-Reply-To: <20130613011708.18316.28106.idtracker@ietfa.amsl.com> References: <20130613011708.18316.28106.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 13 Jun 2013 03:22:43 +0200 Message-ID: To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk5u2v1PvaWC0icf+s+3QyaCA28Hl0UnwQ7+edKGiqOMzN92E09if+hp6BdvTID0UMO6Gtb Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-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: Thu, 13 Jun 2013 01:23:11 -0000 Hi all, This new revision addresses all the issues reported in the WG since previous 08 revision. The changelog in revision 09 is the following: - Improved section "Handshake" (under "The WebSocket SIP Sub-Protocol") by mentioning the error handling when establishing a WebSocket connection (thanks to Suresh Krishnan). - Mention to RFC 4168 (SIP SCTP) removed from the "SIP URI Transport Parameter" section (reported by Suresh Krishnan). - "SIP Transport Implementation Requirements" section clarified by removing the "MAY" keyword (reported by Suresh Krishnan), and text from RFC 3261 section 18 amended (thanks to Barry Leiba). - Text about certificate validation in secure WebSocket clarified in section "Secure WebSocket Connection" within "Security Considerations" (thanks to Richard Barnes). - Section "Authentication" made normative and text about SIP/Web authentication requirement improved. - New appendix "Authentication Use Cases". Really thanks a lot for your help and comments. 2013/6/13 : > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Session Initiation Protocol Core Workin= g Group of the IETF. > > Title : The WebSocket Protocol as a Transport for the S= ession Initiation Protocol (SIP) > Author(s) : Inaki Baz Castillo > Jose Luis Millan Villegas > Victor Pascual > Filename : draft-ietf-sipcore-sip-websocket-09.txt > Pages : 25 > Date : 2013-06-12 > > Abstract: > The WebSocket protocol enables two-way realtime communication between > clients and servers in web-based applications. This document > specifies a WebSocket sub-protocol as a reliable transport mechanism > between SIP (Session Initiation Protocol) entities to enable usage of > SIP in web-oriented deployments. This document normatively updates > RFC 3261. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-09 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Jun 14 00:59:24 2013 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 E20EE21F9C48 for ; Fri, 14 Jun 2013 00:59:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-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 MXinefRw+u7H for ; Fri, 14 Jun 2013 00:59:24 -0700 (PDT) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 64E2021F9C37 for ; Fri, 14 Jun 2013 00:59:24 -0700 (PDT) Received: by mail-qa0-f48.google.com with SMTP id cm16so6266qab.0 for ; Fri, 14 Jun 2013 00:59:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=Hz2rVT5oEBmHIQ+g6OTEdYY5zdksKiZqpGvkXNGy0S8=; b=QrBSf+RBKGnNMQLrzvhuk0JzQSe1Wu4IYK8E3HMQUwj3QommpNllp5EeV1yd3/Y1lY oby0Y8FsGXfoPiquiOoMqPzsGZdhwsC+Ldy7jVL5PC0EoOOZrgsqGj1VF5erMT0eXws5 orC/WpgsEUg66lZrbCKlPcFzN9Tu9doVv5zb5Rv3NY8dGPThvjZi53NK4tXxkvwMeFLK UHZuZVoDeoadPPxcPLhMn3uTeWbFlQ0lqqVd8v3kiz0u7CKlZbaW4oGoGrhkoMLkREce UL+c+DKyOVogNGzoGQ0A7g51pcsGh3P9lm73G8Q0WRWtquQj733254c1YW5uS87TliL9 4otQ== X-Received: by 10.49.81.244 with SMTP id d20mr1155628qey.33.1371196763687; Fri, 14 Jun 2013 00:59:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Fri, 14 Jun 2013 00:59:03 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 14 Jun 2013 09:59:03 +0200 Message-ID: To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQn3Mu0zH0IgP9uYNE4pZO2BSpfcobfZhfl/jj42X2kDuRNWO+jlkPxO7/6TIi0J7O26v6ve Subject: [sipcore] Open isues in draft-ietf-sipcore-sip-websocket-09 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, 14 Jun 2013 07:59:25 -0000 Hi all, Once draft-ietf-sipcore-sip-websocket-09 has been submitted, and after some comments in the WG, I consider that there are still the following open issues (to be addressed in a new revision): 1) Remove "_This section is non-normative_" text at the top of non-normative sections. Those sections don't contain normative keywords (MUST, SHOULD) so they are indeed non-normative. No need for such an statement. 2 Decide whether the draft updates 3261 or not. After recent discussion in the WG my opinion is that if somebody wants to build a SIP UDP and/or TCP device during 2013 year, he does not need to read draft-ietf-sipcore-sip-websocket, and thus the draft does not update RFC 3261. The other point of view is that the draft makes implementation of both UDP and TCP transports non mandatory if WS is implemented. This opens the door to two solutions: a) Stating that in the draft (as currently it does). b) A new WG item for allowing other transports without requiring UDP/TCP. In draft-ietf-sipcore-sip-websocket-09 we have tryed to address all the other open issues reported by members of the WG after 08 was published. I hope changes and additions in 09 satisfy their concerns. Otherwise please let us know and we will address them in rev 10. Thanks a lot to all. -- I=C3=B1aki Baz Castillo From partha@parthasarathi.co.in Sun Jun 16 09:36:57 2013 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 435BC21F9C42 for ; Sun, 16 Jun 2013 09:36:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 dKHglxQ5L8oJ for ; Sun, 16 Jun 2013 09:36:44 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.153]) by ietfa.amsl.com (Postfix) with ESMTP id 66D4F21F9C3B for ; Sun, 16 Jun 2013 09:36:44 -0700 (PDT) Received: from userPC (unknown [122.179.30.130]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 7EFE18688F1; Sun, 16 Jun 2013 16:36:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1371400604; bh=dcULlEN9oeEkgmCGq6TvGNatEPQz3OuVRbaoNthXh+o=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=hhCb/Tu77Vv/z4cZXi7AHKWoz0YoNpqOZ+F6WhB1x0UUBggzvVHIotQscYWFngpUO fbtCpWg725LGUwgstzIFuiDZbkuone7gyL6PpFstuFLSpC11lBwCKPaqIMZC0m9LKN H9tL8fP0MLouAf6hk12XE2kdxt5yAjk0ySROAl2E= From: "Parthasarathi R" To: =?UTF-8?Q?'I=C3=B1aki_Baz_Castillo'?= , "'SIPCORE \(Session Initiation Protocol Core\) WG'" References: In-Reply-To: Date: Sun, 16 Jun 2013 22:06:30 +0530 Message-ID: <003f01ce6aaf$aabda760$0038f620$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5o1Rf7mTRuc8OlR36Wl+FsCEuOAgB2NJvw Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0205.51BDE99C.000B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.156 Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 16 Jun 2013 16:36:57 -0000 Hi Inaki, Open Item 2 comment: The current statement states that=20 " All SIP elements MUST implement at least one of the following: * Both UDP and TCP transports. * SIP WebSocket transport." I could not understand how this update resolve the issue in the = following scenario: SIP UA1 (WS only)----Proxy-----SIP UA2 (UDP/TCP) Here, the dialog is established with contact details for SIP UA1 & SIP = UA2 as follows: 1) contact: sip:sipua1@example.com;transport=3Dws 2) contact: sip:sipua2@example.com;transport=3Dtcp In case SIP UA2 wishes to send RE-INVITE towards SIP UA1, how does it = possible now as per the current update in Sec 5.2.4 of = draft-ietf-sipcore-sip-websocket-09. Apart from this, I'm fine with stating in the draft or new draft wherein = this draft is updated with new draft reference. Thanks Partha=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of I=C3=B1aki Baz Castillo > Sent: Friday, June 14, 2013 1:29 PM > To: SIPCORE (Session Initiation Protocol Core) WG > Subject: [sipcore] Open isues in draft-ietf-sipcore-sip-websocket-09 >=20 > Hi all, >=20 > Once draft-ietf-sipcore-sip-websocket-09 has been submitted, and > after some comments in the WG, I consider that there are still the > following open issues (to be addressed in a new revision): >=20 >=20 >=20 > 1) Remove "_This section is non-normative_" text at the top of > non-normative sections. >=20 > Those sections don't contain normative keywords (MUST, SHOULD) so they > are indeed non-normative. No need for such an statement. >=20 >=20 >=20 >=20 > 2 Decide whether the draft updates 3261 or not. >=20 > After recent discussion in the WG my opinion is that if somebody wants > to build a SIP UDP and/or TCP device during 2013 year, he does not > need to read draft-ietf-sipcore-sip-websocket, and thus the draft does > not update RFC 3261. >=20 > The other point of view is that the draft makes implementation of both > UDP and TCP transports non mandatory if WS is implemented. This opens > the door to two solutions: >=20 > a) Stating that in the draft (as currently it does). >=20 > b) A new WG item for allowing other transports without requiring > UDP/TCP. >=20 >=20 >=20 >=20 >=20 > In draft-ietf-sipcore-sip-websocket-09 we have tryed to address all > the other open issues reported by members of the WG after 08 was > published. I hope changes and additions in 09 satisfy their concerns. > Otherwise please let us know and we will address them in rev 10. >=20 >=20 >=20 > Thanks a lot to all. >=20 >=20 >=20 > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ibc@aliax.net Sun Jun 16 14:15:20 2013 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 0D24B21F9B8C for ; Sun, 16 Jun 2013 14:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-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 alLm0n4VFHW6 for ; Sun, 16 Jun 2013 14:15:19 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 823CE21F9B76 for ; Sun, 16 Jun 2013 14:15:18 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l10so1234032qcy.18 for ; Sun, 16 Jun 2013 14:15: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=Q5UvhPj+FjPmfOn9/6BdqwDHskMrlapPvapxgSjRmXA=; b=owemiexOC6SWMM+2jKsudcVBovn9NMg7QnrqXgKGMQCCaidX+Prr2954560OY/CNl0 ul3xFBGDk8AKAhKvJ+Y5WGEsq2tzP67W2LYvciBcYlfSiA5hhwJO7d9YLGvxOCEmNPYB lYjW97bwRhDWiopL1Bd9NBbdGlIgkYQgG4uAQcTMbPlhWGnTmYtnMq3oDtTpxGkdfg/7 pmNevHRYHstMGP9MPLHpqEwB2XOyDET4ZSCDGVf00npcdLT8o1b7u1+54GJ6LGc63SNx 6jofoiw+lC+MKUsweh35grGE8jbXZNVfR34+sn5XM2uyfOaxjU7wx4TF7QtIQuiRjqGG kFoQ== X-Received: by 10.49.85.4 with SMTP id d4mr9048044qez.10.1371417318293; Sun, 16 Jun 2013 14:15:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Sun, 16 Jun 2013 14:14:58 -0700 (PDT) In-Reply-To: <003f01ce6aaf$aabda760$0038f620$@co.in> References: <003f01ce6aaf$aabda760$0038f620$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 16 Jun 2013 23:14:58 +0200 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmsuzEmqFDUF1cc3PswX1A5K7FP282OvfvkS7tRxd754I7B6lOyR5RzKLsCcyMbcEpXw73e Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 16 Jun 2013 21:15:20 -0000 2013/6/16 Parthasarathi R : > Hi Inaki, > > Open Item 2 comment: The current statement states that > > " All SIP elements MUST implement at least one of the following: > > * Both UDP and TCP transports. > > * SIP WebSocket transport." > > I could not understand how this update resolve the issue in the following= scenario: > > SIP UA1 (WS only)----Proxy-----SIP UA2 (UDP/TCP) > > Here, the dialog is established with contact details for SIP UA1 & SIP UA= 2 as follows: > > 1) contact: sip:sipua1@example.com;transport=3Dws > 2) contact: sip:sipua2@example.com;transport=3Dtcp > > In case SIP UA2 wishes to send RE-INVITE towards SIP UA1, how does it pos= sible now as per the current update in Sec 5.2.4 of draft-ietf-sipcore-sip-= websocket-09. Hi Parthasarathi, this subject was heavily discussed during the past year. It's clear that in 99% or 100% of cases, a SIP WebSocket Client (i.e. a browser) will not be able to receive incoming WS connections (it is not a SIP WebSocket Server) and thus, the proxy in your flow has to perform record-routing, a *standard* mechanism defined in RFC 3261 for making your scenario feasible. IMHO it is not so hard to assume that when SIP over WebSocket devices are present, the proxy they connect to must perform record-routing. The same is true for clients behind NAT. Regards. -- I=C3=B1aki Baz Castillo From partha@parthasarathi.co.in Mon Jun 17 10:40:47 2013 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 88BA421F8EAE for ; Mon, 17 Jun 2013 10:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 8Bi2QG3hDqZW for ; Mon, 17 Jun 2013 10:40:43 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.238]) by ietfa.amsl.com (Postfix) with ESMTP id B01C521F8F7B for ; Mon, 17 Jun 2013 10:40:38 -0700 (PDT) Received: from userPC (unknown [122.179.79.68]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 12002638D36; Mon, 17 Jun 2013 17:40:34 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1371490837; bh=31wQ7L8Fqti8HTbTh3lQpzsprLshfWcxdwltYZGFqZ8=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=NtLsmnwXXinSgh1oyMc4Ni9GJBWb1xo5Aiu5TnkiR7Hjz8GtCvrUS3AuEfkD4xhYO uqchV5w5VDIr49v4CLAV+1Frheytc53dM2MYuR4WmIxxK4SbpTGphYKuWXek8NQRSC o2st+I39JhQPQFFhErTs8yo9VVLbyKVOA9tsr+dA= From: "Parthasarathi R" To: =?UTF-8?Q?'I=C3=B1aki_Baz_Castillo'?= References: <003f01ce6aaf$aabda760$0038f620$@co.in> In-Reply-To: Date: Mon, 17 Jun 2013 23:10:32 +0530 Message-ID: <005801ce6b81$c6669d50$5333d7f0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-Index: Ac5q1p9kA5x6TDYqR3CxVfinOWyN7gAqlLng X-CTCH-RefID: str=0001.0A0C0207.51BF4A15.009D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142 Cc: "'SIPCORE \(Session Initiation Protocol Core\) WG'" Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 17 Jun 2013 17:40:47 -0000 Hi Inaki, As you mentioned, "record-route" is the right solution and not = documented in the draft as of now. My comment is to explicitly add the = statement for clarity. Thanks Partha > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of I=C3=B1aki Baz Castillo > Sent: Monday, June 17, 2013 2:45 AM > To: Parthasarathi R > Cc: SIPCORE (Session Initiation Protocol Core) WG > Subject: Re: [sipcore] Open issues in = draft-ietf-sipcore-sip-websocket- > 09 >=20 > 2013/6/16 Parthasarathi R : > > Hi Inaki, > > > > Open Item 2 comment: The current statement states that > > > > " All SIP elements MUST implement at least one of the = following: > > > > * Both UDP and TCP transports. > > > > * SIP WebSocket transport." > > > > I could not understand how this update resolve the issue in the > following scenario: > > > > SIP UA1 (WS only)----Proxy-----SIP UA2 (UDP/TCP) > > > > Here, the dialog is established with contact details for SIP UA1 & > SIP UA2 as follows: > > > > 1) contact: sip:sipua1@example.com;transport=3Dws > > 2) contact: sip:sipua2@example.com;transport=3Dtcp > > > > In case SIP UA2 wishes to send RE-INVITE towards SIP UA1, how does = it > possible now as per the current update in Sec 5.2.4 of draft-ietf- > sipcore-sip-websocket-09. >=20 >=20 > Hi Parthasarathi, this subject was heavily discussed during the past > year. It's clear that in 99% or 100% of cases, a SIP WebSocket Client > (i.e. a browser) will not be able to receive incoming WS connections > (it is not a SIP WebSocket Server) and thus, the proxy in your flow > has to perform record-routing, a *standard* mechanism defined in RFC > 3261 for making your scenario feasible. >=20 > IMHO it is not so hard to assume that when SIP over WebSocket devices > are present, the proxy they connect to must perform record-routing. > The same is true for clients behind NAT. >=20 >=20 > Regards. >=20 >=20 > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ibc@aliax.net Mon Jun 17 10:50:18 2013 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 9ACA621F9D43 for ; Mon, 17 Jun 2013 10:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.732 X-Spam-Level: X-Spam-Status: No, score=-1.732 tagged_above=-999 required=5 tests=[AWL=-0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-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 UXHr0GAjLKwG for ; Mon, 17 Jun 2013 10:50:18 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id D0E5421F9D3D for ; Mon, 17 Jun 2013 10:50:17 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id l10so1772300qcy.32 for ; Mon, 17 Jun 2013 10:50: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=ZgiQtiPa1FxU65PVbD5LVDVeEIkcNurXp6EU9gLvG6Q=; b=oomu1oS1/CMmcx+mPKTyB+jyxyuqKVfw2+pz3i/um9AMYtWdLYAcvr+fds95SRzwC2 lZf9q9rXPcXvP3rhI2N03vl32TQCclKmusfMjoTl7ha7Hwc/rsm+FPaDYMLCoz6d1uJ7 qDHLfxpy4PJHF1Gj6c7Z+BC5p4rYG1MqO75HyCsgVj7PAi97MjJtkraJx/mVgdGi+ivG z/DV4qp92/hwpsCmx/nXHmivKAHH4BSQSfio/3gldIwdKnVOdeTKvvApSB+AE24dIEdT S15lLZPCm5vSlYatWt0jb6NSF8hNxicUndjO0+LNgoqGx9QOmu2xiSIRby0OauJat7my zI8Q== X-Received: by 10.229.168.132 with SMTP id u4mr6677502qcy.73.1371491417105; Mon, 17 Jun 2013 10:50:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Mon, 17 Jun 2013 10:49:57 -0700 (PDT) In-Reply-To: <005801ce6b81$c6669d50$5333d7f0$@co.in> References: <003f01ce6aaf$aabda760$0038f620$@co.in> <005801ce6b81$c6669d50$5333d7f0$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 17 Jun 2013 19:49:57 +0200 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkpvDJT8kmQw0w9VDHsv8MvkbnXP77i0FkcJoC9Q3c5yBbzvb+jJ/yrB8+knhRyaPXc1Qlu Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 17 Jun 2013 17:50:18 -0000 2013/6/17 Parthasarathi R : > As you mentioned, "record-route" is the right solution and not documented= in the draft as of now. My comment is to explicitly add the statement for = clarity. The draft describes a SIP transport, not a network topology. For clients behind NAT, RFC 5626 (Outbound) already describes a mechanism and requirements for clients and proxies to properly work. RFC 5626 can perfectly be applied to scenarios in which SIP-WebSocket is present. So no need to duplicate all the information provided by RFC 5626 in this draft. Anyhow, the Appendix "Implementation Guidelines" already suggests using Record-Route within the "SIP WebSocket Server Considerations" subsection: The SIP Outbound extension [RFC5626] seems an appropriate solution for this scenario. Therefore these SIP WebSocket Clients and the SIP registrar implement both the Outbound and Path [RFC3327] extensions, and the SIP proxy acts as an Outbound Edge Proxy (as defined in [RFC5626] section 3.4). And of course RFC 5626 already states that a Outbound Edge Proxy must do record-routing. I hope this draft won't become a "general tutorial for SIP and NAT". Regards. -- I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Jun 17 11:51:46 2013 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 2420421F9CFE for ; Mon, 17 Jun 2013 11:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.728 X-Spam-Level: X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-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 I9w6MbjfG4Ce for ; Mon, 17 Jun 2013 11:51:45 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5669C21F9CEA for ; Mon, 17 Jun 2013 11:51:44 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id hu16so1660944qab.8 for ; Mon, 17 Jun 2013 11:51: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=0xkv7ThPyNY0UYWsFbvgUxTfspllYNH0ABiKPYrDI54=; b=A0yW6GuHOwLB0Ck8VTL12loOSyHyuAy3FOK/78QohYqbkyvPAkJ5Wv3APII8NKG81Y Bq/sFIl7QochOESm89gU0zHHCS77vvd4/VlkLqqPt/xNmEDdJfHmryWfZ7PU4HQVGMeP MZRfBVc3RJBJOh0Hp/gyvOBUenf7fDjonUy8DWPv4WPXk0MydBEYilNATtdiSpwuA6xN aeW5x+iMxdw/Wx/I6Ub6xkaR59nuMhtTQhEZwuzBGK49CIJe9RlJXDjxT6rzEnSD55yp vT63oK3ob0jQN6QIc57JamlWDv9jEiRk2cNjXiAau79XOHqyVkwmCa66r1oSKvktziLD gDrg== X-Received: by 10.229.124.68 with SMTP id t4mr6780334qcr.93.1371495104213; Mon, 17 Jun 2013 11:51:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Mon, 17 Jun 2013 11:51:23 -0700 (PDT) In-Reply-To: <003f01ce6aaf$aabda760$0038f620$@co.in> References: <003f01ce6aaf$aabda760$0038f620$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 17 Jun 2013 20:51:23 +0200 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkXQxljtCeqdY6aku1jfePL8NT1IrkrZqU/bD/4ha+jcMPYqXIqzjqW635At3EXvnAAmpki Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 17 Jun 2013 18:51:46 -0000 2013/6/16 Parthasarathi R : > I could not understand how this update resolve the issue in the following= scenario: > > SIP UA1 (WS only)----Proxy-----SIP UA2 (UDP/TCP) > > Here, the dialog is established with contact details for SIP UA1 & SIP UA= 2 as follows: > > 1) contact: sip:sipua1@example.com;transport=3Dws > 2) contact: sip:sipua2@example.com;transport=3Dtcp > > In case SIP UA2 wishes to send RE-INVITE towards SIP UA1, how does it pos= sible now as per the current update in Sec 5.2.4 of draft-ietf-sipcore-sip-= websocket-09. Hi Parthasarathi, SIP UA1 (SCTP/UDP/TCP)----Proxy-----SIP UA2 (UDP/TCP) Here, the dialog is established with contact details for SIP UA1 & SIP UA2 as follows: 1) contact: sip:sipua1@example.com;transport=3Dsctp 2) contact: sip:sipua2@example.com;transport=3Dtcp In case SIP UA2 wishes to send RE-INVITE towards SIP UA1, please let me know in which section of RFC 4168 (SIP STCP) it is stated that the proxy must use Record-Route for the initial INVITE for this scenario to work. Regards. -- I=C3=B1aki Baz Castillo From partha@parthasarathi.co.in Tue Jun 18 09:52:47 2013 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 E1CD721F9AE8 for ; Tue, 18 Jun 2013 09:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=-0.224, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 KRM4YN6YYx7x for ; Tue, 18 Jun 2013 09:52:41 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.228]) by ietfa.amsl.com (Postfix) with ESMTP id E4E1521F9AE2 for ; Tue, 18 Jun 2013 09:52:39 -0700 (PDT) Received: from userPC (unknown [122.179.88.201]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 9D7C1190830D; Tue, 18 Jun 2013 16:52:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1371574359; bh=8aXcOIl1Yxzcm0MlLTKUYLEUqkF98XazGJVBHi0uEW0=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=hjBAgeCwkt2x2bxyjUd4SdVPJKV0u3N9YvSs7QD7UHi4m81SHoSaUOXtAR6I06VzB lybzt2GFjqhULDHP5cQaeowlgp090Xitg3kylFE71lR4nXsOofrKt++sewUlsAirzg nLJnIi/1FfUomlzoxoyXj0nS7dTOrPX8WLFiKg9M= From: "Parthasarathi R" To: =?UTF-8?Q?'I=C3=B1aki_Baz_Castillo'?= References: <003f01ce6aaf$aabda760$0038f620$@co.in> In-Reply-To: Date: Tue, 18 Jun 2013 22:22:32 +0530 Message-ID: <011e01ce6c44$3c70e290$b552a7b0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-Index: Ac5ri7mr0UDPHWK3QWqBvSgq1Y/PpQAt2lrQ X-CTCH-RefID: str=0001.0A0C0201.51C09056.01A7, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: "'SIPCORE \(Session Initiation Protocol Core\) WG'" Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 18 Jun 2013 16:52:48 -0000 Hi Inaki, I agree with you that RFC 4168 (SIP SCTP) does not explain the contact = header usage. But it does not meant that it is the best practice. My = comments is based on the later RFC namely RFC 5630 (The Use of the SIPS = URI Scheme in the Session Initiation Protocol (SIP)) and look into the = draft for the explanation and Normative statements around contact header = w.r.t SIPS URI.=20 The current text in the draft is clear to explain the usage of contact = header. It will confuse in case anybody implement by just looking into = this draft. I think that it is required for SIP over WebSocket to = explain the usage of contact header field with example and normative = statement.=20 Thanks Partha > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of I=C3=B1aki Baz Castillo > Sent: Tuesday, June 18, 2013 12:21 AM > To: Parthasarathi R > Cc: SIPCORE (Session Initiation Protocol Core) WG > Subject: Re: [sipcore] Open issues in = draft-ietf-sipcore-sip-websocket- > 09 >=20 > 2013/6/16 Parthasarathi R : > > I could not understand how this update resolve the issue in the > following scenario: > > > > SIP UA1 (WS only)----Proxy-----SIP UA2 (UDP/TCP) > > > > Here, the dialog is established with contact details for SIP UA1 & > SIP UA2 as follows: > > > > 1) contact: sip:sipua1@example.com;transport=3Dws > > 2) contact: sip:sipua2@example.com;transport=3Dtcp > > > > In case SIP UA2 wishes to send RE-INVITE towards SIP UA1, how does = it > possible now as per the current update in Sec 5.2.4 of draft-ietf- > sipcore-sip-websocket-09. >=20 >=20 > Hi Parthasarathi, >=20 > SIP UA1 (SCTP/UDP/TCP)----Proxy-----SIP UA2 (UDP/TCP) >=20 > Here, the dialog is established with contact details for SIP UA1 & SIP > UA2 as follows: >=20 > 1) contact: sip:sipua1@example.com;transport=3Dsctp > 2) contact: sip:sipua2@example.com;transport=3Dtcp >=20 > In case SIP UA2 wishes to send RE-INVITE towards SIP UA1, please let > me know in which section of RFC 4168 (SIP STCP) it is stated that the > proxy must use Record-Route for the initial INVITE for this scenario > to work. >=20 > Regards. >=20 >=20 > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From partha@parthasarathi.co.in Tue Jun 18 09:54:43 2013 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 EDC4D21F9B01 for ; Tue, 18 Jun 2013 09:54:42 -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.186, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 7LFQlTJfkHWR for ; Tue, 18 Jun 2013 09:54:38 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.228]) by ietfa.amsl.com (Postfix) with ESMTP id 6D23421E8095 for ; Tue, 18 Jun 2013 09:54:32 -0700 (PDT) Received: from userPC (unknown [122.179.88.201]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id A1362190801D; Tue, 18 Jun 2013 16:54:29 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1371574472; bh=EiCmveK8rII6OxWzev0oQCYvgCwzju3Sbit6wWrkwkM=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=KH6pLz1S6Q4HBIbHvsMM9MUZsQi54MbwjQVavrph5nSXpK/wn18i/Ygg4AXumdZD2 YwKbrtfUerSbOXKwZ6c9g+oO6aQS5WT0sHmJen5O7O81Qg7NWP2GSGd4gpgGK0kh9r D0htfVyCr0jM617tKjuzPX06Ocbl2TcUQKNzmDmM= From: "Parthasarathi R" To: =?UTF-8?Q?'I=C3=B1aki_Baz_Castillo'?= References: <003f01ce6aaf$aabda760$0038f620$@co.in> <005801ce6b81$c6669d50$5333d7f0$@co.in> In-Reply-To: Date: Tue, 18 Jun 2013 22:24:25 +0530 Message-ID: <012001ce6c44$7fcf96d0$7f6ec470$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-Index: Ac5rgySkoXwl3I19TmyScmJuVUqk1gAwSmXA X-CTCH-RefID: str=0001.0A0C0201.51C090C8.0002, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 2 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: "'SIPCORE \(Session Initiation Protocol Core\) WG'" Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 18 Jun 2013 16:54:43 -0000 Hi Inaki, I hope this draft won't become a "general tutorial for SIP and = NAT". My reported "contact" header problem is related to SIP routing issue and = not related to NAT. Thanks Partha > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of I=C3=B1aki Baz Castillo > Sent: Monday, June 17, 2013 11:20 PM > To: Parthasarathi R > Cc: SIPCORE (Session Initiation Protocol Core) WG > Subject: Re: [sipcore] Open issues in = draft-ietf-sipcore-sip-websocket- > 09 >=20 > 2013/6/17 Parthasarathi R : > > As you mentioned, "record-route" is the right solution and not > documented in the draft as of now. My comment is to explicitly add the > statement for clarity. >=20 > The draft describes a SIP transport, not a network topology. >=20 > For clients behind NAT, RFC 5626 (Outbound) already describes a > mechanism and requirements for clients and proxies to properly work. > RFC 5626 can perfectly be applied to scenarios in which SIP-WebSocket > is present. So no need to duplicate all the information provided by > RFC 5626 in this draft. >=20 > Anyhow, the Appendix "Implementation Guidelines" already suggests > using Record-Route within the "SIP WebSocket Server Considerations" > subsection: >=20 > The SIP Outbound extension [RFC5626] seems an appropriate solution > for this scenario. Therefore these SIP WebSocket Clients and the > SIP > registrar implement both the Outbound and Path [RFC3327] = extensions, > and the SIP proxy acts as an Outbound Edge Proxy (as defined in > [RFC5626] section 3.4). >=20 > And of course RFC 5626 already states that a Outbound Edge Proxy must > do record-routing. I hope this draft won't become a "general tutorial > for SIP and NAT". >=20 >=20 > Regards. >=20 > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From partha@parthasarathi.co.in Tue Jun 18 11:03:48 2013 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 1149421F9ABC for ; Tue, 18 Jun 2013 11:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 ZMuVT+suS6pI for ; Tue, 18 Jun 2013 11:03:43 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.231]) by ietfa.amsl.com (Postfix) with ESMTP id BC5B721F961F for ; Tue, 18 Jun 2013 11:03:43 -0700 (PDT) Received: from userPC (unknown [122.179.88.201]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 681A61908254; Tue, 18 Jun 2013 18:03:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1371578622; bh=J0djkYgQko8qJ6bnf8uZQEFjF1bl5xJ6zofXOmzHR7U=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=DvcFA1/3xaDVeq0hNaHhecMDh3a7cJAY7QwmXstYtYCY15Ug5kAHENFhUf+qeX8xL WOT21ou3pRiwj28P4Ojdke02/44cMm7R30qgSb7EMmShR4v+MsG443teUeQgZBg2Ej kteBC9/msDypx7++p/ULNTdKViRgHzU0mkKs04/k= From: "Parthasarathi R" To: =?UTF-8?Q?'I=C3=B1aki_Baz_Castillo'?= , "'SIPCORE \(Session Initiation Protocol Core\) WG'" References: <20130613011708.18316.28106.idtracker@ietfa.amsl.com> In-Reply-To: Date: Tue, 18 Jun 2013 23:33:35 +0530 Message-ID: <013c01ce6c4e$29e33c90$7da9b5b0$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: en-us Thread-Index: Ac5n1JRaWWULoyU7RS28nTY76xxLbAEeQnbg X-CTCH-RefID: str=0001.0A0C0209.51C0A0FE.0133, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Subject: [sipcore] No WebSocket level authentication scenario [was RE: I-D Action: draft-ietf-sipcore-sip-websocket-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: Tue, 18 Jun 2013 18:03:48 -0000 Hi Inaki & all, IIUC, The below text in Sec 7 of the draft: "If no authentication is done at WebSocket level then SIP Digest authentication is required for every SIP request coming over the WebSocket connection." has to be changed as Normative statement as follows: "If no authentication is done at WebSocket level then SIP Digest authentication MUST be done for every SIP request coming over the WebSocket connection." Please let me know in case I'm missing something. Thanks Partha > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of I=C3=B1aki Baz Castillo > Sent: Thursday, June 13, 2013 6:53 AM > To: SIPCORE (Session Initiation Protocol Core) WG > Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket- > 09.txt >=20 > Hi all, >=20 > This new revision addresses all the issues reported in the WG since > previous 08 revision. The changelog in revision 09 is the following: >=20 >=20 > - Improved section "Handshake" (under "The WebSocket SIP > Sub-Protocol") by mentioning the error handling when establishing a > WebSocket connection (thanks to Suresh Krishnan). >=20 > - Mention to RFC 4168 (SIP SCTP) removed from the "SIP URI Transport > Parameter" section (reported by Suresh Krishnan). >=20 > - "SIP Transport Implementation Requirements" section clarified by > removing the "MAY" keyword (reported by Suresh Krishnan), and text > from RFC 3261 section 18 amended (thanks to Barry Leiba). >=20 > - Text about certificate validation in secure WebSocket clarified in > section "Secure WebSocket Connection" within "Security Considerations" > (thanks to Richard Barnes). >=20 > - Section "Authentication" made normative and text about SIP/Web > authentication requirement improved. >=20 > - New appendix "Authentication Use Cases". >=20 >=20 > Really thanks a lot for your help and comments. >=20 >=20 >=20 >=20 > 2013/6/13 : > > > > 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 : The WebSocket Protocol as a Transport for > the Session Initiation Protocol (SIP) > > Author(s) : Inaki Baz Castillo > > Jose Luis Millan Villegas > > Victor Pascual > > Filename : draft-ietf-sipcore-sip-websocket-09.txt > > Pages : 25 > > Date : 2013-06-12 > > > > Abstract: > > The WebSocket protocol enables two-way realtime communication > between > > clients and servers in web-based applications. This document > > specifies a WebSocket sub-protocol as a reliable transport > mechanism > > between SIP (Session Initiation Protocol) entities to enable = usage > of > > SIP in web-oriented deployments. This document normatively > updates > > RFC 3261. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-09 > > > > A diff from the previous version is available at: > > = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-09 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 >=20 > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ibc@aliax.net Tue Jun 18 15:05:25 2013 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 411B221E80D8 for ; Tue, 18 Jun 2013 15:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.654 X-Spam-Level: X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=0.023, 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 m452XgTat4uU for ; Tue, 18 Jun 2013 15:05:21 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 821BA21E80C8 for ; Tue, 18 Jun 2013 15:05:19 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id i11so2797933qej.39 for ; Tue, 18 Jun 2013 15:05: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=uK0VWhVGVzZSXQcK6JjA3s8s7bIjzRw73ccn+NWKwH0=; b=IUJC+c1g+bTqWIGsQPaexLJf2XUvNTv7INpOc0r5+h8nJ15A1uA5gUVv9RMFVOfIHt QehpUU/G6cCHLY5mXMiMHSr2G2fl1ctvDu7tk/Af0aBtknjWV72fB3xB3z8sNZ5TY2g8 ganMmajr1KL5xtr9l1O+lsrXaFTrbeE7YonTiP2ggqeD6iMqurvp6k4D5IaRlxZLFvwh OafygEr07hQNryWxvl6a/T+xWK7PbO2q7xcrvZgK+3JdML/N2Y7elrtvXtjZmNDfbXvX 1kP3LI0AU4uw6ep0vYerewRh3mdQusH/Av2577CxoL4RBBlMP776xSgl/0JPB2vP2b6l cI5g== X-Received: by 10.49.109.72 with SMTP id hq8mr30471858qeb.38.1371593113333; Tue, 18 Jun 2013 15:05:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Tue, 18 Jun 2013 15:04:53 -0700 (PDT) In-Reply-To: <013c01ce6c4e$29e33c90$7da9b5b0$@co.in> References: <20130613011708.18316.28106.idtracker@ietfa.amsl.com> <013c01ce6c4e$29e33c90$7da9b5b0$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 19 Jun 2013 00:04:53 +0200 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQncYl76Ii/WHjZvXGTowF46N8GSoZPDmJa2zwoqDrSx5RC5c4LmqZyZjoJq59D+CKRqOQdq Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] No WebSocket level authentication scenario [was RE: I-D Action: draft-ietf-sipcore-sip-websocket-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: Tue, 18 Jun 2013 22:05:25 -0000 Right. I will modify it. Anyhow, I don't know if more changes are required in that "Authentication" section (due to pending issues in another mail thread). Thanks a lot. 2013/6/18 Parthasarathi R : > Hi Inaki & all, > > IIUC, The below text in Sec 7 of the draft: > > "If no authentication is done at WebSocket level then SIP Digest > authentication is required for every SIP request coming over the > WebSocket connection." > > has to be changed as Normative statement as follows: > > "If no authentication is done at WebSocket level then SIP Digest > authentication MUST be done for every SIP request coming over the > WebSocket connection." > > Please let me know in case I'm missing something. > > Thanks > Partha > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of I=C3=B1aki Baz Castillo >> Sent: Thursday, June 13, 2013 6:53 AM >> To: SIPCORE (Session Initiation Protocol Core) WG >> Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket- >> 09.txt >> >> Hi all, >> >> This new revision addresses all the issues reported in the WG since >> previous 08 revision. The changelog in revision 09 is the following: >> >> >> - Improved section "Handshake" (under "The WebSocket SIP >> Sub-Protocol") by mentioning the error handling when establishing a >> WebSocket connection (thanks to Suresh Krishnan). >> >> - Mention to RFC 4168 (SIP SCTP) removed from the "SIP URI Transport >> Parameter" section (reported by Suresh Krishnan). >> >> - "SIP Transport Implementation Requirements" section clarified by >> removing the "MAY" keyword (reported by Suresh Krishnan), and text >> from RFC 3261 section 18 amended (thanks to Barry Leiba). >> >> - Text about certificate validation in secure WebSocket clarified in >> section "Secure WebSocket Connection" within "Security Considerations" >> (thanks to Richard Barnes). >> >> - Section "Authentication" made normative and text about SIP/Web >> authentication requirement improved. >> >> - New appendix "Authentication Use Cases". >> >> >> Really thanks a lot for your help and comments. >> >> >> >> >> 2013/6/13 : >> > >> > 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 : The WebSocket Protocol as a Transport for >> the Session Initiation Protocol (SIP) >> > Author(s) : Inaki Baz Castillo >> > Jose Luis Millan Villegas >> > Victor Pascual >> > Filename : draft-ietf-sipcore-sip-websocket-09.txt >> > Pages : 25 >> > Date : 2013-06-12 >> > >> > Abstract: >> > The WebSocket protocol enables two-way realtime communication >> between >> > clients and servers in web-based applications. This document >> > specifies a WebSocket sub-protocol as a reliable transport >> mechanism >> > between SIP (Session Initiation Protocol) entities to enable usage >> of >> > SIP in web-oriented deployments. This document normatively >> updates >> > RFC 3261. >> > >> > >> > The IETF datatracker status page for this draft is: >> > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket >> > >> > There's also a htmlized version available at: >> > http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-09 >> > >> > A diff from the previous version is available at: >> > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-09 >> > >> > >> > Internet-Drafts are also available by anonymous FTP at: >> > ftp://ftp.ietf.org/internet-drafts/ >> > >> > _______________________________________________ >> > sipcore mailing list >> > sipcore@ietf.org >> > https://www.ietf.org/mailman/listinfo/sipcore >> >> >> >> -- >> I=C3=B1aki Baz Castillo >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Jun 18 15:56:49 2013 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 73BC921E80B6 for ; Tue, 18 Jun 2013 15:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.656 X-Spam-Level: X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=0.022, 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 jie3byNle87E for ; Tue, 18 Jun 2013 15:56:42 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 53DB721E8094 for ; Tue, 18 Jun 2013 15:56:29 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id w7so2863153qeb.32 for ; Tue, 18 Jun 2013 15:56:27 -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=Gzf9VTp8Yb89l/myQCcya2AZj5q274e04PFmBBtgsvw=; b=P9okfmk73rd4bUnShQGtPfSKf/J8pCGnKA958kuj4WUOXQxPUWdqCVnnraSFrcDMvz maT+rCiGPEWgf1a7jcusWttPay82kKLN4uHfsRqXAzkKQiergxCcD8OKGptmw/NSHRRZ FZytURH2Zfjlzn7Fd0cWZtKGK57tBoBd5JPUoKZNjz2FgkAv6ZdL3nbNH7bLwHy+l00h uHvIvMq1xmIWTcb/J/F1LLCc83RfXivZxWI6tCTB2Csw4+ANUfLp0Ugy1uCHikJu5o6+ uQC3fiK/wVY+7Q7P+Z/49Hv+jVZZIk0mcX8KAryW4In3jXmxJDhNtGNZKApt//xUrVxx dw8g== X-Received: by 10.49.109.72 with SMTP id hq8mr31473qeb.38.1371596187348; Tue, 18 Jun 2013 15:56:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Tue, 18 Jun 2013 15:56:07 -0700 (PDT) In-Reply-To: <011e01ce6c44$3c70e290$b552a7b0$@co.in> References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 19 Jun 2013 00:56:07 +0200 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQksysfBBO0e4zjNhEfY7yVdtrxOranZEWTEIB3WL3uWHLKVEEF1rcfmIbtuO9dPwUIbdNI/ Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 18 Jun 2013 22:56:49 -0000 2013/6/18 Parthasarathi R : > I think that it is required for SIP over WebSocket to explain the usage o= f contact header field with example and normative statement. Honestly I have no idea of what you mean. draft-ietf-sipcore-sip-websocket must explain how to use the SIP Contact header? Sorry but I don't understand your concern. Could you please describe it aga= in? Thanks a lot. -- I=C3=B1aki Baz Castillo From ranjit.avasarala@nsn.com Tue Jun 18 22:54:44 2013 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 2926921F9D86 for ; Tue, 18 Jun 2013 22:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[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 81SAzspl0gb6 for ; Tue, 18 Jun 2013 22:54:39 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9154521F9D7D for ; Tue, 18 Jun 2013 22:54:39 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r5J5sbKs017500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 19 Jun 2013 07:54:37 +0200 Received: from SGSIHTC002.nsn-intra.net ([10.159.225.19]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r5J5qKl8000812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 07:54:33 +0200 Received: from SGSIHTC003.nsn-intra.net (10.159.225.20) by SGSIHTC002.nsn-intra.net (10.159.225.19) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 19 Jun 2013 13:53:41 +0800 Received: from SGSIMBX001.nsn-intra.net ([169.254.1.71]) by SGSIHTC003.nsn-intra.net ([10.159.225.20]) with mapi id 14.03.0123.003; Wed, 19 Jun 2013 13:53:41 +0800 From: "Avasarala, Ranjit (NSN - IN/Bangalore)" To: =?utf-8?B?ZXh0IEnDsWFraSBCYXogQ2FzdGlsbG8=?= , Parthasarathi R Thread-Topic: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 Thread-Index: AQHObHcliKGMQna3kEGI3rQZiy9t15k8h92w Date: Wed, 19 Jun 2013 05:53:41 +0000 Message-ID: References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.225.114] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 1856 X-purgate-ID: 151667::1371621277-00002EAE-826247ED/0-0/0-0 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 19 Jun 2013 05:54:44 -0000 SGkgSW5ha2kNCg0KVXN1YWxseSBjb250YWN0IGhlYWRlciBjb250YWlucyB0aGUgYWRkcmVzcyBv biB3aGljaCB0aGUgY2FsbGVlIGNhbiByZWFjaCBjYWxsZXIuIEJ1dCB3aGVuIGEgU0lQIG1lc3Nh Z2UgaXMgc2VudCBpbiB3ZWJzb2NrZXQsIHdoYXQgaXMgdGhlIHVzZSBvZiBwdXR0aW5nIGNvbnRh Y3QgaGVhZGVyPyANCg0KU2hvdWxkIENvbnRhY3QgaGVhZGVyIGNvbnRhaW4gYnJvd3NlcidzIGFk ZHJlc3MsIHNpbmNlIFNJUCBVQSBpcyBhbnl3YXkgcGFydCBvZiBicm93c2VyIGFuZCB0aGUgY2Fs bGVlIGNhbm5vdCBhbnl3YXkgcmVhY2ggU0lQIFVBIGRpcmVjdGx5Lg0KDQpTbyBJIHRoaW5rIHRo ZXJlIG5lZWRzIHRvIGJlIHRleHQgaW4gdGhlIGRyYWZ0IGV4cGxhaW5pbmcgdGhpcyBiZWhhdmlv ci4gDQoNClJlZ2FyZHMNClJhbmppdA0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwY29yZS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgZXh0IEnDsWFraSBCYXogQ2FzdGlsbG8NClNlbnQ6IFdl ZG5lc2RheSwgSnVuZSAxOSwgMjAxMyA0OjI2IEFNDQpUbzogUGFydGhhc2FyYXRoaSBSDQpDYzog U0lQQ09SRSAoU2Vzc2lvbiBJbml0aWF0aW9uIFByb3RvY29sIENvcmUpIFdHDQpTdWJqZWN0OiBS ZTogW3NpcGNvcmVdIE9wZW4gaXNzdWVzIGluIGRyYWZ0LWlldGYtc2lwY29yZS1zaXAtd2Vic29j a2V0LTA5DQoNCjIwMTMvNi8xOCBQYXJ0aGFzYXJhdGhpIFIgPHBhcnRoYUBwYXJ0aGFzYXJhdGhp LmNvLmluPjoNCj4gSSB0aGluayB0aGF0IGl0IGlzIHJlcXVpcmVkIGZvciBTSVAgb3ZlciBXZWJT b2NrZXQgdG8gZXhwbGFpbiB0aGUgdXNhZ2Ugb2YgY29udGFjdCBoZWFkZXIgZmllbGQgd2l0aCBl eGFtcGxlIGFuZCBub3JtYXRpdmUgc3RhdGVtZW50Lg0KDQpIb25lc3RseSBJIGhhdmUgbm8gaWRl YSBvZiB3aGF0IHlvdSBtZWFuLg0KZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC13ZWJzb2NrZXQgbXVz dCBleHBsYWluIGhvdyB0byB1c2UgdGhlIFNJUA0KQ29udGFjdCBoZWFkZXI/DQoNClNvcnJ5IGJ1 dCBJIGRvbid0IHVuZGVyc3RhbmQgeW91ciBjb25jZXJuLiBDb3VsZCB5b3UgcGxlYXNlIGRlc2Ny aWJlIGl0IGFnYWluPw0KDQpUaGFua3MgYSBsb3QuDQoNCg0KLS0NCknDsWFraSBCYXogQ2FzdGls bG8NCjxpYmNAYWxpYXgubmV0Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From saul@ag-projects.com Wed Jun 19 00:14:29 2013 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 ABAEA21F9F80 for ; Wed, 19 Jun 2013 00:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.253 X-Spam-Level: X-Spam-Status: No, score=-1.253 tagged_above=-999 required=5 tests=[AWL=0.435, 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 YU0BkD1fCNM2 for ; Wed, 19 Jun 2013 00:14:23 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id E5BB921F9F82 for ; Wed, 19 Jun 2013 00:14:19 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id 7A466B35E1; Wed, 19 Jun 2013 09:14:17 +0200 (CEST) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 9F28CB017A; Wed, 19 Jun 2013 09:14:16 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: Date: Wed, 19 Jun 2013 09:14:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <12FDD6C8-F172-4B3B-A83A-211CF553DA1A@ag-projects.com> References: <20130613011708.18316.28106.idtracker@ietfa.amsl.com> <013c01ce6c4e$29e33c90$7da9b5b0$@co.in> To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1085) Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , Parthasarathi R Subject: Re: [sipcore] No WebSocket level authentication scenario [was RE: I-D Action: draft-ietf-sipcore-sip-websocket-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: Wed, 19 Jun 2013 07:14:29 -0000 Hi, After reading those 2 paragraphs a few times I have a question about = some corner case (below) On Jun 19, 2013, at 12:04 AM, I=F1aki Baz Castillo wrote: > Right. I will modify it. Anyhow, I don't know if more changes are > required in that "Authentication" section (due to pending issues in > another mail thread). >=20 > Thanks a lot. >=20 > 2013/6/18 Parthasarathi R : >> Hi Inaki & all, >>=20 >> IIUC, The below text in Sec 7 of the draft: >>=20 >> "If no authentication is done at WebSocket level then SIP Digest >> authentication is required for every SIP request coming over the >> WebSocket connection." >>=20 >> has to be changed as Normative statement as follows: >>=20 >> "If no authentication is done at WebSocket level then SIP Digest >> authentication MUST be done for every SIP request coming over the >> WebSocket connection." >>=20 >> Please let me know in case I'm missing something. >>=20 Why is authentication a MUST? Lets assume that I'm using UDP and my = proxy establishes a WS connection with a foreign domain's proxy because = of NAPTR and my proxy supports acting as a WS client. It obviously won't = be able to authenticate. If this scenario supposed to be covered? Thanks, -- Sa=FAl Ibarra Corretg=E9 AG Projects From ibc@aliax.net Wed Jun 19 04:32:36 2013 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 E2AE521F9B9E for ; Wed, 19 Jun 2013 04:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.658 X-Spam-Level: X-Spam-Status: No, score=-2.658 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngpHe4ZsTtFo for ; Wed, 19 Jun 2013 04:32:30 -0700 (PDT) Received: from mail-qe0-f50.google.com (mail-qe0-f50.google.com [209.85.128.50]) by ietfa.amsl.com (Postfix) with ESMTP id AB33921F9B8F for ; Wed, 19 Jun 2013 04:32:30 -0700 (PDT) Received: by mail-qe0-f50.google.com with SMTP id f6so3190001qej.9 for ; Wed, 19 Jun 2013 04:32: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=KbKTN2NBo7icKyVLv2ILF7j72dYbkPa6Br6+zrn+8Dg=; b=S9d+x3bp/iiZfaNh5Z679NjUYVq7li9UkoK48035z8smBm9pYbrfDMkKpyrb/OiGEE uXaHZwxk2h8djfdcBM2+nwtMi8IIWTdZSw0+Nt+QYZZk0FkMC3F6r6aD5SyjxhcbcDBA HPFsuSs6QeMYkWNNmidLVRiKJL3Doh287BAQMTFEJoxl8qh8gHIISKQBvH3RWWpa39Y5 +zWH2Fc863sKyAzgBeMyiCRCl5JxTCHjGptnleblnd4Q1J1jPM5bAvpV20GZt6j3lgg8 htkaSf22gyjWWgHIIxhQ6BAyUVaNlntxBjYtK2n9lduS5hw8XFRGhVK5TK9p4iTgiMQS bEYQ== X-Received: by 10.49.81.244 with SMTP id d20mr2800174qey.33.1371641550009; Wed, 19 Jun 2013 04:32:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 04:32:09 -0700 (PDT) In-Reply-To: <12FDD6C8-F172-4B3B-A83A-211CF553DA1A@ag-projects.com> References: <20130613011708.18316.28106.idtracker@ietfa.amsl.com> <013c01ce6c4e$29e33c90$7da9b5b0$@co.in> <12FDD6C8-F172-4B3B-A83A-211CF553DA1A@ag-projects.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Wed, 19 Jun 2013 13:32:09 +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: ALoCoQl4JRP6xvBwVYOGFNRHmvnipAio8j25OtE1gVLRydrJB2zEqZ8P1L/xQ0aeBLlko9uALcOF Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , Parthasarathi R Subject: Re: [sipcore] No WebSocket level authentication scenario [was RE: I-D Action: draft-ietf-sipcore-sip-websocket-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: Wed, 19 Jun 2013 11:32:36 -0000 2013/6/19 Sa=C3=BAl Ibarra Corretg=C3=A9 : > Why is authentication a MUST? Lets assume that I'm using UDP and my proxy= establishes a WS connection with a foreign domain's proxy because of NAPTR= and my proxy supports acting as a WS client. It obviously won't be able to= authenticate. If this scenario supposed to be covered? Honestly I agree. I cannot find in RFC 3261 (or other RFCs) a normative statement mandating authentication, regardless the request comes from a UA. In another thread we are discussing about MTI authentication mechanisms that must be implemented by SIP WS Clients and Servers. IMHO that is correct, but mandating SIP authentication or WWW authentication for ALL the scenarios seem innapropriate for me. I come back to an use case: A website (a shop) offers a widget in which the visitor can click and made a SIP call (+WebRTC) that will end in the callcenter of the company, answered by an agent that will inform the user about the product he is interested in. Why do we require WWW or SIP authentication in this scenario? If WG agrees with this, I will remove the normative statements in "Authentication" section, and instead address the MTI authentication mechanisms. -- I=C3=B1aki Baz Castillo From keith.drage@alcatel-lucent.com Wed Jun 19 05:06:47 2013 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 C290B21F9B85 for ; Wed, 19 Jun 2013 05:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, 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 F8C5iOOGnULP for ; Wed, 19 Jun 2013 05:06:41 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id F293321F9B84 for ; Wed, 19 Jun 2013 05:06:40 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r5JC6U1e024963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jun 2013 07:06:31 -0500 (CDT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r5JC6SL2005206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 08:06:29 -0400 Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 19 Jun 2013 08:06:28 -0400 Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.27]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 19 Jun 2013 14:06:10 +0200 From: "DRAGE, Keith (Keith)" To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= Thread-Topic: [sipcore] No WebSocket level authentication scenario [was RE: I-D Action: draft-ietf-sipcore-sip-websocket-09.txt] Thread-Index: AQHObODJXZqFHUE1DEqThtssXIioxZk87d6g Date: Wed, 19 Jun 2013 12:06:09 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B055194@FR712WXCHMBA10.zeu.alcatel-lucent.com> References: <20130613011708.18316.28106.idtracker@ietfa.amsl.com> <013c01ce6c4e$29e33c90$7da9b5b0$@co.in> <12FDD6C8-F172-4B3B-A83A-211CF553DA1A@ag-projects.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , Parthasarathi R Subject: Re: [sipcore] No WebSocket level authentication scenario [was RE: I-D Action: draft-ietf-sipcore-sip-websocket-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: Wed, 19 Jun 2013 12:06:47 -0000 I would not use RFC 3261 as justification for what should, or should not, b= e said about authentication. The current RFC 3261 would probably fail a sec= urity directorate review if it was attempted to be approved as an RFC now. (I'd also point out that for any security consideration of RFC 3261, one sh= ould also read RFC 5630.) So I would suggest you conduct an independent security evaluation of what i= s needed. For the use case you give: > A website (a shop) offers a widget in which the visitor can click and > made a SIP call (+WebRTC) that will end in the callcenter of the > company, answered by an agent that will inform the user about the > product he is interested in. Why do we require WWW or SIP > authentication in this scenario? I'd suggest that the issue to be discussed is what happens when the action = described results in a transaction of some form to a third party (in the SI= P case a call). The visitor then includes information that will be relayed = to the third party. Who does the third party rely on to ensure that informa= tion is authentically given by the visitor. Regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of I=F1aki Baz Castillo > Sent: 19 June 2013 12:32 > To: Sa=FAl Ibarra Corretg=E9 > Cc: SIPCORE (Session Initiation Protocol Core) WG; Parthasarathi R > Subject: Re: [sipcore] No WebSocket level authentication scenario [was RE= : > I-D Action: draft-ietf-sipcore-sip-websocket-09.txt] >=20 > 2013/6/19 Sa=FAl Ibarra Corretg=E9 : > > Why is authentication a MUST? Lets assume that I'm using UDP and my > proxy establishes a WS connection with a foreign domain's proxy because o= f > NAPTR and my proxy supports acting as a WS client. It obviously won't be > able to authenticate. If this scenario supposed to be covered? >=20 > Honestly I agree. I cannot find in RFC 3261 (or other RFCs) a > normative statement mandating authentication, regardless the request > comes from a UA. >=20 > In another thread we are discussing about MTI authentication > mechanisms that must be implemented by SIP WS Clients and Servers. > IMHO that is correct, but mandating SIP authentication or WWW > authentication for ALL the scenarios seem innapropriate for me. I come > back to an use case: >=20 > A website (a shop) offers a widget in which the visitor can click and > made a SIP call (+WebRTC) that will end in the callcenter of the > company, answered by an agent that will inform the user about the > product he is interested in. Why do we require WWW or SIP > authentication in this scenario? >=20 > If WG agrees with this, I will remove the normative statements in > "Authentication" section, and instead address the MTI authentication > mechanisms. >=20 >=20 > -- > I=F1aki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From stpeter@stpeter.im Wed Jun 19 10:11:45 2013 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 A78D621F9DB5 for ; Wed, 19 Jun 2013 10:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.126 X-Spam-Level: X-Spam-Status: No, score=-102.126 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, SARE_MLH_Stock1=0.87, 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 HwDuI-f+8byp for ; Wed, 19 Jun 2013 10:11:45 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 534BE21F9A70 for ; Wed, 19 Jun 2013 10:11:38 -0700 (PDT) Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DBAC741278; Wed, 19 Jun 2013 11:11:38 -0600 (MDT) Message-ID: <51C1E647.1040304@stpeter.im> Date: Wed, 19 Jun 2013 11:11:35 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [sipcore] Fwd: [Stox] STOX WG officially approved - charter and work plan 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, 19 Jun 2013 17:11:45 -0000 FYI. Please join the stox@ietf.org list to participate: https://www.ietf.org/mailman/listinfo/stox Peter -------- Original Message -------- Subject: [Stox] STOX WG officially approved - charter and work plan Date: Wed, 19 Jun 2013 09:57:28 +0000 From: To: CC: yana@jitsi.org Hi all, The SIP-to-XMPP (STOX) WG has now been officially approved by the IESG. Our charter can be found at . Myself (markus.isomaki@nokia.com) and Yana Stamcheva (yana@jitsi.org) will act as co-chairs. The plan outlined in the charter is that this will be a focused and relatively straight-forward effort that we aim to finish in just a few months. The charter has these milestones: Jun 2013 Accept starting-point mapping specifications as WG items Aug 2013 Start Working Group Last Call on mapping specifications Oct 2013 Submit mapping specifications to the IESG Yana and I have additionally outlined a bit more detailed plan: - June: One week consensus call on adopting the current drafts as WG items. - Latest by July 8: Submit current drafts as -00 WG drafts. - July: Ask people to comment and raise open issues about the drafts, ask co-authors to prepare presentations about open issues for IETF 87. Start recruiting reviewers and if needed, co-authors. - IETF 87: Meet for 1 hour. Discuss open issues. Agree on the deadline for reviews and WG last call on the documents. Decide if all documents can proceed in the same timeline, or whether some phasing will be needed. - By end of August: Start the official WG last call. - September - October: Process last call comments and finalize the documents for the IESG review. - IETF 88: Meet if there is interest and energy to discuss about rechartering, i.e. adding new WG items. Let us know if you have any feedback to this. I will next send a few mails to the list about specific topics such as our first milestone, i.e. the acceptance of the current drafts as WG items. Markus _______________________________________________ stox mailing list stox@ietf.org https://www.ietf.org/mailman/listinfo/stox From partha@parthasarathi.co.in Wed Jun 19 12:38:40 2013 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 3ED1321F9B85 for ; Wed, 19 Jun 2013 12:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.027, 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 fD-rpgH4HUGm for ; Wed, 19 Jun 2013 12:38:36 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [70.87.28.138]) by ietfa.amsl.com (Postfix) with ESMTP id 6E61221F9DEF for ; Wed, 19 Jun 2013 12:38:32 -0700 (PDT) Received: from userPC (unknown [122.179.32.11]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id BCEE0190830A; Wed, 19 Jun 2013 19:38:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1371670705; bh=i0vASyQqTY/CxB/Gr4egaSQIN5Nqsd6/OVRW9t91sNs=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=IIVs/ZSlkSxcnBILO6JgJ6HjtpWLD2YqDhMB0JL6+l6FMrNQBSWDrH4qMixz8lpZn bSGXJl2oxNwzcJZCEul5TdN4XH/CY0qGj12ICIw3knMZjrIxQhUOG9YYMqzMd4UKZV UxSJe1av472+Gpal9eMWzpPRLsICZzCjiUf0wbRA= From: "Parthasarathi R" To: "'Avasarala, Ranjit \(NSN - IN/Bangalore\)'" , =?UTF-8?Q?'ext_I=C3=B1aki_Baz_Castillo'?= References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> In-Reply-To: Date: Thu, 20 Jun 2013 01:08:15 +0530 Message-ID: <019a01ce6d24$8ee95670$acbc0350$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHObHcliKGMQna3kEGI3rQZiy9t15k8h92wgADmUWA= Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0206.51C208B1.00AF, ss=2, re=0.000, recu=0.000, reip=0.000, cl=2, cld=1, fgs=64 X-CTCH-VOD: Unknown X-CTCH-Spam: Suspect X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 64 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: "'SIPCORE \(Session Initiation Protocol Core\) WG'" Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 19 Jun 2013 19:38:40 -0000 Hi Inaki, Just adding to Ranjit mentioned. The text similar to the following has = to be added. "Record-route header MUST be added by SIP WebSocket Server = in case WebSocket is the only supported SIP transport between SIP = WebSocket client & server and SIP WebSocket server acts as SIP proxy"=20 Thanks Partha > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Avasarala, Ranjit (NSN - IN/Bangalore) > Sent: Wednesday, June 19, 2013 11:24 AM > To: ext I=C3=B1aki Baz Castillo; Parthasarathi R > Cc: SIPCORE (Session Initiation Protocol Core) WG > Subject: Re: [sipcore] Open issues in = draft-ietf-sipcore-sip-websocket- > 09 >=20 > Hi Inaki >=20 > Usually contact header contains the address on which the callee can > reach caller. But when a SIP message is sent in websocket, what is the > use of putting contact header? >=20 > Should Contact header contain browser's address, since SIP UA is = anyway > part of browser and the callee cannot anyway reach SIP UA directly. >=20 > So I think there needs to be text in the draft explaining this > behavior. >=20 > Regards > Ranjit >=20 >=20 >=20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of ext I=C3=B1aki Baz Castillo > Sent: Wednesday, June 19, 2013 4:26 AM > To: Parthasarathi R > Cc: SIPCORE (Session Initiation Protocol Core) WG > Subject: Re: [sipcore] Open issues in = draft-ietf-sipcore-sip-websocket- > 09 >=20 > 2013/6/18 Parthasarathi R : > > I think that it is required for SIP over WebSocket to explain the > usage of contact header field with example and normative statement. >=20 > Honestly I have no idea of what you mean. > draft-ietf-sipcore-sip-websocket must explain how to use the SIP > Contact header? >=20 > Sorry but I don't understand your concern. Could you please describe = it > again? >=20 > Thanks a lot. >=20 >=20 > -- > I=C3=B1aki 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 ibc@aliax.net Wed Jun 19 15:05:32 2013 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 A28A521F9DAD for ; Wed, 19 Jun 2013 15:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMMPu1WCyGFk for ; Wed, 19 Jun 2013 15:05:27 -0700 (PDT) Received: from mail-qe0-f48.google.com (mail-qe0-f48.google.com [209.85.128.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5D42B21F9DAC for ; Wed, 19 Jun 2013 15:05:27 -0700 (PDT) Received: by mail-qe0-f48.google.com with SMTP id 2so3534958qea.21 for ; Wed, 19 Jun 2013 15:05: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=WBlzkZ0ntohBw0taIhNkHEgS1y+dfOSWr6ETbevydM4=; b=lHwkZhTq23bFz8JpEiFQpwvneq2O4U79QI9tRMA7MCt/pg8tDo6o1gOSNk5SzLRgIY wF0swjO0EwteifMzhmtapNYk/cbZNL7kSR19jiVvedXREoIjujs0rvzpfGF8zkpHKIfh qGx973KW5gcHJlmildhTU50HaYe7DXRD5IYvMIbyjsB+ttICMVxfjai2MffHgWPV5lEo HwuLEAexVQeyA6n+EyOUxmnVrAzrLSWHdWV+dmb15k/Lxm10Rv/FYN/UHnFv7tQsdKLT baIh4SIGYXqcKYbJk6vU7l63l5UsroNCfVCZzSkIo6YmoleQWEMHkgKYyUvRNjVzfaJP IiWg== X-Received: by 10.49.35.233 with SMTP id l9mr6158690qej.23.1371679526530; Wed, 19 Jun 2013 15:05:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 15:05:06 -0700 (PDT) In-Reply-To: <019a01ce6d24$8ee95670$acbc0350$@co.in> References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> <019a01ce6d24$8ee95670$acbc0350$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 20 Jun 2013 00:05:06 +0200 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQltX9Ip6DMVqMp7EVUktRY89dRasqy13ydQuElwoihgsWGUfk2yacybzpcTCRgFufUjtma6 Cc: "Avasarala, Ranjit \(NSN - IN/Bangalore\)" , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 19 Jun 2013 22:05:32 -0000 2013/6/19 Parthasarathi R : > > Just adding to Ranjit mentioned. The text similar to the following has to= be added. "Record-route header MUST be added by SIP WebSocket Server in ca= se WebSocket is the only supported SIP transport between SIP WebSocket clie= nt & server and SIP WebSocket server acts as SIP proxy" That is just true in case the client is a web browser (a SIP WS Client but not a SIP WS Server so it can not receive incoming WS connections). So the text would be: "Record-route header MUST be added by SIP WebSocket Server in case WebSocket is the only supported SIP transport between client and server, the server acts as SIP proxy, and the client is a SIP WebSocket Client (but not a SIP WebSocket Server so it can not accept incoming WebSocket connections)." Does it sound ok? If the WG agrees with this I will add such an statement in the draft. BTW, in which section? -- I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Jun 19 15:09:45 2013 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 3C69521F9D75 for ; Wed, 19 Jun 2013 15:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.657 X-Spam-Level: X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-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 cTRIUzOerVEL for ; Wed, 19 Jun 2013 15:09:44 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A496D21F9D71 for ; Wed, 19 Jun 2013 15:09:44 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so753141qae.6 for ; Wed, 19 Jun 2013 15:09: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=EW38DLLlMgYZDtgy41UMx5AWQTmJJdxe4Szvrz7yiSg=; b=BC1pdwpQns7ZbKL93p0vx++XTB5L0AaIHCSz3uAwHnzH/T50Rw6MMNioOi9bUimyUr zGDVrrfHycWHcDFZCP2g6b7SrVNESboZzit5oo9h7uvrjW1bnTkqhycmWZyOTrGalNhg 4Iw1zOx1FukAAzpB+r5dtJx5YltgySgsbGc/AlWX1qzeIytRivtAPy1RYEVCQqVEDaR3 xkCpM9VPdG/gnkLn9ZF3QAM86eUBm+kC52Cmswp32tlyOQeGdJTVMkvVUrxhDFkVpBsM DXRRZXdMNcoy9/Ukxhzb2+6VbNiRXUa4bx+tJpdyMQrPmwvTqfgT8wHo2VnxU0PABtQ5 ZWbw== X-Received: by 10.229.124.68 with SMTP id t4mr1842415qcr.93.1371679783905; Wed, 19 Jun 2013 15:09:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 15:09:23 -0700 (PDT) In-Reply-To: References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 20 Jun 2013 00:09:23 +0200 Message-ID: To: "Avasarala, Ranjit (NSN - IN/Bangalore)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmV3IkBLQ+JJCunBBMbEXZBj13u2dpWrE1ROfyL3kGIDmwBST2sJp8x2vUSGgnbt9BSFC0o Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , Parthasarathi R Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 19 Jun 2013 22:09:45 -0000 2013/6/19 Avasarala, Ranjit (NSN - IN/Bangalore) = : > Hi Inaki > > Usually contact header contains the address on which the callee can reach= caller. But when a SIP message is sent in websocket, what is the use of pu= tting contact header? As said in my previous mail, that is just in case the client is a SIP WebSocket Client but not a SIP WebSocket Server. Anyhow, the Contact header MUST be added anyway as it can contain parameters other than just the UA's address and transport. And it must be added in an INVITE so the remote peer can create the "dialog target" and use its URI value as Request-URI for in-dialog requests. Those are SIP rules, they must be respected. > Should Contact header contain browser's address, since SIP UA is anyway p= art of browser and the callee cannot anyway reach SIP UA directly. Please take a look to the appendix B.1 of the draft: B.1. SIP WebSocket Client Considerations The JavaScript stack in web browsers does not have the ability to discover the local transport address used for originating WebSocket connections. A SIP WebSocket client running in such an environment can construct a domain name consisting of a random token followed by the ".invalid" top-level domain name, as stated in [RFC2606], and uses it within its Via and Contact headers. The Contact URI provided by SIP UAs requesting (and receiving) Outbound support is not used for routing requests to those UAs, thus it is safe to set a random domain in the Contact URI hostport. Clear? :) -- I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Jun 19 15:11:08 2013 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 A399121F9B8F for ; Wed, 19 Jun 2013 15:11:08 -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.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-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 oUY0qon5W7lr for ; Wed, 19 Jun 2013 15:11:08 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7D36521F9C53 for ; Wed, 19 Jun 2013 15:11:04 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id hu16so758331qab.15 for ; Wed, 19 Jun 2013 15:11:03 -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=08/h9OhwVda/oxiwBiB8bc4A71A+hRtdfvpzkxnFVNo=; b=Nde/4XS0VkzKKxU/l1yPTODpCPlmRaKRZWhLcVgd/daHpIx2NBtGDMOqp+PaSFlvAy osYsQTT9o+9V86Ek64RFwuCndUgCpv6U7BKR9Z6TAutIJ4KRBtrWFbbmv5zGdEon8bt4 HGy9jXD/xdiaY417qPl600xdbwV82+GJcwouB0PO10Z7nUDQ9GYW7s+4jOXwM+O00+ss tmAsrVWwftFd3DvcsaMsk3s0/8MkXeBFJ27rkwdGmNKalDedxypp2+/fRO6pVLV9whwO vdp+SwS3IQ432t+pQ5kuX6ELZcKkvJlNkJC9+XPEkRnR5/gLwVgv4xQmRtcEZwKp/SsF firg== X-Received: by 10.49.14.161 with SMTP id q1mr6135819qec.50.1371679863646; Wed, 19 Jun 2013 15:11:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.67.65 with HTTP; Wed, 19 Jun 2013 15:10:43 -0700 (PDT) In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B055194@FR712WXCHMBA10.zeu.alcatel-lucent.com> References: <20130613011708.18316.28106.idtracker@ietfa.amsl.com> <013c01ce6c4e$29e33c90$7da9b5b0$@co.in> <12FDD6C8-F172-4B3B-A83A-211CF553DA1A@ag-projects.com> <949EF20990823C4C85C18D59AA11AD8B055194@FR712WXCHMBA10.zeu.alcatel-lucent.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 20 Jun 2013 00:10:43 +0200 Message-ID: To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmGc0ql6wNn9ktyQTWiDSdH7j24TfZx9lmsalb1KeA+VppXufCjwoJuYP3pcFlVATHw5s0g Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= , Parthasarathi R Subject: Re: [sipcore] No WebSocket level authentication scenario [was RE: I-D Action: draft-ietf-sipcore-sip-websocket-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: Wed, 19 Jun 2013 22:11:08 -0000 Thanks a lot Keith, it's clear. I will address it in next revision. 2013/6/19 DRAGE, Keith (Keith) : > I would not use RFC 3261 as justification for what should, or should not,= be said about authentication. The current RFC 3261 would probably fail a s= ecurity directorate review if it was attempted to be approved as an RFC now= . > > (I'd also point out that for any security consideration of RFC 3261, one = should also read RFC 5630.) > > So I would suggest you conduct an independent security evaluation of what= is needed. > > For the use case you give: > >> A website (a shop) offers a widget in which the visitor can click and >> made a SIP call (+WebRTC) that will end in the callcenter of the >> company, answered by an agent that will inform the user about the >> product he is interested in. Why do we require WWW or SIP >> authentication in this scenario? > > I'd suggest that the issue to be discussed is what happens when the actio= n described results in a transaction of some form to a third party (in the = SIP case a call). The visitor then includes information that will be relaye= d to the third party. Who does the third party rely on to ensure that infor= mation is authentically given by the visitor. > > Regards > > Keith > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Beha= lf >> Of I=C3=B1aki Baz Castillo >> Sent: 19 June 2013 12:32 >> To: Sa=C3=BAl Ibarra Corretg=C3=A9 >> Cc: SIPCORE (Session Initiation Protocol Core) WG; Parthasarathi R >> Subject: Re: [sipcore] No WebSocket level authentication scenario [was R= E: >> I-D Action: draft-ietf-sipcore-sip-websocket-09.txt] >> >> 2013/6/19 Sa=C3=BAl Ibarra Corretg=C3=A9 : >> > Why is authentication a MUST? Lets assume that I'm using UDP and my >> proxy establishes a WS connection with a foreign domain's proxy because = of >> NAPTR and my proxy supports acting as a WS client. It obviously won't be >> able to authenticate. If this scenario supposed to be covered? >> >> Honestly I agree. I cannot find in RFC 3261 (or other RFCs) a >> normative statement mandating authentication, regardless the request >> comes from a UA. >> >> In another thread we are discussing about MTI authentication >> mechanisms that must be implemented by SIP WS Clients and Servers. >> IMHO that is correct, but mandating SIP authentication or WWW >> authentication for ALL the scenarios seem innapropriate for me. I come >> back to an use case: >> >> A website (a shop) offers a widget in which the visitor can click and >> made a SIP call (+WebRTC) that will end in the callcenter of the >> company, answered by an agent that will inform the user about the >> product he is interested in. Why do we require WWW or SIP >> authentication in this scenario? >> >> If WG agrees with this, I will remove the normative statements in >> "Authentication" section, and instead address the MTI authentication >> mechanisms. >> >> >> -- >> I=C3=B1aki Baz Castillo >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Thu Jun 20 08:57:57 2013 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 496D421F9D2A for ; Thu, 20 Jun 2013 08:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.329 X-Spam-Level: X-Spam-Status: No, score=-0.329 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXfGIeHCiK8E for ; Thu, 20 Jun 2013 08:57:51 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 4C7BB21F9CC3 for ; Thu, 20 Jun 2013 08:57:51 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by QMTA11.westchester.pa.mail.comcast.net with comcast id qcpp1l0030cZkys5Bfxqm0; Thu, 20 Jun 2013 15:57:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id qfxq1l00g3ZTu2S3WfxqYT; Thu, 20 Jun 2013 15:57:50 +0000 Message-ID: <51C3267F.8040709@alum.mit.edu> Date: Thu, 20 Jun 2013 11:57:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: sipcore@ietf.org References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> <019a01ce6d24$8ee95670$acbc0350$@co.in> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371743870; bh=gYncWq5I1t7bjLbaRD4A40p6PCyUVl2F2ZbdCoHYyMw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=E/Jg0zSKty6cJqAfSXOegVG0m9dGi0ay3RQg9Dreh+0bjorhYpCMr5pjqtfwD+Tin UuE1D803TqNTEtzu0cA1wbkqUbQTTkfh0FDXm6ohwrI1KzqecK+y48kalU2+bUE6Q6 BdnGd+944IFWztIDZnjzFtqUjPd2B3ZB6KDpRTd5YXeitOpIJuZ3pqKKgCfi/O2CT9 e7Z0eP74QeGr9DNt+TzMI614wYkTNss7S6ffABOcQyuiho1BAylGilUd3fFUHXUYrL S1o2SMvuV/NENxhGtZb6aDphcV8ipYT/Gg5tOPTbrftUgTVVY2CaPfRSWD4JHh5BDs 5TivCQyCRsgYQ== Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 20 Jun 2013 15:57:57 -0000 On 6/19/13 6:05 PM, Iñaki Baz Castillo wrote: > 2013/6/19 Parthasarathi R : >> >> Just adding to Ranjit mentioned. The text similar to the following has to be added. "Record-route header MUST be added by SIP WebSocket Server in case WebSocket is the only supported SIP transport between SIP WebSocket client & server and SIP WebSocket server acts as SIP proxy" > > That is just true in case the client is a web browser (a SIP WS Client > but not a SIP WS Server so it can not receive incoming WS > connections). So the text would be: > > "Record-route header MUST be added by SIP WebSocket Server in case > WebSocket is the only supported SIP transport between client and > server, the server acts as SIP proxy, and the client is a SIP > WebSocket Client (but not a SIP WebSocket Server so it can not accept > incoming WebSocket connections)." How will the server know that the client is not capable of being a WebSocket Server? I guess in many cases it might be able to know that because the client is a browser being controlled by scripting from the server. But in other cases ISTM that it just won't know. Thanks, Paul From pkyzivat@alum.mit.edu Thu Jun 20 09:07:23 2013 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 66CDF21F9DA2 for ; Thu, 20 Jun 2013 09:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.331 X-Spam-Level: X-Spam-Status: No, score=-0.331 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxSPVwfNHRBm for ; Thu, 20 Jun 2013 09:07:18 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 9681721F9D9F for ; Thu, 20 Jun 2013 09:07:18 -0700 (PDT) Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta05.westchester.pa.mail.comcast.net with comcast id qbjf1l0031GhbT855g7H7i; Thu, 20 Jun 2013 16:07:17 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta07.westchester.pa.mail.comcast.net with comcast id qg7H1l00c3ZTu2S3Tg7HBv; Thu, 20 Jun 2013 16:07:17 +0000 Message-ID: <51C328B6.20506@alum.mit.edu> Date: Thu, 20 Jun 2013 12:07:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: sipcore@ietf.org References: <20130613011708.18316.28106.idtracker@ietfa.amsl.com> <013c01ce6c4e$29e33c90$7da9b5b0$@co.in> <12FDD6C8-F172-4B3B-A83A-211CF553DA1A@ag-projects.com> <949EF20990823C4C85C18D59AA11AD8B055194@FR712WXCHMBA10.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B055194@FR712WXCHMBA10.zeu.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371744437; bh=/MOlJ9lS/8vzWr5Mwx8C2kWfy6On0qAxMYyQR8SY2C8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gsZOpmrenlLy7TnmGeUVYv9VfgIWfVXmkvAEt4cq2EG0N0wR8FwELSruM99c7x8yd cpZZLAHXY2rxLpTWB8gObSlQVxuhPyHIl5Qcetppp3mRdSzJD0VY5GjipjP6t3477Y tbOaBMn2Ot4sMox6gLcTgB02HU4EyQm68wPeMfd1imCmOxNOvUSr2bq6qz6yzJWJCD pl6hhDiU4DoxIXUKMmkVCs2ZdX5k6feCw5N0RpGi6Oq/WKkhL/FAzHf5NBcto3xBgN 1RoO1zi16xdGklBOFydJWvj6BKoyJ9yQXnxkFmc65N6W8uVtmr7WYfyMWQXFcVf8KE /b5c5j/I02k2w== Subject: Re: [sipcore] No WebSocket level authentication scenario [was RE: I-D Action: draft-ietf-sipcore-sip-websocket-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: Thu, 20 Jun 2013 16:07:23 -0000 On 6/19/13 8:06 AM, DRAGE, Keith (Keith) wrote: > I would not use RFC 3261 as justification for what should, or should not, be said about authentication. The current RFC 3261 would probably fail a security directorate review if it was attempted to be approved as an RFC now. > > (I'd also point out that for any security consideration of RFC 3261, one should also read RFC 5630.) > > So I would suggest you conduct an independent security evaluation of what is needed. I think we are in the midst of one with Stephen Farrell. > For the use case you give: > >> A website (a shop) offers a widget in which the visitor can click and >> made a SIP call (+WebRTC) that will end in the callcenter of the >> company, answered by an agent that will inform the user about the >> product he is interested in. Why do we require WWW or SIP >> authentication in this scenario? > > I'd suggest that the issue to be discussed is what happens when the action described results in a transaction of some form to a third party (in the SIP case a call). The visitor then includes information that will be relayed to the third party. Who does the third party rely on to ensure that information is authentically given by the visitor. I'm inclined to support Iñaki, that authentication of any sort shouldn't be Mandatory to *Use*. Individual applications can decide when they have uses that require authentication and when they don't. Thanks, Paul > Regards > > Keith > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Iñaki Baz Castillo >> Sent: 19 June 2013 12:32 >> To: Saúl Ibarra Corretgé >> Cc: SIPCORE (Session Initiation Protocol Core) WG; Parthasarathi R >> Subject: Re: [sipcore] No WebSocket level authentication scenario [was RE: >> I-D Action: draft-ietf-sipcore-sip-websocket-09.txt] >> >> 2013/6/19 Saúl Ibarra Corretgé : >>> Why is authentication a MUST? Lets assume that I'm using UDP and my >> proxy establishes a WS connection with a foreign domain's proxy because of >> NAPTR and my proxy supports acting as a WS client. It obviously won't be >> able to authenticate. If this scenario supposed to be covered? >> >> Honestly I agree. I cannot find in RFC 3261 (or other RFCs) a >> normative statement mandating authentication, regardless the request >> comes from a UA. >> >> In another thread we are discussing about MTI authentication >> mechanisms that must be implemented by SIP WS Clients and Servers. >> IMHO that is correct, but mandating SIP authentication or WWW >> authentication for ALL the scenarios seem innapropriate for me. I come >> back to an use case: >> >> A website (a shop) offers a widget in which the visitor can click and >> made a SIP call (+WebRTC) that will end in the callcenter of the >> company, answered by an agent that will inform the user about the >> product he is interested in. Why do we require WWW or SIP >> authentication in this scenario? >> >> If WG agrees with this, I will remove the normative statements in >> "Authentication" section, and instead address the MTI authentication >> mechanisms. >> >> >> -- >> Iñaki 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 partha@parthasarathi.co.in Mon Jun 24 17:41:52 2013 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 4131321F9412 for ; Mon, 24 Jun 2013 17:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i-QRK+zw7I5C for ; Mon, 24 Jun 2013 17:41:47 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.152]) by ietfa.amsl.com (Postfix) with ESMTP id D2F3621F8FE5 for ; Mon, 24 Jun 2013 17:41:47 -0700 (PDT) Received: from userPC (unknown [122.179.33.109]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 9B11086859C; Tue, 25 Jun 2013 00:41:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1372120903; bh=aWGXdrxp6LL3VxWiQWv5BU0MraFF0Ut+OMZZsK3nh+I=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=LjPaRSwqkC0A/JeE+HaWCvzZOX3Zo/yGVVLvRGiIQOFfnrhsRHrwT6kKzkp7diHNo sM5EzCPMl4qm0sCrlv4oVcUxF1Rass5ao67q0DxaMQae7EjofZN10us6O31GCxUuU9 XsxEMull6kiJW92oqPzkDFpz+UxJ3rLvJNJbhztE= From: "Parthasarathi R" To: "'Paul Kyzivat'" , References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> <019a01ce6d24$8ee95670$acbc0350$@co.in> <51C3267F.8040709@alum.mit.edu> In-Reply-To: <51C3267F.8040709@alum.mit.edu> Date: Tue, 25 Jun 2013 06:11:35 +0530 Message-ID: <002301ce713c$c2672880$47357980$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5tzvKHGxjGwUQ2QmGbGID1iM+b0gDaw1ng Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0205.51C8E747.000A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.156 Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 25 Jun 2013 00:41:52 -0000 Paul, I think that we are talking about two problems here 1) SIP routing issue because of SIP WebSocket Client has only WebSocket = as a transport (Browser scenario) a) Solution: Record-route header has to be added by SIP WebSocket = Server. =20 2) How will SIP WebSocket Server know that SIP WebSocket client supports = only SIP WebSocket as a transport? (Non-browser scenario) a) AFAIK, there is no other environment other than browser has the = limitation of not supporting UDP & TCP. In case any other environment = exists, Please let me know. b) The beauty of RFC 3261 is that there is no need to negotiate the set = of "SIP" transport protocol as it mandates for UDP, TCP. I agree that it = is an open item how to represent the list of transport supported by a = SIP UA in case of supporting WebSocket only transport scenario. But I'm = not sure whether this WG is interested in solving this issue. We need to = here from more folks and its relevant usecases. Thanks Partha > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, June 20, 2013 9:28 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] Open issues in = draft-ietf-sipcore-sip-websocket- > 09 >=20 > On 6/19/13 6:05 PM, I=C3=B1aki Baz Castillo wrote: > > 2013/6/19 Parthasarathi R : > >> > >> Just adding to Ranjit mentioned. The text similar to the following > has to be added. "Record-route header MUST be added by SIP WebSocket > Server in case WebSocket is the only supported SIP transport between > SIP WebSocket client & server and SIP WebSocket server acts as SIP > proxy" > > > > That is just true in case the client is a web browser (a SIP WS > Client > > but not a SIP WS Server so it can not receive incoming WS > > connections). So the text would be: > > > > "Record-route header MUST be added by SIP WebSocket Server in case > > WebSocket is the only supported SIP transport between client and > > server, the server acts as SIP proxy, and the client is a SIP > > WebSocket Client (but not a SIP WebSocket Server so it can not = accept > > incoming WebSocket connections)." >=20 > How will the server know that the client is not capable of being a > WebSocket Server? >=20 > I guess in many cases it might be able to know that because the client > is a browser being controlled by scripting from the server. But in > other > cases ISTM that it just won't know. >=20 > Thanks, > Paul >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From partha@parthasarathi.co.in Mon Jun 24 17:48:07 2013 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 30D2321F9DEC for ; Mon, 24 Jun 2013 17:48:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.441 X-Spam-Level: X-Spam-Status: No, score=-2.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 FAvJsWHwkAVX for ; Mon, 24 Jun 2013 17:48:02 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us3.mailhostbox.com [70.87.28.153]) by ietfa.amsl.com (Postfix) with ESMTP id CC45721F9DE8 for ; Mon, 24 Jun 2013 17:48:02 -0700 (PDT) Received: from userPC (unknown [122.179.51.111]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id D181F868818; Tue, 25 Jun 2013 00:47:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1372121282; bh=a1ScJH/SfytC6FwQZBUoL6AJzp0GT0L+xhksRncmZng=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZxCiac6/W3/R5gnLVYL/37TefEqKjxUe+NpYdptGBX4CnUtzXG6oafOJYzfUXdgzL RjNHMRkHPkWCdYef5Spm68bYS/qfGiGVwDydrua9iQ0Jpxwd9l3dhpcgB6NZqeQjsZ bmr7T5VMq4eGcwnPj60rgLc6+neoBUTBKSWJ7IEA= From: "Parthasarathi R" To: "'Paul Kyzivat'" , References: <20130613011708.18316.28106.idtracker@ietfa.amsl.com> <013c01ce6c4e$29e33c90$7da9b5b0$@co.in> <12FDD6C8-F172-4B3B-A83A-211CF553DA1A@ag-projects.com> <949EF20990823C4C85C18D59AA11AD8B055194@FR712WXCHMBA10.zeu.alcatel-lucent.com> <51C328B6.20506@alum.mit.edu> In-Reply-To: <51C328B6.20506@alum.mit.edu> Date: Tue, 25 Jun 2013 06:17:55 +0530 Message-ID: <002501ce713d$a47221d0$ed566570$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5t0EIaQjnhKj7TRVuQDcUlUQ7CgwDbL8GA Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0203.51C8E8C2.0062, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.156 Subject: Re: [sipcore] No WebSocket level authentication scenario [was RE: I-D Action: draft-ietf-sipcore-sip-websocket-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: Tue, 25 Jun 2013 00:48:07 -0000 Paul, In case it is not mandatory to use authentication, the following = statement in Sec 7 of the draft is not correct: " If no authentication is done at WebSocket level then SIP Digest authentication is required for every SIP request coming over the WebSocket connection." Please let me know your comment on the same. Thanks Partha > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, June 20, 2013 9:37 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] No WebSocket level authentication scenario [was > RE: I-D Action: draft-ietf-sipcore-sip-websocket-09.txt] >=20 > On 6/19/13 8:06 AM, DRAGE, Keith (Keith) wrote: > > I would not use RFC 3261 as justification for what should, or should > not, be said about authentication. The current RFC 3261 would probably > fail a security directorate review if it was attempted to be approved > as an RFC now. > > > > (I'd also point out that for any security consideration of RFC 3261, > one should also read RFC 5630.) > > > > So I would suggest you conduct an independent security evaluation of > what is needed. >=20 > I think we are in the midst of one with Stephen Farrell. >=20 > > For the use case you give: > > > >> A website (a shop) offers a widget in which the visitor can click > and > >> made a SIP call (+WebRTC) that will end in the callcenter of the > >> company, answered by an agent that will inform the user about the > >> product he is interested in. Why do we require WWW or SIP > >> authentication in this scenario? > > > > I'd suggest that the issue to be discussed is what happens when the > action described results in a transaction of some form to a third = party > (in the SIP case a call). The visitor then includes information that > will be relayed to the third party. Who does the third party rely on = to > ensure that information is authentically given by the visitor. >=20 > I'm inclined to support I=F1aki, that authentication of any sort > shouldn't > be Mandatory to *Use*. Individual applications can decide when they > have uses that require authentication and when they don't. >=20 > Thanks, > Paul >=20 > > Regards > > > > Keith > > > > > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf > >> Of I=F1aki Baz Castillo > >> Sent: 19 June 2013 12:32 > >> To: Sa=FAl Ibarra Corretg=E9 > >> Cc: SIPCORE (Session Initiation Protocol Core) WG; Parthasarathi R > >> Subject: Re: [sipcore] No WebSocket level authentication scenario > [was RE: > >> I-D Action: draft-ietf-sipcore-sip-websocket-09.txt] > >> > >> 2013/6/19 Sa=FAl Ibarra Corretg=E9 : > >>> Why is authentication a MUST? Lets assume that I'm using UDP and = my > >> proxy establishes a WS connection with a foreign domain's proxy > because of > >> NAPTR and my proxy supports acting as a WS client. It obviously > won't be > >> able to authenticate. If this scenario supposed to be covered? > >> > >> Honestly I agree. I cannot find in RFC 3261 (or other RFCs) a > >> normative statement mandating authentication, regardless the = request > >> comes from a UA. > >> > >> In another thread we are discussing about MTI authentication > >> mechanisms that must be implemented by SIP WS Clients and Servers. > >> IMHO that is correct, but mandating SIP authentication or WWW > >> authentication for ALL the scenarios seem innapropriate for me. I > come > >> back to an use case: > >> > >> A website (a shop) offers a widget in which the visitor can click > and > >> made a SIP call (+WebRTC) that will end in the callcenter of the > >> company, answered by an agent that will inform the user about the > >> product he is interested in. Why do we require WWW or SIP > >> authentication in this scenario? > >> > >> If WG agrees with this, I will remove the normative statements in > >> "Authentication" section, and instead address the MTI = authentication > >> mechanisms. > >> > >> > >> -- > >> 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 > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Wed Jun 26 08:14:04 2013 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 5593321E8090 for ; Wed, 26 Jun 2013 08:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.119 X-Spam-Level: X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+7YYIs1XixC for ; Wed, 26 Jun 2013 08:13:59 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id E10FF21E8063 for ; Wed, 26 Jun 2013 08:13:55 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta01.westchester.pa.mail.comcast.net with comcast id t15U1l00316LCl0513Dvl0; Wed, 26 Jun 2013 15:13:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id t3Dv1l00E3ZTu2S3S3DvFG; Wed, 26 Jun 2013 15:13:55 +0000 Message-ID: <51CB0532.3020107@alum.mit.edu> Date: Wed, 26 Jun 2013 11:13:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Parthasarathi R References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> <019a01ce6d24$8ee95670$acbc0350$@co.in> <51C3267F.8040709@alum.mit.edu> <002301ce713c$c2672880$47357980$@co.in> In-Reply-To: <002301ce713c$c2672880$47357980$@co.in> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372259635; bh=m7BpWPq2wsJ31blmck/uJzubmwmxiE8pgXi/8HvYgWE=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=hSlTlUQikiYTxKKVSX3xNspw0rFb+u/eYrzPaBH7sEkRAWBWjJQerqSG82KVQqfPp A4KBZB00v2Aqh/uy8ADlSAVRJknotEey6oi6iaoILXpTUQQW2E7ZXahBcWBPzvZwV/ oBiLaePx1iG+gUNu/DaaVH9bakPZOf+ARqLvT3LeqFYl9R6l33PyWaALS2Z9vqYAcu 1c5eqlcsmk1pXx2p9r75hTY1j+6ewKR4UltSRVIvp6DJtaNlO4iVN/Sj2ja/Im5SmF jrxWO4tHEdS7AW0BkIj68wfwk/0Tka61GrhT2SiUrPGRIbdFVhSCMNvm7XCUPcE6TZ P2LlgI8n/+sLw== Cc: sipcore@ietf.org Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 26 Jun 2013 15:14:04 -0000 Partha, You addressed your reply to me. But I just posed the question, not the answer. I'm waiting for those who proposed the language to clarify it. The real issue is: how can a websocket server ever decide that it *doesn't* need to R-R? Thanks, Paul On 6/24/13 8:41 PM, Parthasarathi R wrote: > Paul, > > I think that we are talking about two problems here > > 1) SIP routing issue because of SIP WebSocket Client has only WebSocket as a transport (Browser scenario) > a) Solution: Record-route header has to be added by SIP WebSocket Server. > > 2) How will SIP WebSocket Server know that SIP WebSocket client supports only SIP WebSocket as a transport? (Non-browser scenario) > a) AFAIK, there is no other environment other than browser has the limitation of not supporting UDP & TCP. In case any other environment exists, Please let me know. > b) The beauty of RFC 3261 is that there is no need to negotiate the set of "SIP" transport protocol as it mandates for UDP, TCP. I agree that it is an open item how to represent the list of transport supported by a SIP UA in case of supporting WebSocket only transport scenario. But I'm not sure whether this WG is interested in solving this issue. We need to here from more folks and its relevant usecases. > > Thanks > Partha > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Thursday, June 20, 2013 9:28 PM >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket- >> 09 >> >> On 6/19/13 6:05 PM, Iñaki Baz Castillo wrote: >>> 2013/6/19 Parthasarathi R : >>>> >>>> Just adding to Ranjit mentioned. The text similar to the following >> has to be added. "Record-route header MUST be added by SIP WebSocket >> Server in case WebSocket is the only supported SIP transport between >> SIP WebSocket client & server and SIP WebSocket server acts as SIP >> proxy" >>> >>> That is just true in case the client is a web browser (a SIP WS >> Client >>> but not a SIP WS Server so it can not receive incoming WS >>> connections). So the text would be: >>> >>> "Record-route header MUST be added by SIP WebSocket Server in case >>> WebSocket is the only supported SIP transport between client and >>> server, the server acts as SIP proxy, and the client is a SIP >>> WebSocket Client (but not a SIP WebSocket Server so it can not accept >>> incoming WebSocket connections)." >> >> How will the server know that the client is not capable of being a >> WebSocket Server? >> >> I guess in many cases it might be able to know that because the client >> is a browser being controlled by scripting from the server. But in >> other >> cases ISTM that it just won't know. >> >> Thanks, >> Paul >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > From pkyzivat@alum.mit.edu Wed Jun 26 08:16:25 2013 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 C6DE421F9A71 for ; Wed, 26 Jun 2013 08:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.145 X-Spam-Level: X-Spam-Status: No, score=-0.145 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id safwwFoZ8hbg for ; Wed, 26 Jun 2013 08:16:19 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id A494021F92D3 for ; Wed, 26 Jun 2013 08:16:19 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id szxo1l0011swQuc5F3G5xC; Wed, 26 Jun 2013 15:16:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id t3G51l00C3ZTu2S3b3G51q; Wed, 26 Jun 2013 15:16:05 +0000 Message-ID: <51CB05B5.10204@alum.mit.edu> Date: Wed, 26 Jun 2013 11:16:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Parthasarathi R References: <20130613011708.18316.28106.idtracker@ietfa.amsl.com> <013c01ce6c4e$29e33c90$7da9b5b0$@co.in> <12FDD6C8-F172-4B3B-A83A-211CF553DA1A@ag-projects.com> <949EF20990823C4C85C18D59AA11AD8B055194@FR712WXCHMBA10.zeu.alcatel-lucent.com> <51C328B6.20506@alum.mit.edu> <002501ce713d$a47221d0$ed566570$@co.in> In-Reply-To: <002501ce713d$a47221d0$ed566570$@co.in> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372259765; bh=pRmEURGuXJEi/jYZZ0Ox+UKgjOUDOwHbJskGkKpZSnU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=D72fKgR/5px2C7RR1eSf2A462P7vcSZaPCgLHH8DnJFWOKZONZqxpcrMZbCUHWbqD +vOk+ajgagayaNTHomo2WtvF0mleXQ2+LtsxhwMLNohltp4lalUKNnN+UY5MNedSLM ruZyxL9lv0FJ4amHjcUzkMf+3uZV2j/Fuf+EYJxDoOcJS3rUp+jXPVivO4OuQXmXR/ volXvcXokWKXC+yltpdYeDh1alcSBTA9EsS02NJs3I3pJlMOmUrKJZ2V8JwU5UNCTs UKGUkHgf4sSwOKDAQsDdp62ZLvdpHM0fUp+u9It66I+0TfNcGh0TGF0S7y+zaf9Z+D xE02jLODq7eKA== Cc: sipcore@ietf.org Subject: Re: [sipcore] No WebSocket level authentication scenario [was RE: I-D Action: draft-ietf-sipcore-sip-websocket-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: Wed, 26 Jun 2013 15:16:25 -0000 Partha, Again, I'm not the one to answer. I'm just the chair, not the author. Thanks, Paul On 6/24/13 8:47 PM, Parthasarathi R wrote: > Paul, > > In case it is not mandatory to use authentication, the following statement > in Sec 7 of the draft is not correct: > > " If no authentication is done at WebSocket level then SIP Digest > authentication is required for every SIP request coming over the > WebSocket connection." > > Please let me know your comment on the same. > > Thanks > Partha > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Paul Kyzivat >> Sent: Thursday, June 20, 2013 9:37 PM >> To: sipcore@ietf.org >> Subject: Re: [sipcore] No WebSocket level authentication scenario [was >> RE: I-D Action: draft-ietf-sipcore-sip-websocket-09.txt] >> >> On 6/19/13 8:06 AM, DRAGE, Keith (Keith) wrote: >>> I would not use RFC 3261 as justification for what should, or should >> not, be said about authentication. The current RFC 3261 would probably >> fail a security directorate review if it was attempted to be approved >> as an RFC now. >>> >>> (I'd also point out that for any security consideration of RFC 3261, >> one should also read RFC 5630.) >>> >>> So I would suggest you conduct an independent security evaluation of >> what is needed. >> >> I think we are in the midst of one with Stephen Farrell. >> >>> For the use case you give: >>> >>>> A website (a shop) offers a widget in which the visitor can click >> and >>>> made a SIP call (+WebRTC) that will end in the callcenter of the >>>> company, answered by an agent that will inform the user about the >>>> product he is interested in. Why do we require WWW or SIP >>>> authentication in this scenario? >>> >>> I'd suggest that the issue to be discussed is what happens when the >> action described results in a transaction of some form to a third party >> (in the SIP case a call). The visitor then includes information that >> will be relayed to the third party. Who does the third party rely on to >> ensure that information is authentically given by the visitor. >> >> I'm inclined to support Iñaki, that authentication of any sort >> shouldn't >> be Mandatory to *Use*. Individual applications can decide when they >> have uses that require authentication and when they don't. >> >> Thanks, >> Paul >> >>> Regards >>> >>> Keith >>> >>> >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf >>>> Of Iñaki Baz Castillo >>>> Sent: 19 June 2013 12:32 >>>> To: Saúl Ibarra Corretgé >>>> Cc: SIPCORE (Session Initiation Protocol Core) WG; Parthasarathi R >>>> Subject: Re: [sipcore] No WebSocket level authentication scenario >> [was RE: >>>> I-D Action: draft-ietf-sipcore-sip-websocket-09.txt] >>>> >>>> 2013/6/19 Saúl Ibarra Corretgé : >>>>> Why is authentication a MUST? Lets assume that I'm using UDP and my >>>> proxy establishes a WS connection with a foreign domain's proxy >> because of >>>> NAPTR and my proxy supports acting as a WS client. It obviously >> won't be >>>> able to authenticate. If this scenario supposed to be covered? >>>> >>>> Honestly I agree. I cannot find in RFC 3261 (or other RFCs) a >>>> normative statement mandating authentication, regardless the request >>>> comes from a UA. >>>> >>>> In another thread we are discussing about MTI authentication >>>> mechanisms that must be implemented by SIP WS Clients and Servers. >>>> IMHO that is correct, but mandating SIP authentication or WWW >>>> authentication for ALL the scenarios seem innapropriate for me. I >> come >>>> back to an use case: >>>> >>>> A website (a shop) offers a widget in which the visitor can click >> and >>>> made a SIP call (+WebRTC) that will end in the callcenter of the >>>> company, answered by an agent that will inform the user about the >>>> product he is interested in. Why do we require WWW or SIP >>>> authentication in this scenario? >>>> >>>> If WG agrees with this, I will remove the normative statements in >>>> "Authentication" section, and instead address the MTI authentication >>>> mechanisms. >>>> >>>> >>>> -- >>>> Iñaki 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 > > From michael@voip.co.uk Thu Jun 27 06:57:16 2013 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 EEE6621F9997 for ; Thu, 27 Jun 2013 06:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 G1nRxLcJTc8g for ; Thu, 27 Jun 2013 06:57:10 -0700 (PDT) Received: from na3sys009aog120.obsmtp.com (na3sys009aog120.obsmtp.com [74.125.149.140]) by ietfa.amsl.com (Postfix) with SMTP id B272021F9D89 for ; Thu, 27 Jun 2013 06:57:09 -0700 (PDT) Received: from mail-wi0-f182.google.com ([209.85.212.182]) (using TLSv1) by na3sys009aob120.postini.com ([74.125.148.12]) with SMTP ID DSNKUcxEtT2STMTdcYG9LTMqggCaE4idbAH7@postini.com; Thu, 27 Jun 2013 06:57:09 PDT Received: by mail-wi0-f182.google.com with SMTP id m6so652525wiv.15 for ; Thu, 27 Jun 2013 06:57: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:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=5T8byCQc/S3sjltiz1ei9POXZg1YkW2ilAGAqpZDZOc=; b=brIz9o6EkG8S5qIc4hB67ibUOxdFrROLTg/EBKUC86M3oG1ZBUHlt4iUzTeFSI4UfT c8H7o0/zQsVJRkbuIObFySqkJJL2v4UotJeCEcEOgbx0joVWOJsSe9AIUiu2AsQo9BD9 2sCSKOnhg1eH3H1yS70FlXw26hWUZjDGELRI1l5Lyin6oSI2ffCHClqI5FcXsVCWQ8Tb TjnJ8HT0uQaCI6NaS2NEtgmNSpxpjUvDUCHUmy/6QipPPmh3sxHKkAGSNXW+R100lJSi bPCc94+AXqtYCeApafM/QDG1Kszhv2ilHrVjqS36j1WQDrWUsbU8ihIsmJS7WURYAF+Q MqJw== X-Received: by 10.194.240.201 with SMTP id wc9mr6569111wjc.1.1372341428030; Thu, 27 Jun 2013 06:57:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.240.201 with SMTP id wc9mr6569108wjc.1.1372341427961; Thu, 27 Jun 2013 06:57:07 -0700 (PDT) Received: by 10.194.164.234 with HTTP; Thu, 27 Jun 2013 06:57:07 -0700 (PDT) In-Reply-To: <51CB0532.3020107@alum.mit.edu> References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> <019a01ce6d24$8ee95670$acbc0350$@co.in> <51C3267F.8040709@alum.mit.edu> <002301ce713c$c2672880$47357980$@co.in> <51CB0532.3020107@alum.mit.edu> Date: Thu, 27 Jun 2013 14:57:07 +0100 Message-ID: From: Michael Procter To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnATHs6MBas1hyowwNJMXWra80JLJZ1+Pv1VHPWVsq+TkPTeMYxlXflrh3uMRP6EaxWcdS7usHy21Ny581RaQsXNFgxi4IMPajwTPDEnp3LT1p0Uh6xwaGgkIg5q4Dau9hTImhNnWkIntb9QLnmqom5LVQrHQ== Cc: sipcore@ietf.org Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 27 Jun 2013 13:57:16 -0000 On 26 June 2013 16:13, Paul Kyzivat wrote: > The real issue is: how can a websocket server ever decide that it *doesn'= t* > need to R-R? The websocket server shouldn't R-R a request if it is a non-dialog-establis= hing request (e.g. REGISTER, PUBLISH) or an in-dialog non-target-refresh request (e.g. INFO). It is probably fair to say that INVITEs should be, but that specific case is already covered by RFC5626, as I=F1aki has pointed out. Regards, Michael From pkyzivat@alum.mit.edu Thu Jun 27 07:58:18 2013 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 3E76B21F9D3D for ; Thu, 27 Jun 2013 07:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.187 X-Spam-Level: X-Spam-Status: No, score=-0.187 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zC-PW0YcQ1u for ; Thu, 27 Jun 2013 07:58:12 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1EB21F9DAA for ; Thu, 27 Jun 2013 07:57:55 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id tPqE1l0021YDfWL53SxtQU; Thu, 27 Jun 2013 14:57:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id tSxs1l0103ZTu2S3gSxsaq; Thu, 27 Jun 2013 14:57:53 +0000 Message-ID: <51CC52F0.3050809@alum.mit.edu> Date: Thu, 27 Jun 2013 10:57:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael Procter References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> <019a01ce6d24$8ee95670$acbc0350$@co.in> <51C3267F.8040709@alum.mit.edu> <002301ce713c$c2672880$47357980$@co.in> <51CB0532.3020107@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372345073; bh=/XLs/HAPb1MX+tEoLyABbdMG7Bk3Fy5wB0yocg8EwxU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=NW4OHsTjUjBclNiuUKhH7e+duDIxu4ltKoGLCmTZwWOpLeNkNBscb5pSnl0Y8cn/W cBPK54TvPAqWHtE0ahQWXc9xNfcWT92n3pK6uEt168kxUmG8TNk8NuzjDGx2PKyZ+Q OeBsKhx6EFsuzYcClzedGchH+Eikd1fOL3KCx9XTAkqu+4cM3WyHnYof5/v60lpve9 wHlNfHltr/FNhnnGl/Yf2m6y9F4v9O8hYhWnIBTF96TDYOUYc+7u9PiYO/nizfWhdm +tPd6/nsOzWJMQufAMOw+575DiIydjQI+VR6xds+2CEE5t4wb4+kn159QySvTgTwv6 wRT1/y9lbLN0A== Cc: sipcore@ietf.org Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 27 Jun 2013 14:58:19 -0000 On 6/27/13 9:57 AM, Michael Procter wrote: > On 26 June 2013 16:13, Paul Kyzivat wrote: >> The real issue is: how can a websocket server ever decide that it *doesn't* >> need to R-R? > > The websocket server shouldn't R-R a request if it is a non-dialog-establishing > request (e.g. REGISTER, PUBLISH) or an in-dialog non-target-refresh request > (e.g. INFO). It is probably fair to say that INVITEs should be, but > that specific > case is already covered by RFC5626, as Iñaki has pointed out. You miss my point. The cases you describe above are cases where it never makes sense to R-R. The only place the question is relevant is on dialog establishing requests. The simple answer would be that websocket proxy handling a dialog establishing request should *always* R-R. But there has been an assertion that there may be some sip-websocket UACs that are also capable of being sip-websocket servers. In that case, it would be desirable for the proxy to *not* R-R, so that it won't be in the signaling path for the entire dialog. But how would the proxy know that it is safe to not R-R? One thing that comes to mind for me is that the UAC could decide whether or not to tag its contact URI with ";gr". If it were so tagged, then that says it is globally routable, so it would be safe for the proxy to bypass the R-R. If the contact isn't a gruu, then the proxy would decide that it must R-R. I think Iñaki said he was on vacation for a couple of weeks, so we may not hear from him on this soon. Thanks, Paul From michael@voip.co.uk Thu Jun 27 08:34:50 2013 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 49BFD21F91C4 for ; Thu, 27 Jun 2013 08:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, 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 KX7W3viMksZ9 for ; Thu, 27 Jun 2013 08:34:44 -0700 (PDT) Received: from na3sys009aog124.obsmtp.com (na3sys009aog124.obsmtp.com [74.125.149.151]) by ietfa.amsl.com (Postfix) with SMTP id E1CC521F9CFF for ; Thu, 27 Jun 2013 08:32:50 -0700 (PDT) Received: from mail-wi0-f176.google.com ([209.85.212.176]) (using TLSv1) by na3sys009aob124.postini.com ([74.125.148.12]) with SMTP ID DSNKUcxbHRuPxYnAmNI/5sIBuQGW8MfRaVp5@postini.com; Thu, 27 Jun 2013 08:33:14 PDT Received: by mail-wi0-f176.google.com with SMTP id ey16so3240800wid.9 for ; Thu, 27 Jun 2013 08:32: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:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Fm0WETizzD/6QcODYxwB/5umxMokddun+sJyQ30P1hg=; b=X5gZhQWKp5WdbanONwELtRw1JaXo9g7y2KB1jH+PPAIrL5DOI5XvVlbkUc4P57aHwp mcvMG1AJB4jWx9v5GZrxZ+bt1IpZBgf0wPeHNlbuIMVZ3S81JV7LhwYf8HugUoeT8Swc PtbOHCyfg0sUlI7JxCEpUvnV7YXhHLZQ764aSM6GDqXoAnnr0kIHYLI5G3rtkGK4RZcM wXALKVMutnzkMHNdLjx6vZQZ3SVOH0WixioKmgj1WPmssjl/4a61Xe8rUXtyVn71oE52 n1pqhfthUjEir8mcvSuxPZnlJGuDLzfQ2vEGVypcPYmCphJyp5PTR/eja2Ss41K/pi9b 29rQ== X-Received: by 10.180.184.12 with SMTP id eq12mr6323989wic.8.1372347163994; Thu, 27 Jun 2013 08:32:43 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.184.12 with SMTP id eq12mr6323927wic.8.1372347162759; Thu, 27 Jun 2013 08:32:42 -0700 (PDT) Received: by 10.194.164.234 with HTTP; Thu, 27 Jun 2013 08:32:42 -0700 (PDT) In-Reply-To: <51CC52F0.3050809@alum.mit.edu> References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> <019a01ce6d24$8ee95670$acbc0350$@co.in> <51C3267F.8040709@alum.mit.edu> <002301ce713c$c2672880$47357980$@co.in> <51CB0532.3020107@alum.mit.edu> <51CC52F0.3050809@alum.mit.edu> Date: Thu, 27 Jun 2013 16:32:42 +0100 Message-ID: From: Michael Procter To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkTUN+OfJcFilnIpepk/tLHacX/z+pKr71VKdFnM0Kw+4axD8IaCdyxw+SYBFN9CS7x/Xqz1uq81a3t0ggTJnAs3ey6vY16dYZ7fY3eUZ/CpNHYobfUB8hPPuHoACV4mNQVcyV7ucwhgiHu6bKYVQ+ZXQJrnQ== Cc: sipcore@ietf.org Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 27 Jun 2013 15:34:50 -0000 On 27 June 2013 15:57, Paul Kyzivat wrote: > You miss my point. The cases you describe above are cases where it never > makes sense to R-R. The only place the question is relevant is on dialog > establishing requests. Apologies. Partha seemed to be edging towards a more general statement than simply for dialog establishing requests and your question was similarly unrestricted. > One thing that comes to mind for me is that the UAC could decide whether or > not to tag its contact URI with ";gr". If it were so tagged, then that says > it is globally routable, so it would be safe for the proxy to bypass the > R-R. That sounds like a step forward. I think this problem, specifically for the non-browser scenario, has overlaps with the scenario RFC5923 addresses. Maybe the 'alias' via parameter would also be a clue that R-R is not necessarily required. Regards, Michael From partha@parthasarathi.co.in Thu Jun 27 09:09:38 2013 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 D90AC21F9E07 for ; Thu, 27 Jun 2013 09:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[IP_NOT_FRIENDLY=0.334] 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 Zqrs3PLbhTOX for ; Thu, 27 Jun 2013 09:09:34 -0700 (PDT) Received: from smtp.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.231]) by ietfa.amsl.com (Postfix) with ESMTP id 79B2D21F9DEA for ; Thu, 27 Jun 2013 09:09:34 -0700 (PDT) Received: from userPC (unknown [122.178.223.166]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 48B13190800F; Thu, 27 Jun 2013 16:09:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1372349371; bh=QmERdNbUdonfQZk+CSAXiHEjSgD2/frm4YaJGog4OSw=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=gEI7422BA+MrMpAEa7OHo0o2yV3PkeVmjHq2lzT9lkV1/ahDU1ukF176jr1LyY2sn X/cIfMRhDtWbPLflEJTysc5VjC9YXgpOnhbR3a2WRte7U3gKt8rYPN6yhVIt35C6B6 Obwde1MZ7pIMT7QWVsnFIMJKY2z/qCDuSsun36yQ= From: "Parthasarathi R" To: "'Paul Kyzivat'" References: <003f01ce6aaf$aabda760$0038f620$@co.in> <011e01ce6c44$3c70e290$b552a7b0$@co.in> <019a01ce6d24$8ee95670$acbc0350$@co.in> <51C3267F.8040709@alum.mit.edu> <002301ce713c$c2672880$47357980$@co.in> <51CB0532.3020107@alum.mit.edu> In-Reply-To: <51CB0532.3020107@alum.mit.edu> Date: Thu, 27 Jun 2013 21:39:21 +0530 Message-ID: <012b01ce7350$b257f5d0$1707e170$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac5yf83UTehphANETkmM4ljJIdqDigA0KkcA Content-Language: en-us X-CTCH-RefID: str=0001.0A0C0202.51CC63BB.011C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: partha@parthasarathi.co.in X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 70.87.28.138 Cc: sipcore@ietf.org Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip-websocket-09 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, 27 Jun 2013 16:09:39 -0000 Paul, Thanks for the clarification. Let us wait for the clarification on R-R = issue. Thanks Partha > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Wednesday, June 26, 2013 8:44 PM > To: Parthasarathi R > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Open issues in = draft-ietf-sipcore-sip-websocket- > 09 >=20 > Partha, >=20 > You addressed your reply to me. But I just posed the question, not the > answer. I'm waiting for those who proposed the language to clarify it. >=20 > The real issue is: how can a websocket server ever decide that it > *doesn't* need to R-R? >=20 > Thanks, > Paul >=20 > On 6/24/13 8:41 PM, Parthasarathi R wrote: > > Paul, > > > > I think that we are talking about two problems here > > > > 1) SIP routing issue because of SIP WebSocket Client has only > WebSocket as a transport (Browser scenario) > > a) Solution: Record-route header has to be added by SIP WebSocket > Server. > > > > 2) How will SIP WebSocket Server know that SIP WebSocket client > supports only SIP WebSocket as a transport? (Non-browser scenario) > > a) AFAIK, there is no other environment other than browser has > the limitation of not supporting UDP & TCP. In case any other > environment exists, Please let me know. > > b) The beauty of RFC 3261 is that there is no need to negotiate > the set of "SIP" transport protocol as it mandates for UDP, TCP. I > agree that it is an open item how to represent the list of transport > supported by a SIP UA in case of supporting WebSocket only transport > scenario. But I'm not sure whether this WG is interested in solving > this issue. We need to here from more folks and its relevant usecases. > > > > Thanks > > Partha > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > >> Behalf Of Paul Kyzivat > >> Sent: Thursday, June 20, 2013 9:28 PM > >> To: sipcore@ietf.org > >> Subject: Re: [sipcore] Open issues in draft-ietf-sipcore-sip- > websocket- > >> 09 > >> > >> On 6/19/13 6:05 PM, I=C3=B1aki Baz Castillo wrote: > >>> 2013/6/19 Parthasarathi R : > >>>> > >>>> Just adding to Ranjit mentioned. The text similar to the = following > >> has to be added. "Record-route header MUST be added by SIP = WebSocket > >> Server in case WebSocket is the only supported SIP transport = between > >> SIP WebSocket client & server and SIP WebSocket server acts as SIP > >> proxy" > >>> > >>> That is just true in case the client is a web browser (a SIP WS > >> Client > >>> but not a SIP WS Server so it can not receive incoming WS > >>> connections). So the text would be: > >>> > >>> "Record-route header MUST be added by SIP WebSocket Server in case > >>> WebSocket is the only supported SIP transport between client and > >>> server, the server acts as SIP proxy, and the client is a SIP > >>> WebSocket Client (but not a SIP WebSocket Server so it can not > accept > >>> incoming WebSocket connections)." > >> > >> How will the server know that the client is not capable of being a > >> WebSocket Server? > >> > >> I guess in many cases it might be able to know that because the > client > >> is a browser being controlled by scripting from the server. But in > >> other > >> cases ISTM that it just won't know. > >> > >> Thanks, > >> Paul > >> > >> _______________________________________________ > >> 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 jmillan@aliax.net Fri Jun 28 02:50:01 2013 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 1765121F9BA2 for ; Fri, 28 Jun 2013 02:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[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 CJHNlK4s5y2y for ; Fri, 28 Jun 2013 02:49:50 -0700 (PDT) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id B76CF21F853A for ; Fri, 28 Jun 2013 02:48:22 -0700 (PDT) Received: by mail-vc0-f182.google.com with SMTP id id13so680686vcb.41 for ; Fri, 28 Jun 2013 02:48:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=ngrwGCVtdEKo78MWUlzH8O6VdkXh7maIV+Qiq2znOyM=; b=JZgavIZprbqNHc6KmRdnKNv6+HQdiMccHPkB+nHiQLNPvHX1kt73ZS7R51ZupY2QI/ kYruc/WBmCEJcoz57KBVxvaO2nYKjuf3sy+1fGUdT510vk3ssaUFgXgJhsITA5T1L8zb 9fuBg/cCSaBwtapa37COPPBipaETo7fJ+YPufTEBBPUSyZTHxx/ygogGOi9hazUwgs68 VRmq8X9o038G+QKtlUZTUnjuP8HNojMTTQI54STIbf5UU52k+c6LIPtbf9DUDNoa8AJr xINnObcJGVrO9rMR4r/aHMzBhgSXi3uvWBR6ovw9Rj97u7NkNMgKZWCSowh7rYSoiDLD magw== MIME-Version: 1.0 X-Received: by 10.59.9.69 with SMTP id dq5mr5064948ved.87.1372412902103; Fri, 28 Jun 2013 02:48:22 -0700 (PDT) Received: by 10.220.49.138 with HTTP; Fri, 28 Jun 2013 02:48:22 -0700 (PDT) Date: Fri, 28 Jun 2013 11:48:22 +0200 Message-ID: From: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: multipart/alternative; boundary=047d7bd74cf883edf304e033c7f1 X-Gm-Message-State: ALoCoQkXU6+1iqmq1Uyo4R3y900lXppxvOykfY9gpxVLu2TSmEONOk+BWo2K5lITbP3WndUEv/aw Subject: [sipcore] Outbound clarification 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, 28 Jun 2013 09:50:01 -0000 --047d7bd74cf883edf304e033c7f1 Content-Type: text/plain; charset=UTF-8 Hi, May someone help me parsing this phrase from Outbound specification? The prhase I don't understand is: ''' that was instantiated using a Contact header field value that included an "ob" parameter ''' It is taken from RFC 5626 section 4.3. "Sending Non-REGISTER Requests": ''' If the UAC is using a Globally Routable UA URI (GRUU) [RFC5627] that was instantiated using a Contact header field value that included an "ob" parameter, the UAC sends the request over the flow used for registration, and subsequent requests will arrive over that same flow. If the UAC is not using such a GRUU, then the UAC adds an "ob" parameter to its Contact header field value. ''' Thanks a lot --047d7bd74cf883edf304e033c7f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

May someone help me pars= ing this phrase from Outbound specification?

The p= rhase I don't understand is:
'''
that w= as instantiated using a=C2=A0Contact header field value that included an &q= uot;ob" parameter
'''

It is taken from RFC 56= 26 section 4.3. "Sending Non-REGISTER Requests":

'''
If the UAC is using a Globally
Routable UA URI (G= RUU) [RFC5627] that was instantiated using a
Contact header field value that included an "ob" parameter, the U= AC
sends the request over the flow used for registration, and subsequent=
requests will arrive over that same flow. =C2=A0If the UAC is not using=
such a GRUU, then the UAC adds an "ob" parameter to its Contactheader field value.
'''

Thanks a= lot
--047d7bd74cf883edf304e033c7f1-- From jmillan@aliax.net Fri Jun 28 03:30:03 2013 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 D071721F9F04 for ; Fri, 28 Jun 2013 03:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.676 tagged_above=-999 required=5 tests=[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 vP55ZFwwDRVL for ; Fri, 28 Jun 2013 03:29:53 -0700 (PDT) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id C8AE121F9CA0 for ; Fri, 28 Jun 2013 03:29:46 -0700 (PDT) Received: by mail-vb0-f54.google.com with SMTP id q12so1548804vbe.41 for ; Fri, 28 Jun 2013 03:29: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:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=5DhNbPstjv0u3RyXfheUt9Zs23auh7yrp0GcPOh/BN0=; b=RSCpEH4IrXndoK/QV6QjYv2hxUQqWxwF9cNXFalX8SjtBC+0oKDXujNdR9H+ah29PZ uJmuEwCQbq5rfYk3PBpenFw31/zbsLdqbONrT0tmrYS9GfBoxAaz9ip1BTsA8nqbs4Pl eoKaf5HN4HyVna338xZz2Qw8BHsfMPK16DCtMNLrWuM6JaTMHDNfUyL3Hzps6Dd3W23f I0nLtXXXGTKbFWM2l5ooaQPZ6q2qm++w6ZJC/c6h9G8HEvjE0EyWbaoxB8JLvToda5dN /dJPH9b9EhbTim8yi2axj+GCw5Q7/M1xYhHQYKaitXOY9LPFykTFfc/I1/GHC5uPoQnF H7Vw== MIME-Version: 1.0 X-Received: by 10.59.0.2 with SMTP id au2mr5227129ved.83.1372415385006; Fri, 28 Jun 2013 03:29:45 -0700 (PDT) Received: by 10.220.49.138 with HTTP; Fri, 28 Jun 2013 03:29:44 -0700 (PDT) In-Reply-To: References: Date: Fri, 28 Jun 2013 12:29:44 +0200 Message-ID: From: =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: multipart/alternative; boundary=047d7bd750b282088a04e0345b91 X-Gm-Message-State: ALoCoQlXPpvmbP07ntgbRGCG+7IISvKjvsPO/GSvnVNZyD4i1FqBXIPYc9f2F+QPE5MRwYv3Gpw5 Subject: Re: [sipcore] Outbound clarification 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, 28 Jun 2013 10:30:04 -0000 --047d7bd750b282088a04e0345b91 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable May it mean that the GRUU was obtained from a REGISTER request which Contact header contained the ;ob parameter? 2013/6/28 Jos=C3=A9 Luis Mill=C3=A1n > Hi, > > May someone help me parsing this phrase from Outbound specification? > > The prhase I don't understand is: > ''' > that was instantiated using a Contact header field value that included an > "ob" parameter > ''' > > It is taken from RFC 5626 section 4.3. "Sending Non-REGISTER Requests": > > ''' > If the UAC is using a Globally > Routable UA URI (GRUU) [RFC5627] that was instantiated using a > Contact header field value that included an "ob" parameter, the UAC > sends the request over the flow used for registration, and subsequent > requests will arrive over that same flow. If the UAC is not using > such a GRUU, then the UAC adds an "ob" parameter to its Contact > header field value. > ''' > > Thanks a lot > --=20 Jos=C3=A9 Luis Mill=C3=A1n --047d7bd750b282088a04e0345b91 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
May it mean that the GRUU was obtained from a REGISTER req= uest which Contact header contained the ;ob parameter?


2013/6/28 Jos=C3=A9 Luis Mil= l=C3=A1n <jmillan@aliax.net>
Hi,

May someone help me parsing this phrase from Outbound specification?=

The prhase I don't understand is:
'&#= 39;'
that was instantiated using a=C2=A0Contact header field = value that included an "ob" parameter
'''

It is taken from RFC 56= 26 section 4.3. "Sending Non-REGISTER Requests":

'''
If the UAC is using a Globally
Routable UA URI (G= RUU) [RFC5627] that was instantiated using a
Contact header field value that included an "ob" parameter, the U= AC
sends the request over the flow used for registration, and subsequent=
requests will arrive over that same flow. =C2=A0If the UAC is not using=
such a GRUU, then the UAC adds an "ob" parameter to its Contactheader field value.
'''

Thanks a= lot



--
Jos=C3=A9 Lu= is Mill=C3=A1n
--047d7bd750b282088a04e0345b91-- From worley@shell01.TheWorld.com Fri Jun 28 13:35:33 2013 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 25E6221F99B0 for ; Fri, 28 Jun 2013 13:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 IhI9HLyQ9zRc for ; Fri, 28 Jun 2013 13:35:27 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 405DC21F9433 for ; Fri, 28 Jun 2013 13:35:26 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r5SKYvW0016305; Fri, 28 Jun 2013 16:34:59 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r5SKYvc7115801; Fri, 28 Jun 2013 16:34:57 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r5SKYs1E115839; Fri, 28 Jun 2013 16:34:54 -0400 (EDT) Date: Fri, 28 Jun 2013 16:34:54 -0400 (EDT) Message-Id: <201306282034.r5SKYs1E115839@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Jose Luis Millan In-reply-to: (jmillan@aliax.net) References: Cc: sipcore@ietf.org Subject: Re: [sipcore] Outbound clarification 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, 28 Jun 2013 20:35:33 -0000 > From: JosC) Luis MillC!n > > May it mean that the GRUU was obtained from a REGISTER request which > Contact header contained the ;ob parameter? Yes, I believe that is what it means. Every GRUU refers to an underlying Contact address, which is where requests to that GRUU will be routed to. That Contact address is what was used in the REGISTER request to obtain the GRUU. The question seems to be, "Does this GRUU refer to a Contact address that includes an "ob" parameter?" Dale