From brett@broadsoft.com Thu Aug 2 07:22:32 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8973C21F85C9 for ; Thu, 2 Aug 2012 07:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKVqfwrwu7RB for ; Thu, 2 Aug 2012 07:22:31 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id D570D21F85C5 for ; Thu, 2 Aug 2012 07:22:31 -0700 (PDT) Received: from casumhub01.citservers.local (172.16.98.57) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 2 Aug 2012 07:25:53 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Thu, 2 Aug 2012 07:25:53 -0700 From: Brett Tate To: "sipcore@ietf.org" , "draft-barnes-sipcore-rfc4244bis-callflows@tools.ietf.org" Date: Thu, 2 Aug 2012 07:22:29 -0700 Thread-Topic: draft-barnes-sipcore-rfc4244bis-callflows-03: comments Thread-Index: Ac1wuj+eUGPLjezmTKK3TdQhPozn9g== Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF22C@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-barnes-sipcore-rfc4244bis-callflows-03: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:22:32 -0000 Howdy, The following are some draft-barnes-sipcore-rfc4244bis-callflows-03 comment= s. They are similar to those provided in April for draft-ietf-sipcore-rfc4= 244bis-07. Thanks, Brett ------ Section 3 general comments: - If depicting an RFC 3261 compliant UAS, the 302 examples must include To = tags. - If depicting an RFC 3261 compliant UAS, the Via headers using an FQDN mus= t cause the UAS to add a received parameter to the Via. Section 3.1: - In case not intentional, the 302's ACK is not depicted within the call fl= ow. - The 2xx's ACK is depicted a ladder; however example.com did not add a Rec= ord-Route. - F4: The top unique via branch should be changed since it was already used= within F2. Section 3.2: - F2: If depicting an RFC 3261 compliant UAS, must add a To tag. Section 3.3: - In case not intentional, the 302's ACK is not depicted within the call fl= ow. - The 2xx's ACK is depicted a ladder; however example.com did not add a Rec= ord-Route. - F4: The top unique via branch should be changed since it was already used= within F2. - F5: The Contact should be changed since it reflects the proxy instead of = UAS location. - F6: The top unique via branch should be changed since it was already used= within F2. - F7: The Contact should be changed since it reflects the proxy instead of = UAS location. Section 3.4: - In case not intentional, the 302's ACK is not depicted within the call fl= ow. - The 2xx's ACK is depicted a ladder; however example.com did not add a Rec= ord-Route. - F4: The top unique via branch should be changed since it was already used= within F2. - F5: The Contact should be changed since it reflects the proxy instead of = UAS location. - F6: The top unique via branch should be changed since it was already used= within F2. - F7: The Contact should be changed since it reflects the proxy instead of = UAS location. This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you ar= e not the intended recipient and have received this email in error, please = notify BroadSoft, Inc. immediately by replying to this message, or by sendi= ng an email to helpdesk@broadsoft.com, and destroy all copies of this messa= ge, along with any attachment, prior to reading, distributing or copying it= . From shida@ntt-at.com Thu Aug 2 07:45:42 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938C411E80D3 for ; Thu, 2 Aug 2012 07:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geAi36u+VAVi for ; Thu, 2 Aug 2012 07:45:42 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 0269311E80A3 for ; Thu, 2 Aug 2012 07:45:41 -0700 (PDT) Received: from [172.218.64.46] (port=55889 helo=[192.168.1.76]) by gator465.hostgator.com with esmtpa (Exim 4.77) (envelope-from ) id 1Swweh-00022x-Bf; Thu, 02 Aug 2012 09:45:39 -0500 Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF22C@EXMBXCLUS01.citservers.local> Date: Thu, 2 Aug 2012 07:45:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <26DC1083-E136-4ED6-B9BE-9E90BF06838C@ntt-at.com> References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E1CF22C@EXMBXCLUS01.citservers.local> To: Brett Tate X-Mailer: Apple Mail (2.1280) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.76]) [172.218.64.46]:55889 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 2 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: "draft-barnes-sipcore-rfc4244bis-callflows@tools.ietf.org" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis-callflows-03: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Aug 2012 14:45:42 -0000 Brett; Many thanks for the comments.=20 I will reflect them ASAP.=20 =20 Thanks again Shida On Aug 2, 2012, at 7:22 AM, Brett Tate wrote: > Howdy, >=20 > The following are some draft-barnes-sipcore-rfc4244bis-callflows-03 = comments. They are similar to those provided in April for = draft-ietf-sipcore-rfc4244bis-07. >=20 > Thanks, > Brett >=20 > ------ >=20 >=20 > Section 3 general comments: >=20 > - If depicting an RFC 3261 compliant UAS, the 302 examples must = include To tags. >=20 > - If depicting an RFC 3261 compliant UAS, the Via headers using an = FQDN must cause the UAS to add a received parameter to the Via. >=20 > Section 3.1: >=20 > - In case not intentional, the 302's ACK is not depicted within the = call flow. >=20 > - The 2xx's ACK is depicted a ladder; however example.com did not add = a Record-Route. >=20 > - F4: The top unique via branch should be changed since it was already = used within F2. >=20 > Section 3.2: >=20 > - F2: If depicting an RFC 3261 compliant UAS, must add a To tag. >=20 > Section 3.3: >=20 > - In case not intentional, the 302's ACK is not depicted within the = call flow. >=20 > - The 2xx's ACK is depicted a ladder; however example.com did not add = a Record-Route. >=20 > - F4: The top unique via branch should be changed since it was already = used within F2. >=20 > - F5: The Contact should be changed since it reflects the proxy = instead of UAS location. >=20 > - F6: The top unique via branch should be changed since it was already = used within F2. >=20 > - F7: The Contact should be changed since it reflects the proxy = instead of UAS location. >=20 > Section 3.4: >=20 > - In case not intentional, the 302's ACK is not depicted within the = call flow. >=20 > - The 2xx's ACK is depicted a ladder; however example.com did not add = a Record-Route. >=20 > - F4: The top unique via branch should be changed since it was already = used within F2. >=20 > - F5: The Contact should be changed since it reflects the proxy = instead of UAS location. >=20 > - F6: The top unique via branch should be changed since it was already = used within F2. >=20 > - F7: The Contact should be changed since it reflects the proxy = instead of UAS location. >=20 >=20 >=20 > This email is intended solely for the person or entity to which it is = addressed and may contain confidential and/or privileged information. = If you are not the intended recipient and have received this email in = error, please notify BroadSoft, Inc. immediately by replying to this = message, or by sending an email to helpdesk@broadsoft.com, and destroy = all copies of this message, along with any attachment, prior to reading, = distributing or copying it. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From fluffy@cisco.com Thu Aug 2 17:02:04 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DCB21F8BD9 for ; Thu, 2 Aug 2012 17:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.213 X-Spam-Level: X-Spam-Status: No, score=-110.213 tagged_above=-999 required=5 tests=[AWL=0.086, 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 u7JtiGxjtIj3 for ; Thu, 2 Aug 2012 17:02:03 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD6821F8BD6 for ; Thu, 2 Aug 2012 17:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=779; q=dns/txt; s=iport; t=1343952122; x=1345161722; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=nmxfYlHdI1IWE1Fm55z4uaQgZuKwO9mtDyhs/OHx11k=; b=YyzD9h/IYXXllPNPeB+AhJJ3FYJkuFb5e003LxxRk2yweDnukT6ayvMw YCMr/RXuNhpONNftHqiacTRdHBZU9C9pu3BmKRFf4JfVYotw1FH53b+sW jldvYHyo3VEUmvDGDpVMn2NxbzVMpsyXpFSTgl7fMbTaYHnuHJwUIFWWR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAGADcUG1CtJXG//2dsb2JhbAAkIbkigQeCJxIBeAGBACcEAS0Hh2ucfaBJkW5gA4gYjS+OJ4Fmgl8 X-IronPort-AV: E=Sophos;i="4.77,704,1336348800"; d="scan'208";a="105046807" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 03 Aug 2012 00:02:01 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q730213E006131 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 00:02:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.237]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 19:02:00 -0500 From: "Cullen Jennings (fluffy)" To: "sipcore@ietf.org WG" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "jmillan@aliax.net" , "vpascual@acmepacket.com" Thread-Topic: Comments on draft-ietf-sipcore-sip-websocket-01 Thread-Index: AQHNcQs0A1L+IsCI2Uay/0ZAAPc+aA== Date: Fri, 3 Aug 2012 00:01:59 +0000 Message-ID: <07A0D0F2-352B-402F-9BFF-D5763A2A7E8A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.66.244] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.000 x-tm-as-result: No--31.764200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: <324C6DC8708EA74C8CFDF3DCD7A93974@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] Comments on draft-ietf-sipcore-sip-websocket-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 00:02:04 -0000 I am sorry to miss sipcore but unfortunately I am chairing another meeting = at this time - I would like to add a few comments.=20 I like this draft and think it is going the right direction. In section 5.3, I think a better solution would be just require that any br= owser needs to use an outbound proxy over ws. So effectively the web server= needs to provide an outbound proxy that can be used. Once we have that, yo= u never need to do a SIP URL resolution inside the JS.=20 In section 7, I think it is key that credential used to get to the WS Proxy= can be different that the SIP credentials used to register with. This may = be what you are greeting at but it seems a bit unclear. So in 8.1, I would = have expected to see an challenge to the F3.=20 From jhildebr@cisco.com Thu Aug 2 18:53:36 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7C511E80E5 for ; Thu, 2 Aug 2012 18:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+JYoWLSgFVZ for ; Thu, 2 Aug 2012 18:53:35 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 05B9E11E80A6 for ; Thu, 2 Aug 2012 18:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jhildebr@cisco.com; l=712; q=dns/txt; s=iport; t=1343958811; x=1345168411; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=ORg0LIAT9AYBIDaCONmBYdb6OjLkIVTqSdUZ9i9f3PY=; b=A6QXInI8gJ+IDh6oPaQ71X/Ss5e+kaTzo7eI7IEzMHyNRioJS+Oxbfs7 h17SoMfnUcpoqAX5RszYCObNeWUc9D/EluKUMKhtNPUdajHu3yQPNTMS7 PmFEZSZs7ObdTBWLkRHPaswKgUy2eZZNnHL1cU81/akIcXhesOR5bjBCi k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAH4uG1CtJXG9/2dsb2JhbABFhTSzcIEHgicSAXgBCHglAgQBEhsHh2udEqBOkk4DiBiNL44ngWaCXw X-IronPort-AV: E=Sophos;i="4.77,704,1336348800"; d="scan'208";a="107844145" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 03 Aug 2012 01:53:30 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q731rUPq013945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Aug 2012 01:53:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.184]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0298.004; Thu, 2 Aug 2012 20:53:29 -0500 From: "Joe Hildebrand (jhildebr)" To: "Cullen Jennings (fluffy)" , "sipcore@ietf.org WG" , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "jmillan@aliax.net" , "vpascual@acmepacket.com" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-sip-websocket-01 Thread-Index: AQHNcQs0A1L+IsCI2Uay/0ZAAPc+aJdHMe0A Date: Fri, 3 Aug 2012 01:53:29 +0000 Message-ID: In-Reply-To: <07A0D0F2-352B-402F-9BFF-D5763A2A7E8A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.118.123] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19082.000 x-tm-as-result: No--25.582100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 02 Aug 2012 23:10:52 -0700 Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-websocket-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 01:53:36 -0000 On 8/2/12 5:01 PM, "Cullen Jennings (fluffy)" wrote: >In section 5.3, I think a better solution would be just require that any >browser needs to use an outbound proxy over ws. So effectively the web >server needs to provide an outbound proxy that can be used. Once we have >that, you never need to do a SIP URL resolution inside the JS. As long as you're authenticating to the proxy, it could choose to do CORS, which might allow for some more interesting deployments. I'd suggest you don't rule that out. However, in those use cases, you still don't need to do SIP URL resolution; the web context around the JS will know where to send you to connect. --=20 Joe Hildebrand From ibc@aliax.net Fri Aug 3 05:04:23 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5550C21F8D92 for ; Fri, 3 Aug 2012 05:04:23 -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 xtPTjHiBb5UO for ; Fri, 3 Aug 2012 05:04:22 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6407A21F8D95 for ; Fri, 3 Aug 2012 05:04:19 -0700 (PDT) Received: by lahm15 with SMTP id m15so347740lah.31 for ; Fri, 03 Aug 2012 05:04: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=QH6NUC6j/xoLB7AcKEefTaiO2s1I05/Qou6Sma//n08=; b=NPqfvAvS/wSzANC/Xdm605lP5lIGZAHQF8Z4kr9TdS3OnHwzrIC9w0KaqmO+sJ8qE/ nCe6J26MVlBArLzL8gKu6a9M/qEuw1u7oInp459guD/VRE4CCkR1ag/HWGgZXGqfUNaY reH3zqUhM4mlqGO6uUOXljrPtLDqMpiYwTOFu3yextEeOCFGyvxHcfJFn3dKtbue5h0d q20GI4imjKC3eaGoutXxfdjwN/L/rcjXFSjZUugLEykNUlUjpzbaItbHLZfsNdU8OXE3 NYLr2axuewlWJ4wwaQy1GfSuIwfKJAI6WIvGFDcSrJtLmqvLr2+V/ERLypAesART7vpF +wjw== Received: by 10.152.46.232 with SMTP id y8mr1434337lam.18.1343995458256; Fri, 03 Aug 2012 05:04:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.23.2 with HTTP; Fri, 3 Aug 2012 05:03:57 -0700 (PDT) In-Reply-To: <07A0D0F2-352B-402F-9BFF-D5763A2A7E8A@cisco.com> References: <07A0D0F2-352B-402F-9BFF-D5763A2A7E8A@cisco.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 3 Aug 2012 14:03:57 +0200 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlf0jjTDrXYvkgJi3gRkZx/tM05QTKMVIt9Nq76RnBJh8u4dUkBWwP7LacfofAWaAfFFlvo Cc: "vpascual@acmepacket.com" , "sipcore@ietf.org WG" , "jmillan@aliax.net" Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sip-websocket-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2012 12:04:23 -0000 2012/8/3 Cullen Jennings (fluffy) : > I like this draft and think it is going the right direction. Hi Cullen, please read comments inline: > In section 5.3, I think a better solution would be just require that any = browser needs to use an outbound proxy over ws. So effectively the web serv= er needs to provide an outbound proxy that can be used. Once we have that, = you never need to do a SIP URL resolution inside the JS. The draft does not assume web browser scenarios. In a web browser scenario the web server providing the JavaScript SIP stack can decide how the UA has to connect to the appropriate WebSocket and how to provisione it with a WS URI or a SIP URI (so the JavaScript code should map it to a WS URI prior to establish the WS connection). I don't think we should mandate how such a WebSocket server should be provided to the client. But there are other scenarios, i.e. a SIP UA running in a mobile device using a WebSocket stack provided by the mobile's operating system, and using SIP on top of it. In this case the UA can perform NAPTR/SRV queries as any other non-webapp application. We wouldn't like to focus this draft just on web browser scenarios, neither making rules based on web browser/JavaScript limitations. IMHO this has been previously discussed on the list, and the consensus was not to focus on web browser scenarios. > In section 7, I think it is key that credential used to get to the WS Pro= xy can be different that the SIP credentials used to register with. This ma= y be what you are greeting at but it seems a bit unclear. So in 8.1, I woul= d have expected to see an challenge to the F3. "credential used to get to the WS Proxy" is a bit unclear. RFC 6455 (WebSocket) leaves the door open for a WebSocket server to reply 401/407 response for a WebSocket handshake request, but the fact is that no one web browser reacts on a 401/407 (instead they just abort the connection and raise a JS error). Also, by participating in IETF WebSocket WG, I've realized that WWW people want to know *nothing* about HTTP authentication. Instead they trust on current WWW extended approach (Cookies, HTML form based authentication, OAuth...). So, IMHO, adding a credencials procedure in the WebSocket handshake flow in example 8.1 would cause some confusion. Take into account that, for sure, most of the SIP WebSocket implementors will build their own authentication mechanism for validating a WebSocket connection. Probably they will rely on the Cookie header in the WebSocket GET request (a Cookie returned by the *Web* server after the user logged in the web) or in some custom parameters in the WebSocket GET request-line. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From adam@nostrum.com Mon Aug 6 16:05:32 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5E621F859B for ; Mon, 6 Aug 2012 16:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.2 X-Spam-Level: X-Spam-Status: No, score=-102.2 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuafAqLl2Ok2 for ; Mon, 6 Aug 2012 16:05:31 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 309B021F8569 for ; Mon, 6 Aug 2012 16:05:27 -0700 (PDT) Received: from Svantevit.local ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q76N5LFK006335 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 6 Aug 2012 18:05:26 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <50204DB1.3010103@nostrum.com> Date: Mon, 06 Aug 2012 18:05:21 -0500 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [sipcore] Minutes Posted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Aug 2012 23:05:32 -0000 Preliminary minutes have been posted for the face-to-face meeting in Vancouver. Please send any comments to me and Paul: http://www.ietf.org/proceedings/84/minutes/minutes-84-sipcore /a From dwing@cisco.com Mon Aug 6 16:25:37 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6304711E80DF for ; Mon, 6 Aug 2012 16:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECNKCaadg7Up for ; Mon, 6 Aug 2012 16:25:36 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB3811E80A5 for ; Mon, 6 Aug 2012 16:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=3681; q=dns/txt; s=iport; t=1344295536; x=1345505136; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=pu8jnF8TcBDP8O3PxiBFeo48K+3rZ2H1EgXpoHjx1Ws=; b=SzkOCBdjzcRLHn3/wXSurN2oJCF+8rHU4Yr8qwsSHjJ/BZgpwOrFh30W GN+cAbn9dbKDAp9IIbLZSdUkEvFfvg9IrqZNupxhPyTbEnXNeznp2cmfj JtRyx3ggWC0HEVTMDjQV0DQK6PRGiWjY7NEv6TTyzqPx1dEYv0UZX3Msz E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtsKAD5RIFCrRDoH/2dsb2JhbABFqhqOMAKBA4EHgicICgEXED8NBRhQIxwBBB4Xh2qbGKA0i0+BRoUiA4hNhQ2WFYFmgn+BNgc X-IronPort-AV: E=Sophos;i="4.77,722,1336348800"; d="scan'208";a="51160425" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 06 Aug 2012 23:25:36 +0000 Received: from dwingWS (sjc-vpn3-793.cisco.com [10.21.67.25]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q76NPZ3p011040; Mon, 6 Aug 2012 23:25:36 GMT From: "Dan Wing" To: Date: Mon, 6 Aug 2012 16:25:35 -0700 Message-ID: <07e201cd742a$c8505a10$58f10e30$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac10KsgS8/15saAMSM+C3NclQ0mkVw== Content-Language: en-us Cc: oscar.gallego@vodafone.com, draft-holmberg-sipcore-rkeep@tools.ietf.org Subject: [sipcore] comments on draft-holmberg-sipcore-rkeep-00 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, 06 Aug 2012 23:25:37 -0000 The document insufficient describes the problem. It only says "One reason can be that the scheduling policy", with insufficient detail. After bumping into the SIPCORE chairs and mentioning that I had some feedback on 'rkeep', I have a deeper understanding of the problem space. However, the document should provide that understanding. Specifically, the problem is that applications cannot get scheduled to send their periodic keepalive messages, but that a network-originated packet will allow the application to get scheduled to send its reply; it is that reply message that is critical to RKEEP working (because the NAT pinhole is often only refreshed with outbound traffic, not inbound traffic). This needs to be clearly stated in the document. When that is done, we can more carefully understand the reason that operating systems are reluctant to schedule applications to send occasional keepalive traffic. I would guess the reasoning is to save the device's battery. If my guess is accurate, then RKEEP destroys (ruins) that purpose of application scheduling. SIP is not the sole protocol that would benefit from RKEEP. We could see other long-lived quiescent connections benefiting from RKEEP, such as IMAP or XMPP, to keep their TCP connections open. If RKEEP is used by those other connections, the servers will not synchronize when they send their keepalive traffic. In contrast, if the applications were allowed to schedule their own application keepalives and their own network keepalives, the applications (or the client operating system) could coordinate those application and network keepalives to use the battery most efficiently. With RKEEP's network-based keepalives, such efficiency can never be realized. This text in the document: This section describes how SIP UAs and proxies negotiate usage of keep-alives associated with a registration, or a dialog, which types of SIP requests can be used in order to negotiate the usage, and the lifetime of the negotiated keep-alives. and several other places in the document, intermixes two things, (a) SIP dialog state and (b) NAT pinhole state. These really need to be described separately, because they are different things -- (a) is application state (SIP dialog state) the (b) is network middlebox state (NAT state). Combining them, for the purposes of optimization, is useful, but needs to be clearly stated. This is because if the SIP communication is over TCP or is signaled with PCP, the network state maintenance changes whereas the application state may well remain the same (the application may want a 'liveness' check every ~10 minutes, but the network elements no longer need such frequent traffic). The document needs to acknowledge and describe the firewalls -- and not just NATs -- create state that occasionally needs refreshing. Currently, the word 'firewall' does not appear in the document at all. This is important because while it might be true that "NAT goes away with IPv6", the need and value of firewalls to protect the network (from useless noise traffic) and to protect hosts does not necessarily go away with IPv6. And of course NAT64, if it is used with a SIP service (e.g., over the top service), may also need these similar functions and thus IPv6 (on the handset) didn't eliminate the need for NAT keepalives if the traffic traverses a stateful NAT64. The document should recommend PCP as the better answer than RKEEP. Nit: removing the rkeep parameter (Section 5.4) isn't the best way to signal support of rkeep, but I believe that feedback was already provided in the WG meeting. -d From pkyzivat@alum.mit.edu Mon Aug 6 16:43:17 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD46111E80D7 for ; Mon, 6 Aug 2012 16:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=0.309, 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 Ugx8uk1rxEYI for ; Mon, 6 Aug 2012 16:43:17 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id CA2EA11E8087 for ; Mon, 6 Aug 2012 16:43:16 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta03.westchester.pa.mail.comcast.net with comcast id jPnb1j00C1HzFnQ53bjKR3; Mon, 06 Aug 2012 23:43:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id jbjJ1j00F3ZTu2S3abjJZg; Mon, 06 Aug 2012 23:43:18 +0000 Message-ID: <50205693.5050109@alum.mit.edu> Date: Mon, 06 Aug 2012 16:43:15 -0700 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <07e201cd742a$c8505a10$58f10e30$@com> In-Reply-To: <07e201cd742a$c8505a10$58f10e30$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] comments on draft-holmberg-sipcore-rkeep-00 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, 06 Aug 2012 23:43:17 -0000 Thank you Dan for providing a different perspective. This demonstrates a reason not to rush this work into sipcore - that we should investigate if the problem deserves to be considered in a broader focus. While we think about where to deal with this I encourage more discussion. Thanks, Paul (as sipcore co-chair) On 8/6/12 4:25 PM, Dan Wing wrote: > The document insufficient describes the problem. It only says "One reason > can be that the scheduling policy", with insufficient detail. After bumping > into the SIPCORE chairs and mentioning that I had some feedback on 'rkeep', > I have a deeper understanding of the problem space. However, the document > should provide that understanding. Specifically, the problem is that > applications cannot get scheduled to send their periodic keepalive messages, > but that a network-originated packet will allow the application to get > scheduled to send its reply; it is that reply message that is critical to > RKEEP working (because the NAT pinhole is often only refreshed with outbound > traffic, not inbound traffic). This needs to be clearly stated in the > document. When that is done, we can more carefully understand the reason > that operating systems are reluctant to schedule applications to send > occasional keepalive traffic. I would guess the reasoning is to save the > device's battery. If my guess is accurate, then RKEEP destroys (ruins) that > purpose of application scheduling. SIP is not the sole protocol that would > benefit from RKEEP. We could see other long-lived quiescent connections > benefiting from RKEEP, such as IMAP or XMPP, to keep their TCP connections > open. If RKEEP is used by those other connections, the servers will not > synchronize when they send their keepalive traffic. In contrast, if the > applications were allowed to schedule their own application keepalives and > their own network keepalives, the applications (or the client operating > system) could coordinate those application and network keepalives to use the > battery most efficiently. With RKEEP's network-based keepalives, such > efficiency can never be realized. > > > This text in the document: > This section describes how SIP UAs and proxies negotiate usage of > keep-alives associated with a registration, or a dialog, which types > of SIP requests can be used in order to negotiate the usage, and the > lifetime of the negotiated keep-alives. > and several other places in the document, intermixes two things, (a) SIP > dialog state and (b) NAT pinhole state. These really need to be described > separately, because they are different things -- (a) is application state > (SIP dialog state) the (b) is network middlebox state (NAT state). > Combining them, for the purposes of optimization, is useful, but needs to be > clearly stated. This is because if the SIP communication is over TCP or is > signaled with PCP, the network state maintenance changes whereas the > application state may well remain the same (the application may want a > 'liveness' check every ~10 minutes, but the network elements no longer need > such frequent traffic). > > > The document needs to acknowledge and describe the firewalls -- and not just > NATs -- create state that occasionally needs refreshing. Currently, the > word 'firewall' does not appear in the document at all. This is important > because while it might be true that "NAT goes away with IPv6", the need and > value of firewalls to protect the network (from useless noise traffic) and > to protect hosts does not necessarily go away with IPv6. And of course > NAT64, if it is used with a SIP service (e.g., over the top service), may > also need these similar functions and thus IPv6 (on the handset) didn't > eliminate the need for NAT keepalives if the traffic traverses a stateful > NAT64. > > The document should recommend PCP as the better answer than RKEEP. > > > Nit: removing the rkeep parameter (Section 5.4) isn't the best way to > signal support of rkeep, but I believe that feedback was already provided in > the WG meeting. > > -d > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From hannes.tschofenig@gmx.net Tue Aug 7 00:35:11 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6AA911E80EE for ; Tue, 7 Aug 2012 00:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.615 X-Spam-Level: X-Spam-Status: No, score=-102.615 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 7C-BDuAVULqU for ; Tue, 7 Aug 2012 00:35:04 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id F0E1F11E80A6 for ; Tue, 7 Aug 2012 00:35:03 -0700 (PDT) Received: (qmail invoked by alias); 07 Aug 2012 07:35:02 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp001) with SMTP; 07 Aug 2012 09:35:02 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+Fxpc2vXOFonBJ8mvuymtz0e4kTPzWzf8S07sM1E f0KS3SCzy/9O5E From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Aug 2012 10:35:01 +0300 Message-Id: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> To: "SIPCORE (Session Initiation Protocol Core) WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [sipcore] Geolocation Header Question 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, 07 Aug 2012 07:35:11 -0000 Hi guys,=20 I had gotten a question from the ATIS guys since they are thinking about = using the Geolocation header from RFC 6442 but in an interesting way.=20 Section 4.1 of RFC 6442 indicates what URIs can go into the Geolocation = header, which includes SIP and SIPS URIs.=20 ATIS has a different deployment model where the SIP messages go to a = gateway that allows interactions with a legacy PSAP. The legacy PSAP = then performs a location lookup using a regular phone number (using = legacy location protocols).=20 In order to convey that phone number for a lookup they are thinking = about using the Geolocation header in the following form: Geolocation: 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 B27E121F85E0 for ; Tue, 7 Aug 2012 07:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, 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 QjX6WgTABrZC for ; Tue, 7 Aug 2012 07:31:11 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3035221F85D0 for ; Tue, 7 Aug 2012 07:31:11 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id jnAi1j00F1ZXKqc53qXD2f; Tue, 07 Aug 2012 14:31:13 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id jqXi1j00L3ZTu2S3hqXj9s; Tue, 07 Aug 2012 14:31:43 +0000 Message-ID: <502126AB.5090807@alum.mit.edu> Date: Tue, 07 Aug 2012 07:31:07 -0700 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> In-Reply-To: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Geolocation Header Question 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, 07 Aug 2012 14:31:12 -0000 On 8/7/12 12:35 AM, Hannes Tschofenig wrote: > Hi guys, > > I had gotten a question from the ATIS guys since they are thinking about using the Geolocation header from RFC 6442 but in an interesting way. > > Section 4.1 of RFC 6442 indicates what URIs can go into the Geolocation header, which includes SIP and SIPS URIs. > > ATIS has a different deployment model where the SIP messages go to a gateway that allows interactions with a legacy PSAP. The legacy PSAP then performs a location lookup using a regular phone number (using legacy location protocols). > > In order to convey that phone number for a lookup they are thinking about using the Geolocation header in the following form: > Geolocation: > Since a SIP URI is allowed in the Geolocation header it seems that this functionality is supported but the semantics is quite different to what SIP location conveyance envisions. The envisioned functionality was that the receipient of that location URI would either look at the body of the message (in case of a CID), would use HELD (in case of a HTTP/HTTPS URI) or SIP (in case of a SIP, SIPS, or PRES URI). > > I had spoken to a few of you during the meeting and I had gotten conflicting responses about whether this is allowed behavior or not. > > Any feedback from folks on this list? Well, the problem I see with this is that including a sip uri in geolocation header field implies that the deref will be done via a subscribe. Apparently that isn't then intent here. That presents two distinct problems: - what happens if the dereferencer actually tries to use subscribe? - what happens if dereferencer uses this ATIS-specific mechanism but the server for the designated URI only supports subscribe and not this new mechanism? I have no problem with using this approach *if* both of the above cases work. But if either of them will fail then I think this is an abuse of 6442. IMO it would be ok for the dereferencer to attempt some proprietary optimization of the deref as long as: - it is also capable of falling back to subscribe if the optimization fails; - the server for the supplied sip uri (mgcf.carrier.net in the example) is capable of handling the subscribe if it gets one; - the results of the subscribe and the proprietary deref always yield the same result. Thanks, Paul (as individual) (I'm speaking as an individual for now. Later we can discuss if we need a chair ruling.) From dworley@avaya.com Tue Aug 7 07:53:42 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBCAD21F8702 for ; Tue, 7 Aug 2012 07:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.773 X-Spam-Level: X-Spam-Status: No, score=-102.773 tagged_above=-999 required=5 tests=[AWL=-0.174, 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 dIN1LFFHkYgH for ; Tue, 7 Aug 2012 07:53:42 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id CF65C21F86FC for ; Tue, 7 Aug 2012 07:53:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIcqIVDGmAcF/2dsb2JhbABFuUaBB4IgAQEBAQIBEigtFwsCAQgNCCEQMiUBAQQTCBqHXAMGBp5dnV6KK4ZxYAObRYoPgns X-IronPort-AV: E=Sophos;i="4.77,727,1336363200"; d="scan'208";a="21368085" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 07 Aug 2012 10:47:47 -0400 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 07 Aug 2012 10:48:51 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 7 Aug 2012 10:53:39 -0400 From: "Worley, Dale R (Dale)" To: Hannes Tschofenig , "SIPCORE (Session Initiation Protocol Core) WG" Date: Tue, 7 Aug 2012 10:52:11 -0400 Thread-Topic: [sipcore] Geolocation Header Question Thread-Index: Ac10bzDYDSrbsANjQ4OeLOS6P2BnMQAPQlD1 Message-ID: References: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> In-Reply-To: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] Geolocation Header Question 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, 07 Aug 2012 14:53:43 -0000 > From: Hannes Tschofenig [hannes.tschofenig@gmx.net] >=20 > In order to convey that phone number for a lookup they are thinking > about using the Geolocation header in the following form: > Geolocation: 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 C93D921F84DD for ; Tue, 7 Aug 2012 08:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 vgACDdLgrb1W for ; Tue, 7 Aug 2012 08:31:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id CDA6621F84CD for ; Tue, 7 Aug 2012 08:31:20 -0700 (PDT) Received: (qmail invoked by alias); 07 Aug 2012 15:31:19 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp010) with SMTP; 07 Aug 2012 17:31:19 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19roixSkpxr9lIiFO3pX79/tooEPsYDoJ0mMxENAe RRD6sbYk8RiXAK Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Tue, 7 Aug 2012 18:31:18 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> To: "Worley, Dale R (Dale)" X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Geolocation Header Question 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, 07 Aug 2012 15:31:35 -0000 I agree but the tel URI is not one of the supported location URIs in RFC = 6442.=20 Hence, the guys just use a different way to convey the same information.=20= On Aug 7, 2012, at 5:52 PM, Worley, Dale R (Dale) wrote: >> From: Hannes Tschofenig [hannes.tschofenig@gmx.net] >>=20 >> In order to convey that phone number for a lookup they are thinking >> about using the Geolocation header in the following form: >> Geolocation:=20 > Naively, I'd say that since the goal is to carry an E.164 number, a > tel: URI would be the ideal choice. >=20 > Dale From hannes.tschofenig@gmx.net Tue Aug 7 08:36:06 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA7521F859F for ; Tue, 7 Aug 2012 08:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 WmG9alc8sOaS for ; Tue, 7 Aug 2012 08:36:05 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3201321F8646 for ; Tue, 7 Aug 2012 08:36:05 -0700 (PDT) Received: (qmail invoked by alias); 07 Aug 2012 15:35:56 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.105]) [88.115.216.191] by mail.gmx.net (mp071) with SMTP; 07 Aug 2012 17:35:56 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX194ZlQLa8x4/ltg2IvlgFNsYHWjreahVGB/0ukJcL HymU1+rerBI5Nv Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <502126AB.5090807@alum.mit.edu> Date: Tue, 7 Aug 2012 18:35:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <25EE25ED-76E4-40ED-8290-B6D071677B73@gmx.net> References: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> <502126AB.5090807@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: sipcore@ietf.org Subject: Re: [sipcore] Geolocation Header Question 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, 07 Aug 2012 15:36:07 -0000 Hi Paul,=20 these are good points. Thanks for the feedback.=20 I could imagine that the interaction with the location server fails when = one tries to dereference the location URI using a subscribe. I will forward your comments to the respective ATIS persons.=20 Ciao Hannes On Aug 7, 2012, at 5:31 PM, Paul Kyzivat wrote: > On 8/7/12 12:35 AM, Hannes Tschofenig wrote: >> Hi guys, >>=20 >> I had gotten a question from the ATIS guys since they are thinking = about using the Geolocation header from RFC 6442 but in an interesting = way. >>=20 >> Section 4.1 of RFC 6442 indicates what URIs can go into the = Geolocation header, which includes SIP and SIPS URIs. >>=20 >> ATIS has a different deployment model where the SIP messages go to a = gateway that allows interactions with a legacy PSAP. The legacy PSAP = then performs a location lookup using a regular phone number (using = legacy location protocols). >>=20 >> In order to convey that phone number for a lookup they are thinking = about using the Geolocation header in the following form: >> Geolocation:>=20 >> Since a SIP URI is allowed in the Geolocation header it seems that = this functionality is supported but the semantics is quite different to = what SIP location conveyance envisions. The envisioned functionality was = that the receipient of that location URI would either look at the body = of the message (in case of a CID), would use HELD (in case of a = HTTP/HTTPS URI) or SIP (in case of a SIP, SIPS, or PRES URI). >>=20 >> I had spoken to a few of you during the meeting and I had gotten = conflicting responses about whether this is allowed behavior or not. >>=20 >> Any feedback from folks on this list? >=20 > Well, the problem I see with this is that including a sip uri in = geolocation header field implies that the deref will be done via a = subscribe. Apparently that isn't then intent here. >=20 > That presents two distinct problems: >=20 > - what happens if the dereferencer actually tries to use subscribe? >=20 > - what happens if dereferencer uses this ATIS-specific mechanism > but the server for the designated URI only supports subscribe > and not this new mechanism? >=20 > I have no problem with using this approach *if* both of the above = cases work. But if either of them will fail then I think this is an = abuse of 6442. >=20 > IMO it would be ok for the dereferencer to attempt some proprietary = optimization of the deref as long as: > - it is also capable of falling back to subscribe if the optimization > fails; > - the server for the supplied sip uri (mgcf.carrier.net in the = example) > is capable of handling the subscribe if it gets one; > - the results of the subscribe and the proprietary deref always > yield the same result. >=20 > Thanks, > Paul (as individual) >=20 > (I'm speaking as an individual for now. Later we can discuss if we = need a chair ruling.) > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From internet-drafts@ietf.org Wed Aug 8 08:41:57 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720A221F86BD; Wed, 8 Aug 2012 08:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 ahcc64QnHYyu; Wed, 8 Aug 2012 08:41:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C746321F86B2; Wed, 8 Aug 2012 08:41:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120808154156.11189.17768.idtracker@ietfa.amsl.com> Date: Wed, 08 Aug 2012 08:41:56 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-05.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, 08 Aug 2012 15:41:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : Mechanism to indicate support of features and capabiliti= es in the Session Initiation Protocol (SIP) Author(s) : Christer Holmberg Ivo Sedlacek Hadriel Kaplan Filename : draft-ietf-sipcore-proxy-feature-05.txt Pages : 20 Date : 2012-08-08 Abstract: This specification defines a new SIP header field, Feature-Caps, to convey feature capability indicators, which are used by SIP entities not represented by the URI of the Contact header field to indicate support of features and capabilities, where media feature tags cannot be used to indicate the support. This specification also defines feature capability indicators, and creates a new IANA registry, "Proxy-Feature Feature Capability Indicator Trees", for registering feature capability indicators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-proxy-feature There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-proxy-feature-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Wed Aug 8 09:09:05 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C5621F8713 for ; Wed, 8 Aug 2012 09:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r66NiVXMILEE for ; Wed, 8 Aug 2012 09:09:04 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5009921F8712 for ; Wed, 8 Aug 2012 09:09:04 -0700 (PDT) X-AuditID: c1b4fb30-b7fd46d000003161-bc-50228f1f205f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 10.47.12641.F1F82205; Wed, 8 Aug 2012 18:09:03 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 8 Aug 2012 18:09:03 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Date: Wed, 8 Aug 2012 18:09:02 +0200 Thread-Topic: Draft new version: proxy-feature-05 Thread-Index: AQHNdYAgKxVBhr8w/EuztgeQoF5sHw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853408683616@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM+Jvra58v1KAwc7VihZff2xic2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtYG/oJpjBXbFj1nbWAs6mJk55AQMJHot+pi5ASyxCQu3FvP 1sXIxSEkcIpR4uiiEywQzmxGicbfK5i6GDk42AQsJLr/aYM0iAhoSiz/tpUdxGYRUJF4cXgP G4gtLKAjcfDqNmaIGkOJa3vWsEDYehLffm8Cq+EVCJf4/+Q8I4jNCLT4+6k1TCA2s4C4xK0n 85kgDhKQWLLnPDOELSrx8vE/Voh6UYk77esZIer1JG5MncIGYWtLLFv4mhlivqDEyZlPWCYw Cs9CMnYWkpZZSFpmIWlZwMiyilE4NzEzJ73cXC+1KDO5uDg/T684dRMjMKwPbvltsINx032x Q4zSHCxK4rx6qvv9hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTC6LWKSto0QOL5OYwV71+lP hSs1DXe631fQWPrPoviBkeQPz/K/S6S3ZsT/idi/jLPqXtWEJ8aB65d8SZvKcco/Vc6vq3zv pSmNzzROn3zMVHm8IGli9hHP3JdTL+1Mea52hCtq3SOrN3myvaF2E3d/y1rk5R5tXVc9q8yl K0jg3KY0fw6XtdeVWIozEg21mIuKEwGP0b9uOQIAAA== Subject: [sipcore] Draft new version: proxy-feature-05 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, 08 Aug 2012 16:09:05 -0000 Hi, I have submitted a new version (-05) of the proxy-feature draft, based on K= eith's WGLC comments. May the force be with you, Christer From christer.holmberg@ericsson.com Wed Aug 8 12:50:57 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538F721F85C3 for ; Wed, 8 Aug 2012 12:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V61cAyojX-zu for ; Wed, 8 Aug 2012 12:50:56 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDBF21F85B8 for ; Wed, 8 Aug 2012 12:50:54 -0700 (PDT) X-AuditID: c1b4fb2d-b7fd66d0000004ad-17-5022c31dac87 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A3.47.01197.D13C2205; Wed, 8 Aug 2012 21:50:53 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 8 Aug 2012 21:50:53 +0200 From: Christer Holmberg To: Dan Wing , "sipcore@ietf.org" Date: Wed, 8 Aug 2012 21:50:52 +0200 Thread-Topic: comments on draft-holmberg-sipcore-rkeep-00 Thread-Index: Ac10KsgS8/15saAMSM+C3NclQ0mkVwAFLVD+ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853408683603@ESESSCMS0356.eemea.ericsson.se> References: <07e201cd742a$c8505a10$58f10e30$@com> In-Reply-To: <07e201cd742a$c8505a10$58f10e30$@com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvra7sYaUAgxWTDS2ed75jtbh47SGT xcnLi1ktvv7YxObA4jHl90ZWjyVLfjJ5fLn8mc2jb8Z6xgCWKC6blNSczLLUIn27BK6M5fN5 Cn6rVxx+k9LAOE+hi5GTQ0LARGLTh/NsELaYxIV764FsLg4hgVOMElv6T7BAOPMZJXobnwA5 HBxsAhYS3f+0QRpEBFwlfpzfzwhSwywwj1Fiz7FZTCAJFgEViekPf7GD2MJA9beO9rJDNFhK LOnrhrKNJKZ9fwBWzysQLrH8fxMjyHwhAUOJ9v8OIGFOoJKbTZ9ZQWxGoOO+n1oDVs4sIC5x 68l8JoijBSSW7DnPDGGLSrx8/A+qXlTiTvt6Roh6HYkFuz+xQdjaEssWvmaGWCsocXLmE5YJ jGKzkIydhaRlFpKWWUhaFjCyrGIUzk3MzEkvN9RLLcpMLi7Oz9MrTt3ECIyvg1t+6+5gPHVO 5BCjNAeLkjgvV9J+fyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MTYdvSqh2Wnz6oPZmN+uV Q5Mfs6dOSz+hoaeyqJx39vUEPa2kysJav9Nv9jDVLPyvdqTg0VXly3vCO4vYchYLfV4dbXe+ 6dJ5f90XgebP1kluKajROBNj4KuRzPK/8KDAutm/G+V/Vz3k//WwNW3Gj+qP0ob7K5KFDrF6 nLl0deWK3uy3Wy9lKLEUZyQaajEXFScCAJL2B+R9AgAA Cc: "oscar.gallego@vodafone.com" , "draft-holmberg-sipcore-rkeep@tools.ietf.org" Subject: Re: [sipcore] comments on draft-holmberg-sipcore-rkeep-00 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, 08 Aug 2012 19:50:57 -0000 Hi Dan, >The document insufficient describes the problem. It only says "One reason >can be that the scheduling policy", with insufficient detail. After bumpi= ng >into the SIPCORE chairs and mentioning that I had some feedback on 'rkeep'= , >I have a deeper understanding of the problem space. However, the document >should provide that understanding. Specifically, the problem is that >applications cannot get scheduled to send their periodic keepalive message= s, >but that a network-originated packet will allow the application to get >scheduled to send its reply; it is that reply message that is critical to >RKEEP working (because the NAT pinhole is often only refreshed with outbou= nd >traffic, not inbound traffic). This needs to be clearly stated in the >document. In my presentation, I tried to make it very clear that it is the STUN *resp= onse*, sent from the UA, which acts as the actual keep-alive message, due to the reason you also mention, But, I do agree with you that it should be made more clear in the draft. >When that is done, we can more carefully understand the reason >that operating systems are reluctant to schedule applications to send >occasional keepalive traffic. I would guess the reasoning is to save the >device's battery. If my guess is accurate, then RKEEP destroys (ruins) tha= t >purpose of application scheduling. I don't think it's only about sending keep-alives, but to be able to perfor= m any type of scheduled actions. >SIP is not the sole protocol that would benefit from RKEEP. We could see = other long-lived quiescent connections >benefiting from RKEEP, such as IMAP or XMPP, to keep their TCP connections= open. Keep in mind that the actual STUN keep-alive mechanism is already defined i= n RFC 5626. This draft only defines a *SIP* mechanism for negotiating the usage of it. If you want to define how *other* protocols negotiate the usage of STUN for= keep-alives, I don't think it belongs in this draft. >If RKEEP is used by those other connections, the servers will not synchron= ize when they send their keepalive traffic. In contrast, if the >applications were allowed to schedule their own application keepalives and= their own network keepalives, the=20 >applications (or the client operating system) could coordinate those appli= cation and network keepalives to use the >battery most efficiently. With RKEEP's network-based keepalives, such eff= iciency can never be realized. > >This text in the document: > This section describes how SIP UAs and proxies negotiate usage of > keep-alives associated with a registration, or a dialog, which types > of SIP requests can be used in order to negotiate the usage, and the > lifetime of the negotiated keep-alives. >and several other places in the document, intermixes two things, (a) SIP >dialog state and (b) NAT pinhole state. These really need to be described >separately, because they are different things -- (a) is application state >(SIP dialog state) the (b) is network middlebox state (NAT state). >Combining them, for the purposes of optimization, is useful, but needs to = be >clearly stated. SIP dialog only refers to the scope of the negotiated keep-alives, ie that = you can negotiate them to be sent within the lifetime of a SIP dialog. >This is because if the SIP communication is over TCP or is >signaled with PCP, the network state maintenance changes whereas the >application state may well remain the same (the application may want a >'liveness' check every ~10 minutes, but the network elements no longer nee= d >such frequent traffic). > >The document needs to acknowledge and describe the firewalls -- and not ju= st >NATs -- create state that occasionally needs refreshing. Currently, the >word 'firewall' does not appear in the document at all. This is important >because while it might be true that "NAT goes away with IPv6", the need an= d >value of firewalls to protect the network (from useless noise traffic) and >to protect hosts does not necessarily go away with IPv6. And of course >NAT64, if it is used with a SIP service (e.g., over the top service), may >also need these similar functions and thus IPv6 (on the handset) didn't >eliminate the need for NAT keepalives if the traffic traverses a stateful >NAT64. > > The document should recommend PCP as the better answer than RKEEP. As said earlier, the STUN keep-alive mechanism is already defined in RFC 56= 26.=20 RFC 6233 defines a SIP mechanism which allows a UA behind a NAT to indicate= willingness to send such STUN requests, and this draft now defines a SIP m= echanism (based on the 6233 mechanism) which allows a UA behind a NAT to in= dicate willingess to receive such STUN requests. >Nit: removing the rkeep parameter (Section 5.4) isn't the best way to >signal support of rkeep, but I believe that feedback was already provided = in >the WG meeting. The details of the mechanism obviously needs to be discussed, if the work i= s started. Regards, Christer= From adam@nostrum.com Wed Aug 8 13:07:02 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF9B611E80F3 for ; Wed, 8 Aug 2012 13:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.24 X-Spam-Level: X-Spam-Status: No, score=-102.24 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEhIhSmcn6Pb for ; Wed, 8 Aug 2012 13:07:02 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0639711E8072 for ; Wed, 8 Aug 2012 13:07:01 -0700 (PDT) Received: from Svantevit.local ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q78K6xvR066045 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 8 Aug 2012 15:06:59 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5022C6E3.2030309@nostrum.com> Date: Wed, 08 Aug 2012 15:06:59 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <07e201cd742a$c8505a10$58f10e30$@com> <7F2072F1E0DE894DA4B517B93C6A05853408683603@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853408683603@ESESSCMS0356.eemea.ericsson.se> Content-Type: multipart/alternative; boundary="------------010002030702000207040807" Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: Re: [sipcore] comments on draft-holmberg-sipcore-rkeep-00 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, 08 Aug 2012 20:07:03 -0000 This is a multi-part message in MIME format. --------------010002030702000207040807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as an individual] On 8/8/12 2:50 PM, Christer Holmberg wrote: > Keep in mind that the actual STUN keep-alive mechanism is already defined in RFC 5626. This draft only defines a*SIP* > mechanism for negotiating the usage of it. > > If you want to define how*other* protocols negotiate the usage of STUN for keep-alives, I don't think it belongs in this draft. The concern, I believe -- and I've heard this from people other than Dan -- is that the issue of sending periodic NAT binding keepalives in the face of unpredictable OS scheduling is a *general* problem, and that it might be inadvisable to come up with application-by-application solutions to the problem. /a --------------010002030702000207040807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
[as an individual]

On 8/8/12 2:50 PM, Christer Holmberg wrote:
Keep in mind that the actual STUN keep-alive mechanism is already defined in RFC 5626. This draft only defines a *SIP*
mechanism for negotiating the usage of it.

If you want to define how *other* protocols negotiate the usage of STUN for keep-alives, I don't think it belongs in this draft.

The concern, I believe -- and I've heard this from people other than Dan -- is that the issue of sending periodic NAT binding keepalives in the face of unpredictable OS scheduling is a *general* problem, and that it might be inadvisable to come up with application-by-application solutions to the problem.

/a
--------------010002030702000207040807-- From christer.holmberg@ericsson.com Wed Aug 8 13:31:48 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D53521F85CD for ; Wed, 8 Aug 2012 13:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tl7Gcxi4X5HU for ; Wed, 8 Aug 2012 13:31:47 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 625F521F85DB for ; Wed, 8 Aug 2012 13:31:47 -0700 (PDT) X-AuditID: c1b4fb2d-b7fd66d0000004ad-be-5022ccb28e1a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C6.7A.01197.2BCC2205; Wed, 8 Aug 2012 22:31:46 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.21]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 8 Aug 2012 22:31:45 +0200 From: Christer Holmberg To: Adam Roach , "sipcore@ietf.org" Date: Wed, 8 Aug 2012 22:28:39 +0200 Thread-Topic: [sipcore] comments on draft-holmberg-sipcore-rkeep-00 Thread-Index: Ac11oWI4+RxSiMmES7e2qXwJGQw2YQAAwMJS Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853408683619@ESESSCMS0356.eemea.ericsson.se> References: <07e201cd742a$c8505a10$58f10e30$@com> <7F2072F1E0DE894DA4B517B93C6A05853408683603@ESESSCMS0356.eemea.ericsson.se>, <5022C6E3.2030309@nostrum.com> In-Reply-To: <5022C6E3.2030309@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvre6mM0oBBmvXKFns+buI3eLrj01s DkweS5b8ZPKYtfMJSwBTFJdNSmpOZllqkb5dAlfG7a4mloJF7BWrJ99gbWB8zdrFyMEhIWAi 8XWOUxcjJ5ApJnHh3nq2LkYuDiGBU4wSm7Y+ZoRw5jNKTJ4/gx2kgU3AQqL7nzZIg4iAh8SM J9eZQGwWARWJTy272UBsYQEniedX5zJD1DhL7H87nxXCNpJ4t+IGO4jNKxAuMXPOcmaI+fMY JX7fPM8IkuAU0JaY07wMrIgR6KLvp9aALWAWEJe49WQ+E8SlAhJL9pxnhrBFJV4+/scKUS8q cad9PSNEvY7Egt2f2CBsbYllC18zQywWlDg58wnLBEbRWUjGzkLSMgtJyywkLQsYWVYxCucm ZuaklxvqpRZlJhcX5+fpFaduYgTGyMEtv3V3MJ46J3KIUZqDRUmclytpv7+QQHpiSWp2ampB alF8UWlOavEhRiYOTqkGxuL19TV31Xbk2r3ftu/q8vzrEqvO6aatrpXpUntTdkLhjv7xbM/X KTccu3ZwXTv5am9fzVEvo0s1O4N+9k6cvzX0vJ3zJP5Tmy3Kjp759sM0Z0qMcGr6u+N31vAF Las/6sniobDxiSAPw1uBmJWTErVCJPcoXKxOOfxyguOdA61no1l3WrHVdSuxFGckGmoxFxUn AgAlNE7IXwIAAA== Subject: Re: [sipcore] comments on draft-holmberg-sipcore-rkeep-00 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, 08 Aug 2012 20:31:48 -0000 Hi, >[as an individual] > >On 8/8/12 2:50 PM, Christer Holmberg wrote: > >>Keep in mind that the actual STUN keep-alive mechanism is already defined= in RFC 5626. This draft only defines a *SIP* >>mechanism for negotiating the usage of it. >> >>If you want to define how *other* protocols negotiate the usage of STUN f= or keep-alives, I don't think it belongs in this draft. > >The concern, I believe -- and I've heard this from people other than Dan -= - is that the issue of sending periodic NAT binding keepalives=20 >in the face of unpredictable OS scheduling is a *general* problem, and tha= t it might be inadvisable to come up with application-by-application=20 >solutions to the problem. You might still need protocol-by-protocol solutions to negotiate the keep-a= live, and the draft defines a negotiation solution for SIP. It can then be = used by any SIP application. Regards, Christer= From dwing@cisco.com Wed Aug 8 17:41:21 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5355F21F84EA for ; Wed, 8 Aug 2012 17:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.503 X-Spam-Level: X-Spam-Status: No, score=-110.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSD9VXbvRSHm for ; Wed, 8 Aug 2012 17:41:20 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4F78321F84E4 for ; Wed, 8 Aug 2012 17:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=dwing@cisco.com; l=6615; q=dns/txt; s=iport; t=1344472880; x=1345682480; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=Advn1ZotRuKfS+V185buA7UnZrPJq3FJFUH9xEyafVE=; b=FqPM/pxUl9q/sjdiaF6m2DEXkn8AO8APZiX8UdyXjrTfyYOV1bIjIUv1 uYMsqKVf5eZv8EiFpJnyqahQ1jp8gxURo5WcGnxFHhKG/EOxdWkB3zgTv QSdTSkKs4Rn0yVmvUy3Z4Hul1hPS033RqejGdCqugrFT56NG3DpvjiZMk 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOkFI1CrRDoI/2dsb2JhbABFqhyPRoEHgiABAQEECAoBFxAxDgwBAwIJDwIEAQEoBxkjCgkIAQEEARILEAeHaptCoDCLEgWGWwOIToUMlhiBZoJ/gTYH X-IronPort-AV: E=Sophos;i="4.77,735,1336348800"; d="scan'208";a="54406132" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 09 Aug 2012 00:41:19 +0000 Received: from dwingWS (sjc-vpn4-1372.cisco.com [10.21.85.91]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q790fI6u006508; Thu, 9 Aug 2012 00:41:18 GMT From: "Dan Wing" To: "'Christer Holmberg'" , References: <07e201cd742a$c8505a10$58f10e30$@com> <7F2072F1E0DE894DA4B517B93C6A05853408683603@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853408683603@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 8 Aug 2012 17:41:17 -0700 Message-ID: <01ff01cd75c7$b0703de0$1150b9a0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac10KsgS8/15saAMSM+C3NclQ0mkVwAFLVD+AGHXLsA= Content-Language: en-us Cc: oscar.gallego@vodafone.com, draft-holmberg-sipcore-rkeep@tools.ietf.org Subject: Re: [sipcore] comments on draft-holmberg-sipcore-rkeep-00 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, 09 Aug 2012 00:41:21 -0000 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Wednesday, August 08, 2012 12:51 PM > To: Dan Wing; sipcore@ietf.org > Cc: draft-holmberg-sipcore-rkeep@tools.ietf.org; > oscar.gallego@vodafone.com > Subject: RE: comments on draft-holmberg-sipcore-rkeep-00 > > Hi Dan, > > >The document insufficient describes the problem. It only says "One > reason > >can be that the scheduling policy", with insufficient detail. After > bumping > >into the SIPCORE chairs and mentioning that I had some feedback on > 'rkeep', > >I have a deeper understanding of the problem space. However, the > document > >should provide that understanding. Specifically, the problem is that > >applications cannot get scheduled to send their periodic keepalive > messages, > >but that a network-originated packet will allow the application to get > >scheduled to send its reply; it is that reply message that is critical > to > >RKEEP working (because the NAT pinhole is often only refreshed with > outbound > >traffic, not inbound traffic). This needs to be clearly stated in the > >document. > > In my presentation, I tried to make it very clear that it is the STUN > *response*, sent > from the UA, which acts as the actual keep-alive message, due to the > reason you also mention, > > But, I do agree with you that it should be made more clear in the > draft. That is the solution. The underlying problem is caused by operating systems that are not allowing client applications, running on handsets, to send their own keepalives. It is that problem I would like to have better described. > >When that is done, we can more carefully understand the reason > >that operating systems are reluctant to schedule applications to send > >occasional keepalive traffic. I would guess the reasoning is to save > the > >device's battery. If my guess is accurate, then RKEEP destroys (ruins) > that > >purpose of application scheduling. > > I don't think it's only about sending keep-alives, but to be able to > perform any type of scheduled actions. That is vague. Can you be more specific by what you mean about 'scheduled actions', if those are not keepalive messages. > >SIP is not the sole protocol that would benefit from RKEEP. We could > see other long-lived quiescent connections > >benefiting from RKEEP, such as IMAP or XMPP, to keep their TCP > connections open. > > Keep in mind that the actual STUN keep-alive mechanism is already > defined in RFC 5626. This draft only defines a *SIP* > mechanism for negotiating the usage of it. > > If you want to define how *other* protocols negotiate the usage of STUN > for keep-alives, I don't think it belongs in this draft. I understand the scope of the draft. My point is that the problem is larger than just the SIP application. That is why I want the problem described better, so we can understand the underlying cause of the problem -- and either get that fixed (because it is flawed) or understand it better so we can quickly apply this same RKEEP-style workaround to the other 213 applications that use long-lived connections (the number 213 might be off by an order of magnitude). > >If RKEEP is used by those other connections, the servers will not > synchronize when they send their keepalive traffic. In contrast, if > the > >applications were allowed to schedule their own application keepalives > and their own network keepalives, the > >applications (or the client operating system) could coordinate those > application and network keepalives to use the > >battery most efficiently. With RKEEP's network-based keepalives, such > efficiency can never be realized. > > > >This text in the document: > > This section describes how SIP UAs and proxies negotiate usage of > > keep-alives associated with a registration, or a dialog, which > types > > of SIP requests can be used in order to negotiate the usage, and > the > > lifetime of the negotiated keep-alives. > >and several other places in the document, intermixes two things, (a) > SIP > >dialog state and (b) NAT pinhole state. These really need to be > described > >separately, because they are different things -- (a) is application > state > >(SIP dialog state) the (b) is network middlebox state (NAT state). > >Combining them, for the purposes of optimization, is useful, but needs > to be > >clearly stated. > > SIP dialog only refers to the scope of the negotiated keep-alives, ie > that you can negotiate them to be sent within the lifetime of a SIP > dialog. I'll leave it to y'all, as SIP experts, how that relates to registration refresh, if it relates at all. > >This is because if the SIP communication is over TCP or is > >signaled with PCP, the network state maintenance changes whereas the > >application state may well remain the same (the application may want a > >'liveness' check every ~10 minutes, but the network elements no longer > need > >such frequent traffic). > > > >The document needs to acknowledge and describe the firewalls -- and > not just > >NATs -- create state that occasionally needs refreshing. Currently, > the > >word 'firewall' does not appear in the document at all. This is > important > >because while it might be true that "NAT goes away with IPv6", the > need and > >value of firewalls to protect the network (from useless noise traffic) > and > >to protect hosts does not necessarily go away with IPv6. And of > course > >NAT64, if it is used with a SIP service (e.g., over the top service), > may > >also need these similar functions and thus IPv6 (on the handset) > didn't > >eliminate the need for NAT keepalives if the traffic traverses a > stateful > >NAT64. > > > > The document should recommend PCP as the better answer than RKEEP. > > As said earlier, the STUN keep-alive mechanism is already defined in > RFC 5626. > > RFC 6233 defines a SIP mechanism which allows a UA behind a NAT to > indicate willingness to send such STUN requests, and this draft now > defines a SIP mechanism (based on the 6233 mechanism) which allows a UA > behind a NAT to indicate willingess to receive such STUN requests. -d > >Nit: removing the rkeep parameter (Section 5.4) isn't the best way to > >signal support of rkeep, but I believe that feedback was already > provided in > >the WG meeting. > > The details of the mechanism obviously needs to be discussed, if the > work is started. > > Regards, > > Christer= From adam@nostrum.com Fri Aug 10 11:38:42 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EECC921F871E for ; Fri, 10 Aug 2012 11:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.273 X-Spam-Level: X-Spam-Status: No, score=-102.273 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gX8q1hVYiyxi for ; Fri, 10 Aug 2012 11:38:41 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 47ABE21F8715 for ; Fri, 10 Aug 2012 11:38:41 -0700 (PDT) Received: from Svantevit.local ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7AIceZt031449 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 10 Aug 2012 13:38:40 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <50255530.1020208@nostrum.com> Date: Fri, 10 Aug 2012 13:38:40 -0500 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [sipcore] WGLC: draft-ietf-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 18:38:42 -0000 [as chair] Based on feedback received from the authors and working group, we believe that the document "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)" is ready for working group last call. Working group participants -- and, in particular, those participants who indicated a willingness to perform a dedicated review of the document -- are asked to read the current document and provide feedback. Even short statements along the lines of "I have carefully read the document and believe it is ready for publication" are useful. The current version of the document is available here: http://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket/ This WGLC runs until Friday, August 24th. Thank you. /a From roman@telurix.com Fri Aug 10 14:31:45 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E531111E8099 for ; Fri, 10 Aug 2012 14:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.859 X-Spam-Level: X-Spam-Status: No, score=-2.859 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sqk5iXeKxNF for ; Fri, 10 Aug 2012 14:31:44 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD0011E808E for ; Fri, 10 Aug 2012 14:31:44 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3315043pbb.31 for ; Fri, 10 Aug 2012 14:31:44 -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:cc:content-type :x-gm-message-state; bh=T3M7tbrs/LhP93o5Lw5zN/Y977RPgfD17eoVEOLOnwU=; b=ADVUa5QwAlidkmR6GRs23E+gr1Ajm3Od79JoTrMoSjGY9grmHCPwtsONcdSs8lF+ee 4DR3Ii+3HVj3mK7MMmKUD60Sb9HWa/K+bMPNntLGtr1fS+v8gQ5NOteMyurN5XN4vRHp ZQUj3aImuURaOJmnrC22AZIeMbXKfYlWof52M4mvhQ3l2txSQuZJvze7WosSmIZ0ecyo c+UouxObP9wURwYyz+J5GaSLRKIlD+F3eAGPOClwiFEKLXoC6diqgUVmOKVYZeBKC642 178ldKWjfzMQITas7S3QU5/4Va1Bn+upl2GU032B9mNGcOi0pPvATxtPCO2efAdds46N hlQA== Received: by 10.68.116.48 with SMTP id jt16mr15583287pbb.101.1344634304312; Fri, 10 Aug 2012 14:31:44 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id kc7sm9920pbb.5.2012.08.10.14.31.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Aug 2012 14:31:43 -0700 (PDT) Received: by pbbrr4 with SMTP id rr4so3315020pbb.31 for ; Fri, 10 Aug 2012 14:31:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.200.138 with SMTP id js10mr911622pbc.23.1344634302645; Fri, 10 Aug 2012 14:31:42 -0700 (PDT) Received: by 10.68.132.103 with HTTP; Fri, 10 Aug 2012 14:31:42 -0700 (PDT) Date: Fri, 10 Aug 2012 17:31:42 -0400 Message-ID: From: Roman Shpount To: sipcore@ietf.org Content-Type: multipart/alternative; boundary=047d7b15a549f6446e04c6f011c9 X-Gm-Message-State: ALoCoQkdQSEUeX/CrNt1b1n34biSr1gND/Fv4Sbvi2HTRHh53mxUgZ0qOvawTUERMn2Ka7JUDGOQ Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 21:31:46 -0000 --047d7b15a549f6446e04c6f011c9 Content-Type: text/plain; charset=ISO-8859-1 My only concern with this draft is the "Appendix B. Topology Hiding" which clearly states that SIP WebSocket Server would be non-compliant with RFC3261 if it implements topology hiding which is actually recommended. I would much rather see that this specification update RFC3261. It should update section 18.2.1 of RFC 3261 stating that the server SHOULD not to add "received" parameter to the via header if request was received via WebSocket protocol and MUST not add the this parameter if via "sent-by" header contains an address with ".invaid" domain. _____________ Roman Shpount --047d7b15a549f6446e04c6f011c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My only concern with this draft is the "Appendix B. Topology Hiding&qu= ot; which clearly states that SIP WebSocket Server would be non-compliant w= ith RFC3261 if it implements topology hiding which is actually recommended.= I would much rather see that this specification update RFC3261. It should = update section 18.2.1 of RFC 3261 stating that the server SHOULD not to add= "received" parameter to the via header if request was received v= ia=A0WebSocket protocol and MUST not add the this parameter if via "se= nt-by" header contains an address with ".invaid" domain. _____________
Roman Shpount

--047d7b15a549f6446e04c6f011c9-- From pkyzivat@alum.mit.edu Fri Aug 10 16:20:52 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0AE11E80AD for ; Fri, 10 Aug 2012 16:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=0.306, 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 ooKbbzF5rN0U for ; Fri, 10 Aug 2012 16:20:51 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 62B5711E80A3 for ; Fri, 10 Aug 2012 16:20:49 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id l0jq1j00U0cZkys53BLsD1; Fri, 10 Aug 2012 23:20:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id lBLo1j00G3ZTu2S3WBLqZq; Fri, 10 Aug 2012 23:20:51 +0000 Message-ID: <5025974B.80300@alum.mit.edu> Date: Fri, 10 Aug 2012 16:20:43 -0700 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Aug 2012 23:20:52 -0000 In addition to this issue, there is the one about the current 3261 requirement to support TCP and UDP transports, which many implementations of this draft will have difficulty complying with. I'd like to hear more people's thoughts on whether to have this draft update 3261 on either or both of these points. Thanks, Paul On 8/10/12 2:31 PM, Roman Shpount wrote: > My only concern with this draft is the "Appendix B. Topology Hiding" > which clearly states that SIP WebSocket Server would be non-compliant > with RFC3261 if it implements topology hiding which is actually > recommended. I would much rather see that this specification update > RFC3261. It should update section 18.2.1 of RFC 3261 stating that the > server SHOULD not to add "received" parameter to the via header if > request was received via WebSocket protocol and MUST not add the this > parameter if via "sent-by" header contains an address with ".invaid" domain. > _____________ > Roman Shpount > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From HKaplan@acmepacket.com Sat Aug 11 10:57:25 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D7921F85ED for ; Sat, 11 Aug 2012 10:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJd+sA6xNu+B for ; Sat, 11 Aug 2012 10:57:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1C51021F85DA for ; Sat, 11 Aug 2012 10:57:24 -0700 (PDT) Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 11 Aug 2012 13:57:22 -0400 Received: from MAIL1.acmepacket.com ([169.254.1.149]) by Mail2.acmepacket.com ([169.254.2.128]) with mapi id 14.02.0283.003; Sat, 11 Aug 2012 13:57:22 -0400 From: Hadriel Kaplan To: Hannes Tschofenig Thread-Topic: [sipcore] Geolocation Header Question Thread-Index: AQHNd+rBX5eEEowhe0i+/6e6ZLko4g== Date: Sat, 11 Aug 2012 17:57:21 +0000 Message-ID: <6C0A8F8E-B79C-4F82-AECC-51FFA79ED6A1@acmepacket.com> References: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.41.24.34] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAC02Se0hTYRjG9+1s6yg7dXReXkdijdLMS14oDBH0L4OS9B+le8d1ckM3ZRdYFiRCSJJpmqTDUnMOW5ol2EKbl2mgghNW5KUwNUmaGWqUSaid7Ryt768fz/O83/ucw4djvmtCmchb4M3jBUTxH4amxzSW3u3AEgYa76OEvvI9yfx03lmhUp2db7gsVJQMOQQFFrGhdimxCP32KkVeuC/5BMG77txS5M1wA4IfW6PIbYjIKHhua8Pc7EfGQv+AU+RmjNSDub7Jk5GQcVD1bJjRcSYTD67yGDYeDbdtTk9EQB6EkdU5oZsJMgWM5jcYu8uKoMU16zG8yET4uFjJdzMiA2BtpJXP7gqEqfl6DwMZAVZXj5DlSOh4bxGwnAhLg384nQTT6zGMZRmUffjOzfrD18+bXCYKqmvM3GwGrLxo5zJH4ZvJyelJMNS2wd2TCrfaGzk9DexNJo5DYGv6E8fJsNRl5fL7YL1vHdu+54uzheOT0NxcxnEcjP8sFlWgcON/n8lyJDR0r4pYToJe46aQ5QgwNy5iRs9/9IHh2nlBAxJakD+tU1HKvGhKrqILKHkurYuW56s6EPMoJsJB9ArN/QqzoyCcL/MnxmpD0313Z+dfuaagtIpLGn0erbUjwMUyPyK2jvEIbQGl0ipztq29OC4D4rrb8tHQObThqjJPR2tYewQFSQOJYiNjku45hV694zmRv1RC6CsZT1xAa1RKHatPIQk+y/cVqPPVtJSpyGPOIeRCgTiSSYgM9yKxUq3bqeBi2vGZdmu4p52O+mdJi1D18i5jydvRmTp5TmGm6E6b88j5UcdKxIpxf9ZMrnliK22q52awtZenqHjUn9lpQpMHjlfOxHcNJsZow6SnK+wLnTWYrSUluH7aJk6z2Jcdi8Mug+3YucdnfDaWLWOqxc4bG1XUA+/Cl6da4ycvrI6HOFMXyBMOgn/vYktm1lOZQKugYg9jGi31F0Mjz BeKAwAA Cc: "Worley, Dale R \(Dale\)" , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Geolocation Header Question X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Aug 2012 17:57:25 -0000 You could do this: Geolocation: (although why ATIS would be defining how calls from Finland work is beyond = me ;) But I don't understand why they need it in a Geoloc header to begin with. = I assumed that header was for devices/networks that use its mechanisms (ie,= HELD, SUB, pidf). They're not going to do that, so why use that header? You said they're doing the location lookup on the PSTN side - presumably th= en the location is being looked up based on the calling party info, which s= hould be in another existing header. Can't they use one of them as the que= ry key for the lookup? (we have plenty to choose from for that already :) -hadriel On Aug 7, 2012, at 11:31 AM, Hannes Tschofenig wrote: > I agree but the tel URI is not one of the supported location URIs in RFC = 6442.=20 > Hence, the guys just use a different way to convey the same information.= =20 >=20 > On Aug 7, 2012, at 5:52 PM, Worley, Dale R (Dale) wrote: >=20 >>> From: Hannes Tschofenig [hannes.tschofenig@gmx.net] >>>=20 >>> In order to convey that phone number for a lookup they are thinking >>> about using the Geolocation header in the following form: >>> Geolocation:>=20 >> Naively, I'd say that since the goal is to carry an E.164 number, a >> tel: URI would be the ideal choice. >>=20 >> Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From br@brianrosen.net Tue Aug 14 10:55:16 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260A221F871D for ; Tue, 14 Aug 2012 10:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HywY3Ul9MjyL for ; Tue, 14 Aug 2012 10:55:15 -0700 (PDT) Received: from barmail4.idig.net (barmail4.idig.net [64.34.111.235]) by ietfa.amsl.com (Postfix) with ESMTP id 8F85521F86FE for ; Tue, 14 Aug 2012 10:55:15 -0700 (PDT) X-ASG-Debug-ID: 1344966914-04d035107354bbb0001-zLx1xO Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail4.idig.net with ESMTP id dDdr2ufUBPKak81t; Tue, 14 Aug 2012 10:55:14 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from localhost ([127.0.0.1]:44480 helo=webmail.brianrosen.net) by wwh1.winweblinux.com with esmtpa (Exim 4.77) (envelope-from ) id 1T1LKk-001dvT-F3; Tue, 14 Aug 2012 10:55:14 -0700 Received: from 209.173.53.233 ([209.173.53.233]) (proxying for 209.173.53.233, 66.151.103.8) (SquirrelMail authenticated user br@brianrosen.net) by webmail.brianrosen.net with HTTP; Tue, 14 Aug 2012 13:55:14 -0400 Message-ID: In-Reply-To: <6C0A8F8E-B79C-4F82-AECC-51FFA79ED6A1@acmepacket.com> References: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> <6C0A8F8E-B79C-4F82-AECC-51FFA79ED6A1@acmepacket.com> Date: Tue, 14 Aug 2012 13:55:14 -0400 From: "Brian Rosen" X-ASG-Orig-Subj: Re: [sipcore] Geolocation Header Question To: "Hadriel Kaplan" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1344966914 X-Barracuda-URL: http://64.34.111.235:8000/cgi-mod/mark.cgi X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.105639 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: "Worley, Dale R \(Dale\)" , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Geolocation Header Question 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, 14 Aug 2012 17:55:16 -0000 I don't think so. A geolocation header with a sip uri has to lead to a presence server that can respond to a presence subscription which would return a PIDF with location. Routing a tel uri (which user=phone is supposed to be interchangeable with) to a presence service usually makes no sense. I don't think you can send a SUBSCRIBE to a tel uri. If you could, user=phone is okay. If you can't, user=phone is not okay. It's perfectly reasonable to make the uri sip:+358222222222@presence.example.com that is, a real domain, and no user=phone Brian > > You could do this: > Geolocation: > (although why ATIS would be defining how calls from Finland work is beyond > me ;) > > But I don't understand why they need it in a Geoloc header to begin with. > I assumed that header was for devices/networks that use its mechanisms > (ie, HELD, SUB, pidf). They're not going to do that, so why use that > header? > > You said they're doing the location lookup on the PSTN side - presumably > then the location is being looked up based on the calling party info, > which should be in another existing header. Can't they use one of them as > the query key for the lookup? (we have plenty to choose from for that > already :) > > -hadriel > > > On Aug 7, 2012, at 11:31 AM, Hannes Tschofenig wrote: > >> I agree but the tel URI is not one of the supported location URIs in RFC >> 6442. >> Hence, the guys just use a different way to convey the same information. >> >> On Aug 7, 2012, at 5:52 PM, Worley, Dale R (Dale) wrote: >> >>>> From: Hannes Tschofenig [hannes.tschofenig@gmx.net] >>>> >>>> In order to convey that phone number for a lookup they are thinking >>>> about using the Geolocation header in the following form: >>>> Geolocation:>> >>> Naively, I'd say that since the goal is to carry an E.164 number, a >>> tel: URI would be the ideal choice. >>> >>> Dale >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@alum.mit.edu Tue Aug 14 12:59:06 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3686621F87A0 for ; Tue, 14 Aug 2012 12:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Wm33ZBvOIMA for ; Tue, 14 Aug 2012 12:59:05 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7863821F878E for ; Tue, 14 Aug 2012 12:59:05 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id mgKm1j0051c6gX853jz8Lb; Tue, 14 Aug 2012 19:59:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id mjyn1j00b3ZTu2S3jjyna3; Tue, 14 Aug 2012 19:58:47 +0000 Message-ID: <502AAE07.3020309@alum.mit.edu> Date: Tue, 14 Aug 2012 15:59:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> <6C0A8F8E-B79C-4F82-AECC-51FFA79ED6A1@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Geolocation Header Question 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, 14 Aug 2012 19:59:06 -0000 I already commented to the original question. Here I'm just commenting on the comments. On 8/14/12 1:55 PM, Brian Rosen wrote: > I don't think so. > > A geolocation header with a sip uri has to lead to a presence server that > can respond to a presence subscription which would return a PIDF with > location. > > Routing a tel uri (which user=phone is supposed to be interchangeable > with) to a presence service usually makes no sense. I don't think you can > send a SUBSCRIBE to a tel uri. If you could, user=phone is okay. If you > can't, user=phone is not okay. I disagree that a tel uri is *equivalent* to a sip URI with user=phone! A sip URI with user=phone is supposed to be routed like any other sip URI until it reaches a server responsible for the domain of the URI. *Then* the user part is to be interpreted as representing a phone number. Conversely, a tel URI has no domain. (And no user=phone.) The semantics of telephone numbers are public knowledge. So any server can decide where to route it next, based on the number and whatever other context it has. IMO the distinction is important. If you want to enable anybody to decide how to reach the phone number (including going through a PSTN GW), then use a tel URI. If you want the call handled via SIP at least until it reaches a particular domain, then use a sip URI. Thanks, Paul > It's perfectly reasonable to make the uri > sip:+358222222222@presence.example.com > that is, a real domain, and no user=phone > > Brian >> >> You could do this: >> Geolocation: >> (although why ATIS would be defining how calls from Finland work is beyond >> me ;) >> >> But I don't understand why they need it in a Geoloc header to begin with. >> I assumed that header was for devices/networks that use its mechanisms >> (ie, HELD, SUB, pidf). They're not going to do that, so why use that >> header? >> >> You said they're doing the location lookup on the PSTN side - presumably >> then the location is being looked up based on the calling party info, >> which should be in another existing header. Can't they use one of them as >> the query key for the lookup? (we have plenty to choose from for that >> already :) >> >> -hadriel >> >> >> On Aug 7, 2012, at 11:31 AM, Hannes Tschofenig wrote: >> >>> I agree but the tel URI is not one of the supported location URIs in RFC >>> 6442. >>> Hence, the guys just use a different way to convey the same information. >>> >>> On Aug 7, 2012, at 5:52 PM, Worley, Dale R (Dale) wrote: >>> >>>>> From: Hannes Tschofenig [hannes.tschofenig@gmx.net] >>>>> >>>>> In order to convey that phone number for a lookup they are thinking >>>>> about using the Geolocation header in the following form: >>>>> Geolocation:>>> >>>> Naively, I'd say that since the goal is to carry an E.164 number, a >>>> tel: URI would be the ideal choice. >>>> >>>> Dale >>> >>> _______________________________________________ >>> 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 br@brianrosen.net Tue Aug 14 14:04:53 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F6121E80B9 for ; Tue, 14 Aug 2012 14:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2WQQ7rxhmBY for ; Tue, 14 Aug 2012 14:04:52 -0700 (PDT) Received: from barmail6.idig.net (barmail6.idig.net [64.34.111.239]) by ietfa.amsl.com (Postfix) with ESMTP id E2BAB21E80B0 for ; Tue, 14 Aug 2012 14:04:51 -0700 (PDT) X-ASG-Debug-ID: 1344978260-0538de0e33653b80001-zLx1xO Received: from wwh1.winweblinux.com (wwh1.winweblinux.com [76.74.186.184]) by barmail6.idig.net with ESMTP id rvxBRj8b2O2scZ3n; Tue, 14 Aug 2012 14:04:20 -0700 (PDT) X-Barracuda-Envelope-From: br@brianrosen.net X-Barracuda-Apparent-Source-IP: 76.74.186.184 Received: from localhost ([127.0.0.1]:33919 helo=webmail.brianrosen.net) by wwh1.winweblinux.com with esmtpa (Exim 4.77) (envelope-from ) id 1T1OHh-001vZc-GC; Tue, 14 Aug 2012 14:04:19 -0700 Received: from 209.173.53.233 ([209.173.53.233]) (proxying for 209.173.53.233, 66.151.103.8) (SquirrelMail authenticated user br@brianrosen.net) by webmail.brianrosen.net with HTTP; Tue, 14 Aug 2012 17:04:17 -0400 Message-ID: <43ef3c20e7f1fb98a6a6d8758fb4a59c.squirrel@webmail.brianrosen.net> In-Reply-To: <502AAE07.3020309@alum.mit.edu> References: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> <6C0A8F8E-B79C-4F82-AECC-51FFA79ED6A1@acmepacket.com> <502AAE07.3020309@alum.mit.edu> Date: Tue, 14 Aug 2012 17:04:17 -0400 From: "Brian Rosen" X-ASG-Orig-Subj: Re: [sipcore] Geolocation Header Question To: "Paul Kyzivat" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Barracuda-Connect: wwh1.winweblinux.com[76.74.186.184] X-Barracuda-Start-Time: 1344978260 X-Barracuda-URL: http://64.34.111.239:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at idig.net X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=3.5 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.105653 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Cc: sipcore@ietf.org Subject: Re: [sipcore] Geolocation Header Question 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, 14 Aug 2012 21:04:53 -0000 Yes, agree, but probably not relevant to the discussion. I went back and looked at the original email, and decided I either don't understand something, or there is some larger problem. Between what two elements is this Geolocation header running? UAS to proxy server (UE to E-CSCF)? Proxy to gateway (E-CSCF to MGCF)? Regardless, it seems to be misusing the header, because it's not a sip or http LbyR. Better to get a real scheme somehow that does the right thing, use a parameter in another header, or create a new header. Depends on what this actually represents. It sounds like it really is LbyR, and you want to communicate a key. :@domain is appropriate. The issue is what is the right scheme? It's not sip - it's not sip presence. It's not HELD identity I take it. Brian > I already commented to the original question. > Here I'm just commenting on the comments. > > On 8/14/12 1:55 PM, Brian Rosen wrote: >> I don't think so. >> >> A geolocation header with a sip uri has to lead to a presence server >> that >> can respond to a presence subscription which would return a PIDF with >> location. >> >> Routing a tel uri (which user=phone is supposed to be interchangeable >> with) to a presence service usually makes no sense. I don't think you >> can >> send a SUBSCRIBE to a tel uri. If you could, user=phone is okay. If >> you >> can't, user=phone is not okay. > > I disagree that a tel uri is *equivalent* to a sip URI with user=phone! > > A sip URI with user=phone is supposed to be routed like any other sip > URI until it reaches a server responsible for the domain of the URI. > *Then* the user part is to be interpreted as representing a phone number. > > Conversely, a tel URI has no domain. (And no user=phone.) The semantics > of telephone numbers are public knowledge. So any server can decide > where to route it next, based on the number and whatever other context > it has. > > IMO the distinction is important. If you want to enable anybody to > decide how to reach the phone number (including going through a PSTN > GW), then use a tel URI. If you want the call handled via SIP at least > until it reaches a particular domain, then use a sip URI. > > Thanks, > Paul > >> It's perfectly reasonable to make the uri >> sip:+358222222222@presence.example.com >> that is, a real domain, and no user=phone >> >> Brian >>> >>> You could do this: >>> Geolocation: >>> (although why ATIS would be defining how calls from Finland work is >>> beyond >>> me ;) >>> >>> But I don't understand why they need it in a Geoloc header to begin >>> with. >>> I assumed that header was for devices/networks that use its mechanisms >>> (ie, HELD, SUB, pidf). They're not going to do that, so why use that >>> header? >>> >>> You said they're doing the location lookup on the PSTN side - >>> presumably >>> then the location is being looked up based on the calling party info, >>> which should be in another existing header. Can't they use one of them >>> as >>> the query key for the lookup? (we have plenty to choose from for that >>> already :) >>> >>> -hadriel >>> >>> >>> On Aug 7, 2012, at 11:31 AM, Hannes Tschofenig wrote: >>> >>>> I agree but the tel URI is not one of the supported location URIs in >>>> RFC >>>> 6442. >>>> Hence, the guys just use a different way to convey the same >>>> information. >>>> >>>> On Aug 7, 2012, at 5:52 PM, Worley, Dale R (Dale) wrote: >>>> >>>>>> From: Hannes Tschofenig [hannes.tschofenig@gmx.net] >>>>>> >>>>>> In order to convey that phone number for a lookup they are thinking >>>>>> about using the Geolocation header in the following form: >>>>>> Geolocation:>>>> >>>>> Naively, I'd say that since the goal is to carry an E.164 number, a >>>>> tel: URI would be the ideal choice. >>>>> >>>>> Dale >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@alum.mit.edu Tue Aug 14 14:11:58 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68A9521E80B3 for ; Tue, 14 Aug 2012 14:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.914 X-Spam-Level: X-Spam-Status: No, score=-0.914 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_45=0.6, 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 SOjNdalbOfp9 for ; Tue, 14 Aug 2012 14:11:57 -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 65A8E21F861E for ; Tue, 14 Aug 2012 14:11:57 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta01.westchester.pa.mail.comcast.net with comcast id mbZk1j0031HzFnQ51lC0HR; Tue, 14 Aug 2012 21:12:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id mlBy1j00R3ZTu2S3alBzFJ; Tue, 14 Aug 2012 21:11:59 +0000 Message-ID: <502ABF1B.9020400@alum.mit.edu> Date: Tue, 14 Aug 2012 17:11:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Brian Rosen References: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> <6C0A8F8E-B79C-4F82-AECC-51FFA79ED6A1@acmepacket.com> <502AAE07.3020309@alum.mit.edu> <43ef3c20e7f1fb98a6a6d8758fb4a59c.squirrel@webmail.brianrosen.net> In-Reply-To: <43ef3c20e7f1fb98a6a6d8758fb4a59c.squirrel@webmail.brianrosen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Geolocation Header Question 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, 14 Aug 2012 21:11:58 -0000 On 8/14/12 5:04 PM, Brian Rosen wrote: > Yes, agree, but probably not relevant to the discussion. > > I went back and looked at the original email, and decided I either don't > understand something, or there is some larger problem. > > Between what two elements is this Geolocation header running? > > UAS to proxy server (UE to E-CSCF)? Proxy to gateway (E-CSCF to MGCF)? > > Regardless, it seems to be misusing the header, because it's not a sip or > http LbyR. > Better to get a real scheme somehow that does the right thing, use a > parameter in another header, or create a new header. Depends on what this > actually represents. It sounds like it really is LbyR, and you want to > communicate a key.:@domain is appropriate. The issue is > what is the right scheme? It's not sip - it's not sip presence. It's not > HELD identity I take it. As I already stated, I think sip: is ok if this special lookup can be viewed as an *optimization* over doing the presence lookup, and doing it the presence way still works. Otherwise I agree with Brian. Thanks, Paul > Brian > >> I already commented to the original question. >> Here I'm just commenting on the comments. >> >> On 8/14/12 1:55 PM, Brian Rosen wrote: >>> I don't think so. >>> >>> A geolocation header with a sip uri has to lead to a presence server >>> that >>> can respond to a presence subscription which would return a PIDF with >>> location. >>> >>> Routing a tel uri (which user=phone is supposed to be interchangeable >>> with) to a presence service usually makes no sense. I don't think you >>> can >>> send a SUBSCRIBE to a tel uri. If you could, user=phone is okay. If >>> you >>> can't, user=phone is not okay. >> >> I disagree that a tel uri is *equivalent* to a sip URI with user=phone! >> >> A sip URI with user=phone is supposed to be routed like any other sip >> URI until it reaches a server responsible for the domain of the URI. >> *Then* the user part is to be interpreted as representing a phone number. >> >> Conversely, a tel URI has no domain. (And no user=phone.) The semantics >> of telephone numbers are public knowledge. So any server can decide >> where to route it next, based on the number and whatever other context >> it has. >> >> IMO the distinction is important. If you want to enable anybody to >> decide how to reach the phone number (including going through a PSTN >> GW), then use a tel URI. If you want the call handled via SIP at least >> until it reaches a particular domain, then use a sip URI. >> >> Thanks, >> Paul >> >>> It's perfectly reasonable to make the uri >>> sip:+358222222222@presence.example.com >>> that is, a real domain, and no user=phone >>> >>> Brian >>>> >>>> You could do this: >>>> Geolocation: >>>> (although why ATIS would be defining how calls from Finland work is >>>> beyond >>>> me ;) >>>> >>>> But I don't understand why they need it in a Geoloc header to begin >>>> with. >>>> I assumed that header was for devices/networks that use its mechanisms >>>> (ie, HELD, SUB, pidf). They're not going to do that, so why use that >>>> header? >>>> >>>> You said they're doing the location lookup on the PSTN side - >>>> presumably >>>> then the location is being looked up based on the calling party info, >>>> which should be in another existing header. Can't they use one of them >>>> as >>>> the query key for the lookup? (we have plenty to choose from for that >>>> already :) >>>> >>>> -hadriel >>>> >>>> >>>> On Aug 7, 2012, at 11:31 AM, Hannes Tschofenig wrote: >>>> >>>>> I agree but the tel URI is not one of the supported location URIs in >>>>> RFC >>>>> 6442. >>>>> Hence, the guys just use a different way to convey the same >>>>> information. >>>>> >>>>> On Aug 7, 2012, at 5:52 PM, Worley, Dale R (Dale) wrote: >>>>> >>>>>>> From: Hannes Tschofenig [hannes.tschofenig@gmx.net] >>>>>>> >>>>>>> In order to convey that phone number for a lookup they are thinking >>>>>>> about using the Geolocation header in the following form: >>>>>>> Geolocation:>>>>> >>>>>> Naively, I'd say that since the goal is to carry an E.164 number, a >>>>>> tel: URI would be the ideal choice. >>>>>> >>>>>> Dale >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > > From rjsparks@nostrum.com Tue Aug 21 14:56:58 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F37021F876C for ; Tue, 21 Aug 2012 14:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPEPsNqtQcpq for ; Tue, 21 Aug 2012 14:56:57 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 001CC21F8768 for ; Tue, 21 Aug 2012 14:56:56 -0700 (PDT) Received: from unnumerable.local (pool-173-57-102-202.dllstx.fios.verizon.net [173.57.102.202]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7LLutau071221 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 21 Aug 2012 16:56:55 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <50340427.40707@nostrum.com> Date: Tue, 21 Aug 2012 16:56:55 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sipcore@ietf.org, draft-ietf-sipcore-proxy-feature@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.57.102.202 is authenticated by a trusted mechanism) Subject: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 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, 21 Aug 2012 21:56:58 -0000 Summary: There are a few issues to address before progressing to IETF LC. I'm putting the document into revised ID needed to address at least the IANA points below. The primary issue is with the instructions to IANA on creating the new trees and the registration template used to put things in those trees. Sections 7.3.2 and 7.3.3 don't currently define the format of an entry in the trees in the new subregistry. This needs to be clearly defined, and the sections need to explicitly indicate that the trees are initially empty. The template in section 8 was adapted from RFC2506, but it needs more tweaks and it needs to match whatever format is defined above. * We don't need a separate list for reviewing these requests. We certainly don't need a list at apps.ietf.org. The normal process for submitting a request for the global tree should be submitting the template by email to iana@iana.org, and for the sip tree, the normal process would be submitting an Internet-Draft to the IESG. * IANA is currently using a different for media feature tag registrations. It's available at . If we really need to follow that registration format, please start from this template. But do we need all this information in the registry? Other major issues: 1) Should the expert reviewer be explicitly required to consider security issues as part of that review? (see section 4.6 of for example). 2) The security considerations section claims that the aspects of the considerations in rfc3840 that apply to end user devices don't apply here since these are not typically used to convey information about end user devices. "Not typically" is weak. Can this sentence be made more specific about what concerns do and don't apply? The concerns in 3840 about influencing application behavior, and in 2506 about providing information that can be used to exploit implementation weakeness at the elements that do provide these tags should be reflected here. 3) Consider clarifying the behavior of SUBSCRIBE NOTIFY dialogs in section 4.3.2. Only one of the 200 OKs to a forked SUBSCRIBE will get back to the UA that sent the subscribe. The information that creates the other dialogs for it must appear in the immediate NOTIFYs. Is there a requirement for the end accepting a subscription to use the same feature capabilities in the 200 OK to the subscription and in the immediate NOTIFY? 4) Similarly, consider clarifying whether UPDATES nested within an INVITE constrained to keep the same feature capability indicators as in the INVITE? Minor Issues: Section 4.3.4: A SIP Stand-Alone Transaction is by definition a non-INVITE transaction. RFC4320 made 18x to non-INVITES a MUST NOT. I suggest s/18x or 2xx/2xx/ in this section. The two places where you talk about overriding registration policy in section 5.2 isn't quite right. We should be specific that we're only talking about SIP header field parameters. In the first case, we're using IETF Consensus (this document) to delegate parameters starting with a 'g.' for _this_ header field to a policy of Expert Review. In the second case, there's no overriding at all - registrations use IETF Consensus there. Here's a stab at something more accurate. Maybe others can come up with something better. I suggest replacing the first instance with "Note that the general policy for registering SIP header field parameters is 'IETF Consensus' as specified in [RFC3968]. This document delegates the registration of parameters to the Feature-Caps header field starting with 'g.' to a policy of 'Expert Review'", and deleting the second instance. The NOTE in section 6.2.1 is not useful unless you know the history of that led to the syntax in 3840 and 3841. I suggest replacing it with 'NOTE: The "*" value is present in order to follow the guidelines for syntac in [RFC4485] and to maintain a consistent format with [RFC3840] and [RFC3841].' Nits: There is a mix of "xxx" "XXX" and "XXXX" to indicate to the RFC Editor that the number assigned to this RFC should appear here. Please choose one format and make the instructions to the RFC Editor for making the substitution clear. Section 4.1: I suggest s/in a non-priority order, and any/as an unordered set. Any/ Why is the second paragraph of 4.1 in the introduction to this section? It's getting pretty deep into specification detail. It would fit better at the end of 4.2.1. Section 4.2.2: The beginning of paragraphs 2 an 4 start "When a UA", but don't mean any UA. They rely on the context of the previous paragraphs to scope it to a UA that is part of a B2BUA. To help avoid confusion I suggest changing both of these this way: s/When a UA/When such a UA/ The NOTE in section 4.3.1 is confusing. What's the distinction between a SIP method and a request type that's important here? What methods does this specification leave the behavior undefined for. I don't think there are any except perhaps CANCEL. Is the note important to keep? Section 4.3.2: s/is no long supported/is no longer supported/ Section 4.3.3: The NOTE says support applies to a Contact. It doesn't really - it applies to messages sent with that Contact as the target perhaps. Section 5.1 has some edititis. Parts of it look like a "structure of this document" description, which should be in the Introduction to the document. It's especially odd that it points to earlier in the document. I suggest either deleting the last 3 1-sentence paragraphs, or moving them to section 1, and making the document roadmap more complete. Section 5.2.2: I suggest s/ensure that the feature capability indicator meets/ensure that the definition of the feature capability indicator meets/ Section 5.3.3: STRONGLY RECOMMENDED isn't 2119. I suspect some 2119 purists will object that this sentence doesn't need 2119 at all. I suggest at least changing STRONGLY to lower-case, and consider changing both words. Section 7.3.2: s/through the Expert Review policies/through the Expert Review policy/ From pkyzivat@alum.mit.edu Tue Aug 21 16:00:59 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43ADD21F8647 for ; Tue, 21 Aug 2012 16:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsPaK+9FVcK3 for ; Tue, 21 Aug 2012 16:00:58 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2003821F8645 for ; Tue, 21 Aug 2012 16:00:57 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta08.westchester.pa.mail.comcast.net with comcast id pYjf1j0031uE5Es58b109S; Tue, 21 Aug 2012 23:01:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta16.westchester.pa.mail.comcast.net with comcast id pb181j00H3ZTu2S3cb18LM; Tue, 21 Aug 2012 23:01:08 +0000 Message-ID: <50341328.9090604@alum.mit.edu> Date: Tue, 21 Aug 2012 19:00:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Robert Sparks References: <50340427.40707@nostrum.com> In-Reply-To: <50340427.40707@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 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, 21 Aug 2012 23:00:59 -0000 Thanks Robert! I'm going to defer to Christer on most of this, but want to comment on a couple of things: On 8/21/12 5:56 PM, Robert Sparks wrote: > Summary: There are a few issues to address before progressing to IETF > LC. I'm putting the document into revised ID needed to address at least > the IANA points below. > > The primary issue is with the instructions to IANA on creating the new > trees and the registration template used to put things in those trees. > > Sections 7.3.2 and 7.3.3 don't currently define the format of an entry > in the trees in the new subregistry. This needs to be clearly defined, > and the sections need to explicitly indicate that the trees are > initially empty. > > The template in section 8 was adapted from RFC2506, but it needs more > tweaks and it needs to match whatever format is defined above. > > * We don't need a separate list for reviewing these requests. We > certainly don't need a list at apps.ietf.org. The normal process for > submitting a request for the global tree should be submitting the > template by email to iana@iana.org, and for the sip tree, the normal > process would be submitting an Internet-Draft to the IESG. > > * IANA is currently using a different for media feature tag > registrations. It's available at > . If we > really need to follow that registration format, please start from this > template. But do we need all this information in the registry? I find this one, and the old one, a bit strange. The template asks for a bunch of information that IANA doesn't capture in its subregistry. Presumably that info could be used by the expert reviewer, but it wouldn't be available to users. In practice it appears that all the things registered have a reference to a document that might contain the same info. (Or it could contain conflicting info.) So I'm thinking we need to do better than has been done for media feature tags. > Other major issues: > > 1) Should the expert reviewer be explicitly required to consider > security issues as part of that review? (see section 4.6 of > > for example). > > 2) The security considerations section claims that the aspects of the > considerations in rfc3840 that apply to end user devices don't apply > here since these are not typically used to convey information about end > user devices. "Not typically" is weak. Can this sentence be made more > specific about what concerns do and don't apply? The concerns in 3840 > about influencing application behavior, and in 2506 about providing > information that can be used to exploit implementation weakeness at the > elements that do provide these tags should be reflected here. > > 3) Consider clarifying the behavior of SUBSCRIBE NOTIFY dialogs in > section 4.3.2. Only one of the 200 OKs to a forked SUBSCRIBE will get > back to the UA that sent the subscribe. The information that creates the > other dialogs for it must appear in the immediate NOTIFYs. Is there a > requirement for the end accepting a subscription to use the same feature > capabilities in the 200 OK to the subscription and in the immediate NOTIFY? > > 4) Similarly, consider clarifying whether UPDATES nested within an > INVITE constrained to keep the same feature capability indicators as in > the INVITE? I presume you mean an UPDATE to a before the final response to the dialog establishing INVITE is received. It seems that UPDATES after the dialog is established aren't permitted to carry the header. > Minor Issues: > > Section 4.3.4: A SIP Stand-Alone Transaction is by definition a > non-INVITE transaction. RFC4320 made 18x to non-INVITES a MUST NOT. I > suggest s/18x or 2xx/2xx/ in this section. > > The two places where you talk about overriding registration policy in > section 5.2 isn't quite right. We should be specific that we're only > talking about SIP header field parameters. In the first case, we're > using IETF Consensus (this document) to delegate parameters starting > with a 'g.' for _this_ header field to a policy of Expert Review. In the > second case, there's no overriding at all - registrations use IETF > Consensus there. Here's a stab at something more accurate. Maybe others > can come up with something better. I suggest replacing the first > instance with "Note that the general policy for registering SIP header > field parameters is 'IETF Consensus' as specified in [RFC3968]. This > document delegates the registration of parameters to the Feature-Caps > header field starting with 'g.' to a policy of 'Expert Review'", and > deleting the second instance. You and I already talked about this, but I realize now that we have to work on the wording more. The issue is that from a sip header field perspective the parameter includes the "+", and its parameters that begin with "+" that we are reserving in the header field parameter registry. But the "+" isn't part of the name of the feature capability indicator. So we are delegating parameters that start with "+g." to the expert review procedure. And while things in the sip tree (things beginning with "+sip.", while still requiring IETF consensus, will still go in the sip tree, not as individuals in the sip header fields parameter registry. But maybe we don't need to "note" this part. > The NOTE in section 6.2.1 is not useful unless you know the history of > that led to the syntax in 3840 and 3841. I suggest replacing it with > 'NOTE: The "*" value is present in order to follow the guidelines for > syntac in [RFC4485] and to maintain a consistent format with [RFC3840] > and [RFC3841].' > > Nits: > > There is a mix of "xxx" "XXX" and "XXXX" to indicate to the RFC Editor > that the number assigned to this RFC should appear here. Please choose > one format and make the instructions to the RFC Editor for making the > substitution clear. I recently discovered that xml2rfc has '&rfc.number;' to get this value, though I haven't tried it yet. Apparently it expands to XXXX for drafts. Thanks, Paul From jmpolk@cisco.com Tue Aug 21 17:05:10 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6D011E80A6 for ; Tue, 21 Aug 2012 17:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.922 X-Spam-Level: X-Spam-Status: No, score=-109.922 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kigE1Ye1Pgr9 for ; Tue, 21 Aug 2012 17:05:08 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA1F11E808D for ; Tue, 21 Aug 2012 17:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=5493; q=dns/txt; s=iport; t=1345593908; x=1346803508; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=XiBf0Hrr4sB3oU5TsiwpAZfQpDAE+s6ebfjHmI19gZE=; b=bqjJ6AyVHND6mGiUvhiLwiaoFS2BThVRmTJNTa9H+GRgx4K2JcCLG575 vaiJoN69c1caVGcp2VDjSYhvUOinz/rW5ECpQi5m5iq9YlEEYN0rj35HS zmH0MFhx5DY5CX3aM+0szutMU06DpRtOUOUGJ1jDvzNxjrbByzyU2q+kj Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ4gNFCrRDoG/2dsb2JhbAA8CQ66UIEHgiABAQEDAQEBAQ8BJQItBwsFCwcEDgcDDAEREBkOMAYBEiKHXAMGBQyZH6AjBIolYxGGK2ADiE+bMIFmgidYgUM X-IronPort-AV: E=Sophos;i="4.77,806,1336348800"; d="scan'208";a="53138830" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 22 Aug 2012 00:05:07 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7M057iE008732; Wed, 22 Aug 2012 00:05:07 GMT Message-Id: <201208220005.q7M057iE008732@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 21 Aug 2012 19:05:05 -0500 To: Paul Kyzivat , Brian Rosen From: James Polk In-Reply-To: <502ABF1B.9020400@alum.mit.edu> References: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> <6C0A8F8E-B79C-4F82-AECC-51FFA79ED6A1@acmepacket.com> <502AAE07.3020309@alum.mit.edu> <43ef3c20e7f1fb98a6a6d8758fb4a59c.squirrel@webmail.brianrosen.net> <502ABF1B.9020400@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: sipcore@ietf.org Subject: Re: [sipcore] Geolocation Header Question 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, 22 Aug 2012 00:05:10 -0000 At 04:11 PM 8/14/2012, Paul Kyzivat wrote: >On 8/14/12 5:04 PM, Brian Rosen wrote: >>Yes, agree, but probably not relevant to the discussion. >> >>I went back and looked at the original email, and decided I either don't >>understand something, or there is some larger problem. >> >>Between what two elements is this Geolocation header running? >> >>UAS to proxy server (UE to E-CSCF)? Proxy to gateway (E-CSCF to MGCF)? >> >>Regardless, it seems to be misusing the header, because it's not a sip or >>http LbyR. >>Better to get a real scheme somehow that does the right thing, use a >>parameter in another header, or create a new header. Depends on what this >>actually represents. It sounds like it really is LbyR, and you want to >>communicate a key.:@domain is appropriate. The issue is >>what is the right scheme? It's not sip - it's not sip presence. It's not >>HELD identity I take it. > >As I already stated, I think sip: is ok if this special lookup can >be viewed as an *optimization* over doing the presence lookup, and >doing it the presence way still works. > >Otherwise I agree with Brian. isn't an allowed URI in RFC 6442, neither is the use=phone tag, so IMO that makes this offering a no go as far as 'being in line with an IETF standards track RFC' (to be formal about it). James > Thanks, > Paul > >>Brian >> >>>I already commented to the original question. >>>Here I'm just commenting on the comments. >>> >>>On 8/14/12 1:55 PM, Brian Rosen wrote: >>>>I don't think so. >>>> >>>>A geolocation header with a sip uri has to lead to a presence server >>>>that >>>>can respond to a presence subscription which would return a PIDF with >>>>location. >>>> >>>>Routing a tel uri (which user=phone is supposed to be interchangeable >>>>with) to a presence service usually makes no sense. I don't think you >>>>can >>>>send a SUBSCRIBE to a tel uri. If you could, user=phone is okay. If >>>>you >>>>can't, user=phone is not okay. >>> >>>I disagree that a tel uri is *equivalent* to a sip URI with user=phone! >>> >>>A sip URI with user=phone is supposed to be routed like any other sip >>>URI until it reaches a server responsible for the domain of the URI. >>>*Then* the user part is to be interpreted as representing a phone number. >>> >>>Conversely, a tel URI has no domain. (And no user=phone.) The semantics >>>of telephone numbers are public knowledge. So any server can decide >>>where to route it next, based on the number and whatever other context >>>it has. >>> >>>IMO the distinction is important. If you want to enable anybody to >>>decide how to reach the phone number (including going through a PSTN >>>GW), then use a tel URI. If you want the call handled via SIP at least >>>until it reaches a particular domain, then use a sip URI. >>> >>> Thanks, >>> Paul >>> >>>>It's perfectly reasonable to make the uri >>>>sip:+358222222222@presence.example.com >>>>that is, a real domain, and no user=phone >>>> >>>>Brian >>>>> >>>>>You could do this: >>>>>Geolocation: >>>>>(although why ATIS would be defining how calls from Finland work is >>>>>beyond >>>>>me ;) >>>>> >>>>>But I don't understand why they need it in a Geoloc header to begin >>>>>with. >>>>>I assumed that header was for devices/networks that use its mechanisms >>>>>(ie, HELD, SUB, pidf). They're not going to do that, so why use that >>>>>header? >>>>> >>>>>You said they're doing the location lookup on the PSTN side - >>>>>presumably >>>>>then the location is being looked up based on the calling party info, >>>>>which should be in another existing header. Can't they use one of them >>>>>as >>>>>the query key for the lookup? (we have plenty to choose from for that >>>>>already :) >>>>> >>>>>-hadriel >>>>> >>>>> >>>>>On Aug 7, 2012, at 11:31 AM, Hannes Tschofenig wrote: >>>>> >>>>>>I agree but the tel URI is not one of the supported location URIs in >>>>>>RFC >>>>>>6442. >>>>>>Hence, the guys just use a different way to convey the same >>>>>>information. >>>>>> >>>>>>On Aug 7, 2012, at 5:52 PM, Worley, Dale R (Dale) wrote: >>>>>> >>>>>>>>From: Hannes Tschofenig [hannes.tschofenig@gmx.net] >>>>>>>> >>>>>>>>In order to convey that phone number for a lookup they are thinking >>>>>>>>about using the Geolocation header in the following form: >>>>>>>>Geolocation:>>>>>> >>>>>>>Naively, I'd say that since the goal is to carry an E.164 number, a >>>>>>>tel: URI would be the ideal choice. >>>>>>> >>>>>>>Dale >>>>>> >>>>>>_______________________________________________ >>>>>>sipcore mailing list >>>>>>sipcore@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>>>_______________________________________________ >>>>>sipcore mailing list >>>>>sipcore@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>>>_______________________________________________ >>>>sipcore mailing list >>>>sipcore@ietf.org >>>>https://www.ietf.org/mailman/listinfo/sipcore >>> >>>_______________________________________________ >>>sipcore mailing list >>>sipcore@ietf.org >>>https://www.ietf.org/mailman/listinfo/sipcore >> >> > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Tue Aug 21 21:31:49 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3D811E80AD for ; Tue, 21 Aug 2012 21:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[AWL=-0.312, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2xs6PDsXObG for ; Tue, 21 Aug 2012 21:31:45 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 374C721F851E for ; Tue, 21 Aug 2012 21:31:45 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta13.westchester.pa.mail.comcast.net with comcast id pgTr1j00516LCl05DgXmtF; Wed, 22 Aug 2012 04:31:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id pgXV1j0043ZTu2S3SgXVHH; Wed, 22 Aug 2012 04:31:29 +0000 Message-ID: <503460AE.70507@alum.mit.edu> Date: Wed, 22 Aug 2012 00:31:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: James Polk References: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> <6C0A8F8E-B79C-4F82-AECC-51FFA79ED6A1@acmepacket.com> <502AAE07.3020309@alum.mit.edu> <43ef3c20e7f1fb98a6a6d8758fb4a59c.squirrel@webmail.brianrosen.net> <502ABF1B.9020400@alum.mit.edu> <201208220005.q7M057iE008732@mtv-core-1.cisco.com> In-Reply-To: <201208220005.q7M057iE008732@mtv-core-1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Geolocation Header Question 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, 22 Aug 2012 04:31:49 -0000 On 8/21/12 8:05 PM, James Polk wrote: > At 04:11 PM 8/14/2012, Paul Kyzivat wrote: >> On 8/14/12 5:04 PM, Brian Rosen wrote: >>> Yes, agree, but probably not relevant to the discussion. >>> >>> I went back and looked at the original email, and decided I either don't >>> understand something, or there is some larger problem. >>> >>> Between what two elements is this Geolocation header running? >>> >>> UAS to proxy server (UE to E-CSCF)? Proxy to gateway (E-CSCF to MGCF)? >>> >>> Regardless, it seems to be misusing the header, because it's not a >>> sip or >>> http LbyR. >>> Better to get a real scheme somehow that does the right thing, use a >>> parameter in another header, or create a new header. Depends on what >>> this >>> actually represents. It sounds like it really is LbyR, and you want to >>> communicate a key.:@domain is appropriate. The issue is >>> what is the right scheme? It's not sip - it's not sip presence. >>> It's not >>> HELD identity I take it. >> >> As I already stated, I think sip: is ok if this special lookup can be >> viewed as an *optimization* over doing the presence lookup, and doing >> it the presence way still works. >> >> Otherwise I agree with Brian. > > isn't an allowed URI in RFC 6442, neither is the use=phone tag, > so IMO that makes this offering a no go as far as 'being in line with an > IETF standards track RFC' (to be formal about it). how does it forbid user=phone? (It's a sip uri parameter, not a header parameter.) > James > > >> Thanks, >> Paul >> >>> Brian >>> >>>> I already commented to the original question. >>>> Here I'm just commenting on the comments. >>>> >>>> On 8/14/12 1:55 PM, Brian Rosen wrote: >>>>> I don't think so. >>>>> >>>>> A geolocation header with a sip uri has to lead to a presence server >>>>> that >>>>> can respond to a presence subscription which would return a PIDF with >>>>> location. >>>>> >>>>> Routing a tel uri (which user=phone is supposed to be interchangeable >>>>> with) to a presence service usually makes no sense. I don't think you >>>>> can >>>>> send a SUBSCRIBE to a tel uri. If you could, user=phone is okay. If >>>>> you >>>>> can't, user=phone is not okay. >>>> >>>> I disagree that a tel uri is *equivalent* to a sip URI with user=phone! >>>> >>>> A sip URI with user=phone is supposed to be routed like any other sip >>>> URI until it reaches a server responsible for the domain of the URI. >>>> *Then* the user part is to be interpreted as representing a phone >>>> number. >>>> >>>> Conversely, a tel URI has no domain. (And no user=phone.) The semantics >>>> of telephone numbers are public knowledge. So any server can decide >>>> where to route it next, based on the number and whatever other context >>>> it has. >>>> >>>> IMO the distinction is important. If you want to enable anybody to >>>> decide how to reach the phone number (including going through a PSTN >>>> GW), then use a tel URI. If you want the call handled via SIP at least >>>> until it reaches a particular domain, then use a sip URI. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> It's perfectly reasonable to make the uri >>>>> sip:+358222222222@presence.example.com >>>>> that is, a real domain, and no user=phone >>>>> >>>>> Brian >>>>>> >>>>>> You could do this: >>>>>> Geolocation: >>>>>> (although why ATIS would be defining how calls from Finland work is >>>>>> beyond >>>>>> me ;) >>>>>> >>>>>> But I don't understand why they need it in a Geoloc header to begin >>>>>> with. >>>>>> I assumed that header was for devices/networks that use its >>>>>> mechanisms >>>>>> (ie, HELD, SUB, pidf). They're not going to do that, so why use that >>>>>> header? >>>>>> >>>>>> You said they're doing the location lookup on the PSTN side - >>>>>> presumably >>>>>> then the location is being looked up based on the calling party info, >>>>>> which should be in another existing header. Can't they use one of >>>>>> them >>>>>> as >>>>>> the query key for the lookup? (we have plenty to choose from for that >>>>>> already :) >>>>>> >>>>>> -hadriel >>>>>> >>>>>> >>>>>> On Aug 7, 2012, at 11:31 AM, Hannes Tschofenig wrote: >>>>>> >>>>>>> I agree but the tel URI is not one of the supported location URIs in >>>>>>> RFC >>>>>>> 6442. >>>>>>> Hence, the guys just use a different way to convey the same >>>>>>> information. >>>>>>> >>>>>>> On Aug 7, 2012, at 5:52 PM, Worley, Dale R (Dale) wrote: >>>>>>> >>>>>>>>> From: Hannes Tschofenig [hannes.tschofenig@gmx.net] >>>>>>>>> >>>>>>>>> In order to convey that phone number for a lookup they are >>>>>>>>> thinking >>>>>>>>> about using the Geolocation header in the following form: >>>>>>>>> Geolocation:>>>>>>> >>>>>>>> Naively, I'd say that since the goal is to carry an E.164 number, a >>>>>>>> tel: URI would be the ideal choice. >>>>>>>> >>>>>>>> Dale >>>>>>> >>>>>>> _______________________________________________ >>>>>>> sipcore mailing list >>>>>>> sipcore@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>>> >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > From hannes.tschofenig@nsn.com Wed Aug 22 00:14:39 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8A711E80E1 for ; Wed, 22 Aug 2012 00:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.898 X-Spam-Level: X-Spam-Status: No, score=-105.898 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWBQrB+eWc8d for ; Wed, 22 Aug 2012 00:14:39 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0E411E80DE for ; Wed, 22 Aug 2012 00:14:37 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q7M7ERaa024393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Aug 2012 09:14:27 +0200 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q7M7EKH1011689; Wed, 22 Aug 2012 09:14:24 +0200 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Aug 2012 09:14:24 +0200 Received: from 10.144.254.41 ([10.144.254.41]) by FIESEXC035.nsn-intra.net ([10.159.0.182]) via Exchange Front-End Server webmail.nsn-intra.net ([10.150.128.36]) with Microsoft Exchange Server HTTP-DAV ; Wed, 22 Aug 2012 07:14:23 +0000 User-Agent: Microsoft-Entourage/12.33.0.120411 Date: Wed, 22 Aug 2012 10:14:22 +0300 From: Hannes Tschofenig To: ext Paul Kyzivat , James Polk Message-ID: Thread-Topic: [sipcore] Geolocation Header Question Thread-Index: Ac2ANcDOauC4/Fd75k6V8knPcGvmvQ== In-Reply-To: <503460AE.70507@alum.mit.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Aug 2012 07:14:24.0487 (UTC) FILETIME=[C24A1770:01CD8035] 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: 551 X-purgate-ID: 151667::1345619667-00006F5F-BE14B0C1/0-0/0-0 Cc: sipcore@ietf.org Subject: Re: [sipcore] Geolocation Header Question 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, 22 Aug 2012 07:14:39 -0000 On 8/22/12 7:31 AM, "ext Paul Kyzivat" wrote: >> isn't an allowed URI in RFC 6442, neither is the use=phone tag, >> so IMO that makes this offering a no go as far as 'being in line with an >> IETF standards track RFC' (to be formal about it). > > how does it forbid user=phone? (It's a sip uri parameter, not a header > parameter.) Reading through the SIP location conveyance document I couldn't find a place that said sip:+1222222222@foo-bar.com;user=phone isn't allowed. So, I agree with Paul. From jon.peterson@neustar.biz Wed Aug 22 00:18:31 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA3211E80EC for ; Wed, 22 Aug 2012 00:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.099 X-Spam-Level: X-Spam-Status: No, score=-106.099 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWknPIaqTI5p for ; Wed, 22 Aug 2012 00:18:27 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5FF11E80D7 for ; Wed, 22 Aug 2012 00:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1345620180; x=1660974502; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=HbR9DbdrQavE7QCjUma/s LqDK8I7Uf9cYWTDYuj0KwU=; b=E7siE9p/IVszKtmdaCMbrWHCmosRYF+3ym3mE SYXfVngKVGnQ81YA23PiA/t22idrFENVTUparhp1/h0ANWKGg== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.13371411; Wed, 22 Aug 2012 03:22:59 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 22 Aug 2012 03:18:21 -0400 From: "Peterson, Jon" To: James Polk , Paul Kyzivat , Brian Rosen Date: Wed, 22 Aug 2012 03:15:50 -0400 Thread-Topic: [sipcore] Geolocation Header Question Thread-Index: Ac1/+c96ThkajAHiSFKTXx9dlmG79AAPCYYo Message-ID: <55A5A9A87506CB4BA580BF9D531957DA69232F38@STNTEXCH01.cis.neustar.com> References: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> <6C0A8F8E-B79C-4F82-AECC-51FFA79ED6A1@acmepacket.com> <502AAE07.3020309@alum.mit.edu> <43ef3c20e7f1fb98a6a6d8758fb4a59c.squirrel@webmail.brianrosen.net> <502ABF1B.9020400@alum.mit.edu>, <201208220005.q7M057iE008732@mtv-core-1.cisco.com> In-Reply-To: <201208220005.q7M057iE008732@mtv-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Tr9oSlHld6EGK9Jv1epwYg== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Geolocation Header Question 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, 22 Aug 2012 07:18:31 -0000 Um... why isn't sip:@domain valid? I see sip-uri as valid in the BNF, = and that implies tel in the user portion. Jon Peterson NeuStar, Inc. ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Jame= s Polk [jmpolk@cisco.com] Sent: Tuesday, August 21, 2012 5:05 PM To: Paul Kyzivat; Brian Rosen Cc: sipcore@ietf.org Subject: Re: [sipcore] Geolocation Header Question At 04:11 PM 8/14/2012, Paul Kyzivat wrote: >On 8/14/12 5:04 PM, Brian Rosen wrote: >>Yes, agree, but probably not relevant to the discussion. >> >>I went back and looked at the original email, and decided I either don't >>understand something, or there is some larger problem. >> >>Between what two elements is this Geolocation header running? >> >>UAS to proxy server (UE to E-CSCF)? Proxy to gateway (E-CSCF to MGCF)? >> >>Regardless, it seems to be misusing the header, because it's not a sip or >>http LbyR. >>Better to get a real scheme somehow that does the right thing, use a >>parameter in another header, or create a new header. Depends on what thi= s >>actually represents. It sounds like it really is LbyR, and you want to >>communicate a key.:@domain is appropriate. The issue is >>what is the right scheme? It's not sip - it's not sip presence. It's no= t >>HELD identity I take it. > >As I already stated, I think sip: is ok if this special lookup can >be viewed as an *optimization* over doing the presence lookup, and >doing it the presence way still works. > >Otherwise I agree with Brian. isn't an allowed URI in RFC 6442, neither is the use=3Dphone tag, so IMO that makes this offering a no go as far as 'being in line with an IETF standards track RFC' (to be formal about it). James > Thanks, > Paul > >>Brian >> >>>I already commented to the original question. >>>Here I'm just commenting on the comments. >>> >>>On 8/14/12 1:55 PM, Brian Rosen wrote: >>>>I don't think so. >>>> >>>>A geolocation header with a sip uri has to lead to a presence server >>>>that >>>>can respond to a presence subscription which would return a PIDF with >>>>location. >>>> >>>>Routing a tel uri (which user=3Dphone is supposed to be interchangeable >>>>with) to a presence service usually makes no sense. I don't think you >>>>can >>>>send a SUBSCRIBE to a tel uri. If you could, user=3Dphone is okay. If >>>>you >>>>can't, user=3Dphone is not okay. >>> >>>I disagree that a tel uri is *equivalent* to a sip URI with user=3Dphone= ! >>> >>>A sip URI with user=3Dphone is supposed to be routed like any other sip >>>URI until it reaches a server responsible for the domain of the URI. >>>*Then* the user part is to be interpreted as representing a phone number= . >>> >>>Conversely, a tel URI has no domain. (And no user=3Dphone.) The semantic= s >>>of telephone numbers are public knowledge. So any server can decide >>>where to route it next, based on the number and whatever other context >>>it has. >>> >>>IMO the distinction is important. If you want to enable anybody to >>>decide how to reach the phone number (including going through a PSTN >>>GW), then use a tel URI. If you want the call handled via SIP at least >>>until it reaches a particular domain, then use a sip URI. >>> >>> Thanks, >>> Paul >>> >>>>It's perfectly reasonable to make the uri >>>>sip:+358222222222@presence.example.com >>>>that is, a real domain, and no user=3Dphone >>>> >>>>Brian >>>>> >>>>>You could do this: >>>>>Geolocation: >>>>>(although why ATIS would be defining how calls from Finland work is >>>>>beyond >>>>>me ;) >>>>> >>>>>But I don't understand why they need it in a Geoloc header to begin >>>>>with. >>>>>I assumed that header was for devices/networks that use its mechanisms >>>>>(ie, HELD, SUB, pidf). They're not going to do that, so why use that >>>>>header? >>>>> >>>>>You said they're doing the location lookup on the PSTN side - >>>>>presumably >>>>>then the location is being looked up based on the calling party info, >>>>>which should be in another existing header. Can't they use one of the= m >>>>>as >>>>>the query key for the lookup? (we have plenty to choose from for that >>>>>already :) >>>>> >>>>>-hadriel >>>>> >>>>> >>>>>On Aug 7, 2012, at 11:31 AM, Hannes Tschofenig wrote: >>>>> >>>>>>I agree but the tel URI is not one of the supported location URIs in >>>>>>RFC >>>>>>6442. >>>>>>Hence, the guys just use a different way to convey the same >>>>>>information. >>>>>> >>>>>>On Aug 7, 2012, at 5:52 PM, Worley, Dale R (Dale) wrote: >>>>>> >>>>>>>>From: Hannes Tschofenig [hannes.tschofenig@gmx.net] >>>>>>>> >>>>>>>>In order to convey that phone number for a lookup they are thinking >>>>>>>>about using the Geolocation header in the following form: >>>>>>>>Geolocation:>>>>>> >>>>>>>Naively, I'd say that since the goal is to carry an E.164 number, a >>>>>>>tel: URI would be the ideal choice. >>>>>>> >>>>>>>Dale >>>>>> >>>>>>_______________________________________________ >>>>>>sipcore mailing list >>>>>>sipcore@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>>>_______________________________________________ >>>>>sipcore mailing list >>>>>sipcore@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>>>_______________________________________________ >>>>sipcore mailing list >>>>sipcore@ietf.org >>>>https://www.ietf.org/mailman/listinfo/sipcore >>> >>>_______________________________________________ >>>sipcore mailing list >>>sipcore@ietf.org >>>https://www.ietf.org/mailman/listinfo/sipcore >> >> > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Aug 22 02:19:01 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3295621F862B for ; Wed, 22 Aug 2012 02:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 348mgxL9r8xH for ; Wed, 22 Aug 2012 02:19:00 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C71E921F8623 for ; Wed, 22 Aug 2012 02:18:59 -0700 (PDT) X-AuditID: c1b4fb30-b7fd46d000003161-24-5034a4020999 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 0A.A4.12641.204A4305; Wed, 22 Aug 2012 11:18:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Wed, 22 Aug 2012 11:18:56 +0200 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" , "draft-ietf-sipcore-proxy-feature@tools.ietf.org" Date: Wed, 22 Aug 2012 11:18:54 +0200 Thread-Topic: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - minor issues and nits Thread-Index: Ac2ARFBMc+F/dBRLRnaXfTmyrEAXuQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FBF196@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+JvrS7TEpMAg4MvFS3e9s9ntLg2p5HN 4uuPTWwOzB5Llvxk8pi18wmLx5fLn9kCmKO4bFJSczLLUov07RK4MrYc/8FU8Fy7YvmN80wN jP+Uuhg5OSQETCQ6mvewQNhiEhfurWfrYuTiEBI4xSixb/USVpCEkMACRokz+y26GDk42AQs JLr/aYPUiAjsYJT4fWgeC0icRUBV4szsUpByYYFiiYevzjOB2CICJRI3G46xQNh6Euu/HWIG sXkFwiUmffoJFmcE2vv91BqwemYBcYlbT+YzQdwjILFkz3lmCFtU4uXjf6wQ9aISd9rXM0LU 60gs2P2JDcLWlli28DXUfEGJkzOfsExgFJ6FZOwsJC2zkLTMQtKygJFlFaNwbmJmTnq5uV5q UWZycXF+nl5x6iZGYBQc3PLbYAfjpvtihxilOViUxHn1VPf7CwmkJ5akZqemFqQWxReV5qQW H2Jk4uCUamB0WzSv32/9pLS2T0Jrs39VTVd8JfBdsNvI3djmoFe32tqUo3Gcf7LFt64/Pt/q 6MTXJSZxbFmypg4vK4oaWouCrWrubgtTWNsXJfJSad2WbO072W71ncseTfqt3f7t4wpTgylH lC7l3Dn4KmQbu8OzvWtj+kv2uMtZvt7yT47tn/G96vqu5VuUWIozEg21mIuKEwGtZOCQUAIA AA== Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - minor issues and nits 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, 22 Aug 2012 09:19:01 -0000 Hi Robert, (I will address the major issue in a separate reply) Minor Issues: ------------------------------------------------ > Section 4.3.4: A SIP Stand-Alone Transaction is by definition a non-INVIT= E transaction. RFC4320 made 18x to non-INVITES a MUST NOT. I suggest s/18x = or 2xx/2xx/ in this section. Ok. I will change as suggested. ------------------------ > The two places where you talk about overriding registration policy in sec= tion 5.2 isn't quite right. We should be specific that=20 > we're only talking about SIP header field parameters. In the first case, = we're using IETF Consensus (this document) to delegate=20 > parameters starting with a 'g.' for _this_ header field to a policy of Ex= pert Review. In the second case, there's no overriding at=20 > all - registrations use IETF Consensus there. Here's a stab at something= more accurate. Maybe others can come up with=20 > something better. I suggest replacing the first instance with "Note that = the general policy for registering SIP header field=20 > parameters is 'IETF Consensus' as specified in [RFC3968]. This document d= elegates the registration of parameters to the > Feature-Caps header field starting with 'g.' to a policy of 'Expert Revie= w'", and deleting the second instance. > The NOTE in section 6.2.1 is not useful unless you know the history of th= at led to the syntax in 3840 and 3841. I suggest replacing it with > 'NOTE: The "*" value is present in order to follow the guidelines for syn= tac in [RFC4485] and to maintain a consistent format with [RFC3840] and [RF= C3841].' Ok. I will change as suggested. Nits: ------------------------------------------------ > There is a mix of "xxx" "XXX" and "XXXX" to indicate to the RFC Editor th= at the number assigned to this RFC should appear here. Please choose one fo= rmat and make the instructions to the RFC Editor for making the substitutio= n clear. Ok. I'll fix that. ------------------------ > Section 4.1: I suggest s/in a non-priority order, and any/as an unordered= set. Any/ Ok. I will change as suggested. ------------------------ > Why is the second paragraph of 4.1 in the introduction to this section?=20 > It's getting pretty deep into specification detail. It would fit better a= t the end of 4.2.1. Ok. I will move it there. ------------------------ > Section 4.2.2: The beginning of paragraphs 2 an 4 start "When a UA", but = don't mean any UA. They=20 > rely on the context of the previous paragraphs to scope it to a UA that i= s part of a B2BUA. To help > avoid confusion I suggest changing both of these this way: s/When a UA/Wh= en such a UA/ Ok. I will change as suggested. ------------------------ > The NOTE in section 4.3.1 is confusing. What's the distinction between a = SIP method and a request type=20 > that's important here? What methods does this specification leave the beh= avior undefined for. I don't think > there are any except perhaps CANCEL. Is the note important to keep? The content of the note is quite obvious, so I can remove it. ------------------------ > Section 4.3.2: s/is no long supported/is no longer supported/ Ok. I will change as suggested. ------------------------ >Section 4.3.3: The NOTE says support applies to a Contact. It doesn't real= ly - it applies to messages sent with that Contact as the target perhaps. I suggest the new modified note text: "NOTE: While a REGISTER response can contain contacts that have been registered as part of other registration transactions, support of any indicated feature only applies to requests sent to the contact(s) that= =20 were explicitly conveyed in the associated REGISTER request." ------------------------ > Section 5.1 has some edititis. Parts of it look like a "structure of this= document" description, which should be in the=20 > Introduction to the document. It's especially odd that it points to earli= er in the document.=20 > I suggest either deleting the last 3 1-sentence paragraphs, or moving the= m to section 1, and making the document=20 > roadmap more complete. I suggest to remove them. Adding them to section 1 (where I do agree that t= hey belong if we would keep them) makes little sense, as the table of conte= nts comes just before section 1. So, section 5.1 would look like: "5.1. Introduction Feature capability indicators are used by SIP entities not represented by the URI of the Contact header field to indicate support of features and capabilities, where media feature tags cannot be used to indicate the support. A value, or a list of values, that provides additional information about the supported feature or capability, can be associated with a feature capability indicator." ------------------------ > Section 5.2.2: I suggest s/ensure that the feature capability indicator m= eets/ensure that the definition of the feature capability indicator meets/ Ok. I will change as suggested. ------------------------ > Section 5.3.3: STRONGLY RECOMMENDED isn't 2119. I suspect some 2119 puris= ts will object that this sentence doesn't need 2119 at all. I suggest at le= ast changing STRONGLY to lower-case, and consider changing both words. Ok. I will change as suggested. ------------------------ >Section 7.3.2: s/through the Expert Review policies/through the Expert Rev= iew policy/ Ok. I will change as suggested. ------------------------ Thanks! Regards, Christer From christer.holmberg@ericsson.com Wed Aug 22 05:09:47 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A3C21F8489 for ; Wed, 22 Aug 2012 05:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fvjg6wDOIXxz for ; Wed, 22 Aug 2012 05:09:42 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id BCE0E21F8694 for ; Wed, 22 Aug 2012 05:09:39 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-66-5034cc021f11 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 3E.AC.25676.20CC4305; Wed, 22 Aug 2012 14:09:38 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 22 Aug 2012 14:09:37 +0200 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" , "draft-ietf-sipcore-proxy-feature@tools.ietf.org" Date: Wed, 22 Aug 2012 14:09:36 +0200 Thread-Topic: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues Thread-Index: Ac2AXv93lTJjLkhVTEyk90Fi7o7g2w== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FBF33A@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUyM+JvrS7TGZMAg8MPFS3e9s9ntLg2p5HN 4uuPTWwOzB5Llvxk8pi18wmLx5fLn9kCmKO4bFJSczLLUov07RK4MloWrWEsmJla8evLY7YG xvbALkZODgkBE4m+C0sZIWwxiQv31rN1MXJxCAmcYpQ4dv0DlLOAUeLX4xXMXYwcHGwCFhLd /7RB4iICOxglfh+axwLSzSKgKvGgYy47iC0sUCXR1PSJDcQWEaiW+P71GzOErSfxat99sBpe gXCJ36/XsoLYjECbv59awwRiMwuIS9x6Mp8J4iIBiSV7zjND2KISLx//g6oXlbjTvp4Rol5H YsFuiF3MAtoSyxa+ZoaYLyhxcuYTlgmMwrOQjJ2FpGUWkpZZSFoWMLKsYhTOTczMSS830kst ykwuLs7P0ytO3cQIjISDW36r7mC8c07kEKM0B4uSOK/11j3+QgLpiSWp2ampBalF8UWlOanF hxiZODilGhgtrL8HXg09v5GFd9p3fvZjT044iCayzO/hOSG1x09VSXel9bbzGU+der6evSYS HTIpQ8894tYcxd7PEr46p39/0ixdXrW/4JrpFNnGkBNJPY/dJ+w8rP1poqjZ18t8Ks8rP3ba ahzI2ZixbkWmutzxBSb753HnrVp7h8Mh98ee/2yKhZMaRKyVWIozEg21mIuKEwHOOiOjUgIA AA== Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues 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, 22 Aug 2012 12:09:47 -0000 Hi Robert, This reply addresses your comment regarding the IANA registration template/= procedure, and the major issues. > Summary: There are a few issues to address before progressing to IETF LC.= I'm putting the document into revised ID needed to address at least the IA= NA points below. > > The primary issue is with the instructions to IANA on creating the new tr= ees and the registration template used to put things in those trees. > > Sections 7.3.2 and 7.3.3 don't currently define the format of an entry in= the trees in the new subregistry. This needs to be clearly defined, and th= e sections need to explicitly indicate that the trees are initially empty. I suggest to add the following text to the end of sections 7.3.2 and 7.3.3: "The format of the [global/SIP] tree is as described below: Decimal Name Description Reference --------------------------------------------------- Decimal contains an integer value, incremented by IANA every time a new fe= ature capability indicator is added to the table.=20 Name contains the Feature Capability Indicator Name, provided in the regis= tration feature capability indication registration template. Description contains the Abstract, provided in the registration feature ca= pability indication registration template. Reference contains the Feature Capability Indicator Specification Referenc= e, provided in the registration feature capability indication registration = template." ---------------- > The template in section 8 was adapted from RFC2506, but it needs more twe= aks and it needs to match whatever format is defined above. > > * We don't need a separate list for reviewing these requests. We certai= nly don't need a list at apps.ietf.org. The normal process for submitting a= request for the global tree should be submitting the template by email to = iana@iana.org, and for the sip=20 > tree, the normal process would be submitting an Internet-Draft to the IES= G. I suggest the following change: OLD: "To: sip-feature-capability-indicators@apps.ietf.org (feature capability indicators mailing list) Subject: Registration of feature capability indicator XXXX" NEW: "Registration requests for the global tree are submitted by e-mail to ian= a@iana.org. Registration requests for the sip tree requires submitting an Internet-Dra= ft to the IESG." ---------------- > * IANA is currently using a different for media feature tag registratio= ns. It's available at . If we really need to follow that registration format, please sta= rt from this template. But do we=20 > need all this information in the registry? I did start from the media feature tag template, and then removed stuff :) However, I do agree that not all of the remaining stuff needs to be in the = template. Unlike media feature tags, we do mandate a reference to a specifi= cation for feature capability indicators, so whatever information that IANA= doesn't need can be put in that specification. So, my suggestion would be that the registration template would look like t= his: "| Instructions are preceded by '|'. All fields are mandatory. Feature capability indicator name: Description: | The description should be no longer than 4 lines. More | detailed information can be provided in the feature | capability indicator specification. Feature capability indicator name: | The referenced specification MUST contain the information | listed in Section 5.3 of XXXX (IANA: Replace XXXX with | assigned RFC number of this specification. Contact: | Name(s) & email address(es) of person(s) to | contact for further information." The following information would be in the feature capability indication spe= cification: 5.3. Feature Capability Indicator Specification Requirements 5.3.1. General A feature capability indicator specification MUST address the issues defined in the following subsections, or document why an issue is not applicable for the specific feature capability indicator. A reference to the specification MUST be provided when the feature capability indicator is registered with IANA (see Section 8). It is bad practice for feature capability indicator specifications to repeat procedures (e.g. general procedures on the usage of the Feature-Caps header field and feature capability indicators) defined in this specification, unless needed for clarification or emphasis purpose. A feature capability indicator specification MUST NOT modify the Feature-Caps header field rules and semantics defined in Section 4. A feature capability indicator specification MUST NOT weaken any behavior designated with "SHOULD" or "MUST" in this specification. However, a specification MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" strength if features and capabilities associated with the SIP feature capability indicator 5.3.2. Overall Description The feature capability indicator specification MUST contain an overall description of the feature capability indicator: how it is used to indicate support of a feature, a description of the feature associated with the SIP feature cap, a description of any additional information (conveyed using one or more feature capability indicator values) that can be conveyed together with the feature capability indicator, and a description of how the associated feature may be exercised/invoked. 5.3.3. Feature Capability Indicator Values A feature capability indicator can have an associated value, or a list of values. The feature capability indicator specification MUST define the syntax and semantics of any value defined for the feature capability indicator, including possible restrictions related to the usage of a specific value. The feature capability indicator specification MUST=20 define the value(s) in accordance with the ABNF defined in Section 6.3.2. The feature capability indicator specification MUST define the default value, if applicable. If not values are defined for the feature capability indicator, it MUST be indicated in the feature capability indicator specification. A feature capability indicator value is only applicable for the feature capability indicator for which it has been defined. For other feature capability indicators, the value has to be defined explicitly, even if the semantics are identical. It is strongly RECOMMENDED to not re-use a value that already has been defined for another feature capability indicator, unless the semantics of the values are the same. 5.3.4. Usage Restrictions If there are restrictions on how SIP entities can insert a feature=20 capability indicator, the feature capability indicator specification MUS= T document such restrictions. There might be restrictions related to whether entities are allowed to insert a feature capability indicator in registration related messages, standalone transaction messages, or dialog related messages, whether entities are allowed to insert a feature capability indicator in requests or responses, whether entities also need to support other features and capabilities in order to insert a feature capability indicator, and whether entities are allowed to indicate support of a feature in conjunction with another feature. 5.3.5. Interoperability Considerations If there are specific interoperability considerations that apply to the=20 feature capability indicator, the feature capability indicator specificat= ion MUST document such considerations. 5.3.6. Security Considerations =09 If there are specific security considerations that apply to the feature capability indicator, the feature capability indicator specification MUST document such considerations. 5.3.7. Examples It is RECOMMENDED that the feature capability indicator specification provide demonstrative message flow diagrams, paired with complete messages and message descriptions. Note that example message flows are by definition informative, and do not replace normative text. 5.3.8. Other Information If there is additional information about the feature capability indicato= r, it is RECOMMENDED to describe such information. It can include e.g. names of related feature capability indicators." =20 Other major issues: ----------------------------------------- > 1) Should the expert reviewer be explicitly required to consider security= issues as part of that review? (see section 4.6 of > for example). Per my suggestion above, about moving 'Security considerations' from the te= mplate into the feature capability indicator specification, I guess the exp= ert reviewer would also look at the Security Considerations. I don't think = we need to explicitly say anything. ---------------- > 2) The security considerations section claims that the aspects of the con= siderations in rfc3840 that apply to end user devices don't apply here sinc= e these are not typically used to convey information about end user devices= . "Not typically" is weak. Can this > sentence be made more specific about = what concerns do and don't apply? The concerns in 3840 about influencing ap= plication behavior, and in 2506 about providing information that can be use= d to exploit implementation weakeness at the elements that > do provide the= se tags should be reflected here. I suggest some additional security considerations text: "9. Security Considerations The security issues for feature capability indicators are similar to the ones defined in RFC 3840 for media feature tags. Media feature tags can reveal information about end-users and end-user=20 equipment, which can be used for industrial espionage. The knowledge about end-user equipment capabilities can also be used to influence application behavior. As feature capability indicators are not intended = =20 to convey capability information of end-user devices, such end-user=20 security aspects of RFC 3840 do not apply to feature capability indica= tors. In addition, the RFC 3840 security issue regarding an attacker using the SIP caller preferences extension [RFC3841] in order to affect routing decisions does not apply, as the mechanism is not defined to be used with feature capability indicators. Feature capability indicators can, however, provide capability and=20 characteristics information about the SIP entity, some of which might be sensitive. The Feature- Caps header field does not convey address=20 information about SIP entities. However, individual feature capability= =20 indicators might provide address information as feature capability indic= ator values. Therefore, mechanisms for guaranteeing confidentiality and authenticity SHOULD be provided." ---------------- >3) Consider clarifying the behavior of SUBSCRIBE NOTIFY dialogs in section= 4.3.2. Only one of the 200 OKs to a forked SUBSCRIBE=20 >will get back to the UA that sent the subscribe. The information that crea= tes the other dialogs for it must appear in the immediate=20 >NOTIFYs. Is there a requirement for the end accepting a subscription to us= e the same feature capabilities in the 200 OK to the subscription=20 >and in the immediate NOTIFY? I suggest the following new note to section 4.3.2. "NOTE: As it cannot be guaranteed that 2xx responses associated with SIP SUBSCRIBE requests will reach the UAC, due to forking of the reques= t, entities need to indicate supported features and capabilities in the SIP N= OTIFY=20 request that will be sent for each of the created subscription dialogs." I don't think we need to mandate the capabilities in the 200 OK (if inserte= d in the first place) need to be identical to the NOTIFY. As the NOTIFY is = a target refresh request, it is allowed to indicate different capabilities. ---------------- > 4) Similarly, consider clarifying whether UPDATES nested within an INVITE= constrained to keep the same feature capability indicators as in the INVIT= E? Again, as UPDATEs are target refresh requests (even when nested within an I= NVITE), they can indicate a new set of supported capabilities. Note that the indication of supported features is not "offer/answer" - the = support is indicated independently in each direction. ---------------- Thanks! Regards, Christer From christer.holmberg@ericsson.com Wed Aug 22 05:14:50 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC36D21F869F for ; Wed, 22 Aug 2012 05:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.16 X-Spam-Level: X-Spam-Status: No, score=-6.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFsZUDn4kOYr for ; Wed, 22 Aug 2012 05:14:50 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id BE68721F8694 for ; Wed, 22 Aug 2012 05:14:49 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-a1-5034cd388d46 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7E.EC.17130.83DC4305; Wed, 22 Aug 2012 14:14:48 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 22 Aug 2012 14:14:48 +0200 From: Christer Holmberg To: Paul Kyzivat , Robert Sparks Date: Wed, 22 Aug 2012 14:14:47 +0200 Thread-Topic: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 Thread-Index: Ac1/8Nb8AjU9WcEiQ8akPTcQ1/D6tQAbj0qw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FBF344@ESESSCMS0356.eemea.ericsson.se> References: <50340427.40707@nostrum.com> <50341328.9090604@alum.mit.edu> In-Reply-To: <50341328.9090604@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvra7FWZMAg4aPRhYrNhxgtbg2p5HN 4uuPTWwOzB5/339g8liy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4MvbcyCx4LFXxvv8FSwPj btEuRk4OCQETiQXTDrNA2GISF+6tZ+ti5OIQEjjFKDH7cA8LhLOAUWLj6QPsXYwcHGwCFhLd /7RBGkQE/CT+PLzDDGIzC2hKPNq5lwnEZhFQlfg+5RjYUGEBV4kfq3+wQNS7SVyZfBLKNpJo ntAHVs8rEC5xv/sAK4gtJOAhsfn+SrCZnAI6Els/XmcHsRmBjvt+ag0TxC5xiVtP5jNBHC0g sWTPeWYIW1Ti5eN/rBD1ohJ32tczQtTrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExgFJuFZOws JC2zkLTMQtKygJFlFaNwbmJmTnq5uV5qUWZycXF+nl5x6iZGYDQd3PLbYAfjpvtihxilOViU xHn1VPf7CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamC0/C7EnpeSp891q/39Is05+8wuFTzh fXdQvC7h7MZn3Zd9jqsLGwXYRHxeNFl0k6tWbdr/CyfZp5wPWR91Nm7Zo41tLrFMRX0zbkY7 Rf09OftUnUoNn2NZRZj2109lp86lMuTP/ybif//JT5+wcPbYWxve1JWmM99NuHu529zo9Y6q Ob7rV8cqsRRnJBpqMRcVJwIAAiGspHQCAAA= Cc: "sipcore@ietf.org" Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 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, 22 Aug 2012 12:14:50 -0000 Hi Paul, >> 4) Similarly, consider clarifying whether UPDATES nested within an=20 >> INVITE constrained to keep the same feature capability indicators as=20 >> in the INVITE? > > I presume you mean an UPDATE to a before the final response to the dialog= establishing INVITE is received. > > It seems that UPDATES after the dialog is established aren't permitted to= carry the header. Where do you read that? The text says that the header field can be carried in target refresh reques= ts. >> Minor Issues: >> >> Section 4.3.4: A SIP Stand-Alone Transaction is by definition a=20 >> non-INVITE transaction. RFC4320 made 18x to non-INVITES a MUST NOT. I=20 >> suggest s/18x or 2xx/2xx/ in this section. >> >> The two places where you talk about overriding registration policy in=20 >> section 5.2 isn't quite right. We should be specific that we're only=20 >> talking about SIP header field parameters. In the first case, we're=20 >> using IETF Consensus (this document) to delegate parameters starting=20 >> with a 'g.' for _this_ header field to a policy of Expert Review. In=20 >> the second case, there's no overriding at all - registrations use IETF=20 >> Consensus there. Here's a stab at something more accurate. Maybe=20 >> others can come up with something better. I suggest replacing the=20 >> first instance with "Note that the general policy for registering SIP=20 >> header field parameters is 'IETF Consensus' as specified in [RFC3968].=20 >> This document delegates the registration of parameters to the=20 >> Feature-Caps header field starting with 'g.' to a policy of 'Expert=20 >> Review'", and deleting the second instance. > > You and I already talked about this, but I realize now that we have to wo= rk on the wording more. The issue is that from a sip=20 > header field perspective the parameter includes the "+", and its paramete= rs that begin with "+" that we are reserving in the header field parameter = registry. > > But the "+" isn't part of the name of the feature capability indicator. > > So we are delegating parameters that start with "+g." to the expert revie= w procedure. > > And while things in the sip tree (things beginning with "+sip.", while st= ill requiring IETF consensus, will still go in the sip tree, not as individ= uals in the sip header fields parameter registry. But maybe we don't need t= o "note" this part. I am not sure I understand. The reviewer will check the feature capability = indicator. The "+" is a SIP coding issue. The draft even says that the lead= ing "+" is not part of the registration. >> The NOTE in section 6.2.1 is not useful unless you know the history of=20 >> that led to the syntax in 3840 and 3841. I suggest replacing it with >> 'NOTE: The "*" value is present in order to follow the guidelines for=20 >> syntac in [RFC4485] and to maintain a consistent format with [RFC3840]=20 >> and [RFC3841].' >> >> Nits: >> >> There is a mix of "xxx" "XXX" and "XXXX" to indicate to the RFC Editor=20 >> that the number assigned to this RFC should appear here. Please choose=20 >> one format and make the instructions to the RFC Editor for making the=20 >> substitution clear. > > I recently discovered that xml2rfc has '&rfc.number;' to get this value, = though I haven't tried it yet. Apparently it expands to XXXX for drafts. I'll take a look :) Regards, Christer From brett@broadsoft.com Wed Aug 22 05:19:34 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE2621F86A3 for ; Wed, 22 Aug 2012 05:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQpeJ9aHHHB2 for ; Wed, 22 Aug 2012 05:19:33 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.202]) by ietfa.amsl.com (Postfix) with ESMTP id 96C1921F86A1 for ; Wed, 22 Aug 2012 05:19:33 -0700 (PDT) Received: from casumhub01.citservers.local (172.16.98.57) by FW02.citservers.local (172.16.98.4) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 22 Aug 2012 05:23:10 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Wed, 22 Aug 2012 05:23:11 -0700 From: Brett Tate To: "sipcore@ietf.org" , "draft-ietf-sipcore-proxy-feature@tools.ietf.org" Date: Wed, 22 Aug 2012 05:19:30 -0700 Thread-Topic: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues Thread-Index: Ac2AXv93lTJjLkhVTEyk90Fi7o7g2wAAGykg Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F7509@EXMBXCLUS01.citservers.local> References: <7F2072F1E0DE894DA4B517B93C6A05853409FBF33A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FBF33A@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues 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, 22 Aug 2012 12:19:34 -0000 > >3) Consider clarifying the behavior of SUBSCRIBE NOTIFY dialogs in > section 4.3.2. Only one of the 200 OKs to a forked SUBSCRIBE > >will get back to the UA that sent the subscribe. The information that > creates the other dialogs for it must appear in the immediate > >NOTIFYs. Is there a requirement for the end accepting a subscription > to use the same feature capabilities in the 200 OK to the subscription > >and in the immediate NOTIFY? >=20 > I suggest the following new note to section 4.3.2. >=20 > "NOTE: As it cannot be guaranteed that 2xx responses associated with > SIP SUBSCRIBE requests will reach the UAC, due to forking of the request= , > entities need to indicate supported features and capabilities in=20 > the SIP NOTIFY request that will be sent for each of the created=20 > subscription dialogs." >=20 > I don't think we need to mandate the capabilities in the 200 OK=20 > (if inserted in the first place) need to be identical to the=20 > NOTIFY. As the NOTIFY is a target refresh request, it is allowed=20 > to indicate different capabilities. Based upon the current wording of draft-ietf-sipcore-proxy-feature-05 secti= on 4.3.2, the feature-caps within the initial SUBSCRIBE's 2xx (or deprecate= d 18x) appears irrelevant from subscriber's perspective since the response = does not appear to create a dialog. RFC 6665 is a little ambiguous concerning if SUBSCRIBE's 2xx actually creat= es a dialog. From notifier perspective, it looks like sending 2xx does ind= icate that the dialog usage was created. However from a subscriber perspec= tive, it looks like receiving the 2xx no longer creates a dialog. RFC 6665 section 4.2.1.1 "Once the notifier determines that it has enough information to create the subscription (i.e., it understands the event package, the subscription pertains to a known resource, and there are no other barriers to creating the subscription), it creates the subscription and a dialog usage, and returns a 200 (OK) response." RFC 6665 section 4.4.1: "Dialogs usages are created upon completion of a NOTIFY transaction for a new subscription, unless the NOTIFY request contains a "Subscription-State" of "terminated." Because the dialog usage is established by the NOTIFY request, the route set at the subscriber is taken from the NOTIFY request itself, as opposed to the route set present in the 200-class response to the SUBSCRIBE request." From christer.holmberg@ericsson.com Wed Aug 22 05:21:28 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73D321F86A3 for ; Wed, 22 Aug 2012 05:21:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.161 X-Spam-Level: X-Spam-Status: No, score=-6.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1Krto9Vv3ql for ; Wed, 22 Aug 2012 05:21:24 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6880121F86AD for ; Wed, 22 Aug 2012 05:21:24 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-73-5034cec27e42 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A0.BE.11467.3CEC4305; Wed, 22 Aug 2012 14:21:23 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 22 Aug 2012 14:21:23 +0200 From: Christer Holmberg To: Brett Tate , "sipcore@ietf.org" , "draft-ietf-sipcore-proxy-feature@tools.ietf.org" Date: Wed, 22 Aug 2012 14:21:21 +0200 Thread-Topic: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues Thread-Index: Ac2AXv93lTJjLkhVTEyk90Fi7o7g2wAAGykgAABFq5A= Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FBF354@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853409FBF33A@ESESSCMS0356.eemea.ericsson.se> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F7509@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F7509@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvre7hcyYBBhMb+S2a5/9jtHjbP5/R 4uuPTWwOzB4/bgd6LFnyk8njy+XPbAHMUVw2Kak5mWWpRfp2CVwZ07btZSpokai4MvkgWwPj ZeEuRk4OCQETicuzzjNC2GISF+6tZ+ti5OIQEjjFKDHz8gGwhJDAAkaJlv/VXYwcHGwCFhLd /7RBakQEtjBKvH1wCayGRUBVYtueU0wgtrBAlURT0yc2EFtEoFri+9dvzCC9IgJWEvcWSYOE eQXCJb48XMUOMX4xo8TjXQYgNqdAmMS+lWvAxjAC3fP9FITNLCAucevJfCaIOwUkluw5zwxh i0q8fPyPFaJeVOJO+3pGiHodiQW7IU5gFtCWWLbwNTPEXkGJkzOfsExgFJ2FZOwsJC2zkLTM QtKygJFlFaNwbmJmTnq5oV5qUWZycXF+nl5x6iZGYMwc3PJbdwfjqXMihxilOViUxHm5kvb7 CwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamC0WXFmquRB5f+7Lqj4zHrw79o97Z8nC8+X1Be2 v863q0mK8zrxyCFyxRGtbtXkucuX/1z2veTI9qq+lZXWObITdQ7nZKnY9qy/tGRRnY7VDBej voa/um62optktofP494cXV7sGRnl/n+iyZy57qfFrJN3OG1VmWOxTVL3807JGqtTife2Fq1U YinOSDTUYi4qTgQAXDGiXmcCAAA= Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues 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, 22 Aug 2012 12:21:29 -0000 Hi Brett, Please see the note text I suggested in my reply to Robert. Regards, Christer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Brett Tate Sent: 22. elokuuta 2012 15:20 To: sipcore@ietf.org; draft-ietf-sipcore-proxy-feature@tools.ietf.org Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Rob= ert's comments - IANA issues and major issues > >3) Consider clarifying the behavior of SUBSCRIBE NOTIFY dialogs in > section 4.3.2. Only one of the 200 OKs to a forked SUBSCRIBE > >will get back to the UA that sent the subscribe. The information that > creates the other dialogs for it must appear in the immediate > >NOTIFYs. Is there a requirement for the end accepting a subscription > to use the same feature capabilities in the 200 OK to the subscription > >and in the immediate NOTIFY? >=20 > I suggest the following new note to section 4.3.2. >=20 > "NOTE: As it cannot be guaranteed that 2xx responses associated with =20 > SIP SUBSCRIBE requests will reach the UAC, due to forking of the=20 > request, entities need to indicate supported features and=20 > capabilities in the SIP NOTIFY request that will be sent for each of=20 > the created subscription dialogs." >=20 > I don't think we need to mandate the capabilities in the 200 OK (if=20 > inserted in the first place) need to be identical to the NOTIFY. As=20 > the NOTIFY is a target refresh request, it is allowed to indicate=20 > different capabilities. Based upon the current wording of draft-ietf-sipcore-proxy-feature-05 secti= on 4.3.2, the feature-caps within the initial SUBSCRIBE's 2xx (or deprecate= d 18x) appears irrelevant from subscriber's perspective since the response = does not appear to create a dialog. RFC 6665 is a little ambiguous concerning if SUBSCRIBE's 2xx actually creat= es a dialog. From notifier perspective, it looks like sending 2xx does ind= icate that the dialog usage was created. However from a subscriber perspec= tive, it looks like receiving the 2xx no longer creates a dialog. RFC 6665 section 4.2.1.1 "Once the notifier determines that it has enough information to create the= subscription (i.e., it understands the event package, the subscription pe= rtains to a known resource, and there are no other barriers to creating th= e subscription), it creates the subscription and a dialog usage, and retur= ns a 200 (OK) response." RFC 6665 section 4.4.1: "Dialogs usages are created upon completion of a NOTIFY transaction for a = new subscription, unless the NOTIFY request contains a "Subscription-State= " of "terminated." Because the dialog usage is established by the NOTIFY request, the route = set at the subscriber is taken from the NOTIFY request itself, as opposed = to the route set present in the 200-class response to the SUBSCRIBE reques= t." _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From brett@broadsoft.com Wed Aug 22 05:45:47 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BC921F862B for ; Wed, 22 Aug 2012 05:45:47 -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] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+58EbUcHXc2 for ; Wed, 22 Aug 2012 05:45:47 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id EE1A621F84D4 for ; Wed, 22 Aug 2012 05:45:46 -0700 (PDT) Received: from CASUMHUB02.citservers.local (172.16.98.161) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 22 Aug 2012 05:49:24 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Wed, 22 Aug 2012 05:49:24 -0700 From: Brett Tate To: "sipcore@ietf.org" , "draft-ietf-sipcore-proxy-feature@tools.ietf.org" Date: Wed, 22 Aug 2012 05:45:44 -0700 Thread-Topic: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues Thread-Index: Ac2AXv93lTJjLkhVTEyk90Fi7o7g2wAAGykgAABFq5AAAFZbAA== Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F7513@EXMBXCLUS01.citservers.local> References: <7F2072F1E0DE894DA4B517B93C6A05853409FBF33A@ESESSCMS0356.eemea.ericsson.se> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E2F7509@EXMBXCLUS01.citservers.local> <7F2072F1E0DE894DA4B517B93C6A05853409FBF354@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FBF354@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues 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, 22 Aug 2012 12:45:47 -0000 > Please see the note text I suggested in my reply to Robert. >=20 > > I suggest the following new note to section 4.3.2. > > > > "NOTE: As it cannot be guaranteed that 2xx responses=20 > > associated with SIP SUBSCRIBE requests will reach the=20 > > UAC, due to forking of the request, entities need to=20 > > indicate supported features and capabilities in the=20 > > SIP NOTIFY request that will be sent for each of > > the created subscription dialogs." Good enough for me. However, my understanding is that the SUBSCRIBE 2xx co= mment is relevant to RFC 3265 compliant subscribers instead of RFC 6665 com= pliant subscribers. From pkyzivat@alum.mit.edu Wed Aug 22 10:18:49 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7222C21F858A for ; Wed, 22 Aug 2012 10:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=0.298, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGsBKx2j9V7s for ; Wed, 22 Aug 2012 10:18:48 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id C137521F85F4 for ; Wed, 22 Aug 2012 10:18:48 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta03.westchester.pa.mail.comcast.net with comcast id pmH01j00A1YDfWL53tJrP2; Wed, 22 Aug 2012 17:18:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id ptJU1j01M3ZTu2S3gtJUD4; Wed, 22 Aug 2012 17:18:28 +0000 Message-ID: <50351485.7050507@alum.mit.edu> Date: Wed, 22 Aug 2012 13:19:01 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05853409FBF33A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FBF33A@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues 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, 22 Aug 2012 17:18:49 -0000 A couple of comments now. Maybe more when I have more time to think about it: On 8/22/12 8:09 AM, Christer Holmberg wrote: > Hi Robert, > > This reply addresses your comment regarding the IANA registration template/procedure, and the major issues. > >> Summary: There are a few issues to address before progressing to IETF LC. I'm putting the document into revised ID needed to address at least the IANA points below. >> >> The primary issue is with the instructions to IANA on creating the new trees and the registration template used to put things in those trees. >> >> Sections 7.3.2 and 7.3.3 don't currently define the format of an entry in the trees in the new subregistry. This needs to be clearly defined, and the sections need to explicitly indicate that the trees are initially empty. > > I suggest to add the following text to the end of sections 7.3.2 and 7.3.3: > > "The format of the [global/SIP] tree is as described below: > > Decimal Name Description Reference > --------------------------------------------------- > > Decimal contains an integer value, incremented by IANA every time a new feature capability indicator is added to the table. Why? What value does this integer have? >> 4) Similarly, consider clarifying whether UPDATES nested within an INVITE constrained to keep the same feature capability indicators as in the INVITE? > > Again, as UPDATEs are target refresh requests (even when nested within an INVITE), they can indicate a new set of supported capabilities. Consider: INVITE 1xx INVITE UPDATE 200 UPDATE 200 INVITE (Regardless of the direction of the UPDATE) Do the P-F values in the 200 INVITE override those from the UPDATE or its response? In theory the 200 UPDATE and 200 INVITE can be received out of order. And proxies that are including P-F may not be stateful about this, so that they can only indicate their state at the time the message goes by. I don't see what could be done about it. In most cases it won't matter what the order is. Thanks, Paul From pkyzivat@alum.mit.edu Wed Aug 22 10:50:19 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8F221F8620 for ; Wed, 22 Aug 2012 10:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOEsAQxrnCCu for ; Wed, 22 Aug 2012 10:50:18 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB5121F8576 for ; Wed, 22 Aug 2012 10:50:17 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta14.westchester.pa.mail.comcast.net with comcast id pt731j0030xGWP85EtqLvA; Wed, 22 Aug 2012 17:50:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id ptpm1j0083ZTu2S3Ytpmdr; Wed, 22 Aug 2012 17:49:46 +0000 Message-ID: <50351BE5.9070805@alum.mit.edu> Date: Wed, 22 Aug 2012 13:50:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Christer Holmberg References: <50340427.40707@nostrum.com> <50341328.9090604@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FBF344@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FBF344@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 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, 22 Aug 2012 17:50:19 -0000 On 8/22/12 8:14 AM, Christer Holmberg wrote: > Hi Paul, > >>> 4) Similarly, consider clarifying whether UPDATES nested within an >>> INVITE constrained to keep the same feature capability indicators as >>> in the INVITE? >> >> I presume you mean an UPDATE to a before the final response to the dialog establishing INVITE is received. >> >> It seems that UPDATES after the dialog is established aren't permitted to carry the header. > > Where do you read that? Oops. Sorry. At the time I wrote that I missed the part about being allowed in target refresh requests. > The text says that the header field can be carried in target refresh requests. > >>> Minor Issues: >>> >>> Section 4.3.4: A SIP Stand-Alone Transaction is by definition a >>> non-INVITE transaction. RFC4320 made 18x to non-INVITES a MUST NOT. I >>> suggest s/18x or 2xx/2xx/ in this section. >>> >>> The two places where you talk about overriding registration policy in >>> section 5.2 isn't quite right. We should be specific that we're only >>> talking about SIP header field parameters. In the first case, we're >>> using IETF Consensus (this document) to delegate parameters starting >>> with a 'g.' for _this_ header field to a policy of Expert Review. In >>> the second case, there's no overriding at all - registrations use IETF >>> Consensus there. Here's a stab at something more accurate. Maybe >>> others can come up with something better. I suggest replacing the >>> first instance with "Note that the general policy for registering SIP >>> header field parameters is 'IETF Consensus' as specified in [RFC3968]. >>> This document delegates the registration of parameters to the >>> Feature-Caps header field starting with 'g.' to a policy of 'Expert >>> Review'", and deleting the second instance. >> >> You and I already talked about this, but I realize now that we have to work on the wording more. The issue is that from a sip >> header field perspective the parameter includes the "+", and its parameters that begin with "+" that we are reserving in the header field parameter registry. >> >> But the "+" isn't part of the name of the feature capability indicator. >> >> So we are delegating parameters that start with "+g." to the expert review procedure. >> >> And while things in the sip tree (things beginning with "+sip.", while still requiring IETF consensus, will still go in the sip tree, not as individuals in the sip header fields parameter registry. But maybe we don't need to "note" this part. > > I am not sure I understand. The reviewer will check the feature capability indicator. The "+" is a SIP coding issue. The draft even says that the leading "+" is not part of the registration. I brought it up because when you look at the header as a whole, the *parameter* does include the "+". That is pertinent to the discussion of which parameters are being delegated. What do you think of: "Note that the general policy for registering SIP header field parameters is 'IETF Consensus' as specified in [RFC3968]. This document, itself subject to 'IETF Consensus' defines a new IANA procedure for registration of all parameters beginning with "+" of the "Proxy-Feature" sip header field. The registration of those parameters beginning with "+" followed by "g." are governed by 'Expert Review' policy, while others are 'IETF Consensus'. Thanks, Paul From christer.holmberg@ericsson.com Wed Aug 22 11:35:55 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5309521F8658 for ; Wed, 22 Aug 2012 11:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8Zd4+R42t3G for ; Wed, 22 Aug 2012 11:35:54 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0CDE721F8665 for ; Wed, 22 Aug 2012 11:35:53 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-0f-5035268873e7 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 42.E4.11467.88625305; Wed, 22 Aug 2012 20:35:52 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Wed, 22 Aug 2012 20:35:53 +0200 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Date: Wed, 22 Aug 2012 20:35:51 +0200 Thread-Topic: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues Thread-Index: Ac2AijU/QjkPoYL3RfqqNU4vhWUFBgACbp22 Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EDD@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853409FBF33A@ESESSCMS0356.eemea.ericsson.se>, <50351485.7050507@alum.mit.edu> In-Reply-To: <50351485.7050507@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM+JvrW6HmmmAweWVphYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXxddIWtoL9ghX9l2UaGG/wdjFyckgImEg8 unyVEcIWk7hwbz1bFyMXh5DAKUaJU41zWSGcBYwS/evnsXcxcnCwCVhIdP/TBmkQEQiUuLpk AjOIzSKgKjGn5QWYLSxQJdHU9IkNoqZa4vvXb8wQtpHE8hnzweK8AuESTbsPsILYQgLlEnP3 XgGr4RTQkfgy8SKYzQh00PdTa5hAbGYBcYlbT+YzQRwqILFkz3lmCFtU4uXjf6wQ9aISd9rX M0LU60gs2A1xA7OAtsSyha+ZIfYKSpyc+YRlAqPoLCRjZyFpmYWkZRaSlgWMLKsYhXMTM3PS yw31Uosyk4uL8/P0ilM3MQIj5OCW37o7GE+dEznEKM3BoiTOy5W0319IID2xJDU7NbUgtSi+ qDQntfgQIxMHp1QDY6jfDFW3P7qpJZev2fGfFPV7VZR3Wt8p7vhZjx7+GayeigcX/+FW2ZX5 SCmkP2HDGZX7l3MWyq8/VMjdlin8ojrv0SvvK8m8Vg5Pr3B2/FbMEdm+RC7Sg8OoUrBk88vT bEeX9HtzvCw/GH5m2d/nK77YrLF2Lt11+ueGOO7p60J3nHy9l104RomlOCPRUIu5qDgRAAxo q/1eAgAA Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues 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, 22 Aug 2012 18:35:55 -0000 Hi, >>> Summary: There are a few issues to address before progressing to IETF L= C. I'm putting the document into revised ID needed to address at least the = IANA points below. >>> >>> The primary issue is with the instructions to IANA on creating the new = trees and the registration template used to put things in those trees. >>> >>> Sections 7.3.2 and 7.3.3 don't currently define the format of an entry = in the trees in the new subregistry. This needs to be clearly defined, and = the sections need to explicitly indicate that the trees are initially empty= . >> >> I suggest to add the following text to the end of sections 7.3.2 and 7.3= .3: >> >> "The format of the [global/SIP] tree is as described below: >> >> Decimal Name Description Reference >> --------------------------------------------------- >> >> Decimal contains an integer value, incremented by IANA every time = a new feature capability indicator is added to the table. > > Why? What value does this integer have? It's just a "row number". Most media feature tag tables seem to have it, so= that's why I added it... I didn't even check whether it's part of the associated registration templa= tes, or whether IANA adds it by default. >>> 4) Similarly, consider clarifying whether UPDATES nested within an INVI= TE constrained to keep the same feature capability indicators as in the INV= ITE? >> >> Again, as UPDATEs are target refresh requests (even when nested within a= n INVITE), they can indicate a new set of supported capabilities. > >Consider: > >INVITE >1xx INVITE >UPDATE >200 UPDATE >200 INVITE > >(Regardless of the direction of the UPDATE) > >Do the P-F values in the 200 INVITE override those from the UPDATE or >its response? > >In theory the 200 UPDATE and 200 INVITE can be received out of order. >And proxies that are including P-F may not be stateful about this, so >that they can only indicate their state at the time the message goes by. > >I don't see what could be done about it. In most cases it won't matter >what the order is. I agree, because I think the indicated features will be the same in these m= essages. Regards, Christer= From christer.holmberg@ericsson.com Wed Aug 22 11:40:02 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFA0221F865B for ; Wed, 22 Aug 2012 11:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.163 X-Spam-Level: X-Spam-Status: No, score=-6.163 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqsAPLwg4AUe for ; Wed, 22 Aug 2012 11:40:01 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8237A21F8653 for ; Wed, 22 Aug 2012 11:40:00 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-c2-5035277fc93c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 0A.D5.25676.F7725305; Wed, 22 Aug 2012 20:39:59 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 22 Aug 2012 20:39:59 +0200 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 22 Aug 2012 20:36:14 +0200 Thread-Topic: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 Thread-Index: Ac2AjpfNsSPg42jdQIGG+lamVpIAsgABmsMm Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EDE@ESESSCMS0356.eemea.ericsson.se> References: <50340427.40707@nostrum.com> <50341328.9090604@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FBF344@ESESSCMS0356.eemea.ericsson.se>, <50351BE5.9070805@alum.mit.edu> In-Reply-To: <50351BE5.9070805@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvrW69ummAwbt58hYrNhxgtbg2p5HN 4uuPTWwOzB5/339g8liy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4MhZPncda0CJesfn2ddYG xrNCXYycHBICJhLnd3ewQNhiEhfurWfrYuTiEBI4xSjReGwDO4Qzh1Fiz+u1QBkODjYBC4nu f9ogpoiAhsSkrWogvcwCgRIb985mAQmzCKhKLNmdAhIWFnCV+LH6B9h4EQE3iSuTT0LZRhK/ Jt1lBbF5BcIl1m6+C7VpG6PE13kXwBKcAjoSn358AbMZgW77fmoNE8QucYlbT+YzQdwsILFk z3lmCFtU4uXjf1D1ohJ32tczQtTrSCzY/YkNwtaWWLbwNTPEYkGJkzOfsExgFJuFZOwsJC2z kLTMQtKygJFlFaNwbmJmTnq5kV5qUWZycXF+nl5x6iZGYDQd3PJbdQfjnXMihxilOViUxHmt t+7xFxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cBosPPNe6l31y/cqp7LtvTRHu7WOXftNqiL FJy7Zsp19NJnK+XSquAscabeWw/bt9Yt3Df9iFoZL/txpUWf7jy68yc/9qCYmIxwplmVxsH1 cVrTdop/c5h5yLb2p+bxX87Sdv+W3ZQLqa09Z9LJ6Ll350spNtd39fmMR3V15n0LEbz3baP+ y677SizFGYmGWsxFxYkAhfLorHQCAAA= Cc: "sipcore@ietf.org" Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 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, 22 Aug 2012 18:40:02 -0000 Hi, >>>> Minor Issues: >>>> >>>> Section 4.3.4: A SIP Stand-Alone Transaction is by definition a >>>> non-INVITE transaction. RFC4320 made 18x to non-INVITES a MUST NOT. I >>>> suggest s/18x or 2xx/2xx/ in this section. >>>> >>>> The two places where you talk about overriding registration policy in >>>> section 5.2 isn't quite right. We should be specific that we're only >>>> talking about SIP header field parameters. In the first case, we're >>>> using IETF Consensus (this document) to delegate parameters starting >>>> with a 'g.' for _this_ header field to a policy of Expert Review. In >>>> the second case, there's no overriding at all - registrations use IETF >>>> Consensus there. Here's a stab at something more accurate. Maybe >>>> others can come up with something better. I suggest replacing the >>>> first instance with "Note that the general policy for registering SIP >>>> header field parameters is 'IETF Consensus' as specified in [RFC3968]. >>>> This document delegates the registration of parameters to the >>>> Feature-Caps header field starting with 'g.' to a policy of 'Expert >>>> Review'", and deleting the second instance. >>> >>> You and I already talked about this, but I realize now that we have to = work on the wording more. The issue is that from a sip >>> header field perspective the parameter includes the "+", and its parame= ters that begin with "+" that we are reserving in the header field paramete= r registry. >>> >>> But the "+" isn't part of the name of the feature capability indicator. >>> >>> So we are delegating parameters that start with "+g." to the expert rev= iew procedure. >>> >>> And while things in the sip tree (things beginning with "+sip.", while = still requiring IETF consensus, will still go in the sip tree, not as indiv= iduals in the sip header fields parameter registry. But maybe we don't need= to "note" this part. >> >> I am not sure I understand. The reviewer will check the feature capabili= ty indicator. The "+" is a SIP coding issue. The draft even says that the l= eading "+" is not part of the registration. > > I brought it up because when you look at the header as a whole, the > *parameter* does include the "+". That is pertinent to the discussion of > which parameters are being delegated. What do you think of: > > "Note that the general policy for registering SIP header field > parameters is 'IETF Consensus' as specified in [RFC3968]. This document, > itself subject to 'IETF Consensus' defines a new IANA procedure for > registration of all parameters beginning with "+" of the "Proxy-Feature" > sip header field. The registration of those parameters beginning with > "+" followed by "g." are governed by 'Expert Review' policy, while > others are 'IETF Consensus'. Just to make sure I understand, where do you suggest to add this note, and = what text would it replace? :) Regards, Christer= From jmpolk@cisco.com Wed Aug 22 11:54:58 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5347A21F866E for ; Wed, 22 Aug 2012 11:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.916 X-Spam-Level: X-Spam-Status: No, score=-109.916 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VxgAMMY8IJC for ; Wed, 22 Aug 2012 11:54:57 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 42B0121F8665 for ; Wed, 22 Aug 2012 11:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=7849; q=dns/txt; s=iport; t=1345661697; x=1346871297; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=SvhG0I6NjnK7Sq26l3eRrWcrMYHYHqXIXD8FVVik/Fk=; b=OaNYl9N+FjkLzPclNFxEpOS9guipefFialXveCR9Lo4gxOa09s7XZKZ1 SgmUGG++QoyVZFHOrJ+f16zQ3JoS9bZGXjdWRdOn7w5WXDqepLFIm/ijQ mf6P98IaAIWE0j4AhfWyOAqImeO3zD11QMRz2F8CZ5RefrymMv1zIiWZE Q=; X-IronPort-AV: E=Sophos;i="4.80,809,1344211200"; d="scan'208";a="55709758" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 22 Aug 2012 18:54:57 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id q7MIsuBv016403; Wed, 22 Aug 2012 18:54:56 GMT Message-Id: <201208221854.q7MIsuBv016403@mtv-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 22 Aug 2012 13:54:54 -0500 To: "Peterson, Jon" , James Polk , Paul Kyzivat , "Brian Rosen" From: James Polk In-Reply-To: <55A5A9A87506CB4BA580BF9D531957DA69232F38@STNTEXCH01.cis.ne ustar.com> References: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> <6C0A8F8E-B79C-4F82-AECC-51FFA79ED6A1@acmepacket.com> <502AAE07.3020309@alum.mit.edu> <43ef3c20e7f1fb98a6a6d8758fb4a59c.squirrel@webmail.brianrosen.net> <502ABF1B.9020400@alum.mit.edu> <201208220005.q7M057iE008732@mtv-core-1.cisco.com> <55A5A9A87506CB4BA580BF9D531957DA69232F38@STNTEXCH01.cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Geolocation Header Question 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, 22 Aug 2012 18:54:58 -0000 At 02:15 AM 8/22/2012, Peterson, Jon wrote: >Um... why isn't sip:@domain valid? I see sip-uri as valid in >the BNF, and that implies tel in the user portion. I'm basing my response on this from section 4.6 If a location URI is included in a SIP request, the sending user agent MUST also include a Supported header field indicating which location profiles it supports. Two option tags for location profiles are defined by this document: "geolocation-sip" and "geolocation- http". Future specifications MAY define further location profiles per the IANA policy described in Section 8.3. The "geolocation-sip" option tag signals support for acquiring location information via the presence event package of SIP [RFC3856]. A location recipient who supports this option can send a SUBSCRIBE request and parse a resulting NOTIFY containing a PIDF-LO object. The URI schemes supported by this option include "sip", "sips", and "pres". I haven't read that this Geolocation: ; user=phone will be subscribed to and expect to receive a PIDF-LO, which the RFC says earlier is the only location value format that's specified as acceptable. I may have missed something in the discussion, but that's why I don't think the scenario is depicting what RFC 6442 is specifying. Additionally, and I just may not know this - as I'm not an expert on , but I haven't ever heard of someone wanting to SUBSCRIBE to a . But again, I could be underinformed on this one. James >Jon Peterson >NeuStar, Inc. >________________________________________ >From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf >Of James Polk [jmpolk@cisco.com] >Sent: Tuesday, August 21, 2012 5:05 PM >To: Paul Kyzivat; Brian Rosen >Cc: sipcore@ietf.org >Subject: Re: [sipcore] Geolocation Header Question > >At 04:11 PM 8/14/2012, Paul Kyzivat wrote: > >On 8/14/12 5:04 PM, Brian Rosen wrote: > >>Yes, agree, but probably not relevant to the discussion. > >> > >>I went back and looked at the original email, and decided I either don't > >>understand something, or there is some larger problem. > >> > >>Between what two elements is this Geolocation header running? > >> > >>UAS to proxy server (UE to E-CSCF)? Proxy to gateway (E-CSCF to MGCF)? > >> > >>Regardless, it seems to be misusing the header, because it's not a sip or > >>http LbyR. > >>Better to get a real scheme somehow that does the right thing, use a > >>parameter in another header, or create a new header. Depends on what this > >>actually represents. It sounds like it really is LbyR, and you want to > >>communicate a key.:@domain is appropriate. The issue is > >>what is the right scheme? It's not sip - it's not sip presence. It's not > >>HELD identity I take it. > > > >As I already stated, I think sip: is ok if this special lookup can > >be viewed as an *optimization* over doing the presence lookup, and > >doing it the presence way still works. > > > >Otherwise I agree with Brian. > > isn't an allowed URI in RFC 6442, neither is the use=phone >tag, so IMO that makes this offering a no go as far as 'being in line >with an IETF standards track RFC' (to be formal about it). > >James > > > > Thanks, > > Paul > > > >>Brian > >> > >>>I already commented to the original question. > >>>Here I'm just commenting on the comments. > >>> > >>>On 8/14/12 1:55 PM, Brian Rosen wrote: > >>>>I don't think so. > >>>> > >>>>A geolocation header with a sip uri has to lead to a presence server > >>>>that > >>>>can respond to a presence subscription which would return a PIDF with > >>>>location. > >>>> > >>>>Routing a tel uri (which user=phone is supposed to be interchangeable > >>>>with) to a presence service usually makes no sense. I don't think you > >>>>can > >>>>send a SUBSCRIBE to a tel uri. If you could, user=phone is okay. If > >>>>you > >>>>can't, user=phone is not okay. > >>> > >>>I disagree that a tel uri is *equivalent* to a sip URI with user=phone! > >>> > >>>A sip URI with user=phone is supposed to be routed like any other sip > >>>URI until it reaches a server responsible for the domain of the URI. > >>>*Then* the user part is to be interpreted as representing a phone number. > >>> > >>>Conversely, a tel URI has no domain. (And no user=phone.) The semantics > >>>of telephone numbers are public knowledge. So any server can decide > >>>where to route it next, based on the number and whatever other context > >>>it has. > >>> > >>>IMO the distinction is important. If you want to enable anybody to > >>>decide how to reach the phone number (including going through a PSTN > >>>GW), then use a tel URI. If you want the call handled via SIP at least > >>>until it reaches a particular domain, then use a sip URI. > >>> > >>> Thanks, > >>> Paul > >>> > >>>>It's perfectly reasonable to make the uri > >>>>sip:+358222222222@presence.example.com > >>>>that is, a real domain, and no user=phone > >>>> > >>>>Brian > >>>>> > >>>>>You could do this: > >>>>>Geolocation: > >>>>>(although why ATIS would be defining how calls from Finland work is > >>>>>beyond > >>>>>me ;) > >>>>> > >>>>>But I don't understand why they need it in a Geoloc header to begin > >>>>>with. > >>>>>I assumed that header was for devices/networks that use its mechanisms > >>>>>(ie, HELD, SUB, pidf). They're not going to do that, so why use that > >>>>>header? > >>>>> > >>>>>You said they're doing the location lookup on the PSTN side - > >>>>>presumably > >>>>>then the location is being looked up based on the calling party info, > >>>>>which should be in another existing header. Can't they use one of them > >>>>>as > >>>>>the query key for the lookup? (we have plenty to choose from for that > >>>>>already :) > >>>>> > >>>>>-hadriel > >>>>> > >>>>> > >>>>>On Aug 7, 2012, at 11:31 AM, Hannes Tschofenig wrote: > >>>>> > >>>>>>I agree but the tel URI is not one of the supported location URIs in > >>>>>>RFC > >>>>>>6442. > >>>>>>Hence, the guys just use a different way to convey the same > >>>>>>information. > >>>>>> > >>>>>>On Aug 7, 2012, at 5:52 PM, Worley, Dale R (Dale) wrote: > >>>>>> > >>>>>>>>From: Hannes Tschofenig [hannes.tschofenig@gmx.net] > >>>>>>>> > >>>>>>>>In order to convey that phone number for a lookup they are thinking > >>>>>>>>about using the Geolocation header in the following form: > >>>>>>>>Geolocation: >>>>>>> > >>>>>>>Naively, I'd say that since the goal is to carry an E.164 number, a > >>>>>>>tel: URI would be the ideal choice. > >>>>>>> > >>>>>>>Dale > >>>>>> > >>>>>>_______________________________________________ > >>>>>>sipcore mailing list > >>>>>>sipcore@ietf.org > >>>>>>https://www.ietf.org/mailman/listinfo/sipcore > >>>>> > >>>>>_______________________________________________ > >>>>>sipcore mailing list > >>>>>sipcore@ietf.org > >>>>>https://www.ietf.org/mailman/listinfo/sipcore > >>>> > >>>> > >>>>_______________________________________________ > >>>>sipcore mailing list > >>>>sipcore@ietf.org > >>>>https://www.ietf.org/mailman/listinfo/sipcore > >>> > >>>_______________________________________________ > >>>sipcore mailing list > >>>sipcore@ietf.org > >>>https://www.ietf.org/mailman/listinfo/sipcore > >> > >> > > > >_______________________________________________ > >sipcore mailing list > >sipcore@ietf.org > >https://www.ietf.org/mailman/listinfo/sipcore > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Wed Aug 22 12:37:59 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B840721F850D for ; Wed, 22 Aug 2012 12:37:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=-0.307, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCYttwHY9ze3 for ; Wed, 22 Aug 2012 12:37:59 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 98E9921F84C8 for ; Wed, 22 Aug 2012 12:37:58 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by qmta03.westchester.pa.mail.comcast.net with comcast id pmXu1j00A0SCNGk53ve1Q7; Wed, 22 Aug 2012 19:38:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id pve81j00L3ZTu2S3Vve822; Wed, 22 Aug 2012 19:38:08 +0000 Message-ID: <50353521.5060606@alum.mit.edu> Date: Wed, 22 Aug 2012 15:38:09 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: James Polk References: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> <6C0A8F8E-B79C-4F82-AECC-51FFA79ED6A1@acmepacket.com> <502AAE07.3020309@alum.mit.edu> <43ef3c20e7f1fb98a6a6d8758fb4a59c.squirrel@webmail.brianrosen.net> <502ABF1B.9020400@alum.mit.edu> <201208220005.q7M057iE008732@mtv-core-1.cisco.com> <55A5A9A87506CB4BA580BF9D531957DA69232F38@STNTEXCH01.cis.neustar.com> <201208221854.q7MIsuBv016403@mtv-core-3.cisco.com> In-Reply-To: <201208221854.q7MIsuBv016403@mtv-core-3.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Geolocation Header Question 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, 22 Aug 2012 19:38:00 -0000 On 8/22/12 2:54 PM, James Polk wrote: > At 02:15 AM 8/22/2012, Peterson, Jon wrote: > >> Um... why isn't sip:@domain valid? I see sip-uri as valid in the >> BNF, and that implies tel in the user portion. > > I'm basing my response on this from section 4.6 > > If a location URI is included in a SIP request, the sending user > agent MUST also include a Supported header field indicating which > location profiles it supports. Two option tags for location profiles > are defined by this document: "geolocation-sip" and "geolocation- > http". Future specifications MAY define further location profiles > per the IANA policy described in Section 8.3. > > The "geolocation-sip" option tag signals support for acquiring > location information via the presence event package of SIP [RFC3856]. > A location recipient who supports this option can send a SUBSCRIBE > request and parse a resulting NOTIFY containing a PIDF-LO object. > The URI schemes supported by this option include "sip", "sips", and > "pres". > > I haven't read that this > > Geolocation: ; user=phone This discussion is mixing up two related but different things: - a uri with a "tel:" scheme - a sip uri with phone number syntax in the user part and a ";user=phone" parameter. I guess this header doesn't all use of the tel: scheme, so that is off the table unless it is changed. A sip uri with ";user=phone" is still a sip uri. The syntax you show above isn't right, because the parameter should be inside the <>. E.g. Geolocation: So *syntactically* it should be fine to do this. But then there are still the options to deal with. I assume geolocation-sip would apply here (since its hard to do a GET on a sip uri.) So that says the specified sip uri should be suitable for doing a subscribe for presence. What I argued earlier is that IMO it might be ok in this case for the dereferencer to *try* some other proprietary mechanism, , and then fall back to subscription if that fails. > will be subscribed to and expect to receive a PIDF-LO, which the RFC > says earlier is the only location value format that's specified as > acceptable. > > I may have missed something in the discussion, but that's why I don't > think the scenario is depicting what RFC 6442 is specifying. > Additionally, and I just may not know this - as I'm not an expert on > , but I haven't ever heard of someone wanting to SUBSCRIBE to > a . But again, I could be underinformed on this one. Well, technically its ok to send a SUBSCRIBE with a tel: R-URI. That will be ok as long as it can be routed through the sip network. If it gets to a PSTN gateway its hard to say what will happen. Probably most gateways will have no idea what to do with a subscribe for presence. My *impression* when I first saw this mentioned was that the intent was that the tel: URI would override geolocation-sip, and be an implicit indication to some telephony-specific mechanism. But that was just my guess. Thanks, Paul > James > > >> Jon Peterson >> NeuStar, Inc. >> ________________________________________ >> From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of >> James Polk [jmpolk@cisco.com] >> Sent: Tuesday, August 21, 2012 5:05 PM >> To: Paul Kyzivat; Brian Rosen >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Geolocation Header Question >> >> At 04:11 PM 8/14/2012, Paul Kyzivat wrote: >> >On 8/14/12 5:04 PM, Brian Rosen wrote: >> >>Yes, agree, but probably not relevant to the discussion. >> >> >> >>I went back and looked at the original email, and decided I either >> don't >> >>understand something, or there is some larger problem. >> >> >> >>Between what two elements is this Geolocation header running? >> >> >> >>UAS to proxy server (UE to E-CSCF)? Proxy to gateway (E-CSCF to MGCF)? >> >> >> >>Regardless, it seems to be misusing the header, because it's not a >> sip or >> >>http LbyR. >> >>Better to get a real scheme somehow that does the right thing, use a >> >>parameter in another header, or create a new header. Depends on >> what this >> >>actually represents. It sounds like it really is LbyR, and you want to >> >>communicate a key.:@domain is appropriate. The issue is >> >>what is the right scheme? It's not sip - it's not sip presence. >> It's not >> >>HELD identity I take it. >> > >> >As I already stated, I think sip: is ok if this special lookup can >> >be viewed as an *optimization* over doing the presence lookup, and >> >doing it the presence way still works. >> > >> >Otherwise I agree with Brian. >> >> isn't an allowed URI in RFC 6442, neither is the use=phone >> tag, so IMO that makes this offering a no go as far as 'being in line >> with an IETF standards track RFC' (to be formal about it). >> >> James >> >> >> > Thanks, >> > Paul >> > >> >>Brian >> >> >> >>>I already commented to the original question. >> >>>Here I'm just commenting on the comments. >> >>> >> >>>On 8/14/12 1:55 PM, Brian Rosen wrote: >> >>>>I don't think so. >> >>>> >> >>>>A geolocation header with a sip uri has to lead to a presence server >> >>>>that >> >>>>can respond to a presence subscription which would return a PIDF with >> >>>>location. >> >>>> >> >>>>Routing a tel uri (which user=phone is supposed to be interchangeable >> >>>>with) to a presence service usually makes no sense. I don't think >> you >> >>>>can >> >>>>send a SUBSCRIBE to a tel uri. If you could, user=phone is okay. If >> >>>>you >> >>>>can't, user=phone is not okay. >> >>> >> >>>I disagree that a tel uri is *equivalent* to a sip URI with >> user=phone! >> >>> >> >>>A sip URI with user=phone is supposed to be routed like any other sip >> >>>URI until it reaches a server responsible for the domain of the URI. >> >>>*Then* the user part is to be interpreted as representing a phone >> number. >> >>> >> >>>Conversely, a tel URI has no domain. (And no user=phone.) The >> semantics >> >>>of telephone numbers are public knowledge. So any server can decide >> >>>where to route it next, based on the number and whatever other context >> >>>it has. >> >>> >> >>>IMO the distinction is important. If you want to enable anybody to >> >>>decide how to reach the phone number (including going through a PSTN >> >>>GW), then use a tel URI. If you want the call handled via SIP at least >> >>>until it reaches a particular domain, then use a sip URI. >> >>> >> >>> Thanks, >> >>> Paul >> >>> >> >>>>It's perfectly reasonable to make the uri >> >>>>sip:+358222222222@presence.example.com >> >>>>that is, a real domain, and no user=phone >> >>>> >> >>>>Brian >> >>>>> >> >>>>>You could do this: >> >>>>>Geolocation: >> >>>>>(although why ATIS would be defining how calls from Finland work is >> >>>>>beyond >> >>>>>me ;) >> >>>>> >> >>>>>But I don't understand why they need it in a Geoloc header to begin >> >>>>>with. >> >>>>>I assumed that header was for devices/networks that use its >> mechanisms >> >>>>>(ie, HELD, SUB, pidf). They're not going to do that, so why use >> that >> >>>>>header? >> >>>>> >> >>>>>You said they're doing the location lookup on the PSTN side - >> >>>>>presumably >> >>>>>then the location is being looked up based on the calling party >> info, >> >>>>>which should be in another existing header. Can't they use one >> of them >> >>>>>as >> >>>>>the query key for the lookup? (we have plenty to choose from for >> that >> >>>>>already :) >> >>>>> >> >>>>>-hadriel >> >>>>> >> >>>>> >> >>>>>On Aug 7, 2012, at 11:31 AM, Hannes Tschofenig wrote: >> >>>>> >> >>>>>>I agree but the tel URI is not one of the supported location >> URIs in >> >>>>>>RFC >> >>>>>>6442. >> >>>>>>Hence, the guys just use a different way to convey the same >> >>>>>>information. >> >>>>>> >> >>>>>>On Aug 7, 2012, at 5:52 PM, Worley, Dale R (Dale) wrote: >> >>>>>> >> >>>>>>>>From: Hannes Tschofenig [hannes.tschofenig@gmx.net] >> >>>>>>>> >> >>>>>>>>In order to convey that phone number for a lookup they are >> thinking >> >>>>>>>>about using the Geolocation header in the following form: >> >>>>>>>>Geolocation:> >>>>>>> >> >>>>>>>Naively, I'd say that since the goal is to carry an E.164 >> number, a >> >>>>>>>tel: URI would be the ideal choice. >> >>>>>>> >> >>>>>>>Dale >> >>>>>> >> >>>>>>_______________________________________________ >> >>>>>>sipcore mailing list >> >>>>>>sipcore@ietf.org >> >>>>>>https://www.ietf.org/mailman/listinfo/sipcore >> >>>>> >> >>>>>_______________________________________________ >> >>>>>sipcore mailing list >> >>>>>sipcore@ietf.org >> >>>>>https://www.ietf.org/mailman/listinfo/sipcore >> >>>> >> >>>> >> >>>>_______________________________________________ >> >>>>sipcore mailing list >> >>>>sipcore@ietf.org >> >>>>https://www.ietf.org/mailman/listinfo/sipcore >> >>> >> >>>_______________________________________________ >> >>>sipcore mailing list >> >>>sipcore@ietf.org >> >>>https://www.ietf.org/mailman/listinfo/sipcore >> >> >> >> >> > >> >_______________________________________________ >> >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 jmpolk@cisco.com Wed Aug 22 12:52:12 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE6E621F86AA for ; Wed, 22 Aug 2012 12:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.909 X-Spam-Level: X-Spam-Status: No, score=-109.909 tagged_above=-999 required=5 tests=[AWL=-0.510, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QO5QPM6ldzX4 for ; Wed, 22 Aug 2012 12:52:11 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 8E00221F85BB for ; Wed, 22 Aug 2012 12:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=10406; q=dns/txt; s=iport; t=1345665131; x=1346874731; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=IhAF4sJ0TVKCLqwd/Twd/W0xp2X5vu7hIiIWnTlzzNU=; b=mL8spddBFH8s4TFTbAvojoxvRaTFZw14fRXweJDEYbmhwvIXHP8IM2YW Dvy/hM8/c9JUGURo3qTXRxY7JgWVyQH0JK4rpEIm5o+1mJ+LegtvtivAg oNe7WVe81oshCx8QWyLXLzknYpNTxwSERxYH6jSPKyfJDAJooeiraGigQ Q=; X-IronPort-AV: E=Sophos;i="4.80,809,1344211200"; d="scan'208";a="55713910" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 22 Aug 2012 19:52:10 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8715.cisco.com [10.99.80.22]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q7MJq93D031087; Wed, 22 Aug 2012 19:52:10 GMT Message-Id: <201208221952.q7MJq93D031087@mtv-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 22 Aug 2012 14:52:07 -0500 To: Paul Kyzivat , James Polk From: James Polk In-Reply-To: <50353521.5060606@alum.mit.edu> References: <1BC647AD-539C-491D-BE9A-6B058B5B3BB3@gmx.net> <6C0A8F8E-B79C-4F82-AECC-51FFA79ED6A1@acmepacket.com> <502AAE07.3020309@alum.mit.edu> <43ef3c20e7f1fb98a6a6d8758fb4a59c.squirrel@webmail.brianrosen.net> <502ABF1B.9020400@alum.mit.edu> <201208220005.q7M057iE008732@mtv-core-1.cisco.com> <55A5A9A87506CB4BA580BF9D531957DA69232F38@STNTEXCH01.cis.neustar.com> <201208221854.q7MIsuBv016403@mtv-core-3.cisco.com> <50353521.5060606@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Geolocation Header Question 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, 22 Aug 2012 19:52:12 -0000 At 02:38 PM 8/22/2012, Paul Kyzivat wrote: >On 8/22/12 2:54 PM, James Polk wrote: >>At 02:15 AM 8/22/2012, Peterson, Jon wrote: >> >>>Um... why isn't sip:@domain valid? I see sip-uri as valid in the >>>BNF, and that implies tel in the user portion. >> >>I'm basing my response on this from section 4.6 >> >> If a location URI is included in a SIP request, the sending user >> agent MUST also include a Supported header field indicating which >> location profiles it supports. Two option tags for location profiles >> are defined by this document: "geolocation-sip" and "geolocation- >> http". Future specifications MAY define further location profiles >> per the IANA policy described in Section 8.3. >> >> The "geolocation-sip" option tag signals support for acquiring >> location information via the presence event package of SIP [RFC3856]. >> A location recipient who supports this option can send a SUBSCRIBE >> request and parse a resulting NOTIFY containing a PIDF-LO object. >> The URI schemes supported by this option include "sip", "sips", and >> "pres". >> >>I haven't read that this >> >> Geolocation: ; user=phone > >This discussion is mixing up two related but different things: >- a uri with a "tel:" scheme >- a sip uri with phone number syntax in the user part > and a ";user=phone" parameter. > >I guess this header doesn't all use of the tel: scheme, so that is >off the table unless it is changed. > >A sip uri with ";user=phone" is still a sip uri. The syntax you show >above isn't right, because the parameter should be inside the <> sorry, I was writing quickly >. E.g. > > Geolocation: > >So *syntactically* it should be fine to do this. But then there are >still the options to deal with. I assume geolocation-sip would apply >here (since its hard to do a GET on a sip uri.) So that says the >specified sip uri should be suitable for doing a subscribe for presence. > >What I argued earlier is that IMO it might be ok in this case for >the dereferencer to *try* some other proprietary mechanism, , and >then fall back to subscription if that fails. > >>will be subscribed to and expect to receive a PIDF-LO, which the RFC >>says earlier is the only location value format that's specified as >>acceptable. >> >>I may have missed something in the discussion, but that's why I don't >>think the scenario is depicting what RFC 6442 is specifying. >>Additionally, and I just may not know this - as I'm not an expert on >>, but I haven't ever heard of someone wanting to SUBSCRIBE to >>a . But again, I could be underinformed on this one. > >Well, technically its ok to send a SUBSCRIBE with a tel: R-URI. That >will be ok as long as it can be routed through the sip network. If >it gets to a PSTN gateway its hard to say what will happen. Probably >most gateways will have no idea what to do with a subscribe for presence. That's my impression of this scenario also, unless the something within the or URI *doesn't* point that SUBSCRIBE request at the gateway, but rather to another presence server that can give out the PIDF-LO for that phone number. I'm just guessing here too. But at that point, why not use a URI that points to the location record contained on that server? James >My *impression* when I first saw this mentioned was that the intent >was that the tel: URI would override geolocation-sip, and be an >implicit indication to some telephony-specific mechanism. But that >was just my guess. > > Thanks, > Paul > >>James >> >> >>>Jon Peterson >>>NeuStar, Inc. >>>________________________________________ >>>From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of >>>James Polk [jmpolk@cisco.com] >>>Sent: Tuesday, August 21, 2012 5:05 PM >>>To: Paul Kyzivat; Brian Rosen >>>Cc: sipcore@ietf.org >>>Subject: Re: [sipcore] Geolocation Header Question >>> >>>At 04:11 PM 8/14/2012, Paul Kyzivat wrote: >>> >On 8/14/12 5:04 PM, Brian Rosen wrote: >>> >>Yes, agree, but probably not relevant to the discussion. >>> >> >>> >>I went back and looked at the original email, and decided I either >>>don't >>> >>understand something, or there is some larger problem. >>> >> >>> >>Between what two elements is this Geolocation header running? >>> >> >>> >>UAS to proxy server (UE to E-CSCF)? Proxy to gateway (E-CSCF to MGCF)? >>> >> >>> >>Regardless, it seems to be misusing the header, because it's not a >>>sip or >>> >>http LbyR. >>> >>Better to get a real scheme somehow that does the right thing, use a >>> >>parameter in another header, or create a new header. Depends on >>>what this >>> >>actually represents. It sounds like it really is LbyR, and you want to >>> >>communicate a key.:@domain is appropriate. The issue is >>> >>what is the right scheme? It's not sip - it's not sip presence. >>>It's not >>> >>HELD identity I take it. >>> > >>> >As I already stated, I think sip: is ok if this special lookup can >>> >be viewed as an *optimization* over doing the presence lookup, and >>> >doing it the presence way still works. >>> > >>> >Otherwise I agree with Brian. >>> >>> isn't an allowed URI in RFC 6442, neither is the use=phone >>>tag, so IMO that makes this offering a no go as far as 'being in line >>>with an IETF standards track RFC' (to be formal about it). >>> >>>James >>> >>> >>> > Thanks, >>> > Paul >>> > >>> >>Brian >>> >> >>> >>>I already commented to the original question. >>> >>>Here I'm just commenting on the comments. >>> >>> >>> >>>On 8/14/12 1:55 PM, Brian Rosen wrote: >>> >>>>I don't think so. >>> >>>> >>> >>>>A geolocation header with a sip uri has to lead to a presence server >>> >>>>that >>> >>>>can respond to a presence subscription which would return a PIDF with >>> >>>>location. >>> >>>> >>> >>>>Routing a tel uri (which user=phone is supposed to be interchangeable >>> >>>>with) to a presence service usually makes no sense. I don't think >>>you >>> >>>>can >>> >>>>send a SUBSCRIBE to a tel uri. If you could, user=phone is okay. If >>> >>>>you >>> >>>>can't, user=phone is not okay. >>> >>> >>> >>>I disagree that a tel uri is *equivalent* to a sip URI with >>>user=phone! >>> >>> >>> >>>A sip URI with user=phone is supposed to be routed like any other sip >>> >>>URI until it reaches a server responsible for the domain of the URI. >>> >>>*Then* the user part is to be interpreted as representing a phone >>>number. >>> >>> >>> >>>Conversely, a tel URI has no domain. (And no user=phone.) The >>>semantics >>> >>>of telephone numbers are public knowledge. So any server can decide >>> >>>where to route it next, based on the number and whatever other context >>> >>>it has. >>> >>> >>> >>>IMO the distinction is important. If you want to enable anybody to >>> >>>decide how to reach the phone number (including going through a PSTN >>> >>>GW), then use a tel URI. If you want the call handled via SIP at least >>> >>>until it reaches a particular domain, then use a sip URI. >>> >>> >>> >>> Thanks, >>> >>> Paul >>> >>> >>> >>>>It's perfectly reasonable to make the uri >>> >>>>sip:+358222222222@presence.example.com >>> >>>>that is, a real domain, and no user=phone >>> >>>> >>> >>>>Brian >>> >>>>> >>> >>>>>You could do this: >>> >>>>>Geolocation: >>> >>>>>(although why ATIS would be defining how calls from Finland work is >>> >>>>>beyond >>> >>>>>me ;) >>> >>>>> >>> >>>>>But I don't understand why they need it in a Geoloc header to begin >>> >>>>>with. >>> >>>>>I assumed that header was for devices/networks that use its >>>mechanisms >>> >>>>>(ie, HELD, SUB, pidf). They're not going to do that, so why use >>>that >>> >>>>>header? >>> >>>>> >>> >>>>>You said they're doing the location lookup on the PSTN side - >>> >>>>>presumably >>> >>>>>then the location is being looked up based on the calling party >>>info, >>> >>>>>which should be in another existing header. Can't they use one >>>of them >>> >>>>>as >>> >>>>>the query key for the lookup? (we have plenty to choose from for >>>that >>> >>>>>already :) >>> >>>>> >>> >>>>>-hadriel >>> >>>>> >>> >>>>> >>> >>>>>On Aug 7, 2012, at 11:31 AM, Hannes Tschofenig wrote: >>> >>>>> >>> >>>>>>I agree but the tel URI is not one of the supported location >>>URIs in >>> >>>>>>RFC >>> >>>>>>6442. >>> >>>>>>Hence, the guys just use a different way to convey the same >>> >>>>>>information. >>> >>>>>> >>> >>>>>>On Aug 7, 2012, at 5:52 PM, Worley, Dale R (Dale) wrote: >>> >>>>>> >>> >>>>>>>>From: Hannes Tschofenig [hannes.tschofenig@gmx.net] >>> >>>>>>>> >>> >>>>>>>>In order to convey that phone number for a lookup they are >>>thinking >>> >>>>>>>>about using the Geolocation header in the following form: >>> >>>>>>>>Geolocation:>> >>>>>>> >>> >>>>>>>Naively, I'd say that since the goal is to carry an E.164 >>>number, a >>> >>>>>>>tel: URI would be the ideal choice. >>> >>>>>>> >>> >>>>>>>Dale >>> >>>>>> >>> >>>>>>_______________________________________________ >>> >>>>>>sipcore mailing list >>> >>>>>>sipcore@ietf.org >>> >>>>>>https://www.ietf.org/mailman/listinfo/sipcore >>> >>>>> >>> >>>>>_______________________________________________ >>> >>>>>sipcore mailing list >>> >>>>>sipcore@ietf.org >>> >>>>>https://www.ietf.org/mailman/listinfo/sipcore >>> >>>> >>> >>>> >>> >>>>_______________________________________________ >>> >>>>sipcore mailing list >>> >>>>sipcore@ietf.org >>> >>>>https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >>> >>>_______________________________________________ >>> >>>sipcore mailing list >>> >>>sipcore@ietf.org >>> >>>https://www.ietf.org/mailman/listinfo/sipcore >>> >> >>> >> >>> > >>> >_______________________________________________ >>> >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 rjsparks@nostrum.com Wed Aug 22 14:01:05 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D9621F86DE for ; Wed, 22 Aug 2012 14:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vp1FFuETaVIn for ; Wed, 22 Aug 2012 14:01:03 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 662F221F86EC for ; Wed, 22 Aug 2012 14:01:03 -0700 (PDT) Received: from unnumerable.local (pool-173-57-102-202.dllstx.fios.verizon.net [173.57.102.202]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7ML0v2x010080 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 22 Aug 2012 16:00:57 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <50354889.4020009@nostrum.com> Date: Wed, 22 Aug 2012 16:00:57 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05853409FBF33A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FBF33A@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.57.102.202 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" , "draft-ietf-sipcore-proxy-feature@tools.ietf.org" Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues 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, 22 Aug 2012 21:01:05 -0000 Hi Christer - This all looks good to me (except for a further comment on the Security Considerations section inline). On 8/22/12 7:09 AM, Christer Holmberg wrote: > Hi Robert, > > This reply addresses your comment regarding the IANA registration template/procedure, and the major issues. > >> Summary: There are a few issues to address before progressing to IETF LC. I'm putting the document into revised ID needed to address at least the IANA points below. >> >> The primary issue is with the instructions to IANA on creating the new trees and the registration template used to put things in those trees. >> >> Sections 7.3.2 and 7.3.3 don't currently define the format of an entry in the trees in the new subregistry. This needs to be clearly defined, and the sections need to explicitly indicate that the trees are initially empty. > I suggest to add the following text to the end of sections 7.3.2 and 7.3.3: > > "The format of the [global/SIP] tree is as described below: > > Decimal Name Description Reference > --------------------------------------------------- > > Decimal contains an integer value, incremented by IANA every time a new feature capability indicator is added to the table. > > Name contains the Feature Capability Indicator Name, provided in the registration feature capability indication registration template. > > Description contains the Abstract, provided in the registration feature capability indication registration template. > > Reference contains the Feature Capability Indicator Specification Reference, provided in the registration feature capability indication registration template." > > ---------------- > >> The template in section 8 was adapted from RFC2506, but it needs more tweaks and it needs to match whatever format is defined above. >> >> * We don't need a separate list for reviewing these requests. We certainly don't need a list at apps.ietf.org. The normal process for submitting a request for the global tree should be submitting the template by email to iana@iana.org, and for the sip >> tree, the normal process would be submitting an Internet-Draft to the IESG. > I suggest the following change: > > OLD: > > "To: sip-feature-capability-indicators@apps.ietf.org > (feature capability indicators mailing list) > Subject: Registration of feature capability indicator XXXX" > > NEW: > > "Registration requests for the global tree are submitted by e-mail to iana@iana.org. > Registration requests for the sip tree requires submitting an Internet-Draft to the IESG." > > ---------------- > >> * IANA is currently using a different for media feature tag registrations. It's available at . If we really need to follow that registration format, please start from this template. But do we >> need all this information in the registry? > I did start from the media feature tag template, and then removed stuff :) > > However, I do agree that not all of the remaining stuff needs to be in the template. Unlike media feature tags, we do mandate a reference to a specification for feature capability indicators, so whatever information that IANA doesn't need can be put in that specification. > > So, my suggestion would be that the registration template would look like this: > > > "| Instructions are preceded by '|'. All fields are mandatory. > > Feature capability indicator name: > > Description: > > | The description should be no longer than 4 lines. More > | detailed information can be provided in the feature > | capability indicator specification. > > Feature capability indicator name: > > | The referenced specification MUST contain the information > | listed in Section 5.3 of XXXX (IANA: Replace XXXX with > | assigned RFC number of this specification. > > Contact: > > | Name(s) & email address(es) of person(s) to > | contact for further information." > > > The following information would be in the feature capability indication specification: > > > 5.3. Feature Capability Indicator Specification Requirements > > 5.3.1. General > > A feature capability indicator specification MUST address the issues > defined in the following subsections, or document why an issue is not > applicable for the specific feature capability indicator. A > reference to the specification MUST be provided when the feature > capability indicator is registered with IANA (see Section 8). > > It is bad practice for feature capability indicator specifications to > repeat procedures (e.g. general procedures on the usage of the > Feature-Caps header field and feature capability indicators) defined > in this specification, unless needed for clarification or emphasis > purpose. A feature capability indicator specification MUST NOT > modify the Feature-Caps header field rules and semantics defined in > Section 4. > > A feature capability indicator specification MUST NOT weaken any > behavior designated with "SHOULD" or "MUST" in this specification. > However, a specification MAY strengthen "SHOULD", "MAY", or > "RECOMMENDED" requirements to "MUST" strength if features and > capabilities associated with the SIP feature capability indicator > > 5.3.2. Overall Description > > The feature capability indicator specification MUST contain an > overall description of the feature capability indicator: how it is > used to indicate support of a feature, a description of the feature > associated with the SIP feature cap, a description of any additional > information (conveyed using one or more feature capability indicator > values) that can be conveyed together with the feature capability > indicator, and a description of how the associated feature may be > exercised/invoked. > > 5.3.3. Feature Capability Indicator Values > > A feature capability indicator can have an associated value, or a > list of values. > > The feature capability indicator specification MUST define the syntax > and semantics of any value defined for the feature capability > indicator, including possible restrictions related to the usage of a > specific value. The feature capability indicator specification MUST > define the value(s) in accordance with the ABNF defined in Section > 6.3.2. The feature capability indicator specification MUST define > the default value, if applicable. > > If not values are defined for the feature capability indicator, it MUST > be indicated in the feature capability indicator specification. > > A feature capability indicator value is only applicable for the > feature capability indicator for which it has been defined. For > other feature capability indicators, the value has to be defined > explicitly, even if the semantics are identical. > > It is strongly RECOMMENDED to not re-use a value that already has > been defined for another feature capability indicator, unless the > semantics of the values are the same. > > 5.3.4. Usage Restrictions > > If there are restrictions on how SIP entities can insert a feature > capability indicator, the feature capability indicator specification MUST > document such restrictions. > > There might be restrictions related to whether entities are allowed > to insert a feature capability indicator in registration related > messages, standalone transaction messages, or dialog related > messages, whether entities are allowed to insert a feature capability > indicator in requests or responses, whether entities also need to > support other features and capabilities in order to insert a feature > capability indicator, and whether entities are allowed to indicate > support of a feature in conjunction with another feature. > > 5.3.5. Interoperability Considerations > > If there are specific interoperability considerations that apply to the > feature capability indicator, the feature capability indicator specification > MUST document such considerations. > > 5.3.6. Security Considerations > > If there are specific security considerations that apply to the feature > capability indicator, the feature capability indicator specification > MUST document such considerations. > > 5.3.7. Examples > > It is RECOMMENDED that the feature capability indicator specification > provide demonstrative message flow diagrams, paired with complete > messages and message descriptions. > > Note that example message flows are by definition informative, and do > not replace normative text. > > 5.3.8. Other Information > > If there is additional information about the feature capability indicator, > it is RECOMMENDED to describe such information. It can include e.g. > names of related feature capability indicators." > > > > Other major issues: > ----------------------------------------- > >> 1) Should the expert reviewer be explicitly required to consider security issues as part of that review? (see section 4.6 of >> for example). > Per my suggestion above, about moving 'Security considerations' from the template into the feature capability indicator specification, I guess the expert reviewer would also look at the Security Considerations. I don't think we need to explicitly say anything. > > ---------------- > >> 2) The security considerations section claims that the aspects of the considerations in rfc3840 that apply to end user devices don't apply here since these are not typically used to convey information about end user devices. "Not typically" is weak. Can this > sentence be made more specific about what concerns do and don't apply? The concerns in 3840 about influencing application behavior, and in 2506 about providing information that can be used to exploit implementation weakeness at the elements that > do provide these tags should be reflected here. > I suggest some additional security considerations text: > > "9. Security Considerations > > The security issues for feature capability indicators are similar to > the ones defined in RFC 3840 for media feature tags. Media > feature tags can reveal information about end-users and end-user > equipment, which can be used for industrial espionage. The knowledge > about end-user equipment capabilities can also be used to influence > application behavior. As feature capability indicators are not intended > to convey capability information of end-user devices, such end-user > security aspects of RFC 3840 do not apply to feature capability indicators. But they are conveying the capability information for intermediaries, and the concerns about exploiting knowing about what features that intermediary supports, particularly exploiting known implementation weaknesses in the implementation of that feature do apply. > > In addition, the RFC 3840 security issue regarding an attacker using > the SIP caller preferences extension [RFC3841] in order to affect > routing decisions does not apply, as the mechanism is not defined to > be used with feature capability indicators. > > Feature capability indicators can, however, provide capability and > characteristics information about the SIP entity, some of which might > be sensitive. The Feature- Caps header field does not convey address > information about SIP entities. However, individual feature capability > indicators might provide address information as feature capability indicator > values. Therefore, mechanisms for guaranteeing confidentiality and > authenticity SHOULD be provided." > > ---------------- > >> 3) Consider clarifying the behavior of SUBSCRIBE NOTIFY dialogs in section 4.3.2. Only one of the 200 OKs to a forked SUBSCRIBE >> will get back to the UA that sent the subscribe. The information that creates the other dialogs for it must appear in the immediate >> NOTIFYs. Is there a requirement for the end accepting a subscription to use the same feature capabilities in the 200 OK to the subscription >> and in the immediate NOTIFY? > I suggest the following new note to section 4.3.2. > > "NOTE: As it cannot be guaranteed that 2xx responses associated with > SIP SUBSCRIBE requests will reach the UAC, due to forking of the request, > entities need to indicate supported features and capabilities in the SIP NOTIFY > request that will be sent for each of the created subscription dialogs." > > I don't think we need to mandate the capabilities in the 200 OK (if inserted in the first place) need to be identical to the NOTIFY. As the NOTIFY is a target refresh request, it is allowed to indicate different capabilities. > > ---------------- > >> 4) Similarly, consider clarifying whether UPDATES nested within an INVITE constrained to keep the same feature capability indicators as in the INVITE? > Again, as UPDATEs are target refresh requests (even when nested within an INVITE), they can indicate a new set of supported capabilities. > > Note that the indication of supported features is not "offer/answer" - the support is indicated independently in each direction. > > ---------------- > > Thanks! > > Regards, > > Christer From christer.holmberg@ericsson.com Wed Aug 22 14:09:17 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32B221F86DE for ; Wed, 22 Aug 2012 14:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.167 X-Spam-Level: X-Spam-Status: No, score=-6.167 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8gNekTMNU4iW for ; Wed, 22 Aug 2012 14:09:17 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 84C3121F86D4 for ; Wed, 22 Aug 2012 14:09:16 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-55-50354a7bfa21 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 78.AE.17130.B7A45305; Wed, 22 Aug 2012 23:09:15 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Wed, 22 Aug 2012 23:09:14 +0200 From: Christer Holmberg To: 'Robert Sparks' Date: Wed, 22 Aug 2012 23:09:13 +0200 Thread-Topic: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues Thread-Index: Ac2AqT1LrHRupvCTS82Pix7Q1s67yQAAIdEg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6F@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853409FBF33A@ESESSCMS0356.eemea.ericsson.se> <50354889.4020009@nostrum.com> In-Reply-To: <50354889.4020009@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+JvrW61l2mAQfsRFYu3/fMZLa7NaWSz +PpjE5sDs8eSJT+ZPGbtfMLi8eXyZ7YA5igum5TUnMyy1CJ9uwSujJXXt7MVtItW7Gl5w9jA eFegi5GTQ0LARGJX82RGCFtM4sK99WwgtpDAKUaJ1R0eXYxcQPYCRomzdxaydjFycLAJWEh0 /9MGqRER0JJ4f/sVM0gNs8AkRolPj+4xgSRYBFQl1r34CmYLC1RJNDV9YoNoqJb4/vUbM4Rt JDHt+Gl2EJtXIFzi8M02ZojFFRLPb0wCq+cU0JbYv+UQWJwR6Ljvp9aAzWQWEJe49WQ+E8TR AhJL9pxnhrBFJV4+/scKUS8qcad9PSNEvY7Egt0QNzADzVy28DUzxF5BiZMzn7BMYBSbhWTs LCQts5C0zELSsoCRZRWjcG5iZk56ublealFmcnFxfp5eceomRmA8Hdzy22AH46b7YocYpTlY lMR59VT3+wsJpCeWpGanphakFsUXleakFh9iZOLglGpg7K0qvtLuYhOis3hVV0cet1FDt8jU /JMy8X2J0xiSC5f+np13VEksn9Wi87xX0PWmZlOWGyei1GOjOw6vi8/TvKCiKuPCmOkn+5dv +eovzx2il+08x/Al41C0rtdBnS19OWFpx9JqTAqeue94dGXCZcODU5zeTrC6c8BFbteLqbem msctZFZUYinOSDTUYi4qTgQAwH9kvXUCAAA= Cc: "sipcore@ietf.org" , "draft-ietf-sipcore-proxy-feature@tools.ietf.org" Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues 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, 22 Aug 2012 21:09:17 -0000 =20 Hi, > This all looks good to me (except for a further comment on the Security C= onsiderations section inline). >>> 2) The security considerations section claims that the aspects of the c= onsiderations in rfc3840=20 >>> that apply to end user devices don't apply here since these are not typ= ically used to convey=20 >>> information about end user devices. "Not typically" is weak. Can this s= entence be made more=20 >>> specific about what concerns do and don't apply? The concerns in 3840 a= bout influencing application=20 >>> behavior, and in 2506 about providing information that can be used to e= xploit implementation weakeness=20 >>> at the elements that do provide these tags should be reflected here. >> I suggest some additional security considerations text: >> >> "9. Security Considerations >> >> The security issues for feature capability indicators are similar to >> the ones defined in RFC 3840 for media feature tags. Media >> feature tags can reveal information about end-users and end-user >> equipment, which can be used for industrial espionage. The knowledge >> about end-user equipment capabilities can also be used to influence >> application behavior. As feature capability indicators are not inten= ded >> to convey capability information of end-user devices, such end-user >> security aspects of RFC 3840 do not apply to feature capability in= dicators. >> > But they are conveying the capability information for intermediaries, and= the concerns about=20 > exploiting knowing about what features that intermediary supports, partic= ularly exploiting=20 > known implementation weaknesses in the implementation of that feature do = apply. I am trying to cover that in the 3rd paragraph (below). I guess I could move that text up, if it helps. >> In addition, the RFC 3840 security issue regarding an attacker using >> the SIP caller preferences extension [RFC3841] in order to affect >> routing decisions does not apply, as the mechanism is not defined to >> be used with feature capability indicators. >> >> Feature capability indicators can, however, provide capability and >> characteristics information about the SIP entity, some of which migh= t >> be sensitive. The Feature- Caps header field does not convey addres= s >> information about SIP entities. However, individual feature capabil= ity >> indicators might provide address information as feature capability i= ndicator >> values. Therefore, mechanisms for guaranteeing confidentiality and >> authenticity SHOULD be provided." Regards, Christer From rjsparks@nostrum.com Wed Aug 22 14:22:31 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1106221F86D9 for ; Wed, 22 Aug 2012 14:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.506 X-Spam-Level: X-Spam-Status: No, score=-102.506 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKRP67pLnSNs for ; Wed, 22 Aug 2012 14:22:30 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC1D21F86D6 for ; Wed, 22 Aug 2012 14:22:29 -0700 (PDT) Received: from unnumerable.local (pool-173-57-102-202.dllstx.fios.verizon.net [173.57.102.202]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7MLMQ4f012472 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 22 Aug 2012 16:22:26 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <50354D92.4080004@nostrum.com> Date: Wed, 22 Aug 2012 16:22:26 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05853409FBF33A@ESESSCMS0356.eemea.ericsson.se> <50354889.4020009@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6F@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6F@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.57.102.202 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" , "draft-ietf-sipcore-proxy-feature@tools.ietf.org" Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues 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, 22 Aug 2012 21:22:31 -0000 On 8/22/12 4:09 PM, Christer Holmberg wrote: > > Hi, > >> This all looks good to me (except for a further comment on the Security Considerations section inline). >>>> 2) The security considerations section claims that the aspects of the considerations in rfc3840 >>>> that apply to end user devices don't apply here since these are not typically used to convey >>>> information about end user devices. "Not typically" is weak. Can this sentence be made more >>>> specific about what concerns do and don't apply? The concerns in 3840 about influencing application >>>> behavior, and in 2506 about providing information that can be used to exploit implementation weakeness >>>> at the elements that do provide these tags should be reflected here. >>> I suggest some additional security considerations text: >>> >>> "9. Security Considerations >>> >>> The security issues for feature capability indicators are similar to >>> the ones defined in RFC 3840 for media feature tags. Media >>> feature tags can reveal information about end-users and end-user >>> equipment, which can be used for industrial espionage. The knowledge >>> about end-user equipment capabilities can also be used to influence >>> application behavior. As feature capability indicators are not intended >>> to convey capability information of end-user devices, such end-user >>> security aspects of RFC 3840 do not apply to feature capability indicators. >>> >> But they are conveying the capability information for intermediaries, and the concerns about >> exploiting knowing about what features that intermediary supports, particularly exploiting >> known implementation weaknesses in the implementation of that feature do apply. > I am trying to cover that in the 3rd paragraph (below). > > I guess I could move that text up, if it helps. I don't think "might be sensitive" raises the reader's level of awareness sufficiently. How about adding "Malicious elements viewing the indicators may be able to discern application deployment details or identify elements with exploitable feature implementation weaknesses." after that first sentence, leaving the paragraph where it is? > >>> In addition, the RFC 3840 security issue regarding an attacker using >>> the SIP caller preferences extension [RFC3841] in order to affect >>> routing decisions does not apply, as the mechanism is not defined to >>> be used with feature capability indicators. >>> >>> Feature capability indicators can, however, provide capability and >>> characteristics information about the SIP entity, some of which might >>> be sensitive. The Feature- Caps header field does not convey address >>> information about SIP entities. However, individual feature capability >>> indicators might provide address information as feature capability indicator >>> values. Therefore, mechanisms for guaranteeing confidentiality and >>> authenticity SHOULD be provided." > Regards, > > Christer From christer.holmberg@ericsson.com Wed Aug 22 23:04:19 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949FF21F84FA for ; Wed, 22 Aug 2012 23:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.168 X-Spam-Level: X-Spam-Status: No, score=-6.168 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loiGniEbTsco for ; Wed, 22 Aug 2012 23:04:19 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 80EE221F84F2 for ; Wed, 22 Aug 2012 23:04:18 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-b1-5035c7e0d1ce Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id C4.44.25676.0E7C5305; Thu, 23 Aug 2012 08:04:17 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Thu, 23 Aug 2012 08:04:16 +0200 From: Christer Holmberg To: Robert Sparks Date: Thu, 23 Aug 2012 08:04:16 +0200 Thread-Topic: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues Thread-Index: Ac2ArDwFLXt10dxrQRamicfJJQUlVQASAKDn Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EE9@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853409FBF33A@ESESSCMS0356.eemea.ericsson.se> <50354889.4020009@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A6F@ESESSCMS0356.eemea.ericsson.se>, <50354D92.4080004@nostrum.com> In-Reply-To: <50354D92.4080004@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+Jvre7D46YBBqevMFu87Z/PaHFtTiOb xdcfm9gcmD2WLPnJ5DFr5xMWjy+XP7MFMEdx2aSk5mSWpRbp2yVwZbT8X85a8Eu24uSyL+wN jI/Euxg5OSQETCR6js9ihLDFJC7cW8/WxcjFISRwilFix62brBDOAkaJq7cfAzkcHGwCFhLd /7RBGkQENCSuLVnCDlLDLDCJUeLTo3tMIAkWAVWJd1u2sYLYwgJVEk1Nn9ggGqolvn/9xgxh G0l8udoKZvMKhEv8uveFGWLZU0aJ7onTwAZxCmhLPL47Cew8RqDzvp9aAxZnFhCXuPVkPhPE 2QISS/acZ4awRSVePv7HClEvKnGnfT0jRL2OxILdEEcwA81ctvA11GJBiZMzn7BMYBSbhWTs LCQts5C0zELSsoCRZRWjcG5iZk56uZFealFmcnFxfp5eceomRmBMHdzyW3UH451zIocYpTlY lMR5rbfu8RcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuJQ/NDPxotver3GMJaH7zv73Etl7 QHBp+N3FjbNCwv7PzmqJD3G/pjkpev75SwcM712Z8He3+Ur1EJGuQ+8FTul1JT8PbpP4nhCz ZcnZNFHNdoHa+y+Sw2IXKmln/dr64YZkasakaNXmvV7xFw4ZLNHaOn/1ByNOK1exn4vbdjLx aPk/vnzkvBJLcUaioRZzUXEiAM6TZl13AgAA Cc: "sipcore@ietf.org" , "draft-ietf-sipcore-proxy-feature@tools.ietf.org" Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues 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, 23 Aug 2012 06:04:19 -0000 Hi, >>>>> 2) The security considerations section claims that the aspects of the= considerations in rfc3840 >>>>> that apply to end user devices don't apply here since these are not t= ypically used to convey >>>>> information about end user devices. "Not typically" is weak. Can this= sentence be made more >>>>> specific about what concerns do and don't apply? The concerns in 3840= about influencing application >>>>> behavior, and in 2506 about providing information that can be used to= exploit implementation weakeness >>>>> at the elements that do provide these tags should be reflected here. >>>> I suggest some additional security considerations text: >>>> >>>> "9. Security Considerations >>>> >>>> The security issues for feature capability indicators are similar= to >>>> the ones defined in RFC 3840 for media feature tags. Media >>>> feature tags can reveal information about end-users and end-user >>>> equipment, which can be used for industrial espionage. The knowle= dge >>>> about end-user equipment capabilities can also be used to influen= ce >>>> application behavior. As feature capability indicators are not in= tended >>>> to convey capability information of end-user devices, such end-u= ser >>>> security aspects of RFC 3840 do not apply to feature capability= indicators. >>>> >>> But they are conveying the capability information for intermediaries, a= nd the concerns about >>> exploiting knowing about what features that intermediary supports, part= icularly exploiting >>> known implementation weaknesses in the implementation of that feature d= o apply. >> I am trying to cover that in the 3rd paragraph (below). >> >> I guess I could move that text up, if it helps. > >I don't think "might be sensitive" raises the reader's level of awareness = sufficiently. > > How about adding "Malicious elements viewing the indicators may be able > to discern application deployment details or identify elements with explo= itable feature > implementation weaknesses." after that first sentence, leaving the paragr= aph where it is? Sounds good. So, something like: "9. Security Considerations The security issues for feature capability indicators are similar to the ones defined in RFC 3840 for media feature tags. Media feature tags can reveal information about end-users and end-user equipment, which can be used for industrial espionage. The knowledge about end-user equipment capabilities can also be used to influence application behavior. As feature capability indicators are not intende= d to convey capability information of end-user devices, such end-user security aspects of RFC 3840 do not apply to feature capability indi= cators. In addition, the RFC 3840 security issue regarding an attacker using the SIP caller preferences extension [RFC3841] in order to affect routing decisions does not apply, as the mechanism is not defined to be used with feature capability indicators. Feature capability indicators can, however, provide capability and characteristics information about the SIP entity, some of which might be sensitive. Malicious elements viewing the indicators may be able to discern application deployment details or identify elements with=20 exploitable feature implementation weaknesses. The Feature-Caps=20 header field does not convey address information about SIP entities. = =20 However, individual feature capability indicators might provide addres= s=20 information as feature capability indicator values. Therefore, mechani= sms=20 for guaranteeing confidentiality and authenticity SHOULD be provided." Regards, Christer= From christer.holmberg@ericsson.com Wed Aug 22 23:23:52 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C08121F845E for ; Wed, 22 Aug 2012 23:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.169 X-Spam-Level: X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POT6YBQ0yvvG for ; Wed, 22 Aug 2012 23:23:52 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2CC21F8467 for ; Wed, 22 Aug 2012 23:23:50 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-24-5035cc752e2c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 65.76.25676.57CC5305; Thu, 23 Aug 2012 08:23:50 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 23 Aug 2012 08:23:50 +0200 From: Christer Holmberg To: Robert Sparks , "sipcore@ietf.org" , "draft-ietf-sipcore-proxy-feature@tools.ietf.org" Date: Thu, 23 Aug 2012 08:21:12 +0200 Thread-Topic: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues Thread-Index: Ac2AXv93lTJjLkhVTEyk90Fi7o7g2wAmH7Zy Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2EEA@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05853409FBF33A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FBF33A@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvrW7ZGdMAgwWLeC3e9s9ntLg2p5HN 4uuPTWwOzB5Llvxk8pi18wmLx5fLn9kCmKO4bFJSczLLUov07RK4Mja2nWQp6OasWLJsKmsD 41G2LkZODgkBE4l7R89B2WISF+6tB7K5OIQETjFKzH3yGcqZwygxpX0vSxcjBwebgIVE9z9t kLiIwA5Gid+H5rGAdLMIqEp0fr4JZgsLVEk0NX0CmyoiUC3x/es3ZgjbSGLu4jeMIDavQLjE vuO7weqFgOzFjyeA1XAKREice/gJzGYEuuj7qTVMIDazgLjErSfzmSAuFZBYsuc8M4QtKvHy 8T9WiHpRiTvt6xkh6nUkFuyGuIFZQFti2cLXzBB7BSVOznzCMoFRdBaSsbOQtMxC0jILScsC RpZVjMK5iZk56eVGeqlFmcnFxfl5esWpmxiBkXNwy2/VHYx3zokcYpTmYFES57XeusdfSCA9 sSQ1OzW1ILUovqg0J7X4ECMTB6dUAyN7aUevqJJ60tQLFQ3rJIyPHSplM7FIfq0Y4dxYoVPv p3X7d1hcp3g982WHwqqE584Vi3o1DqzP2x3D1LX+0v7Vx3Tm2Mn/nK639cdsL50nnwWmbv/+ zKbl7x2Di9lpXV4W7SzcZXvW5z7dwd5YnBwxh9fh1Zmtt1fFXl7D2HHadcYXlZ6bD5RYijMS DbWYi4oTAepX7vNqAgAA Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-proxy-feature-05 - Robert's comments - IANA issues and major issues 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, 23 Aug 2012 06:23:52 -0000 Hi, >So, my suggestion would be that the registration template would look like = this: > > > "| Instructions are preceded by '|'. All fields are mandatory. > > Feature capability indicator name: > > Description: > > | The description should be no longer than 4 lines. More > | detailed information can be provided in the feature > | capability indicator specification. > > Feature capability indicator name: > > | The referenced specification MUST contain the information > | listed in Section 5.3 of XXXX (IANA: Replace XXXX with > | assigned RFC number of this specification. > > Contact: > > | Name(s) & email address(es) of person(s) to > | contact for further information." The fci specification reference will of course also be part of the template= : "Feature capability indicator specification reference: =20 | The referenced specification MUST contain the information=20 | listed in Section 5.3 of XXXX (IANA: Replace XXXX with=20 | assigned RFC number of this specification." Regards, Christer= From victor.pascual.avila@gmail.com Thu Aug 23 06:20:53 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF6E21F8594 for ; Thu, 23 Aug 2012 06:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zncxhBnJFT8O for ; Thu, 23 Aug 2012 06:20:52 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB03821F858F for ; Thu, 23 Aug 2012 06:20:52 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so1786091obb.31 for ; Thu, 23 Aug 2012 06:20:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=weEFNh7hZlix08cmMNU6bTTssApf6PctNdq+c3wlXBM=; b=wDigbwzSNdmCzyyZUa5JQSBVss5fFtaApvRAc73HBv0L6tDvzJjJwYWBYqdcw2Ld9D Jp8wupGZ46eynfpgUmZ9IAC48+/4RRqF4SToILnHhP4l1nkIIlOhkKirN7zkfd/cd4nV jHZxWc3P1mZZ8pseP/8XG2x5QxL6rJOHpjixy1MTuqiugUfawB1k1EOUVo6MgFpOiM8H PAZo6vfKOXHziPt05GQCaPVot3iXgI7AJ1pEPveXNRP+Iz/1XBPIzi9C0KBUPl/Nb5Qa R4b4sZ3kEavzYvllvcoFEYNKCuu9Gek2V222TmF/5MsNv+UV0/jAl774s2dFvXBAa5r8 kb+Q== MIME-Version: 1.0 Received: by 10.60.170.105 with SMTP id al9mr985009oec.136.1345728052358; Thu, 23 Aug 2012 06:20:52 -0700 (PDT) Received: by 10.60.69.104 with HTTP; Thu, 23 Aug 2012 06:20:52 -0700 (PDT) Date: Thu, 23 Aug 2012 15:20:52 +0200 Message-ID: From: Victor Pascual Avila To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Cc: sipcore@ietf.org Subject: [sipcore] requirement to support TCP and UDP transports (was Re: WGLC: draft-ietf-sipcore-sip-websocket-02) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 13:20:53 -0000 On Sat, Aug 11, 2012 at 1:20 AM, Paul Kyzivat wrote: > In addition to this issue, there is the one about the current 3261 > requirement to support TCP and UDP transports, which many implementations of > this draft will have difficulty complying with. This transport can be implemented also on User Agents other than web browsers (e.g. smartphones). What would be your suggestion, relax the "MUST implement UDP and TCP" requirement (1)only for web browsers, (2)for any device implementing the websockets transport, (3)in general? Cheers, -Victor From partha@parthasarathi.co.in Thu Aug 23 05:53:31 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 205AB21F852D for ; Thu, 23 Aug 2012 05:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.336 X-Spam-Level: X-Spam-Status: No, score=0.336 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5XJaQfhhD2fG for ; Thu, 23 Aug 2012 05:53:30 -0700 (PDT) Received: from outbound-us2.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.237]) by ietfa.amsl.com (Postfix) with ESMTP id 3C72621F8528 for ; Thu, 23 Aug 2012 05:53:30 -0700 (PDT) Received: from userPC (unknown [122.179.54.188]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us2.mailhostbox.com (Postfix) with ESMTPA id 9E27F3E26A0 for ; Thu, 23 Aug 2012 12:53:23 +0000 (GMT) From: "Parthasarathi R" To: Date: Thu, 23 Aug 2012 18:23:18 +0530 Message-ID: <000d01cd812e$46bb4850$d431d8f0$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01CD815C.60738450" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2BLkRsdkJeYB9EQ6ujSEE8c7ovIQ== Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0201.503627C5.0197, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Subject: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 13:21:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000E_01CD815C.60738450 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, As I discussed during IETF-84 meeting, the following text is provided for the starting the discussion on deviation of RFC 3261 mandatory to implement (UDP/TCP) transport in this draft. "In case SIP WebSocket Client is a web browser and SIP Websocket Server is a SIP proxy, then record-route header MUST be included by SIP Websocket server in all SIP messages. This requirement assures that SIP WebSocket Client is able to contact with UAS through SIP Websocket Server during the mid-dialog irrespective of the contact SIP URI received from UAS " The above normative statement will be update to RFC 3261. Thanks Partha ------=_NextPart_000_000E_01CD815C.60738450 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

As I discussed during IETF-84 meeting,  the following text is provided = for the starting the discussion on deviation of RFC 3261 mandatory to = implement (UDP/TCP) transport in this draft.

 

“In case SIP WebSocket Client is a web browser and SIP Websocket Server is a = SIP proxy, then record-route header MUST be included by SIP Websocket server = in all SIP messages. This requirement assures that SIP WebSocket Client is able = to contact with UAS through SIP Websocket Server during the mid-dialog = irrespective of the contact SIP URI received from UAS ”

 

The above normative statement will be update to  RFC = 3261.

 

Thanks

Partha

------=_NextPart_000_000E_01CD815C.60738450-- From jmillan@aliax.net Thu Aug 23 09:15:51 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E6821F85AA for ; Thu, 23 Aug 2012 09:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn01vw5KISwr for ; Thu, 23 Aug 2012 09:15:51 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7770421F85A3 for ; Thu, 23 Aug 2012 09:15:50 -0700 (PDT) Received: by lahm15 with SMTP id m15so583172lah.31 for ; Thu, 23 Aug 2012 09:15:49 -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=yqA/FBdHOEYGBsf3wRZ1XsHh8JT4yXDtxmYtg1MzV8o=; b=A7/5W3hmDoAQQwh2cdJhkRmx35FUNKL1MttKSDYvB7ACRfQ06a32gDbSe+N0UmD3R2 /zWrY6LfU1A6IxQBGfr9knII9y+F+8/CS36e++1YLX+jvWrUi/Ugdqy53LtS1lHGIqq5 K3aIWMXXrXKEHSQetHj2h0RaqL8ycnL5iLsmXlDOGI+6vHKW+8KGUbCvuhrdrRrn/J5T +k9QO1sO5dUJT1eVXUtlfPPvcf103+lsWlsOp/A/n7AZ3WHyFMOGLuWOQOJPRlDayFw8 SUGEC1NLj3aAkTTzBb/yCKef6wvtb5jEIrcNvBUbbrLwxh7LvlI3KYmaTWzyyXufcLfI U98g== MIME-Version: 1.0 Received: by 10.112.27.226 with SMTP id w2mr1173468lbg.57.1345738549359; Thu, 23 Aug 2012 09:15:49 -0700 (PDT) Received: by 10.112.94.33 with HTTP; Thu, 23 Aug 2012 09:15:49 -0700 (PDT) In-Reply-To: <000d01cd812e$46bb4850$d431d8f0$@co.in> References: <000d01cd812e$46bb4850$d431d8f0$@co.in> Date: Thu, 23 Aug 2012 18:15:49 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: Parthasarathi R Content-Type: multipart/alternative; boundary=bcaec554de6231f59a04c7f12c9e X-Gm-Message-State: ALoCoQmjuev8NO2ghtfxAL6/xwLYPi+NwxsMtStXMhf8Xv0MqWq9OStgSwIZFYf+VxVcnPxURuWH Cc: sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2012 16:15:51 -0000 --bcaec554de6231f59a04c7f12c9e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, 2012/8/23 Parthasarathi R > Hi all,**** > > ** ** > > As I discussed during IETF-84 meeting, the following text is provided fo= r > the starting the discussion on deviation of RFC 3261 mandatory to impleme= nt > (UDP/TCP) transport in this draft. **** > > ** ** > > =93In case SIP WebSocket Client is a web browser and SIP Websocket Server= is > a SIP proxy, then record-route header MUST be included by SIP Websocket > server in all SIP messages. This requirement assures that SIP WebSocket > Client is able to contact with UAS through SIP Websocket Server during th= e > mid-dialog irrespective of the contact SIP URI received from UAS =94 > Record-Route header field is useful for a proxy in order to remain in the dialog path. It is not necessary for all SIP messages. This is defined in RFC 3261 as 'loose routing' and draft-ibc-sipcore-sip-websocket-02 does not change it at all. Section 2 of Apendix A (Implementation guidelines) already mentions it: " The proxy performs Loose Routing and remains in dialogs path as specified in [RFC3261 ]. Otherwise in-dialog requests would fail since SIP WebSocket Clients make use of their SIP WebSocket Server in order to send and receive SIP requests and responses. " Regards, > ** > > The above normative statement will be update to RFC 3261.**** > > ** ** > > Thanks**** > > Partha**** > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --bcaec554de6231f59a04c7f12c9e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,

2012/8/23 Parthasarathi R <partha@parthasarathi.co.in<= /a>>

Hi all,

=A0

As I discussed during IETF-84 meeting, =A0the following text is provided for the starting the discussion on deviation of RFC 3261 mandatory to implement= (UDP/TCP) transport in this draft.

=A0

=93In case SIP WebSocket Client is a web browser and SIP Websocket Server is a SI= P proxy, then record-route header MUST be included by SIP Websocket server in= all SIP messages. This requirement assures that SIP WebSocket Client is able to contact with UAS through SIP Websocket Server during the mid-dialog irrespe= ctive of the contact SIP URI received from UAS =94


Record-Route header field is useful for a proxy in= order to remain in the dialog path. It is not necessary for all SIP messag= es.=A0This is defined in RFC 3261 as 'loose routing' and=A0draft-ib= c-sipcore-sip-websocket-02 does not change it at all.

Section 2 of Apendix A (Implementation guidelines) alre= ady=A0mentions=A0it:

"
=A0The proxy performs Loose Routing and r= emains in dialogs path as
   specified in [RFC3261].  Otherwise in-dialog requests would fail
   since SIP WebSocket Clients make use of their SIP WebSocket Server in
   order to send and receive SIP requests and responses.

"


Regards,

=A0

The above normative statement will be update to=A0 RFC 3261.

=A0

Thanks

Partha


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


--bcaec554de6231f59a04c7f12c9e-- From dwsauder@dsauder.com Thu Aug 23 17:54:21 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B527C21F863B for ; Thu, 23 Aug 2012 17:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbggkMF34y7o for ; Thu, 23 Aug 2012 17:54:21 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0371821F8624 for ; Thu, 23 Aug 2012 17:54:21 -0700 (PDT) Received: from destiny.local (99-37-203-241.lightspeed.dllstx.sbcglobal.net [99.37.203.241]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M71Cv-1Tq45P2Yp3-00wiiC; Thu, 23 Aug 2012 20:54:19 -0400 Message-ID: <5036D0B9.1050502@dsauder.com> Date: Thu, 23 Aug 2012 19:54:17 -0500 From: Doug Sauder User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <50255530.1020208@nostrum.com> In-Reply-To: <50255530.1020208@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:oBbH4yELVIAGT+bd9uAWx8HLFW/tfmhtHcnbckgYWYJ e9FD8JXkIIgMEv1HkMzJHyH0PTZRulONpSE4cLw3RZv8Ze6uwV P05jba3DFGEBBzRbrvWixy4XH85AuIxsOwrMv82kUEp1m7+CwE AhILZYWOccadLlZDrQhwjgqqoIfbsAMoUekkIPppY8B35oCD/f BKW6HRC2CIun9TxnN8O5abkUOH+4AmzvQXXkE/ENg0HPdpU7Xc 6w57dvPOOoAZOYae1BXBytxuiqha32nxSsVh/MjxPPmjcWr6xr rgluysImEGJAES2gVtfUgYjYl5wRwBc7ZFIe3s0LRNVmzCk+1t uVR6P7n4KUIt7T7cIftQ= Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 00:54:21 -0000 I think this document is well written overall and I have no comments other than one nit. Referring to page 18, the paragraph that begins "If a REFER request is sent to a third SIP user agent ..." -- I think this paragraph should be rewritten. The first sentence, being in passive voice, does not provide a clue as to who sends the REFER. Also, it's not clear who "a third SIP user agent" is supposed to be, and it seems to imply there is a "first SIP user agent" and a "second SIP user agent" (who are not identified). I found this paragraph to be confusing. -- Doug Sauder On 2012-08-10 13:38 , Adam Roach - SIPCORE Chair wrote: > [as chair] > > Based on feedback received from the authors and working group, we > believe that the document "The WebSocket Protocol as a Transport for > the Session Initiation Protocol (SIP)" is ready for working group last > call. > > Working group participants -- and, in particular, those participants > who indicated a willingness to perform a dedicated review of the > document -- are asked to read the current document and provide > feedback. Even short statements along the lines of "I have carefully > read the document and believe it is ready for publication" are useful. > > The current version of the document is available here: > > http://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket/ > > This WGLC runs until Friday, August 24th. Thank you. > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From internet-drafts@ietf.org Fri Aug 24 02:44:43 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B05F521F86D9; Fri, 24 Aug 2012 02:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-g8fWYYZ4na; Fri, 24 Aug 2012 02:44:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B87821F86C7; Fri, 24 Aug 2012 02:44:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120824094443.5296.49516.idtracker@ietfa.amsl.com> Date: Fri, 24 Aug 2012 02:44:43 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-06.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: Fri, 24 Aug 2012 09:44:44 -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 : Mechanism to indicate support of features and capabiliti= es in the Session Initiation Protocol (SIP) Author(s) : Christer Holmberg Ivo Sedlacek Hadriel Kaplan Filename : draft-ietf-sipcore-proxy-feature-06.txt Pages : 21 Date : 2012-08-24 Abstract: This specification defines a new SIP header field, Feature-Caps, to convey feature capability indicators, which are used by SIP entities not represented by the URI of the Contact header field to indicate support of features and capabilities, where media feature tags cannot be used to indicate the support. This specification also defines feature capability indicators, and creates a new IANA registry, "Proxy-Feature Feature Capability Indicator Trees", for registering feature capability indicators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-proxy-feature There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-proxy-feature-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Fri Aug 24 02:46:24 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B506321F86D7 for ; Fri, 24 Aug 2012 02:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GuuCsJrRriV for ; Fri, 24 Aug 2012 02:46:24 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2649321F86C9 for ; Fri, 24 Aug 2012 02:46:17 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-5f-50374d69f7ae Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CD.F9.11467.96D47305; Fri, 24 Aug 2012 11:46:17 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 24 Aug 2012 11:46:13 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Date: Fri, 24 Aug 2012 11:46:11 +0200 Thread-Topic: Draft new version: proxy-feature-06 Thread-Index: Ac2B3SrszzBRAjI1ThmMC8dWznffkQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A292879@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A292879ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+JvrW6mr3mAwd19whbX5jSyWZx6dZrZ 4uuPTWwOzB5Llvxk8pi18wmLx5fLn9kCmKO4bFJSczLLUov07RK4Mg7N72IpuC1cceyMRAPj TcEuRk4OCQETiWUXdzJC2GISF+6tZ+ti5OIQEjjFKHHo7UZWCGcBo0Rj/0Mgh4ODTcBCovuf NkiDiICmxPJvW9lBapgFpjJKvFh5hxkkwSKgKnH9xgQmkHphAR2J7kt+EPWGEjd2LmKFsPUk 5n/vYAexeQXCJZZdWwTWygh0xPdTa5hAbGYBcYlbT+YzQRwnILFkz3lmCFtU4uXjf6wQ9aIS d9rXM0LU50tcW3eaGWKmoMTJmU9YJjAKz0IyahaSsllIyiDiOhILdn9ig7C1JZYtfM0MY585 8JgJWXwBI/sqRuHcxMyc9HJDvdSizOTi4vw8veLUTYzAaDq45bfuDsZT50QOMUpzsCiJ83Il 7fcXEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMhXFWRy+P+2P7XtUhcf3pQ94bJ6o1lk9DnW Q2seC31ItFzn0i8oWfmkNGJvCmfbAaWoG166n6/7eDdefdI3p/jp3BDnb8GfgpaVlnYzihv3 O73WtD9ksfq6xr0c2Q9XZRccOS2llyjCNP3GTpdt8hc+MH0M8Xp6cPVzQ3dLLfWjW7/3OgZZ RCixFGckGmoxFxUnAgDVuexNdAIAAA== Cc: "SIPCORE Chairs \(sipcore-chairs@tools.ietf.org\)" Subject: [sipcore] Draft new version: proxy-feature-06 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, 24 Aug 2012 09:46:24 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A292879ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the comments from Robert, I've updated and submitted a new version= (-06) of the proxy-feature draft. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340A292879ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on t= he comments from Robert, I’ve updated and submitted a new version (-0= 6) of the proxy-feature draft.

&nbs= p;

Regards,

 

Christer

= --_000_7F2072F1E0DE894DA4B517B93C6A0585340A292879ESESSCMS0356e_-- From brett@broadsoft.com Fri Aug 24 05:51:54 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E941A21F8609 for ; Fri, 24 Aug 2012 05:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zE51SxH5xb8u for ; Fri, 24 Aug 2012 05:51:54 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 793B021F854B for ; Fri, 24 Aug 2012 05:51:54 -0700 (PDT) Received: from casumhub01.citservers.local (172.16.98.57) by Xedge01.citservers.local (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 24 Aug 2012 05:55:34 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Fri, 24 Aug 2012 05:55:33 -0700 From: Brett Tate To: "sipcore@ietf.org" , "draft-ietf-sipcore-sip-websocket@tools.ietf.org" Date: Fri, 24 Aug 2012 05:51:51 -0700 Thread-Topic: draft-ietf-sipcore-sip-websocket-02: comments Thread-Index: Ac2B9ztyT0svAv2oSq+KYiBbJJzkOA== Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9467@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] draft-ietf-sipcore-sip-websocket-02: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 12:51:55 -0000 Howdy, The following are some minor comments concerning draft-ietf-sipcore-sip-web= socket-02. Thanks, Brett ---- Section 8.2: - The response examples should likely indicate the Via "received" parameter= when Via transport is UDP. - Max-Forwards should likely be removed from response examples. Section A.1: "hostpart" potentially should be "hostport". This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you ar= e not the intended recipient and have received this email in error, please = notify BroadSoft, Inc. immediately by replying to this message, or by sendi= ng an email to helpdesk@broadsoft.com, and destroy all copies of this messa= ge, along with any attachment, prior to reading, distributing or copying it= . From partha@parthasarathi.co.in Fri Aug 24 09:22:19 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3214321F85C3 for ; Fri, 24 Aug 2012 09:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0f3PbFXhCaB for ; Fri, 24 Aug 2012 09:22:17 -0700 (PDT) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.231]) by ietfa.amsl.com (Postfix) with ESMTP id 1353521F85AD for ; Fri, 24 Aug 2012 09:22:16 -0700 (PDT) Received: from userPC (unknown [122.172.178.73]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id D3FC5190805D; Fri, 24 Aug 2012 16:22:12 +0000 (GMT) From: "Parthasarathi R" To: =?iso-8859-1?Q?'Jos=E9_Luis_Mill=E1n'?= References: <000d01cd812e$46bb4850$d431d8f0$@co.in> In-Reply-To: Date: Fri, 24 Aug 2012 21:52:05 +0530 Message-ID: <000f01cd8214$9d255a00$d7700e00$@co.in> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01CD8242.B6DD9600" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2BSpKO/MKsAhDRT/yjl8Acf5gG9QAx04wQ Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0206.5037AA38.001A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 16:22:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0010_01CD8242.B6DD9600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Jose, =20 Let us assume draft-ibc-sipcore-sip-websocket-02 does not change proxy behavior in SIP websocket server then the dialog creation in the following topology breaks as follows: =20 Topolgy: =20 UAC SIP Websocket client (Browser)------Proxy SIP Websocket Server------UAS (RFC 3261 UA)=20 =20 Callflow steps: =20 1) UAC SIP Websocket client initiates INVITE dialog towards SIP = Websocket server 2) INVITE is forwarded towards UAS by SIP Websocket server 3) UAS receives INVITE and sent 200 OK response with contact address = with UDP transport towards SIP Websocket server 4) SIP Websocket server forwards 200 OK towards SIP Websocket client without record-route 5) Whether SIP Websocket Client(browser) will be able to send ACK = towards UAS contact address in UDP transport? No. =20 In case normal RFC 3261 application or application based on SIP = websocket client, ACK will send towards=20 UAS contact address with UDP transport as per mandatory to implement transport mechanism in RFC 3261.=20 As browser acting as SIP Websocket client violates the mandatory to implement transport mechanism, the callflow breaks in this specification.=20 =20 In case you wish to put some other text, Please let us discuss. =20 Thanks Partha =20 From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf Of Jos=E9 Luis Mill=E1n Sent: Thursday, August 23, 2012 9:46 PM To: Parthasarathi R Cc: sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 =20 Hi, 2012/8/23 Parthasarathi R Hi all, =20 As I discussed during IETF-84 meeting, the following text is provided = for the starting the discussion on deviation of RFC 3261 mandatory to = implement (UDP/TCP) transport in this draft.=20 =20 =93In case SIP WebSocket Client is a web browser and SIP Websocket = Server is a SIP proxy, then record-route header MUST be included by SIP Websocket = server in all SIP messages. This requirement assures that SIP WebSocket Client = is able to contact with UAS through SIP Websocket Server during the = mid-dialog irrespective of the contact SIP URI received from UAS =94 =20 Record-Route header field is useful for a proxy in order to remain in = the dialog path. It is not necessary for all SIP messages. This is defined = in RFC 3261 as 'loose routing' and draft-ibc-sipcore-sip-websocket-02 does = not change it at all. =20 Section 2 of Apendix A (Implementation guidelines) already mentions it: =20 " The proxy performs Loose Routing and remains in dialogs path as specified in [RFC3261 ]. = Otherwise in-dialog requests would fail since SIP WebSocket Clients make use of their SIP WebSocket Server in order to send and receive SIP requests and responses. " =20 Regards, =20 The above normative statement will be update to RFC 3261. =20 Thanks Partha _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =20 ------=_NextPart_000_0010_01CD8242.B6DD9600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Jose,

 

Let us assume draft-ibc-sipcore-sip-websocket-02 does not = change proxy behavior in SIP websocket server then

the dialog creation in the following topology breaks as = follows:

 <= /o:p>

Topolgy:

 <= /o:p>

=A0 UAC SIP Websocket client (Browser)------Proxy SIP Websocket = Server------UAS (RFC 3261 UA)

 <= /o:p>

Callflow steps:

 <= /o:p>

1)    UAC SIP Websocket client initiates INVITE dialog towards = SIP Websocket server

2)    INVITE is forwarded towards UAS by SIP Websocket = server

3)    UAS receives INVITE and sent 200 OK response with contact = address with UDP transport

towards SIP Websocket server

4)    SIP Websocket server forwards 200 OK towards SIP = Websocket client without record-route

5)    Whether SIP Websocket Client(browser) will be able to = send ACK towards UAS contact

=A0=A0=A0=A0=A0 = =A0address in UDP transport? No.

 

In case normal RFC 3261 application or application based = on SIP websocket client, ACK will send towards

UAS contact address with UDP transport as per mandatory = to implement transport mechanism in RFC 3261.

As browser acting as SIP Websocket client violates the = mandatory to implement transport mechanism,

the callflow breaks in this specification. =

 

In case you wish to put some other text, Please let us = discuss.

 

Thanks

Partha

 

From:= sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Jos=E9 Luis Mill=E1n
Sent: Thursday, August 23, 2012 9:46 PM
To: Parthasarathi R
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Mandatory to implement transport comment = on draft-ibc-sipcore-sip-websocket-02

 

Hi,

2012/8/23 Parthasarathi R <partha@parthasarathi.co.in>

Hi all,

 <= /o:p>

As I discussed during IETF-84 meeting,  the following text is provided = for the starting the discussion on deviation of RFC 3261 mandatory to implement (UDP/TCP) transport in this draft.

 <= /o:p>

“In case SIP WebSocket Client is a web browser and SIP = Websocket Server is a SIP proxy, then record-route header MUST be included by SIP = Websocket server in all SIP messages. This requirement assures that SIP WebSocket = Client is able to contact with UAS through SIP Websocket Server during the = mid-dialog irrespective of the contact SIP URI received from UAS = ”

 

Record-Route header field is useful for a proxy in = order to remain in the dialog path. It is not necessary for all SIP = messages. This is defined in RFC 3261 as 'loose routing' and draft-ibc-sipcore-sip-websocket-02 does not change it at = all.

 

Section 2 of Apendix A (Implementation guidelines) already mentions it:

 

"

 The proxy performs Loose Routing and remains in dialogs path = as

=A0=A0 specified =
in [RFC3261].=A0 =
Otherwise in-dialog requests would =
fail
 =A0=A0since SIP WebSocket =
Clients make use of their SIP WebSocket Server =
in
=A0=A0 order to send and =
receive SIP requests and responses.

"

 

Regards,

 <= /o:p>

The above normative statement will be update to  RFC = 3261.

 <= /o:p>

Thanks<= /o:p>

Partha<= /o:p>


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

 

------=_NextPart_000_0010_01CD8242.B6DD9600-- From ibc@aliax.net Fri Aug 24 09:39:34 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F28C21F86C2 for ; Fri, 24 Aug 2012 09:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.66 X-Spam-Level: X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auSbVQs2SjDA for ; Fri, 24 Aug 2012 09:39:34 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B894521F86A2 for ; Fri, 24 Aug 2012 09:39:33 -0700 (PDT) Received: by lahm15 with SMTP id m15so1319690lah.31 for ; Fri, 24 Aug 2012 09:39:32 -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=BLoWQC1SpXRIGjm5i/MfYFgUv3HN7i8h9Ak8DY8U2mo=; b=HK/uv6Ra1EfwVvJZoTVFCNNe/L9NjiIHBkHqiDVq9r7H+QORZZJeDqxzxWK6MllyM+ 642Jregcq44Rmyn3CTQMA8/KkLVbqw2zuLIc4c0B1UxPTwUZLj0B8t+CVegLZsXDh2P0 kFw9G2X7i5f6kB/wLMZY2UuxSbg3uywB0YRcSigXi/6dSej7tF9oZeDDT0Bj1PHK9Zv/ U2If9iGmOhqQhC7ECr7bkKIiUG7sci0CYnqebbm18iv6gj8f1TuArY/Ww7U4fqvKsFAk lcJLCdXYbwH7N3mPyPPT4QDgXx0EpZZz27ZZL8XMmJejqfvlU7U68V5YG/1xFhl3sQ3H e1zw== Received: by 10.152.104.146 with SMTP id ge18mr6520900lab.7.1345826372316; Fri, 24 Aug 2012 09:39:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.7 with HTTP; Fri, 24 Aug 2012 09:39:12 -0700 (PDT) In-Reply-To: <000f01cd8214$9d255a00$d7700e00$@co.in> References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 24 Aug 2012 18:39:12 +0200 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk0Bv8sVBCSvGkVC11hyQ/3d6/9Sq4bPX3+jRvfTbqhoLFlfVnyleqRCuzhTBDMpVSc3t4E Cc: sipcore@ietf.org, =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 16:39:34 -0000 2012/8/24 Parthasarathi R : > In case normal RFC 3261 application or application based on SIP websocket > client, ACK will send towards > > UAS contact address with UDP transport as per mandatory to implement > transport mechanism in RFC 3261. > > As browser acting as SIP Websocket client violates the mandatory to > implement transport mechanism, > > the callflow breaks in this specification. Hi Partha. As said many times this draft is not *just* about web browsers. Please imagine that new versions of iOS and Android come with a WebSocket Client stack (so native apps can use it). Should we also add them to the draft?: =E2=80=9CIn case SIP WebSocket Client is a web browser or a native iOS or Android application, and SIP Websocket Server is a SIP proxy, then..." Ugly, agree? Anyhow, for the case of a web browser (which indeed cannot send a UDP datagram) the draft already describes a full guideline in the Appendix section: http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02#appendix-A IMHO that's enough. The mandatory sections of the draft should not focus just on web browsers. BTW your text is incomplete: =E2=80=9CIn case SIP WebSocket Client is a web browser and SIP Websocket Server is a SIP proxy, then record-route header MUST be included by SIP Websocket server in all SIP messages. This requirement assures that SIP WebSocket Client is able to contact with UAS through SIP Websocket Server during the mid-dialog irrespective of the contact SIP URI received from UAS =E2=80=9D That's not enough. If you want to also *receive* incoming requests you need to mandate Outbound RFC 5626 (since the proxy cannot establish a WebSocket connection with a web browser). But we don't want to mandate Outbound (it was discussed and voted in Paris) since the draft just describes a SIP transport and does not assume specific topologies or UA devices. IMHO the Appendix guideline (which was already discussed in this WG) is the appropriate section for talking about specific common scenarios. The draft should not "update" RFC 3261 just for the case of web browsers. Regards. --=20 I=C3=B1aki Baz Castillo From jmillan@aliax.net Fri Aug 24 09:48:50 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A93E21F85FC for ; Fri, 24 Aug 2012 09:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnW9bhyHE34U for ; Fri, 24 Aug 2012 09:48:49 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3935D21F85B1 for ; Fri, 24 Aug 2012 09:48:48 -0700 (PDT) Received: by lahm15 with SMTP id m15so1325031lah.31 for ; Fri, 24 Aug 2012 09:48:43 -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=mdSlNIwrbYHy9njVDWNoMvj/tnq8mjIdGnBI5uaujvA=; b=S8DNtyiX3aWJlDP1dcweQ1pLUv82KFNtlADAV2jcEIg8Y282PXbU7hnn23QSWtuy/9 zzKf1uuMYtS1o2kWOphiCJiiMTf8hEjHFKgqV9gpNx3a1SiwKO03ziZN/ubc/gVUVkrM JkOSbfpNLqGsRwYlcYDOzs9zuNn+sk+kUdUpmO7mnzBN84FnlSNWbnf4sCXLJD5yIBqz 2mrViCyXGA+pSFxy/CkqQjkEtVIUilTfA2tI3yfcNsq7DIzF3+2b1WMfgTBo72DF0DEw qiCbcIYQRHy8QL0Mje/QU8EuMuMlyc4qXXrzhCWb1I0hiMvrhKVsAilCG38mtEgppC7j ezIw== MIME-Version: 1.0 Received: by 10.152.46.209 with SMTP id x17mr6271910lam.38.1345826923169; Fri, 24 Aug 2012 09:48:43 -0700 (PDT) Received: by 10.112.94.33 with HTTP; Fri, 24 Aug 2012 09:48:43 -0700 (PDT) In-Reply-To: <000f01cd8214$9d255a00$d7700e00$@co.in> References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> Date: Fri, 24 Aug 2012 18:48:43 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: Parthasarathi R Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkhN214ptJwKvFHMw3pzdTIxRw4Ddg2fvgAwqUrt5AH3bnZFzbDjaOpG14Vysz5cfsiU7da Cc: sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 16:48:50 -0000 Hi Partha, Please, read inline. 2012/8/24 Parthasarathi R : > Hi Jose, > > > > Let us assume draft-ibc-sipcore-sip-websocket-02 does not change proxy > behavior in SIP websocket server then > > the dialog creation in the following topology breaks as follows: > > > > Topolgy: > > > > UAC SIP Websocket client (Browser)------Proxy SIP Websocket > Server------UAS (RFC 3261 UA) > > > > Callflow steps: > > > > 1) UAC SIP Websocket client initiates INVITE dialog towards SIP Websoc= ket > server > > 2) INVITE is forwarded towards UAS by SIP Websocket server .. which adds a Record-Route header field because it wants to stay in the signaling path during the dialog ;-) > > 3) UAS receives INVITE and sent 200 OK response with contact address w= ith > UDP transport it builds the 200 OK response taking the Record-Route headers from the received INVITE request. > > towards SIP Websocket server > > 4) SIP Websocket server forwards 200 OK towards SIP Websocket client > without record-route It receives 200 OK with the Record-Route headers > > 5) Whether SIP Websocket Client(browser) will be able to send ACK towa= rds > UAS contact > > address in UDP transport? No. > ACK request will be formed with the dialog`s route set, being the first hop the SIP WebSocket Server. > > > In case normal RFC 3261 application or application based on SIP websocket > client, ACK will send towards > > UAS contact address with UDP transport as per mandatory to implement > transport mechanism in RFC 3261. > > As browser acting as SIP Websocket client violates the mandatory to > implement transport mechanism, > > the callflow breaks in this specification. > Why didn't you add a Record-Route header in the point '2' ( INVITE is forwarded towards UAS by SIP Websocket server) ? You should have added if you wanted to stay in the signaling path during the dialog. This is stated in RFC 3261. The reason your ACK does not reach the destination is a configuration problem more that specification definition issue. > > > In case you wish to put some other text, Please let us discuss. > > > > Thanks > > Partha > Regards. > > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Jos=E9 Luis Mill=E1n > Sent: Thursday, August 23, 2012 9:46 PM > To: Parthasarathi R > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Mandatory to implement transport comment on > draft-ibc-sipcore-sip-websocket-02 > > > > Hi, > > 2012/8/23 Parthasarathi R > > Hi all, > > > > As I discussed during IETF-84 meeting, the following text is provided fo= r > the starting the discussion on deviation of RFC 3261 mandatory to impleme= nt > (UDP/TCP) transport in this draft. > > > > =93In case SIP WebSocket Client is a web browser and SIP Websocket Server= is a > SIP proxy, then record-route header MUST be included by SIP Websocket ser= ver > in all SIP messages. This requirement assures that SIP WebSocket Client i= s > able to contact with UAS through SIP Websocket Server during the mid-dial= og > irrespective of the contact SIP URI received from UAS =94 > > > > Record-Route header field is useful for a proxy in order to remain in the > dialog path. It is not necessary for all SIP messages. This is defined in > RFC 3261 as 'loose routing' and draft-ibc-sipcore-sip-websocket-02 does n= ot > change it at all. > > > > Section 2 of Apendix A (Implementation guidelines) already mentions it: > > > > " > > The proxy performs Loose Routing and remains in dialogs path as > > specified in [RFC3261]. Otherwise in-dialog requests would fail > > since SIP WebSocket Clients make use of their SIP WebSocket Server in > > order to send and receive SIP requests and responses. > > " > > > > Regards, > > > > The above normative statement will be update to RFC 3261. > > > > Thanks > > Partha > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From jmillan@aliax.net Fri Aug 24 10:15:24 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD4821F8718 for ; Fri, 24 Aug 2012 10:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIZe2rLqcVTV for ; Fri, 24 Aug 2012 10:15:23 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B00421F8715 for ; Fri, 24 Aug 2012 10:15:23 -0700 (PDT) Received: by lahm15 with SMTP id m15so1340722lah.31 for ; Fri, 24 Aug 2012 10:15:22 -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=+aEjdp7HCHzwenT/aMHp4ecUJxPCn0DUM8QdaSxIskU=; b=GymtakbbwYzkJm+SPABaW2bCWdCUQU+xuE8w3/Pm7+djp7zW1lYlSDuurMdDDgiQGX cVxqpyQVHYSzjNzlq+1EobXeO0PyxJTijYQLKje7cz0fnHKG3J5IeGVelzZZnrh2pkeT 0z6FgTCAM0j9vix1iYZb0517YlEY5f73DArD3SN8Psk6LaVrcrbY+xYQs/pJ54jmVAPI h+mqatZ/p/sxBzl3kkIuBzE9uXM0BcDOvmB1rf7Og33IOPgtY8ixQ2ckXNAY1y2SE5b3 QOvsUNGiYGXzNTe92dW1vRmhFpoBNc/jr0ukyZHY9c3nPxYtX3l09JIetPNHZDlA41I7 TY3Q== MIME-Version: 1.0 Received: by 10.152.46.209 with SMTP id x17mr6345112lam.38.1345828522080; Fri, 24 Aug 2012 10:15:22 -0700 (PDT) Received: by 10.112.94.33 with HTTP; Fri, 24 Aug 2012 10:15:22 -0700 (PDT) In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9467@EXMBXCLUS01.citservers.local> References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9467@EXMBXCLUS01.citservers.local> Date: Fri, 24 Aug 2012 19:15:22 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: Brett Tate Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmRRlHHXKhWVBzWsv42gPXRCxfFbeqZ+/NRvjBS6yJME3khPSr2JkGqQ8sFuMK5Wh2rfizx Cc: "sipcore@ietf.org" , "draft-ietf-sipcore-sip-websocket@tools.ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-sip-websocket-02: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:15:24 -0000 Hi Brett, Thanks for your comments. We will address them. Regards, 2012/8/24 Brett Tate : > Howdy, > > The following are some minor comments concerning draft-ietf-sipcore-sip-w= ebsocket-02. > > Thanks, > Brett > > ---- > > Section 8.2: > > - The response examples should likely indicate the Via "received" paramet= er when Via transport is UDP. > > - Max-Forwards should likely be removed from response examples. > > Section A.1: "hostpart" potentially should be "hostport". > > > This email is intended solely for the person or entity to which it is add= ressed and may contain confidential and/or privileged information. If you = are not the intended recipient and have received this email in error, pleas= e notify BroadSoft, Inc. immediately by replying to this message, or by sen= ding an email to helpdesk@broadsoft.com, and destroy all copies of this mes= sage, along with any attachment, prior to reading, distributing or copying = it. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From partha@parthasarathi.co.in Fri Aug 24 10:15:28 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740AE21F8722 for ; Fri, 24 Aug 2012 10:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYXTA2iT-tZ7 for ; Fri, 24 Aug 2012 10:15:27 -0700 (PDT) Received: from outbound-us2.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.236]) by ietfa.amsl.com (Postfix) with ESMTP id B2EED21F8720 for ; Fri, 24 Aug 2012 10:15:27 -0700 (PDT) Received: from userPC (unknown [122.178.222.129]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us2.mailhostbox.com (Postfix) with ESMTPA id A801A3E2B25; Fri, 24 Aug 2012 17:15:24 +0000 (GMT) From: "Parthasarathi R" To: =?iso-8859-1?Q?'Jos=E9_Luis_Mill=E1n'?= References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> In-Reply-To: Date: Fri, 24 Aug 2012 22:45:17 +0530 Message-ID: <000601cd821c$0b2b88b0$21829a10$@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: Ac2CGFiLIV1rTMerS4CnXs/SWWd9HQAAp18g Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0207.5037B6AF.0053, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:15:28 -0000 Jose, I haven't added "record-route" in point 2 as RFC 3261 does not mandates = to add :-)=20 In case of RFC 3261 SIP transports, the dialog creation happens without "record-route"=20 whereas SIP over WebSocket transport in browser is different. Thanks Partha -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf Of Jos=E9 Luis Mill=E1n Sent: Friday, August 24, 2012 10:19 PM To: Parthasarathi R Cc: sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 Hi Partha, Please, read inline. 2012/8/24 Parthasarathi R : > Hi Jose, > > > > Let us assume draft-ibc-sipcore-sip-websocket-02 does not change proxy > behavior in SIP websocket server then > > the dialog creation in the following topology breaks as follows: > > > > Topolgy: > > > > UAC SIP Websocket client (Browser)------Proxy SIP Websocket > Server------UAS (RFC 3261 UA) > > > > Callflow steps: > > > > 1) UAC SIP Websocket client initiates INVITE dialog towards SIP Websocket > server > > 2) INVITE is forwarded towards UAS by SIP Websocket server .. which adds a Record-Route header field because it wants to stay in the signaling path during the dialog ;-) > > 3) UAS receives INVITE and sent 200 OK response with contact = address with > UDP transport it builds the 200 OK response taking the Record-Route headers from the received INVITE request. > > towards SIP Websocket server > > 4) SIP Websocket server forwards 200 OK towards SIP Websocket = client > without record-route It receives 200 OK with the Record-Route headers > > 5) Whether SIP Websocket Client(browser) will be able to send ACK towards > UAS contact > > address in UDP transport? No. > ACK request will be formed with the dialog`s route set, being the first hop the SIP WebSocket Server. > > > In case normal RFC 3261 application or application based on SIP = websocket > client, ACK will send towards > > UAS contact address with UDP transport as per mandatory to implement > transport mechanism in RFC 3261. > > As browser acting as SIP Websocket client violates the mandatory to > implement transport mechanism, > > the callflow breaks in this specification. > Why didn't you add a Record-Route header in the point '2' ( INVITE is forwarded towards UAS by SIP Websocket server) ? You should have added if you wanted to stay in the signaling path during the dialog. This is stated in RFC 3261. The reason your ACK does not reach the destination is a configuration problem more that specification definition issue. > > > In case you wish to put some other text, Please let us discuss. > > > > Thanks > > Partha > Regards. > > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf > Of Jos=E9 Luis Mill=E1n > Sent: Thursday, August 23, 2012 9:46 PM > To: Parthasarathi R > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Mandatory to implement transport comment on > draft-ibc-sipcore-sip-websocket-02 > > > > Hi, > > 2012/8/23 Parthasarathi R > > Hi all, > > > > As I discussed during IETF-84 meeting, the following text is provided = for > the starting the discussion on deviation of RFC 3261 mandatory to implement > (UDP/TCP) transport in this draft. > > > > =93In case SIP WebSocket Client is a web browser and SIP Websocket = Server is a > SIP proxy, then record-route header MUST be included by SIP Websocket server > in all SIP messages. This requirement assures that SIP WebSocket = Client is > able to contact with UAS through SIP Websocket Server during the mid-dialog > irrespective of the contact SIP URI received from UAS =94 > > > > Record-Route header field is useful for a proxy in order to remain in = the > dialog path. It is not necessary for all SIP messages. This is defined = in > RFC 3261 as 'loose routing' and draft-ibc-sipcore-sip-websocket-02 = does not > change it at all. > > > > Section 2 of Apendix A (Implementation guidelines) already mentions = it: > > > > " > > The proxy performs Loose Routing and remains in dialogs path as > > specified in [RFC3261]. Otherwise in-dialog requests would fail > > since SIP WebSocket Clients make use of their SIP WebSocket Server = in > > order to send and receive SIP requests and responses. > > " > > > > Regards, > > > > The above normative statement will be update to RFC 3261. > > > > Thanks > > Partha > > > _______________________________________________ > 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 Fri Aug 24 10:41:19 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5E321F8691 for ; Fri, 24 Aug 2012 10:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.059 X-Spam-Level: X-Spam-Status: No, score=-1.059 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8ggcytlYSAY for ; Fri, 24 Aug 2012 10:41:18 -0700 (PDT) Received: from outbound-us2.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.233]) by ietfa.amsl.com (Postfix) with ESMTP id 366B521F8615 for ; Fri, 24 Aug 2012 10:41:18 -0700 (PDT) Received: from userPC (unknown [122.179.95.174]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us2.mailhostbox.com (Postfix) with ESMTPA id 25DC73E2F88; Fri, 24 Aug 2012 17:41:09 +0000 (GMT) From: "Parthasarathi R" To: =?UTF-8?Q?'I=C3=B1aki_Baz_Castillo'?= References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> In-Reply-To: Date: Fri, 24 Aug 2012 23:11:02 +0530 Message-ID: <000701cd821f$a5245070$ef6cf150$@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: Ac2CFwoqLKbcycXFQEyMrONHXP+0QQABr09w Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B020A.5037BCB9.014F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: sipcore@ietf.org, =?UTF-8?Q?'Jos=C3=A9_Luis_Mill=C3=A1n'?= Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:41:19 -0000 Inaki, Paul started the relaxing the criteria for mandatory to implement = transport mail thread during WG adoption of SIP over websocket draft and = one of the mail is = http://www.ietf.org/mail-archive/web/sipcore/current/msg04930.html. My = understanding of the mail thread conclusion was that narrow approach of = providing leniency for mandatory to implement transport in SIP over = Websocket draft itself. I noticed in the current document that there is = no relevant text for this leniency and so raised the issue in IETF-84 = SIPCore meeting. As per IETF-84 SIPCore meeting discussion, I started = this mail thread. In case you are not in favor of narrow approach proposed by Paul, then = it is a separate discussion. Also you have indicated that the narrow = approach needs more text, then please suggest the text and let us = discuss. Thanks Partha=20 -----Original Message----- From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net]=20 Sent: Friday, August 24, 2012 10:09 PM To: Parthasarathi R Cc: Jos=C3=A9 Luis Mill=C3=A1n; sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on = draft-ibc-sipcore-sip-websocket-02 2012/8/24 Parthasarathi R : > In case normal RFC 3261 application or application based on SIP = websocket > client, ACK will send towards > > UAS contact address with UDP transport as per mandatory to implement > transport mechanism in RFC 3261. > > As browser acting as SIP Websocket client violates the mandatory to > implement transport mechanism, > > the callflow breaks in this specification. Hi Partha. As said many times this draft is not *just* about web browsers. Please imagine that new versions of iOS and Android come with a WebSocket Client stack (so native apps can use it). Should we also add them to the draft?: =E2=80=9CIn case SIP WebSocket Client is a web browser or a native iOS = or Android application, and SIP Websocket Server is a SIP proxy, then..." Ugly, agree? Anyhow, for the case of a web browser (which indeed cannot send a UDP datagram) the draft already describes a full guideline in the Appendix section: http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02#appendix-A IMHO that's enough. The mandatory sections of the draft should not focus just on web browsers. BTW your text is incomplete: =E2=80=9CIn case SIP WebSocket Client is a web browser and SIP Websocket Server is a SIP proxy, then record-route header MUST be included by SIP Websocket server in all SIP messages. This requirement assures that SIP WebSocket Client is able to contact with UAS through SIP Websocket Server during the mid-dialog irrespective of the contact SIP URI received from UAS =E2=80=9D That's not enough. If you want to also *receive* incoming requests you need to mandate Outbound RFC 5626 (since the proxy cannot establish a WebSocket connection with a web browser). But we don't want to mandate Outbound (it was discussed and voted in Paris) since the draft just describes a SIP transport and does not assume specific topologies or UA devices. IMHO the Appendix guideline (which was already discussed in this WG) is the appropriate section for talking about specific common scenarios. The draft should not "update" RFC 3261 just for the case of web browsers. Regards. --=20 I=C3=B1aki Baz Castillo From jmillan@aliax.net Fri Aug 24 10:44:28 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60AB21F8646 for ; Fri, 24 Aug 2012 10:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ueg8XtsD7iTH for ; Fri, 24 Aug 2012 10:44:27 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7B621F861D for ; Fri, 24 Aug 2012 10:44:26 -0700 (PDT) Received: by lbky2 with SMTP id y2so549118lbk.31 for ; Fri, 24 Aug 2012 10:44:21 -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=Gme1kUlOgSWgdmkNOXVb+pcUvh5id8986NMwbjWugM4=; b=iks5jMkZPK1WSTHfj0il3Do+GsuHdwbTIROjW856krUn5KNvraany8b2hQ3Ku/23Sk nxqV/kcTNr6PKJ8NhR7hWGQRVx8Rp1s2SqblcZ0nmAwi50txW0QFDKuJTSJg5pQ5JsvT CHJ+UfTfV1sq+n9tg1lifzm8oa4fLfvJHLetv5BbVhc4Xqwb/1mUlOmSkrtiRW8sc5iQ KWifXN17+WWE30eZ6ao+hIP2HvbV8209Hn4MGKOeSy/3dRz3LfIF5DwcKzm51ns97Hrj Jllq/Ml9BQk0tfivOGJ+0oezNvT3gOAg5kTfoPEr0hHQryJaQNUU+nMep1vtroljlToO gpDQ== MIME-Version: 1.0 Received: by 10.112.46.136 with SMTP id v8mr3058102lbm.5.1345830260899; Fri, 24 Aug 2012 10:44:20 -0700 (PDT) Received: by 10.112.94.33 with HTTP; Fri, 24 Aug 2012 10:44:20 -0700 (PDT) In-Reply-To: <000601cd821c$0b2b88b0$21829a10$@co.in> References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> <000601cd821c$0b2b88b0$21829a10$@co.in> Date: Fri, 24 Aug 2012 19:44:20 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: Parthasarathi R Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmxZY6dCGgrpHzxylEGgCmNagqEt0qY9TKScYO3nPBL06Vzd3PjjHyXIsLBCcTIP4NxtUa9 Cc: sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 17:44:28 -0000 2012/8/24 Parthasarathi R : > Jose, > > I haven't added "record-route" in point 2 as RFC 3261 does not mandates t= o > add :-) It mandates to insert a Record-Route header field if the proxy wishes to remain on the path of future requests in a dialog. " 16.6 Request Forwarding If this proxy wishes to remain on the path of future requests in a dialog created by this request (assuming the request creates a dialog), it MUST insert a Record-Route header field value into the copy before any existing Record-Route header field values, even if a Route header field is already present. " Addition of Record-Route header field is already commented in draft-ibc-sipcore-sip-websocket-02, in section 2 of Appendix A: SIP WebSocket Server Considerations. " The proxy performs Loose Routing and remains in dialogs path as specified in [RFC3261]. Otherwise in-dialog requests would fail since SIP WebSocket Clients make use of their SIP WebSocket Server in order to send and receive SIP requests and responses. " May the following (extracted from the previous text) not be clear? " SIP WebSocket Clients make use of their SIP WebSocket Server in order to send and receive SIP requests and responses " Considering the previous text, isn't it clear that the SIP WebSocket Server is used by the SIP WebSocket Client for sending and receiving SIP requests and responses, which involves SIP WebSocket Server staying in the signaling path? > In case of RFC 3261 SIP transports, the dialog creation happens without > "record-route" > whereas SIP over WebSocket transport in browser is different. > > Thanks > Partha Regards. > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Jos=E9 Luis Mill=E1n > Sent: Friday, August 24, 2012 10:19 PM > To: Parthasarathi R > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Mandatory to implement transport comment on > draft-ibc-sipcore-sip-websocket-02 > > Hi Partha, > > Please, read inline. > > 2012/8/24 Parthasarathi R : >> Hi Jose, >> >> >> >> Let us assume draft-ibc-sipcore-sip-websocket-02 does not change proxy >> behavior in SIP websocket server then >> >> the dialog creation in the following topology breaks as follows: >> >> >> >> Topolgy: >> >> >> >> UAC SIP Websocket client (Browser)------Proxy SIP Websocket >> Server------UAS (RFC 3261 UA) >> >> >> >> Callflow steps: >> >> >> >> 1) UAC SIP Websocket client initiates INVITE dialog towards SIP > Websocket >> server >> >> 2) INVITE is forwarded towards UAS by SIP Websocket server > > .. which adds a Record-Route header field because it wants to stay in > the signaling path during the dialog ;-) > >> >> 3) UAS receives INVITE and sent 200 OK response with contact address > with >> UDP transport > > it builds the 200 OK response taking the Record-Route headers from the > received INVITE request. > >> >> towards SIP Websocket server >> >> 4) SIP Websocket server forwards 200 OK towards SIP Websocket client >> without record-route > > It receives 200 OK with the Record-Route headers > >> >> 5) Whether SIP Websocket Client(browser) will be able to send ACK > towards >> UAS contact >> >> address in UDP transport? No. >> > > ACK request will be formed with the dialog`s route set, being the > first hop the SIP WebSocket Server. > >> >> >> In case normal RFC 3261 application or application based on SIP websocke= t >> client, ACK will send towards >> >> UAS contact address with UDP transport as per mandatory to implement >> transport mechanism in RFC 3261. >> >> As browser acting as SIP Websocket client violates the mandatory to >> implement transport mechanism, >> >> the callflow breaks in this specification. >> > > Why didn't you add a Record-Route header in the point '2' ( INVITE is > forwarded towards UAS by SIP Websocket server) ? > > You should have added if you wanted to stay in the signaling path > during the dialog. This is stated in RFC 3261. The reason your ACK > does not reach the destination is a configuration problem more that > specification definition issue. > >> >> >> In case you wish to put some other text, Please let us discuss. >> >> >> >> Thanks >> >> Partha >> > > Regards. > >> >> >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Beha= lf >> Of Jos=E9 Luis Mill=E1n >> Sent: Thursday, August 23, 2012 9:46 PM >> To: Parthasarathi R >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Mandatory to implement transport comment on >> draft-ibc-sipcore-sip-websocket-02 >> >> >> >> Hi, >> >> 2012/8/23 Parthasarathi R >> >> Hi all, >> >> >> >> As I discussed during IETF-84 meeting, the following text is provided f= or >> the starting the discussion on deviation of RFC 3261 mandatory to > implement >> (UDP/TCP) transport in this draft. >> >> >> >> =93In case SIP WebSocket Client is a web browser and SIP Websocket Serve= r is > a >> SIP proxy, then record-route header MUST be included by SIP Websocket > server >> in all SIP messages. This requirement assures that SIP WebSocket Client = is >> able to contact with UAS through SIP Websocket Server during the > mid-dialog >> irrespective of the contact SIP URI received from UAS =94 >> >> >> >> Record-Route header field is useful for a proxy in order to remain in th= e >> dialog path. It is not necessary for all SIP messages. This is defined i= n >> RFC 3261 as 'loose routing' and draft-ibc-sipcore-sip-websocket-02 does > not >> change it at all. >> >> >> >> Section 2 of Apendix A (Implementation guidelines) already mentions it: >> >> >> >> " >> >> The proxy performs Loose Routing and remains in dialogs path as >> >> specified in [RFC3261]. Otherwise in-dialog requests would fail >> >> since SIP WebSocket Clients make use of their SIP WebSocket Server in >> >> order to send and receive SIP requests and responses. >> >> " >> >> >> >> Regards, >> >> >> >> The above normative statement will be update to RFC 3261. >> >> >> >> Thanks >> >> Partha >> >> >> _______________________________________________ >> 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 jmillan@aliax.net Fri Aug 24 11:15:35 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D9221F85F4 for ; Fri, 24 Aug 2012 11:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPfvWWgksoJs for ; Fri, 24 Aug 2012 11:15:30 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C65D21F861C for ; Fri, 24 Aug 2012 11:15:30 -0700 (PDT) Received: by lbky2 with SMTP id y2so565919lbk.31 for ; Fri, 24 Aug 2012 11:15:29 -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=anZi7WwEoJ6LqI+jQxhXIbG4sYXCctOkACkXu21fKu8=; b=C9CT4nGBf2f2PU6r4wcZ0O7hLBfm+YLa7Zmofpw/QUtOycI6eVnVSs5fPnTsWLr2m1 05qwh3lb2Xg3cLbjcQ8NZJrz2m3Thqx6vLJc2iP4rGN1XVqTcyTcY3ty8Q1o0yxVhJ1q zAEMG5ewJf4Z0cIke/yswe60oFRySimekzhyhd0/y8yjGNLEvvTMafQMfToe3+IcSdmJ 3yH866ZGbHy0MSi150CWgS1eGViAJ0Fix+a88qF9eAX4Xm48mN2Q1fU/p4lDT/rFCLmI RDRuDIbayH1XJGQefEK/3ARQ2y88M6C++/f+G2elr3gPN1aqu87E36coaOYgRmBosPO/ i3cg== MIME-Version: 1.0 Received: by 10.152.104.146 with SMTP id ge18mr6786626lab.7.1345832129008; Fri, 24 Aug 2012 11:15:29 -0700 (PDT) Received: by 10.112.94.33 with HTTP; Fri, 24 Aug 2012 11:15:28 -0700 (PDT) In-Reply-To: References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> <000601cd821c$0b2b88b0$21829a10$@co.in> Date: Fri, 24 Aug 2012 20:15:28 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: Parthasarathi R Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl4fMhIigcrIFgNZA0wn6YVTOpNElCcAsPpRcV+CmbaUx1c368oCQnnLo/EvuhM2UbpA6JN Cc: sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 18:15:35 -0000 Hi Partha, I honestly think this thread is not a good starting point for discussing the subject related to 3261 requirement for UDP and TCP transports. Best regards, 2012/8/24 Jos=E9 Luis Mill=E1n : > 2012/8/24 Parthasarathi R : >> Jose, >> >> I haven't added "record-route" in point 2 as RFC 3261 does not mandates = to >> add :-) > > It mandates to insert a Record-Route header field if the proxy wishes > to remain on the path of future requests in a dialog. > > " > 16.6 Request Forwarding > > If this proxy wishes to remain on the path of future requests > in a dialog created by this request (assuming the request > creates a dialog), it MUST insert a Record-Route header field > value into the copy before any existing Record-Route header > field values, even if a Route header field is already present. > " > > Addition of Record-Route header field is already commented in > draft-ibc-sipcore-sip-websocket-02, in section 2 of Appendix A: SIP > WebSocket Server Considerations. > > " > The proxy performs Loose Routing and remains in dialogs path as > specified in [RFC3261]. Otherwise in-dialog requests would fail > since SIP WebSocket Clients make use of their SIP WebSocket Server in > order to send and receive SIP requests and responses. > " > > May the following (extracted from the previous text) not be clear? > > " > SIP WebSocket Clients make use of their SIP WebSocket Server in > order to send and receive SIP requests and responses > " > > Considering the previous text, isn't it clear that the SIP WebSocket > Server is used by the SIP WebSocket Client for sending and receiving > SIP requests and responses, which involves SIP WebSocket Server > staying in the signaling path? > > >> In case of RFC 3261 SIP transports, the dialog creation happens without >> "record-route" >> whereas SIP over WebSocket transport in browser is different. >> >> Thanks >> Partha > > Regards. > >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Beha= lf >> Of Jos=E9 Luis Mill=E1n >> Sent: Friday, August 24, 2012 10:19 PM >> To: Parthasarathi R >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Mandatory to implement transport comment on >> draft-ibc-sipcore-sip-websocket-02 >> >> Hi Partha, >> >> Please, read inline. >> >> 2012/8/24 Parthasarathi R : >>> Hi Jose, >>> >>> >>> >>> Let us assume draft-ibc-sipcore-sip-websocket-02 does not change proxy >>> behavior in SIP websocket server then >>> >>> the dialog creation in the following topology breaks as follows: >>> >>> >>> >>> Topolgy: >>> >>> >>> >>> UAC SIP Websocket client (Browser)------Proxy SIP Websocket >>> Server------UAS (RFC 3261 UA) >>> >>> >>> >>> Callflow steps: >>> >>> >>> >>> 1) UAC SIP Websocket client initiates INVITE dialog towards SIP >> Websocket >>> server >>> >>> 2) INVITE is forwarded towards UAS by SIP Websocket server >> >> .. which adds a Record-Route header field because it wants to stay in >> the signaling path during the dialog ;-) >> >>> >>> 3) UAS receives INVITE and sent 200 OK response with contact address >> with >>> UDP transport >> >> it builds the 200 OK response taking the Record-Route headers from the >> received INVITE request. >> >>> >>> towards SIP Websocket server >>> >>> 4) SIP Websocket server forwards 200 OK towards SIP Websocket client >>> without record-route >> >> It receives 200 OK with the Record-Route headers >> >>> >>> 5) Whether SIP Websocket Client(browser) will be able to send ACK >> towards >>> UAS contact >>> >>> address in UDP transport? No. >>> >> >> ACK request will be formed with the dialog`s route set, being the >> first hop the SIP WebSocket Server. >> >>> >>> >>> In case normal RFC 3261 application or application based on SIP websock= et >>> client, ACK will send towards >>> >>> UAS contact address with UDP transport as per mandatory to implement >>> transport mechanism in RFC 3261. >>> >>> As browser acting as SIP Websocket client violates the mandatory to >>> implement transport mechanism, >>> >>> the callflow breaks in this specification. >>> >> >> Why didn't you add a Record-Route header in the point '2' ( INVITE is >> forwarded towards UAS by SIP Websocket server) ? >> >> You should have added if you wanted to stay in the signaling path >> during the dialog. This is stated in RFC 3261. The reason your ACK >> does not reach the destination is a configuration problem more that >> specification definition issue. >> >>> >>> >>> In case you wish to put some other text, Please let us discuss. >>> >>> >>> >>> Thanks >>> >>> Partha >>> >> >> Regards. >> >>> >>> >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Beh= alf >>> Of Jos=E9 Luis Mill=E1n >>> Sent: Thursday, August 23, 2012 9:46 PM >>> To: Parthasarathi R >>> Cc: sipcore@ietf.org >>> Subject: Re: [sipcore] Mandatory to implement transport comment on >>> draft-ibc-sipcore-sip-websocket-02 >>> >>> >>> >>> Hi, >>> >>> 2012/8/23 Parthasarathi R >>> >>> Hi all, >>> >>> >>> >>> As I discussed during IETF-84 meeting, the following text is provided = for >>> the starting the discussion on deviation of RFC 3261 mandatory to >> implement >>> (UDP/TCP) transport in this draft. >>> >>> >>> >>> =93In case SIP WebSocket Client is a web browser and SIP Websocket Serv= er is >> a >>> SIP proxy, then record-route header MUST be included by SIP Websocket >> server >>> in all SIP messages. This requirement assures that SIP WebSocket Client= is >>> able to contact with UAS through SIP Websocket Server during the >> mid-dialog >>> irrespective of the contact SIP URI received from UAS =94 >>> >>> >>> >>> Record-Route header field is useful for a proxy in order to remain in t= he >>> dialog path. It is not necessary for all SIP messages. This is defined = in >>> RFC 3261 as 'loose routing' and draft-ibc-sipcore-sip-websocket-02 does >> not >>> change it at all. >>> >>> >>> >>> Section 2 of Apendix A (Implementation guidelines) already mentions it: >>> >>> >>> >>> " >>> >>> The proxy performs Loose Routing and remains in dialogs path as >>> >>> specified in [RFC3261]. Otherwise in-dialog requests would fail >>> >>> since SIP WebSocket Clients make use of their SIP WebSocket Server i= n >>> >>> order to send and receive SIP requests and responses. >>> >>> " >>> >>> >>> >>> Regards, >>> >>> >>> >>> The above normative statement will be update to RFC 3261. >>> >>> >>> >>> Thanks >>> >>> Partha >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From ibc@aliax.net Fri Aug 24 11:42:35 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F68321F8717 for ; Fri, 24 Aug 2012 11:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.661 X-Spam-Level: X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usWBltmn+CdI for ; Fri, 24 Aug 2012 11:42:34 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0428621F8711 for ; Fri, 24 Aug 2012 11:42:33 -0700 (PDT) Received: by lahm15 with SMTP id m15so1389445lah.31 for ; Fri, 24 Aug 2012 11:42:32 -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=bOlcVnxJE4VPpwaWbv1mKrHLcF7zhws+Z22lNNmjm8A=; b=X/8h3LAu2hDFDoglY/UHqJfcvJS+vbc90cn+RqSAs57j7SY3BPkFomz1M1QfTAkt+k JzJWAxzSs5/NfCVT+2EuSDJfTCn9dwC734K52B7yG/kjo3IJeXRs4e6sN8iJqdpKdXHS jJGx4el8kAiBv43h0PX4jT53kFCwD4k67Ogz/zkGEDsSiDkwv7TXW9ZugPT/fCB2/ttc BkHNvbHyKyo65ql5z5zoMWIFjUFmRCE+WazbowE1hiBpO7Siqvs+NFLsLB4Uy+MA/1Je 3ksqVASSnjz1WR7HAv907EI59K33C0An52ccvPBbsuxiuNv0z13+P/0XMkyKibPI5XDU D7kw== Received: by 10.152.46.49 with SMTP id s17mr6752979lam.17.1345833752675; Fri, 24 Aug 2012 11:42:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.7 with HTTP; Fri, 24 Aug 2012 11:42:12 -0700 (PDT) In-Reply-To: <000f01cd8214$9d255a00$d7700e00$@co.in> References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 24 Aug 2012 20:42:12 +0200 Message-ID: To: Parthasarathi R Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmV+oTIG6yNvAXH8EOa6iXoB6gxC1B9BWKYKOeZ0luMvXuMbwCt6PIJw+M1nUoaWZ3p2ZzO Cc: sipcore@ietf.org, =?UTF-8?B?Sm9zw6kgTHVpcyBNaWxsw6Fu?= Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 18:42:35 -0000 2012/8/24 Parthasarathi R : > Topolgy: > > UAC SIP Websocket client (Browser)------Proxy SIP Websocket > Server------UAS (RFC 3261 UA) > > Callflow steps: > > 1) UAC SIP Websocket client initiates INVITE dialog towards SIP Websoc= ket > server > > 2) INVITE is forwarded towards UAS by SIP Websocket server > > 3) UAS receives INVITE and sent 200 OK response with contact address w= ith > UDP transport > > towards SIP Websocket server > > 4) SIP Websocket server forwards 200 OK towards SIP Websocket client > without record-route > > 5) Whether SIP Websocket Client(browser) will be able to send ACK towa= rds > UAS contact address in UDP transport? No. > > In case normal RFC 3261 application or application based on SIP websocket > client, ACK will send towards UAS contact address with UDP transport as p= er mandatory to implement > transport mechanism in RFC 3261. > > As browser acting as SIP Websocket client violates the mandatory to > implement transport mechanism, the callflow breaks in this specification. Hi Partha, please read the following scenario: UAC SIP UDP/TCP client ------ Proxy SIP ----- UAS SIP UDP/TCP/SCTP Callflow steps: 1) UAC resolves via RFC3263 the transport and destination of the Proxy (UDP is the first NAPTR option) and uses UDP to send an INVITE to the AoR of UAS through the Proxy. The INVITE has a Contact URI with ;transport=3Dudp. 2) INVITE arrives to the Proxy which does NOT add Record-Route, performs RFC3263 with the Request-URI (SCTP is the preferred transport) and opens an SCTP connection with UAS for forwarding the INVITE. 3) UAS receives INVITE and sent 200 OK response with Contact address with ;transport=3Dsctp. 4) Proxy forwards the 200 OK to UAC (no Record-Route). 5) UAC should now send the ACK by opening an SCTP connection with UAS. Can UAC do that? not, because it does NOT implement SCTP transport. So the only solution here is for the Proxy to add Record-Route to the initial INVITE. Please let me know where RFC 4168 (SIP SCTP transport) talks about this scenario and where the RFC mentions the words "Record-Route" or "Proxy" (it does not). So, shouldn't RFC 4168 also update RFC 3261 by stating that "If an INVITE arrives to a proxy through an SCTP connection and the proxy forwards it via UDP or TCP then it MUST/SHOULD add Record-Route headers"? It does not so, why should the sip-websocket draft mandate it? Please, reply. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From rjsparks@nostrum.com Fri Aug 24 11:46:03 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D5521F8712 for ; Fri, 24 Aug 2012 11:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htuiCFiew9Z3 for ; Fri, 24 Aug 2012 11:46:02 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 49CAF21F86B7 for ; Fri, 24 Aug 2012 11:46:02 -0700 (PDT) Received: from unnumerable.local ([4.30.77.1]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7OIk0QY085688 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 24 Aug 2012 13:46:01 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5037CBE7.6070006@nostrum.com> Date: Fri, 24 Aug 2012 13:45:59 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "sipcore@ietf.org" , draft-ietf-sipcore-rfc4244bis@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 4.30.77.1 is authenticated by a trusted mechanism) Subject: [sipcore] AD review: draft-ietf-sipcore-rfc4244bis-08 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, 24 Aug 2012 18:46:03 -0000 Summary: There are a couple of questions to discuss before progressing to IETF LC. This document is much easier to follow than RFC4244. It is still complex, but the rewrite effort improved its readability significantly. There are a couple of things I would like the WG to consider before moving into IETF LC. 1) Since the WG adopted the call-flows document, does this document still need Appendix A, or should any of the examples there that are not already in the call-flows document be moved to that document? 2) The document requires that redirect servers include an hi-target-param in the Contact header fields it provides, and requires elements recursing on redirect responses to only include hi-target-params that it finds in those Contacts. They are specifically forbidden from providing the param if there are no params in the Contact. Please consider saying why this is required. If I recall the conversation correctly, it's because the redirect server is the only element that can tell whether mp or rc would be appropriate. For np, however, it's not clear why this requirement exists. Is it just to keep things simple? 3) Section 103 step 6 says "If the request clearly has a gap", but I don't see any description of what an element is supposed to look for to determine there is a gap. From a discussion with Mary, it should be as simple as comparing the last HI entry to the Request-URI. If that's right, please add that to this description, and make it clear that you would only add one .0. when identifying a gap, not try to figure out how many elements may have not added history (that is, you would never produce something that looked like 1.0.0.1). 4) The Changes from RFC4244 section doesn't call out the new .0. gap detection/representation mechanic. 5) The backwards compatibility consideration focuses on exploring how RFC4244 elements will deal with messages created following this specification. There should be some additional exploration of how elements implementing this specification will deal with messages created by RFC4244 elements. Those messages could be missing things this specification says MUST be there. Can we make it more likely that an implementer won't create code that rejects such messages as malformed? Nits: At the definition of hi-index, the document talks of "nesting of requests". It's the only place the word nesting occurs in the document. Could you provide a description/definition or a pointer to one? The description of using an internal cache to describe how an element will construct the history-info values it emits is likely to draw discussion during IETF/IESG review. It uses 2119 language to describe a possible implementation. Please consider changing the phrasing to make it clear that the normative constraints are on what's emitted, not on they way you store the information internally. First paragraph of 10.4 still says "two header field parameters" and "Both", but talks about three. "As for the behavior of the entity followings have changed" does not parse. In the first example in appendix A, the Contact in F3 has no parameters, but the corresponding H-I value in F4 has an mp=1. The version of this example in the callflow doc has the mp=1 in the Contact in the 302. From ibc@aliax.net Fri Aug 24 11:52:04 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0B621F8686 for ; Fri, 24 Aug 2012 11:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iInaN8FNRWmt for ; Fri, 24 Aug 2012 11:52:04 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A7BFA21F8685 for ; Fri, 24 Aug 2012 11:52:03 -0700 (PDT) Received: by lbky2 with SMTP id y2so585520lbk.31 for ; Fri, 24 Aug 2012 11:52:02 -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=VRKXEPJ2sMjG0KJJWTqP5qKNdnN/G2O43To5Kx097oI=; b=SzZwwlmgwh0Xsp/x8Jvm8We2oiHZ040CtpYmCZYZ1BZKvtbpRRNxczzsQfW9CrZWXn zHogUoeswhDZJmzKKfGDEQiqKFuUGIiSUvbeZVxGfyOj+4nYmziS6oNj11bo4Bg24kvL jMJUaJMiWXzIcqkRDmoSkmYlxEiNU9N1ZaEOz7u0q0K4VDrtUgyxfOv8Otw3Jk5dq3gA 3ebD4ekz8IimJOdF9hvdg1oApgpu2MCM0vILqARK1bN9DZ7XyJJ7qHC/A4+mAV8fPeYo HO0yDVg98EENHJiOZEDzXnwPkZW8putdtVCjb/VS2s9tkibQpxITnPDDL/xIz97+9OWs KU2g== Received: by 10.152.46.49 with SMTP id s17mr6776335lam.17.1345834322605; Fri, 24 Aug 2012 11:52:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.7 with HTTP; Fri, 24 Aug 2012 11:51:42 -0700 (PDT) In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9467@EXMBXCLUS01.citservers.local> References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9467@EXMBXCLUS01.citservers.local> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 24 Aug 2012 20:51:42 +0200 Message-ID: To: Brett Tate Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkqErnc+7Ycp3ZDTPtU34dBCkQGAWPvB8w5BCH2+WavsYfaey5WMqEGrRsu+KqnDO1LXr4E Cc: "sipcore@ietf.org" , "draft-ietf-sipcore-sip-websocket@tools.ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-sip-websocket-02: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 18:52:04 -0000 2012/8/24 Brett Tate : > The following are some minor comments concerning draft-ietf-sipcore-sip-w= ebsocket-02. Hi Brett, thanks a lot. Please read inline: > Section 8.2: > > - The response examples should likely indicate the Via "received" paramet= er when Via transport is UDP. Adding Via "received" is just mandatory in case the source IP of the request does not match the Via sentby-host component. > - Max-Forwards should likely be removed from response examples. Done in our working copy for the next version. > Section A.1: "hostpart" potentially should be "hostport". Done in our working copy for the next version. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From brett@broadsoft.com Fri Aug 24 12:13:43 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8702521F8535 for ; Fri, 24 Aug 2012 12:13:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwDqcols89G7 for ; Fri, 24 Aug 2012 12:13:42 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6A221F8555 for ; Fri, 24 Aug 2012 12:13:41 -0700 (PDT) Received: from casumhub01.citservers.local (172.16.98.57) by Xedge01.citservers.local (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 24 Aug 2012 12:17:21 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Fri, 24 Aug 2012 12:17:21 -0700 From: Brett Tate To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "sipcore@ietf.org" , "draft-ietf-sipcore-sip-websocket@tools.ietf.org" Date: Fri, 24 Aug 2012 12:13:39 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-sip-websocket-02: comments Thread-Index: Ac2CKhJCStOvTDQ0TkafZ/UzGCmu3gAAFK9g Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9538@EXMBXCLUS01.citservers.local> References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9467@EXMBXCLUS01.citservers.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-sip-websocket-02: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 19:13:43 -0000 PiA+IFNlY3Rpb24gOC4yOg0KPiA+DQo+ID4gLSBUaGUgcmVzcG9uc2UgZXhhbXBsZXMgc2hvdWxk IGxpa2VseSBpbmRpY2F0ZSB0aGUgDQo+ID4gVmlhICJyZWNlaXZlZCIgcGFyYW1ldGVyIHdoZW4g VmlhIHRyYW5zcG9ydCBpcyBVRFAuDQo+IA0KPiBBZGRpbmcgVmlhICJyZWNlaXZlZCIgaXMganVz dCBtYW5kYXRvcnkgaW4gY2FzZQ0KPiB0aGUgc291cmNlIElQIG9mIHRoZSByZXF1ZXN0IGRvZXMg bm90IG1hdGNoIHRoZSANCj4gVmlhIHNlbnRieS1ob3N0IGNvbXBvbmVudC4NCg0KSGkgScOxYWtp LA0KDQpUaGUgZm9sbG93aW5nIGlzIHRoZSBSRkMgMzI2MSBzZWN0aW9uIDE4LjIuMSBzbmlwcGV0 IGluZGljYXRpbmcgdGhhdCB0aGUgInJlY2VpdmVkIiBwYXJhbWV0ZXIgbXVzdCBiZSBhZGRlZCBp ZiB0aGUgVmlhIHNlbnQtYnkgaXMgYSBkb21haW4gbmFtZS4gIElmIHRoZSBkcmFmdCBpbnRlbmRz IHRvIHNob3cgY29tcGxpYW50IGRldmljZXMgZm9yIFVEUCwgdGhlIGZvbGxvd2luZyBtZXNzYWdl cyBzaG91bGQgaW5kaWNhdGUgdGhlIHJlY2VpdmVkOiBGNCwgRjksIEYxMCwgRjExLg0KDQpSRkMg MzI2MSBzZWN0aW9uIDE4LjIuMToNCg0KIldoZW4gdGhlIHNlcnZlciB0cmFuc3BvcnQgcmVjZWl2 ZXMgYSByZXF1ZXN0IG92ZXIgYW55IHRyYW5zcG9ydCwgaXQNCiBNVVNUIGV4YW1pbmUgdGhlIHZh bHVlIG9mIHRoZSAic2VudC1ieSIgcGFyYW1ldGVyIGluIHRoZSB0b3AgVmlhDQogaGVhZGVyIGZp ZWxkIHZhbHVlLiAgSWYgdGhlIGhvc3QgcG9ydGlvbiBvZiB0aGUgInNlbnQtYnkiIHBhcmFtZXRl cg0KIGNvbnRhaW5zIGEgZG9tYWluIG5hbWUsIG9yIGlmIGl0IGNvbnRhaW5zIGFuIElQIGFkZHJl c3MgdGhhdCBkaWZmZXJzDQogZnJvbSB0aGUgcGFja2V0IHNvdXJjZSBhZGRyZXNzLCB0aGUgc2Vy dmVyIE1VU1QgYWRkIGEgInJlY2VpdmVkIg0KIHBhcmFtZXRlciB0byB0aGF0IFZpYSBoZWFkZXIg ZmllbGQgdmFsdWUuICBUaGlzIHBhcmFtZXRlciBNVVNUDQogY29udGFpbiB0aGUgc291cmNlIGFk ZHJlc3MgZnJvbSB3aGljaCB0aGUgcGFja2V0IHdhcyByZWNlaXZlZC4iDQoNCg0KVGhhbmtzLA0K QnJldHQNCg0K From brett@broadsoft.com Fri Aug 24 12:26:40 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC21D21F8616 for ; Fri, 24 Aug 2012 12:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rllcxG2Xp3B3 for ; Fri, 24 Aug 2012 12:26:40 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.203]) by ietfa.amsl.com (Postfix) with ESMTP id 63B1C21F8610 for ; Fri, 24 Aug 2012 12:26:40 -0700 (PDT) Received: from CASUMHUB02.citservers.local (172.16.98.161) by Xedge01.citservers.local (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 24 Aug 2012 12:30:20 -0700 Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Fri, 24 Aug 2012 12:30:19 -0700 From: Brett Tate To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "sipcore@ietf.org" , "draft-ietf-sipcore-sip-websocket@tools.ietf.org" Date: Fri, 24 Aug 2012 12:26:38 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-sip-websocket-02: comments Thread-Index: Ac2CKhJCStOvTDQ0TkafZ/UzGCmu3gAAFK9gAADbPwA= Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9545@EXMBXCLUS01.citservers.local> References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9467@EXMBXCLUS01.citservers.local> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9538@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9538@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-sip-websocket-02: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 19:26:41 -0000 T29wcywgc29ycnkgZm9yIHJlc2VuZC4gIEkganVzdCBub3RpY2VkIHRoZSBpcC1hZGRyZXNzZXMg d2l0aGluIEY5LCBGMTAsIEYxMTsgb25seSBGNCBzaG91bGQgYmUgY2hhbmdlZC4NCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBCcmV0dCBU YXRlDQo+IFNlbnQ6IEZyaWRheSwgQXVndXN0IDI0LCAyMDEyIDM6MTQgUE0NCj4gVG86IEnDsWFr aSBCYXogQ2FzdGlsbG87IHNpcGNvcmVAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtc2lwY29yZS1zaXAt DQo+IHdlYnNvY2tldEB0b29scy5pZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIGRy YWZ0LWlldGYtc2lwY29yZS1zaXAtd2Vic29ja2V0LTAyOiBjb21tZW50cw0KPiANCj4gPiA+IFNl Y3Rpb24gOC4yOg0KPiA+ID4NCj4gPiA+IC0gVGhlIHJlc3BvbnNlIGV4YW1wbGVzIHNob3VsZCBs aWtlbHkgaW5kaWNhdGUgdGhlDQo+ID4gPiBWaWEgInJlY2VpdmVkIiBwYXJhbWV0ZXIgd2hlbiBW aWEgdHJhbnNwb3J0IGlzIFVEUC4NCj4gPg0KPiA+IEFkZGluZyBWaWEgInJlY2VpdmVkIiBpcyBq dXN0IG1hbmRhdG9yeSBpbiBjYXNlDQo+ID4gdGhlIHNvdXJjZSBJUCBvZiB0aGUgcmVxdWVzdCBk b2VzIG5vdCBtYXRjaCB0aGUNCj4gPiBWaWEgc2VudGJ5LWhvc3QgY29tcG9uZW50Lg0KPiANCj4g SGkgScOxYWtpLA0KPiANCj4gVGhlIGZvbGxvd2luZyBpcyB0aGUgUkZDIDMyNjEgc2VjdGlvbiAx OC4yLjEgc25pcHBldCBpbmRpY2F0aW5nIHRoYXQNCj4gdGhlICJyZWNlaXZlZCIgcGFyYW1ldGVy IG11c3QgYmUgYWRkZWQgaWYgdGhlIFZpYSBzZW50LWJ5IGlzIGEgZG9tYWluDQo+IG5hbWUuICBJ ZiB0aGUgZHJhZnQgaW50ZW5kcyB0byBzaG93IGNvbXBsaWFudCBkZXZpY2VzIGZvciBVRFAsIHRo ZQ0KPiBmb2xsb3dpbmcgbWVzc2FnZXMgc2hvdWxkIGluZGljYXRlIHRoZSByZWNlaXZlZDogRjQs IEY5LCBGMTAsIEYxMS4NCj4gDQo+IFJGQyAzMjYxIHNlY3Rpb24gMTguMi4xOg0KPiANCj4gIldo ZW4gdGhlIHNlcnZlciB0cmFuc3BvcnQgcmVjZWl2ZXMgYSByZXF1ZXN0IG92ZXIgYW55IHRyYW5z cG9ydCwgaXQNCj4gIE1VU1QgZXhhbWluZSB0aGUgdmFsdWUgb2YgdGhlICJzZW50LWJ5IiBwYXJh bWV0ZXIgaW4gdGhlIHRvcCBWaWENCj4gIGhlYWRlciBmaWVsZCB2YWx1ZS4gIElmIHRoZSBob3N0 IHBvcnRpb24gb2YgdGhlICJzZW50LWJ5IiBwYXJhbWV0ZXINCj4gIGNvbnRhaW5zIGEgZG9tYWlu IG5hbWUsIG9yIGlmIGl0IGNvbnRhaW5zIGFuIElQIGFkZHJlc3MgdGhhdCBkaWZmZXJzDQo+ICBm cm9tIHRoZSBwYWNrZXQgc291cmNlIGFkZHJlc3MsIHRoZSBzZXJ2ZXIgTVVTVCBhZGQgYSAicmVj ZWl2ZWQiDQo+ICBwYXJhbWV0ZXIgdG8gdGhhdCBWaWEgaGVhZGVyIGZpZWxkIHZhbHVlLiAgVGhp cyBwYXJhbWV0ZXIgTVVTVA0KPiAgY29udGFpbiB0aGUgc291cmNlIGFkZHJlc3MgZnJvbSB3aGlj aCB0aGUgcGFja2V0IHdhcyByZWNlaXZlZC4iDQo+IA0KPiANCj4gVGhhbmtzLA0KPiBCcmV0dA0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g c2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From ibc@aliax.net Fri Aug 24 12:28:17 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DC721F858E for ; Fri, 24 Aug 2012 12:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.663 X-Spam-Level: X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-FfwVIkp+CP for ; Fri, 24 Aug 2012 12:28:16 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 71F9A21F8575 for ; Fri, 24 Aug 2012 12:28:15 -0700 (PDT) Received: by lahm15 with SMTP id m15so1412760lah.31 for ; Fri, 24 Aug 2012 12:28:14 -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=07CdQh+mKtIoYWGH3z1y4K+ZAm+TxThj4iBcnIEPKoE=; b=BDOGGxFRdMB7VKl772CpWJprw5pbh4xQzMT6soKZgwbASTOvsiIskLDQDJaEDTYrD2 fnwDHZQo9CjNtTyltyX9CrVpcdnnQiaT8YS+QoOA4d0nAgycsDP3vpaQa39m9vdweBH4 ZAKY5YfjI9EamGHxTl8ToiQPcZA/gaRNLbzTd1TIDdSNxm6nh15ORiD2MKSiNWxS00m5 igUzm0C0NeA9avz9c9D7hktQROR238rsREFWMszydZpon+fP1RZag7Ff8Fw8Ji9dQCSc CrMfVAfLodFVjawnoGsxs94Z307GezKqag/GvCT5iUMuixks5Ic5PJoWFcT8T3UDqjeV GGqA== Received: by 10.152.104.44 with SMTP id gb12mr6926158lab.29.1345836494270; Fri, 24 Aug 2012 12:28:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.3.7 with HTTP; Fri, 24 Aug 2012 12:27:54 -0700 (PDT) In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9545@EXMBXCLUS01.citservers.local> References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9467@EXMBXCLUS01.citservers.local> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9538@EXMBXCLUS01.citservers.local> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C2E3F9545@EXMBXCLUS01.citservers.local> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 24 Aug 2012 21:27:54 +0200 Message-ID: To: Brett Tate Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmquy8mECPk7grnrDh5TxPD8DuEKqvHm7QxcdJqtJAmT1gz0UFOZEki2rOGp1MvbFOHxVy4 Cc: "sipcore@ietf.org" , "draft-ietf-sipcore-sip-websocket@tools.ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-sip-websocket-02: comments X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 19:28:17 -0000 2012/8/24 Brett Tate : > Oops, sorry for resend. I just noticed the ip-addresses within F9, F10, = F11; only F4 should be changed. You are right, I missed that. Fixed in our local copy. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From internet-drafts@ietf.org Fri Aug 24 15:11:12 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F319021F861E; Fri, 24 Aug 2012 15:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11LAK1ICHGrQ; Fri, 24 Aug 2012 15:11:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8996721F8609; Fri, 24 Aug 2012 15:11:11 -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.34 Message-ID: <20120824221111.6718.42028.idtracker@ietfa.amsl.com> Date: Fri, 24 Aug 2012 15:11:11 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-07.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: Fri, 24 Aug 2012 22:11:12 -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 : Mechanism to indicate support of features and capabiliti= es in the Session Initiation Protocol (SIP) Author(s) : Christer Holmberg Ivo Sedlacek Hadriel Kaplan Filename : draft-ietf-sipcore-proxy-feature-07.txt Pages : 21 Date : 2012-08-24 Abstract: This specification defines a new SIP header field, Feature-Caps, to convey feature capability indicators, which are used by SIP entities not represented by the URI of the Contact header field to indicate support of features and capabilities, where media feature tags cannot be used to indicate the support. This specification also defines feature capability indicators, and creates a new IANA registry, "Proxy-Feature Feature Capability Indicator Trees", for registering feature capability indicators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-proxy-feature There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-proxy-feature-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Fri Aug 24 15:13:00 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F20B21F8525 for ; Fri, 24 Aug 2012 15:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1QDG4Y2NVkM for ; Fri, 24 Aug 2012 15:12:59 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0973B21F84E4 for ; Fri, 24 Aug 2012 15:12:58 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-e4-5037fc6ab4d3 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 35.24.25676.A6CF7305; Sat, 25 Aug 2012 00:12:58 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sat, 25 Aug 2012 00:12:57 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Date: Sat, 25 Aug 2012 00:12:56 +0200 Thread-Topic: Draft new version: proxy-feature-07 Thread-Index: AQHNgkWdKuAlp/OXlECu3R8UTHUthQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F1C@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+JvrW7WH/MAg0dHeCyuzWlks/j6YxOb A5PHkiU/mTxm7XzCEsAUxWWTkpqTWZZapG+XwJUxbfdctoLSiiOHf7A1MEZ1MXJySAiYSLTf usIEYYtJXLi3nq2LkYtDSOAUo8SSBZvYQRJCAgsYJX6er+pi5OBgE7CQ6P6nDRIWEdCUWP5t K1gJs4CGxJMpaxhBbBYBVYn9r26ygtjCAjoSd8+8YYaoN5TYd/AOI4StJ/Hq22awOK9AuMTZ hZPBbmAEuuH7qTVMEDPFJW49mQ91m4DEkj3nmSFsUYmXj/+xQtSLStxpX88IUa8ncWPqFDYI W1ti2cLXUPMFJU7OfMIygVFkFpKxs5C0zELSMgtJywJGllWMwrmJmTnp5UZ6qUWZycXF+Xl6 xambGIFRcHDLb9UdjHfOiRxilOZgURLntd66x19IID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD 47Q6m5BpzILrn/x7ftFg99wiNefv3pNe6ka1Hf5+ZpryottHhQ7YVmTvXhUhGFL4gU/z645z BWdfKtfsFF58+Ij+W547h5XD33LxOglZLmDe4LY4YN6mlSLtW/OO2MX3lLWJqPKoThY7yfRe ZUL6x3dnV9i25IQWm+q/ctBMPK6/fdq5X/0npimxFGckGmoxFxUnAgDyAdtjUAIAAA== Subject: [sipcore] Draft new version: proxy-feature-07 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, 24 Aug 2012 22:13:00 -0000 Hi, I've submitted a new version (-07) of proxy-feature, fixing the remaining i= ssues. Regards, Christer From rjsparks@nostrum.com Fri Aug 24 15:23:10 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8635F21F852B for ; Fri, 24 Aug 2012 15:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-etYXJ6vUQD for ; Fri, 24 Aug 2012 15:23:10 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id EF78B21F8534 for ; Fri, 24 Aug 2012 15:23:09 -0700 (PDT) Received: from unnumerable.local (pool-173-57-102-202.dllstx.fios.verizon.net [173.57.102.202]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q7OMN6rC006428 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 24 Aug 2012 17:23:06 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-ID: <5037FECA.6020306@nostrum.com> Date: Fri, 24 Aug 2012 17:23:06 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F1C@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F1C@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.57.102.202 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: proxy-feature-07 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, 24 Aug 2012 22:23:10 -0000 SIPCORE - There is quite a bit of new text here. It addresses my review comments. Please make sure you are all OK with these changes: RjS On 8/24/12 5:12 PM, Christer Holmberg wrote: > Hi, > > I've submitted a new version (-07) of proxy-feature, fixing the remaining issues. > > Regards, > > Christer From internet-drafts@ietf.org Fri Aug 24 16:47:39 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADAB21F844E; Fri, 24 Aug 2012 16:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ri4uEmQJXz86; Fri, 24 Aug 2012 16:47:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E382021F8646; Fri, 24 Aug 2012 16:47:38 -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.34 Message-ID: <20120824234738.26192.92411.idtracker@ietfa.amsl.com> Date: Fri, 24 Aug 2012 16:47:38 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-08.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Aug 2012 23:47:39 -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 : Mechanism to indicate support of features and capabiliti= es in the Session Initiation Protocol (SIP) Author(s) : Christer Holmberg Ivo Sedlacek Hadriel Kaplan Filename : draft-ietf-sipcore-proxy-feature-08.txt Pages : 21 Date : 2012-08-24 Abstract: This specification defines a new SIP header field, Feature-Caps, to convey feature capability indicators, which are used by SIP entities not represented by the URI of the Contact header field to indicate support of features and capabilities, where media feature tags cannot be used to indicate the support. This specification also defines feature capability indicators, and creates a new IANA registry, "Proxy-Feature Feature Capability Indicator Trees", for registering feature capability indicators. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-proxy-feature There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-proxy-feature-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From christer.holmberg@ericsson.com Fri Aug 24 16:50:04 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D6621F8670 for ; Fri, 24 Aug 2012 16:50:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.175 X-Spam-Level: X-Spam-Status: No, score=-6.175 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mt8j7Mzku-oj for ; Fri, 24 Aug 2012 16:50:04 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 67E3521F8534 for ; Fri, 24 Aug 2012 16:50:03 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-8d-50381329e4ab Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8E.5C.11467.92318305; Sat, 25 Aug 2012 01:50:02 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sat, 25 Aug 2012 01:50:01 +0200 From: Christer Holmberg To: "sipcore@ietf.org" Date: Sat, 25 Aug 2012 01:50:00 +0200 Thread-Topic: Draft new version: proxy-feature-08 Thread-Index: Ac2CUyy6Zoi7Gd4HRi2ENQOyuC/HuQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3A8F@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340A1E3A8FESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvra6WsEWAwZ7TXBbX5jSyWZx6dZrZ 4uuPTWwOzB5Llvxk8pi18wmLx5fLn9kCmKO4bFJSczLLUov07RK4Mv6s/s1U0MtX0XRmH1sD 43yeLkZODgkBE4muM7MZIWwxiQv31rN1MXJxCAmcYpRo7H8L5SxglDh0eiZLFyMHB5uAhUT3 P22QBhEBTYnl37ayg9jMAjES2zZ9YAGxWQRUJZbv+QdmCwvoSNx538AKUW8o8XrvNGYIW09i y6mHYDavQDhQ/VQwmxHoiO+n1jBBzBSXuPVkPhPEcQISS/acZ4awRSVePv7HClEvKnGnfT0j RH2+xPt3s1ggZgpKnJz5hGUCo/AsJKNmISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDF FzCyr2IUzk3MzEkvN9RLLcpMLi7Oz9MrTt3ECIyng1t+6+5gPHVO5BCjNAeLkjgvV9J+fyGB 9MSS1OzU1ILUovii0pzU4kOMTBycUg2MpaF9J1cX23sdK87O/XZVJijCuH7frDnyN+10lt65 8XTNzYfRauUn5+Xd89psLfOPPzS3fbfNLpv9itfFZevLpv62+3Hxa4b75+D1vzIfTJzi56he n/943fOEew9rLAWifJwbz77gtbFWmnlwb4VhwPoqgxlvl/i27T4iuzrxbNuSp8+4T/FMUWIp zkg01GIuKk4EAKPrIUt1AgAA Cc: 'SIPCORE Chairs' Subject: [sipcore] Draft new version: proxy-feature-08 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, 24 Aug 2012 23:50:04 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A1E3A8FESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Yet another new version (-08) of proxy-feature, due to some xml2rfc feature= s that didn't work as expected :) The only difference between -07 and -08 is that I manually had to add "XXXX= " (which will be replaced by the assigned RFC number later) in a few places= . Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340A1E3A8FESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Yet another new version (-08) of proxy-feature, due t= o some xml2rfc features that didn't work as expected :)
 
The only difference between -07 and -08 is that I man= ually had to add "XXXX" (which will be replaced by the assigned R= FC number later) in a few places.
 
Regards,
 
Christer
 
 --_000_7F2072F1E0DE894DA4B517B93C6A0585340A1E3A8FESESSCMS0356e_-- From partha@parthasarathi.co.in Sat Aug 25 08:51:50 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322BE21F84CE for ; Sat, 25 Aug 2012 08:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.361 X-Spam-Level: X-Spam-Status: No, score=-1.361 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZL2ATJRnpVu for ; Sat, 25 Aug 2012 08:51:49 -0700 (PDT) Received: from outbound-us2.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.236]) by ietfa.amsl.com (Postfix) with ESMTP id A76FE21F84CF for ; Sat, 25 Aug 2012 08:51:49 -0700 (PDT) Received: from userPC (unknown [122.179.24.14]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us2.mailhostbox.com (Postfix) with ESMTPA id 37448638D9D; Sat, 25 Aug 2012 15:51:44 +0000 (GMT) From: "Parthasarathi R" To: =?utf-8?Q?'I=C3=B1aki_Baz_Castillo'?= References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> In-Reply-To: Date: Sat, 25 Aug 2012 21:21:37 +0530 Message-ID: <000001cd82d9$868aa640$939ff2c0$@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: Ac2CKDmV7CMqfXDcQ6e/UeKTCTQrJQAsQb1Q Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B0204.5038F495.0012, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: sipcore@ietf.org, =?utf-8?Q?'Jos=C3=A9_Luis_Mill=C3=A1n'?= Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 15:51:50 -0000 Inaki, I could not see the relation between UAC SIP Websocket client violates = RFC 3261 normative statement and your callflow. In your callflow, the = dialog fails because of the extension is not supported by UAC. Thanks Partha=20 -----Original Message----- From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net]=20 Sent: Saturday, August 25, 2012 12:12 AM To: Parthasarathi R Cc: Jos=C3=A9 Luis Mill=C3=A1n; sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on = draft-ibc-sipcore-sip-websocket-02 2012/8/24 Parthasarathi R : > Topolgy: > > UAC SIP Websocket client (Browser)------Proxy SIP Websocket > Server------UAS (RFC 3261 UA) > > Callflow steps: > > 1) UAC SIP Websocket client initiates INVITE dialog towards SIP = Websocket > server > > 2) INVITE is forwarded towards UAS by SIP Websocket server > > 3) UAS receives INVITE and sent 200 OK response with contact = address with > UDP transport > > towards SIP Websocket server > > 4) SIP Websocket server forwards 200 OK towards SIP Websocket = client > without record-route > > 5) Whether SIP Websocket Client(browser) will be able to send ACK = towards > UAS contact address in UDP transport? No. > > In case normal RFC 3261 application or application based on SIP = websocket > client, ACK will send towards UAS contact address with UDP transport = as per mandatory to implement > transport mechanism in RFC 3261. > > As browser acting as SIP Websocket client violates the mandatory to > implement transport mechanism, the callflow breaks in this = specification. Hi Partha, please read the following scenario: UAC SIP UDP/TCP client ------ Proxy SIP ----- UAS SIP UDP/TCP/SCTP Callflow steps: 1) UAC resolves via RFC3263 the transport and destination of the Proxy (UDP is the first NAPTR option) and uses UDP to send an INVITE to the AoR of UAS through the Proxy. The INVITE has a Contact URI with ;transport=3Dudp. 2) INVITE arrives to the Proxy which does NOT add Record-Route, performs RFC3263 with the Request-URI (SCTP is the preferred transport) and opens an SCTP connection with UAS for forwarding the INVITE. 3) UAS receives INVITE and sent 200 OK response with Contact address with ;transport=3Dsctp. 4) Proxy forwards the 200 OK to UAC (no Record-Route). 5) UAC should now send the ACK by opening an SCTP connection with UAS. Can UAC do that? not, because it does NOT implement SCTP transport. So the only solution here is for the Proxy to add Record-Route to the initial INVITE. Please let me know where RFC 4168 (SIP SCTP transport) talks about this scenario and where the RFC mentions the words "Record-Route" or "Proxy" (it does not). So, shouldn't RFC 4168 also update RFC 3261 by stating that "If an INVITE arrives to a proxy through an SCTP connection and the proxy forwards it via UDP or TCP then it MUST/SHOULD add Record-Route headers"? It does not so, why should the sip-websocket draft mandate it? Please, reply. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From partha@parthasarathi.co.in Sat Aug 25 09:07:11 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A515D21F84DD for ; Sat, 25 Aug 2012 09:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.512 X-Spam-Level: X-Spam-Status: No, score=-1.512 tagged_above=-999 required=5 tests=[AWL=0.453, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFsDSUA3T5Is for ; Sat, 25 Aug 2012 09:07:11 -0700 (PDT) Received: from outbound-us2.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.234]) by ietfa.amsl.com (Postfix) with ESMTP id EDAC121F84DC for ; Sat, 25 Aug 2012 09:07:10 -0700 (PDT) Received: from userPC (unknown [122.179.24.14]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us2.mailhostbox.com (Postfix) with ESMTPA id 6C5843E1995; Sat, 25 Aug 2012 16:07:03 +0000 (GMT) From: "Parthasarathi R" To: =?utf-8?Q?'I=C3=B1aki_Baz_Castillo'?= , =?utf-8?Q?'Jos=C3=A9_Luis_Mill=C3=A1n'?= References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> In-Reply-To: Date: Sat, 25 Aug 2012 21:36:56 +0530 Message-ID: <000101cd82db$ab93a0c0$02bae240$@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: Ac2CFwoqLKbcycXFQEyMrONHXP+0QQABr09wAC7wDdA= Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B020A.5038F82E.002A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 16:07:11 -0000 Inaki/Jose, Your current argument in the different mail of this same mail thread = argue for not to close this open item which allows to relaxing the = criteria for mandatory to implement (UDP/TCP) transport. If so, SIP over = Websocket client MUST support UDP & TCP as SIP transport to meet RFC = 3261 normative statement. Please note that SIP over Websocket = implementation with UDP & TCP as SIP transport is possible by = Linux/Windows application but not by Browser as of now. I'll like to hear more opinion from different folks before closing this = open item. Thanks Partha -----Original Message----- From: Parthasarathi R [mailto:partha@parthasarathi.co.in]=20 Sent: Friday, August 24, 2012 11:11 PM To: 'I=C3=B1aki Baz Castillo' Cc: 'Jos=C3=A9 Luis Mill=C3=A1n'; 'sipcore@ietf.org' Subject: RE: [sipcore] Mandatory to implement transport comment on = draft-ibc-sipcore-sip-websocket-02 Inaki, Paul started the relaxing the criteria for mandatory to implement = transport mail thread during WG adoption of SIP over websocket draft and = one of the mail is = http://www.ietf.org/mail-archive/web/sipcore/current/msg04930.html. My = understanding of the mail thread conclusion was that narrow approach of = providing leniency for mandatory to implement transport in SIP over = Websocket draft itself. I noticed in the current document that there is = no relevant text for this leniency and so raised the issue in IETF-84 = SIPCore meeting. As per IETF-84 SIPCore meeting discussion, I started = this mail thread. In case you are not in favor of narrow approach proposed by Paul, then = it is a separate discussion. Also you have indicated that the narrow = approach needs more text, then please suggest the text and let us = discuss. Thanks Partha=20 -----Original Message----- From: I=C3=B1aki Baz Castillo [mailto:ibc@aliax.net]=20 Sent: Friday, August 24, 2012 10:09 PM To: Parthasarathi R Cc: Jos=C3=A9 Luis Mill=C3=A1n; sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on = draft-ibc-sipcore-sip-websocket-02 2012/8/24 Parthasarathi R : > In case normal RFC 3261 application or application based on SIP = websocket > client, ACK will send towards > > UAS contact address with UDP transport as per mandatory to implement > transport mechanism in RFC 3261. > > As browser acting as SIP Websocket client violates the mandatory to > implement transport mechanism, > > the callflow breaks in this specification. Hi Partha. As said many times this draft is not *just* about web browsers. Please imagine that new versions of iOS and Android come with a WebSocket Client stack (so native apps can use it). Should we also add them to the draft?: =E2=80=9CIn case SIP WebSocket Client is a web browser or a native iOS = or Android application, and SIP Websocket Server is a SIP proxy, then..." Ugly, agree? Anyhow, for the case of a web browser (which indeed cannot send a UDP datagram) the draft already describes a full guideline in the Appendix section: http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02#appendix-A IMHO that's enough. The mandatory sections of the draft should not focus just on web browsers. BTW your text is incomplete: =E2=80=9CIn case SIP WebSocket Client is a web browser and SIP Websocket Server is a SIP proxy, then record-route header MUST be included by SIP Websocket server in all SIP messages. This requirement assures that SIP WebSocket Client is able to contact with UAS through SIP Websocket Server during the mid-dialog irrespective of the contact SIP URI received from UAS =E2=80=9D That's not enough. If you want to also *receive* incoming requests you need to mandate Outbound RFC 5626 (since the proxy cannot establish a WebSocket connection with a web browser). But we don't want to mandate Outbound (it was discussed and voted in Paris) since the draft just describes a SIP transport and does not assume specific topologies or UA devices. IMHO the Appendix guideline (which was already discussed in this WG) is the appropriate section for talking about specific common scenarios. The draft should not "update" RFC 3261 just for the case of web browsers. Regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Sat Aug 25 11:50:41 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 416BC21F84F9 for ; Sat, 25 Aug 2012 11:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.018 X-Spam-Level: X-Spam-Status: No, score=-6.018 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86H+jk6ZtSsG for ; Sat, 25 Aug 2012 11:50:40 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id D9DA121F84E4 for ; Sat, 25 Aug 2012 11:50:27 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-b2-50391e72cc88 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id EE.C6.11467.27E19305; Sat, 25 Aug 2012 20:50:26 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 25 Aug 2012 20:50:26 +0200 From: Christer Holmberg To: Parthasarathi R , =?Windows-1252?Q?=27I=F1aki_Baz_Castillo=27?= , =?Windows-1252?Q?=27Jos=E9_Luis_Mill=E1n=27?= Date: Sat, 25 Aug 2012 20:46:07 +0200 Thread-Topic: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 Thread-Index: Ac2CFwoqLKbcycXFQEyMrONHXP+0QQABr09wAC7wDdAABhbq9Q== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F25@ESESSCMS0356.eemea.ericsson.se> References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> , <000101cd82db$ab93a0c0$02bae240$@co.in> In-Reply-To: <000101cd82db$ab93a0c0$02bae240$@co.in> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+JvrW6RnGWAwfc7RhbT99lYrDtgYjH5 Ux+rxdcfm9gcWDzONbxn91iy5CeTx4f5X9gDmKO4bFJSczLLUov07RK4Mr5NUig4qllxrfEV UwPjL8UuRk4OCQETib1b97BC2GISF+6tZ+ti5OIQEjjFKDHnzE5mCGcBo8SkmUeBMhwcbAIW Et3/tEHiIgLbGCWef77LDNLNLKAp8WjnXiYQm0VAVaL/4yIWEFtYIF1i6d23jCC2iECGxO3f V6FsJ4ln1/+B1fAKhEvcX7CVEWLZZCaJL8fvsoEkOIHOe3yiA6yBEei876fWMEEsE5e49WQ+ E8TZAhJL9pxnhrBFJV4+/scKUS8qcad9PSNEvYHE+3PzoQ7Vlli28DUzxGJBiZMzn7BMYBSb hWTsLCQts5C0zELSsoCRZRWjcG5iZk56uaFealFmcnFxfp5eceomRmBcHdzyW3cH46lzIocY pTlYlMR5uZL2+wsJpCeWpGanphakFsUXleakFh9iZOLglGpgbPg0P+zDhBtrpVOMP70/rljZ vP7dg7McC5epvWs3y7lhX3FqcgiTbdLXdUxsawUu5C799maR0MS0IqP3m7ale8RKRtScSvgk Lb5u9ep3T587rHkz9+P1R0JBD6+Id593KIlq22DbzOwtWhDpK5h/826f+drZ2xybeZ7a9V4X UO6+HZCqPMdwhRJLcUaioRZzUXEiAD8USkR5AgAA Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Aug 2012 18:50:41 -0000 Hi, I am not sure who I agree/disagree with, but my opinion is that a WebSocket= UA shall not be mandated to implement UDP and TCP. A WebSocket UA might work in an environement where it can't use UDP or TCP = anyway. For example, if a JavaScript SIP UA in a browser technically can on= ly use WebSocket for SIP, why mandate it to implement something that it can= 't use??? As far as the WebServer SIP proxy it concerned, it MUST Record-Route. Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Part= hasarathi R [partha@parthasarathi.co.in] Sent: Saturday, August 25, 2012 7:06 PM To: 'I=F1aki Baz Castillo'; 'Jos=E9 Luis Mill=E1n' Cc: sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on dra= ft-ibc-sipcore-sip-websocket-02 Inaki/Jose, Your current argument in the different mail of this same mail thread argue = for not to close this open item which allows to relaxing the criteria for m= andatory to implement (UDP/TCP) transport. If so, SIP over Websocket client= MUST support UDP & TCP as SIP transport to meet RFC 3261 normative stateme= nt. Please note that SIP over Websocket implementation with UDP & TCP as SI= P transport is possible by Linux/Windows application but not by Browser as = of now. I'll like to hear more opinion from different folks before closing this ope= n item. Thanks Partha -----Original Message----- From: Parthasarathi R [mailto:partha@parthasarathi.co.in] Sent: Friday, August 24, 2012 11:11 PM To: 'I=F1aki Baz Castillo' Cc: 'Jos=E9 Luis Mill=E1n'; 'sipcore@ietf.org' Subject: RE: [sipcore] Mandatory to implement transport comment on draft-ib= c-sipcore-sip-websocket-02 Inaki, Paul started the relaxing the criteria for mandatory to implement transport= mail thread during WG adoption of SIP over websocket draft and one of the = mail is http://www.ietf.org/mail-archive/web/sipcore/current/msg04930.html.= My understanding of the mail thread conclusion was that narrow approach of= providing leniency for mandatory to implement transport in SIP over Websoc= ket draft itself. I noticed in the current document that there is no relev= ant text for this leniency and so raised the issue in IETF-84 SIPCore meeti= ng. As per IETF-84 SIPCore meeting discussion, I started this mail thread. In case you are not in favor of narrow approach proposed by Paul, then it i= s a separate discussion. Also you have indicated that the narrow approach n= eeds more text, then please suggest the text and let us discuss. Thanks Partha -----Original Message----- From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] Sent: Friday, August 24, 2012 10:09 PM To: Parthasarathi R Cc: Jos=E9 Luis Mill=E1n; sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ib= c-sipcore-sip-websocket-02 2012/8/24 Parthasarathi R : > In case normal RFC 3261 application or application based on SIP websocket > client, ACK will send towards > > UAS contact address with UDP transport as per mandatory to implement > transport mechanism in RFC 3261. > > As browser acting as SIP Websocket client violates the mandatory to > implement transport mechanism, > > the callflow breaks in this specification. Hi Partha. As said many times this draft is not *just* about web browsers. Please imagine that new versions of iOS and Android come with a WebSocket Client stack (so native apps can use it). Should we also add them to the draft?: =93In case SIP WebSocket Client is a web browser or a native iOS or Android application, and SIP Websocket Server is a SIP proxy, then..." Ugly, agree? Anyhow, for the case of a web browser (which indeed cannot send a UDP datagram) the draft already describes a full guideline in the Appendix section: http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02#appendix-A IMHO that's enough. The mandatory sections of the draft should not focus just on web browsers. BTW your text is incomplete: =93In case SIP WebSocket Client is a web browser and SIP Websocket Server is a SIP proxy, then record-route header MUST be included by SIP Websocket server in all SIP messages. This requirement assures that SIP WebSocket Client is able to contact with UAS through SIP Websocket Server during the mid-dialog irrespective of the contact SIP URI received from UAS =94 That's not enough. If you want to also *receive* incoming requests you need to mandate Outbound RFC 5626 (since the proxy cannot establish a WebSocket connection with a web browser). But we don't want to mandate Outbound (it was discussed and voted in Paris) since the draft just describes a SIP transport and does not assume specific topologies or UA devices. IMHO the Appendix guideline (which was already discussed in this WG) is the appropriate section for talking about specific common scenarios. The draft should not "update" RFC 3261 just for the case of web browsers. Regards. -- I=F1aki Baz Castillo _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From jmillan@aliax.net Sun Aug 26 03:09:40 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E358921F8513 for ; Sun, 26 Aug 2012 03:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-tRSiUaau0k for ; Sun, 26 Aug 2012 03:09:40 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F88B21F8512 for ; Sun, 26 Aug 2012 03:09:38 -0700 (PDT) Received: by lahm15 with SMTP id m15so2059547lah.31 for ; Sun, 26 Aug 2012 03:09:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=pNKrU8QbTkJTyCtjVfc4AS2TxmWYNgQYLT9jCiz75WA=; b=HMvpjd1mZKqFyI2ZMmK4lTaCsrMmvsYVF3Bgoe1yrN5egEqJ1D3t38hxVffCzIPqjE xm+N0pckX5nU7kI7ynDBu3i85V4NQdc7Xr5omLCZ8ePtTYrSCHG4+vas2QNov42q/YGl hF4AqL9vj67EIg0PMyngFcl7Oys48UygMjwgCYTGvmxJ7JPjjcbG07Vd3o8sBnEgGdz5 PgF0nKPo5/R4/igPSYNiys+EpF3141lBJc7Kg+dJ8a8iizEyrC6prAPVn5OifL2S6uKw bQED7u87qCTzvmyzuTNDFCTI3PImQ8aWqEgQkySIXy6Gg4zco/4N+1Y4AVTxSalKmKNd sAYw== MIME-Version: 1.0 Received: by 10.152.46.209 with SMTP id x17mr10896832lam.38.1345975777850; Sun, 26 Aug 2012 03:09:37 -0700 (PDT) Received: by 10.112.94.33 with HTTP; Sun, 26 Aug 2012 03:09:37 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F25@ESESSCMS0356.eemea.ericsson.se> References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> <000101cd82db$ab93a0c0$02bae240$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F25@ESESSCMS0356.eemea.ericsson.se> Date: Sun, 26 Aug 2012 12:09:37 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: Christer Holmberg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnu7ROtHhS7qhGrnv4SLyXYtOPtIaCsdG7yMKd7HdpwbQ5EJ0diU7eHqegjlm8VjSeOeKJr Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , "sipcore@ietf.org" , Parthasarathi R Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 10:09:41 -0000 Hi, Most WebSocket implementations do not allow (and there is no evidence they will in the near future) receiving incoming connections. They can only establish outgoing connections with WebSocket server implementations. The specification of this new transport allows SIP to be used as a session establishment protocol in the World Wide Web, in scenarios where non of other transport protocols defined for SIP can be used. SIP is the one entering in the WWW within this draft, allowing massively used applications to use our loving protocol. Most of those applications do not implement any existing SIP transport but WebSocket, the one we are adopting in this document. This specification defines the way SIP WebSocket Client and Server communicate and the mechanisms for the SIP element acting as WebSocket Server to interact with other non WebSocket SIP elements. We authors propose the following statements to be used in this specification according to this task: " SIP WebSocket Servers implementing this specification MUST implement UDP and TCP as stated in [RFC 3261]. SIP WebSocket Clients implementing this specification MAY implement UDP and TCP protocols, being their interoperability guaranteed by SIP WebSocket Servers which MUST be used as the first hop in the signaling path. " Of course, by definition, a SIP WebSocket server MUST Record-Route. Any comment about the proposed statements is appreciated. Regards, 2012/8/25 Christer Holmberg : > Hi, > > I am not sure who I agree/disagree with, but my opinion is that a WebSock= et UA shall not be mandated to implement UDP and TCP. > > A WebSocket UA might work in an environement where it can't use UDP or TC= P anyway. For example, if a JavaScript SIP UA in a browser technically can = only use WebSocket for SIP, why mandate it to implement something that it c= an't use??? > > As far as the WebServer SIP proxy it concerned, it MUST Record-Route. > > Regards, > > Christer > > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Pa= rthasarathi R [partha@parthasarathi.co.in] > Sent: Saturday, August 25, 2012 7:06 PM > To: 'I=F1aki Baz Castillo'; 'Jos=E9 Luis Mill=E1n' > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Mandatory to implement transport comment on d= raft-ibc-sipcore-sip-websocket-02 > > Inaki/Jose, > > Your current argument in the different mail of this same mail thread argu= e for not to close this open item which allows to relaxing the criteria for= mandatory to implement (UDP/TCP) transport. If so, SIP over Websocket clie= nt MUST support UDP & TCP as SIP transport to meet RFC 3261 normative state= ment. Please note that SIP over Websocket implementation with UDP & TCP as = SIP transport is possible by Linux/Windows application but not by Browser a= s of now. > > I'll like to hear more opinion from different folks before closing this o= pen item. > > Thanks > Partha > > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: Friday, August 24, 2012 11:11 PM > To: 'I=F1aki Baz Castillo' > Cc: 'Jos=E9 Luis Mill=E1n'; 'sipcore@ietf.org' > Subject: RE: [sipcore] Mandatory to implement transport comment on draft-= ibc-sipcore-sip-websocket-02 > > Inaki, > > Paul started the relaxing the criteria for mandatory to implement transpo= rt mail thread during WG adoption of SIP over websocket draft and one of th= e mail is http://www.ietf.org/mail-archive/web/sipcore/current/msg04930.htm= l. My understanding of the mail thread conclusion was that narrow approach = of providing leniency for mandatory to implement transport in SIP over Webs= ocket draft itself. I noticed in the current document that there is no rel= evant text for this leniency and so raised the issue in IETF-84 SIPCore mee= ting. As per IETF-84 SIPCore meeting discussion, I started this mail thread= . > > In case you are not in favor of narrow approach proposed by Paul, then it= is a separate discussion. Also you have indicated that the narrow approach= needs more text, then please suggest the text and let us discuss. > > Thanks > Partha > > -----Original Message----- > From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] > Sent: Friday, August 24, 2012 10:09 PM > To: Parthasarathi R > Cc: Jos=E9 Luis Mill=E1n; sipcore@ietf.org > Subject: Re: [sipcore] Mandatory to implement transport comment on draft-= ibc-sipcore-sip-websocket-02 > > 2012/8/24 Parthasarathi R : >> In case normal RFC 3261 application or application based on SIP websocke= t >> client, ACK will send towards >> >> UAS contact address with UDP transport as per mandatory to implement >> transport mechanism in RFC 3261. >> >> As browser acting as SIP Websocket client violates the mandatory to >> implement transport mechanism, >> >> the callflow breaks in this specification. > > Hi Partha. As said many times this draft is not *just* about web > browsers. Please imagine that new versions of iOS and Android come > with a WebSocket Client stack (so native apps can use it). Should we > also add them to the draft?: > > =93In case SIP WebSocket Client is a web browser or a native iOS or > Android application, and SIP Websocket Server is a SIP proxy, then..." > > Ugly, agree? > > > Anyhow, for the case of a web browser (which indeed cannot send a UDP > datagram) the draft already describes a full guideline in the Appendix > section: > > http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02#appendix-A > > IMHO that's enough. The mandatory sections of the draft should not > focus just on web browsers. > > > BTW your text is incomplete: > > > =93In case SIP WebSocket Client is a web browser and SIP Websocket > Server is a SIP proxy, then record-route header MUST be included by > SIP Websocket server in all SIP messages. This requirement assures > that SIP WebSocket Client is able to contact with UAS through SIP > Websocket Server during the mid-dialog irrespective of the contact SIP > URI received from UAS =94 > > That's not enough. If you want to also *receive* incoming requests you > need to mandate Outbound RFC 5626 (since the proxy cannot establish a > WebSocket connection with a web browser). But we don't want to mandate > Outbound (it was discussed and voted in Paris) since the draft just > describes a SIP transport and does not assume specific topologies or > UA devices. > > IMHO the Appendix guideline (which was already discussed in this WG) > is the appropriate section for talking about specific common > scenarios. The draft should not "update" RFC 3261 just for the case of > web browsers. > > > Regards. > > > > -- > I=F1aki Baz Castillo > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Sun Aug 26 04:35:53 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC0721F84B2 for ; Sun, 26 Aug 2012 04:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.017 X-Spam-Level: X-Spam-Status: No, score=-6.017 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYu59v+hOudA for ; Sun, 26 Aug 2012 04:35:52 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9202D21F84FA for ; Sun, 26 Aug 2012 04:35:49 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-38-503a0a0c3e57 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 9B.C4.17130.C0A0A305; Sun, 26 Aug 2012 13:35:40 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sun, 26 Aug 2012 13:35:40 +0200 From: Christer Holmberg To: =?Windows-1252?Q?Jos=E9_Luis_Mill=E1n?= Date: Sun, 26 Aug 2012 13:35:39 +0200 Thread-Topic: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 Thread-Index: Ac2Dcua9hBTqm7IJTOCvR8cPzvwy8QABzNav Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F28@ESESSCMS0356.eemea.ericsson.se> References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> <000101cd82db$ab93a0c0$02bae240$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F25@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOLMWRmVeSWpSXmKPExsUyM+JvrS4Pl1WAQd8fQ4vp+2ws1h0wsZj8 qY/V4uuPTWwOLB7nGt6zeyxZ8pPJ48P8L+wBzFFcNimpOZllqUX6dglcGd/Xr2QpmGFXcX/O ffYGxnVGXYycHBICJhLnDv9igrDFJC7cW8/WxcjFISRwilHiw+51LBDOAkaJjf2b2bsYOTjY BCwkuv9pgzSICNhLTDu5hRWkhllgCqPE7a0bWEASLAKqEpMWTASbKiyQLjFrdzsTREOGxKc/ B1ggbCOJuTv+g9m8AuESl242MUIsW8EssfLcHTaQBKdAoMSCpf/BmhmBzvt+ag2YzSwgLnHr yXyoswUkluw5zwxhi0q8fPyPFaJeVOJO+3pGiHoDiffn5jND2NoSyxa+ZoZYLChxcuYTlgmM YrOQjJ2FpGUWkpZZSFoWMLKsYhTOTczMSS8310stykwuLs7P0ytO3cQIjKyDW34b7GDcdF/s EKM0B4uSOK+e6n5/IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyTjYzb/n293Jlwgv9FxbdH D+IVj1XPl9TddpwpuNl/Ep/QqsL3mhH315dbrT577fSnG3v4rJ7XzKx0cDn1+bTJXIsXwV1p 4gtrTx0+Fz5NgeVTqLqfyV7VA5EBvR9aeqYflCg94iD9/KqAd1209Lz44jM2i2dYPzi/Wdda KPmfxblvTk88C9crsRRnJBpqMRcVJwIAqUmwJ3oCAAA= Cc: =?Windows-1252?Q?I=F1aki_Baz_Castillo?= , "sipcore@ietf.org" , Parthasarathi R Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2012 11:35:53 -0000 Hi, >Most WebSocket implementations do not allow (and there is no evidence >they will in the near future) receiving incoming connections. They can >only establish outgoing connections with WebSocket server >implementations. Exactly. >The specification of this new transport allows SIP to be used as a >session establishment protocol in the World Wide Web, in scenarios >where non of other transport protocols defined for SIP can be used. Exactly. It's a completely new environment. >SIP is the one entering in the WWW within this draft, allowing >massively used applications to use our loving protocol. Most of those >applications do not implement any existing SIP transport but >WebSocket, the one we are adopting in this document. Exactly. >This specification defines the way SIP WebSocket Client and Server >communicate and the mechanisms for the SIP element acting as WebSocket >Server to interact with other non WebSocket SIP elements. We authors propose the following statements to be used in this specification according to this task: >" >SIP WebSocket Servers implementing this specification MUST implement >UDP and TCP as stated in [RFC 3261]. I would suggest to say that the MUST applies if such server also communicat= e SIP using non-WS interfaces. Because, there could be a SIP WebSocket Server that *only* provides service= s to WS clients. Maybe something like: "SIP WebSocket Servers implementing this specification, and that also suppo= rt SIP using the transport mechanisms defined in [RFC 3261], MUST implement= both UDP and TCP, as stated in the RFC" >>SIP WebSocket Clients implementing this specification MAY implement >>UDP and TCP protocols, being their interoperability guaranteed by SIP >>WebSocket Servers which MUST be used as the first hop in the signaling >>path." I can't parse the sentence. Maybe something like: "As a SIP WebSocket Client will always communicate with a SIP WebSocket Ser= ver, and since some environments do not enable SIP WebSocket Clients to use= other UDP and TCP as SIP transport protocols for SIP, a SIP WebSocket Clie= nt is not mandated to implement support of UDP and TCP." Regards, Christer >Of course, by definition, a SIP WebSocket server MUST Record-Route. > >Any comment about the proposed statements is appreciated. 2012/8/25 Christer Holmberg : > Hi, > > I am not sure who I agree/disagree with, but my opinion is that a WebSock= et UA shall not be mandated to implement UDP and TCP. > > A WebSocket UA might work in an environement where it can't use UDP or TC= P anyway. For example, if a JavaScript SIP UA in a browser technically can = only use WebSocket for SIP, why mandate it to implement something that it c= an't use??? > > As far as the WebServer SIP proxy it concerned, it MUST Record-Route. > > Regards, > > Christer > > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Pa= rthasarathi R [partha@parthasarathi.co.in] > Sent: Saturday, August 25, 2012 7:06 PM > To: 'I=F1aki Baz Castillo'; 'Jos=E9 Luis Mill=E1n' > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Mandatory to implement transport comment on d= raft-ibc-sipcore-sip-websocket-02 > > Inaki/Jose, > > Your current argument in the different mail of this same mail thread argu= e for not to close this open item which allows to relaxing the criteria for= mandatory to implement (UDP/TCP) transport. If so, SIP over Websocket clie= nt MUST support UDP & TCP as SIP transport to meet RFC 3261 normative state= ment. Please note that SIP over Websocket implementation with UDP & TCP as = SIP transport is possible by Linux/Windows application but not by Browser a= s of now. > > I'll like to hear more opinion from different folks before closing this o= pen item. > > Thanks > Partha > > -----Original Message----- > From: Parthasarathi R [mailto:partha@parthasarathi.co.in] > Sent: Friday, August 24, 2012 11:11 PM > To: 'I=F1aki Baz Castillo' > Cc: 'Jos=E9 Luis Mill=E1n'; 'sipcore@ietf.org' > Subject: RE: [sipcore] Mandatory to implement transport comment on draft-= ibc-sipcore-sip-websocket-02 > > Inaki, > > Paul started the relaxing the criteria for mandatory to implement transpo= rt mail thread during WG adoption of SIP over websocket draft and one of th= e mail is http://www.ietf.org/mail-archive/web/sipcore/current/msg04930.htm= l. My understanding of the mail thread conclusion was that narrow approach = of providing leniency for mandatory to implement transport in SIP over Webs= ocket draft itself. I noticed in the current document that there is no rel= evant text for this leniency and so raised the issue in IETF-84 SIPCore mee= ting. As per IETF-84 SIPCore meeting discussion, I started this mail thread= . > > In case you are not in favor of narrow approach proposed by Paul, then it= is a separate discussion. Also you have indicated that the narrow approach= needs more text, then please suggest the text and let us discuss. > > Thanks > Partha > > -----Original Message----- > From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] > Sent: Friday, August 24, 2012 10:09 PM > To: Parthasarathi R > Cc: Jos=E9 Luis Mill=E1n; sipcore@ietf.org > Subject: Re: [sipcore] Mandatory to implement transport comment on draft-= ibc-sipcore-sip-websocket-02 > > 2012/8/24 Parthasarathi R : >> In case normal RFC 3261 application or application based on SIP websocke= t >> client, ACK will send towards >> >> UAS contact address with UDP transport as per mandatory to implement >> transport mechanism in RFC 3261. >> >> As browser acting as SIP Websocket client violates the mandatory to >> implement transport mechanism, >> >> the callflow breaks in this specification. > > Hi Partha. As said many times this draft is not *just* about web > browsers. Please imagine that new versions of iOS and Android come > with a WebSocket Client stack (so native apps can use it). Should we > also add them to the draft?: > > =93In case SIP WebSocket Client is a web browser or a native iOS or > Android application, and SIP Websocket Server is a SIP proxy, then..." > > Ugly, agree? > > > Anyhow, for the case of a web browser (which indeed cannot send a UDP > datagram) the draft already describes a full guideline in the Appendix > section: > > http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02#appendix-A > > IMHO that's enough. The mandatory sections of the draft should not > focus just on web browsers. > > > BTW your text is incomplete: > > > =93In case SIP WebSocket Client is a web browser and SIP Websocket > Server is a SIP proxy, then record-route header MUST be included by > SIP Websocket server in all SIP messages. This requirement assures > that SIP WebSocket Client is able to contact with UAS through SIP > Websocket Server during the mid-dialog irrespective of the contact SIP > URI received from UAS =94 > > That's not enough. If you want to also *receive* incoming requests you > need to mandate Outbound RFC 5626 (since the proxy cannot establish a > WebSocket connection with a web browser). But we don't want to mandate > Outbound (it was discussed and voted in Paris) since the draft just > describes a SIP transport and does not assume specific topologies or > UA devices. > > IMHO the Appendix guideline (which was already discussed in this WG) > is the appropriate section for talking about specific common > scenarios. The draft should not "update" RFC 3261 just for the case of > web browsers. > > > Regards. > > > > -- > I=F1aki Baz Castillo > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore= From pkyzivat@alum.mit.edu Mon Aug 27 13:01:52 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C90F21F8532 for ; Mon, 27 Aug 2012 13:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.205 X-Spam-Level: X-Spam-Status: No, score=-1.205 tagged_above=-999 required=5 tests=[AWL=-0.768, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlB15kpgeFUf for ; Mon, 27 Aug 2012 13:01:51 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9AF21F846E for ; Mon, 27 Aug 2012 13:01:51 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta02.westchester.pa.mail.comcast.net with comcast id rrJi1j0170xGWP851w1uYA; Mon, 27 Aug 2012 20:01:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id rw1H1j00D3ZTu2S3Yw1HGq; Mon, 27 Aug 2012 20:01:17 +0000 Message-ID: <503BD22D.2060007@alum.mit.edu> Date: Mon, 27 Aug 2012 16:01:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08 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, 27 Aug 2012 20:01:52 -0000 Sorry to do this again, but we need to do another WGLC on draft-ietf-sipcore-proxy-feature-08. The WGLC will run for a week. It will conclude at 23:59 UTC on Monday, September 3, 2012. (A week should be enough considering the nature of the changes since the last WGLC.) This covers changes since the last WGLC, which was for the -02 version. Those changes were to cover things I found while writing the document up for submission to the iesg, and things found by Robert Sparks in his AD review. Most of those things were editorial, but some of them were quite heavy editorial, such as rearranging sections of the document. (This causes the diff to version -02 to be largely worthless.) There was one significant change that isn't editorial. We changed the review policy for registering new feature capability indicators in the global tree from Expert Reveiw to Specification Required. This isn't a big change, since we were always requiring a specification. But it is a better fit. (This doesn't require an RFC, only a specification that can be referenced permanently.) Please look at this and then indicate you acceptance or issues here on the mailing list. We really need responses to indicate that it has been reviewed. Some helpful links: The draft version being reviewed: http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-08 Diff from version -06 (recent changes): http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipcore-proxy-feature-08.txt;url1=draft-ietf-sipcore-proxy-feature-06.txt Diff from version -02 (the subject of the last WGLC): http://tools.ietf.org/rfcdiff?url2=draft-ietf-sipcore-proxy-feature-08.txt;url1=draft-ietf-sipcore-proxy-feature-02.txt Thanks, Paul (as co-chair) _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From jmillan@aliax.net Mon Aug 27 22:30:35 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997D011E809C for ; Mon, 27 Aug 2012 22:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dHW8BB6YUcPa for ; Mon, 27 Aug 2012 22:30:34 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7F011E80A3 for ; Mon, 27 Aug 2012 22:30:33 -0700 (PDT) Received: by lahm15 with SMTP id m15so3182101lah.31 for ; Mon, 27 Aug 2012 22:30:33 -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=ugGYMaw4FHrLux59gmar0rGbk3zBYIuMJr32luyDXjc=; b=Jy5bGncKdKptvf4dYMG5ixu0x5N0pQpcl32lAqbmtw5KkTXWFK9DSHZ3U6xR9WoMOs Qyg4yAiMVjTYPyALgtgr+ITvk37JtxQwSPJA6vAuwEPWwWa9zm5MllqXnqy3bJMDnFN0 vK7Mq++5jC/WL0K0/OYOmJSW/Mn58Lw+7RF4BDjEQayFA/TR2Vy4+MD0/geqOOx5EAPJ dvZX0g1yc3u0YcGW4xTdnB3dqQGQGXlG4XfmMoHqSlylt3q4/PCtnFiwFAwcB2AToB4Y BRupDPyRip3lUJML9rvSoe9vR/tXizsY1KdOz7CMjFeb/s7ZnltYAt4JpO1cL9xBo7J6 5pRg== MIME-Version: 1.0 Received: by 10.152.146.163 with SMTP id td3mr17405624lab.26.1346131832918; Mon, 27 Aug 2012 22:30:32 -0700 (PDT) Received: by 10.112.94.33 with HTTP; Mon, 27 Aug 2012 22:30:32 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2F28@ESESSCMS0356.eemea.ericsson.se> References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> <000101cd82db$ab93a0c0$02bae240$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F25@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F28@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 28 Aug 2012 07:30:32 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: Christer Holmberg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQldzMvZpWC9atsB7zoTuyno+zu3v/3tCknUhNWZDtx4cklhBpJbg/72fl4Zm5FMk3bF2dNO Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , "sipcore@ietf.org" , Parthasarathi R Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 05:30:35 -0000 2012/8/26 Christer Holmberg : > Hi, > >>Most WebSocket implementations do not allow (and there is no evidence >>they will in the near future) receiving incoming connections. They can >>only establish outgoing connections with WebSocket server >>implementations. > > Exactly. > >>The specification of this new transport allows SIP to be used as a >>session establishment protocol in the World Wide Web, in scenarios >>where non of other transport protocols defined for SIP can be used. > > Exactly. It's a completely new environment. > >>SIP is the one entering in the WWW within this draft, allowing >>massively used applications to use our loving protocol. Most of those >>applications do not implement any existing SIP transport but >>WebSocket, the one we are adopting in this document. > > Exactly. > >>This specification defines the way SIP WebSocket Client and Server >>communicate and the mechanisms for the SIP element acting as WebSocket >>Server to interact with other non WebSocket SIP elements. > > We authors propose the following statements to be used in this > specification according to this task: > >>" >>SIP WebSocket Servers implementing this specification MUST implement >>UDP and TCP as stated in [RFC 3261]. > > I would suggest to say that the MUST applies if such server also communic= ate SIP using non-WS interfaces. > > Because, there could be a SIP WebSocket Server that *only* provides servi= ces to WS clients. > > Maybe something like: > > "SIP WebSocket Servers implementing this specification, and that also sup= port SIP using the transport mechanisms defined in [RFC 3261], MUST impleme= nt both UDP and TCP, as stated in the RFC" > Although it could seem logical at a first glance, such a statement breaks the basic level of protocol interoperability. This limitation is not imposed by the new transport and hence it seems reasonable that the SIP WebSocket Server MUST implement UDP and TCP as stated in [RFC 3261]. do you agree? >>>SIP WebSocket Clients implementing this specification MAY implement >>>UDP and TCP protocols, being their interoperability guaranteed by SIP >>>WebSocket Servers which MUST be used as the first hop in the signaling >>>path." > > I can't parse the sentence. > > Maybe something like: > > "As a SIP WebSocket Client will always communicate with a SIP WebSocket S= erver, and since some environments do not enable SIP WebSocket Clients to u= se other UDP and TCP as SIP transport protocols for SIP, a SIP WebSocket Cl= ient is not mandated to implement support of UDP and TCP." > Agree with this. > Regards, > > Christer > > Thank you for your comments Christer, Regards > > > > >>Of course, by definition, a SIP WebSocket server MUST Record-Route. >> >>Any comment about the proposed statements is appreciated. > > > 2012/8/25 Christer Holmberg : >> Hi, >> >> I am not sure who I agree/disagree with, but my opinion is that a WebSoc= ket UA shall not be mandated to implement UDP and TCP. >> >> A WebSocket UA might work in an environement where it can't use UDP or T= CP anyway. For example, if a JavaScript SIP UA in a browser technically can= only use WebSocket for SIP, why mandate it to implement something that it = can't use??? >> >> As far as the WebServer SIP proxy it concerned, it MUST Record-Route. >> >> Regards, >> >> Christer >> >> ________________________________________ >> From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of P= arthasarathi R [partha@parthasarathi.co.in] >> Sent: Saturday, August 25, 2012 7:06 PM >> To: 'I=F1aki Baz Castillo'; 'Jos=E9 Luis Mill=E1n' >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Mandatory to implement transport comment on = draft-ibc-sipcore-sip-websocket-02 >> >> Inaki/Jose, >> >> Your current argument in the different mail of this same mail thread arg= ue for not to close this open item which allows to relaxing the criteria fo= r mandatory to implement (UDP/TCP) transport. If so, SIP over Websocket cli= ent MUST support UDP & TCP as SIP transport to meet RFC 3261 normative stat= ement. Please note that SIP over Websocket implementation with UDP & TCP as= SIP transport is possible by Linux/Windows application but not by Browser = as of now. >> >> I'll like to hear more opinion from different folks before closing this = open item. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: Parthasarathi R [mailto:partha@parthasarathi.co.in] >> Sent: Friday, August 24, 2012 11:11 PM >> To: 'I=F1aki Baz Castillo' >> Cc: 'Jos=E9 Luis Mill=E1n'; 'sipcore@ietf.org' >> Subject: RE: [sipcore] Mandatory to implement transport comment on draft= -ibc-sipcore-sip-websocket-02 >> >> Inaki, >> >> Paul started the relaxing the criteria for mandatory to implement transp= ort mail thread during WG adoption of SIP over websocket draft and one of t= he mail is http://www.ietf.org/mail-archive/web/sipcore/current/msg04930.ht= ml. My understanding of the mail thread conclusion was that narrow approach= of providing leniency for mandatory to implement transport in SIP over Web= socket draft itself. I noticed in the current document that there is no re= levant text for this leniency and so raised the issue in IETF-84 SIPCore me= eting. As per IETF-84 SIPCore meeting discussion, I started this mail threa= d. >> >> In case you are not in favor of narrow approach proposed by Paul, then i= t is a separate discussion. Also you have indicated that the narrow approac= h needs more text, then please suggest the text and let us discuss. >> >> Thanks >> Partha >> >> -----Original Message----- >> From: I=F1aki Baz Castillo [mailto:ibc@aliax.net] >> Sent: Friday, August 24, 2012 10:09 PM >> To: Parthasarathi R >> Cc: Jos=E9 Luis Mill=E1n; sipcore@ietf.org >> Subject: Re: [sipcore] Mandatory to implement transport comment on draft= -ibc-sipcore-sip-websocket-02 >> >> 2012/8/24 Parthasarathi R : >>> In case normal RFC 3261 application or application based on SIP websock= et >>> client, ACK will send towards >>> >>> UAS contact address with UDP transport as per mandatory to implement >>> transport mechanism in RFC 3261. >>> >>> As browser acting as SIP Websocket client violates the mandatory to >>> implement transport mechanism, >>> >>> the callflow breaks in this specification. >> >> Hi Partha. As said many times this draft is not *just* about web >> browsers. Please imagine that new versions of iOS and Android come >> with a WebSocket Client stack (so native apps can use it). Should we >> also add them to the draft?: >> >> =93In case SIP WebSocket Client is a web browser or a native iOS or >> Android application, and SIP Websocket Server is a SIP proxy, then..." >> >> Ugly, agree? >> >> >> Anyhow, for the case of a web browser (which indeed cannot send a UDP >> datagram) the draft already describes a full guideline in the Appendix >> section: >> >> http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-02#appendix-A >> >> IMHO that's enough. The mandatory sections of the draft should not >> focus just on web browsers. >> >> >> BTW your text is incomplete: >> >> >> =93In case SIP WebSocket Client is a web browser and SIP Websocket >> Server is a SIP proxy, then record-route header MUST be included by >> SIP Websocket server in all SIP messages. This requirement assures >> that SIP WebSocket Client is able to contact with UAS through SIP >> Websocket Server during the mid-dialog irrespective of the contact SIP >> URI received from UAS =94 >> >> That's not enough. If you want to also *receive* incoming requests you >> need to mandate Outbound RFC 5626 (since the proxy cannot establish a >> WebSocket connection with a web browser). But we don't want to mandate >> Outbound (it was discussed and voted in Paris) since the draft just >> describes a SIP transport and does not assume specific topologies or >> UA devices. >> >> IMHO the Appendix guideline (which was already discussed in this WG) >> is the appropriate section for talking about specific common >> scenarios. The draft should not "update" RFC 3261 just for the case of >> web browsers. >> >> >> Regards. >> >> >> >> -- >> I=F1aki Baz Castillo >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From atle.monrad@ericsson.com Mon Aug 27 22:45:24 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25F821F84F2 for ; Mon, 27 Aug 2012 22:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XiqR5g1wgSxZ for ; Mon, 27 Aug 2012 22:45:24 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B3FF721F84EC for ; Mon, 27 Aug 2012 22:45:23 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-36-503c5af2a026 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B9.11.17130.2FA5C305; Tue, 28 Aug 2012 07:45:22 +0200 (CEST) Received: from ESESSCMS0352.eemea.ericsson.se ([169.254.2.64]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Tue, 28 Aug 2012 07:45:22 +0200 From: Atle Monrad To: Paul Kyzivat , SIPCORE Date: Tue, 28 Aug 2012 07:45:20 +0200 Thread-Topic: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08 Thread-Index: Ac2Ejs8GGAfNQydNTg2oR91JJc/K+gAGXA6w Message-ID: <7A051DFAA46D0246A82293C7CEF621E90709D2E766@ESESSCMS0352.eemea.ericsson.se> References: <503BD22D.2060007@alum.mit.edu> In-Reply-To: <503BD22D.2060007@alum.mit.edu> Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: nb-NO, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM+Jvre6nKJsAgxMv+CxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj28bzjAWTJSpmrJjC0sA4QaSLkZNDQsBE 4uflv8wQtpjEhXvr2boYuTiEBE4xSpw7+Y8FwpnDKDH51UNWkCo2AR2Jcz/vgNkiAi4SS7qP gHWzCKhKnGy8CmYLCwRLvLjXxQ5REyLxccU5NgjbSOLj//1gvbwC4RL9Hc1gcSEBbYl381+C 1XMCzX96fTPQYg4ORgFZiblNvCBhZgFxiVtP5jNBHCogsWTPeaijRSVePv4HNpJRQEZixdZv bBD1OhILdn+CsrUlli18zQyxVlDi5MwnLBMYRWchGTsLScssJC2zkLQsYGRZxSicm5iZk15u rpdalJlcXJyfp1ecuokRGCMHt/w22MG46b7YIUZpDhYlcV491f3+QgLpiSWp2ampBalF8UWl OanFhxiZODilGhj7/+5e22S7sVLrRMcm5jOlzziyN26Y8/fC1meyeW8O7224fMM62YclsWLq 5nYz02THTSd1V2hcUtiaZbbfqvTJiiUHvmkd9Myp4c+4WRPZ8+zigRURE/8uzNz67baJfejP 6Z2CAmGv2leytGhZ9HHWL5gR9JahaeUK3rVnTS0uC06xlcvIvZmuxFKckWioxVxUnAgAKBf7 nV8CAAA= Subject: Re: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08 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, 28 Aug 2012 05:45:25 -0000 Paul, all I've read through draft-ietf-sipcore-proxy-feature-08 and provided Christer= et.al. with a number of proposed nits plus a couple of other wordings that= seems to need corrections aswell.=20 Generally I'm fine with this version of the draft. It seems to me that the draft has progressed as indicated by the previous c= omments given, thus I hope that the draft -08 can be accepted and with some= polishing can progress towards completion rather soon. We have features in 3GPP Rel-10 and 3GPP Rel-11 that are waiting for comple= tion of this draft. Thanks /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Standardization and Regulation, Group Function Technology and Portfolio Management=20 Ericsson -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 27. august 2012 22:02 To: SIPCORE Subject: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-= 08 Sorry to do this again, but we need to do another WGLC on draft-ietf-sipcor= e-proxy-feature-08. The WGLC will run for a week. It will conclude at 23:59 UTC on Monday, Sept= ember 3, 2012. (A week should be enough considering the nature of the chang= es since the last WGLC.) This covers changes since the last WGLC, which was for the -02 version.=20 Those changes were to cover things I found while writing the document up fo= r submission to the iesg, and things found by Robert Sparks in his AD revie= w. Most of those things were editorial, but some of them were quite heavy e= ditorial, such as rearranging sections of the document. (This causes the di= ff to version -02 to be largely worthless.) There was one significant change that isn't editorial. We changed the revie= w policy for registering new feature capability indicators in the global tr= ee from Expert Reveiw to Specification Required. This isn't a big change, s= ince we were always requiring a specification. But it is a better fit. (Thi= s doesn't require an RFC, only a specification that can be referenced perma= nently.) Please look at this and then indicate you acceptance or issues here on the = mailing list. We really need responses to indicate that it has been reviewe= d. Some helpful links: The draft version being reviewed: http://tools.ietf.org/html/draft-ietf-sipcore-proxy-feature-08 Diff from version -06 (recent changes): http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-proxy-feature-08.tx= t;url1=3Ddraft-ietf-sipcore-proxy-feature-06.txt Diff from version -02 (the subject of the last WGLC): http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-proxy-feature-08.tx= t;url1=3Ddraft-ietf-sipcore-proxy-feature-02.txt Thanks, Paul (as co-chair) _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Mon Aug 27 23:50:59 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7871721E804D for ; Mon, 27 Aug 2012 23:50:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.008 X-Spam-Level: X-Spam-Status: No, score=-6.008 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRoMiVqAxgki for ; Mon, 27 Aug 2012 23:50:59 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9CC21E804B for ; Mon, 27 Aug 2012 23:50:58 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-51-503c6a503a8b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 38.5E.11467.05A6C305; Tue, 28 Aug 2012 08:50:57 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 28 Aug 2012 08:50:56 +0200 From: Christer Holmberg To: =?iso-8859-1?Q?Jos=E9_Luis_Mill=E1n?= Date: Tue, 28 Aug 2012 08:50:55 +0200 Thread-Topic: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 Thread-Index: Ac2E3j7CFitrUh8/RmGNA9XunSvUkAACvrJA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A356BF8@ESESSCMS0356.eemea.ericsson.se> References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> <000101cd82db$ab93a0c0$02bae240$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F25@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F28@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGLMWRmVeSWpSXmKPExsUyM+JvrW5glk2AwaIGNovp+2ws1h0wsZj8 qY/V4uuPTWwOLB7nGt6zeyxZ8pPJ48P8L+wBzFFcNimpOZllqUX6dglcGcvfT2IpmMtVsfV4 O1sD42yOLkZODgkBE4mJNy6wQNhiEhfurWfrYuTiEBI4xSgx91sXC4SzgFFi4+P37F2MHBxs AhYS3f+0QUwRAVuJy0f8QEqYBSYxSjyeOhlsEIuAqsSuW7sZQWxhgXSJWbvbmUBsEYEMiU9/ DrBA2EYSXzY/A7N5BcIlJk/ZBLV4P4vEhJsQzZwCgRLHuv6zg9iMQNd9P7UGbBCzgLjErSfz mSCuFpBYsuc8M4QtKvHy8T9WiHpRiTvt6xkh6vUkbkydwgZha0ssW/iaGWKxoMTJmU9YJjCK zUIydhaSlllIWmYhaVnAyLKKUTg3MTMnvdxQL7UoM7m4OD9Przh1EyMwrg5u+a27g/HUOZFD jNIcLErivFxJ+/2FBNITS1KzU1MLUovii0pzUosPMTJxcEo1MOYvWtTos1B/86UD/a01Vhtt GwwC17/Y8DRp/+q1V6tUOKvbZIpU311lj/JiWLZid+1ER+3I47dZ+S4auMU4e6xcWtj6gU/H 49TGd6I1VcbHn/bJRvoce8JXEXFXoTmAN0VbdDNXsmPe753u24RbzW8KC72I0PV9ZSfeUlU5 6fa+3+8WFr0sU2Ipzkg01GIuKk4EANjGS095AgAA Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "sipcore@ietf.org" , Parthasarathi R Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 06:50:59 -0000 Hi, >>>This specification defines the way SIP WebSocket Client and Server=20 >>>communicate and the mechanisms for the SIP element acting as WebSocket=20 >>>Server to interact with other non WebSocket SIP elements. >> >> We authors propose the following statements to be used in this=20 >> specification according to this task: >> >>>" >>>SIP WebSocket Servers implementing this specification MUST implement=20 >>>UDP and TCP as stated in [RFC 3261]. >> >>> I would suggest to say that the MUST applies if such server also commun= icate SIP using non-WS interfaces. >> >> Because, there could be a SIP WebSocket Server that *only* provides serv= ices to WS clients. >> >> Maybe something like: >> >> "SIP WebSocket Servers implementing this specification, and that also su= pport SIP using the transport mechanisms defined in [RFC 3261], MUST implem= ent both UDP and TCP, as stated in the RFC" >> > > Although it could seem logical at a first glance, such a statement breaks= the basic level of protocol interoperability. This limitation is not impos= ed by the new transport and hence it seems reasonable that the SIP WebSocke= t Server MUST implement UDP=20 > and TCP as stated in [RFC 3261]. > > do you agree? I'm fine with your suggestion. Regards, Christer From victor.pascual.avila@gmail.com Tue Aug 28 02:02:58 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BFE21F853F for ; Tue, 28 Aug 2012 02:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBHeTT9wX+t8 for ; Tue, 28 Aug 2012 02:02:58 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D8CD021F8437 for ; Tue, 28 Aug 2012 02:02:57 -0700 (PDT) Received: by iabz21 with SMTP id z21so11453234iab.31 for ; Tue, 28 Aug 2012 02:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=97ukVfp+ZCzY3DGhr6e1KPwuVkTYTLgPhfK46e+5nPk=; b=QbF5sM4+net4AhdnD6JU8DJ+IrFEzfil30+M0UN6U83ofvjlDiSOLqkK3gkM2JcNLI NsRQDHZkl+QwMn0co8b9Ebjzq5NNgAJ3vUVnrRNpBI2+rjZqYyko0l9csMl28qBieJHf 610hrdzJtWJRMxS22hNTYwooJM2jHWQitV0ufQW4v6goouW/5ZZxs16ROGpMfo+TCCED ts5Ygp8kMjJBx8ax+6pp8EV7g0nIcKhzRltm5apflATITq5d4Zr18ohNaPIf54Fx0jGu X9kZCdXW7jdn55QIk67JTmI8r1dc7u71SxKdH7DuWx9DpppiwlF7A2/iPKV3Pgcegx5A 58vQ== MIME-Version: 1.0 Received: by 10.50.36.195 with SMTP id s3mr12965978igj.63.1346144577475; Tue, 28 Aug 2012 02:02:57 -0700 (PDT) Received: by 10.64.46.105 with HTTP; Tue, 28 Aug 2012 02:02:57 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A356BF8@ESESSCMS0356.eemea.ericsson.se> References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> <000101cd82db$ab93a0c0$02bae240$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F25@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F28@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A356BF8@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 28 Aug 2012 11:02:57 +0200 Message-ID: From: Victor Pascual Avila To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 09:02:58 -0000 On Tue, Aug 28, 2012 at 8:50 AM, Christer Holmberg wrote: > Hi, > >>>>This specification defines the way SIP WebSocket Client and Server >>>>communicate and the mechanisms for the SIP element acting as WebSocket >>>>Server to interact with other non WebSocket SIP elements. >>> >>> We authors propose the following statements to be used in this >>> specification according to this task: >>> >>>>" >>>>SIP WebSocket Servers implementing this specification MUST implement >>>>UDP and TCP as stated in [RFC 3261]. >>> >>>> I would suggest to say that the MUST applies if such server also communicate SIP using non-WS interfaces. >>> >>> Because, there could be a SIP WebSocket Server that *only* provides services to WS clients. >>> >>> Maybe something like: >>> >>> "SIP WebSocket Servers implementing this specification, and that also support SIP using the transport mechanisms defined in [RFC 3261], MUST implement both UDP and TCP, as stated in the RFC" >>> >> >> Although it could seem logical at a first glance, such a statement breaks the basic level of protocol interoperability. This limitation is not imposed by the new transport and hence it seems reasonable that the SIP WebSocket Server MUST implement UDP >> and TCP as stated in [RFC 3261]. >> >> do you agree? > > I'm fine with your suggestion. Great -- we'll update the draft accordingly Cheers, -Victor From pkyzivat@alum.mit.edu Tue Aug 28 06:10:20 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5DD921F8567 for ; Tue, 28 Aug 2012 06:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[AWL=-1.062, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_22=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdbzscM++XpK for ; Tue, 28 Aug 2012 06:10:20 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF8E11E80D3 for ; Tue, 28 Aug 2012 06:10:19 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta14.westchester.pa.mail.comcast.net with comcast id sD061j0051YDfWL5EDAPXs; Tue, 28 Aug 2012 13:10:23 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id sD9x1j00k3ZTu2S3gD9yPN; Tue, 28 Aug 2012 13:09:58 +0000 Message-ID: <503CC33A.2040808@alum.mit.edu> Date: Tue, 28 Aug 2012 09:10:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Atle Monrad References: <503BD22D.2060007@alum.mit.edu> <7A051DFAA46D0246A82293C7CEF621E90709D2E766@ESESSCMS0352.eemea.ericsson.se> In-Reply-To: <7A051DFAA46D0246A82293C7CEF621E90709D2E766@ESESSCMS0352.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08 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, 28 Aug 2012 13:10:21 -0000 On 8/28/12 1:45 AM, Atle Monrad wrote: > Paul, all > > I've read through draft-ietf-sipcore-proxy-feature-08 and provided Christer et.al. with a number of proposed nits plus a couple of other wordings that seems to need corrections aswell. > > Generally I'm fine with this version of the draft. > > It seems to me that the draft has progressed as indicated by the previous comments given, thus I hope that the draft -08 can be accepted and with some polishing can progress towards completion rather soon. > > We have features in 3GPP Rel-10 and 3GPP Rel-11 that are waiting for completion of this draft. The only "polishing" I anticipate will be - to respond to any iesg comments - editorial fixes requested by the editor Thanks, Paul From partha@parthasarathi.co.in Tue Aug 28 09:37:49 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DE521F8598 for ; Tue, 28 Aug 2012 09:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.443 X-Spam-Level: X-Spam-Status: No, score=-1.443 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6ouxxQGg-5v for ; Tue, 28 Aug 2012 09:37:48 -0700 (PDT) Received: from outbound-us1.mailhostbox.com (outbound-us1.mailhostbox.com [69.93.141.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE8721F852A for ; Tue, 28 Aug 2012 09:37:48 -0700 (PDT) Received: from userPC (unknown [122.179.96.15]) (Authenticated sender: partha@parthasarathi.co.in) by outbound-us1.mailhostbox.com (Postfix) with ESMTPA id A86F41908364; Tue, 28 Aug 2012 16:37:43 +0000 (GMT) From: "Parthasarathi R" To: "'Victor Pascual Avila'" , "'Christer Holmberg'" References: <000d01cd812e$46bb4850$d431d8f0$@co.in> <000f01cd8214$9d255a00$d7700e00$@co.in> <000101cd82db$ab93a0c0$02bae240$@co.in> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F25@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05853409FF2F28@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585340A356BF8@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Date: Tue, 28 Aug 2012 22:07:36 +0530 Message-ID: <000301cd853b$72ebe7c0$58c3b740$@co.in> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2E++4aFx6pLeQ9TAOGP/pGn7dYJwAP2r0A Content-Language: en-us X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-RefID: str=0001.0A0B020D.503CF3DC.0016, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 Cc: sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 16:37:49 -0000 Hi, It is good to see the addition of text around this open issue. As there is no normative usage in the proposed text, The minor correction shall be as follows: "As a SIP WebSocket Client will always communicate with a SIP WebSocket Server, and since some environments do not enable SIP WebSocket Clients to use other UDP and TCP as SIP transport protocols for SIP, a SIP WebSocket Client MAY not implement UDP and TCP as SIP transport" Thanks Partha -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Victor Pascual Avila Sent: Tuesday, August 28, 2012 2:33 PM To: Christer Holmberg Cc: sipcore@ietf.org Subject: Re: [sipcore] Mandatory to implement transport comment on draft-ibc-sipcore-sip-websocket-02 On Tue, Aug 28, 2012 at 8:50 AM, Christer Holmberg wrote: > Hi, > >>>>This specification defines the way SIP WebSocket Client and Server >>>>communicate and the mechanisms for the SIP element acting as WebSocket >>>>Server to interact with other non WebSocket SIP elements. >>> >>> We authors propose the following statements to be used in this >>> specification according to this task: >>> >>>>" >>>>SIP WebSocket Servers implementing this specification MUST implement >>>>UDP and TCP as stated in [RFC 3261]. >>> >>>> I would suggest to say that the MUST applies if such server also communicate SIP using non-WS interfaces. >>> >>> Because, there could be a SIP WebSocket Server that *only* provides services to WS clients. >>> >>> Maybe something like: >>> >>> "SIP WebSocket Servers implementing this specification, and that also support SIP using the transport mechanisms defined in [RFC 3261], MUST implement both UDP and TCP, as stated in the RFC" >>> >> >> Although it could seem logical at a first glance, such a statement breaks the basic level of protocol interoperability. This limitation is not imposed by the new transport and hence it seems reasonable that the SIP WebSocket Server MUST implement UDP >> and TCP as stated in [RFC 3261]. >> >> do you agree? > > I'm fine with your suggestion. Great -- we'll update the draft accordingly Cheers, -Victor _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From jmillan@aliax.net Tue Aug 28 15:47:51 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B46321F8565 for ; Tue, 28 Aug 2012 15:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcuMdLSs1qGQ for ; Tue, 28 Aug 2012 15:47:50 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF3321F855D for ; Tue, 28 Aug 2012 15:47:50 -0700 (PDT) Received: by lbky2 with SMTP id y2so5320lbk.31 for ; Tue, 28 Aug 2012 15:47:49 -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=1T48xNMiiZ10F/zFrXa+WIJaSzEUkQE92yN5IBux6nk=; b=NPIv1QFwauXf2zN8Q75jWdiBUcy45MyESx6k9Dlu7DeuRbaGnSw0X+dB688oL0swaB aNyULheLoSO13AwdA2hQzgF13eFEvef0DmjeihpMJvXXmj4Y67GB0MmwL+vLa0znAxcr og/xqcoSfoo8I1oU79wEcfiW11V21fGvq4LPSeuUybUj6hnTf3QwmbE6xiFmOFvcGJR+ BJoaWVSmp2RX8zQXvw7eIb4UwnrmUljqyc7J249oxXd5u9ReF3FQmcQcA4OUoDKImWij 6lBwbhkXPQ4/6idw2pnspN8J8fUnMTSsA/dOCZgOTR7YtHoGCEyCKHGUb8+/NSmSuZxi 5kGg== MIME-Version: 1.0 Received: by 10.152.146.163 with SMTP id td3mr20237505lab.26.1346194069175; Tue, 28 Aug 2012 15:47:49 -0700 (PDT) Received: by 10.112.94.33 with HTTP; Tue, 28 Aug 2012 15:47:49 -0700 (PDT) Date: Wed, 29 Aug 2012 00:47:49 +0200 Message-ID: From: =?ISO-8859-1?Q?Jos=E9_Luis_Mill=E1n?= To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmpYnkQeOspG+zxVYfy6nCTBwvg3zpV4677ZLMA5/oxofQPWxTPDiupe/5PIhwVgA/A+AkN Subject: [sipcore] Via 'received' parameter (was Re: WGLC: draft-ietf-sipcore-sip-websocket-02) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Aug 2012 22:47:51 -0000 Hi, Is it convenient for a SIP WebSocket Server to strictly satisfy 18.2.1 and 18.2.2 sections in [RFC 3261] ? The WebSocket connection may traverse one or more HTTP elements before reaching the SIP WebSocket Server. In this case, the Via 'received' parameter will point to a non SIP element. Additionally, many SIP WebSocket Clients won't act as SIP WebSocket Servers. They won't allow receiving WebSocket connections. Trying to establish a new connection to the address represented in the Via 'received' parameter, as stated in section 18.2.2 of [RFC 3261], won't succeed in any of the scenarios defined above. For this reason, it may be reasonable to relax 18.2.1 and 18.2.2 sections of [RFC 3261] by stating something like: " SIP WebSocket Server implementations MAY decide not to add the Via 'received' parameter to received SIP requests, in which case the server transaction MUST NOT attempt to open a connection for sending a response. " It might be worth saying that: " It is RECOMMENDED that SIP WebSocket Server implementations do not add the Via 'received' parameter to SIP requests when acting as edge proxies. " Regards, From christer.holmberg@ericsson.com Wed Aug 29 01:10:38 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CB821F8570 for ; Wed, 29 Aug 2012 01:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.861 X-Spam-Level: X-Spam-Status: No, score=-5.861 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id If5-ba6V13aY for ; Wed, 29 Aug 2012 01:10:37 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 877DF21F84C8 for ; Wed, 29 Aug 2012 01:10:36 -0700 (PDT) X-AuditID: c1b4fb25-b7f046d00000644c-0a-503dce7a924d Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id A7.29.25676.A7ECD305; Wed, 29 Aug 2012 10:10:34 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 29 Aug 2012 10:10:34 +0200 From: Christer Holmberg To: 'Paul Kyzivat' , Atle Monrad Date: Wed, 29 Aug 2012 10:10:32 +0200 Thread-Topic: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08 Thread-Index: Ac2FHnwjnskruYfQQhi5eIkNQvrFrQANneYg Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340A357404@ESESSCMS0356.eemea.ericsson.se> References: <503BD22D.2060007@alum.mit.edu> <7A051DFAA46D0246A82293C7CEF621E90709D2E766@ESESSCMS0352.eemea.ericsson.se> <503CC33A.2040808@alum.mit.edu> In-Reply-To: <503CC33A.2040808@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+JvrW7VOdsAg6UzrS1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj8NqVbAXtQhX39i1mbWDcydfFyMEhIWAi 0bdRvIuRE8gUk7hwbz1bFyMXh5DAKUaJBaeWMUM4Cxgl9jadZARpYBOwkOj+pw3SICIQIvFi WjMziM0sICdx/cNGNhCbRUBVYuWp9YwgtrBAsMTdCY3MMPVXLj9jg7CNJD5e7mMHGckrEC5x 8kA+xKrZjBIX398Bq+cU0JH4uOoxmM0IdNz3U2uYIHaJS9x6Mp8J4mgBiSV7zjND2KISLx// Y4WoF5W40w5xAzPQnAW7P7FB2NoSyxa+BqvnFRCUODnzCcsERrFZSMbOQtIyC0nLLCQtCxhZ VjEK5yZm5qSXG+mlFmUmFxfn5+kVp25iBEbOwS2/VXcw3jkncohRmoNFSZzXeusefyGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2MWlvXX1x+OzLvS8DczlXNF0K1FX3OxiSv3Owy1YDfaOb6 TfxM3LwyK+S3JxeJKPff3+MlsuDc5jbmz54LXQ539wsWTWT2fTvJcO9KFe9XOxZP3Gp12Xbv n1tPquNk1hfGB302vaOUOc/teoG7Q9fCD4yaFR08hwUuiDaxPfc9mKfBLzw9/aCQEktxRqKh FnNRcSIA53mH1WoCAAA= Cc: SIPCORE Subject: Re: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08 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, 29 Aug 2012 08:10:38 -0000 Hi, Based on Atle's findings, there are a few editorial nits that I think we sh= all fix: Section 4.3.2: ---------------- The text says: "Unless a feature capability indicator is inserted in a Feature-Caps header field or a target refresh request,.." Replace "or" with "of". Section 5.3.4: ----------------- The text says: "There might be restrictions related to whether entities are allowed to insert a feature capability indicator in registration related messages, standalone transaction messages, or dialog related messages, whether entities are..." Remove "or". Sections 7.3.2 and 7.3.3: ----------------------------- In both sections we have the following text: "Description contains the Abstract, provided in the registration feature capability indication registration template." However, there is no "Abstract" in the template. There is a "Description", = though. So, I suggest to simply say: "Description, provided in the registration feature capability=20 indication registration template." Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 28. elokuuta 2012 16:10 To: Atle Monrad Cc: SIPCORE Subject: Re: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feat= ure-08 On 8/28/12 1:45 AM, Atle Monrad wrote: > Paul, all > > I've read through draft-ietf-sipcore-proxy-feature-08 and provided Christ= er et.al. with a number of proposed nits plus a couple of other wordings th= at seems to need corrections aswell. > > Generally I'm fine with this version of the draft. > > It seems to me that the draft has progressed as indicated by the previous= comments given, thus I hope that the draft -08 can be accepted and with so= me polishing can progress towards completion rather soon. > > We have features in 3GPP Rel-10 and 3GPP Rel-11 that are waiting for comp= letion of this draft. The only "polishing" I anticipate will be - to respond to any iesg comments - editorial fixes requested by the editor Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Wed Aug 29 07:53:06 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C3821F853E for ; Wed, 29 Aug 2012 07:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.862 X-Spam-Level: X-Spam-Status: No, score=-0.862 tagged_above=-999 required=5 tests=[AWL=-1.025, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_22=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZrWpDrM886Ct for ; Wed, 29 Aug 2012 07:53:05 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 3E27F21F853A for ; Wed, 29 Aug 2012 07:53:05 -0700 (PDT) Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta02.westchester.pa.mail.comcast.net with comcast id sazx1j00C27AodY51et8xi; Wed, 29 Aug 2012 14:53:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta19.westchester.pa.mail.comcast.net with comcast id setP1j01a3ZTu2S3fetPlF; Wed, 29 Aug 2012 14:53:24 +0000 Message-ID: <503E2CCF.4000501@alum.mit.edu> Date: Wed, 29 Aug 2012 10:53:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Christer Holmberg References: <503BD22D.2060007@alum.mit.edu> <7A051DFAA46D0246A82293C7CEF621E90709D2E766@ESESSCMS0352.eemea.ericsson.se> <503CC33A.2040808@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585340A357404@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340A357404@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Atle Monrad , SIPCORE Subject: Re: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08 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, 29 Aug 2012 14:53:06 -0000 These are very editorial in nature. (Hopefully the RFC editor would have caught them too.) They should be fixed, but I think you can save them for the next required edit. Thanks, Paul On 8/29/12 4:10 AM, Christer Holmberg wrote: > Hi, > > Based on Atle's findings, there are a few editorial nits that I think we shall fix: > > > Section 4.3.2: > ---------------- > > The text says: > > "Unless a feature capability indicator is inserted in a Feature-Caps > header field or a target refresh request,.." > > Replace "or" with "of". > > > Section 5.3.4: > ----------------- > > The text says: > > "There might be restrictions related to whether entities are allowed > to insert a feature capability indicator in registration related > messages, standalone transaction messages, or dialog related > messages, whether entities are..." > > Remove "or". > > > > Sections 7.3.2 and 7.3.3: > ----------------------------- > > In both sections we have the following text: > > "Description contains the Abstract, provided in the registration > feature capability indication registration template." > > However, there is no "Abstract" in the template. There is a "Description", though. > > So, I suggest to simply say: > > "Description, provided in the registration feature capability > indication registration template." > > > Regards, > > Christer > > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 28. elokuuta 2012 16:10 > To: Atle Monrad > Cc: SIPCORE > Subject: Re: [sipcore] Another quick WGLC for draft-ietf-sipcore-proxy-feature-08 > > On 8/28/12 1:45 AM, Atle Monrad wrote: >> Paul, all >> >> I've read through draft-ietf-sipcore-proxy-feature-08 and provided Christer et.al. with a number of proposed nits plus a couple of other wordings that seems to need corrections aswell. >> >> Generally I'm fine with this version of the draft. >> >> It seems to me that the draft has progressed as indicated by the previous comments given, thus I hope that the draft -08 can be accepted and with some polishing can progress towards completion rather soon. >> >> We have features in 3GPP Rel-10 and 3GPP Rel-11 that are waiting for completion of this draft. > > The only "polishing" I anticipate will be > - to respond to any iesg comments > - editorial fixes requested by the editor > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >