From vkg@bell-labs.com Tue Nov 1 06:52:28 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E991F0C72 for ; Tue, 1 Nov 2011 06:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.568 X-Spam-Level: X-Spam-Status: No, score=-106.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzoAKDP-2ZhG for ; Tue, 1 Nov 2011 06:52:27 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 82ABC1F0CAF for ; Tue, 1 Nov 2011 06:52:25 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pA1DqMcZ024949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 1 Nov 2011 08:52:22 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA1DqM5x012762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 1 Nov 2011 08:52:22 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pA1DqMgO026760 for ; Tue, 1 Nov 2011 08:52:22 -0500 (CDT) Message-ID: <4EAFFA49.1060804@bell-labs.com> Date: Tue, 01 Nov 2011 08:55:21 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20110927 Thunderbird/7.0 MIME-Version: 1.0 To: sipcore@ietf.org References: <4EAEE023.6010600@alum.mit.edu> <4EAEFC94.3050207@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 13:52:28 -0000 On 10/31/2011 10:57 PM, Iñaki Baz Castillo wrote: > Ok. IMHO "sips" is just impossible to work since a proxy adding a > "sips" schema must use a domain in the Record-Route, and such domain > could resolve to multiple NAPTR/SRV/A/AAAA records, so we loose the > pach for in-dialog requests and that's critical when Outbound is being > used. Well, one could insert the FQDN of the proxy in the R-R set such that rfc3263 resolution on that FQDN returns only one A/AAAA RR. However, this means that the FQDN identity must be present in the subjectAltName extension of the X.509 certificate for this to work as expected. Such "pinning" capability has been discussed before; see [1,2]. However, my impression is that most deployments use the generic URI (sip:example.com) in the certificate and do not bother with loading other identities (sip:p1.example.com, sip:p2.example.com, ...) in the certificate. [1] Slide 7 in http://www.ietf.org/proceedings/65/slides/sip-5.pdf [2] Slide 3 in http://www.ietf.org/proceedings/67/slides/sip-6.pdf Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From ibc@aliax.net Tue Nov 1 07:24:15 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1B5B21F9104 for ; Tue, 1 Nov 2011 07:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, 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 dobnK+ArMBWB for ; Tue, 1 Nov 2011 07:24:15 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37C6D21F914F for ; Tue, 1 Nov 2011 07:24:15 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so6899931vcb.31 for ; Tue, 01 Nov 2011 07:24:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.150.212 with SMTP id z20mr2784163vcv.58.1320157453591; Tue, 01 Nov 2011 07:24:13 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Tue, 1 Nov 2011 07:24:13 -0700 (PDT) In-Reply-To: <4EAFFA49.1060804@bell-labs.com> References: <4EAEE023.6010600@alum.mit.edu> <4EAEFC94.3050207@alum.mit.edu> <4EAFFA49.1060804@bell-labs.com> Date: Tue, 1 Nov 2011 15:24:13 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: "Vijay K. Gurbani" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 14:24:15 -0000 2011/11/1 Vijay K. Gurbani : > On 10/31/2011 10:57 PM, I=C3=B1aki Baz Castillo wrote: >> >> Ok. IMHO "sips" is just impossible to work since a proxy adding a >> "sips" schema must use a domain in the Record-Route, and such domain >> could resolve to multiple NAPTR/SRV/A/AAAA records, so we loose the >> pach for in-dialog requests and that's critical when Outbound is being >> used. > > Well, one could insert the FQDN of the proxy in the R-R set such > that rfc3263 resolution on that FQDN returns only one A/AAAA RR. > However, this means that the FQDN identity must be present in the > subjectAltName extension of the X.509 certificate for this to > work as expected. > > Such "pinning" capability has been discussed before; see [1,2]. > However, my impression is that most deployments use the generic > URI (sip:example.com) in the certificate and do not bother with > loading other identities (sip:p1.example.com, sip:p2.example.com, > ...) in the certificate. > > [1] Slide 7 in http://www.ietf.org/proceedings/65/slides/sip-5.pdf > [2] Slide 3 in http://www.ietf.org/proceedings/67/slides/sip-6.pdf Hi Vijay. Thanks a lot fot those links, they are very useful. --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Tue Nov 1 07:45:34 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD3A21F992E for ; Tue, 1 Nov 2011 07:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB9j0mb4dQ7d for ; Tue, 1 Nov 2011 07:45:33 -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 5BC5B21F9038 for ; Tue, 1 Nov 2011 07:45:33 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta03.westchester.pa.mail.comcast.net with comcast id rqfa1h00A0ldTLk53qlZUr; Tue, 01 Nov 2011 14:45:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta04.westchester.pa.mail.comcast.net with comcast id rqlY1h01K0tdiYw3QqlYtL; Tue, 01 Nov 2011 14:45:33 +0000 Message-ID: <4EB0060A.5020106@alum.mit.edu> Date: Tue, 01 Nov 2011 10:45:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4EAEE023.6010600@alum.mit.edu> <4EAEFC94.3050207@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 14:45:34 -0000 Inline On 10/31/11 11:57 PM, Iñaki Baz Castillo wrote: > 2011/10/31 Paul Kyzivat: >>> First of all let me say that I plan to remove "sips" schema from the >>> draft (given the ammount of issues with "sips" mechanism). >> >> Well, if you remove the use of sips, then all issues related to use of sips >> will go away. :-) >> >> But I got the impression that you wanted use of wss to force use of a >> secured connection e2e. sips is the only thing we have that comes close to >> providing that. > > Ok. So I will leave "sips" schema which in the context of WebSocket > transport requires WebSocket over TLS ("wss" schema in the WebSocket > URI connection of the client). And adjust examples and rules to be compliant with sips usage. > However, nobody prevents a WS client to establish a WSS connection but > use "sip" schema on top of it (as RFC 5630 section-3.1.3 states). Sure. >>> However, the remote peer (using SIP over UDP so "sip" scheme) never >>> contacts a SIP node speaking "sips", but "sip". The proxy adds two >>> Record-Route, the the UDP peer always contacts the URI in the >>> Record-Route with "sip" schema and UDP protocol. >> >> The intent of sips is that every hop, e2e, is sips over tls. >> Double R-R doesn't eliminate that requirement. > > Ok. IMHO "sips" is just impossible to work since a proxy adding a > "sips" schema must use a domain in the Record-Route, and such domain > could resolve to multiple NAPTR/SRV/A/AAAA records, so we loose the > pach for in-dialog requests and that's critical when Outbound is being > used. However this is another history out of the scope here. Reports on problems trying to implement sips are welcome. >> OK. If your intent is to require use of outbound then that answers a lot. >> Then we will have to ensure that it all integrates with outbound. > > Sure :) > > >>> I also have to add a modification to RFC 3261: >>> >>> When a proxy/server receives a request via WebSocket transport, it MAY >>> choose not to add the ";received" param in the top Via. This is >>> because WebSocket is supposed to use already existing infrastructure >>> in which there can be certain number of HTTP or TCP load balancers >>> between the client and HTTP/WebSocket server, so the server would >>> write into ;received the IP of the load balancer in front of it. This >>> would reveal the client the internal HTTP/TCP topology of the server >>> which could be insecure. >>> >>> So adding ;received to Via would be a local policy decision. >> >> This seems like a real hack. If there is a problem to deal with here I hope >> it can be abstracted. > > Let's assume that: > > - A SIP Websocket client is a real client (not a proxy or server). > - The spec will require Outbound so ;received and ;rport is 100% > useless (even more when the server cannot try the IP in > ;received/;rport for sending a response in case the connection is > closed since a WebSocket client does not listen for incoming > connections). I think you are saying that those are useless with outbound in general, so the remedy you are suggesting could be abstracted to all uses of outbound. Is that right? > So IMHO it's clear that ;received is useless in SIP over WebSocket, > and it can reveal server internal infrastructure to the client. So, > what can we do here? IMHO the SIP WebSocket server/proxy should be > able not to set the ;received param given the above rationale. Why is this internal structure more important to hide in the websocket case than in other cases? Is this just for the paranoid? One of the justifications for SBCs is so that they can do "topology hiding". Are you just asking for a special case of this? Thanks, Paul From pkyzivat@alum.mit.edu Tue Nov 1 10:26:05 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398101F0C44 for ; Tue, 1 Nov 2011 10:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 InCuUnt4lW82 for ; Tue, 1 Nov 2011 10:26:04 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2702611E8094 for ; Tue, 1 Nov 2011 10:26:03 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta05.westchester.pa.mail.comcast.net with comcast id rohc1h0031vXlb855tRmT8; Tue, 01 Nov 2011 17:25:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta17.westchester.pa.mail.comcast.net with comcast id rtRl1h01t0tdiYw3dtRlZ2; Tue, 01 Nov 2011 17:25:46 +0000 Message-ID: <4EB02B97.5080008@alum.mit.edu> Date: Tue, 01 Nov 2011 13:25:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se> <6CB233EE-CBD0-4319-B46F-1483302263E0@cisco.com> , <4EAEDEDD.30202@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852235717398@ESESSCMS0356.eemea.erics son.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852235717398@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 17:26:05 -0000 On 10/31/11 2:36 PM, Christer Holmberg wrote: > > Hi, > >>> Since then it has slowly morphed into the type of DWIM vs DWIS mechanism that I thought we agreed we did not to do. Keep in mind any UA can >>> act as an embedded proxy and this looks like the feature scheme that I thought was the roughly the core of the DWIM vs DWIS argument. >>> >>> Anyways, for any mechanisms of this sort, I will be strongly apposed unless the registration mechanism for new tags, features, options or whatever >>> you call them is the same as it is for sip option tags. I have spoken at the mic several times in favor of what Christer was presenting but it always had >>> that property. This does not and I am strongly opposed to it. Given the previous conversation were in the other context, whatever consensus they >>> may or may not have had does not seem to apply here. If the goal is simply to change what is required to register option tags, I'd be happy to have that conversation. >> >> Currently the draft mechanism is indicating RFC-3840-type feature-tags. As such yes new values require RFCs published through IETF Consensus (IESG approval), as >> opposed to standards track RFCs as required for option-tags. I believe as a WG-draft we can choose whether tokens put into a new header are actual feature-tags, >> or some new "capability-tags" with higher RFC approval status required. And of course we can say what semantics such new capability-tags RFCs must define and be >> constrained to. I don't think any of those things prevent us from making it a WG draft do they? I thought being a WG draft just meant the WG accepted the goal as a >> milestone, had enough people willing to work on it, and thought the general direction of the draft's solution was right. >> >> Actually, its possible to define feature tags without any standards >> action. See section 3.1.3 of RFC 2506. (It allows feature tags beginning >> with "u." followed by a URI.) >> >> Its my impression that this is one of the things that 3gpp likes about >> feature tags - they can define new ones without an ietf standards action. > > There are no 3GPP defined feature tags beginning with "u", and as far as I know 3GPP has (or, is in the progress of) registered all their feature tags with IANA. OK, my mistake. There is also a global tree (tags starting with g.) for which new values can be registered by expert review, without publication of an RFC. And 3gpp has registered several of these. > And, as you also indicated, we can specify what information a feature tag specification, and its associated IANA registration, needs to contain. If we use feature tags, unless we require use of the "sip" tree, or define a new tree, I don't think we can specify what the specification includes, since the registration is defined by RFC 2506. > Also, if you look at the use-cases behind this work, I think feature tags are very appropriate. We are talking about feature indications ("I can do this"). And, we are not talking about extensions to the SIP protocol, in > which case I agree option-tags probably would be more suitable. Frankly, IMO the adoption of feature tags for 3840 was a mistake, because the semantics of feature tags for callee caps / callerprefs largely disjoint from the intended original use of feature tags. If the intent is to require a specification with particular properties, then we can do this better by defining a new namespace. Thanks, Paul From ibc@aliax.net Tue Nov 1 10:27:35 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2548511E8094 for ; Tue, 1 Nov 2011 10:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnTeJYycPrwt for ; Tue, 1 Nov 2011 10:27:34 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 578671F0C44 for ; Tue, 1 Nov 2011 10:27:34 -0700 (PDT) Received: by vws5 with SMTP id 5so7132364vws.31 for ; Tue, 01 Nov 2011 10:26:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.35.70 with SMTP id f6mr384491vdj.84.1320168089658; Tue, 01 Nov 2011 10:21:29 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Tue, 1 Nov 2011 10:21:29 -0700 (PDT) In-Reply-To: <4EB0060A.5020106@alum.mit.edu> References: <4EAEE023.6010600@alum.mit.edu> <4EAEFC94.3050207@alum.mit.edu> <4EB0060A.5020106@alum.mit.edu> Date: Tue, 1 Nov 2011 18:21:29 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 17:27:35 -0000 2011/11/1 Paul Kyzivat : >> Ok. So I will leave "sips" schema which in the context of WebSocket >> transport requires WebSocket over TLS ("wss" schema in the WebSocket >> URI connection of the client). > > And adjust examples and rules to be compliant with sips usage. Sure. >> Ok. IMHO "sips" is just impossible to work since a proxy adding a >> "sips" schema must use a domain in the Record-Route, and such domain >> could resolve to multiple NAPTR/SRV/A/AAAA records, so we loose the >> pach for in-dialog requests and that's critical when Outbound is being >> used. However this is another history out of the scope here. > > Reports on problems trying to implement sips are welcome. Yes, sorry, let's discuss about it in a new future thread. >> Let's assume that: >> >> - A SIP Websocket client is a real client (not a proxy or server). >> - The spec will require Outbound so ;received and ;rport is 100% >> useless (even more when the server cannot try the IP in >> ;received/;rport for sending a response in case the connection is >> closed since a WebSocket client does not listen for incoming >> connections). > > I think you are saying that those are useless with outbound in general, s= o > the remedy you are suggesting could be abstracted to all uses of outbound= . > Is that right? Well, in case of SIP over UDP/TCP/TLS usage of ;received param is indeed useless. But in case of SIP over WebSocket is not just useless but also dangerous as it reveals to the WS client the IP of a possible TCP/HTTP load-balancer before the WebSocket SIP server. Such internal IP is hidden for the WS client during the WebSocket handshake (an HTTP GET request + 101 response). >> So IMHO it's clear that ;received is useless in SIP over WebSocket, >> and it can reveal server internal infrastructure to the client. So, >> what can we do here? IMHO the SIP WebSocket server/proxy should be >> able not to set the ;received param given the above rationale. > > Why is this internal structure more important to hide in the websocket ca= se > than in other cases? Is this just for the paranoid? I'm not involved in HTTP scenarios but I got some interesting replies about this subject in Hyby WG (WebSocket WG): http://www.ietf.org/mail-archive/web/hybi/current/msg09091.html Some text in that thread: ------------------------------ Yes, the problem comes from the fact that a protocol that is used across a number of intermediaries would suddenly transport sensible information. Internal IP addresses *are* sensible information to a number of companies. Whether this makes sense or not is not our problem, these companies don't want their internal networks to be unveiled to outers and they have their reasons for this. Now if your usual WS server emits its address in every response and the reverse-proxy that is placed in front of it does not change it, all of your clients will get this information they don't need. > BTW it would be really great a simple "Connection-Source" header in > the HTTP 101 response during the WS handshake. Examples: > > Connetion-Source: 34.67.123.94:26745 > > Connection-Source: [20a:12::3dde:190:ed5]:19443 Same problem, you'll divulgate the IP:port of the reverse-proxy to clients and the number of reverse-proxies. It can even be used by attackers to detect that they managed to crash one of them because after a specific request, they use another one. An HTTP chain very commonly involves these components : [client]----[proxy]-------//// net ////-------[rproxy]------[server] The proxy commonly is on the client's network in enterprises, or at the ISP's for home or mobile users. The "net" may involve a number of transparent intermediaries, but that's not that much common though. The reverse proxy (rproxy) generally is on the server side. It's in fact common to see a long chain of many of them. 3-5 are not uncommon these days, though some of them may be transparent. I have not even represented NAT devices such as firewalls or some L4 load balancers which often don't rewrite the source IP but change the source port. ------------------------------ > One of the justifications for SBCs is so that they can do "topology hidin= g". > Are you just asking for a special case of this? Well, IMHO "topolgy hiding" means that the SBC hides leg-A details into leg= -B. What I'm suggesting is that the server (the SIP WebSocket server) should not reveal to the client sensible information about internal IP addresses of the provider TCP/HTTP load-balancers located in server side. IMHO the thread above (the link) justifies that with good rationale. However I don't think that omitting the ;received stuff in the SIP WebSocket server is something critical. As said before, ;received is useless in SIP over WebSocket: it's a connection oriented protocol so responses are sent using the same connection, and in case such connection is closed responses cannot be sent to the WS client since the WS client does not liste for incoming connections. The same occurs with SIP TCP natted clients, but in this last case revealing the ;received IP is not a risk. Regards. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Tue Nov 1 11:56:53 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A343C11E816E for ; Tue, 1 Nov 2011 11:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, J_CHICKENPOX_83=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 iknB9XLPJtR4 for ; Tue, 1 Nov 2011 11:56:53 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id E05F011E811F for ; Tue, 1 Nov 2011 11:56:52 -0700 (PDT) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA1IsbeI006412; Tue, 1 Nov 2011 14:54:37 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Nov 2011 14:53:51 -0400 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 00:23:55 +0530 Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by inba-hub01.sonusnet.com (10.70.51.86) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 2 Nov 2011 00:23:54 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Wed, 2 Nov 2011 00:23:54 +0530 From: Ravindran Parthasarathi To: "Worley, Dale R (Dale)" , "sipcore@ietf.org" Thread-Topic: [sipcore] Proposal for a new SIP transport (WebSocket) Thread-Index: AcyVikXNSMUssoD1TwmwuLzmfhjfMwCNzwOAAAB9xIAAA3sXgAABP8eAADu8GgA= Date: Tue, 1 Nov 2011 18:53:53 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6CBD80@inba-mail01.sonusnet.com> References: <4EAAD0CD.6010506@alum.mit.edu> <4E2EBDE2-9128-4E6E-ACA6-E4671EA23934@acmepacket.com> , <2FCEB44F-12ED-4460-987A-E4FC6E4FB48E@acmepacket.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.53.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Nov 2011 18:53:55.0706 (UTC) FILETIME=[9B399DA0:01CC98C7] Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 18:56:53 -0000 Dale, > >It sounds like WebSocket paths are effectively a variant of the >connection between the UA and the Edge Proxy in SIP Outbound (RFC >5626), and what they need is a "flow token" (defined by the edge >proxy), not a new Via transport value (standardized). > Agree with you. In fact, I got the same answer for not choosing SIP as RTCW= eb signaling protocol because SIP outbound(RFC 5626) is addressed in part o= f RFC 3261 and the same NAT issue is addressed in websocket base protocol i= tself. Thanks Partha >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >Behalf Of Worley, Dale R (Dale) >Sent: Tuesday, November 01, 2011 1:07 AM >To: sipcore@ietf.org >Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) > >> From: I=F1aki Baz Castillo [ibc@aliax.net] >> >> Well, honestly I see no use case for using WebSocket transport between >> SIP proxies/servers. WebSocket is clearly a transport for web browsers >> and also for client applications. There is no advantage in using >> WebSocket between other SIP nodes. > >It sounds like WebSocket paths are effectively a variant of the >connection between the UA and the Edge Proxy in SIP Outbound (RFC >5626), and what they need is a "flow token" (defined by the edge >proxy), not a new Via transport value (standardized). > >> From: Hadriel Kaplan [HKaplan@acmepacket.com] >> >> 2) Since websocket can cross even restrictive firewalls, you could use >> a piece of proxy-ish software on your laptop like SER or Asterix or >> SipXecs or whatever. I have no idea why you'd want to run those from >> behind a restrictive firewall, or why you couldn't configure the >> firewall to let you do it, instead of using websocket; but if you >> needed to, you could use websocket. > >Isn't there an RFC (around 1 April 1988?) detailing encapsulating IP >packets in HTTP requests/responses as a way to get through restrictive >firewalls? > >Dale >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From pravindran@sonusnet.com Tue Nov 1 12:10:02 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 436D321F8D0E for ; Tue, 1 Nov 2011 12:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, J_CHICKENPOX_83=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 gPxKy7ljPu+S for ; Tue, 1 Nov 2011 12:10:01 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0387811E80B5 for ; Tue, 1 Nov 2011 12:09:53 -0700 (PDT) Received: from sonusmail06.sonusnet.com (sonusmail06.sonusnet.com [10.128.32.156]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id pA1J9cKC016304; Tue, 1 Nov 2011 15:09:38 -0400 Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail06.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Nov 2011 15:08:11 -0400 Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Nov 2011 00:38:14 +0530 Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by inba-hub01.sonusnet.com (10.70.51.86) with Microsoft SMTP Server (TLS) id 14.1.339.1; Wed, 2 Nov 2011 00:38:13 +0530 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0339.001; Wed, 2 Nov 2011 00:38:13 +0530 From: Ravindran Parthasarathi To: Ravindran Parthasarathi , "Worley, Dale R (Dale)" , "sipcore@ietf.org" Thread-Topic: [sipcore] Proposal for a new SIP transport (WebSocket) Thread-Index: AcyVikXNSMUssoD1TwmwuLzmfhjfMwCNzwOAAAB9xIAAA3sXgAABP8eAADu8GgAAAQROgA== Date: Tue, 1 Nov 2011 19:08:13 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6CBDD3@inba-mail01.sonusnet.com> References: <4EAAD0CD.6010506@alum.mit.edu> <4E2EBDE2-9128-4E6E-ACA6-E4671EA23934@acmepacket.com> , <2FCEB44F-12ED-4460-987A-E4FC6E4FB48E@acmepacket.com> <387F9047F55E8C42850AD6B3A7A03C6CBD80@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6CBD80@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.53.6] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 01 Nov 2011 19:08:14.0721 (UTC) FILETIME=[9B3CE710:01CC98C9] Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 19:10:02 -0000 Typo - because SIP outbound(RFC 5626) is "not" addressed as >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >Behalf Of Ravindran Parthasarathi >Sent: Wednesday, November 02, 2011 12:24 AM >To: Worley, Dale R (Dale); sipcore@ietf.org >Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) > >Dale, > >> >>It sounds like WebSocket paths are effectively a variant of the >>connection between the UA and the Edge Proxy in SIP Outbound (RFC >>5626), and what they need is a "flow token" (defined by the edge >>proxy), not a new Via transport value (standardized). >> > >Agree with you. In fact, I got the same answer for not choosing SIP as >RTCWeb signaling protocol because SIP outbound(RFC 5626) is not addressed = as >part of RFC 3261 and the same NAT issue is addressed in websocket base >protocol itself. > >Thanks >Partha > >>-----Original Message----- >>From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>Behalf Of Worley, Dale R (Dale) >>Sent: Tuesday, November 01, 2011 1:07 AM >>To: sipcore@ietf.org >>Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) >> >>> From: I=F1aki Baz Castillo [ibc@aliax.net] >>> >>> Well, honestly I see no use case for using WebSocket transport >between >>> SIP proxies/servers. WebSocket is clearly a transport for web >browsers >>> and also for client applications. There is no advantage in using >>> WebSocket between other SIP nodes. >> >>It sounds like WebSocket paths are effectively a variant of the >>connection between the UA and the Edge Proxy in SIP Outbound (RFC >>5626), and what they need is a "flow token" (defined by the edge >>proxy), not a new Via transport value (standardized). >> >>> From: Hadriel Kaplan [HKaplan@acmepacket.com] >>> >>> 2) Since websocket can cross even restrictive firewalls, you could >use >>> a piece of proxy-ish software on your laptop like SER or Asterix or >>> SipXecs or whatever. I have no idea why you'd want to run those from >>> behind a restrictive firewall, or why you couldn't configure the >>> firewall to let you do it, instead of using websocket; but if you >>> needed to, you could use websocket. >> >>Isn't there an RFC (around 1 April 1988?) detailing encapsulating IP >>packets in HTTP requests/responses as a way to get through restrictive >>firewalls? >> >>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 Nov 1 12:34:54 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7051121F9BBD for ; Tue, 1 Nov 2011 12:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.383 X-Spam-Level: X-Spam-Status: No, score=-2.383 tagged_above=-999 required=5 tests=[AWL=0.216, 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 9ZuRCbBpb-MB for ; Tue, 1 Nov 2011 12:34:53 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6465921F8F09 for ; Tue, 1 Nov 2011 12:34:36 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta05.westchester.pa.mail.comcast.net with comcast id rvBL1h0080cZkys55vXu1R; Tue, 01 Nov 2011 19:31:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta10.westchester.pa.mail.comcast.net with comcast id rvXt1h01o0tdiYw3WvXtCu; Tue, 01 Nov 2011 19:31:54 +0000 Message-ID: <4EB04927.9060402@alum.mit.edu> Date: Tue, 01 Nov 2011 15:31:51 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05852234CFC9FD@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852234CFC9FD@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 19:34:54 -0000 On 10/29/11 5:15 PM, Christer Holmberg wrote: > > Hi Cullen, > >> This started as something for a proxy to indicate what type of things it could support that could show up in a Proxy-Require and allow a given proxy to indicate to downstream things an additional Proxy-Require level requirement. I thought that sounded like a reasonable idea but we needed to >> nail down the details of what we were actually talking about. >> >> Since then it has slowly morphed into the type of DWIM vs DWIS mechanism that I thought we agreed we did not to do. Keep in mind any UA can act as an embedded proxy and this looks like the feature scheme that I thought was the roughly the core of the DWIM vs DWIS argument. > > The requirements clearly say (or, are supposed to say) that the proxy that inserts the support indication must not make any assumptions that a receiver will understand the meaning of it. It is only an "I can do this" indication - NOT an "I have done this" or "I expect you to do this" indication. That has been the intention from day one :) I guess in this context, DWIS/DWIM stand for "*Does* what I say/mean", rather than "Do". > In that way it is exactly the same as when a UA inserts a feature tag in the Contact header field. The proposal is to allow entities that do not insert a Contact header field to do the same. Nothing more - nothing less. And there was a huge debate about DWIS/DWIM when 3840/3841 were developed. The goal was that everybody be able to know what the features meant. Its debatable whether we achieved that. Later, a case about DWIS/DWIM came up around "service identification", though it wasn't directly connected to callee-caps/callerprefs. It culminated in: RFC 5897: Identification of Communications Services in the Session Initiation Protocol (SIP) (Jonathan Rosenberg) RFC 6050: A Session Initiation Protocol (SIP) Extension for the Identification of Services (P-Preferred-Service / P-Asserted-Service) (Keith Drage) The latter includes: It should be noted that RFC 5897 [RFC5897] clearly states that declarative service identification -- the process by which a user agent inserts a moniker into a message that defines the desired service, separate from explicit and well-defined protocol mechanisms -- is harmful. During a session setup, proxies may need to understand what service the request is related to in order to know what application server to contact or other service logic to invoke. The SIP INVITE request contains all of the information necessary to determine the service. However, the calculation of the service may be computational and database intensive. For example, a given trust domain's definition of a service might include request authorization. Moreover, the analysis may require examination of the Session Description Protocol (SDP). For example, an INVITE request with video SDP directed to a video-on- demand Request-URI could be marked as an IPTV session. An INVITE request with push-to-talk over cellular (PoC) routes could be marked as a PoC session. An INVITE request with a Require header field containing an option tag of "foogame" could be marked as a foogame session. NOTE: If the information contained within the SIP INVITE request is not sufficient to uniquely identify a service, the remedy is to extend the SIP signaling to capture the missing element. RFC 5897 [RFC5897] provides further explanation. By providing a mechanism to compute and store the results of the domain-specific service calculation, i.e., the derived service identification, this optimization allows a single trusted proxy to perform an analysis of the request and authorize the requestor's permission to request such a service. The proxy may then include a service identifier that relieves other trusted proxies and trusted UAs from performing further duplicate analysis of the request for their service identification purposes. In addition, this extension allows user agent clients outside the trust domain to provide a hint of the requested service. RFC 6050 then goes on to define P-Preferred-Service and P-Asserted-Service header fields that carry "Service_IDs" represented as URNs. IIUC these URNs encapsulate IMS Communication Service Identifiers and Application Service Identifiers. It carefully explains that these are used simply for optimization and can be derived from other signaling. But this does relate, because I find that there are also feature tags defined for these identifiers: g.3gpp.icsi-ref: Each value of the Service Reference media feature-tag indicates the software applications supported by the agent. The values for this tag equal the IMS communication Service Identifier (ICSI) values supported by the agent. The Service Reference media feature tag is defined to fulfil the requirements for forking to an appropriate UE when multiple UEs are registered and dispatch to an appropriate application within the UE based upon the IMS communication Service Identifier (ICSI) values as stated in 3GPP TS 23.228. g.3gpp.iari-ref: Each value of the Application Reference media feature-tag indicates the software applications supported by the agent. The values for this tag equal IMS Application Reference Identifier (IARI) values supported by the agent The Application Reference media feature tag is defined to fulfil the requirements for forking to an appropriate UE when multiple UEs are registered and dispatch to an appropriate application within the UE based upon and IMS Application Reference Identifier (IARI) values as stated in 3GPP TS 23.228. Using these as feature tags seems to be an example of "declarative service identification" that RFC 5897 proscribes. Of course that is all for UAs. The examples given in draft-ietf-sipcore-proxy-feature-reqs all appear to be of a similar nature - I suspect they may in fact *be* ICSIs. And in this case I don't see any intent that they be derivable from other signaling and used simply as an optimization. So I think there is indeed something to be concerned with here regarding DWIS/DWIM. Thanks, Paul > I am happy to add whatever text is needed to make that even more clear. > > Regards, > > Christer > > > > > >> Anyways, for any mechanisms of this sort, I will be strongly apposed unless the registration mechanism for new tags, features, options or whatever you call them is the same as it is for sip option tags. I have spoken at the mic several times in favor of what Christer was presenting but it always >> had that property. This does not and I am strongly opposed to it. Given the previous conversation were in the other context, whatever consensus they may or may not have had does not seem to apply here. If the goal is simply to change what is required to register option tags, I'd be happy to >> have that conversation. > > > > > > On Oct 28, 2011, at 2:46 PM, Hadriel Kaplan wrote: > >> Howdy, >> I've read this latest draft and I propose we make this a WG item. I believe there has been strong consensus for this work, from even last year, but also from the following email thread from the SIPCORE Chairs asking for WG consensus: >> http://www.ietf.org/mail-archive/web/sipcore/current/msg04104.html >> >> If this needs a new charter milestone, then I propose a new milestone be added for: >> "A mechanism to indicate proxy/B2BUA capabilities to both endpoints and other proxies/B2BUAs in the path of a SIP REGISTER transaction or a dialog-forming transaction". >> >> There may be some nits/details to argue over in the draft, but I think we can do that as a WG draft/item. >> >> As often asked for by WG Chairs when considering new milestones: I also volunteer to spend time/effort in contributing to the work item, and helping the authors by providing text if needed. >> >> -hadriel >> >> >> On Oct 28, 2011, at 6:09 AM, Christer Holmberg wrote: >> >>> >>> Hi, >>> >>> I've submitted a new version (-03) of draft-holmberg-sipcore-proxy-feature, which suggests a solution based on the proxy feature requirements. >>> >>> The MAJOR CHANGE, based on the list discussions, is that the mechanism now uses a new header field, Feature-Caps, rather than existing header fields (Record-Route, Path etc). >>> >>> I did not include the "SIP-URI alternative" at this point. >>> >>> We will also have to think about the "proxy" terminology, as it has been indicated that entities using the mechanism might not be pure proxies. But, I don't think that should prevent us from moving forward the the mechanism as such. >>> >>> Thanks to everyone who has provided feedback and input! >>> >>> Regards, >>> >>> Christer >>> _______________________________________________ >>> 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 Nov 1 13:25:45 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C09D21F9C9B for ; Tue, 1 Nov 2011 13:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 5kn6fX+Vj2Vf for ; Tue, 1 Nov 2011 13:25:44 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 544FD21F9C9A for ; Tue, 1 Nov 2011 13:25:44 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta12.westchester.pa.mail.comcast.net with comcast id rwFt1h00A0bG4ec5CwNwKT; Tue, 01 Nov 2011 20:22:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta03.westchester.pa.mail.comcast.net with comcast id rwNv1h01T0tdiYw3PwNv9k; Tue, 01 Nov 2011 20:22:56 +0000 Message-ID: <4EB0551D.5090309@alum.mit.edu> Date: Tue, 01 Nov 2011 16:22:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 20:25:45 -0000 Here are comments on the new version. From the introduction: This document defines a new SIP header field, Feature-Caps, that can be used by entities to indicate support of features and capabilities, in case they cannot use the Contact header field for that purpose. This is really loose!!! Its not limited to proxies. It could be any UA that "cannot use the Contact header field for that purpose". What constitutes a such a reason? The Definitions section has a very non-standard definition of Proxy: Proxy: Within this specification, a "proxy" refers to an entity that does not indicate supported features using the Contact header field. Normally, however, entities that indicate support of features do not act as pure proxies, as defined by RFC 3261, but rather contain different levels of B2BUAs functionality. IMO Proxy should be defined only as it is in 3261. Section 4.1 says: A UA MUST NOT, except when it acts as a SIP registrar, insert a Feature-Caps header field in a SIP request or response. By this do you intend that a B2BUA/SBC cannot use this? Or are you drawing a fine line, where an element nominally acting as a proxy inserts this, even if it describes a feature that will require it starting to act as a B2BUA in the same dialog? In section 6.2: If a feature tag is inserted in a Feature-Caps header field of an initial SIP request or response for a dialog, the feature associated with the feature tag MUST be supported for the dialog, until the dialog is terminated. Do you mean that it cannot be changed by subsequent signaling within the dialog? If Feature-Caps can be used by a 3pcc (b2bua) controller (can it?) then this limitation could break 3pcc transfers, where the transfer-target has different features. Section 8: Since this is using feature tags, it has to live with the IANA registration mechanism defined in 2506. I think that means, at best, you can require that certain material be included in the "Related standards or documents" that can optionally be included in a feature tag registration. That means it won't be possible to discern from a feature tag registration whether it applicable for use in Feature-Caps. Thanks, Paul On 10/28/11 6:09 AM, Christer Holmberg wrote: > > Hi, > > I've submitted a new version (-03) of draft-holmberg-sipcore-proxy-feature, which suggests a solution based on the proxy feature requirements. > > The MAJOR CHANGE, based on the list discussions, is that the mechanism now uses a new header field, Feature-Caps, rather than existing header fields (Record-Route, Path etc). > > I did not include the "SIP-URI alternative" at this point. > > We will also have to think about the "proxy" terminology, as it has been indicated that entities using the mechanism might not be pure proxies. But, I don't think that should prevent us from moving forward the the mechanism as such. > > Thanks to everyone who has provided feedback and input! > > Regards, > > Christer > From pkyzivat@alum.mit.edu Tue Nov 1 13:34:02 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AAB11E812D for ; Tue, 1 Nov 2011 13:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, 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 Swjex4DJ6JAr for ; Tue, 1 Nov 2011 13:34:01 -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 4ACFA11E80B7 for ; Tue, 1 Nov 2011 13:34:01 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id ruxQ1h0031ap0As53wYTAh; Tue, 01 Nov 2011 20:32:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta22.westchester.pa.mail.comcast.net with comcast id rwYP1h02e0tdiYw3iwYP9x; Tue, 01 Nov 2011 20:32:25 +0000 Message-ID: <4EB05756.3090303@alum.mit.edu> Date: Tue, 01 Nov 2011 16:32:22 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Hadriel Kaplan References: <4E8C785D.5080003@alum.mit.edu> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 20:34:02 -0000 On 10/28/11 4:46 PM, Hadriel Kaplan wrote: > Howdy, > I've read this latest draft and I propose we make this a WG item. I believe there has been strong consensus for this work, from even last year, but also from the following email thread from the SIPCORE Chairs asking for WG consensus: > http://www.ietf.org/mail-archive/web/sipcore/current/msg04104.html After discussion with the ADs, we decided to generate an item for the *requirements* document. And Christer mutated that document into the requirements doc that was then adopted as a WG draft. > If this needs a new charter milestone, then I propose a new milestone be added for: > "A mechanism to indicate proxy/B2BUA capabilities to both endpoints and other proxies/B2BUAs in the path of a SIP REGISTER transaction or a dialog-forming transaction". > > There may be some nits/details to argue over in the draft, but I think we can do that as a WG draft/item. > > As often asked for by WG Chairs when considering new milestones: I also volunteer to spend time/effort in contributing to the work item, and helping the authors by providing text if needed. IMO there is still a lot of volatility around what the mechanism should look like. The new draft (with the ink still wet) is a substantial change from the prior one. I'd like to see it stabilize a bit before moving to adopt it. I appreciate your joining in the discussion. Till now its mostly been a dialog between me and Christer with an occasional shot from someone else. Thanks, Paul > -hadriel > > > On Oct 28, 2011, at 6:09 AM, Christer Holmberg wrote: > >> >> Hi, >> >> I've submitted a new version (-03) of draft-holmberg-sipcore-proxy-feature, which suggests a solution based on the proxy feature requirements. >> >> The MAJOR CHANGE, based on the list discussions, is that the mechanism now uses a new header field, Feature-Caps, rather than existing header fields (Record-Route, Path etc). >> >> I did not include the "SIP-URI alternative" at this point. >> >> We will also have to think about the "proxy" terminology, as it has been indicated that entities using the mechanism might not be pure proxies. But, I don't think that should prevent us from moving forward the the mechanism as such. >> >> Thanks to everyone who has provided feedback and input! >> >> Regards, >> >> Christer >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > From christer.holmberg@ericsson.com Tue Nov 1 14:26:39 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5367A11E80DC for ; Tue, 1 Nov 2011 14:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.254 X-Spam-Level: X-Spam-Status: No, score=-6.254 tagged_above=-999 required=5 tests=[AWL=0.345, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkpdOxtLHE59 for ; Tue, 1 Nov 2011 14:26:38 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1FCB311E808B for ; Tue, 1 Nov 2011 14:26:37 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-52-4eb0600760c9 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5C.AF.20773.70060BE4; Tue, 1 Nov 2011 22:09:27 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 1 Nov 2011 22:09:27 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 1 Nov 2011 22:09:25 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) Thread-Index: AcyYzOmjZ2wqI4Z1RbKWaZ3HhNgWkQACmjUa Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585223571739C@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852234CFC9FD@ESESSCMS0356.eemea.ericsson.se>, <4EB04927.9060402@alum.mit.edu> In-Reply-To: <4EB04927.9060402@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 21:26:39 -0000 Hi, >>> This started as something for a proxy to indicate what type of things = it could support that could show up in a Proxy-Require and allow a given pr= oxy to=20 >>> indicate to downstream things an additional Proxy-Require level require= ment. I thought that sounded like a reasonable idea but we needed to >>> nail down the details of what we were actually talking about. >>> >>> Since then it has slowly morphed into the type of DWIM vs DWIS mechanis= m that I thought we agreed we did not to do. Keep in mind any UA can act as= an embedded proxy and this looks like the feature scheme that I thought wa= s the roughly the core of the DWIM vs DWIS argument. >> >> The requirements clearly say (or, are supposed to say) that the proxy th= at inserts the support indication must not make any assumptions that a rece= iver >> will understand the meaning of it. It is only an "I can do this" indicat= ion - NOT an "I have done this" or "I expect you to do this" indication. Th= at has been the intention from day one :) > > I guess in this context, DWIS/DWIM stand for "*Does* what I say/mean", > rather than "Do". That is not true either. The use-cases do not indicate what an entity "does= ". It only indicates something that it is able to do, ie "I can do this" - = as is described in the requirements.=20 The entities do not insert the feature tags to request other entities to do= things. In fact, we have even a WG agreement that things like "service inv= ocation" is out of the scope of the current charter. >> In that way it is exactly the same as when a UA inserts a feature tag in= the Contact header field. The proposal is to allow entities that do not in= sert a Contact header field to do the same. Nothing more - nothing less. > > And there was a huge debate about DWIS/DWIM when 3840/3841 were developed= . > > The goal was that everybody be able to know what the features meant. > Its debatable whether we achieved that. > > Later, a case about DWIS/DWIM came up around "service identification", > though it wasn't directly connected to callee-caps/callerprefs. It > culminated in: > Of course that is all for UAs. The examples given in > draft-ietf-sipcore-proxy-feature-reqs all appear to be of a similar > nature - I suspect they may in fact *be* ICSIs. And in this case I don't > see any intent that they be derivable from other signaling and used > simply as an optimization. > > So I think there is indeed something to be concerned with here regarding > DWIS/DWIM. Again, in the use-cases, the entities that inserts the feature indication d= o not assume, or request, that anyone else will do something. They only ind= icate what they CAN do, and the sessions (or, registrations), as part of wh= ich the feature indication is included, will not fail in case other entitie= s do not understand , and/or do not support, the supported feature(s). Regards, Christer >> Anyways, for any mechanisms of this sort, I will be strongly apposed unl= ess the registration mechanism for new tags, features, options or whatever = you call them is the same as it is for sip option tags. I have spoken at th= e mic several times in favor of what Christer was presenting but it always >> had that property. This does not and I am strongly opposed to it. Given = the previous conversation were in the other context, whatever consensus the= y may or may not have had does not seem to apply here. If the goal is simpl= y to change what is required to register option tags, I'd be happy to >> have that conversation. > > > > > > On Oct 28, 2011, at 2:46 PM, Hadriel Kaplan wrote: > >> Howdy, >> I've read this latest draft and I propose we make this a WG item. I bel= ieve there has been strong consensus for this work, from even last year, bu= t also from the following email thread from the SIPCORE Chairs asking for W= G consensus: >> http://www.ietf.org/mail-archive/web/sipcore/current/msg04104.html >> >> If this needs a new charter milestone, then I propose a new milestone be= added for: >> "A mechanism to indicate proxy/B2BUA capabilities to both endpoints and = other proxies/B2BUAs in the path of a SIP REGISTER transaction or a dialog-= forming transaction". >> >> There may be some nits/details to argue over in the draft, but I think w= e can do that as a WG draft/item. >> >> As often asked for by WG Chairs when considering new milestones: I also = volunteer to spend time/effort in contributing to the work item, and helpin= g the authors by providing text if needed. >> >> -hadriel >> >> >> On Oct 28, 2011, at 6:09 AM, Christer Holmberg wrote: >> >>> >>> Hi, >>> >>> I've submitted a new version (-03) of draft-holmberg-sipcore-proxy-feat= ure, which suggests a solution based on the proxy feature requirements. >>> >>> The MAJOR CHANGE, based on the list discussions, is that the mechanism = now uses a new header field, Feature-Caps, rather than existing header fiel= ds (Record-Route, Path etc). >>> >>> I did not include the "SIP-URI alternative" at this point. >>> >>> We will also have to think about the "proxy" terminology, as it has bee= n indicated that entities using the mechanism might not be pure proxies. Bu= t, I don't think that should prevent us from moving forward the the mechani= sm as such. >>> >>> Thanks to everyone who has provided feedback and input! >>> >>> Regards, >>> >>> Christer >>> _______________________________________________ >>> 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 Tue Nov 1 14:31:21 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A647811E80E5 for ; Tue, 1 Nov 2011 14:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.259 X-Spam-Level: X-Spam-Status: No, score=-6.259 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pzyr-puydNuF for ; Tue, 1 Nov 2011 14:31:21 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA4511E80A2 for ; Tue, 1 Nov 2011 14:31:20 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-04-4eb06527cdbc Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FB.01.20773.72560BE4; Tue, 1 Nov 2011 22:31:19 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Tue, 1 Nov 2011 22:31:19 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 1 Nov 2011 22:31:18 +0100 Thread-Topic: Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) Thread-Index: AcyY1ApsQeBa6bjQQq+kZtsD50G4XgABo1RN Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585223571739D@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341AE6C3@ESESSCMS0356.eemea.ericsson.se> <96C0AE13-C263-48BA-96BE-64A047484575@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se>, <4EB0551D.5090309@alum.mit.edu> In-Reply-To: <4EB0551D.5090309@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 21:31:21 -0000 Hi, > Here are comments on the new version. > > From the introduction: > > This document defines a new SIP header field, Feature-Caps, that can > be used by entities to indicate support of features and capabilities, > in case they cannot use the Contact header field for that purpose. > > This is really loose!!! > Its not limited to proxies. It could be any UA that "cannot use the > Contact header field for that purpose". What constitutes a such a reason? > > The Definitions section has a very non-standard definition of Proxy: > > Proxy: Within this specification, a "proxy" refers to an entity that > does not indicate supported features using the Contact header field. > Normally, however, entities that indicate support of features do not > act as pure proxies, as defined by RFC 3261, but rather contain > different levels of B2BUAs functionality. > > IMO Proxy should be defined only as it is in 3261. As I said when I submitted the draft, and which Hadriel also indicated, we = DO need to sort out the terminology :) (I think Hadriel even had some proposed alternative wording). ------------- >Section 4.1 says: > > A UA MUST NOT, except when it acts as a SIP registrar, insert a > Feature-Caps header field in a SIP request or response. > > By this do you intend that a B2BUA/SBC cannot use this? > > Or are you drawing a fine line, where an element nominally acting as a > proxy inserts this, even if it describes a feature that will require it > starting to act as a B2BUA in the same dialog? The issue is not whether the entity is a proxy or a B2BUA, or a registrar. It's about an entity which is not "represented" by the Contact header field= , or an entity which is not allowed (by SIP rules) to use the Contact heade= r field. And, again, I totally agree that we need to use other wording than "proxy" = and "UA", to make that clear :) ------------- >In section 6.2: > > If a feature tag is inserted in a Feature-Caps header field of an > initial SIP request or response for a dialog, the feature associated > with the feature tag MUST be supported for the dialog, until the > dialog is terminated. > > Do you mean that it cannot be changed by subsequent signaling within the > dialog? If Feature-Caps can be used by a 3pcc (b2bua) controller (can > it?) then this limitation could break 3pcc transfers, where the > transfer-target has different features. The limitation seems to be a left-over from when the draft used Record-Rout= e.=20 If needed, for Feature-Caps, we can always specify that entities must inclu= de it e.g. also in target refresh requests within a session. ------------- > Section 8: > > Since this is using feature tags, it has to live with the IANA > registration mechanism defined in 2506. I think that means, at best, you > can require that certain material be included in the "Related standards > or documents" that can optionally be included in a feature tag > registration. That means it won't be possible to discern from a feature > tag registration whether it applicable for use in Feature-Caps. I don't know remember whether the references are optional or not, but at le= ast 3GPP has provided them for all feature tags. But, in general, I still think we can provide guidance and recommendations = in the spec on what kind of information needs to be provided in the definit= ion/registration. Regards, Christer On 10/28/11 6:09 AM, Christer Holmberg wrote: > > Hi, > > I've submitted a new version (-03) of draft-holmberg-sipcore-proxy-featur= e, which suggests a solution based on the proxy feature requirements. > > The MAJOR CHANGE, based on the list discussions, is that the mechanism no= w uses a new header field, Feature-Caps, rather than existing header fields= (Record-Route, Path etc). > > I did not include the "SIP-URI alternative" at this point. > > We will also have to think about the "proxy" terminology, as it has been = indicated that entities using the mechanism might not be pure proxies. But,= I don't think that should prevent us from moving forward the the mechanism= as such. > > Thanks to everyone who has provided feedback and input! > > Regards, > > Christer > From christer.holmberg@ericsson.com Tue Nov 1 14:40:11 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4381C11E807F for ; Tue, 1 Nov 2011 14:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.264 X-Spam-Level: X-Spam-Status: No, score=-6.264 tagged_above=-999 required=5 tests=[AWL=0.335, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve2mHAZxI5oG for ; Tue, 1 Nov 2011 14:40:10 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A7DDF11E8073 for ; Tue, 1 Nov 2011 14:40:09 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-54-4eb05a53e46a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F3.ED.20773.35A50BE4; Tue, 1 Nov 2011 21:45:08 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 1 Nov 2011 21:45:07 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 1 Nov 2011 21:45:06 +0100 Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) Thread-Index: AcyYu0rHTDO5rYGhSVqhnDK5Nq8k5gAGGEXe Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585223571739B@ESESSCMS0356.eemea.ericsson.se> References: <4E8C785D.5080003@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se> <6CB233EE-CBD0-4319-B46F-1483302263E0@cisco.com> , <4EAEDEDD.30202@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852235717398@ESESSCMS0356.eemea.ericsson.se>, <4EB02B97.5080008@alum.mit.edu> In-Reply-To: <4EB02B97.5080008@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Nov 2011 21:40:11 -0000 Hi, >>>> Since then it has slowly morphed into the type of DWIM vs DWIS mechani= sm that I thought we agreed we did not to do. Keep in mind any UA can >>>> act as an embedded proxy and this looks like the feature scheme that I= thought was the roughly the core of the DWIM vs DWIS argument. >>>> >>>> Anyways, for any mechanisms of this sort, I will be strongly apposed u= nless the registration mechanism for new tags, features, options or whateve= r >>>> you call them is the same as it is for sip option tags. I have spoken = at the mic several times in favor of what Christer was presenting but it a= lways had >>>> that property. This does not and I am strongly opposed to it. Given th= e previous conversation were in the other context, whatever consensus they >>>> may or may not have had does not seem to apply here. If the goal is si= mply to change what is required to register option tags, I'd be happy to ha= ve that conversation. >>> >>> Currently the draft mechanism is indicating RFC-3840-type feature-tags.= As such yes new values require RFCs published through IETF Consensus (IES= G approval), as >>> opposed to standards track RFCs as required for option-tags. I believe= as a WG-draft we can choose whether tokens put into a new header are actua= l feature-tags, >>> or some new "capability-tags" with higher RFC approval status required.= And of course we can say what semantics such new capability-tags RFCs mus= t define and be >>> constrained to. I don't think any of those things prevent us from maki= ng it a WG draft do they? I thought being a WG draft just meant the WG acc= epted the goal as a >>> milestone, had enough people willing to work on it, and thought the gen= eral direction of the draft's solution was right. >>> >>> Actually, its possible to define feature tags without any standards >>> action. See section 3.1.3 of RFC 2506. (It allows feature tags beginnin= g >>> with "u." followed by a URI.) >>> >>> Its my impression that this is one of the things that 3gpp likes about >>> feature tags - they can define new ones without an ietf standards actio= n. >> >> There are no 3GPP defined feature tags beginning with "u", and as far as= I know 3GPP has (or, is in the progress of) registered all their feature t= ags with IANA. > > OK, my mistake. > > There is also a global tree (tags starting with g.) for which new values > can be registered by expert review, without publication of an RFC. And > 3gpp has registered several of these. Correct. I believe all 3GPP feature tags use the g.3gpp tree. >> And, as you also indicated, we can specify what information a feature ta= g specification, and its associated IANA registration, needs to contain. > > If we use feature tags, unless we require use of the "sip" tree, or > define a new tree, I don't think we can specify what the specification > includes, since the registration is defined by RFC 2506. What is it then that is missing today? For example, alll the currently IANA= registered g.3gpp feature tags DO contain a specification reference. >> Also, if you look at the use-cases behind this work, I think feature tag= s are very appropriate. We are talking about feature >> indications ("I can do this"). And, we are not talking about extensions = to the SIP protocol, in which case I agree option-tags probably would be mo= re suitable. > > Frankly, IMO the adoption of feature tags for 3840 was a mistake, > because the semantics of feature tags for callee caps / callerprefs > largely disjoint from the intended original use of feature tags. > > If the intent is to require a specification with particular properties, > then we can do this better by defining a new namespace. Again, the registered g.3gpp feature tags contain specification references. Regards, Christer From pkyzivat@alum.mit.edu Wed Nov 2 08:16:03 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08DA91F0C9F for ; Wed, 2 Nov 2011 08:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.394 X-Spam-Level: X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vb6wGwFBHo4R for ; Wed, 2 Nov 2011 08:16:02 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF711F0C95 for ; Wed, 2 Nov 2011 08:16:01 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta06.westchester.pa.mail.comcast.net with comcast id sFCd1h00C17dt5G56FG2DZ; Wed, 02 Nov 2011 15:16:02 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta13.westchester.pa.mail.comcast.net with comcast id sFG11h0130tdiYw3ZFG2Ge; Wed, 02 Nov 2011 15:16:02 +0000 Message-ID: <4EB15EB0.2050901@alum.mit.edu> Date: Wed, 02 Nov 2011 11:16:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341F491F@ESESSCMS0356.eemea.ericsson.se>, <4E9EF814.4070908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B7F8@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se>, <4EB0551D.5090309@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223571739D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585223571739D@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 02 Nov 2011 15:16:03 -0000 On 11/1/11 5:31 PM, Christer Holmberg wrote: > > Hi, > >> Here are comments on the new version. >> >> From the introduction: >> >> This document defines a new SIP header field, Feature-Caps, that can >> be used by entities to indicate support of features and capabilities, >> in case they cannot use the Contact header field for that purpose. >> >> This is really loose!!! >> Its not limited to proxies. It could be any UA that "cannot use the >> Contact header field for that purpose". What constitutes a such a reason? >> >> The Definitions section has a very non-standard definition of Proxy: >> >> Proxy: Within this specification, a "proxy" refers to an entity that >> does not indicate supported features using the Contact header field. >> Normally, however, entities that indicate support of features do not >> act as pure proxies, as defined by RFC 3261, but rather contain >> different levels of B2BUAs functionality. >> >> IMO Proxy should be defined only as it is in 3261. > > As I said when I submitted the draft, and which Hadriel also indicated, we DO need to sort out the terminology :) Consider these comments to be input to the terminology restructuring. Its something that we need to get right, because it goes to the heart of what this is about. > (I think Hadriel even had some proposed alternative wording). >> Section 4.1 says: >> >> A UA MUST NOT, except when it acts as a SIP registrar, insert a >> Feature-Caps header field in a SIP request or response. >> >> By this do you intend that a B2BUA/SBC cannot use this? >> >> Or are you drawing a fine line, where an element nominally acting as a >> proxy inserts this, even if it describes a feature that will require it >> starting to act as a B2BUA in the same dialog? > > The issue is not whether the entity is a proxy or a B2BUA, or a registrar. > > It's about an entity which is not "represented" by the Contact header field, or an entity which is not allowed (by SIP rules) to use the Contact header field. I like your characterization of the difference here better than what I have seen before. > And, again, I totally agree that we need to use other wording than "proxy" and "UA", to make that clear :) See my earlier comment. >> In section 6.2: >> >> If a feature tag is inserted in a Feature-Caps header field of an >> initial SIP request or response for a dialog, the feature associated >> with the feature tag MUST be supported for the dialog, until the >> dialog is terminated. >> >> Do you mean that it cannot be changed by subsequent signaling within the >> dialog? If Feature-Caps can be used by a 3pcc (b2bua) controller (can >> it?) then this limitation could break 3pcc transfers, where the >> transfer-target has different features. > > The limitation seems to be a left-over from when the draft used Record-Route. > > If needed, for Feature-Caps, we can always specify that entities must include it e.g. also in target refresh requests within a session. I think that is needed. >> Section 8: >> >> Since this is using feature tags, it has to live with the IANA >> registration mechanism defined in 2506. I think that means, at best, you >> can require that certain material be included in the "Related standards >> or documents" that can optionally be included in a feature tag >> registration. That means it won't be possible to discern from a feature >> tag registration whether it applicable for use in Feature-Caps. > > I don't know remember whether the references are optional or not, but at least 3GPP has provided them for all feature tags. I checked - they are optional. > But, in general, I still think we can provide guidance and recommendations in the spec on what kind of information needs to be provided in the definition/registration. I guess you can say that a feature-tag can only be used in this way if the registration of the tag references a document that has some specific content. That would rule out all the existing ones, until their registration is updated. Thanks, Paul > Regards, > > Christer > > > > > > > On 10/28/11 6:09 AM, Christer Holmberg wrote: >> >> Hi, >> >> I've submitted a new version (-03) of draft-holmberg-sipcore-proxy-feature, which suggests a solution based on the proxy feature requirements. >> >> The MAJOR CHANGE, based on the list discussions, is that the mechanism now uses a new header field, Feature-Caps, rather than existing header fields (Record-Route, Path etc). >> >> I did not include the "SIP-URI alternative" at this point. >> >> We will also have to think about the "proxy" terminology, as it has been indicated that entities using the mechanism might not be pure proxies. But, I don't think that should prevent us from moving forward the the mechanism as such. >> >> Thanks to everyone who has provided feedback and input! >> >> Regards, >> >> Christer >> > > From pkyzivat@alum.mit.edu Wed Nov 2 08:29:37 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AEE21F8997 for ; Wed, 2 Nov 2011 08:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 7xxkIfTqGw9D for ; Wed, 2 Nov 2011 08:29:36 -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 695B721F8876 for ; Wed, 2 Nov 2011 08:29:35 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta14.westchester.pa.mail.comcast.net with comcast id sEF51h0071c6gX85EFVcrF; Wed, 02 Nov 2011 15:29:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id sFVb1h01L0tdiYw3jFVcoA; Wed, 02 Nov 2011 15:29:36 +0000 Message-ID: <4EB161DD.6010307@alum.mit.edu> Date: Wed, 02 Nov 2011 11:29:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4E8C785D.5080003@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se> <6CB233EE-CBD0-4319-B46F-1483302263E0@cisco.com> , <4EAEDEDD.30202@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852235717398@ESESSCMS0356.eemea.ericsson.se>, <4EB02B97.5080008@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223571739B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585223571739B@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 02 Nov 2011 15:29:37 -0000 [trimming] On 11/1/11 4:45 PM, Christer Holmberg wrote: >>> And, as you also indicated, we can specify what information a feature tag specification, and its associated IANA registration, needs to contain. >> >> If we use feature tags, unless we require use of the "sip" tree, or >> define a new tree, I don't think we can specify what the specification >> includes, since the registration is defined by RFC 2506. > > What is it then that is missing today? For example, alll the currently IANA registered g.3gpp feature tags DO contain a specification reference. We can't easily (without ammending 2506) change what is required to register a feature tag. The document references are optional, and there is no required content for referenced documents. I think its probably possible to craft the normative requirements for a new usage of feature-tags (i.e. in Feature-Caps) to restrict usage to feature tags that have a referenced document with some specific content. What that wouldn't do is normatively prohibit the use of those new feature tags in other places, such as called out in 3840/3841. To do that we would have to revise 3840/3841. Thanks, Paul From christer.holmberg@ericsson.com Wed Nov 2 13:00:34 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB4B1F0CAC for ; Wed, 2 Nov 2011 13:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.278 X-Spam-Level: X-Spam-Status: No, score=-6.278 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwWFurjzG4fB for ; Wed, 2 Nov 2011 13:00:33 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9113B1F0C56 for ; Wed, 2 Nov 2011 13:00:33 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-88-4eb1a15a4862 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3C.48.20773.A51A1BE4; Wed, 2 Nov 2011 21:00:26 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 2 Nov 2011 21:00:26 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 2 Nov 2011 21:00:25 +0100 Thread-Topic: Feature-Caps - feature tag registration [was: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field)] Thread-Index: AQHMmZkcV5x+AK+iC0mdr5wLcvEkdA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522357173A1@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: [sipcore] Feature-Caps - feature tag registration [was: Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field)] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 02 Nov 2011 20:00:34 -0000 Hi, (Moved first part from the terminology thread) >>> Section 8: >>> >>> Since this is using feature tags, it has to live with the IANA >>> registration mechanism defined in 2506. I think that means, at best, yo= u >>> can require that certain material be included in the "Related standards >>> or documents" that can optionally be included in a feature tag >>> registration. That means it won't be possible to discern from a feature >>> tag registration whether it applicable for use in Feature-Caps. >> >> I don't know remember whether the references are optional or not, but at= least 3GPP has provided them for all feature tags. > > I checked - they are optional. > >> But, in general, I still think we can provide guidance and recommendatio= ns in the spec on what kind of information needs to be provided in the defi= nition/registration. > > I guess you can say that a feature-tag can only be used in this way if > the registration of the tag references a document that has some specific > content. That would rule out all the existing ones, until their > registration is updated. > >>>> And, as you also indicated, we can specify what information a feature = tag specification, and its associated IANA registration, needs to contain. >>> >>> If we use feature tags, unless we require use of the "sip" tree, or >>> define a new tree, I don't think we can specify what the specification >>> includes, since the registration is defined by RFC 2506. >> >> What is it then that is missing today? For example, alll the currently I= ANA registered g.3gpp feature tags DO contain a specification reference. > > We can't easily (without ammending 2506) change what is required to > register a feature tag. The document references are optional, and there > is no required content for referenced documents. > > I think its probably possible to craft the normative requirements for a > new usage of feature-tags (i.e. in Feature-Caps) to restrict usage to > feature tags that have a referenced document with some specific content. > > What that wouldn't do is normatively prohibit the use of those new > feature tags in other places, such as called out in 3840/3841. To do > that we would have to revise 3840/3841. I am sure we will be able to sort those things out. Regards, Christer= From christer.holmberg@ericsson.com Wed Nov 2 13:00:43 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E9811E8179 for ; Wed, 2 Nov 2011 13:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.283 X-Spam-Level: X-Spam-Status: No, score=-6.283 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdS1+LVHc6wV for ; Wed, 2 Nov 2011 13:00:42 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 52B3C11E8178 for ; Wed, 2 Nov 2011 13:00:42 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-3f-4eb1a165fef5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 45.00.13753.561A1BE4; Wed, 2 Nov 2011 21:00:37 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 2 Nov 2011 21:00:37 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 2 Nov 2011 21:00:36 +0100 Thread-Topic: Feature-Caps - Terminology [was: Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field)] Thread-Index: AQHMmZdcQYx9iM69S0ia7qNL9RWaFw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522357173A0@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "" Subject: [sipcore] Feature-Caps - Terminology [was: Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field)] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 02 Nov 2011 20:00:43 -0000 Hi, >>> Here are comments on the new version. >>> >>> From the introduction: >>> >>> This document defines a new SIP header field, Feature-Caps, that ca= n >>> be used by entities to indicate support of features and capabilities= , >>> in case they cannot use the Contact header field for that purpose. >>> >>> This is really loose!!! >>> Its not limited to proxies. It could be any UA that "cannot use the >>> Contact header field for that purpose". What constitutes a such a reaso= n? >>> >>> The Definitions section has a very non-standard definition of Proxy: >>> >>> Proxy: Within this specification, a "proxy" refers to an entity tha= t >>> does not indicate supported features using the Contact header field. >>> Normally, however, entities that indicate support of features do no= t >>> act as pure proxies, as defined by RFC 3261, but rather contain >>> different levels of B2BUAs functionality. >>> >>> IMO Proxy should be defined only as it is in 3261. >> >> As I said when I submitted the draft, and which Hadriel also indicated, = we DO need to sort out the terminology :) > > Consider these comments to be input to the terminology restructuring. > Its something that we need to get right, because it goes to the heart of > what this is about. I agree. The intention was not to keep the currently proposed terminology, but in or= der to be able to submit the draft start with something "familiar", and the= n work from there. ---------- >>> Section 4.1 says: >>> >>> A UA MUST NOT, except when it acts as a SIP registrar, insert a >>> Feature-Caps header field in a SIP request or response. >>> >>> By this do you intend that a B2BUA/SBC cannot use this? >>> >>> Or are you drawing a fine line, where an element nominally acting as a >>> proxy inserts this, even if it describes a feature that will require it >>> starting to act as a B2BUA in the same dialog? >> >> The issue is not whether the entity is a proxy or a B2BUA, or a registra= r. >> >> It's about an entity which is not "represented" by the Contact header fi= eld, or an entity which is not allowed (by SIP rules) to use the Contact he= ader field. > > I like your characterization of the difference here better than what I ha= ve seen before. And, in addition to the definition of the entity, we of course also need to= decided what to call it :) ---------- >>> In section 6.2: >>> >>> If a feature tag is inserted in a Feature-Caps header field of an >>> initial SIP request or response for a dialog, the feature associate= d >>> with the feature tag MUST be supported for the dialog, until the >>> dialog is terminated. >>> >>> Do you mean that it cannot be changed by subsequent signaling within th= e >>> dialog? If Feature-Caps can be used by a 3pcc (b2bua) controller (can >>> it?) then this limitation could break 3pcc transfers, where the >>> transfer-target has different features. >> >> The limitation seems to be a left-over from when the draft used Record-R= oute. >> >> If needed, for Feature-Caps, we can always specify that entities must in= clude it e.g. also in target refresh requests within a session. > > I think that is needed. I'll note that down. ---------- >>> Section 8: >>> >>> Since this is using feature tags, it has to live with the IANA >>> registration mechanism defined in 2506. I think that means, at best, yo= u >>> can require that certain material be included in the "Related standards >>> or documents" that can optionally be included in a feature tag >>> registration. That means it won't be possible to discern from a feature >>> tag registration whether it applicable for use in Feature-Caps. >> >> I don't know remember whether the references are optional or not, but at= least 3GPP has provided them for all feature tags. > > I checked - they are optional. > >> But, in general, I still think we can provide guidance and recommendatio= ns in the spec on what kind of information needs to be provided in the defi= nition/registration. > > I guess you can say that a feature-tag can only be used in this way if > the registration of the tag references a document that has some specific > content. That would rule out all the existing ones, until their > registration is updated. I'll move this to the other thread, as it's not related to the entity termi= nology. Regards, Christer Thanks, Paul > Regards, > > Christer > > > > > > > On 10/28/11 6:09 AM, Christer Holmberg wrote: >> >> Hi, >> >> I've submitted a new version (-03) of draft-holmberg-sipcore-proxy-featu= re, which suggests a solution based on the proxy feature requirements. >> >> The MAJOR CHANGE, based on the list discussions, is that the mechanism n= ow uses a new header field, Feature-Caps, rather than existing header field= s (Record-Route, Path etc). >> >> I did not include the "SIP-URI alternative" at this point. >> >> We will also have to think about the "proxy" terminology, as it has been= indicated that entities using the mechanism might not be pure proxies. But= , I don't think that should prevent us from moving forward the the mechanis= m as such. >> >> Thanks to everyone who has provided feedback and input! >> >> Regards, >> >> Christer >> > > From adam@nostrum.com Wed Nov 2 14:18:37 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220E211E8152 for ; Wed, 2 Nov 2011 14:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9EwyUegTyYa for ; Wed, 2 Nov 2011 14:18:36 -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 A706511E80FD for ; Wed, 2 Nov 2011 14:18:36 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id pA2LIZ5x014210 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 2 Nov 2011 16:18:36 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4EB1B3AB.6040105@nostrum.com> Date: Wed, 02 Nov 2011 16:18:35 -0500 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] IETF 82 SIPCORE Agenda X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 21:18:37 -0000 [as chair] I have posted a preliminary version of the SIPCORE agenda for the face-to-face meeting we will have in Taipei later this month. Presently, it looks like we will have a very short meeting to discuss the proxy features requirements document. http://www.ietf.org/proceedings/82/agenda/sipcore.html If you wish to make requests for additions to the agenda, please send an email to the chairs no later than THIS FRIDAY, November 4th. Thank you. /a From christer.holmberg@ericsson.com Thu Nov 3 05:50:24 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D560311E80AC for ; Thu, 3 Nov 2011 05:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.3 X-Spam-Level: X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7izgEF1dNpt2 for ; Thu, 3 Nov 2011 05:50:24 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 263CF11E80D2 for ; Thu, 3 Nov 2011 05:50:23 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-bf-4eb28e0e4510 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EC.47.13753.E0E82BE4; Thu, 3 Nov 2011 13:50:22 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 3 Nov 2011 13:50:21 +0100 From: Christer Holmberg To: "" Date: Thu, 3 Nov 2011 13:50:20 +0100 Thread-Topic: Feature-Caps - Terminology Thread-Index: AQHMmZdcQYx9iM69S0ia7qNL9RWaF5WbDHUg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852235962759@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A058522357173A0@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522357173A0@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Feature-Caps - Terminology X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 03 Nov 2011 12:50:25 -0000 Hi, Based on the terminology comments, I suggest some modified/new text for Sec= tion 1 and Section 3 (still working on section 4). "1. Introduction The Session Initiation Protocol (SIP) "Caller Preferences" extension, defined in RFC 3840 [RFC3840], provides a mechanism that allows a SIP message to convey information relating to the originator's features and capabilities, using the Contact header field. =09 This document defines a new SIP header field, Feature-Caps, that can be used by SIP entities to indicate support of features and capabilities= , in cases where the Contact header field contains a URI that does not=20 represent the SIP entity that wants to indicate support of its features = and=20 capabilities. Such cases are: - The SIP entity acts as a SIP proxy. - The SIP entity acts as a SIP registrar. - The SIP entity acts as a B2BUA, where the Contact header field URI=20 represents another SIP entity." =20 Section 3: ---------- The proxy definition text is removed. Regards, Christer From christer.holmberg@ericsson.com Thu Nov 3 06:08:11 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831BB11E811F for ; Thu, 3 Nov 2011 06:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.306 X-Spam-Level: X-Spam-Status: No, score=-6.306 tagged_above=-999 required=5 tests=[AWL=0.292, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-KPuMFn+jTQ for ; Thu, 3 Nov 2011 06:08:11 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 8426711E8110 for ; Thu, 3 Nov 2011 06:08:10 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-7d-4eb292399a9c Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5A.AA.13753.93292BE4; Thu, 3 Nov 2011 14:08:09 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 3 Nov 2011 14:08:08 +0100 From: Christer Holmberg To: "" Date: Thu, 3 Nov 2011 14:08:07 +0100 Thread-Topic: Feature-Caps: Feature indications in 18x and 200 Thread-Index: AcyaKaDr9sNrpIJ9RlKSWi2LDONmIg== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852235962788@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_7F2072F1E0DE894DA4B517B93C6A05852235962788ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Feature-Caps: Feature indications in 18x and 200 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 03 Nov 2011 13:08:11 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852235962788ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The Feature-Caps draft currently allows sending of feature indications in r= eliable 18x and 200 responses. I've received an off-line question, asking whether the indicated features m= ust be identical, if included both in 18x and 200 for the same request. My suggestion would be that we take the same approach that we did for Info = Packages. Section 5.2.3 of RFC 6086 says: "As with SDP answers, the receiver can include the same Rec= v-Info header field value in multiple responses (18x/2xx) for the = same INVITE/re-INVITE transaction, but the receiver MUST use the= same Recv-Info header field value (if included) in all responses= for the same transaction." ...so, for Feature-Caps it could say something like: "An entity can include the same Feature-Caps header field value in multiple responses (18x/2xx) for the = same INVITE/re-INVITE transaction, but the entity MUST use the s= ame Feature-Caps header field value (if included) in all respon= ses for the same transaction." Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A05852235962788ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
The Feature-Caps draft currently allows sending of fe= ature indications in reliable 18x and 200 responses.
 
I've received an off-line question, asking whether th= e indicated features must be identical, if included both in 18x and 200 for= the same request.
 
My suggestion would be that we take the same approach= that we did for Info Packages.
 
Section 5.2.3 of RFC 6086 says:
 
         = ;       "As with SDP answers, the receiv= er can include the same Recv-Info
         = ;        header field value in multiple = responses (18x/2xx) for the same
         = ;        INVITE/re-INVITE transaction, b= ut the receiver MUST use the same
         = ;        Recv-Info header field value (i= f included) in all responses for the
         = ;        same transaction."<= /div>
 
...so, for Feature-Caps it could say something like:<= /font>
 
         = ;       "An entity can include the same = Feature-Caps
         = ;        header field value in multiple = responses (18x/2xx) for the same
         = ;        INVITE/re-INVITE transaction, b= ut the entity MUST use the same
         = ;        Feature-Caps header field value= (if included) in all responses for the
         = ;        same transaction."<= /div>
 
Regards,
 
Christer
 
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05852235962788ESESSCMS0356e_-- From pkyzivat@alum.mit.edu Thu Nov 3 08:14:58 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B5E1F0C96 for ; Thu, 3 Nov 2011 08:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6AlY+jhaR4V for ; Thu, 3 Nov 2011 08:14:58 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0465D1F0C34 for ; Thu, 3 Nov 2011 08:14:57 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta10.westchester.pa.mail.comcast.net with comcast id sfCD1h0060cZkys5AfEwgk; Thu, 03 Nov 2011 15:14:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta10.westchester.pa.mail.comcast.net with comcast id sfEv1h02i0tdiYw3WfEwgw; Thu, 03 Nov 2011 15:14:56 +0000 Message-ID: <4EB2AFEE.9050006@alum.mit.edu> Date: Thu, 03 Nov 2011 11:14:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4EAEE023.6010600@alum.mit.edu> <4EAEFC94.3050207@alum.mit.edu> <4EB0060A.5020106@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 03 Nov 2011 15:14:59 -0000 Trimming On 11/1/11 1:21 PM, Iñaki Baz Castillo wrote: >>> Ok. IMHO "sips" is just impossible to work since a proxy adding a >>> "sips" schema must use a domain in the Record-Route, and such domain >>> could resolve to multiple NAPTR/SRV/A/AAAA records, so we loose the >>> pach for in-dialog requests and that's critical when Outbound is being >>> used. However this is another history out of the scope here. >> >> Reports on problems trying to implement sips are welcome. > > Yes, sorry, let's discuss about it in a new future thread. Sounds good. >>> Let's assume that: >>> >>> - A SIP Websocket client is a real client (not a proxy or server). >>> - The spec will require Outbound so ;received and ;rport is 100% >>> useless (even more when the server cannot try the IP in >>> ;received/;rport for sending a response in case the connection is >>> closed since a WebSocket client does not listen for incoming >>> connections). >> >> I think you are saying that those are useless with outbound in general, so >> the remedy you are suggesting could be abstracted to all uses of outbound. >> Is that right? > > Well, in case of SIP over UDP/TCP/TLS usage of ;received param is > indeed useless. But in case of SIP over WebSocket is not just useless > but also dangerous as it reveals to the WS client the IP of a possible > TCP/HTTP load-balancer before the WebSocket SIP server. Such internal > IP is hidden for the WS client during the WebSocket handshake (an HTTP > GET request + 101 response). I'll respond below. >>> So IMHO it's clear that ;received is useless in SIP over WebSocket, >>> and it can reveal server internal infrastructure to the client. So, >>> what can we do here? IMHO the SIP WebSocket server/proxy should be >>> able not to set the ;received param given the above rationale. >> >> Why is this internal structure more important to hide in the websocket case >> than in other cases? Is this just for the paranoid? > > I'm not involved in HTTP scenarios but I got some interesting replies > about this subject in Hyby WG (WebSocket WG): > > http://www.ietf.org/mail-archive/web/hybi/current/msg09091.html > > Some text in that thread: > ------------------------------ > Yes, the problem comes from the fact that a protocol that is used across > a number of intermediaries would suddenly transport sensible information. > Internal IP addresses *are* sensible information to a number of companies. > Whether this makes sense or not is not our problem, these companies don't > want their internal networks to be unveiled to outers and they have their > reasons for this. Now if your usual WS server emits its address in every > response and the reverse-proxy that is placed in front of it does not > change it, all of your clients will get this information they don't need. > >> BTW it would be really great a simple "Connection-Source" header in >> the HTTP 101 response during the WS handshake. Examples: >> >> Connetion-Source: 34.67.123.94:26745 >> >> Connection-Source: [20a:12::3dde:190:ed5]:19443 > > Same problem, you'll divulgate the IP:port of the reverse-proxy to clients > and the number of reverse-proxies. It can even be used by attackers to > detect that they managed to crash one of them because after a specific > request, they use another one. > > An HTTP chain very commonly involves these components : > > [client]----[proxy]-------//// net ////-------[rproxy]------[server] > > The proxy commonly is on the client's network in enterprises, or at > the ISP's for home or mobile users. The "net" may involve a number of > transparent intermediaries, but that's not that much common though. > The reverse proxy (rproxy) generally is on the server side. It's in > fact common to see a long chain of many of them. 3-5 are not uncommon > these days, though some of them may be transparent. I have not even > represented NAT devices such as firewalls or some L4 load balancers > which often don't rewrite the source IP but change the source port. This above seems to describe exactly the same issues that I hear advanced as reasons for topology hiding in SIP. Hadriel - can you confirm that? >> One of the justifications for SBCs is so that they can do "topology hiding". >> Are you just asking for a special case of this? > > Well, IMHO "topolgy hiding" means that the SBC hides leg-A details into leg-B. > What I'm suggesting is that the server (the SIP WebSocket server) > should not reveal to the client sensible information about internal IP > addresses of the provider TCP/HTTP load-balancers located in server > side. IMHO the thread above (the link) justifies that with good > rationale. I don't think its leg-A vs. leg-B. Rather its potentially anywhere there is an administrative boundary where one side doesn't trust the other side. > However I don't think that omitting the ;received stuff in the SIP > WebSocket server is something critical. As said before, ;received is > useless in SIP over WebSocket: it's a connection oriented protocol so > responses are sent using the same connection, and in case such > connection is closed responses cannot be sent to the WS client since > the WS client does not liste for incoming connections. The same occurs > with SIP TCP natted clients, but in this last case revealing the > ;received IP is not a risk. IMO this isn't something that it makes sense to deal with piecemeal. If a case can be made that this sort of privacy is important enough to introduce architectural changes in protocols, then we should be talking about that in general. (But I suspect this will continue to be politically incorrect.) Thanks, Paul From ibc@aliax.net Thu Nov 3 08:30:26 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98301F0C96 for ; Thu, 3 Nov 2011 08:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMITYI1N2-+m for ; Thu, 3 Nov 2011 08:30:26 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2515A1F0C72 for ; Thu, 3 Nov 2011 08:30:26 -0700 (PDT) Received: by vcbfl11 with SMTP id fl11so1426894vcb.31 for ; Thu, 03 Nov 2011 08:30:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.100.70 with SMTP id ew6mr10121334vdb.49.1320334225566; Thu, 03 Nov 2011 08:30:25 -0700 (PDT) Received: by 10.220.107.206 with HTTP; Thu, 3 Nov 2011 08:30:25 -0700 (PDT) In-Reply-To: <4EB2AFEE.9050006@alum.mit.edu> References: <4EAEE023.6010600@alum.mit.edu> <4EAEFC94.3050207@alum.mit.edu> <4EB0060A.5020106@alum.mit.edu> <4EB2AFEE.9050006@alum.mit.edu> Date: Thu, 3 Nov 2011 16:30:25 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 03 Nov 2011 15:30:26 -0000 2011/11/3 Paul Kyzivat : >> However I don't think that omitting the ;received stuff in the SIP >> WebSocket server is something critical. As said before, ;received is >> useless in SIP over WebSocket: it's a connection oriented protocol so >> responses are sent using the same connection, and in case such >> connection is closed responses cannot be sent to the WS client since >> the WS client does not liste for incoming connections. The same occurs >> with SIP TCP natted clients, but in this last case revealing the >> ;received IP is not a risk. > > IMO this isn't something that it makes sense to deal with piecemeal. > If a case can be made that this sort of privacy is important enough to > introduce architectural changes in protocols, then we should be talking > about that in general. Hi Paul. I see a bit difference here: In SIP we all assume that an element in the path of a SIP communication is a IP layer box (a router) or a SIP box (a SIP proxy/B2BUA/SBC). Let's forget NAT routers for now. But in HTTP world is very common to have TCP/HTTP load balancers in the path (while in SIP we use SIP proxies for balancing). Those elements alter the received IP:port in the HTTP server but nobody cares since such information is never told to the HTTP client. This is not true in SIP since Via ;received / ;rport are supposed to reveal to the client the source IP:port from which the server has received the request. In the case of WebSocket, the WS connection is made using an HTTP GET replied with an HTTP 101. And then we have a TCP connection in which both the WS client and WS server can send data by encapsulating it over WebSocket frames. Since we are defining here WebSocket as a transport for SIP, IMHO it should not matter the TCP/HTTP load balancers in the path. Those are in a layer below the WebSocket communication. The link I pasted in my previous mail clearly shows how the received IP:port can be totally useless for a WebSocket server. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From aallen@rim.com Thu Nov 3 11:20:59 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B60C1F0C40 for ; Thu, 3 Nov 2011 11:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.319 X-Spam-Level: X-Spam-Status: No, score=-5.319 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 n5n4rGXX8+TK for ; Thu, 3 Nov 2011 11:20:53 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id E955A1F0CA3 for ; Thu, 3 Nov 2011 11:20:52 -0700 (PDT) X-AuditID: 0a412830-b7b29ae000000f33-2b-4eb2db8360d3 Received: from XHT107CNC.rim.net (xht107cnc.rim.net [10.65.12.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 7B.33.03891.38BD2BE4; Thu, 3 Nov 2011 18:20:52 +0000 (GMT) Received: from XCT104ADS.rim.net (10.67.111.45) by XHT107CNC.rim.net (10.65.12.217) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 3 Nov 2011 14:20:52 -0400 Received: from XMB105ADS.rim.net ([fe80::c47b:e609:558:1b44]) by XCT104ADS.rim.net ([fe80::90f9:3b89:1d94:aa9b%22]) with mapi id 14.01.0289.001; Thu, 3 Nov 2011 13:20:50 -0500 From: Andrew Allen To: Christer Holmberg , "" Thread-Topic: Feature-Caps: Feature indications in 18x and 200 Thread-Index: AcyaKaDr9sNrpIJ9RlKSWi2LDONmIgAK6xkQ Date: Thu, 3 Nov 2011 18:20:50 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852235962788@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852235962788@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.254] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD23067A5BXMB105ADSrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNKsWRmVeSWpSXmKPExsXC5chzU7fl9iY/g9MHGS0uzDzMaPH1xyY2 ByaPX1+vsnksWfKTKYApqoHRJjEvL78ksSRVISW1ONlWySc1PTFHIaAosywxuVLBJbM4OScx Mze1SEkhM8VWyURJoSAnMTk1NzWvxFYpsaAgNS9FyY5LAQPYAJVl5imk5iXnp2TmpdsqeQb7 61pYmFrqGirZ6SKBhH/cGdOX97MVnGhmrHjZt5algfFVeRcjJ4eEgInEz5fXmCBsMYkL99az dTFycQgJ9DJJTPm0mRHCWcoo8fniNmYIZzOjxJW/D8Fa2ASUJZb/nsEIYosIJEos2/SLHcQW FrCVOPfxKBtE3E7i8qKZLBC2kcTiey/B6lkEVCSe3JwENIeDg1fATWLDxxSQsJBAuMSsXW1g 5ZwCERKb/h5kBbEZga77fmoN2FpmAXGJW0/mQ10tILFkz3lmCFtU4uXjf6wgIyUEFCVen66D KM+VmLj1I9g1vAKCEidnPmGBWCUtsePkGsYJjGKzkEydhaRlFpIWiLiOxILdn9ggbG2JZQtf M8PYZw48ZkIWX8DIvopRMDej2MDMMDkvWa8oM1cvL7VkEyM44WgY7GCcsFfrEKMAB6MSD2/e jU1+QqyJZcWVuYcYJTiYlUR43U8AhXhTEiurUovy44tKc1KLDzG6AsNtIrMUd3I+MBnmlcQb Gxjg5iiJ88pcyvATEkgHJr3s1NSC1CKYOUwcnFINjEwP7zRb6Ibp2U7e0WYd8qq+5brO36Qy JSGPB3t176e6SBnObwlbcTrtputU/dYQGXOm2q4/p7//eLXA+4TthascCxjnLX3SY5bywDC9 a+HyfVFl+ubyMybaad0wW1PweFblv2jtgsjHN3bXpr865prdssl20U7T1EiFtcsNP/h+bq9Y UrvRTYmlOCPRUIu5qDgRADWsW0VeAwAA Subject: Re: [sipcore] Feature-Caps: Feature indications in 18x and 200 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 03 Nov 2011 18:20:59 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD23067A5BXMB105ADSrimnet_ Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable Agree From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf O= f Christer Holmberg Sent: Thursday, November 03, 2011 8:08 AM To: Subject: [sipcore] Feature-Caps: Feature indications in 18x and 200 Hi, The Feature-Caps draft currently allows sending of feature indications in re= liable 18x and 200 responses. I've received an off-line question, asking whether the indicated features mu= st be identical, if included both in 18x and 200 for the same request. My suggestion would be that we take the same approach that we did for Info P= ackages. Section 5.2.3 of RFC 6086 says: "As with SDP answers, the receiver can include the same Recv= -Info header field value in multiple responses (18x/2xx) for the= same INVITE/re-INVITE transaction, but the receiver MUST use the= same Recv-Info header field value (if included) in all responses= for the same transaction." ...so, for Feature-Caps it could say something like: "An entity can include the same Feature-Caps header field value in multiple responses (18x/2xx) for the= same INVITE/re-INVITE transaction, but the entity MUST use the s= ame Feature-Caps header field value (if included) in all respon= ses for the same transaction." Regards, Christer --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD23067A5BXMB105ADSrimnet_ Content-Type: text/html; charset="us-ascii" content-transfer-encoding: quoted-printable

Agree

 

From: sipcore-bou= nces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Thursday, November 03, 2011 8:08 AM
To: <sipcore@ietf.org>
Subject: [sipcore] Feature-Caps: Feature indications in 18x and 200

 

 

Hi,

 

The Feature-Caps draft currently allows sen= ding of feature indications in reliable 18x and 200 responses.

 

I've received an off-line question, asking= whether the indicated features must be identical, if included both in 18x a= nd 200 for the same request.

 

My suggestion would be that we take the sam= e approach that we did for Info Packages.

 

Section 5.2.3 of RFC 6086 says:<= /span>

 

       &= nbsp;        "As with SDP answers, t= he receiver can include the same Recv-Info

       &= nbsp;         header field value in= multiple responses (18x/2xx) for the same

       &= nbsp;         INVITE/re-INVITE trans= action, but the receiver MUST use the same

       &= nbsp;         Recv-Info header field= value (if included) in all responses for the

       &= nbsp;         same transaction."= ;

 

...so, for Feature-Caps it could say someth= ing like:

 

       &= nbsp;        "An entity can include= the same Feature-Caps

       &= nbsp;         header field value in= multiple responses (18x/2xx) for the same

       &= nbsp;         INVITE/re-INVITE trans= action, but the entity MUST use the same

       &= nbsp;         Feature-Caps header fi= eld value (if included) in all responses for the

       &= nbsp;         same transaction."= ;

 

Regards,

 

Christer

 

 

 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. --_000_BBF5DDFE515C3946BC18D733B20DAD23067A5BXMB105ADSrimnet_-- From christer.holmberg@ericsson.com Fri Nov 4 06:12:51 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3372321F8C12 for ; Fri, 4 Nov 2011 06:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.308 X-Spam-Level: X-Spam-Status: No, score=-6.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2mVN5YALtvZ for ; Fri, 4 Nov 2011 06:12:50 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 5F33221F8BDC for ; Fri, 4 Nov 2011 06:12:50 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-61-4eb3e4d1c74a Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 33.91.13753.1D4E3BE4; Fri, 4 Nov 2011 14:12:49 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 4 Nov 2011 14:12:49 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Date: Fri, 4 Nov 2011 14:12:48 +0100 Thread-Topic: Feature-Caps: Feature indication in target refresh request Thread-Index: AQHMmvNsFpgV19D5R028+3xjTusUUA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522357173B5@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Feature-Caps: Feature indication in target refresh request X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 04 Nov 2011 13:12:51 -0000 Hi, It has been indicated that it would be useful tobe able to re-indicate supp= orted features within a dialog, as part of a target refresh request. Based on that, I suggest the following modified section 6.2 text: "6.2. SIP Dialog The Feature-Caps header field can be used within an initial SIP request for a dialog, within a target refresh SIP request, and within=20 any 18x or 2xx response associated with such requests. If a feature=20 tag is inserted in a Feature-Caps header field of such request or such=20 response, the feature associated with the feature tag MUST be=20 supported for the dialog, until the next time the dialog target is refreshed, or the dialog is terminated." Regards, Christer= From christer.holmberg@ericsson.com Sat Nov 5 16:49:56 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE6621F8531 for ; Sat, 5 Nov 2011 16:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.313 X-Spam-Level: X-Spam-Status: No, score=-6.313 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YA1G2UjX+kc for ; Sat, 5 Nov 2011 16:49:56 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 047D221F84AE for ; Sat, 5 Nov 2011 16:49:55 -0700 (PDT) X-AuditID: c1b4fb3d-b7c26ae0000035b9-f1-4eb5cba05303 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 22.C6.13753.0ABC5BE4; Sun, 6 Nov 2011 00:49:52 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Sun, 6 Nov 2011 00:49:52 +0100 From: Christer Holmberg To: "" Date: Sun, 6 Nov 2011 00:49:51 +0100 Thread-Topic: Feature-Caps: Feature indications in 18x and 200 Thread-Index: AcyaKaDr9sNrpIJ9RlKSWi2LDONmIgAK6xkQAFc9hCA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522357173BF@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235962788@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Feature-Caps: Feature indications in 18x and 200 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 05 Nov 2011 23:49:56 -0000 Hi, =20 I received a comment that it would be good to clarify that the header field= value must be identical in 18x/2xx responses belonging to the same dialog. =20 In addition, I received a request to say that, if the header field is sent = in a 18x, it shall also be sent in all subsequent 18x responses, and the 2x= x responses, for the same dialog. =20 So, the updated text could say something like: =20 =20 "An entity can include the same Feature-Caps=20 header field value in multiple responses (18x/2xx) for the= same INVITE/re-INVITE transaction, but for a given dialog the e= ntity=20 MUST use the same Feature-Caps header field value (if included)=20 in all responses for the same transaction. In addition, if= an entity includes a Feature-Caps header field in a 18x response, for the given dialog it MUST include the header field in a= ll=20 subsequent 18x responses, and the 2xx response, for the sa= me transaction." Regards, Christer ________________________________ From: Andrew Allen [mailto:aallen@rim.com]=20 Sent: 3. marraskuuta 2011 20:21 To: Christer Holmberg; Subject: RE: Feature-Caps: Feature indications in 18x and 200 Agree =20 From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Christer Holmberg Sent: Thursday, November 03, 2011 8:08 AM To: Subject: [sipcore] Feature-Caps: Feature indications in 18x and 200 =20 =20 Hi, =20 The Feature-Caps draft currently allows sending of feature indications in r= eliable 18x and 200 responses. =20 I've received an off-line question, asking whether the indicated features m= ust be identical, if included both in 18x and 200 for the same request. =20 My suggestion would be that we take the same approach that we did for Info = Packages. =20 Section 5.2.3 of RFC 6086 says: =20 "As with SDP answers, the receiver can include the same Rec= v-Info header field value in multiple responses (18x/2xx) for the= same INVITE/re-INVITE transaction, but the receiver MUST use th= e same Recv-Info header field value (if included) in all response= s for the same transaction." =20 ...so, for Feature-Caps it could say something like: =20 "An entity can include the same Feature-Caps header field value in multiple responses (18x/2xx) for the= same INVITE/re-INVITE transaction, but the entity MUST use the = same Feature-Caps header field value (if included) in all respo= nses for the same transaction." =20 Regards, =20 Christer =20 =20 =20 ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.=20 From HKaplan@acmepacket.com Sun Nov 6 05:17:29 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66D921F844E for ; Sun, 6 Nov 2011 05:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 z4XjwEEK1Zxy for ; Sun, 6 Nov 2011 05:17:29 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id AF9D921F844D for ; Sun, 6 Nov 2011 05:17:28 -0800 (PST) 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; Sun, 6 Nov 2011 08:17:22 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sun, 6 Nov 2011 08:17:22 -0500 From: Hadriel Kaplan To: Christer Holmberg Thread-Topic: [sipcore] Feature-Caps: Feature indications in 18x and 200 Thread-Index: AQHMnIZqsqgAXcvIkU2BPrqsp0MXIA== Date: Sun, 6 Nov 2011 13:17:20 +0000 Message-ID: <89FD9FEC-0A17-4C3A-B337-8D87F6D617FE@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A05852235962788@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522357173BF@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522357173BF@ESESSCMS0356.eemea.ericsson.se> 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: <2DD97C6B9E323C4B91E0C81A17722756@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "sipcore@ietf.org Core\) WG" Subject: Re: [sipcore] Feature-Caps: Feature indications in 18x and 200 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 06 Nov 2011 13:17:29 -0000 The tricky thing is a UAC can't rely on getting the same list in all respon= ses, even if we mandate devices send the same back, due to forking cases, r= ight? So what do we say about the UAC receiving the responses if it gets a 200 wi= th a different Caps list than the 18x? -hadriel On Nov 5, 2011, at 7:49 PM, Christer Holmberg wrote: > Hi, >=20 > I received a comment that it would be good to clarify that the header fie= ld value must be identical in 18x/2xx responses belonging to the same dialo= g. >=20 > In addition, I received a request to say that, if the header field is sen= t in a 18x, it shall also be sent in all subsequent 18x responses, and the = 2xx responses, for the same dialog. >=20 > So, the updated text could say something like: >=20 >=20 > "An entity can include the same Feature-Caps=20 > header field value in multiple responses (18x/2xx) for the= same > INVITE/re-INVITE transaction, but for a given dialog the e= ntity=20 > MUST use the same Feature-Caps header field value (if included)=20 > in all responses for the same transaction. In addition, if= an > entity includes a Feature-Caps header field in a 18x response, > for the given dialog it MUST include the header field in a= ll=20 > subsequent 18x responses, and the 2xx response, for the sa= me > transaction." >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > ________________________________ >=20 > From: Andrew Allen [mailto:aallen@rim.com]=20 > Sent: 3. marraskuuta 2011 20:21 > To: Christer Holmberg; > Subject: RE: Feature-Caps: Feature indications in 18x and 200 >=20 >=20 >=20 > Agree >=20 >=20 >=20 > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f Of Christer Holmberg > Sent: Thursday, November 03, 2011 8:08 AM > To: > Subject: [sipcore] Feature-Caps: Feature indications in 18x and 200 >=20 >=20 >=20 >=20 >=20 > Hi, >=20 >=20 >=20 > The Feature-Caps draft currently allows sending of feature indications in= reliable 18x and 200 responses. >=20 >=20 >=20 > I've received an off-line question, asking whether the indicated features= must be identical, if included both in 18x and 200 for the same request. >=20 >=20 >=20 > My suggestion would be that we take the same approach that we did for Inf= o Packages. >=20 >=20 >=20 > Section 5.2.3 of RFC 6086 says: >=20 >=20 >=20 > "As with SDP answers, the receiver can include the same Rec= v-Info >=20 > header field value in multiple responses (18x/2xx) for the= same >=20 > INVITE/re-INVITE transaction, but the receiver MUST use th= e same >=20 > Recv-Info header field value (if included) in all response= s for the >=20 > same transaction." >=20 >=20 >=20 > ...so, for Feature-Caps it could say something like: >=20 >=20 >=20 > "An entity can include the same Feature-Caps >=20 > header field value in multiple responses (18x/2xx) for the= same >=20 > INVITE/re-INVITE transaction, but the entity MUST use the = same >=20 > Feature-Caps header field value (if included) in all respo= nses for the >=20 > same transaction." >=20 >=20 >=20 > Regards, >=20 >=20 >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ---------------------------------------------------------------------=20 > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful.=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From keith.drage@alcatel-lucent.com Sun Nov 6 09:07:11 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB17D21F84CB for ; Sun, 6 Nov 2011 09:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.173 X-Spam-Level: X-Spam-Status: No, score=-106.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGZSRR44Ft47 for ; Sun, 6 Nov 2011 09:07:11 -0800 (PST) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id C4DDE21F84D5 for ; Sun, 6 Nov 2011 09:07:10 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id pA6H74Wg008613 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 6 Nov 2011 18:07:06 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Sun, 6 Nov 2011 18:07:05 +0100 From: "DRAGE, Keith (Keith)" To: Hadriel Kaplan , Christer Holmberg Date: Sun, 6 Nov 2011 18:07:01 +0100 Thread-Topic: [sipcore] Feature-Caps: Feature indications in 18x and 200 Thread-Index: AQHMnIZqsqgAXcvIkU2BPrqsp0MXIJWgE4xg Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852235962788@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522357173BF@ESESSCMS0356.eemea.ericsson.se> <89FD9FEC-0A17-4C3A-B337-8D87F6D617FE@acmepacket.com> In-Reply-To: <89FD9FEC-0A17-4C3A-B337-8D87F6D617FE@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "sipcore@ietf.org Core\) WG" Subject: Re: [sipcore] Feature-Caps: Feature indications in 18x and 200 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 06 Nov 2011 17:07:12 -0000 Christer is identifying the sending requirements. For the receiving side, I'd suggest that the contents of the 2xx have to be= taken as definitive (assuming you have received it). Regards Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 06 November 2011 13:17 > To: Christer Holmberg > Cc: sipcore@ietf.org Core) WG > Subject: Re: [sipcore] Feature-Caps: Feature indications in=20 > 18x and 200 >=20 >=20 > The tricky thing is a UAC can't rely on getting the same list=20 > in all responses, even if we mandate devices send the same=20 > back, due to forking cases, right? >=20 > So what do we say about the UAC receiving the responses if it=20 > gets a 200 with a different Caps list than the 18x? >=20 > -hadriel >=20 >=20 > On Nov 5, 2011, at 7:49 PM, Christer Holmberg wrote: >=20 > > Hi, > >=20 > > I received a comment that it would be good to clarify that=20 > the header field value must be identical in 18x/2xx responses=20 > belonging to the same dialog. > >=20 > > In addition, I received a request to say that, if the=20 > header field is sent in a 18x, it shall also be sent in all=20 > subsequent 18x responses, and the 2xx responses, for the same dialog. > >=20 > > So, the updated text could say something like: > >=20 > >=20 > > "An entity can include the same Feature-Caps=20 > > header field value in multiple responses=20 > (18x/2xx) for the same > > INVITE/re-INVITE transaction, but for a=20 > given dialog the entity=20 > > MUST use the same Feature-Caps header=20 > field value (if included)=20 > > in all responses for the same transaction.=20 > In addition, if an > > entity includes a Feature-Caps header=20 > field in a 18x response, > > for the given dialog it MUST include the=20 > header field in all=20 > > subsequent 18x responses, and the 2xx=20 > response, for the same > > transaction." > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > >=20 > > ________________________________ > >=20 > > From: Andrew Allen [mailto:aallen@rim.com] > > Sent: 3. marraskuuta 2011 20:21 > > To: Christer Holmberg; > > Subject: RE: Feature-Caps: Feature indications in 18x and 200 > >=20 > >=20 > >=20 > > Agree > >=20 > >=20 > >=20 > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Christer Holmberg > > Sent: Thursday, November 03, 2011 8:08 AM > > To: > > Subject: [sipcore] Feature-Caps: Feature indications in 18x and 200 > >=20 > >=20 > >=20 > >=20 > >=20 > > Hi, > >=20 > >=20 > >=20 > > The Feature-Caps draft currently allows sending of feature=20 > indications in reliable 18x and 200 responses. > >=20 > >=20 > >=20 > > I've received an off-line question, asking whether the=20 > indicated features must be identical, if included both in 18x=20 > and 200 for the same request. > >=20 > >=20 > >=20 > > My suggestion would be that we take the same approach that=20 > we did for Info Packages. > >=20 > >=20 > >=20 > > Section 5.2.3 of RFC 6086 says: > >=20 > >=20 > >=20 > > "As with SDP answers, the receiver can=20 > include the same=20 > > Recv-Info > >=20 > > header field value in multiple responses=20 > (18x/2xx) for=20 > > the same > >=20 > > INVITE/re-INVITE transaction, but the=20 > receiver MUST use=20 > > the same > >=20 > > Recv-Info header field value (if included) in all=20 > > responses for the > >=20 > > same transaction." > >=20 > >=20 > >=20 > > ...so, for Feature-Caps it could say something like: > >=20 > >=20 > >=20 > > "An entity can include the same Feature-Caps > >=20 > > header field value in multiple responses=20 > (18x/2xx) for=20 > > the same > >=20 > > INVITE/re-INVITE transaction, but the entity=20 > MUST use=20 > > the same > >=20 > > Feature-Caps header field value (if included) in all=20 > > responses for the > >=20 > > same transaction." > >=20 > >=20 > >=20 > > Regards, > >=20 > >=20 > >=20 > > Christer > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > >=20 > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain=20 > confidential information, privileged material (including=20 > material protected by the solicitor-client or other=20 > applicable privileges), or constitute non-public information.=20 > Any use of this information by anyone other than the intended=20 > recipient is prohibited. If you have received this=20 > transmission in error, please immediately reply to the sender=20 > and delete this information from your system. Use,=20 > dissemination, distribution, or reproduction of this=20 > transmission by unintended recipients is not authorized and=20 > may be unlawful.=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Sun Nov 6 13:08:02 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C380121F877F for ; Sun, 6 Nov 2011 13:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.315 X-Spam-Level: X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpgE-h5+yWyz for ; Sun, 6 Nov 2011 13:08:01 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 47F7121F8770 for ; Sun, 6 Nov 2011 13:08:00 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-0e-4eb6f72f6f1e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id AF.E3.13753.F27F6BE4; Sun, 6 Nov 2011 22:07:59 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Sun, 6 Nov 2011 22:07:59 +0100 From: Christer Holmberg To: Hadriel Kaplan Date: Sun, 6 Nov 2011 22:05:57 +0100 Thread-Topic: [sipcore] Feature-Caps: Feature indications in 18x and 200 Thread-Index: AQHMnIZqsqgAXcvIkU2BPrqsp0MXIJWgVrXB Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522357173C2@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235962788@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522357173BF@ESESSCMS0356.eemea.ericsson.se>, <89FD9FEC-0A17-4C3A-B337-8D87F6D617FE@acmepacket.com> In-Reply-To: <89FD9FEC-0A17-4C3A-B337-8D87F6D617FE@acmepacket.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org Core\) WG" Subject: Re: [sipcore] Feature-Caps: Feature indications in 18x and 200 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 06 Nov 2011 21:08:02 -0000 Hi Hadriel, > The tricky thing is a UAC can't rely on getting the same list in all resp= onses, even if we mandate devices send the same back, due to forking cases,= right? > > So what do we say about the UAC receiving the responses if it gets a 200 = with a different Caps list than the 18x? Please note that the text talks about using the same value in 18x and 200 -= per dialog. So, in forking case, you can of course receive different values in 18x/2xx = responses associated with different early dialogs. Regards, Christer On Nov 5, 2011, at 7:49 PM, Christer Holmberg wrote: > Hi, > > I received a comment that it would be good to clarify that the header fie= ld value must be identical in 18x/2xx responses belonging to the same dialo= g. > > In addition, I received a request to say that, if the header field is sen= t in a 18x, it shall also be sent in all subsequent 18x responses, and the = 2xx responses, for the same dialog. > > So, the updated text could say something like: > > > "An entity can include the same Feature-Caps > header field value in multiple responses (18x/2xx) for the= same > INVITE/re-INVITE transaction, but for a given dialog the e= ntity > MUST use the same Feature-Caps header field value (if = included) > in all responses for the same transaction. In addition, if= an > entity includes a Feature-Caps header field in a 18x r= esponse, > for the given dialog it MUST include the header field in a= ll > subsequent 18x responses, and the 2xx response, for the sa= me > transaction." > > Regards, > > Christer > > > > ________________________________ > > From: Andrew Allen [mailto:aallen@rim.com] > Sent: 3. marraskuuta 2011 20:21 > To: Christer Holmberg; > Subject: RE: Feature-Caps: Feature indications in 18x and 200 > > > > Agree > > > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f Of Christer Holmberg > Sent: Thursday, November 03, 2011 8:08 AM > To: > Subject: [sipcore] Feature-Caps: Feature indications in 18x and 200 > > > > > > Hi, > > > > The Feature-Caps draft currently allows sending of feature indications in= reliable 18x and 200 responses. > > > > I've received an off-line question, asking whether the indicated features= must be identical, if included both in 18x and 200 for the same request. > > > > My suggestion would be that we take the same approach that we did for Inf= o Packages. > > > > Section 5.2.3 of RFC 6086 says: > > > > "As with SDP answers, the receiver can include the same Rec= v-Info > > header field value in multiple responses (18x/2xx) for the= same > > INVITE/re-INVITE transaction, but the receiver MUST use th= e same > > Recv-Info header field value (if included) in all response= s for the > > same transaction." > > > > ...so, for Feature-Caps it could say something like: > > > > "An entity can include the same Feature-Caps > > header field value in multiple responses (18x/2xx) for the= same > > INVITE/re-INVITE transaction, but the entity MUST use the = same > > Feature-Caps header field value (if included) in all respo= nses for the > > same transaction." > > > > Regards, > > > > Christer > > > > > > > > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential in= formation, privileged material (including material protected by the solicit= or-client or other applicable privileges), or constitute non-public informa= tion. Any use of this information by anyone other than the intended recipie= nt is prohibited. If you have received this transmission in error, please i= mmediately reply to the sender and delete this information from your system= . Use, dissemination, distribution, or reproduction of this transmission by= unintended recipients is not authorized and may be unlawful. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore= From christer.holmberg@ericsson.com Sun Nov 6 13:11:29 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932E721F8586 for ; Sun, 6 Nov 2011 13:11:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.318 X-Spam-Level: X-Spam-Status: No, score=-6.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBKkZrXrA0eN for ; Sun, 6 Nov 2011 13:11:28 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6791521F850B for ; Sun, 6 Nov 2011 13:11:28 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-23-4eb6f7ffcf7f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 36.D2.09514.FF7F6BE4; Sun, 6 Nov 2011 22:11:27 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 6 Nov 2011 22:11:26 +0100 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , Hadriel Kaplan Date: Sun, 6 Nov 2011 22:08:40 +0100 Thread-Topic: [sipcore] Feature-Caps: Feature indications in 18x and 200 Thread-Index: AQHMnIZqsqgAXcvIkU2BPrqsp0MXIJWgE4xggABD6zo= Message-ID: <7F2072F1E0DE894DA4B517B93C6A058522357173C3@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235962788@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522357173BF@ESESSCMS0356.eemea.ericsson.se> <89FD9FEC-0A17-4C3A-B337-8D87F6D617FE@acmepacket.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org Core\) WG" Subject: Re: [sipcore] Feature-Caps: Feature indications in 18x and 200 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 06 Nov 2011 21:11:29 -0000 Hi, > Christer is identifying the sending requirements. > > For the receiving side, I'd suggest that the contents of the 2xx have to = be taken as definitive (assuming you have received it). If an entity receives different values in responses associated with the sam= e dialog, an error case has occured (as the sender should not send differen= t values for the same dialog). So, we can either say that the first response with Feature-Caps is taken as= definitive, or we can say that the Feature-Caps in 2xx is taken as definit= ive, because for a given dialog they should always be the same. Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: 06 November 2011 13:17 > To: Christer Holmberg > Cc: sipcore@ietf.org Core) WG > Subject: Re: [sipcore] Feature-Caps: Feature indications in > 18x and 200 > > > The tricky thing is a UAC can't rely on getting the same list > in all responses, even if we mandate devices send the same > back, due to forking cases, right? > > So what do we say about the UAC receiving the responses if it > gets a 200 with a different Caps list than the 18x? > > -hadriel > > > On Nov 5, 2011, at 7:49 PM, Christer Holmberg wrote: > > > Hi, > > > > I received a comment that it would be good to clarify that > the header field value must be identical in 18x/2xx responses > belonging to the same dialog. > > > > In addition, I received a request to say that, if the > header field is sent in a 18x, it shall also be sent in all > subsequent 18x responses, and the 2xx responses, for the same dialog. > > > > So, the updated text could say something like: > > > > > > "An entity can include the same Feature-Caps > > header field value in multiple responses > (18x/2xx) for the same > > INVITE/re-INVITE transaction, but for a > given dialog the entity > > MUST use the same Feature-Caps header > field value (if included) > > in all responses for the same transaction. > In addition, if an > > entity includes a Feature-Caps header > field in a 18x response, > > for the given dialog it MUST include the > header field in all > > subsequent 18x responses, and the 2xx > response, for the same > > transaction." > > > > Regards, > > > > Christer > > > > > > > > ________________________________ > > > > From: Andrew Allen [mailto:aallen@rim.com] > > Sent: 3. marraskuuta 2011 20:21 > > To: Christer Holmberg; > > Subject: RE: Feature-Caps: Feature indications in 18x and 200 > > > > > > > > Agree > > > > > > > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > > Behalf Of Christer Holmberg > > Sent: Thursday, November 03, 2011 8:08 AM > > To: > > Subject: [sipcore] Feature-Caps: Feature indications in 18x and 200 > > > > > > > > > > > > Hi, > > > > > > > > The Feature-Caps draft currently allows sending of feature > indications in reliable 18x and 200 responses. > > > > > > > > I've received an off-line question, asking whether the > indicated features must be identical, if included both in 18x > and 200 for the same request. > > > > > > > > My suggestion would be that we take the same approach that > we did for Info Packages. > > > > > > > > Section 5.2.3 of RFC 6086 says: > > > > > > > > "As with SDP answers, the receiver can > include the same > > Recv-Info > > > > header field value in multiple responses > (18x/2xx) for > > the same > > > > INVITE/re-INVITE transaction, but the > receiver MUST use > > the same > > > > Recv-Info header field value (if included) in all > > responses for the > > > > same transaction." > > > > > > > > ...so, for Feature-Caps it could say something like: > > > > > > > > "An entity can include the same Feature-Caps > > > > header field value in multiple responses > (18x/2xx) for > > the same > > > > INVITE/re-INVITE transaction, but the entity > MUST use > > the same > > > > Feature-Caps header field value (if included) in all > > responses for the > > > > same transaction." > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain > confidential information, privileged material (including > material protected by the solicitor-client or other > applicable privileges), or constitute non-public information. > Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this > transmission in error, please immediately reply to the sender > and delete this information from your system. Use, > dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and > may be unlawful. > > _______________________________________________ > > 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 HKaplan@acmepacket.com Sun Nov 6 19:34:30 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E226E21F84CB for ; Sun, 6 Nov 2011 19:34:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 MU8X2ZxV16qe for ; Sun, 6 Nov 2011 19:34:29 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 542DD21F84BC for ; Sun, 6 Nov 2011 19:34:29 -0800 (PST) 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; Sun, 6 Nov 2011 22:34:28 -0500 Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Sun, 6 Nov 2011 22:34:28 -0500 From: Hadriel Kaplan To: Christer Holmberg Thread-Topic: [sipcore] Feature-Caps: Feature indications in 18x and 200 Thread-Index: AQHMnP4msqgAXcvIkU2BPrqsp0MXIA== Date: Mon, 7 Nov 2011 03:34:27 +0000 Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A05852235962788@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522357173BF@ESESSCMS0356.eemea.ericsson.se> <89FD9FEC-0A17-4C3A-B337-8D87F6D617FE@acmepacket.com>, <7F2072F1E0DE894DA4B517B93C6A058522357173C3@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058522357173C3@ESESSCMS0356.eemea.ericsson.se> 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: <27CAE4D3AA806C4CB774FB726A3A33E1@acmepacket.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAWE= Cc: "sipcore@ietf.org Core\) WG" Subject: Re: [sipcore] Feature-Caps: Feature indications in 18x and 200 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 07 Nov 2011 03:34:30 -0000 On Nov 6, 2011, at 4:08 PM, Christer Holmberg wrote: > If an entity receives different values in responses associated with the s= ame dialog, an error case has occured (as the sender should not send differ= ent values for the same dialog). >=20 > So, we can either say that the first response with Feature-Caps is taken = as definitive, or we can say that the Feature-Caps in 2xx is taken as defin= itive, because for a given dialog they should always be the same. Right, so I agree with Keith that the 2xx should win. -hadriel From christer.holmberg@ericsson.com Mon Nov 7 00:25:18 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8639221F8515 for ; Mon, 7 Nov 2011 00:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.321 X-Spam-Level: X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzZX-7nnCis8 for ; Mon, 7 Nov 2011 00:25:17 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9D97821F8514 for ; Mon, 7 Nov 2011 00:25:17 -0800 (PST) X-AuditID: c1b4fb3d-b7c26ae0000035b9-fa-4eb795ec0f79 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BB.13.13753.CE597BE4; Mon, 7 Nov 2011 09:25:16 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 7 Nov 2011 09:25:16 +0100 From: Christer Holmberg To: Hadriel Kaplan Date: Mon, 7 Nov 2011 09:25:14 +0100 Thread-Topic: [sipcore] Feature-Caps: Feature indications in 18x and 200 Thread-Index: AQHMnP4msqgAXcvIkU2BPrqsp0MXIJWhE4QA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852235963132@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235962788@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522357173BF@ESESSCMS0356.eemea.ericsson.se> <89FD9FEC-0A17-4C3A-B337-8D87F6D617FE@acmepacket.com>, <7F2072F1E0DE894DA4B517B93C6A058522357173C3@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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org Core\) WG" Subject: Re: [sipcore] Feature-Caps: Feature indications in 18x and 200 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 07 Nov 2011 08:25:18 -0000 Hi,=20 >> If an entity receives different values in responses=20 >> associated with the same dialog, an error case has occured=20 >>(as the sender should not send different values for the same dialog). >>=20 >> So, we can either say that the first response with=20 >> Feature-Caps is taken as definitive, or we can say that the=20 >> Feature-Caps in 2xx is taken as definitive, because for a=20 >> given dialog they should always be the same. >=20 > Right, so I agree with Keith that the 2xx should win. So, I have done some additions () to the suggested text: "An entity can include the same Feature-Caps=20 header field value in multiple responses (18x/2xx)=20 for the same INVITE/re-INVITE transaction, but for a given dialog the entity MUST use the same Feature-Caps=20 header field value (if included) in all responses for=20 the same transaction. In addition, if an entity includes=20 a Feature-Caps header field in a 18x response, for the=20 given dialog it MUST include the header field in all subsequent 18x responses, and the 2xx response, for the=20 same transaction. If an entity, for a given dialog, receives different Feature-Caps header field values in responses to the same transaction (this would not happen in normal operations), it MUST use the latest header field=20 values as the valid one." Regards, Christer= From pkyzivat@alum.mit.edu Mon Nov 7 10:39:34 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0920A11E808E for ; Mon, 7 Nov 2011 10:39:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 GuwxUdLB+UC5 for ; Mon, 7 Nov 2011 10:39:33 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id 4734711E8081 for ; Mon, 7 Nov 2011 10:39:33 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta12.westchester.pa.mail.comcast.net with comcast id uGvp1h00F1ZXKqc5CJfZFF; Mon, 07 Nov 2011 18:39:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id uJfZ1h01007duvL3hJfZvi; Mon, 07 Nov 2011 18:39:33 +0000 Message-ID: <4EB825E3.6060902@alum.mit.edu> Date: Mon, 07 Nov 2011 13:39:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A05852235962788@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522357173BF@ESESSCMS0356.eemea.ericsson.se> <89FD9FEC-0A17-4C3A-B337-8D87F6D617FE@acmepacket.com>, <7F2072F1E0DE894DA4B517B93C6A058522357173C3@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852235963132@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852235963132@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Feature-Caps: Feature indications in 18x and 200 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 07 Nov 2011 18:39:34 -0000 On 11/7/11 3:25 AM, Christer Holmberg wrote: > Hi, > >>> If an entity receives different values in responses >>> associated with the same dialog, an error case has occured >>> (as the sender should not send different values for the same dialog). >>> >>> So, we can either say that the first response with >>> Feature-Caps is taken as definitive, or we can say that the >>> Feature-Caps in 2xx is taken as definitive, because for a >>> given dialog they should always be the same. >> >> Right, so I agree with Keith that the 2xx should win. I generally have some discomfort with specifying the behavior of a recipient upon receiving invalid input. Doing so tacitly gives the sender permission to send in this way, because the behavior is defined. If we are to define how this case is handled we might as well make it valid behavior. So at least I would prefer to have the behavior in this case be non-normative. The reason for sending multiple times can be to get it there asap and still ensure it gets there when the provisionals are unreliable. But its worth considering what to do when the value is send in a *reliable* provisional. The text below talks about a single transaction. But it seems the intent is to establish state the lasts for the duration of a dialog (or a registration). ISTM that it should probably be ok to change the value for a dialog via a reliable request or response withing the dialog. (And for a registration via a registration update.) That would cover the 3pcc cases. While obscure, IMO that would mean that after establishing a value with a reliable provisional, you should then be able to change it in another reliable provisional or the 2xx. (And maybe in an UPDATE.) Thanks, Paul > So, I have done some additions () to the suggested text: > > "An entity can include the same Feature-Caps > header field value in multiple responses (18x/2xx) > for the same INVITE/re-INVITE transaction, but for a > given dialog the entity MUST use the same Feature-Caps > header field value (if included) in all responses for > the same transaction. In addition, if an entity includes > a Feature-Caps header field in a 18x response, for the > given dialog it MUST include the header field in all > subsequent 18x responses, and the 2xx response, for the > same transaction. If an entity, for a given dialog, > receives different Feature-Caps header field values in > responses to the same transaction (this would not happen in > normal operations), it MUST use the latest header field > values as the valid one." > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Mon Nov 7 11:00:14 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C32811E808E for ; Mon, 7 Nov 2011 11:00:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.325 X-Spam-Level: X-Spam-Status: No, score=-6.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9OiIlBFivGD for ; Mon, 7 Nov 2011 11:00:13 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DC8CF21F8B45 for ; Mon, 7 Nov 2011 11:00:12 -0800 (PST) X-AuditID: c1b4fb39-b7b3eae00000252a-ec-4eb82abb51b3 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 46.0C.09514.BBA28BE4; Mon, 7 Nov 2011 20:00:12 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.57]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 7 Nov 2011 20:00:11 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , "sipcore@ietf.org" Date: Mon, 7 Nov 2011 20:00:10 +0100 Thread-Topic: [sipcore] Feature-Caps: Feature indications in 18x and 200 Thread-Index: AcydfJpmGm8VUqHHSNmXQhCTzJnrXQAAUsIg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852235789608@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852235962788@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522357173BF@ESESSCMS0356.eemea.ericsson.se> <89FD9FEC-0A17-4C3A-B337-8D87F6D617FE@acmepacket.com>, <7F2072F1E0DE894DA4B517B93C6A058522357173C3@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852235963132@ESESSCMS0356.eemea.ericsson.se> <4EB825E3.6060902@alum.mit.edu> In-Reply-To: <4EB825E3.6060902@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Feature-Caps: Feature indications in 18x and 200 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 07 Nov 2011 19:00:14 -0000 Hi,=20 >>>> If an entity receives different values in responses associated with=20 >>>> the same dialog, an error case has occured (as the sender should not=20 >>>> send different values for the same dialog). >>>> >>>> So, we can either say that the first response with Feature-Caps is=20 >>>> taken as definitive, or we can say that the Feature-Caps in 2xx is=20 >>>> taken as definitive, because for a given dialog they should always=20 >>>> be the same. >>> >>> Right, so I agree with Keith that the 2xx should win. > > I generally have some discomfort with specifying the behavior of a recipi= ent upon receiving=20 > invalid input. Doing so tacitly gives the sender permission to send in th= is way, because the behavior is defined.=20 > If we are to define how this case is handled we might as well make it val= id behavior. Correct. As you say, if this happens, the sender does something wrong, so n= o matter what we specify for the receiver,=20 I don't think we can ensure that the sender and receiver will have a common= understanding. The same applies for Info Packages, and for that we don't specify any recei= ver procedures for such error case either. > So at least I would prefer to have the behavior in this case be non-norma= tive. > > The reason for sending multiple times can be to get it there asap and sti= ll ensure it gets=20 > there when the provisionals are unreliable. But its worth considering wha= t to do when the=20 > value is send in a *reliable* provisional. The text currently says that the header field has to be sent in a reliable = response, but of course we can allow it also in unreliable responses - as long as it is sent at least in one reliable re= sponse. > The text below talks about a single transaction. But it seems the intent = is to establish=20 > state the lasts for the duration of a dialog (or a registration). > > ISTM that it should probably be ok to change the value for a dialog via a= reliable request=20 > or response withing the dialog. (And for a registration via a registratio= n update.) That=20 > would cover the 3pcc cases. Correct, and based on your earlier comments I have suggested text for that = in another=20 thread ([sipcore] Feature-Caps: Feature indication in target refresh reques= t). The text we are discussing now only covers multiple responses for a single = transaction. > While obscure, IMO that would mean that after establishing a value with a= reliable provisional, you should then be > able to change it in another reliable provisional or the 2xx. (And maybe = in an UPDATE.) The text I've suggested states that the change must be done using a target = refresh request. If you want to discuss that, let's do it in the other thread :) Regards, Christer > So, I have done some additions () to the suggested text: > > "An entity can include the same Feature-Caps > header field value in multiple responses (18x/2xx) > for the same INVITE/re-INVITE transaction, but for a > given dialog the entity MUST use the same Feature-Caps > header field value (if included) in all responses for > the same transaction. In addition, if an entity includes > a Feature-Caps header field in a 18x response, for the > given dialog it MUST include the header field in all > subsequent 18x responses, and the 2xx response, for the > same transaction. If an entity, for a given dialog, > receives different Feature-Caps header field values in > responses to the same transaction (this would not happen in > normal operations), it MUST use the latest header field > values as the valid one." > > Regards, > > Christer > _______________________________________________ > 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 victor.pascual.avila@gmail.com Tue Nov 15 02:02:35 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE7D21F8FAD for ; Tue, 15 Nov 2011 02:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WQfrjdGE1Ko for ; Tue, 15 Nov 2011 02:02:34 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4751321F8FA5 for ; Tue, 15 Nov 2011 02:02:34 -0800 (PST) Received: by ggnr5 with SMTP id r5so2278271ggn.31 for ; Tue, 15 Nov 2011 02:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=0tRgRN4K63xYsLl4x0tpKzOollrGaK1nNYRnQbCr3ak=; b=Pmcu2/wTvenWopHfldRE2eO9aMdYelt3+aVMvMvPSqz48xsBASkFzFC8stdJSZaehQ ySs+Hfa/EmJkAH5tA8r5ADSaREA+JrJNdGEL19FAgZSlt6nzBTUVNS3PZvYIsRB6MRI7 Sq7x8+UdXMX0nLC8VG/2srKQI5Vw6iOyi5mr4= MIME-Version: 1.0 Received: by 10.50.195.233 with SMTP id ih9mr28860196igc.21.1321351353803; Tue, 15 Nov 2011 02:02:33 -0800 (PST) Received: by 10.231.19.204 with HTTP; Tue, 15 Nov 2011 02:02:33 -0800 (PST) In-Reply-To: References: Date: Tue, 15 Nov 2011 11:02:33 +0100 Message-ID: From: Victor Pascual Avila To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 15 Nov 2011 10:02:35 -0000 FYI: We're planning to submit a new revision of the draft (addressing the feedback received so far) during the next couple of weeks -Victor On Fri, Oct 28, 2011 at 2:42 PM, I=C3=B1aki Baz Castillo wr= ote: > A draft describing a mechanism for usage of WebSocket protocol as a > new transport between SIP entities was submitted to rtcweb WG on 13 > Sep 2011. However the discussions on that list seemed to conclude that > the draft was interesting but outside the scope of rtcweb. Since the > draft describes a new transport for SIP it makes more sense to propose > it in SIPCORE WG. Therefore we ask the SIPCORE WG to discuss whether > the proposed draft could fit well in this WG. > > There are some aspects of the draft that will be addressed in a new > revision (as mandating Outbound support given the nature of the > WebSocket protocol). The first revision of the draft can be found at: > > http://datatracker.ietf.org/doc/draft-ibc-rtcweb-sip-websocket/ > > -------------------------------- > Abstract > > =C2=A0=C2=A0This document specifies a WebSocket subprotocol for a new tra= nsport > =C2=A0in SIP (Session Initiation Protocol). =C2=A0The WebSocket protocol = enables > =C2=A0two-way realtime communication between clients (typically web-based > =C2=A0applications) and servers. =C2=A0The main goal of this specificatio= n is to > =C2=A0integrate the SIP protocol within web > =C2=A0applications. > ------------------------------ > > > This new SIP transport could fit well within a RTCweb architecture > (since RTCweb does not mandate the in-the-wire protocol nor the format > of the messages exchanged between RTCweb clients and servers). This is > just a use case, a future revision of the draft could incorporate more > use cases. > > > A presentation of the proposed specification (including a video with > running code) can be found at: > > http://sip-on-the-web.aliax.net/ > > ------------------------------- > Introduction > > =C2=A0The aim of this presentation is to show the SIP protocol working > =C2=A0within a web browser and interoperating with any SIP network. > > =C2=A0=C2=A0After some slides describing the used technology there is a > =C2=A0signaling flowchart and a video showing a real implementation. > ------------------------------- > > > Please let us know whether this draft would fit well in SIPCORE or may > be we would do better by proposing it in DISPATCH. > > Thanks a lot. > > > -- > I=C3=B1aki Baz Castillo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From Ranjit.Avasarala@Polycom.com Tue Nov 15 02:10:34 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29ECE21F8BB6 for ; Tue, 15 Nov 2011 02:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il0vzxLdGind for ; Tue, 15 Nov 2011 02:10:33 -0800 (PST) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id 47F3E21F8D80 for ; Tue, 15 Nov 2011 02:10:23 -0800 (PST) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Tue, 15 Nov 2011 18:10:22 +0800 From: "Avasarala, Ranjit" To: Victor Pascual Avila , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Tue, 15 Nov 2011 18:10:20 +0800 Thread-Topic: [sipcore] Proposal for a new SIP transport (WebSocket) Thread-Index: Acyjfbp1ZNIZdxyqTqKyP9Np6nJ4hQAAKXyQ Message-ID: <1F2A2C70609D9E41844A2126145FC0982D3F4D40@HKGMBOXPRD22.polycom.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 15 Nov 2011 10:10:34 -0000 SGkgVmljdG9yDQoNCk9uZSBjb21tZW50IC0gdGhlIHByb3Bvc2FsIG9mIFNJUCBhcyBhIG5ldyBX ZWJTb2NrZXQgc3ViIHByb3RvY29sIGlzIG5vdCB2ZXJ5IGNsZWFyIGluIHVyIGRyYWZ0LiBTbyB5 b3UgY291bGQgYWRkIGFuIGV4YW1wbGUgZm9yIGl0Lg0KRS5nLiAgU2VjLVdlYlNvY2tldC1Qcm90 b2NvbDogc2lwICAoaXMgdGhpcyB3aGF0IHlvdSBpbnRlbmQgdG8gcHJvcG9zZT8pLg0KDQpBbHNv IGFkZCBhIHNlY3Rpb24gb24gaG93IFNJUCBhcyBhIFdlYlNvY2tldCBzdWIgcHJvdG9jb2wgaXMg bmVnb3RpYXRlZCBhcyBwYXJ0IG9mIGNsaWVudC9zZXJ2ZXIgaGFuZHNoYWtlIHByb2NlZHVyZS4N Cg0KVGhhbmtzDQoNClJlZ2FyZHMNClJhbmppdA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwY29yZS1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVmljdG9yIFBhc2N1YWwgQXZpbGENClNlbnQ6IFR1ZXNk YXksIE5vdmVtYmVyIDE1LCAyMDExIDM6MzMgUE0NClRvOiBTSVBDT1JFIChTZXNzaW9uIEluaXRp YXRpb24gUHJvdG9jb2wgQ29yZSkgV0cNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gUHJvcG9zYWwg Zm9yIGEgbmV3IFNJUCB0cmFuc3BvcnQgKFdlYlNvY2tldCkNCg0KRllJOiBXZSdyZSBwbGFubmlu ZyB0byBzdWJtaXQgYSBuZXcgcmV2aXNpb24gb2YgdGhlIGRyYWZ0IChhZGRyZXNzaW5nDQp0aGUg ZmVlZGJhY2sgcmVjZWl2ZWQgc28gZmFyKSBkdXJpbmcgdGhlIG5leHQgY291cGxlIG9mIHdlZWtz DQoNCi1WaWN0b3INCg0KT24gRnJpLCBPY3QgMjgsIDIwMTEgYXQgMjo0MiBQTSwgScOxYWtpIEJh eiBDYXN0aWxsbyA8aWJjQGFsaWF4Lm5ldD4gd3JvdGU6DQo+IEEgZHJhZnQgZGVzY3JpYmluZyBh IG1lY2hhbmlzbSBmb3IgdXNhZ2Ugb2YgV2ViU29ja2V0IHByb3RvY29sIGFzIGENCj4gbmV3IHRy YW5zcG9ydCBiZXR3ZWVuIFNJUCBlbnRpdGllcyB3YXMgc3VibWl0dGVkIHRvIHJ0Y3dlYiBXRyBv biAxMw0KPiBTZXAgMjAxMS4gSG93ZXZlciB0aGUgZGlzY3Vzc2lvbnMgb24gdGhhdCBsaXN0IHNl ZW1lZCB0byBjb25jbHVkZSB0aGF0DQo+IHRoZSBkcmFmdCB3YXMgaW50ZXJlc3RpbmcgYnV0IG91 dHNpZGUgdGhlIHNjb3BlIG9mIHJ0Y3dlYi4gU2luY2UgdGhlDQo+IGRyYWZ0IGRlc2NyaWJlcyBh IG5ldyB0cmFuc3BvcnQgZm9yIFNJUCBpdCBtYWtlcyBtb3JlIHNlbnNlIHRvIHByb3Bvc2UNCj4g aXQgaW4gU0lQQ09SRSBXRy4gVGhlcmVmb3JlIHdlIGFzayB0aGUgU0lQQ09SRSBXRyB0byBkaXNj dXNzIHdoZXRoZXINCj4gdGhlIHByb3Bvc2VkIGRyYWZ0IGNvdWxkIGZpdCB3ZWxsIGluIHRoaXMg V0cuDQo+DQo+IFRoZXJlIGFyZSBzb21lIGFzcGVjdHMgb2YgdGhlIGRyYWZ0IHRoYXQgd2lsbCBi ZSBhZGRyZXNzZWQgaW4gYSBuZXcNCj4gcmV2aXNpb24gKGFzIG1hbmRhdGluZyBPdXRib3VuZCBz dXBwb3J0IGdpdmVuIHRoZSBuYXR1cmUgb2YgdGhlDQo+IFdlYlNvY2tldCBwcm90b2NvbCkuIFRo ZSBmaXJzdCByZXZpc2lvbiBvZiB0aGUgZHJhZnQgY2FuIGJlIGZvdW5kIGF0Og0KPg0KPiBodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWliYy1ydGN3ZWItc2lwLXdlYnNvY2tl dC8NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gQWJzdHJhY3QNCj4N Cj4gwqDCoFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgV2ViU29ja2V0IHN1YnByb3RvY29sIGZv ciBhIG5ldyB0cmFuc3BvcnQNCj4gwqBpbiBTSVAgKFNlc3Npb24gSW5pdGlhdGlvbiBQcm90b2Nv bCkuIMKgVGhlIFdlYlNvY2tldCBwcm90b2NvbCBlbmFibGVzDQo+IMKgdHdvLXdheSByZWFsdGlt ZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gY2xpZW50cyAodHlwaWNhbGx5IHdlYi1iYXNlZA0KPiDC oGFwcGxpY2F0aW9ucykgYW5kIHNlcnZlcnMuIMKgVGhlIG1haW4gZ29hbCBvZiB0aGlzIHNwZWNp ZmljYXRpb24gaXMgdG8NCj4gwqBpbnRlZ3JhdGUgdGhlIFNJUCBwcm90b2NvbCB3aXRoaW4gd2Vi DQo+IMKgYXBwbGljYXRpb25zLg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4N Cj4NCj4gVGhpcyBuZXcgU0lQIHRyYW5zcG9ydCBjb3VsZCBmaXQgd2VsbCB3aXRoaW4gYSBSVEN3 ZWIgYXJjaGl0ZWN0dXJlDQo+IChzaW5jZSBSVEN3ZWIgZG9lcyBub3QgbWFuZGF0ZSB0aGUgaW4t dGhlLXdpcmUgcHJvdG9jb2wgbm9yIHRoZSBmb3JtYXQNCj4gb2YgdGhlIG1lc3NhZ2VzIGV4Y2hh bmdlZCBiZXR3ZWVuIFJUQ3dlYiBjbGllbnRzIGFuZCBzZXJ2ZXJzKS4gVGhpcyBpcw0KPiBqdXN0 IGEgdXNlIGNhc2UsIGEgZnV0dXJlIHJldmlzaW9uIG9mIHRoZSBkcmFmdCBjb3VsZCBpbmNvcnBv cmF0ZSBtb3JlDQo+IHVzZSBjYXNlcy4NCj4NCj4NCj4gQSBwcmVzZW50YXRpb24gb2YgdGhlIHBy b3Bvc2VkIHNwZWNpZmljYXRpb24gKGluY2x1ZGluZyBhIHZpZGVvIHdpdGgNCj4gcnVubmluZyBj b2RlKSBjYW4gYmUgZm91bmQgYXQ6DQo+DQo+IGh0dHA6Ly9zaXAtb24tdGhlLXdlYi5hbGlheC5u ZXQvDQo+DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSW50cm9kdWN0aW9u DQo+DQo+IMKgVGhlIGFpbSBvZiB0aGlzIHByZXNlbnRhdGlvbiBpcyB0byBzaG93IHRoZSBTSVAg cHJvdG9jb2wgd29ya2luZw0KPiDCoHdpdGhpbiBhIHdlYiBicm93c2VyIGFuZCBpbnRlcm9wZXJh dGluZyB3aXRoIGFueSBTSVAgbmV0d29yay4NCj4NCj4gwqDCoEFmdGVyIHNvbWUgc2xpZGVzIGRl c2NyaWJpbmcgdGhlIHVzZWQgdGVjaG5vbG9neSB0aGVyZSBpcyBhDQo+IMKgc2lnbmFsaW5nIGZs b3djaGFydCBhbmQgYSB2aWRlbyBzaG93aW5nIGEgcmVhbCBpbXBsZW1lbnRhdGlvbi4NCj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPg0KPiBQbGVhc2UgbGV0IHVzIGtub3cg d2hldGhlciB0aGlzIGRyYWZ0IHdvdWxkIGZpdCB3ZWxsIGluIFNJUENPUkUgb3IgbWF5DQo+IGJl IHdlIHdvdWxkIGRvIGJldHRlciBieSBwcm9wb3NpbmcgaXQgaW4gRElTUEFUQ0guDQo+DQo+IFRo YW5rcyBhIGxvdC4NCj4NCj4NCj4gLS0NCj4gScOxYWtpIEJheiBDYXN0aWxsbw0KPiA8aWJjQGFs aWF4Lm5ldD4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lw Y29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj b3JlDQo= From ibc@aliax.net Tue Nov 15 02:18:52 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1875121F8F40 for ; Tue, 15 Nov 2011 02:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=0.038, 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 QESxMdOMyrYt for ; Tue, 15 Nov 2011 02:18:51 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 88F4021F8F3F for ; Tue, 15 Nov 2011 02:18:51 -0800 (PST) Received: by vws5 with SMTP id 5so7283148vws.31 for ; Tue, 15 Nov 2011 02:18:51 -0800 (PST) Received: by 10.52.65.36 with SMTP id u4mr41526032vds.58.1321352331055; Tue, 15 Nov 2011 02:18:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Tue, 15 Nov 2011 02:18:30 -0800 (PST) In-Reply-To: <1F2A2C70609D9E41844A2126145FC0982D3F4D40@HKGMBOXPRD22.polycom.com> References: <1F2A2C70609D9E41844A2126145FC0982D3F4D40@HKGMBOXPRD22.polycom.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 15 Nov 2011 11:18:30 +0100 Message-ID: To: "Avasarala, Ranjit" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 15 Nov 2011 10:18:52 -0000 2011/11/15 Avasarala, Ranjit : > One comment - the proposal of SIP as a new WebSocket sub protocol is not = very clear in ur draft. So you could add an example for it. > E.g. =C2=A0Sec-WebSocket-Protocol: sip =C2=A0(is this what you intend to = propose?). > > Also add a section on how SIP as a WebSocket sub protocol is negotiated a= s part of client/server handshake procedure. Hi, AFAIK there is not yet a official registry for WebSocket subprotocols. We could propose it anyway in the draft. We'll address it. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From petithug@acm.org Tue Nov 15 02:25:55 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D8B11E8220 for ; Tue, 15 Nov 2011 02:25:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yV2y-PNqYSj for ; Tue, 15 Nov 2011 02:25:54 -0800 (PST) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 1778A11E81FA for ; Tue, 15 Nov 2011 02:25:54 -0800 (PST) Received: from [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6] (unknown [IPv6:2001:df8:0:64:ca0a:a9ff:fe2e:a4f6]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "petithug", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 9D16120375; Tue, 15 Nov 2011 10:16:11 +0000 (UTC) Message-ID: <4EC23E2A.8090900@acm.org> Date: Tue, 15 Nov 2011 18:25:46 +0800 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <1F2A2C70609D9E41844A2126145FC0982D3F4D40@HKGMBOXPRD22.polycom.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , "Avasarala, Ranjit" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 15 Nov 2011 10:25:55 -0000 On 11/15/2011 06:18 PM, Iñaki Baz Castillo wrote: > 2011/11/15 Avasarala, Ranjit : >> One comment - the proposal of SIP as a new WebSocket sub protocol is not very clear in ur draft. So you could add an example for it. >> E.g. Sec-WebSocket-Protocol: sip (is this what you intend to propose?). >> >> Also add a section on how SIP as a WebSocket sub protocol is negotiated as part of client/server handshake procedure. > > Hi, > > AFAIK there is not yet a official registry for WebSocket subprotocols. > We could propose it anyway in the draft. We'll address it. http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From ibc@aliax.net Tue Nov 15 02:35:33 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C547411E8265 for ; Tue, 15 Nov 2011 02:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=0.038, 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 SzTJBuT7NGDT for ; Tue, 15 Nov 2011 02:35:33 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1EAD911E824E for ; Tue, 15 Nov 2011 02:35:32 -0800 (PST) Received: by vcbfl15 with SMTP id fl15so273133vcb.31 for ; Tue, 15 Nov 2011 02:35:32 -0800 (PST) Received: by 10.52.65.36 with SMTP id u4mr41632438vds.58.1321353332094; Tue, 15 Nov 2011 02:35:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Tue, 15 Nov 2011 02:35:10 -0800 (PST) In-Reply-To: <4EC23E2A.8090900@acm.org> References: <1F2A2C70609D9E41844A2126145FC0982D3F4D40@HKGMBOXPRD22.polycom.com> <4EC23E2A.8090900@acm.org> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 15 Nov 2011 11:35:10 +0100 Message-ID: To: Marc Petit-Huguenin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , "Avasarala, Ranjit" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 15 Nov 2011 10:35:33 -0000 2011/11/15 Marc Petit-Huguenin : > http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name Good news :) Thanks, then we will propose "sip" WebSocke Subprotocol. --=20 I=C3=B1aki Baz Castillo From Ranjit.Avasarala@Polycom.com Tue Nov 15 02:38:50 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE48021F8F97 for ; Tue, 15 Nov 2011 02:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VTzVNv0IgOV for ; Tue, 15 Nov 2011 02:38:50 -0800 (PST) Received: from Hkgehubprd01.polycom.com (hkgehubprd01.polycom.com [140.242.6.225]) by ietfa.amsl.com (Postfix) with ESMTP id EC90721F8F8F for ; Tue, 15 Nov 2011 02:38:49 -0800 (PST) Received: from hkgmboxprd22.polycom.com ([fe80::c4c3:4566:8b3b:ec85]) by Hkgehubprd01.polycom.com ([fe80::5efe:172.21.6.201%12]) with mapi; Tue, 15 Nov 2011 18:38:48 +0800 From: "Avasarala, Ranjit" To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Marc Petit-Huguenin Date: Tue, 15 Nov 2011 18:38:47 +0800 Thread-Topic: [sipcore] Proposal for a new SIP transport (WebSocket) Thread-Index: Acyjgk8RnQAEqfkaRt6FCCCYS7+kRgAAExRw Message-ID: <1F2A2C70609D9E41844A2126145FC0982D3F4D50@HKGMBOXPRD22.polycom.com> References: <1F2A2C70609D9E41844A2126145FC0982D3F4D40@HKGMBOXPRD22.polycom.com> <4EC23E2A.8090900@acm.org> 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 Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 15 Nov 2011 10:38:50 -0000 QWxzbyBhZGQgYSBzZWN0aW9uIG9uIFdlYnNvY2tldCBjbGllbnQvc2VydmVyIGhhbmRzaGFrZSBz byB0aGF0IGl0IGluZGljYXRlcyB0aGF0ICJzaXAiIGlzIG5lZ290aWF0ZWQgYXMgc2lnbmFsaW5n IHByb3RvY29sIG92ZXIgV2ViU29ja2V0cy4gDQoNClJlZ2FyZHMNClJhbmppdA0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBJw7Fha2kgQmF6IENhc3RpbGxvIFttYWlsdG86 aWJjQGFsaWF4Lm5ldF0gDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxMSA0OjA1IFBN DQpUbzogTWFyYyBQZXRpdC1IdWd1ZW5pbg0KQ2M6IEF2YXNhcmFsYSwgUmFuaml0OyBTSVBDT1JF IChTZXNzaW9uIEluaXRpYXRpb24gUHJvdG9jb2wgQ29yZSkgV0cNClN1YmplY3Q6IFJlOiBbc2lw Y29yZV0gUHJvcG9zYWwgZm9yIGEgbmV3IFNJUCB0cmFuc3BvcnQgKFdlYlNvY2tldCkNCg0KMjAx MS8xMS8xNSBNYXJjIFBldGl0LUh1Z3VlbmluIDxwZXRpdGh1Z0BhY20ub3JnPjoNCj4gaHR0cDov L3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy93ZWJzb2NrZXQvd2Vic29ja2V0LnhtbCNzdWJwcm90 b2NvbC1uYW1lDQoNCkdvb2QgbmV3cyA6KQ0KDQpUaGFua3MsIHRoZW4gd2Ugd2lsbCBwcm9wb3Nl ICJzaXAiIFdlYlNvY2tlIFN1YnByb3RvY29sLg0KDQotLSANCknDsWFraSBCYXogQ2FzdGlsbG8N CjxpYmNAYWxpYXgubmV0Pg0K From ibc@aliax.net Tue Nov 15 02:46:33 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B588E21F8FE5 for ; Tue, 15 Nov 2011 02:46:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=0.038, 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 sN6ci3vy3Pe3 for ; Tue, 15 Nov 2011 02:46:33 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1912221F8FE3 for ; Tue, 15 Nov 2011 02:46:33 -0800 (PST) Received: by vcbfl15 with SMTP id fl15so283961vcb.31 for ; Tue, 15 Nov 2011 02:46:32 -0800 (PST) Received: by 10.220.150.204 with SMTP id z12mr2854439vcv.43.1321353992254; Tue, 15 Nov 2011 02:46:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.107.206 with HTTP; Tue, 15 Nov 2011 02:46:11 -0800 (PST) In-Reply-To: <1F2A2C70609D9E41844A2126145FC0982D3F4D50@HKGMBOXPRD22.polycom.com> References: <1F2A2C70609D9E41844A2126145FC0982D3F4D40@HKGMBOXPRD22.polycom.com> <4EC23E2A.8090900@acm.org> <1F2A2C70609D9E41844A2126145FC0982D3F4D50@HKGMBOXPRD22.polycom.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 15 Nov 2011 11:46:11 +0100 Message-ID: To: "Avasarala, Ranjit" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Marc Petit-Huguenin , "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 15 Nov 2011 10:46:33 -0000 2011/11/15 Avasarala, Ranjit : > Also add a section on Websocket client/server handshake so that it indica= tes that "sip" is negotiated as signaling protocol over WebSockets. Sure. Thanks. --=20 I=C3=B1aki Baz Castillo From fluffy@cisco.com Thu Nov 24 05:43:25 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAC4221F8B71 for ; Thu, 24 Nov 2011 05:43:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.496 X-Spam-Level: X-Spam-Status: No, score=-106.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89f+HF-65zrn for ; Thu, 24 Nov 2011 05:43:24 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E684D21F8B42 for ; Thu, 24 Nov 2011 05:43:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=313; q=dns/txt; s=iport; t=1322142205; x=1323351805; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Nb6188VkD2+sWHR2DPHHlMoW1fgHdJvVNH2U+EbjM/E=; b=TCoOSLLrb70zBAF1t6L/L438EiUst3fhDu+z5k7SRtuS1yG+zFjttnGS Bar/boJHcC8X/6o4XrfK1WKuDOkHFvFvg8gKR4QDRLv6AaqSzqOgSd4SK vIvAt3bZEY7UwECVxcqDL6P5NkuEYR3JEPWng2TXHtdqksFb0EYXxKMRG Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJdJzk6rRDoJ/2dsb2JhbABDqnKBBYFyAQEBAwESASc/BQsLRlcGNYdjliwBnk6Jf2MEiCGMKYVAjGs X-IronPort-AV: E=Sophos;i="4.69,565,1315180800"; d="scan'208";a="16085448" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 24 Nov 2011 13:43:24 +0000 Received: from [192.168.4.100] (sjc-fluffy-8914.cisco.com [10.20.249.165]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pAODhOUU025760; Thu, 24 Nov 2011 13:43:24 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: Date: Thu, 24 Nov 2011 06:43:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7B1BA626-7898-45EF-8FCA-785D219AB254@cisco.com> References: To: Victor Pascual Avila X-Mailer: Apple Mail (2.1084) Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 24 Nov 2011 13:43:25 -0000 Be nice if you said a bit more about how this works with DNS SRV and = NAPTR resolution ... On Nov 15, 2011, at 3:02 AM, Victor Pascual Avila wrote: > FYI: We're planning to submit a new revision of the draft (addressing > the feedback received so far) during the next couple of weeks >=20 > -Victor From ibc@aliax.net Thu Nov 24 06:28:00 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4742421F84A5 for ; Thu, 24 Nov 2011 06:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=0.036, 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 3BiXnck15Ilb for ; Thu, 24 Nov 2011 06:27:59 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B3C9021F84A4 for ; Thu, 24 Nov 2011 06:27:59 -0800 (PST) Received: by vbbez10 with SMTP id ez10so2771160vbb.31 for ; Thu, 24 Nov 2011 06:27:59 -0800 (PST) Received: by 10.52.93.146 with SMTP id cu18mr30308308vdb.56.1322144879132; Thu, 24 Nov 2011 06:27:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.159.132 with HTTP; Thu, 24 Nov 2011 06:27:38 -0800 (PST) In-Reply-To: <7B1BA626-7898-45EF-8FCA-785D219AB254@cisco.com> References: <7B1BA626-7898-45EF-8FCA-785D219AB254@cisco.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 24 Nov 2011 15:27:38 +0100 Message-ID: To: Cullen Jennings Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 24 Nov 2011 14:28:00 -0000 2011/11/24 Cullen Jennings : > Be nice if you said a bit more about how this works with DNS SRV and NAPT= R resolution ... Hi Cullen, NAPTR and SRV is addressed in the new revision of the draft which will be submitted soon. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Sat Nov 26 06:52:09 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD2121F8B5D for ; Sat, 26 Nov 2011 06:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7JQZTsQmo+u for ; Sat, 26 Nov 2011 06:52:08 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 59D3B21F8B20 for ; Sat, 26 Nov 2011 06:52:08 -0800 (PST) X-AuditID: c1b4fb3d-b7b5fae00000219a-c4-4ed0fd17574f Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 0D.24.08602.71DF0DE4; Sat, 26 Nov 2011 15:52:07 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.20]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Sat, 26 Nov 2011 15:52:07 +0100 From: Christer Holmberg To: "sipcore@ietf.org Core) WG" Date: Sat, 26 Nov 2011 15:52:06 +0100 Thread-Topic: Proxy-Feature: Requirement changes based on Robert's comments (IETF#81) Thread-Index: AcysSveAnXAz0KoTRkeTgEFHovL/gQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C3A87DFF5@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_7F2072F1E0DE894DA4B517B93C6A05852C3A87DFF5ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Proxy-Feature: Requirement changes based on Robert's comments (IETF#81) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 26 Nov 2011 14:52:09 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3A87DFF5ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on Robert's comments on the proxy feature requirements in Taipei, thi= s e-mail describes suggested modifications. If people are ok with the suggested modifications I will submit a new versi= on of the requirements draft. Regards, Christer ------------ - Comment that REQ-10 should talk about having access to the information, r= ather than talking specifically about making routing decisions: I suggest a modification of REQ-10: OLD: REQ-10: Other SIP entities MUST be able to make routing decisions based on received feature/capability support indications. NEW: REQ-10: Other SIP entities MUST be able to retrieve the feature/capability support indications received in a SIP message. ------------ - Comment regarding the fact that requirements REQ-8 and REQ-9 seem to be i= dentical: Actually, they are not identical. REQ-8 talks about the case when an entity= receives an indication that it doesn't support, while REQ-9 talks about th= e case where an entity that doesn't even support the mechanism receives an = indication. So, my suggestion is that we keep both requirements. But, If you think it helps, I could modify REQ-8 in the following way: "REQ-8: If a SIP entity that supports the proxy feature/ capability indication mechanism receives a feature support indication that it does not understand, it MUST act as if it hadn't received the indication." ------------ - Comment regarding the fact that we don't have a requirement saying that a= proxy indicating support of a feature/capability associated with a dialog = must be part of the signaling path of that dialog. I suggest the following new requirement: REQ-XX: A SIP proxy that indicates support of a feature/capability associat= ed with a dialog MUST be part of the signaling path of that dialog. ------------ --_000_7F2072F1E0DE894DA4B517B93C6A05852C3A87DFF5ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
Based on Robert's comments on the proxy feature requi= rements in Taipei, this e-mail describes suggested modifications.
 
If people are ok with the suggested modifications I w= ill submit a new version of the requirements draft.
 
Regards,
 
Christer
 
------------
 
- Comment that REQ-10 should talk about having access= to the information, rather than talking specifically about making routing = decisions:
 
I suggest a modification of REQ-10:
 
 
OLD:
 
        REQ-10: Ot= her SIP entities MUST be able to make routing
        decisions = based on received feature/capability support
         indi= cations.
 
NEW:
 
         REQ-= 10: Other SIP entities MUST be able to retrieve the
        feature/ca= pability support indications received in a SIP
        message.
 
 
------------
 
 
- Comment regarding the fact that requirements REQ-8 = and REQ-9 seem to be identical:
 
Actually, they are not identical. REQ-8 talks about t= he case when an entity receives an indication that it doesn't support, whil= e REQ-9 talks about the case where an entity that doesn't even support the = mechanism receives an indication.
 
So, my suggestion is that we keep both requirements.<= /font>
 
But, If you think it helps, I could modify REQ-8 in t= he following way:
 
         &quo= t;REQ-8: If a SIP entity <new> that supports the proxy feature/
         capa= bility indication mechanism </new> receives a feature support =
        indication= that it does not understand, it MUST act as if it hadn't
        received t= he indication."
 
 
------------
 
 
- Comment regarding the fact that we don't have a req= uirement saying that a proxy indicating support of a feature/capability ass= ociated with a dialog must be part of the signaling path of that dialog.
 
I suggest the following new requirement:
 
REQ-XX: A SIP proxy that indicates support of a featu= re/capability associated with a dialog MUST be part of the signaling path o= f that dialog.
 
 
------------
 
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A05852C3A87DFF5ESESSCMS0356e_-- From ibc@aliax.net Sun Nov 27 05:07:33 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F1721F8A71 for ; Sun, 27 Nov 2011 05:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=0.036, 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 qEizFz7fX2+v for ; Sun, 27 Nov 2011 05:07:32 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id F300121F8A35 for ; Sun, 27 Nov 2011 05:07:31 -0800 (PST) Received: by vbbez10 with SMTP id ez10so4576790vbb.31 for ; Sun, 27 Nov 2011 05:07:30 -0800 (PST) Received: by 10.52.186.225 with SMTP id fn1mr7980187vdc.32.1322399248033; Sun, 27 Nov 2011 05:07:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.1.82 with HTTP; Sun, 27 Nov 2011 05:07:05 -0800 (PST) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sun, 27 Nov 2011 14:07:05 +0100 Message-ID: To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [sipcore] New Version Notification for draft-ibc-sipcore-sip-websocket-00 (previously draft-ibc-rtcweb-sip-websocket-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: Sun, 27 Nov 2011 13:07:33 -0000 A new version of I-D, draft-ibc-sipcore-sip-websocket-00.txt has been successfully submitted by I=C3=B1aki Baz Castillo and posted to the IETF repository. Filename: draft-ibc-sipcore-sip-websocket Revision: 00 Title: The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) Creation date: 2011-11-24 WG ID: Individual Submission Number of pages: 27 Abstract: This document specifies a WebSocket Sub-Protocol for a new transport in SIP (Session Initiation Protocol). The WebSocket protocol enables two-way realtime communication between clients and servers. http://www.ietf.org/id/draft-ibc-sipcore-sip-websocket-00.txt http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-00 This draft is a new revision of the previously named draft-ibc-rtcweb-sip-websocket-00. Summary of main changes in this revision: - WebSocket background provided. - Scope not limited to web-browsers. - Outbound and GRUU usage described. - DNS NAPTR/SRV considerations included. - Added some clarifications and bug fixing. As usual, your comments are most appreciated. --=20 I=C3=B1aki Baz Castillo From rbarnes@bbn.com Sun Nov 27 15:40:24 2011 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D4821F8CB8 for ; Sun, 27 Nov 2011 15:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yY5rvD76fg5q for ; Sun, 27 Nov 2011 15:40:24 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id EAAAE21F8CAA for ; Sun, 27 Nov 2011 15:40:23 -0800 (PST) Received: from [128.89.255.1] (port=52351 helo=[192.168.1.4]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RUoKb-000KaP-RP; Sun, 27 Nov 2011 18:40:21 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <7B1BA626-7898-45EF-8FCA-785D219AB254@cisco.com> Date: Sun, 27 Nov 2011 18:40:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <82D94CA8-694C-436C-8252-3C9F9D9E8F9C@bbn.com> References: <7B1BA626-7898-45EF-8FCA-785D219AB254@cisco.com> To: Cullen Jennings X-Mailer: Apple Mail (2.1084) Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Proposal for a new SIP transport (WebSocket) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 27 Nov 2011 23:40:24 -0000 http://jsondns.org/ On Nov 24, 2011, at 8:43 AM, Cullen Jennings wrote: >=20 > Be nice if you said a bit more about how this works with DNS SRV and = NAPTR resolution ... >=20 > On Nov 15, 2011, at 3:02 AM, Victor Pascual Avila wrote: >=20 >> FYI: We're planning to submit a new revision of the draft (addressing >> the feedback received so far) during the next couple of weeks >>=20 >> -Victor >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore