From R.Jesske@telekom.de Thu Mar 1 01:08:38 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689A821F8673 for ; Thu, 1 Mar 2012 01:08:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 n0YbgSQY11YK for ; Thu, 1 Mar 2012 01:08:37 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4E09821F866B for ; Thu, 1 Mar 2012 01:08:37 -0800 (PST) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 01 Mar 2012 10:08:35 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.9]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Thu, 1 Mar 2012 10:08:35 +0100 From: To: Date: Thu, 1 Mar 2012 10:08:34 +0100 Thread-Topic: AW: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft Thread-Index: Acz2InAoq0Vej7i7QY+fRnhvO5h/sgBZeueA Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D13A0024395@HE111648.emea1.cds.t-internal.com> References: <4F4BC754.4030606@alum.mit.edu> <79C4240C13B4C84B910850B96B1B431203D9FBE3@DEMUEXC035.nsn-intra.net> <580BEA5E3B99744AB1F5BFF5E9A3C67D139F8611B2@HE111648.emea1.cds.t-internal.com> <4F4CDFD5.2030208@alum.mit.edu> In-Reply-To: <4F4CDFD5.2030208@alum.mit.edu> Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sipcore@ietf.org Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 01 Mar 2012 09:08:38 -0000 Hi Paul, Due to the fact that I got only the *STRONG SUPPORT* feedback from my deplo= yment guys looking on draft-holmberg-sipcore-proxy-feature and the related= use cases. I unfortunately cannot give more details at this point, but I t= hink there will be a general use. My goal is not use proprietary feature tags. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Gesendet: Dienstag, 28. Februar 2012 15:08 An: Jesske, Roland Cc: peter.leis@nsn.com; sipcore@ietf.org Betreff: Re: AW: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature= as a wgdraft On 2/28/12 8:06 AM, R.Jesske@telekom.de wrote: > Not only from 3GPP work also seen form our own use cases I fully support = the adoption of the draft as wg document. Since many of us have struggled to understand the uses of this mechanism, = it would be great if those of you who have uses would describe them. Are the uses you see ones that would have proprietary feature tags? Or are = they of general use that should have a public tag? Thanks, Paul > Roland > > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im > Auftrag von Leis, Peter (NSN - DE/Munich) > Gesendet: Dienstag, 28. Februar 2012 09:24 > An: ext Paul Kyzivat; SIPCORE > Betreff: Re: [sipcore] Adoption of > draft-holmberg-sipcore-proxy-feature as a wgdraft > > Hello, > > working in 3GPP IMS area, where we need this mechanism, I support adoptin= g the draft as wg document. > > Peter > > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of ext Paul Kyzivat > Sent: Monday, February 27, 2012 7:12 PM > To: SIPCORE > Subject: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as > a wgdraft > > SIPCORE group: > > There has been general agreement on the proxy-feature requirements, so > now we have a basis to work on a corresponding mechanism. Robert has > agreed that sipcore is the proper place to do this work. The document > draft-holmberg-sipcore-proxy-feature-04 has been proposed as a mechanism. > > I am requesting that discussion begin, on the sipcore list, on the suitab= ility of this draft as a basis for a wg mechanism document that will meet t= he requirements expressed in draft-ietf-sipcore-proxy-feature-reqs-03.txt. > > One issue that remains fuzzy is distinguishing what is and is not a valid= proxy-feature. We have a few examples from the use cases, but little clari= ty beyond that on any guidelines for what would qualify and what would not.= However it seems likely that few, if any, of the existing defined feature = tags (even those in the sip tree) would be appropriate. > > So one thing I will be looking for in the mechanism before it is > finalized is a way to resolve this. This might be a set of criteria > that > > can be applied to any new candidate proxy-feature. Or if that proves impo= ssible to define, then we can fall back on requiring standards action for a= feature to be defined. So I encourage discussion of this issue. > > (Currently the draft proposes to build on RFC 3840 and its use of the > feature-tag definition mechanisms specified in RFC 2506. That > registration mechanism has multiple categories of features with > differing approval mechanisms for each category. Some require an RFC, > some expert review, and some no approval at all. Whether this can be > made to work for proxy-features remains to be seen.) > > Thanks, > Paul (as co-chair) > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From Peter.Dawes@vodafone.com Thu Mar 1 08:27:44 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3905721E8229 for ; Thu, 1 Mar 2012 08:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 q5H2i3Pv5-S6 for ; Thu, 1 Mar 2012 08:27:43 -0800 (PST) Received: from mailout01.vodafone.com (mailout01.vodafone.com [195.232.224.70]) by ietfa.amsl.com (Postfix) with ESMTP id D902821E80DF for ; Thu, 1 Mar 2012 08:27:42 -0800 (PST) Received: from mailint01 (localhost [127.0.0.1]) by mailout01 (Postfix) with ESMTP id 54A224797 for ; Thu, 1 Mar 2012 17:27:41 +0100 (CET) Received: from avoexs01.internal.vodafone.com (unknown [145.230.4.134]) by mailint01 (Postfix) with ESMTP id 486114653; Thu, 1 Mar 2012 17:27:41 +0100 (CET) Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs01.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 1 Mar 2012 17:27:15 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 1 Mar 2012 17:27:12 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [sipcore] Adoption of draft-holmberg-sipcore-proxy-featureas a wgdraft Thread-Index: Acz2InAoq0Vej7i7QY+fRnhvO5h/sgBZeueAAA89cyA= From: "Dawes, Peter, VF-Group" To: X-OriginalArrivalTime: 01 Mar 2012 16:27:15.0198 (UTC) FILETIME=[29B269E0:01CCF7C8] Cc: sipcore@ietf.org Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 01 Mar 2012 16:27:44 -0000 Hi Paul, All, I support wg adoption of the proxy-feature draft as this kind of = solution is needed to allow a network to do the things described in = draft-ietf-sipcore-proxy-feature-reqs-03.txt.=20 On the question " Since many of us have struggled to understand the = uses of this mechanism, it would be great if those of you who have uses = would describe them." do you believe that what is needed is more use = cases than those listed in the reqs draft, or a more general idea of the = value of a SIP "feature node" indicating its capabilities to other SIP = entities, or something else? For me, the use cases in the reqs are = sufficient reason to work on the draft. On the question " One issue that remains fuzzy is distinguishing what is = and is not a valid proxy-feature", is the purpose of discussing this = validity to define the requirements and procedure for registering such = proxy-features with IANA or is it more than that?=20 Regards, Peter=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf Of R.Jesske@telekom.de Sent: 01 March 2012 09:09 To: pkyzivat@alum.mit.edu Cc: sipcore@ietf.org Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature = as a wgdraft Hi Paul, Due to the fact that I got only the *STRONG SUPPORT* feedback from my = deployment guys looking on draft-holmberg-sipcore-proxy-feature and the = related use cases. I unfortunately cannot give more details at this = point, but I think there will be a general use. My goal is not use proprietary feature tags. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Gesendet: Dienstag, 28. Februar 2012 15:08 An: Jesske, Roland Cc: peter.leis@nsn.com; sipcore@ietf.org Betreff: Re: AW: [sipcore] Adoption of = draft-holmberg-sipcore-proxy-feature as a wgdraft On 2/28/12 8:06 AM, R.Jesske@telekom.de wrote: > Not only from 3GPP work also seen form our own use cases I fully = support the adoption of the draft as wg document. Since many of us have struggled to understand the uses of this = mechanism, it would be great if those of you who have uses would = describe them. Are the uses you see ones that would have proprietary feature tags? Or = are they of general use that should have a public tag? Thanks, Paul > Roland > > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im=20 > Auftrag von Leis, Peter (NSN - DE/Munich) > Gesendet: Dienstag, 28. Februar 2012 09:24 > An: ext Paul Kyzivat; SIPCORE > Betreff: Re: [sipcore] Adoption of > draft-holmberg-sipcore-proxy-feature as a wgdraft > > Hello, > > working in 3GPP IMS area, where we need this mechanism, I support = adopting the draft as wg document. > > Peter > > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of ext Paul Kyzivat > Sent: Monday, February 27, 2012 7:12 PM > To: SIPCORE > Subject: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as = > a wgdraft > > SIPCORE group: > > There has been general agreement on the proxy-feature requirements, so = > now we have a basis to work on a corresponding mechanism. Robert has=20 > agreed that sipcore is the proper place to do this work. The document > draft-holmberg-sipcore-proxy-feature-04 has been proposed as a = mechanism. > > I am requesting that discussion begin, on the sipcore list, on the = suitability of this draft as a basis for a wg mechanism document that = will meet the requirements expressed in = draft-ietf-sipcore-proxy-feature-reqs-03.txt. > > One issue that remains fuzzy is distinguishing what is and is not a = valid proxy-feature. We have a few examples from the use cases, but = little clarity beyond that on any guidelines for what would qualify and = what would not. However it seems likely that few, if any, of the = existing defined feature tags (even those in the sip tree) would be = appropriate. > > So one thing I will be looking for in the mechanism before it is=20 > finalized is a way to resolve this. This might be a set of criteria=20 > that > > can be applied to any new candidate proxy-feature. Or if that proves = impossible to define, then we can fall back on requiring standards = action for a feature to be defined. So I encourage discussion of this = issue. > > (Currently the draft proposes to build on RFC 3840 and its use of the=20 > feature-tag definition mechanisms specified in RFC 2506. That=20 > registration mechanism has multiple categories of features with=20 > differing approval mechanisms for each category. Some require an RFC,=20 > some expert review, and some no approval at all. Whether this can be=20 > made to work for proxy-features remains to be seen.) > > Thanks, > Paul (as co-chair) > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Thu Mar 1 09:58:34 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C43A21E80F9 for ; Thu, 1 Mar 2012 09:58:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 pdvQWH5ChY1D for ; Thu, 1 Mar 2012 09:58:33 -0800 (PST) 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 82EA921E80DA for ; Thu, 1 Mar 2012 09:58:33 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id gFGr1i00E1ap0As55HyZtR; Thu, 01 Mar 2012 17:58:33 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id gHyZ1i00o07duvL3iHyZ2y; Thu, 01 Mar 2012 17:58:33 +0000 Message-ID: <4F4FB8C8.9080605@alum.mit.edu> Date: Thu, 01 Mar 2012 12:58:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: R.Jesske@telekom.de References: <4F4BC754.4030606@alum.mit.edu> <79C4240C13B4C84B910850B96B1B431203D9FBE3@DEMUEXC035.nsn-intra.net> <580BEA5E3B99744AB1F5BFF5E9A3C67D139F8611B2@HE111648.emea1.cds.t-internal.com> <4F4CDFD5.2030208@alum.mit.edu> <580BEA5E3B99744AB1F5BFF5E9A3C67D13A0024395@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D13A0024395@HE111648.emea1.cds.t-internal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 01 Mar 2012 17:58:34 -0000 On 3/1/12 4:08 AM, R.Jesske@telekom.de wrote: > Hi Paul, > Due to the fact that I got only the *STRONG SUPPORT* feedback from my deployment guys looking on draft-holmberg-sipcore-proxy-feature and the related use cases. I unfortunately cannot give more details at this point, but I think there will be a general use. > My goal is not use proprietary feature tags. Roland, I was keying off your statement: > Not only from 3GPP work also seen form our own use cases I fully support the adoption of the draft as wg document. That seems to say you had some use cases other than the 3GPP ones. But there are no feature tags defined for this use other than ones defined by 3GPP. So I guess they would either be proprietary or else would be new ones that you think will be standardized. That is what I was looking for. Thanks, Paul > Best Regards > > Roland > > -----Urspr�ngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Gesendet: Dienstag, 28. Februar 2012 15:08 > An: Jesske, Roland > Cc: peter.leis@nsn.com; sipcore@ietf.org > Betreff: Re: AW: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft > > On 2/28/12 8:06 AM, R.Jesske@telekom.de wrote: >> Not only from 3GPP work also seen form our own use cases I fully support the adoption of the draft as wg document. > > Since many of us have struggled to understand the uses of this mechanism, it would be great if those of you who have uses would describe them. > > Are the uses you see ones that would have proprietary feature tags? Or are they of general use that should have a public tag? > > Thanks, > Paul > >> Roland >> >> -----Urspr�ngliche Nachricht----- >> Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im >> Auftrag von Leis, Peter (NSN - DE/Munich) >> Gesendet: Dienstag, 28. Februar 2012 09:24 >> An: ext Paul Kyzivat; SIPCORE >> Betreff: Re: [sipcore] Adoption of >> draft-holmberg-sipcore-proxy-feature as a wgdraft >> >> Hello, >> >> working in 3GPP IMS area, where we need this mechanism, I support adopting the draft as wg document. >> >> Peter >> >> >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of ext Paul Kyzivat >> Sent: Monday, February 27, 2012 7:12 PM >> To: SIPCORE >> Subject: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as >> a wgdraft >> >> SIPCORE group: >> >> There has been general agreement on the proxy-feature requirements, so >> now we have a basis to work on a corresponding mechanism. Robert has >> agreed that sipcore is the proper place to do this work. The document >> draft-holmberg-sipcore-proxy-feature-04 has been proposed as a mechanism. >> >> I am requesting that discussion begin, on the sipcore list, on the suitability of this draft as a basis for a wg mechanism document that will meet the requirements expressed in draft-ietf-sipcore-proxy-feature-reqs-03.txt. >> >> One issue that remains fuzzy is distinguishing what is and is not a valid proxy-feature. We have a few examples from the use cases, but little clarity beyond that on any guidelines for what would qualify and what would not. However it seems likely that few, if any, of the existing defined feature tags (even those in the sip tree) would be appropriate. >> >> So one thing I will be looking for in the mechanism before it is >> finalized is a way to resolve this. This might be a set of criteria >> that >> >> can be applied to any new candidate proxy-feature. Or if that proves impossible to define, then we can fall back on requiring standards action for a feature to be defined. So I encourage discussion of this issue. >> >> (Currently the draft proposes to build on RFC 3840 and its use of the >> feature-tag definition mechanisms specified in RFC 2506. That >> registration mechanism has multiple categories of features with >> differing approval mechanisms for each category. Some require an RFC, >> some expert review, and some no approval at all. Whether this can be >> made to work for proxy-features remains to be seen.) >> >> Thanks, >> Paul (as co-chair) >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > From pkyzivat@alum.mit.edu Fri Mar 2 09:07:59 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15D321F86E0 for ; Fri, 2 Mar 2012 09:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 o2oi+viUBghm for ; Fri, 2 Mar 2012 09:07:59 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id BA3C021F86DF for ; Fri, 2 Mar 2012 09:07:58 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA11.westchester.pa.mail.comcast.net with comcast id ggz21i0050EZKEL5Bh7zog; Fri, 02 Mar 2012 17:07:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta01.westchester.pa.mail.comcast.net with comcast id gh7y1i01107duvL3Mh7ybb; Fri, 02 Mar 2012 17:07:59 +0000 Message-ID: <4F50FE6D.6050501@alum.mit.edu> Date: Fri, 02 Mar 2012 12:07:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Dawes, Peter, VF-Group" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 02 Mar 2012 17:07:59 -0000 On 3/1/12 11:27 AM, Dawes, Peter, VF-Group wrote: > Hi Paul, All, > I support wg adoption of the proxy-feature draft as this kind of solution is needed to allow a network to do the things described in draft-ietf-sipcore-proxy-feature-reqs-03.txt. > > On the question " Since many of us have struggled to understand the uses of this mechanism, it would be great if those of you who have uses would describe them." do you believe that what is needed is more use cases than those listed in the reqs draft, or a more general idea of the value of a SIP "feature node" indicating its capabilities to other SIP entities, or something else? For me, the use cases in the reqs are sufficient reason to work on the draft. I think it would be useful to have both more use cases (some that the rest of us can relate to), *and* more general explanation of what it means for a non-endpoint to have a feature that others need to know about. I am not saying that this can't proceed without that, but it will be more difficult, and without that we might end up with a draft that is understood and supported only by those building for IMS. > On the question " One issue that remains fuzzy is distinguishing what is and is not a valid proxy-feature", is the purpose of discussing this validity to define the requirements and procedure for registering such proxy-features with IANA or is it more than that? That is the reason I ask. And of course it is related to the second part of your prior comment. Lacking a clear definition to distinguish valid proxy-features from invalid ones, I can't imagine approving any registration mechanism other than standards-action. (Standards-action follows the approach of "I can't define it but I know it when I see it". Or you could say that it "crowd-sources" the decision.) Thanks, Paul > Regards, > Peter > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of R.Jesske@telekom.de > Sent: 01 March 2012 09:09 > To: pkyzivat@alum.mit.edu > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft > > Hi Paul, > Due to the fact that I got only the *STRONG SUPPORT* feedback from my deployment guys looking on draft-holmberg-sipcore-proxy-feature and the related use cases. I unfortunately cannot give more details at this point, but I think there will be a general use. > My goal is not use proprietary feature tags. > > Best Regards > > Roland > > -----Urspr�ngliche Nachricht----- > Von: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Gesendet: Dienstag, 28. Februar 2012 15:08 > An: Jesske, Roland > Cc: peter.leis@nsn.com; sipcore@ietf.org > Betreff: Re: AW: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft > > On 2/28/12 8:06 AM, R.Jesske@telekom.de wrote: >> Not only from 3GPP work also seen form our own use cases I fully support the adoption of the draft as wg document. > > Since many of us have struggled to understand the uses of this mechanism, it would be great if those of you who have uses would describe them. > > Are the uses you see ones that would have proprietary feature tags? Or are they of general use that should have a public tag? > > Thanks, > Paul > >> Roland >> >> -----Urspr�ngliche Nachricht----- >> Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im >> Auftrag von Leis, Peter (NSN - DE/Munich) >> Gesendet: Dienstag, 28. Februar 2012 09:24 >> An: ext Paul Kyzivat; SIPCORE >> Betreff: Re: [sipcore] Adoption of >> draft-holmberg-sipcore-proxy-feature as a wgdraft >> >> Hello, >> >> working in 3GPP IMS area, where we need this mechanism, I support adopting the draft as wg document. >> >> Peter >> >> >> >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of ext Paul Kyzivat >> Sent: Monday, February 27, 2012 7:12 PM >> To: SIPCORE >> Subject: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as >> a wgdraft >> >> SIPCORE group: >> >> There has been general agreement on the proxy-feature requirements, so >> now we have a basis to work on a corresponding mechanism. Robert has >> agreed that sipcore is the proper place to do this work. The document >> draft-holmberg-sipcore-proxy-feature-04 has been proposed as a mechanism. >> >> I am requesting that discussion begin, on the sipcore list, on the suitability of this draft as a basis for a wg mechanism document that will meet the requirements expressed in draft-ietf-sipcore-proxy-feature-reqs-03.txt. >> >> One issue that remains fuzzy is distinguishing what is and is not a valid proxy-feature. We have a few examples from the use cases, but little clarity beyond that on any guidelines for what would qualify and what would not. However it seems likely that few, if any, of the existing defined feature tags (even those in the sip tree) would be appropriate. >> >> So one thing I will be looking for in the mechanism before it is >> finalized is a way to resolve this. This might be a set of criteria >> that >> >> can be applied to any new candidate proxy-feature. Or if that proves impossible to define, then we can fall back on requiring standards action for a feature to be defined. So I encourage discussion of this issue. >> >> (Currently the draft proposes to build on RFC 3840 and its use of the >> feature-tag definition mechanisms specified in RFC 2506. That >> registration mechanism has multiple categories of features with >> differing approval mechanisms for each category. Some require an RFC, >> some expert review, and some no approval at all. Whether this can be >> made to work for proxy-features remains to be seen.) >> >> Thanks, >> Paul (as co-chair) >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From internet-drafts@ietf.org Fri Mar 2 10:39:06 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DB8621E8045; Fri, 2 Mar 2012 10:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mjwOf6KDXTd; Fri, 2 Mar 2012 10:39:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74B6E21F857A; Fri, 2 Mar 2012 10:39:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120302183905.29117.36588.idtracker@ietfa.amsl.com> Date: Fri, 02 Mar 2012 10:39:05 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-proxy-feature-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 18:39:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Work= ing Group of the IETF. Title : Indication of features supported by proxy Author(s) : Christer Holmberg Ivo Sedlacek Hadriel Kaplan Filename : draft-ietf-sipcore-proxy-feature-00.txt Pages : 12 Date : 2012-02-29 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 represent the SIP entity that wants to indicate support of its features and capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-proxy-feature-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sipcore-proxy-feature-00.txt From glavers@cisco.com Mon Mar 5 13:37:10 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0BB21F8817 for ; Mon, 5 Mar 2012 13:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwUucB9ZQAUQ for ; Mon, 5 Mar 2012 13:37:09 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 112A721F876F for ; Mon, 5 Mar 2012 13:36:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=glavers@cisco.com; l=370; q=dns/txt; s=iport; t=1330983414; x=1332193014; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=1RozZIH+voSZ8l2nieD2bc65w0Ul3AmAp+lKJwuklsc=; b=A6R0jGYKCFfag6cJ/anC5BspN+/VhKaUIuqv5af5ptaRcZKqTvKLqyvU cXXmBgCKv+z7zhEW4jEUHhGM2wocgPysMn70woNcOh+iuJrTHvROI/r78 RcWRay08qK8vJDi+MRkS2dIdWOwQ221BtZsgP7W37Xd0ooCWTTeuHS/ac Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAO8wVU+rRDoJ/2dsb2JhbABDhTSuOXqBB4F/AQQSARANBEUSASICBgYYAgIDAVYBBBsah2QBC5lGAYxlkguBL4t+ggwzYwSIUJ0AgwQ X-IronPort-AV: E=Sophos;i="4.73,536,1325462400"; d="scan'208";a="34654776" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 05 Mar 2012 21:36:53 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q25Lar9N006517; Mon, 5 Mar 2012 21:36:53 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 13:36:53 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Mon, 5 Mar 2012 13:36:52 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Acz7CV1x2e1m2Jd5QsqIDVqUw6Sf9Q== From: "Glen Lavers (glavers)" To: X-OriginalArrivalTime: 05 Mar 2012 21:36:53.0857 (UTC) FILETIME=[1517CD10:01CCFB18] X-Mailman-Approved-At: Mon, 05 Mar 2012 13:49:28 -0800 Cc: paulej@packetizer.com, "Gonzalo Salgueiro \(gsalguei\)" Subject: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:37:10 -0000 Rm9sa3MsDQpJIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IHRvIGRlZmluZSBhbiAnaW1tZXJz aXZlJyBtZWRpYSBmZWF0dXJlIHRhZy4gVGhlIGRyYWZ0IGlzIHBvc3RlZCBhdDogaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGF2ZXJzLXNpcGNvcmUtaW1tZXJzaXZlLWNhcGFiaWxp dHkgDQoNClRoZSBhdXRob3JzIHdvdWxkIGFwcHJlY2lhdGUgZmVlZGJhY2sgIGFuZCBvciBkZXRh aWxlZCBjb21tZW50cy4gDQoNCk1hbnkgdGhhbmtzLA0KR2xlbiANCg== From glavers@cisco.com Tue Mar 6 15:47:16 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5483D21F85B1 for ; Tue, 6 Mar 2012 15:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0eyKlucAkXw for ; Tue, 6 Mar 2012 15:47:15 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 819FD21E800F for ; Tue, 6 Mar 2012 15:47:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=glavers@cisco.com; l=818; q=dns/txt; s=iport; t=1331077635; x=1332287235; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=qNc3aVMt//fMVFVSFpIYL3mUXFPKR9NIrYHh5KpES10=; b=AHEo8fwF+e+s410nhuQNtJEf8HbH+rpNVSVoP0sRg1A4zjESv2FN+Xc9 QTZl7klaxsmi76v42EdM8jscp36sxBfsfgRaIEkUp8QlKw4J0p8MVauuF 1M+Z12Qmm/ilF/g+9tSCWXHBv5U0TTpTm7j6p8mJTdrGglTc92q1oLujH Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOGgVk+rRDoH/2dsb2JhbABDhTSuTn+BB4F9AQEBBBIBEA0ERQwGAQgRBAEBAwIGBhgCAgMBTQkBBBMIGodkAQuaPwGMZ5IrgS+MH4IMM2MEiFKdA4ME X-IronPort-AV: E=Sophos;i="4.73,542,1325462400"; d="scan'208";a="34740226" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 06 Mar 2012 23:47:15 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q26NlFuL000431; Tue, 6 Mar 2012 23:47:15 GMT Received: from xmb-sjc-236.amer.cisco.com ([128.107.191.121]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Mar 2012 15:47:15 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 6 Mar 2012 15:47:14 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-lavers-sipcore-immersive-capability-00.txt Thread-Index: Acz7CV1x2e1m2Jd5QsqIDVqUw6Sf9QA6f8uw From: "Glen Lavers (glavers)" To: X-OriginalArrivalTime: 06 Mar 2012 23:47:15.0217 (UTC) FILETIME=[75666010:01CCFBF3] Cc: paulej@packetizer.com, "Gonzalo Salgueiro \(gsalguei\)" Subject: Re: [sipcore] draft-lavers-sipcore-immersive-capability-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 23:47:16 -0000 TW92ZWQgdGhpcyB0byBkaXNwYXRjaCB0byBkaXNjdXNzIHRoZXJlLg0KQ2hlZXJzLA0KZ2xlbg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEdsZW4gTGF2ZXJzIChnbGF2 ZXJzKQ0KPiBTZW50OiBNb25kYXksIE1hcmNoIDA1LCAyMDEyIDE6MzcgUE0NCj4gVG86ICdzaXBj b3JlQGlldGYub3JnJw0KPiBDYzogcGF1bGVqQHBhY2tldGl6ZXIuY29tOyBHb256YWxvIFNhbGd1 ZWlybyAoZ3NhbGd1ZWkpDQo+IFN1YmplY3Q6IGRyYWZ0LWxhdmVycy1zaXBjb3JlLWltbWVyc2l2 ZS1jYXBhYmlsaXR5LTAwLnR4dA0KPiANCj4gRm9sa3MsDQo+IEkgaGF2ZSBzdWJtaXR0ZWQgYSBu ZXcgZHJhZnQgdG8gZGVmaW5lIGFuICdpbW1lcnNpdmUnIG1lZGlhIGZlYXR1cmUgdGFnLiBUaGUN Cj4gZHJhZnQgaXMgcG9zdGVkIGF0OiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1s YXZlcnMtc2lwY29yZS1pbW1lcnNpdmUtDQo+IGNhcGFiaWxpdHkNCj4gDQo+IFRoZSBhdXRob3Jz IHdvdWxkIGFwcHJlY2lhdGUgZmVlZGJhY2sgIGFuZCBvciBkZXRhaWxlZCBjb21tZW50cy4NCj4g DQo+IE1hbnkgdGhhbmtzLA0KPiBHbGVuDQo= From dean.willis@softarmor.com Wed Mar 7 22:07:33 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD0921F862B for ; Wed, 7 Mar 2012 22:07:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMFqFh3i+Ld6 for ; Wed, 7 Mar 2012 22:07:32 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 01D7421F8629 for ; Wed, 7 Mar 2012 22:07:31 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so1303127pbb.31 for ; Wed, 07 Mar 2012 22:07:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=softarmor.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aA7d+Wi4llQPwg24kH1kuPgjdlAL6fGahO6ZL+ot364=; b=Z3XiaajKj2EO7EjC/gLqHErIvjuxYQk2pCL720GchvW9GGrhtbXxJk3GBDTehmP0aC 34khtyJ7kzfK5zKzzw3L1VcwM/+zUGcfHReV0O9LktDtrkbIZr+nXljV3RLY82Ca3LtR wT5KT108jgMS3B3r+gv2XGU1W3Aw5z7lm5/sY= MIME-Version: 1.0 Received: by 10.68.130.72 with SMTP id oc8mr7444141pbb.115.1331186851446; Wed, 07 Mar 2012 22:07:31 -0800 (PST) Received: by 10.68.9.104 with HTTP; Wed, 7 Mar 2012 22:07:31 -0800 (PST) In-Reply-To: <4F4BC6F5.4040101@alum.mit.edu> References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com> <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> <4F459082.2040402@alum.mit.edu> <01d601ccf3d5$37710880$a6531980$@us> <4F4987A7.5080804@alum.mit.edu> <002a01ccf4c6$60bd1c50$223754f0$@us> <4F4BC6F5.4040101@alum.mit.edu> Date: Thu, 8 Mar 2012 00:07:31 -0600 Message-ID: From: Dean Willis To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b10d07d69016004bab51742 X-Gm-Message-State: ALoCoQnh2+waCaROOxRfQY03GFTvpdBLpjtwrX60g6vRJUL/GamS3pIG0cw+8/VWAOys9mqyFNrG Cc: SIPCORE Subject: Re: [sipcore] Legal controls over sip signaling X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 08 Mar 2012 06:07:33 -0000 --047d7b10d07d69016004bab51742 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Feb 27, 2012 at 12:09 PM, Paul Kyzivat wrote: > > > I don't understand how a legal restriction would work. > > Did you understand how SOPA and PIPA would work? Me neither. But that wasn't enough to stop Congress. Fortunately, Congress does understand mass protests. It's easy to envision laws banning one's "unauthorized signaling implementation." Easy to enforce, too -- just add an App Store check for unauthorized signaling. After all, pretty soon the computer you "use" won't be one you can develop applications for. We'll have a separate (possibly virtual) network for licensed developers. It'll also be illegal to use bandwidth for unauthorized applications. The licensed application providers will buy the required bandwidth for their applications, and they'll negotiate with the transport providers based not just on total bandwidth, but on the perceived value of the application; that is, on the basis of how much money the application provider can make. The transport people are going to want at least 20% share if not more. No revenue? No bandwidth, unless it's a public service announcement from a politically-favored sector. There will be no direct peer-to-peer traffic; all traffic MUST be mediated by an approved application. And did I mention the ITU will be in charge of the protocol specifications and you'll need your government's permission and blessing to influence the decision-making? But with everything doable with a combination of HTTP, SIP, and RTCWeb, we won't really be doing much in the way of protocol development. Instead, we'll all be application developers working within a silo structure such as Facebook, Google App Engine ,Azure, iCloud, or Amazon. This seems to me the likely outcome of cross-factoring "all you can eat" plans, AT$T's new "application provider pays" business model, government willingness to support copyright trolls, and the need to have a "responsible party" to support lawful intercept (and copyright/patent enforcement) for every allowed application. Now, back to our previously-scheduled enjoyment of the Internet's "golden years", before being taken over by the TSA's better-funded but less-pleasant uncle. -- Dean --047d7b10d07d69016004bab51742 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 27, 2012 at 12:09 PM, Paul K= yzivat <pkyzi= vat@alum.mit.edu> wrote:


I don't understand how a legal restriction would work.


Did you understand how SOPA and PIPA would work? Me= neither. But that wasn't enough to stop Congress. Fortunately, Congres= s does understand mass protests.

It's easy to envision laws banning one's "= unauthorized signaling implementation." Easy to enforce, too -- just a= dd an App Store check for unauthorized signaling. After all, pretty soon th= e computer you "use" won't be one you can develop application= s for. We'll have a separate (possibly virtual) network for licensed de= velopers.

It'll also be illegal to use bandwidth for unauthor= ized applications. The licensed application providers will buy the required= bandwidth for their applications, and they'll negotiate with the trans= port providers based not just on total bandwidth, but on the perceived valu= e of the application; that is, on the basis of how much money the applicati= on provider can make. The transport people are going to want at least 20% s= hare if not more. No revenue? No bandwidth, unless it's a public servic= e announcement from a politically-favored sector. There will be no direct p= eer-to-peer traffic; all traffic MUST be mediated by an approved applicatio= n.=A0And did I mention the ITU will be in charge of the protocol specificat= ions and you'll need your government's permission and blessing to i= nfluence the decision-making? But with everything doable with a combination= of HTTP, SIP, and RTCWeb, we won't really be doing much in the way of = protocol development. Instead, we'll all be application developers work= ing within a silo structure such as Facebook, Google App Engine ,Azure, iCl= oud, or Amazon.

This seems to me the likely outcome =A0of cross-factori= ng "all you can eat" plans, AT$T's new "application prov= ider pays" business model, government willingness to support copyright= trolls, and the need to have a "responsible party" to support la= wful intercept (and copyright/patent enforcement) for every allowed applica= tion.=A0

Now, back to our previously-scheduled enjoyment of the = Internet's "golden years", before being taken over by the TSA= 's better-funded but less-pleasant uncle.

--
Dean

--047d7b10d07d69016004bab51742-- From pkyzivat@alum.mit.edu Thu Mar 8 09:28:21 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C84CF21F8684 for ; Thu, 8 Mar 2012 09:28:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.357 X-Spam-Level: X-Spam-Status: No, score=-1.357 tagged_above=-999 required=5 tests=[AWL=-1.217, BAYES_20=-0.74, J_CHICKENPOX_21=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 3H+e9DUw80cU for ; Thu, 8 Mar 2012 09:28:21 -0800 (PST) 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 15D9821F867D for ; Thu, 8 Mar 2012 09:28:20 -0800 (PST) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta14.westchester.pa.mail.comcast.net with comcast id j5Tn1i0090bG4ec5E5UM8t; Thu, 08 Mar 2012 17:28:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta03.westchester.pa.mail.comcast.net with comcast id j5UL1i01t07duvL3P5UL1l; Thu, 08 Mar 2012 17:28:21 +0000 Message-ID: <4F58EC32.1000303@alum.mit.edu> Date: Thu, 08 Mar 2012 12:28:18 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Dean Willis References: <6355FFF51CE10D4A99EA9F2685C2C7C648E9707C1B@sirosmb.oteglobe.gr> <010101cce5f9$10d3b8b0$327b2a10$@us> <38726EDA2109264987B45E29E758C4D608655E@MISOUT7MSGUSR9N.ITServices.sbc.com> <155442B6-76C0-4D17-AD5B-8A1B295D619A@iii.ca> <4F459082.2040402@alum.mit.edu> <01d601ccf3d5$37710880$a6531980$@us> <4F4987A7.5080804@alum.mit.edu> <002a01ccf4c6$60bd1c50$223754f0$@us> <4F4BC6F5.4040101@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Legal controls over sip signaling X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 08 Mar 2012 17:28:21 -0000 Hi Dean, Unfortunately I fear Dean's predictions could actually come true. :-( In the news today I saw that some are now concerned about Tor because it is being used by the "bad guys" for porn and sale of illegal goods. The claim is that the Tor people have turned down requests to add a back door to Tor. (But that may just mean they have elected not to disclose a back door they already have.) Thanks, Paul On 3/8/12 1:07 AM, Dean Willis wrote: > > > On Mon, Feb 27, 2012 at 12:09 PM, Paul Kyzivat > wrote: > > > > I don't understand how a legal restriction would work. > > > Did you understand how SOPA and PIPA would work? Me neither. But that > wasn't enough to stop Congress. Fortunately, Congress does understand > mass protests. > > It's easy to envision laws banning one's "unauthorized signaling > implementation." Easy to enforce, too -- just add an App Store check for > unauthorized signaling. After all, pretty soon the computer you "use" > won't be one you can develop applications for. We'll have a separate > (possibly virtual) network for licensed developers. > > It'll also be illegal to use bandwidth for unauthorized applications. > The licensed application providers will buy the required bandwidth for > their applications, and they'll negotiate with the transport providers > based not just on total bandwidth, but on the perceived value of the > application; that is, on the basis of how much money the application > provider can make. The transport people are going to want at least 20% > share if not more. No revenue? No bandwidth, unless it's a public > service announcement from a politically-favored sector. There will be no > direct peer-to-peer traffic; all traffic MUST be mediated by an approved > application. And did I mention the ITU will be in charge of the protocol > specifications and you'll need your government's permission and blessing > to influence the decision-making? But with everything doable with a > combination of HTTP, SIP, and RTCWeb, we won't really be doing much in > the way of protocol development. Instead, we'll all be application > developers working within a silo structure such as Facebook, Google App > Engine ,Azure, iCloud, or Amazon. > > This seems to me the likely outcome of cross-factoring "all you can > eat" plans, AT$T's new "application provider pays" business model, > government willingness to support copyright trolls, and the need to have > a "responsible party" to support lawful intercept (and copyright/patent > enforcement) for every allowed application. > > Now, back to our previously-scheduled enjoyment of the Internet's > "golden years", before being taken over by the TSA's better-funded but > less-pleasant uncle. > > -- > Dean > From richard@shockey.us Thu Mar 8 15:50:10 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E41ED21F86A2 for ; Thu, 8 Mar 2012 15:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.654 X-Spam-Level: X-Spam-Status: No, score=-98.654 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_40=-0.185, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ3GCwvsKFJB for ; Thu, 8 Mar 2012 15:50:06 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 98D2921F8698 for ; Thu, 8 Mar 2012 15:50:06 -0800 (PST) Received: (qmail 16428 invoked by uid 0); 8 Mar 2012 23:50:06 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy7.bluehost.com with SMTP; 8 Mar 2012 23:50:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=BdOl7uztS5JgGQ7T2oRoEzML6iNJto4ERlYNutCaue8=; b=Y0yV6WXHUlONdtkVhSv86cnPKNPv/LelIidV/XJP9SushZDAQA0pwPmyS6md4Q/BunRZzWEl/A2roPufg1AFEMQLR7K9O9iuW7bhoigl7rruMg2m0HoQjYhy5Tyt3dDK; Received: from pool-108-48-10-220.washdc.fios.verizon.net ([108.48.10.220] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1S5n5x-0001Kk-8e; Thu, 08 Mar 2012 16:50:05 -0700 From: "Richard Shockey" To: , , Date: Thu, 8 Mar 2012 18:50:05 -0500 Message-ID: <001201ccfd86$30d719f0$92854dd0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CCFD5C.480111F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acz9hi+tXVbYOlEGQ6Svhv7wAz9bcQ== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 108.48.10.220 authed with richard@shockey.us} Subject: [sipcore] SIPNOC news Dr Henning Schulzrinne will be keynote speaker X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 08 Mar 2012 23:50:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01CCFD5C.480111F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit he SIP Forum Announces FCC Chief Technology Officer Henning Schulzrinne Keynote Speaker for SIPNOC US 2012 SIP Visionary Schulzrinne to address the worldwide service provider community on SIP technology and opportunities facing the IP communications industry NORTH ANDOVER, MA (March 5, 2012) - The SIP Forum announced today Federal Communications Commission (FCC) Chief Technology Officer (CTO) Henning Schulzrinne as the keynote speaker for the second annual SIP Network Operators Conference (SIPNOC), being held at the Hyatt Dulles Hotel in Herndon, VA, June 25-27, 2012. SIPNOC US 2012 will host an international audience focused on the operational and technical aspects of Session Initiation Protocol (SIP) in service provider networks and issues critical to the reliable and successful deployment and operation of SIP-based services in carrier networks. The agenda will feature special presentations, panel discussions and workshops covering key topics by network operators related to SIP-based services and infrastructure, including testing, application development, SIP trunking, FoIP, call routing and peering, troubleshooting and monitoring, emergency services and more. The event website is located at www.sipnoc.org. "I'm excited to be able to talk about the challenges and opportunities of moving to an all-IP network to this international audience of network operational and technical professionals," said Schulzrinne. "As part of my participation in SIPNOC US 2012, I hope to gain a richer perspective on the future of SIP-enabled communications among service providers." "The SIP Forum is delighted to have Henning keynote this year's SIPNOC event," said Richard Shockey, Chairman of the Board of the SIP Forum. "Henning is universally acclaimed as the Father of the SIP standard. We have come a long way since the first SIP specification was adopted in 1999, and we still have much work to do. We look forward to hearing Henning's insights on where we are headed." As CTO of the FCC, Schulzrinne guides the organization's work on technology and engineering issues, together with the FCC's Office of Engineering and Technology. He advises on matters across the agency to ensure that FCC policies are driving technological innovation, including serving as a resource to FCC Commissioners. Schulzrinne joined the FCC in 2010 as an Engineering Fellow. Schulzrinne serves as Julian Clarence Levi Professor of Mathematical Methods and Computer Science and Professor of Engineering at The Fu Foundation School of Engineering at Columbia University. Over the course of his career, he has published more than 250 journal and conference papers and more than 70 Internet Requests for Comment (RFCs) - working to shape the key protocols for enabling voice-over-IP (VoIP) and other multimedia applications, including the Session Initiation Protocol (SIP) which have become Internet Standards. His research interests include Internet multimedia systems, applied network engineering, wireless networks, security, quality of service, and performance evaluation. "Mr. Schulzrinne is one of the key architects of the SIP standard, and a leading mind in the IP communications industry. We are simply thrilled to have him take part in this year's SIPNOC event," said Marc Robins, SIP Forum President and Managing Director. SIPNOC US 2012 will build on themes first discussed at last year's inaugural event: addressing issues critical to the reliable and successful deployment and operation of SIP-based services in carrier networks and the opportunities that come with it. Among the topics expected to be on the agenda at this year's conference are SIP trunking interoperability and the SIP Forum's recently ratified SIPconnect 1.1 technical specification that provides a definitive and standardized set of guidelines for seamless, end-to-end interoperability between SIP-enabled IP-PBXs and service provider networks. Other themes to be discussed include Fax over Internet protocol (FoIP) interworking, implementing SIP with IPv6, and the sharing of best practices for the utilization of Wireshark for network diagnostics within IP network environments. Attendees at SIPNOC US 2012 will include engineers and network architects from telecommunications providers, major backbone operators, interconnect and wholesale solution providers, ISPs, cable operators, wireless network operators as well as large enterprises deploying major SIP initiatives. At last year's SIPNOC 2011, informational presentations were made by a number of professionals from organizations such as Comcast Cable, Cox Communications, Sprint Nextel, CableLabs and the Internet Engineering Task Force (IETF). Dr. Douglas C. Sicker, Chief Technologist at the Federal Communications Commission, provided the keynote speech. For more information about SIPNOC US 2012, please visit www.sipnoc.org or send an email to sipnocinfo@sipforum.org. REGISTER TODAY- $100 Discount for Limited Time Registration for SIPNOC US 2012 is now open, and for a limited time attendees can take advantage of a special $100 discount off the regular registration rate by entering code "sipnocus12100" on the initial registration page. Click here to register or visit http://www.regonline.com/sipnocus2012. ABOUT THE SIP FORUM The SIP Forum is an IP communications industry association that engages in numerous activities that promote and advance SIP-based technology, such as the development of industry recommendations, the SIPit interoperability and testing events, special interoperability workshops, educational seminars, and general promotion of SIP in the industry. One of the Forum's notable technical activities is the development of the SIPconnect Technical Recommendation -- a standards-based recommendation that provides detailed guidelines for direct IP peering and interoperability between IP PBXs and VoIP service provider networks. The SIPconnect Compliant Certification Program is an associated program through which eligible companies can gain SIPconnect validation and the right to license the use of the SIP Forum's 'SIPconnect Compliant' certification mark -- the official brand of the leading standard for SIP Trunking products and services. Other important Forum initiatives include work in Fax-over-IP interoperability, User Agent Configuration, video interoperability, and SIP and IPv6. For more information, please visit: http://www.sipforum.org. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype-linkedin-facebook: rshockey101 http//www.sipforum.org ------=_NextPart_000_0013_01CCFD5C.480111F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

he SIP = Forum Announces FCC Chief Technology Officer

Henning Schulzrinne Keynote Speaker for SIPNOC US = 2012

 

SIP Visionary Schulzrinne to address the worldwide = service provider community on SIP technology and opportunities facing = the IP communications industry

 

NORTH = ANDOVER, MA (March 5, 2012) - The SIP Forum announced today Federal = Communications Commission (FCC) Chief Technology Officer (CTO) Henning = Schulzrinne as the keynote speaker for the second annual SIP Network = Operators Conference (SIPNOC), being held at the Hyatt Dulles Hotel in = Herndon, VA, June 25-27, 2012.

 

SIPNOC US = 2012 will host an international audience focused on the operational and = technical aspects of Session Initiation Protocol (SIP) in service = provider networks and issues critical to the reliable and successful = deployment and operation of SIP-based services in carrier networks. The = agenda will feature special presentations, panel discussions and = workshops covering key topics by network operators related to SIP-based = services and infrastructure, including testing, application development, = SIP trunking, FoIP, call routing and peering, troubleshooting and = monitoring, emergency services and more. The event website is located at = www.sipnoc.org.

“I’m = excited to be able to talk about the challenges and opportunities of = moving to an all-IP network to this international audience of network = operational and technical professionals,” said Schulzrinne. = “As part of my participation in SIPNOC US 2012, I hope to gain a = richer perspective on the future of SIP-enabled communications among = service providers.”

 

“The = SIP Forum is delighted to have Henning keynote this year’s SIPNOC = event,” said Richard Shockey, Chairman of the Board of the SIP = Forum. “Henning is universally acclaimed as the Father of the SIP = standard. We have come a long way since the first SIP specification was = adopted in 1999, and we still have much work to do. We look forward to = hearing Henning’s insights on where we are headed.” =

 

As CTO of the FCC, Schulzrinne guides the = organization’s work on technology and engineering issues, together = with the FCC’s Office of Engineering and Technology. He advises on = matters across the agency to ensure that FCC policies are driving = technological innovation, including serving as a resource to FCC = Commissioners.  Schulzrinne joined the FCC in 2010 as an = Engineering Fellow.

 

Schulzrinne = serves as Julian Clarence Levi Professor of Mathematical Methods and = Computer Science and Professor of Engineering at The Fu Foundation = School of Engineering at Columbia University.  Over the course of = his career, he has published more than 250 journal and conference papers = and more than 70 Internet Requests for Comment (RFCs) – working to = shape the key protocols for enabling voice-over-IP (VoIP) and other = multimedia applications, including the Session Initiation Protocol (SIP) = which have become Internet Standards.  His research interests = include Internet multimedia systems, applied network engineering, = wireless networks, security, quality of service, and performance = evaluation.

 

“Mr. Schulzrinne is one of the key architects of = the SIP standard, and a leading mind in the IP communications = industry.  We are simply thrilled to have him take part in this = year’s SIPNOC event,” said Marc Robins, SIP Forum President = and Managing Director.

 

SIPNOC US = 2012 will build on themes first discussed at last year’s inaugural = event: addressing issues critical to the reliable and successful = deployment and operation of SIP-based services in carrier networks and = the opportunities that come with it. Among the topics expected to be on = the agenda at this year’s conference are SIP trunking = interoperability and the SIP Forum’s recently ratified SIPconnect = 1.1 technical specification that provides a definitive and standardized = set of guidelines for seamless, end-to-end interoperability between = SIP-enabled IP-PBXs and service provider networks. Other themes to be = discussed include Fax over Internet protocol (FoIP) interworking, = implementing SIP with IPv6, and the sharing of best practices for the = utilization of Wireshark for network diagnostics within IP network = environments.

 

Attendees at = SIPNOC US 2012 will include engineers and network architects from = telecommunications providers, major backbone operators, interconnect and = wholesale solution providers, ISPs, cable operators, wireless network = operators as well as large enterprises deploying major SIP initiatives. = At last year’s SIPNOC 2011, informational presentations were made = by a number of professionals from organizations such as Comcast Cable, = Cox Communications, Sprint Nextel, CableLabs and the Internet = Engineering Task Force (IETF). Dr. Douglas C. Sicker, Chief Technologist = at the Federal Communications Commission, provided the keynote speech. =

 

For more information about SIPNOC US 2012, please = visit www.sipnoc.org or send an email to sipnocinfo@sipforum.org. =

 

 

REGISTER = TODAY–  $100 Discount for Limited Time

Registration for SIPNOC US 2012 is now open, and for a = limited time attendees can take advantage of a special $100 discount off = the regular registration rate by entering code = “sipnocus12100” on the initial registration page.  = Click here to register or visit = http://www.regonline.com/sipnocus2012.

 

ABOUT THE = SIP FORUM

The SIP Forum is an IP = communications industry association that engages in numerous activities = that promote and advance SIP-based technology, such as the development = of industry recommendations, the SIPit interoperability and testing = events, special interoperability workshops, educational seminars, and = general promotion of SIP in the industry.  One of the Forum's = notable technical activities is the development of the SIPconnect = Technical Recommendation -- a standards-based recommendation that = provides detailed guidelines for direct IP peering and interoperability = between IP PBXs and VoIP service provider networks. The SIPconnect = Compliant Certification Program is an associated program through which = eligible companies can gain SIPconnect validation and the right to = license the use of the SIP Forum's 'SIPconnect Compliant' certification = mark -- the official brand of the leading standard for SIP Trunking = products and services. Other important Forum initiatives include work in = Fax-over-IP interoperability, User Agent Configuration, video = interoperability, and SIP and IPv6. For more information, please visit: = http://www.sipforum.org.

 

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

 

------=_NextPart_000_0013_01CCFD5C.480111F0-- From adam@nostrum.com Fri Mar 9 13:16:24 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4959721E8025 for ; Fri, 9 Mar 2012 13:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, 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 TPLcZqVjLtfC for ; Fri, 9 Mar 2012 13:16:23 -0800 (PST) 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 8FF4621E8019 for ; Fri, 9 Mar 2012 13:16:23 -0800 (PST) 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 q29LGMJ3068950 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 9 Mar 2012 15:16:22 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4F5A7326.3030001@nostrum.com> Date: Fri, 09 Mar 2012 15:16:22 -0600 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Call for Reviewers: SIP WebSocket Transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 21:16:24 -0000 [as chair] I've seen a lot of statements of support for the concept of using websockets as a transport for SIP. However, if we're going to have this work move forward, we'll need more in the way of technical discussion on the solution. (All I've seen so far is a discussion around the role of outbound, and I'm not sure that conversation has resolved far enough to call consensus). To that end, I'd like to solicit a small handful of dedicated reviewers to go over the current proposal: http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01 Reviewers would be expected to read the draft carefully, and provide comments to the SIPCORE list. In order for us to have something to talk about in Paris, I would request that such reviews be posted to the list no later than Friday of next week (March 16th). Please inform the chairs (by replying to this message) if you would be willing to perform such a review. Unless we see additional traffic on the mailing list on this topic, I don't believe we'll have any basis for talking about it at the upcoming face-to-face meeting. /a From vkg@bell-labs.com Fri Mar 9 14:11:31 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94EE21E80E2 for ; Fri, 9 Mar 2012 14:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.95 X-Spam-Level: X-Spam-Status: No, score=-106.95 tagged_above=-999 required=5 tests=[AWL=-0.351, 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 KirdqFDqolLV for ; Fri, 9 Mar 2012 14:11:31 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id D7ECA21E80EE for ; Fri, 9 Mar 2012 14:11:30 -0800 (PST) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q29MBT2d025850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 Mar 2012 16:11:29 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q29MBShE024613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 9 Mar 2012 16:11:29 -0600 Received: from shoonya.ih.lucent.com (shoonya-135185238235.ih.lucent.com [135.185.238.235] (may be forged)) by umail.lucent.com (8.13.8/TPES) with ESMTP id q29MBSDb028709 for ; Fri, 9 Mar 2012 16:11:28 -0600 (CST) Message-ID: <4F5A8125.6070307@bell-labs.com> Date: Fri, 09 Mar 2012 16:16:05 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: [sipcore] 4th SIP Bakeoff Baseball Hat X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 09 Mar 2012 22:11:31 -0000 Do you wish you had wearable momentos from early SIP bakeoffs? Do you wish to relive the excitement of having participated in the early SIP bakeoffs? Well ... you need wish no more! While cleaning up at home, I ran across a vintage 4th SIP Bakeoff baseball hat, unused and in excellent condition. The 4th SIP Bakeoff was held on April 17-19, 2000 and was hosted by 3Com in Rolling Meadows, IL The hat is free to the lucky hard core SIP aficionado. Please send me private email --- the first email wins. I will hand-deliver the exquisitely crafted headgear to you in person at Paris! Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From kpfleming@digium.com Fri Mar 9 14:13:32 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2052021E8093 for ; Fri, 9 Mar 2012 14:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.552 X-Spam-Level: X-Spam-Status: No, score=-106.552 tagged_above=-999 required=5 tests=[AWL=0.047, 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 eOGQ1xwNNK98 for ; Fri, 9 Mar 2012 14:13:31 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 419ED21E8025 for ; Fri, 9 Mar 2012 14:13:28 -0800 (PST) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1S683y-0004zB-W7 for sipcore@ietf.org; Fri, 09 Mar 2012 16:13:27 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id EE817D8005 for ; Fri, 9 Mar 2012 16:13:26 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rndxSGnopYDa for ; Fri, 9 Mar 2012 16:13:26 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 969C2D8004 for ; Fri, 9 Mar 2012 16:13:26 -0600 (CST) Message-ID: <4F5A8086.7020704@digium.com> Date: Fri, 09 Mar 2012 16:13:26 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sipcore@ietf.org References: <4F5A7326.3030001@nostrum.com> In-Reply-To: <4F5A7326.3030001@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Call for Reviewers: SIP WebSocket Transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:13:32 -0000 On 03/09/2012 03:16 PM, Adam Roach - SIPCORE Chair wrote: > [as chair] > > I've seen a lot of statements of support for the concept of using > websockets as a transport for SIP. However, if we're going to have this > work move forward, we'll need more in the way of technical discussion on > the solution. (All I've seen so far is a discussion around the role of > outbound, and I'm not sure that conversation has resolved far enough to > call consensus). > > To that end, I'd like to solicit a small handful of dedicated reviewers > to go over the current proposal: > > http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01 > > Reviewers would be expected to read the draft carefully, and provide > comments to the SIPCORE list. In order for us to have something to talk > about in Paris, I would request that such reviews be posted to the list > no later than Friday of next week (March 16th). > > Please inform the chairs (by replying to this message) if you would be > willing to perform such a review. > > Unless we see additional traffic on the mailing list on this topic, I > don't believe we'll have any basis for talking about it at the upcoming > face-to-face meeting. I'll review it this weekend. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From alan.b.johnston@gmail.com Fri Mar 9 14:45:59 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BC821F8460 for ; Fri, 9 Mar 2012 14:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxiLRsx1wk6I for ; Fri, 9 Mar 2012 14:45:59 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id C947821E805F for ; Fri, 9 Mar 2012 14:45:58 -0800 (PST) Received: by iazz13 with SMTP id z13so3134652iaz.31 for ; Fri, 09 Mar 2012 14:45:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-type:message-id :content-transfer-encoding:cc:x-mailer:from:subject:date:to; bh=4ZFQNLwWgk6NvVL+PpGiTT0altlMVHBWoMtJUGbxGYk=; b=MhX5vr0tivcI5DR43946CMO1S2btZ7PvtWhRJaFsJztYx5lzD0dlP3UFQ6RGgMm/6W T8uAMEAPtCVWrSYc3UNwIwVOcUD7JzhRlpFjiWF0MGgt896gpTTZQ+0pxk8kdfLmzBkF n9ZyBAfO7ChBcfdsAQ0ViTEtRKwnJkdhOmNIDt2qmDgdVw4Fh26jpVSGE+q8HX2Sfc9q Fi3jL2mbhu3AQqtNhqb+leJCRbNejPO7nDXZLovALM1ZCT2WnayDxt+/Mjp+lfRYzdN8 qPXk7XyvAwkXTz1Ievu4+4h0/u80P95zfweJU2Yx0Ssh9XWrvvNMyqz0Fc99X7VlOkCN LSwA== Received: by 10.43.51.196 with SMTP id vj4mr5207040icb.19.1331333158339; Fri, 09 Mar 2012 14:45:58 -0800 (PST) Received: from [10.61.39.251] (mobile-166-137-140-006.mycingular.net. [166.137.140.6]) by mx.google.com with ESMTPS id vb4sm3072489igc.10.2012.03.09.14.45.57 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Mar 2012 14:45:57 -0800 (PST) References: <4F5A7326.3030001@nostrum.com> <4F5A8086.7020704@digium.com> In-Reply-To: <4F5A8086.7020704@digium.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (9A405) From: Alan Johnston Date: Fri, 9 Mar 2012 16:45:52 -0600 To: "Kevin P. Fleming" Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Call for Reviewers: SIP WebSocket Transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:45:59 -0000 I will also review it. - Alan - On Mar 9, 2012, at 4:13 PM, "Kevin P. Fleming" wrote: > On 03/09/2012 03:16 PM, Adam Roach - SIPCORE Chair wrote: >> [as chair] >> >> I've seen a lot of statements of support for the concept of using >> websockets as a transport for SIP. However, if we're going to have this >> work move forward, we'll need more in the way of technical discussion on >> the solution. (All I've seen so far is a discussion around the role of >> outbound, and I'm not sure that conversation has resolved far enough to >> call consensus). >> >> To that end, I'd like to solicit a small handful of dedicated reviewers >> to go over the current proposal: >> >> http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01 >> >> Reviewers would be expected to read the draft carefully, and provide >> comments to the SIPCORE list. In order for us to have something to talk >> about in Paris, I would request that such reviews be posted to the list >> no later than Friday of next week (March 16th). >> >> Please inform the chairs (by replying to this message) if you would be >> willing to perform such a review. >> >> Unless we see additional traffic on the mailing list on this topic, I >> don't believe we'll have any basis for talking about it at the upcoming >> face-to-face meeting. > > I'll review it this weekend. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at www.digium.com & www.asterisk.org > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ibc@aliax.net Fri Mar 9 15:12:56 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3852921E80A3 for ; Fri, 9 Mar 2012 15:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.628 X-Spam-Level: X-Spam-Status: No, score=-2.628 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aD8Ngg6LoPU6 for ; Fri, 9 Mar 2012 15:12:55 -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 A473F21E8028 for ; Fri, 9 Mar 2012 15:12:55 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so2228427vcb.31 for ; Fri, 09 Mar 2012 15:12:55 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=4I8RXUz2O14YiLUl/H/WBCzyAK7cI6cKM1JVivjdtCo=; b=RO4hoT0ldYBXpDy+cJrw2D3PJjJXvA0A5vIyIMJrYd5xRYJ6ZzRkIrquz5fphWNVaz BEMKX5eqPcc8ZuLzmvNOdgH/CkDJcF0FR9U6656Tl7w429xYHiOQeg/f98dOedY3N8a7 p0VIOd45TKj46HC+ono0QQakNV37T7R/nwocJHYJHF475RNfXbrix9QijjH4VkJIVBQb H9fMROHcDnDRvyKXfxr9HyYIJ4K4jk9K/rVZugGIyW9RFgDhlYKUFm6aMazBlXMiq4z6 nZQJNxOsPlyYGm1qB0PAIhyvcD7y2sMPAr574seohKIB7gyDzVJwD4Un8YUtm142zqj2 qOkw== Received: by 10.52.70.175 with SMTP id n15mr6833412vdu.10.1331334775131; Fri, 09 Mar 2012 15:12:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.99.131 with HTTP; Fri, 9 Mar 2012 15:12:35 -0800 (PST) In-Reply-To: References: <4F5A7326.3030001@nostrum.com> <4F5A8086.7020704@digium.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Sat, 10 Mar 2012 00:12:35 +0100 Message-ID: To: Alan Johnston Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQm234cI+y35X34SqhbztcNM1l1nbb4alNqXsbhFk8JJFI3uZEm9iKUXmgqTx6khBhcbCFUL Cc: "sipcore@ietf.org" , "Kevin P. Fleming" Subject: Re: [sipcore] Call for Reviewers: SIP WebSocket Transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 23:12:56 -0000 2012/3/9 Alan Johnston : > I will also review it. Thanks Kevin, Alan. We'll be so greateful to read your opinion about the document. --=20 I=C3=B1aki Baz Castillo From salvatore.loreto@ericsson.com Sat Mar 10 06:13:48 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2DE21F8528 for ; Sat, 10 Mar 2012 06:13:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.892 X-Spam-Level: X-Spam-Status: No, score=-109.892 tagged_above=-999 required=5 tests=[AWL=0.707, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCGJMJyWIT9T for ; Sat, 10 Mar 2012 06:13:47 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BA0D921F858D for ; Sat, 10 Mar 2012 06:13:46 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-16-4f5b619932d2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 25.70.27041.9916B5F4; Sat, 10 Mar 2012 15:13:45 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.213.0; Sat, 10 Mar 2012 15:13:45 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3F8FB2320 for ; Sat, 10 Mar 2012 16:13:45 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1C83C51EA7 for ; Sat, 10 Mar 2012 16:13:45 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C4D1950B62 for ; Sat, 10 Mar 2012 16:13:44 +0200 (EET) Message-ID: <4F5B6198.8000708@ericsson.com> Date: Sat, 10 Mar 2012 16:13:44 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sipcore@ietf.org References: <4F5A7326.3030001@nostrum.com> <4F5A8086.7020704@digium.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Call for Reviewers: SIP WebSocket Transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 14:13:48 -0000 I will also review and submit it by March 16th cheers Salvatore On 3/10/12 12:45 AM, Alan Johnston wrote: > I will also review it. > > - Alan - > > > > On Mar 9, 2012, at 4:13 PM, "Kevin P. Fleming" wrote: > >> On 03/09/2012 03:16 PM, Adam Roach - SIPCORE Chair wrote: >>> [as chair] >>> >>> I've seen a lot of statements of support for the concept of using >>> websockets as a transport for SIP. However, if we're going to have this >>> work move forward, we'll need more in the way of technical discussion on >>> the solution. (All I've seen so far is a discussion around the role of >>> outbound, and I'm not sure that conversation has resolved far enough to >>> call consensus). >>> >>> To that end, I'd like to solicit a small handful of dedicated reviewers >>> to go over the current proposal: >>> >>> http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01 >>> >>> Reviewers would be expected to read the draft carefully, and provide >>> comments to the SIPCORE list. In order for us to have something to talk >>> about in Paris, I would request that such reviews be posted to the list >>> no later than Friday of next week (March 16th). >>> >>> Please inform the chairs (by replying to this message) if you would be >>> willing to perform such a review. >>> >>> Unless we see additional traffic on the mailing list on this topic, I >>> don't believe we'll have any basis for talking about it at the upcoming >>> face-to-face meeting. >> I'll review it this weekend. >> >> -- >> Kevin P. Fleming >> Digium, Inc. | Director of Software Technologies >> Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> Check us out at www.digium.com& www.asterisk.org >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore -- Salvatore Loreto www.sloreto.com From christer.holmberg@ericsson.com Mon Mar 12 07:06:22 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5BA21E802F for ; Mon, 12 Mar 2012 07:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.232 X-Spam-Level: X-Spam-Status: No, score=-10.232 tagged_above=-999 required=5 tests=[AWL=0.367, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr5Xi7zvhU+1 for ; Mon, 12 Mar 2012 07:06: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 3D85D21E8028 for ; Mon, 12 Mar 2012 07:06:21 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-01-4f5e02dc174c Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 31.1A.27041.CD20E5F4; Mon, 12 Mar 2012 15:06:20 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 12 Mar 2012 15:06:20 +0100 From: Christer Holmberg To: Salvatore Loreto , "sipcore@ietf.org" Date: Mon, 12 Mar 2012 15:06:18 +0100 Thread-Topic: [sipcore] Call for Reviewers: SIP WebSocket Transport Thread-Index: Acz+yAT5DV17S36SRsKcFSa9QRYIawBkSwFg Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C412E0A62@ESESSCMS0356.eemea.ericsson.se> References: <4F5A7326.3030001@nostrum.com> <4F5A8086.7020704@digium.com> <4F5B6198.8000708@ericsson.com> In-Reply-To: <4F5B6198.8000708@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Call for Reviewers: SIP WebSocket Transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:06:22 -0000 Hi, Earlier I gave some comments on an earlier version of the draft. I will review this version also. Regards, Christer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Salvatore Loreto Sent: 10. maaliskuuta 2012 16:14 To: sipcore@ietf.org Subject: Re: [sipcore] Call for Reviewers: SIP WebSocket Transport I will also review and submit it by March 16th cheers Salvatore On 3/10/12 12:45 AM, Alan Johnston wrote: > I will also review it. > > - Alan - > > > > On Mar 9, 2012, at 4:13 PM, "Kevin P. Fleming" wro= te: > >> On 03/09/2012 03:16 PM, Adam Roach - SIPCORE Chair wrote: >>> [as chair] >>> >>> I've seen a lot of statements of support for the concept of using=20 >>> websockets as a transport for SIP. However, if we're going to have=20 >>> this work move forward, we'll need more in the way of technical=20 >>> discussion on the solution. (All I've seen so far is a discussion=20 >>> around the role of outbound, and I'm not sure that conversation has=20 >>> resolved far enough to call consensus). >>> >>> To that end, I'd like to solicit a small handful of dedicated=20 >>> reviewers to go over the current proposal: >>> >>> http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01 >>> >>> Reviewers would be expected to read the draft carefully, and provide=20 >>> comments to the SIPCORE list. In order for us to have something to=20 >>> talk about in Paris, I would request that such reviews be posted to=20 >>> the list no later than Friday of next week (March 16th). >>> >>> Please inform the chairs (by replying to this message) if you would=20 >>> be willing to perform such a review. >>> >>> Unless we see additional traffic on the mailing list on this topic,=20 >>> I don't believe we'll have any basis for talking about it at the=20 >>> upcoming face-to-face meeting. >> I'll review it this weekend. >> >> -- >> Kevin P. Fleming >> Digium, Inc. | Director of Software Technologies >> Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype:=20 >> kpfleming >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at=20 >> www.digium.com& www.asterisk.org=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore -- Salvatore Loreto www.sloreto.com _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From saul@ag-projects.com Mon Mar 12 07:08:33 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC29321F87AE for ; Mon, 12 Mar 2012 07:08:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+I6zR1GzguY for ; Mon, 12 Mar 2012 07:08:33 -0700 (PDT) Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3CE21F87AD for ; Mon, 12 Mar 2012 07:08:33 -0700 (PDT) Received: by mail.sipthor.net (Postfix, from userid 5001) id CE31AB01A4; Mon, 12 Mar 2012 15:08:31 +0100 (CET) Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id AF1D0B019E; Mon, 12 Mar 2012 15:08:18 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= In-Reply-To: <4F5A8086.7020704@digium.com> Date: Mon, 12 Mar 2012 15:08:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3EEB7D30-C856-48FB-A8B8-1CC8BC717EE8@ag-projects.com> References: <4F5A7326.3030001@nostrum.com> <4F5A8086.7020704@digium.com> To: Kevin P. Fleming X-Mailer: Apple Mail (2.1084) Cc: sipcore@ietf.org Subject: Re: [sipcore] Call for Reviewers: SIP WebSocket Transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:08:34 -0000 On Mar 9, 2012, at 11:13 PM, Kevin P. Fleming wrote: > On 03/09/2012 03:16 PM, Adam Roach - SIPCORE Chair wrote: >> [as chair] >>=20 >> I've seen a lot of statements of support for the concept of using >> websockets as a transport for SIP. However, if we're going to have = this >> work move forward, we'll need more in the way of technical discussion = on >> the solution. (All I've seen so far is a discussion around the role = of >> outbound, and I'm not sure that conversation has resolved far enough = to >> call consensus). >>=20 >> To that end, I'd like to solicit a small handful of dedicated = reviewers >> to go over the current proposal: >>=20 >> http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01 >>=20 >> Reviewers would be expected to read the draft carefully, and provide >> comments to the SIPCORE list. In order for us to have something to = talk >> about in Paris, I would request that such reviews be posted to the = list >> no later than Friday of next week (March 16th). >>=20 >> Please inform the chairs (by replying to this message) if you would = be >> willing to perform such a review. >>=20 >> Unless we see additional traffic on the mailing list on this topic, I >> don't believe we'll have any basis for talking about it at the = upcoming >> face-to-face meeting. >=20 > I'll review it this weekend. >=20 Me too. Regards, -- Sa=FAl Ibarra Corretg=E9 AG Projects From kpfleming@digium.com Mon Mar 12 07:37:15 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC39621F882D for ; Mon, 12 Mar 2012 07:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4REiYPorG0F for ; Mon, 12 Mar 2012 07:37:15 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id D19E721F8826 for ; Mon, 12 Mar 2012 07:37:14 -0700 (PDT) Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1S76N7-0001gM-Qp; Mon, 12 Mar 2012 09:37:13 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id C3954D8011; Mon, 12 Mar 2012 09:37:13 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73SbwLbtL4kw; Mon, 12 Mar 2012 09:37:13 -0500 (CDT) Received: from [192.168.1.10] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 090C9D8010; Mon, 12 Mar 2012 09:37:12 -0500 (CDT) Message-ID: <4F5E0A18.1060301@digium.com> Date: Mon, 12 Mar 2012 09:37:12 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= References: <4F5A7326.3030001@nostrum.com> <4F5A8086.7020704@digium.com> <3EEB7D30-C856-48FB-A8B8-1CC8BC717EE8@ag-projects.com> In-Reply-To: <3EEB7D30-C856-48FB-A8B8-1CC8BC717EE8@ag-projects.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] Call for Reviewers: SIP WebSocket Transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:37:15 -0000 On 03/12/2012 09:08 AM, Sa=FAl Ibarra Corretg=E9 wrote: > > On Mar 9, 2012, at 11:13 PM, Kevin P. Fleming wrote: > >> On 03/09/2012 03:16 PM, Adam Roach - SIPCORE Chair wrote: >>> [as chair] >>> >>> I've seen a lot of statements of support for the concept of using >>> websockets as a transport for SIP. However, if we're going to have th= is >>> work move forward, we'll need more in the way of technical discussion= on >>> the solution. (All I've seen so far is a discussion around the role o= f >>> outbound, and I'm not sure that conversation has resolved far enough = to >>> call consensus). >>> >>> To that end, I'd like to solicit a small handful of dedicated reviewe= rs >>> to go over the current proposal: >>> >>> http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01 >>> >>> Reviewers would be expected to read the draft carefully, and provide >>> comments to the SIPCORE list. In order for us to have something to ta= lk >>> about in Paris, I would request that such reviews be posted to the li= st >>> no later than Friday of next week (March 16th). >>> >>> Please inform the chairs (by replying to this message) if you would b= e >>> willing to perform such a review. >>> >>> Unless we see additional traffic on the mailing list on this topic, I >>> don't believe we'll have any basis for talking about it at the upcomi= ng >>> face-to-face meeting. >> >> I'll review it this weekend. >> > > Me too. Forgot to update the list; during my review this weekend, I noted quite=20 a number of places where the wording could be improved. Inaki has sent=20 me the source for the draft and later today I'll be doing a=20 non-technical editing pass to try to improve the language without=20 changing the meaning. Hopefully I'll get that to him before his day=20 starts tomorrow and he can review/post a new version for all of the=20 reviewers to review. --=20 Kevin P. Fleming Digium, Inc. | Director of Software Technologies Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpflemin= g 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.digium.com & www.asterisk.org From ibc@aliax.net Mon Mar 12 07:51:43 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD86721F8858 for ; Mon, 12 Mar 2012 07:51:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJG08P46etu2 for ; Mon, 12 Mar 2012 07:51:43 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF1621F862A for ; Mon, 12 Mar 2012 07:51:42 -0700 (PDT) Received: by werb10 with SMTP id b10so4152181wer.31 for ; Mon, 12 Mar 2012 07:51:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=YhPGSurL4nTF1MM2AIKrmaVf7rreN/kWvjBKHXZUOsU=; b=RbCbc/0xPQhq3ICYrlQJXNPnoonEIW3QgCLyFTYw1nQ7Hr8MGH9WBknVvRwKeQXmfO o6rRMgbFd68XFNBAtJH3wXWqBxjuYl7IHUeIDWdY72Vs+Y275FIp/83jHexTlHmB6VrA jqEuEI2xizZwe8hmGUzlspWa8PSUX7nOPzMXJg876JVL+1ynvkBt4dC0j35a4i5GwSN/ ocZss5dJSdcNLJMFT+1AfiaJnIEGsSVmOclFvqeeMqESNcASsyb6xLb/nvbqZaj6Vg// QVF3wK9bqTkIW+5hh144vIeq+n4AQz9pPQKglAaJ/R2Nn9Md7Al9eEY0jLhQ1UbVgVec yDyQ== Received: by 10.52.17.239 with SMTP id r15mr14604301vdd.95.1331563901212; Mon, 12 Mar 2012 07:51:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.99.131 with HTTP; Mon, 12 Mar 2012 07:51:21 -0700 (PDT) In-Reply-To: <4F5E0A18.1060301@digium.com> References: <4F5A7326.3030001@nostrum.com> <4F5A8086.7020704@digium.com> <3EEB7D30-C856-48FB-A8B8-1CC8BC717EE8@ag-projects.com> <4F5E0A18.1060301@digium.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 12 Mar 2012 15:51:21 +0100 Message-ID: To: "Kevin P. Fleming" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmxDgXteg2kv9o9CBdaJ3SqPTpUtiVR1+QVX1237OzHqkbzHzQJHEPwi16vyFlfLEJymHhi Cc: sipcore@ietf.org, =?UTF-8?Q?Sa=C3=BAl_Ibarra_Corretg=C3=A9?= Subject: Re: [sipcore] Call for Reviewers: SIP WebSocket Transport X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 14:51:44 -0000 2012/3/12 Kevin P. Fleming : > Forgot to update the list; during my review this weekend, I noted quite a > number of places where the wording could be improved. Inaki has sent me t= he > source for the draft and later today I'll be doing a non-technical editin= g > pass to try to improve the language without changing the meaning. Hopeful= ly > I'll get that to him before his day starts tomorrow and he can review/pos= t a > new version for all of the reviewers to review. Thanks Kevin, I will commit the new revision when you send it back to me. Regards. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue Mar 13 06:06:44 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569E521F8793 for ; Tue, 13 Mar 2012 06:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.246 X-Spam-Level: X-Spam-Status: No, score=-10.246 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqzDLw2QQvNh for ; Tue, 13 Mar 2012 06:06:43 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 32D8B21F877A for ; Tue, 13 Mar 2012 06:06:43 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-85-4f5f46611e09 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BA.A0.27041.1664F5F4; Tue, 13 Mar 2012 14:06:42 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 13 Mar 2012 14:06:41 +0100 From: Christer Holmberg To: SIPCORE Chairs , "SIPCORE (Session Initiation Protocol Core) WG" Date: Tue, 13 Mar 2012 14:06:40 +0100 Thread-Topic: [sipcore] Call for Reviewers: SIP WebSocket Transport - Christer's Review Thread-Index: Ac0AWcRlfqYO8HL2QrC1COTQRbduGA== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4137D763@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: Re: [sipcore] Call for Reviewers: SIP WebSocket Transport - Christer's Review X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 13 Mar 2012 13:06:44 -0000 Hi, Below are my comments on the SIP WebSocket (WS) transport draft. My comment= s are mainly related to the mandated SIP extensions and the relaxed 3261 pr= ocedures. I also include some editorial comments, eventhough I realize those are prob= ably not the main focus of this specific review. (Some of the comments I already gave on an earlie version of the draft.) Also, eventhough I have some issues, I want to clarify that I in general D= O support adopting this work :) GENRAL: ----------- Q_GEN_1: I think it would be good to explicitly indicate that the draft onl= y deals with SIP signaling, and that media transport is outside the scope o= f the document, and is expected to be transported using already standardize= d mechanisms (or, mechanisms standardized elsewhere). Section 1: ------------ Q_1-1: Add an RFC 6455 reference to "WebSocket Sub-Protocol". Section 4: ------------ Q_4-1: I would suggest to add two sub-sections, one which contains the gen= eral description of the sub-protocol, and one which contains the procedures= . Section 5.3: -------------- Q_5_3-1: What does the following text mean? "This requires the server transport to maintain an association=20 between server transactions and transport connections." Q_5_3-2: The text says: "The SIP server transport uses the value of the top Via header field in order to determine where to send a response. If the "sent- protocol" is "WS" or "WSS" the response MUST be sent using the existing WebSocket connection to the source of the original request," I would suggest to simply say that SIP responses MUST be sent using the sa= me WebSocket connection on which the associated request was received. Q_5_3-3: The text says: "If that connection is no longer open, the server MUST NOT attempt to open a WebSocket connection to the Via "sent- by"/"received"/"rport". " I would suggest to simply say that the server MUST NOT attempt to re-open = a WebSocket connection. Section 6: ------------ Q_6-1: Regarding the MUST implement Outbound. The text says: "Therefore clients and servers implementing SIP over the WebSocket transport MUST implement the Outbound mechanism [RFC5626], being this the most suitable solution for SIP clients behind Network Address Translation (NAT) using reliable transports for contacting SIP servers." Therefore why? Because they may not know the WS address they MUST implement= Outbound? I also don't understand the part saying that "Outbound is the most suitable= solution for contacting SIP servers". Also, unless you intend to explicitly forbid it, I guess a WS connection co= uld be established between two SIP proxies. And, as they don't register, th= ey can't use Outbound. Q_6-3: Why is there a SHOULD to implement GRUU? If you want that, you need = some justification, and say how it is specific to the WS transport. Q_6-4: As SIP registrars are outside the scope of this specification, so I = don't think we can tell them to implement GRUU. Section 8.1: -------------- Q_8_1-1: If the client application wants to become reachable again, I guess= it MUST (the text says SHOULD) create a new WS connection, unless it has c= reated additional WS connections using Outbound. Section 10: ------------- Q_10-1: In section 8.1 you say that a client SHOULD re-establish the WS co= nnection if it goes down, but in section 10 you say that the decision wheth= er to maintain the WS connection is outside the scope of the document. Q_10-2: The text says "a SIP server implementing the WebSocket transport MU= ST support the CRLF Keep-Alive Technique.". In that case I guess it SHOULD/= MUST also support the negotiation mechanism, as described in RFC 6223 (even= though CRLF keep-alives can be sent without explicit support indication fro= m the receiving server). Section 13.3: --------------- Q_13_3-1: Do we really want to relax the 3261 procedures regarding "receive= d"? In my opinion topology hiding can be done as an implementation thing - = we don't need to specify it. Q_13_3-2: I don't understand the text regarding not honoring the "rport" pa= rameter. I guess you mean to say that the port number is not added. But, ag= ain, I am not sure we should specify such things. Q_13_3-3: If you are updating RFC 3261, by relaxing the usage of received e= tc, I think there should be a "Updates to RFC 3261" section name. Regards, Christer From ibc@aliax.net Tue Mar 13 09:01:27 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA13621F8839 for ; Tue, 13 Mar 2012 09:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=0.068, 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 rEnNo5NwFVAB for ; Tue, 13 Mar 2012 09:01:27 -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 F11E521F8818 for ; Tue, 13 Mar 2012 09:01:26 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so958511vcb.31 for ; Tue, 13 Mar 2012 09:01:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=/aAIpmFcjHPNEFfSZoxXcw4NUngo+0K1tCz+CKEUlJ4=; b=NEvwy2hEtB/W+QKFsYs9ZJw8rrlfD5chOhwcdEpPLtenEzsruGjWoSBam6jzgx52/v 8aggDK1Yaw8wpu+BfPEupgtymLLx8RGjLHlNBUY7wgqFKgxOFFDzP4C4zeXr2KnvLKSo QXxoLc6iU0adlLHRcFKA2xgCfnEo4nEsCukNKQiOa7++WJE+ctzz4yOTb3L9iJyTgfae wDckzccE/ryeyFSp39Axs9SfS7Kz/S8Y0QCirx87Nis71OAXVdkVm4aYML/YPQScnj09 W3/HXc1JvHcl7hOHuJ5s3lDHi+SYqq11vNEq+7bD0X/br/n8T51eyoMO6kdDHeXYe2V/ 7fdg== Received: by 10.52.71.226 with SMTP id y2mr17596254vdu.78.1331654486158; Tue, 13 Mar 2012 09:01:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.165.162 with HTTP; Tue, 13 Mar 2012 09:01:06 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4137D763@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C4137D763@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 13 Mar 2012 17:01:06 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkZJ9rmCHVNcS1GN+2iXrO05e/OUjOxlv7nl/EYk3tWDJFnuEJ9OKyO3kUkTPK11JDTl0Jp Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Call for Reviewers: SIP WebSocket Transport - Christer's Review X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 13 Mar 2012 16:01:28 -0000 2012/3/13 Christer Holmberg : > Hi, > > Below are my comments on the SIP WebSocket (WS) transport draft. Hi Christer, we are addressing the issues you have mentioned and will reply your mail soon. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Thu Mar 15 02:03:28 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E240921F865A for ; Thu, 15 Mar 2012 02:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.25 X-Spam-Level: X-Spam-Status: No, score=-10.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2ceQmz9hbIc for ; Thu, 15 Mar 2012 02:03:28 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 96DD121F863B for ; Thu, 15 Mar 2012 02:03:27 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-45-4f61b05e5b62 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8A.6C.27041.E50B16F4; Thu, 15 Mar 2012 10:03:26 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 15 Mar 2012 10:03:26 +0100 From: Christer Holmberg To: Paul Kyzivat , "Dawes, Peter, VF-Group" Date: Thu, 15 Mar 2012 10:03:23 +0100 Thread-Topic: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft Thread-Index: Acz4lwbzGEVQ8KaeSVOJk+ZdgL3NmwJ46yRw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4137E2EB@ESESSCMS0356.eemea.ericsson.se> References: <4F50FE6D.6050501@alum.mit.edu> In-Reply-To: <4F50FE6D.6050501@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] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 15 Mar 2012 09:03:29 -0000 Hi Paul, >> I support wg adoption of the proxy-feature draft as this kind of solutio= n is needed to allow a network to do the things=20 >>described in draft-ietf-sipcore-proxy-feature-reqs-03.txt. > >> On the question " Since many of us have struggled to understand the use= s of this mechanism, it would be great if those of you who have uses would= =20 >> describe them." do you believe that what is needed is more use cases tha= n those listed in the reqs draft, or a more general idea of the value of a = SIP >> "feature node" indicating its capabilities to other SIP entities, or som= ething else? For me, the use cases in the reqs are sufficient reason to wor= k on the draft. > > I think it would be useful to have both more use cases (some that the res= t of us can relate to), *and* more general explanation of what it means for= =20 > a non-endpoint to have a feature that others need to know about. > > I am not saying that this can't proceed without that, but it will be more= difficult, and without that we might end up with a draft that is understoo= d=20 > and supported only by those building for IMS. What it means for a non-endpoint to have a feature needs to be described in= the feature specification. I don't think there is a general explanation, o= ther than "I can do capability X". The req spec gives short explanations of the 3GPP use-cases. I also believe= the 3GPP specs are generally available if one wants more information. However, there is nothing IMS specific with the mechanism as such, and I be= lieve there are a number of general use-cases. But, I hope we don't expect = 3GPP to come up with those. Some examples, that I have been thinking about myself: Forking: ---------- This is related to something I have spent quite much time on discussing wit= h customers etc: how to ensure that incoming calls reach the correct device= ? When a user registers multiple devices associated with a single AoR, it is = often difficult to know/ensure that incoming calls reach an appropriate dev= ice. In some cases, the problem could be solved if a UA had additional know= ledge about its registrar's forking capabilities (support of RFC 3841 can a= lready be indicated using an option-tag), and may impact on whether the use= r is going to register multiple devices in the first place, whether the us= er is going to generate local ringback tones/anouncements (maybe the regist= rar can indicate capability of doing it). Automatic call handling (and other network features): ------------------------------------------------------------------ Informing UAs about whether a network entity has the capability to provide = automatic call handling (call forwarding etc), or other features (e.g. the = announcement capability mentioned in the forking use-case). Note that the procedures to actually activate/deactivate/control these feat= ures is outside the scope of the proxy-feature mechanism itself, and may ev= en require separate standardization (if e.g. new SIP/SDP information elemen= ts are needed) within the scope of another charter and/or WG. STUN/TURN server information: --------------------------------------- I haven't thought so much about this, but maybe the mechanism could be used= to inform users about STUN/TURN capabilities (STUN/TURN server addresses a= nd/or URIs to use for DNS etc). Outbound and multiple registration flows: --------------------------------------------------- When a user creates multiple registration flows, with multiple edge proxies= , different edge proxies may have different capabilities, and it may be use= ful for the UA and/or the registrar to know about them when choosing a flow= . Such capabilities could be related e.g. to security, NAT traversal etc. Also, a registrar could indicate the number of flows it has a capability to= handle. I think the use-cases fulfill the requirements that other entities are not = mandated to understand the capabilities. But, if they do, they provide smal= l pieces of building blocks that I believe can improve user experience and = session establishment optimization. I'm sure there are also questions related to these use-cases, and I don't c= laim to have all the answers. But, I do think it shows that there could als= o be general use-cases :) Some other potential use-cases: PBX: ------ Some people have indicated that the mechanism could be useful to indicate s= upport of PBX capabilities. I haven't studied that so much myself, but mayb= e those people could provide more information. Telepresence: ------------------ Also, in CLUE we are discussing the exchange of capabilities between differ= ent entities, but I think it's too early to say whether proxy-feature could= be useful there (it will depend on the amount of information to be exchang= ed - and which entities will exchange it). But, it COULD become a valid use= -case. >> On the question " One issue that remains fuzzy is distinguishing what is= and is not a valid proxy-feature", is the purpose of discussing this valid= ity to define the=20 >> requirements and procedure for registering such proxy-features with IANA= or is it more than that? > > That is the reason I ask. And of course it is related to the second part = of your prior comment. > > Lacking a clear definition to distinguish valid proxy-features from inval= id ones, I can't imagine approving any registration mechanism other than st= andards-action.=20 >(Standards-action follows the approach of "I can't define it but I know it= when I see it". Or you could say that it "crowd-sources" the decision.) There are already a number of requirements regarding the capability indicat= ion, e.g. that it must not be assumed that other entities support it etc. I= think it's quite difficult to say much more about the specific feature its= elf. There are different types of feature-tags defined for UAs. Also, in 3G= PP, at least one of the feature-tag (using to indicate support of alerting = SRVCC) is used both by UAs and proxies. Regards, Christer From alan.b.johnston@gmail.com Thu Mar 15 07:51:50 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB8821F8716 for ; Thu, 15 Mar 2012 07:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.261 X-Spam-Level: X-Spam-Status: No, score=-103.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FkzB8ZLuKF6f for ; Thu, 15 Mar 2012 07:51:50 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1591821F8712 for ; Thu, 15 Mar 2012 07:51:50 -0700 (PDT) Received: by yhkk25 with SMTP id k25so534763yhk.31 for ; Thu, 15 Mar 2012 07:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=h7j51Eh1IPAwnYLfGqsU1syUFBhiFqEwUOlVmjXQEus=; b=sC7rtfx3NpSkliQ2wI4EZIxWQqqFDjtkNOUTDYKW3YWS877MTZ7ck8RNExa+Y546rn DMdcwOJiNnp6arepL3qFCrFQfeHrPRNXQHT6QfYTZl3uGWzbrv2wKizgReLOUBueP0As RnBCwlK0OsH2ztdKxcsUK8qQQl8jHP4Vqij7dDZRk2LL1/rCJCvIeHQ++lGbUgYyFXQR qjC+RCKXzH8s1wUCXHO/D2L7XUxqL3WLUaLcylxV+p1qNOVvbiuVkOUBJgMcMqjpJa79 XgS0Nj0X9IXfV6sWq+off6EfHhttOWVkqvgky7aGl4JnsRHUcIzEB0/35GC7w2yzGd8B N73w== MIME-Version: 1.0 Received: by 10.182.227.37 with SMTP id rx5mr8262687obc.53.1331823109576; Thu, 15 Mar 2012 07:51:49 -0700 (PDT) Received: by 10.182.177.42 with HTTP; Thu, 15 Mar 2012 07:51:49 -0700 (PDT) Date: Thu, 15 Mar 2012 09:51:49 -0500 Message-ID: From: Alan Johnston To: sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [sipcore] Review of draft-ibc-sipcore-sip-websocket-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 14:51:51 -0000 All, Here is my review of draft-ibc-sipcore-wip-websocket-01. As Kevin has noted a number of grammar issues, I won't point any out right now. I would be happy to review the draft for this in the future if the authors would like. I look forward to this work progressing in SIPCORE, as I think it is important. - Alan - Since this draft will update RFC 3261, this should be stated on the first page. The abstract could include a few more details, such as that a new Via transport is defined, a new transport parameter for SIP/SIPS URIs, and a new SIP NAPTR parameter defined. It also could mention that this work relates to the WebRTC effort. The introduction should mention that SIP already has defined transports for UDP, TCP, and SCTP, and this draft extends RFC 3261 to add WS and WSS transport. The new SIP+D2W and SIPS+D2W NAPTRs should also be mentioned here. It would also be useful to refer to the RTCWEB overview, explaining that initial applications are likely to be SIP JavaScript UAs using the WebRTC model. Noting that this architecture has limitations that are discussed in this draft and put new requirements on UAs and Proxies that support WebSocket transport for SIP. To save some trees, please use the XML2RFC setting that doesn't start each section at the start of a new page. ;-) Section 3, the first paragraph has a list of what the WebSocket protocol defines - it would be clearer to make this a list as the punctuation makes this a bit unclear. At the Start of Section 4, it is worth saying that this begins the normative section of the document. In 5.1, mention that the ABNF being extended is from RFC 3261. Wasn't transport=TLS deprecated? I know it is commonly used. In 5.2, again say the ABNF extends the SIP/SIPS ABNF from RFC 3261. The second paragraph of 5.3 appears to be non-normative explanation, which is good. However, it should be indented to make this clear. Section 6 needs a bit of work. The reason for a MUST for Outbound is not clearly explained, and implementors sometimes ignore MUSTs that they don't understand. In Section 6, the reason why an invalid domain name is used should be more carefully explained. In Section 6, 4th paragraph, should reference RFC 3515 In Section 6, 6th paragraph is indented as if it is explanation but appears to have some normative text in it. Section 7, 2nd paragraph mentions a Websocket URI without domain. Is this really valid? Or do you mean a Websocket URI without a valid domain? In Section 8, is there a recommended registration interval? In Section 8.1, first paragraph. Is this normal GRUU/Outbound behavior? If so, is it necessary to state it here in normative language? Perhaps instead a non-normative explanation of why this behavior is critical for WS transport. Section 9.1, first paragraph has a "recommended" which I think should be RECOMMENDED Section 9.1, the second paragraph has some explanation text that should be indented. Section 10. Why is the time out of scope? Is it because we don't have enough implementation experience? Is it because of too many different environments? Are we sure that there will not be any bad interactions between all this different keepalives at different layers? Section 12.2 has some Contact URIs that span more than one line. The might be needed. From pkyzivat@alum.mit.edu Thu Mar 15 08:55:48 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF2D421F8736 for ; Thu, 15 Mar 2012 08:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 Vl6VBJXLXmI3 for ; Thu, 15 Mar 2012 08:55:37 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [76.96.62.16]) by ietfa.amsl.com (Postfix) with ESMTP id B74B821F8722 for ; Thu, 15 Mar 2012 08:55:35 -0700 (PDT) Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta01.westchester.pa.mail.comcast.net with comcast id lqMB1i00A1uE5Es51rvcFx; Thu, 15 Mar 2012 15:55:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id lrvb1i00r07duvL3crvbSq; Thu, 15 Mar 2012 15:55:36 +0000 Message-ID: <4F6210F6.4090001@alum.mit.edu> Date: Thu, 15 Mar 2012 11:55:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4F50FE6D.6050501@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C4137E2EB@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4137E2EB@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Dawes, Peter, VF-Group" , "sipcore@ietf.org" Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 15 Mar 2012 15:55:48 -0000 On 3/15/12 5:03 AM, Christer Holmberg wrote: > Hi Paul, > >>> I support wg adoption of the proxy-feature draft as this kind of solution is needed to allow a network to do the things >>> described in draft-ietf-sipcore-proxy-feature-reqs-03.txt. >> >>> On the question " Since many of us have struggled to understand the uses of this mechanism, it would be great if those of you who have uses would >>> describe them." do you believe that what is needed is more use cases than those listed in the reqs draft, or a more general idea of the value of a SIP >>> "feature node" indicating its capabilities to other SIP entities, or something else? For me, the use cases in the reqs are sufficient reason to work on the draft. >> >> I think it would be useful to have both more use cases (some that the rest of us can relate to), *and* more general explanation of what it means for >> a non-endpoint to have a feature that others need to know about. >> >> I am not saying that this can't proceed without that, but it will be more difficult, and without that we might end up with a draft that is understood >> and supported only by those building for IMS. > > What it means for a non-endpoint to have a feature needs to be described in the feature specification. I don't think there is a general explanation, other than "I can do capability X". Clearly it is the responsibility of each feature spec to describe what it means for a non-endpoint to have that particular feature. *Maybe* some added examples will be enough, but I keep hoping for a general > The req spec gives short explanations of the 3GPP use-cases. I also believe the 3GPP specs are generally available if one wants more information. > > However, there is nothing IMS specific with the mechanism as such, and I believe there are a number of general use-cases. But, I hope we don't expect 3GPP to come up with those. Not necessarily. Now that this is a wg draft we can ask for inputs from others. I would like to see that result in identification of more general capabilities. > Some examples, that I have been thinking about myself: These seem like a good starting point for identifying some. Thanks, Paul > Forking: > ---------- > > This is related to something I have spent quite much time on discussing with customers etc: how to ensure that incoming calls reach the correct device? > > When a user registers multiple devices associated with a single AoR, it is often difficult to know/ensure that incoming calls reach an appropriate device. In some cases, the problem could be solved if a UA had additional knowledge about its registrar's forking capabilities (support of RFC 3841 can already be indicated using an option-tag), and may impact on whether the user is going to register multiple devices in the first place, whether the user is going to generate local ringback tones/anouncements (maybe the registrar can indicate capability of doing it). > > > Automatic call handling (and other network features): > ------------------------------------------------------------------ > > Informing UAs about whether a network entity has the capability to provide automatic call handling (call forwarding etc), or other features (e.g. the announcement capability mentioned in the forking use-case). > > Note that the procedures to actually activate/deactivate/control these features is outside the scope of the proxy-feature mechanism itself, and may even require separate standardization (if e.g. new SIP/SDP information elements are needed) within the scope of another charter and/or WG. > > > STUN/TURN server information: > --------------------------------------- > > I haven't thought so much about this, but maybe the mechanism could be used to inform users about STUN/TURN capabilities (STUN/TURN server addresses and/or URIs to use for DNS etc). > > > > Outbound and multiple registration flows: > --------------------------------------------------- > > When a user creates multiple registration flows, with multiple edge proxies, different edge proxies may have different capabilities, and it may be useful for the UA and/or the registrar to know about them when choosing a flow. Such capabilities could be related e.g. to security, NAT traversal etc. > > Also, a registrar could indicate the number of flows it has a capability to handle. > > > I think the use-cases fulfill the requirements that other entities are not mandated to understand the capabilities. But, if they do, they provide small pieces of building blocks that I believe can improve user experience and session establishment optimization. > > I'm sure there are also questions related to these use-cases, and I don't claim to have all the answers. But, I do think it shows that there could also be general use-cases :) > > > > Some other potential use-cases: > > PBX: > ------ > > Some people have indicated that the mechanism could be useful to indicate support of PBX capabilities. I haven't studied that so much myself, but maybe those people could provide more information. > > > Telepresence: > ------------------ > > Also, in CLUE we are discussing the exchange of capabilities between different entities, but I think it's too early to say whether proxy-feature could be useful there (it will depend on the amount of information to be exchanged - and which entities will exchange it). But, it COULD become a valid use-case. > > >>> On the question " One issue that remains fuzzy is distinguishing what is and is not a valid proxy-feature", is the purpose of discussing this validity to define the >>> requirements and procedure for registering such proxy-features with IANA or is it more than that? >> >> That is the reason I ask. And of course it is related to the second part of your prior comment. >> >> Lacking a clear definition to distinguish valid proxy-features from invalid ones, I can't imagine approving any registration mechanism other than standards-action. >> (Standards-action follows the approach of "I can't define it but I know it when I see it". Or you could say that it "crowd-sources" the decision.) > > There are already a number of requirements regarding the capability indication, e.g. that it must not be assumed that other entities support it etc. I think it's quite difficult to say much more about the specific feature itself. There are different types of feature-tags defined for UAs. Also, in 3GPP, at least one of the feature-tag (using to indicate support of alerting SRVCC) is used both by UAs and proxies. > > Regards, > > Christer > > > > From pkyzivat@alum.mit.edu Thu Mar 15 09:18:48 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8F121F864F for ; Thu, 15 Mar 2012 09:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, J_CHICKENPOX_93=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2cdSU7tDMJg for ; Thu, 15 Mar 2012 09:18:47 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9722D21F863B for ; Thu, 15 Mar 2012 09:18:47 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta04.westchester.pa.mail.comcast.net with comcast id lsJf1i0031ZXKqc54sJo9z; Thu, 15 Mar 2012 16:18:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta21.westchester.pa.mail.comcast.net with comcast id lsJn1i01Q07duvL3hsJnGh; Thu, 15 Mar 2012 16:18:48 +0000 Message-ID: <4F621665.8060201@alum.mit.edu> Date: Thu, 15 Mar 2012 12:18:45 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Review of draft-ibc-sipcore-sip-websocket-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 16:18:48 -0000 Alan, Thanks for the thorough review. Regarding tree saving - does anyone actually *print* these things? Pixels come cheaper than trees. :-) Thanks, Paul On 3/15/12 10:51 AM, Alan Johnston wrote: > All, > > Here is my review of draft-ibc-sipcore-wip-websocket-01. As Kevin has > noted a number of grammar issues, I won't point any out right now. I > would be happy to review the draft for this in the future if the > authors would like. > > I look forward to this work progressing in SIPCORE, as I think it is important. > > - Alan - > > > Since this draft will update RFC 3261, this should be stated on the first page. > > The abstract could include a few more details, such as that a new Via > transport is defined, a new transport parameter for SIP/SIPS URIs, and > a new SIP NAPTR parameter defined. It also could mention that this > work relates to the WebRTC effort. > > The introduction should mention that SIP already has defined > transports for UDP, TCP, and SCTP, and this draft extends RFC 3261 to > add WS and WSS transport. The new SIP+D2W and SIPS+D2W NAPTRs should > also be mentioned here. It would also be useful to refer to the > RTCWEB overview, explaining that initial applications are likely to be > SIP JavaScript UAs using the WebRTC model. Noting that this > architecture has limitations that are discussed in this draft and put > new requirements on UAs and Proxies that support WebSocket transport > for SIP. > > To save some trees, please use the XML2RFC setting that doesn't start > each section at the start of a new page. ;-) > > Section 3, the first paragraph has a list of what the WebSocket > protocol defines - it would be clearer to make this a list as the > punctuation makes this a bit unclear. > > At the Start of Section 4, it is worth saying that this begins the > normative section of the document. > > In 5.1, mention that the ABNF being extended is from RFC 3261. > > Wasn't transport=TLS deprecated? I know it is commonly used. > > In 5.2, again say the ABNF extends the SIP/SIPS ABNF from RFC 3261. > > The second paragraph of 5.3 appears to be non-normative explanation, > which is good. However, it should be indented to make this clear. > > Section 6 needs a bit of work. The reason for a MUST for Outbound is > not clearly explained, and implementors sometimes ignore MUSTs that > they don't understand. > > In Section 6, the reason why an invalid domain name is used should be > more carefully explained. > > In Section 6, 4th paragraph, should reference RFC 3515 > > In Section 6, 6th paragraph is indented as if it is explanation but > appears to have some normative text in it. > > Section 7, 2nd paragraph mentions a Websocket URI without domain. Is > this really valid? Or do you mean a Websocket URI without a valid > domain? > > In Section 8, is there a recommended registration interval? > > In Section 8.1, first paragraph. Is this normal GRUU/Outbound > behavior? If so, is it necessary to state it here in normative > language? Perhaps instead a non-normative explanation of why this > behavior is critical for WS transport. > > Section 9.1, first paragraph has a "recommended" which I think should > be RECOMMENDED > > Section 9.1, the second paragraph has some explanation text that > should be indented. > > Section 10. Why is the time out of scope? Is it because we don't > have enough implementation experience? Is it because of too many > different environments? Are we sure that there will not be any bad > interactions between all this different keepalives at different > layers? > > Section 12.2 has some Contact URIs that span more than one line. The > might be needed. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pravindran@sonusnet.com Thu Mar 15 09:58:09 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC6E21F87CC for ; Thu, 15 Mar 2012 09:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.464 X-Spam-Level: X-Spam-Status: No, score=-4.464 tagged_above=-999 required=5 tests=[AWL=2.135, 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 j4PXxpRWJQya for ; Thu, 15 Mar 2012 09:58:08 -0700 (PDT) Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with ESMTP id 9861821F87C9 for ; Thu, 15 Mar 2012 09:58:07 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKT2IfngydvMcut8yv1U98d7jM4IARp2hV@postini.com; Thu, 15 Mar 2012 09:58:07 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 15 Mar 2012 12:58:17 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Thu, 15 Mar 2012 22:27:55 +0530 From: "Ravindran, Parthasarathi" To: Christer Holmberg , Paul Kyzivat , "Dawes, Peter, VF-Group" Thread-Topic: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft Thread-Index: AQHM+JcIkFrjhpowZkersvZzoej4AJZqx5GAgADfY9A= Date: Thu, 15 Mar 2012 16:57:54 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FD170@inba-mail01.sonusnet.com> References: <4F50FE6D.6050501@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C4137E2EB@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4137E2EB@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 15 Mar 2012 16:58:09 -0000 Hi Christer, Even though the title is proxy-feature, this specification applies informat= ion for both proxy and B2BUA. My doubt is whether this feature-tag applies = for UA whose Contact header field URI represents another SIP entity. Thanks Partha >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >Behalf Of Christer Holmberg >Sent: Thursday, March 15, 2012 2:33 PM >To: Paul Kyzivat; Dawes, Peter, VF-Group >Cc: sipcore@ietf.org >Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature >as a wgdraft > >Hi Paul, > >>> I support wg adoption of the proxy-feature draft as this kind of >>>solution is needed to allow a network to do the things described in >draft-ietf-sipcore-proxy-feature-reqs-03.txt. >> >>> On the question " Since many of us have struggled to understand the >>> uses of this mechanism, it would be great if those of you who have >>> uses would describe them." do you believe that what is needed is more >use cases than those listed in the reqs draft, or a more general idea of >the value of a SIP "feature node" indicating its capabilities to other >SIP entities, or something else? For me, the use cases in the reqs are >sufficient reason to work on the draft. >> >> I think it would be useful to have both more use cases (some that the >> rest of us can relate to), *and* more general explanation of what it >means for a non-endpoint to have a feature that others need to know >about. >> >> I am not saying that this can't proceed without that, but it will be >> more difficult, and without that we might end up with a draft that is >understood and supported only by those building for IMS. > >What it means for a non-endpoint to have a feature needs to be described >in the feature specification. I don't think there is a general >explanation, other than "I can do capability X". > >The req spec gives short explanations of the 3GPP use-cases. I also >believe the 3GPP specs are generally available if one wants more >information. > >However, there is nothing IMS specific with the mechanism as such, and I >believe there are a number of general use-cases. But, I hope we don't >expect 3GPP to come up with those. > >Some examples, that I have been thinking about myself: > >Forking: >---------- > >This is related to something I have spent quite much time on discussing >with customers etc: how to ensure that incoming calls reach the correct >device? > >When a user registers multiple devices associated with a single AoR, it >is often difficult to know/ensure that incoming calls reach an >appropriate device. In some cases, the problem could be solved if a UA >had additional knowledge about its registrar's forking capabilities >(support of RFC 3841 can already be indicated using an option-tag), and >may impact on whether the user is going to register multiple devices in >the first place, whether the user is going to generate local ringback >tones/anouncements (maybe the registrar can indicate capability of doing >it). > > >Automatic call handling (and other network features): >------------------------------------------------------------------ > >Informing UAs about whether a network entity has the capability to >provide automatic call handling (call forwarding etc), or other features >(e.g. the announcement capability mentioned in the forking use-case). > >Note that the procedures to actually activate/deactivate/control these >features is outside the scope of the proxy-feature mechanism itself, and >may even require separate standardization (if e.g. new SIP/SDP >information elements are needed) within the scope of another charter >and/or WG. > > >STUN/TURN server information: >--------------------------------------- > >I haven't thought so much about this, but maybe the mechanism could be >used to inform users about STUN/TURN capabilities (STUN/TURN server >addresses and/or URIs to use for DNS etc). > > > >Outbound and multiple registration flows: >--------------------------------------------------- > >When a user creates multiple registration flows, with multiple edge >proxies, different edge proxies may have different capabilities, and it >may be useful for the UA and/or the registrar to know about them when >choosing a flow. Such capabilities could be related e.g. to security, >NAT traversal etc. > >Also, a registrar could indicate the number of flows it has a capability >to handle. > > >I think the use-cases fulfill the requirements that other entities are >not mandated to understand the capabilities. But, if they do, they >provide small pieces of building blocks that I believe can improve user >experience and session establishment optimization. > >I'm sure there are also questions related to these use-cases, and I >don't claim to have all the answers. But, I do think it shows that there >could also be general use-cases :) > > > >Some other potential use-cases: > >PBX: >------ > >Some people have indicated that the mechanism could be useful to >indicate support of PBX capabilities. I haven't studied that so much >myself, but maybe those people could provide more information. > > >Telepresence: >------------------ > >Also, in CLUE we are discussing the exchange of capabilities between >different entities, but I think it's too early to say whether proxy- >feature could be useful there (it will depend on the amount of >information to be exchanged - and which entities will exchange it). But, >it COULD become a valid use-case. > > >>> On the question " One issue that remains fuzzy is distinguishing what >>> is and is not a valid proxy-feature", is the purpose of discussing >this validity to define the requirements and procedure for registering >such proxy-features with IANA or is it more than that? >> >> That is the reason I ask. And of course it is related to the second >part of your prior comment. >> >> Lacking a clear definition to distinguish valid proxy-features from >invalid ones, I can't imagine approving any registration mechanism other >than standards-action. >>(Standards-action follows the approach of "I can't define it but I know >>it when I see it". Or you could say that it "crowd-sources" the >>decision.) > >There are already a number of requirements regarding the capability >indication, e.g. that it must not be assumed that other entities support >it etc. I think it's quite difficult to say much more about the specific >feature itself. There are different types of feature-tags defined for >UAs. Also, in 3GPP, at least one of the feature-tag (using to indicate >support of alerting SRVCC) is used both by UAs and proxies. > >Regards, > >Christer > > > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From mary.ietf.barnes@gmail.com Thu Mar 15 12:23:41 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4359821F861D for ; Thu, 15 Mar 2012 12:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.376 X-Spam-Level: X-Spam-Status: No, score=-102.376 tagged_above=-999 required=5 tests=[AWL=-1.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666, 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 QCEqOvfHdoU9 for ; Thu, 15 Mar 2012 12:23:40 -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 2EBFC21F8621 for ; Thu, 15 Mar 2012 12:23:40 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so4278340vcb.31 for ; Thu, 15 Mar 2012 12:23:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=KtBhsMWkCat9z3BLvJ6flKVL2ORPDa1fNR+3sjUOH94=; b=G2nHe65TFAUhqH2/oX5VVIqIBh35ZrcN4ISBOqKYVstZz73zJsTxs4Ioh4RumyBv6a c1hulQg8PNUWZ4l8TQdtFtIFzbEUylJqFB5iyBtiN3QlYNpk9IK46NKqKsE9Gu7pm0tx WBZRmoN3W8rjChhNJrpuxuz/nEpxw04WQAcd2PQeDyDXuHwASatG1SYnldadyFQrBWd2 zrKw8nFnWRGa1I1W91tObAHwKKRaIH+GDUCDDiyzIkPL0x9Z4yQVnEuD3OWPB3htmzqr pFxiiCTWlMWdQkuQTWsWtDLxWWDEXWWvfYdvQqs8GcD1l5jD3bDJdyjEmi1qIt7lXYXO d97A== MIME-Version: 1.0 Received: by 10.52.97.225 with SMTP id ed1mr136379vdb.55.1331839419706; Thu, 15 Mar 2012 12:23:39 -0700 (PDT) Received: by 10.52.111.136 with HTTP; Thu, 15 Mar 2012 12:23:39 -0700 (PDT) In-Reply-To: <4F621665.8060201@alum.mit.edu> References: <4F621665.8060201@alum.mit.edu> Date: Thu, 15 Mar 2012 14:23:39 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=20cf307ac895826f6704bb4d077d Cc: sipcore@ietf.org Subject: Re: [sipcore] Review of draft-ibc-sipcore-sip-websocket-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:23:41 -0000 --20cf307ac895826f6704bb4d077d Content-Type: text/plain; charset=ISO-8859-1 I still print somethings, in particular when doing more "official" type reviews (e.g., WGLC, Review teams, etc.) as it is much easier to read a doc and mark things up with a red pen and then type the email summarizing things. I also will sometimes rethink some of my comments as I'm typing. I think my reviews are more thorough by doing it this way. This also gives me portability that doesn't require electronics. These docs are great to review while waiting at the DMV, doctors, carpool etc. I print 2 pages per sheet double sided so I'm wasting as little paper as possible. Mary. On Thu, Mar 15, 2012 at 11:18 AM, Paul Kyzivat wrote: > Alan, > > Thanks for the thorough review. > > Regarding tree saving - does anyone actually *print* these things? > Pixels come cheaper than trees. :-) > > Thanks, > Paul > > > On 3/15/12 10:51 AM, Alan Johnston wrote: > >> All, >> >> Here is my review of draft-ibc-sipcore-wip-**websocket-01. As Kevin has >> noted a number of grammar issues, I won't point any out right now. I >> would be happy to review the draft for this in the future if the >> authors would like. >> >> I look forward to this work progressing in SIPCORE, as I think it is >> important. >> >> - Alan - >> >> >> Since this draft will update RFC 3261, this should be stated on the first >> page. >> >> The abstract could include a few more details, such as that a new Via >> transport is defined, a new transport parameter for SIP/SIPS URIs, and >> a new SIP NAPTR parameter defined. It also could mention that this >> work relates to the WebRTC effort. >> >> The introduction should mention that SIP already has defined >> transports for UDP, TCP, and SCTP, and this draft extends RFC 3261 to >> add WS and WSS transport. The new SIP+D2W and SIPS+D2W NAPTRs should >> also be mentioned here. It would also be useful to refer to the >> RTCWEB overview, explaining that initial applications are likely to be >> SIP JavaScript UAs using the WebRTC model. Noting that this >> architecture has limitations that are discussed in this draft and put >> new requirements on UAs and Proxies that support WebSocket transport >> for SIP. >> >> To save some trees, please use the XML2RFC setting that doesn't start >> each section at the start of a new page. ;-) >> >> Section 3, the first paragraph has a list of what the WebSocket >> protocol defines - it would be clearer to make this a list as the >> punctuation makes this a bit unclear. >> >> At the Start of Section 4, it is worth saying that this begins the >> normative section of the document. >> >> In 5.1, mention that the ABNF being extended is from RFC 3261. >> >> Wasn't transport=TLS deprecated? I know it is commonly used. >> >> In 5.2, again say the ABNF extends the SIP/SIPS ABNF from RFC 3261. >> >> The second paragraph of 5.3 appears to be non-normative explanation, >> which is good. However, it should be indented to make this clear. >> >> Section 6 needs a bit of work. The reason for a MUST for Outbound is >> not clearly explained, and implementors sometimes ignore MUSTs that >> they don't understand. >> >> In Section 6, the reason why an invalid domain name is used should be >> more carefully explained. >> >> In Section 6, 4th paragraph, should reference RFC 3515 >> >> In Section 6, 6th paragraph is indented as if it is explanation but >> appears to have some normative text in it. >> >> Section 7, 2nd paragraph mentions a Websocket URI without domain. Is >> this really valid? Or do you mean a Websocket URI without a valid >> domain? >> >> In Section 8, is there a recommended registration interval? >> >> In Section 8.1, first paragraph. Is this normal GRUU/Outbound >> behavior? If so, is it necessary to state it here in normative >> language? Perhaps instead a non-normative explanation of why this >> behavior is critical for WS transport. >> >> Section 9.1, first paragraph has a "recommended" which I think should >> be RECOMMENDED >> >> Section 9.1, the second paragraph has some explanation text that >> should be indented. >> >> Section 10. Why is the time out of scope? Is it because we don't >> have enough implementation experience? Is it because of too many >> different environments? Are we sure that there will not be any bad >> interactions between all this different keepalives at different >> layers? >> >> Section 12.2 has some Contact URIs that span more than one line. The >> might be needed. >> ______________________________**_________________ >> 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 > --20cf307ac895826f6704bb4d077d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I still print somethings, in particular when doing more "official"= ; type reviews (e.g., WGLC, Review teams, etc.) as it is much easier to rea= d a doc and mark things up with a red pen and then type the email summarizi= ng things.=A0=A0I also will sometimes rethink some of my comments as I'= m typing. =A0=A0I think my reviews are more thorough by doing it this way. = =A0This also gives me portability that doesn't require electronics. =A0= These docs are great to review while waiting at the DMV, doctors, carpool e= tc. =A0I=A0print 2 pages per sheet double sided so I'm wasting as littl= e paper as possible.

Mary.

On Thu, Mar 15, 2012= at 11:18 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
Alan,

Thanks for the thorough review.

Regarding tree saving - does anyone actually *print* these things?
Pixels come cheaper than trees. :-)

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


On 3/15/12 10:51 AM, Alan Johnston wrote:
All,

Here is my review of draft-ibc-sipcore-wip-websocket-01. =A0As Kevin= has
noted a number of grammar issues, I won't point any out right now. =A0I=
would be happy to review the draft for this in the future if the
authors would like.

I look forward to this work progressing in SIPCORE, as I think it is import= ant.

- Alan -


Since this draft will update RFC 3261, this should be stated on the first p= age.

The abstract could include a few more details, such as that a new Via
transport is defined, a new transport parameter for SIP/SIPS URIs, and
a new SIP NAPTR parameter defined. =A0It also could mention that this
work relates to the WebRTC effort.

The introduction should mention that SIP already has defined
transports for UDP, TCP, and SCTP, and this draft extends RFC 3261 to
add WS and WSS transport. =A0The new SIP+D2W and SIPS+D2W NAPTRs should
also be mentioned here. =A0It would also be useful to refer to the
RTCWEB overview, explaining that initial applications are likely to be
SIP JavaScript UAs using the WebRTC model. =A0Noting that this
architecture has limitations that are discussed in this draft and put
new requirements on UAs and Proxies that support WebSocket transport
for SIP.

To save some trees, please use the XML2RFC setting that doesn't start each section at the start of a new page. ;-)

Section 3, the first paragraph has a list of what the WebSocket
protocol defines - it would be clearer to make this a list as the
punctuation makes this a bit unclear.

At the Start of Section 4, it is worth saying that this begins the
normative section of the document.

In 5.1, mention that the ABNF being extended is from RFC 3261.

Wasn't transport=3DTLS deprecated? =A0I know it is commonly used.

In 5.2, again say the ABNF extends the SIP/SIPS ABNF from RFC 3261.

The second paragraph of 5.3 appears to be non-normative explanation,
which is good. =A0However, it should be indented to make this clear.

Section 6 needs a bit of work. =A0The reason for a MUST for Outbound is
not clearly explained, and implementors sometimes ignore MUSTs that
they don't understand.

In Section 6, the reason why an invalid domain name is used should be
more carefully explained.

In Section 6, 4th paragraph, should reference RFC 3515

In Section 6, 6th paragraph is indented as if it is explanation but
appears to have some normative text in it.

Section 7, 2nd paragraph mentions a Websocket URI without domain. =A0Is
this really valid? =A0Or do you mean a Websocket URI without a valid
domain?

In Section 8, is there a recommended registration interval?

In Section 8.1, first paragraph. =A0Is this normal GRUU/Outbound
behavior? =A0If so, is it necessary to state it here in normative
language? =A0Perhaps instead a non-normative explanation of why this
behavior is critical for WS transport.

Section 9.1, first paragraph has a "recommended" which I think sh= ould
be RECOMMENDED

Section 9.1, the second paragraph has some explanation text that
should be indented.

Section 10. =A0Why is the time out of scope? =A0Is it because we don't<= br> have enough implementation experience? =A0Is it because of too many
different environments? =A0Are we sure that there will not be any bad
interactions between all this different keepalives at different
layers?

Section 12.2 has some Contact URIs that span more than one line. =A0The
<AllOneLine> =A0might be needed.
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore


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

--20cf307ac895826f6704bb4d077d-- From christer.holmberg@ericsson.com Thu Mar 15 12:38:47 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F04F21E8029 for ; Thu, 15 Mar 2012 12:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.255 X-Spam-Level: X-Spam-Status: No, score=-10.255 tagged_above=-999 required=5 tests=[AWL=0.344, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsZL0CRrawPV for ; Thu, 15 Mar 2012 12:38:46 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B757421F8523 for ; Thu, 15 Mar 2012 12:38:45 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-81-4f6245444deb Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 17.4D.27041.445426F4; Thu, 15 Mar 2012 20:38:44 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 15 Mar 2012 20:38:44 +0100 From: Christer Holmberg To: "Ravindran, Parthasarathi" , Paul Kyzivat , "Dawes, Peter, VF-Group" Date: Thu, 15 Mar 2012 20:34:08 +0100 Thread-Topic: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft Thread-Index: AQHM+JcIkFrjhpowZkersvZzoej4AJZqx5GAgADfY9CAAC0MlQ== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C411A5647@ESESSCMS0356.eemea.ericsson.se> References: <4F50FE6D.6050501@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C4137E2EB@ESESSCMS0356.eemea.ericsson.se>, <387F9047F55E8C42850AD6B3A7A03C6C0E1FD170@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E1FD170@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 15 Mar 2012 19:38:47 -0000 Hi, > Even though the title is proxy-feature, this specification applies inform= ation for both proxy and B2BUA.=20 Correct. We have discussed that earlier, and we may have to change to name = to avoid confusion. > My doubt is whether this feature-tag applies for UA whose Contact header = field URI represents another > SIP entity. Correct, if you by UA refer to an end device (not a B2BUA, or somthing simi= lar). I am not aware of a case where an end device would use a Contact head= er field that represents another entity. Regards, Christer >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >Behalf Of Christer Holmberg >Sent: Thursday, March 15, 2012 2:33 PM >To: Paul Kyzivat; Dawes, Peter, VF-Group >Cc: sipcore@ietf.org >Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature >as a wgdraft > >Hi Paul, > >>> I support wg adoption of the proxy-feature draft as this kind of >>>solution is needed to allow a network to do the things described in >draft-ietf-sipcore-proxy-feature-reqs-03.txt. >> >>> On the question " Since many of us have struggled to understand the >>> uses of this mechanism, it would be great if those of you who have >>> uses would describe them." do you believe that what is needed is more >use cases than those listed in the reqs draft, or a more general idea of >the value of a SIP "feature node" indicating its capabilities to other >SIP entities, or something else? For me, the use cases in the reqs are >sufficient reason to work on the draft. >> >> I think it would be useful to have both more use cases (some that the >> rest of us can relate to), *and* more general explanation of what it >means for a non-endpoint to have a feature that others need to know >about. >> >> I am not saying that this can't proceed without that, but it will be >> more difficult, and without that we might end up with a draft that is >understood and supported only by those building for IMS. > >What it means for a non-endpoint to have a feature needs to be described >in the feature specification. I don't think there is a general >explanation, other than "I can do capability X". > >The req spec gives short explanations of the 3GPP use-cases. I also >believe the 3GPP specs are generally available if one wants more >information. > >However, there is nothing IMS specific with the mechanism as such, and I >believe there are a number of general use-cases. But, I hope we don't >expect 3GPP to come up with those. > >Some examples, that I have been thinking about myself: > >Forking: >---------- > >This is related to something I have spent quite much time on discussing >with customers etc: how to ensure that incoming calls reach the correct >device? > >When a user registers multiple devices associated with a single AoR, it >is often difficult to know/ensure that incoming calls reach an >appropriate device. In some cases, the problem could be solved if a UA >had additional knowledge about its registrar's forking capabilities >(support of RFC 3841 can already be indicated using an option-tag), and >may impact on whether the user is going to register multiple devices in >the first place, whether the user is going to generate local ringback >tones/anouncements (maybe the registrar can indicate capability of doing >it). > > >Automatic call handling (and other network features): >------------------------------------------------------------------ > >Informing UAs about whether a network entity has the capability to >provide automatic call handling (call forwarding etc), or other features >(e.g. the announcement capability mentioned in the forking use-case). > >Note that the procedures to actually activate/deactivate/control these >features is outside the scope of the proxy-feature mechanism itself, and >may even require separate standardization (if e.g. new SIP/SDP >information elements are needed) within the scope of another charter >and/or WG. > > >STUN/TURN server information: >--------------------------------------- > >I haven't thought so much about this, but maybe the mechanism could be >used to inform users about STUN/TURN capabilities (STUN/TURN server >addresses and/or URIs to use for DNS etc). > > > >Outbound and multiple registration flows: >--------------------------------------------------- > >When a user creates multiple registration flows, with multiple edge >proxies, different edge proxies may have different capabilities, and it >may be useful for the UA and/or the registrar to know about them when >choosing a flow. Such capabilities could be related e.g. to security, >NAT traversal etc. > >Also, a registrar could indicate the number of flows it has a capability >to handle. > > >I think the use-cases fulfill the requirements that other entities are >not mandated to understand the capabilities. But, if they do, they >provide small pieces of building blocks that I believe can improve user >experience and session establishment optimization. > >I'm sure there are also questions related to these use-cases, and I >don't claim to have all the answers. But, I do think it shows that there >could also be general use-cases :) > > > >Some other potential use-cases: > >PBX: >------ > >Some people have indicated that the mechanism could be useful to >indicate support of PBX capabilities. I haven't studied that so much >myself, but maybe those people could provide more information. > > >Telepresence: >------------------ > >Also, in CLUE we are discussing the exchange of capabilities between >different entities, but I think it's too early to say whether proxy- >feature could be useful there (it will depend on the amount of >information to be exchanged - and which entities will exchange it). But, >it COULD become a valid use-case. > > >>> On the question " One issue that remains fuzzy is distinguishing what >>> is and is not a valid proxy-feature", is the purpose of discussing >this validity to define the requirements and procedure for registering >such proxy-features with IANA or is it more than that? >> >> That is the reason I ask. And of course it is related to the second >part of your prior comment. >> >> Lacking a clear definition to distinguish valid proxy-features from >invalid ones, I can't imagine approving any registration mechanism other >than standards-action. >>(Standards-action follows the approach of "I can't define it but I know >>it when I see it". Or you could say that it "crowd-sources" the >>decision.) > >There are already a number of requirements regarding the capability >indication, e.g. that it must not be assumed that other entities support >it etc. I think it's quite difficult to say much more about the specific >feature itself. There are different types of feature-tags defined for >UAs. Also, in 3GPP, at least one of the feature-tag (using to indicate >support of alerting SRVCC) is used both by UAs and proxies. > >Regards, > >Christer > > > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore= From pravindran@sonusnet.com Thu Mar 15 23:24:54 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FA621F86CF for ; Thu, 15 Mar 2012 23:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 HBNjZalAUCVi for ; Thu, 15 Mar 2012 23:24:53 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with ESMTP id C8DF221F86D0 for ; Thu, 15 Mar 2012 23:24:52 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT2LctH6XTeZWQITkMKC9GEKOw2umx0Se@postini.com; Thu, 15 Mar 2012 23:24:52 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 16 Mar 2012 02:25:02 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Fri, 16 Mar 2012 11:54:46 +0530 From: "Ravindran, Parthasarathi" To: Christer Holmberg , Paul Kyzivat , "Dawes, Peter, VF-Group" Thread-Topic: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft Thread-Index: AQHM+JcIkFrjhpowZkersvZzoej4AJZqx5GAgADfY9CAAC0MlYAAq/ng Date: Fri, 16 Mar 2012 06:24:46 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E1FD583@inba-mail01.sonusnet.com> References: <4F50FE6D.6050501@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C4137E2EB@ESESSCMS0356.eemea.ericsson.se>, <387F9047F55E8C42850AD6B3A7A03C6C0E1FD170@inba-mail01.sonusnet.com> <7F2072F1E0DE894DA4B517B93C6A05852C411A5647@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C411A5647@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.67] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature as a wgdraft X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 16 Mar 2012 06:24:54 -0000 Christer, Thanks for the clarification about proxy terminology change. UA is not required to be end-point and it shall be SIP-any protocol (PSTN, = H.323, RTCWeb) gateway. I asked this query as there should be no difference= in UAC behavior between B2BUA and UA.=20 Thanks Partha >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] >Sent: Friday, March 16, 2012 1:04 AM >To: Ravindran, Parthasarathi; Paul Kyzivat; Dawes, Peter, VF-Group >Cc: sipcore@ietf.org >Subject: RE: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature >as a wgdraft > >Hi, > >> Even though the title is proxy-feature, this specification applies >information for both proxy and B2BUA. > >Correct. We have discussed that earlier, and we may have to change to >name to avoid confusion. > >> My doubt is whether this feature-tag applies for UA whose Contact >header field URI represents another > SIP entity. > >Correct, if you by UA refer to an end device (not a B2BUA, or somthing >similar). I am not aware of a case where an end device would use a >Contact header field that represents another entity. > >Regards, > >Christer > > >>-----Original Message----- >>From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>Behalf Of Christer Holmberg >>Sent: Thursday, March 15, 2012 2:33 PM >>To: Paul Kyzivat; Dawes, Peter, VF-Group >>Cc: sipcore@ietf.org >>Subject: Re: [sipcore] Adoption of draft-holmberg-sipcore-proxy-feature >>as a wgdraft >> >>Hi Paul, >> >>>> I support wg adoption of the proxy-feature draft as this kind of >>>>solution is needed to allow a network to do the things described in >>draft-ietf-sipcore-proxy-feature-reqs-03.txt. >>> >>>> On the question " Since many of us have struggled to understand the >>>> uses of this mechanism, it would be great if those of you who have >>>> uses would describe them." do you believe that what is needed is >>>> more >>use cases than those listed in the reqs draft, or a more general idea >>of the value of a SIP "feature node" indicating its capabilities to >>other SIP entities, or something else? For me, the use cases in the >>reqs are sufficient reason to work on the draft. >>> >>> I think it would be useful to have both more use cases (some that the >>> rest of us can relate to), *and* more general explanation of what it >>means for a non-endpoint to have a feature that others need to know >>about. >>> >>> I am not saying that this can't proceed without that, but it will be >>> more difficult, and without that we might end up with a draft that is >>understood and supported only by those building for IMS. >> >>What it means for a non-endpoint to have a feature needs to be >>described in the feature specification. I don't think there is a >>general explanation, other than "I can do capability X". >> >>The req spec gives short explanations of the 3GPP use-cases. I also >>believe the 3GPP specs are generally available if one wants more >>information. >> >>However, there is nothing IMS specific with the mechanism as such, and >>I believe there are a number of general use-cases. But, I hope we don't >>expect 3GPP to come up with those. >> >>Some examples, that I have been thinking about myself: >> >>Forking: >>---------- >> >>This is related to something I have spent quite much time on discussing >>with customers etc: how to ensure that incoming calls reach the correct >>device? >> >>When a user registers multiple devices associated with a single AoR, it >>is often difficult to know/ensure that incoming calls reach an >>appropriate device. In some cases, the problem could be solved if a UA >>had additional knowledge about its registrar's forking capabilities >>(support of RFC 3841 can already be indicated using an option-tag), and >>may impact on whether the user is going to register multiple devices >>in the first place, whether the user is going to generate local >>ringback tones/anouncements (maybe the registrar can indicate >>capability of doing it). >> >> >>Automatic call handling (and other network features): >>------------------------------------------------------------------ >> >>Informing UAs about whether a network entity has the capability to >>provide automatic call handling (call forwarding etc), or other >>features (e.g. the announcement capability mentioned in the forking >use-case). >> >>Note that the procedures to actually activate/deactivate/control these >>features is outside the scope of the proxy-feature mechanism itself, >>and may even require separate standardization (if e.g. new SIP/SDP >>information elements are needed) within the scope of another charter >>and/or WG. >> >> >>STUN/TURN server information: >>--------------------------------------- >> >>I haven't thought so much about this, but maybe the mechanism could be >>used to inform users about STUN/TURN capabilities (STUN/TURN server >>addresses and/or URIs to use for DNS etc). >> >> >> >>Outbound and multiple registration flows: >>--------------------------------------------------- >> >>When a user creates multiple registration flows, with multiple edge >>proxies, different edge proxies may have different capabilities, and it >>may be useful for the UA and/or the registrar to know about them when >>choosing a flow. Such capabilities could be related e.g. to security, >>NAT traversal etc. >> >>Also, a registrar could indicate the number of flows it has a >>capability to handle. >> >> >>I think the use-cases fulfill the requirements that other entities are >>not mandated to understand the capabilities. But, if they do, they >>provide small pieces of building blocks that I believe can improve user >>experience and session establishment optimization. >> >>I'm sure there are also questions related to these use-cases, and I >>don't claim to have all the answers. But, I do think it shows that >>there could also be general use-cases :) >> >> >> >>Some other potential use-cases: >> >>PBX: >>------ >> >>Some people have indicated that the mechanism could be useful to >>indicate support of PBX capabilities. I haven't studied that so much >>myself, but maybe those people could provide more information. >> >> >>Telepresence: >>------------------ >> >>Also, in CLUE we are discussing the exchange of capabilities between >>different entities, but I think it's too early to say whether proxy- >>feature could be useful there (it will depend on the amount of >>information to be exchanged - and which entities will exchange it). >>But, it COULD become a valid use-case. >> >> >>>> On the question " One issue that remains fuzzy is distinguishing >>>> what is and is not a valid proxy-feature", is the purpose of >>>> discussing >>this validity to define the requirements and procedure for registering >>such proxy-features with IANA or is it more than that? >>> >>> That is the reason I ask. And of course it is related to the second >>part of your prior comment. >>> >>> Lacking a clear definition to distinguish valid proxy-features from >>invalid ones, I can't imagine approving any registration mechanism >>other than standards-action. >>>(Standards-action follows the approach of "I can't define it but I >>>know it when I see it". Or you could say that it "crowd-sources" the >>>decision.) >> >>There are already a number of requirements regarding the capability >>indication, e.g. that it must not be assumed that other entities >>support it etc. I think it's quite difficult to say much more about the >>specific feature itself. There are different types of feature-tags >>defined for UAs. Also, in 3GPP, at least one of the feature-tag (using >>to indicate support of alerting SRVCC) is used both by UAs and proxies. >> >>Regards, >> >>Christer >> >> >> >>_______________________________________________ >>sipcore mailing list >>sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore From alan.b.johnston@gmail.com Fri Mar 16 05:15:27 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0930621F86C9 for ; Fri, 16 Mar 2012 05:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.24 X-Spam-Level: X-Spam-Status: No, score=-103.24 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ss-JkGE7c+s2 for ; Fri, 16 Mar 2012 05:15:25 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB4C721F86C2 for ; Fri, 16 Mar 2012 05:15:25 -0700 (PDT) Received: by ggmi1 with SMTP id i1so4669829ggm.31 for ; Fri, 16 Mar 2012 05:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=F6o9cMyN5VEdaZUT0wg2cMfk7x0E4eMf84cpB6kVcwQ=; b=LTzywk/TEDDzDvhM0T/uj+Noyy6/fmwrgJlpuAEelzQizvW30zH47P3roUzakSOBd+ hQfNd4+leBVip353lI8UIMWYSFVYr8AOBNAQoTzfrceQv7WP15jPIe0YxezvgRu67RlC HO/41lME5lJLzTxcsYgLlYBMvq+J7hcCRE4ykHDdyAE8r3YRVHtV2dierjj2646fM7Fz WhTQyF9uGabaAABM6zFStoayJ4oNBVmSEAabMU9C5F8JRgjvcI82CIKnnXUN498s9r/a /Y4vOh4Zd+uR6Fl3Yn7ZVEKH6gAATq17jaQjb5NfmqDbiiAUrAvkTTpQhkKjSFryIKXm vldw== MIME-Version: 1.0 Received: by 10.60.6.164 with SMTP id c4mr2856366oea.43.1331900125271; Fri, 16 Mar 2012 05:15:25 -0700 (PDT) Received: by 10.182.177.42 with HTTP; Fri, 16 Mar 2012 05:15:25 -0700 (PDT) In-Reply-To: References: <4F621665.8060201@alum.mit.edu> Date: Fri, 16 Mar 2012 07:15:25 -0500 Message-ID: From: Alan Johnston To: Mary Barnes Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] Review of draft-ibc-sipcore-sip-websocket-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 12:15:27 -0000 I do print things, but only when I am proof reading. And I do print 2 pages per, 2 sides per page. Do you remember when Rohan generated a PDF of 4 pages per of every SIP related I-D for one meeting? ;-) I can't proof read on a screen - you miss too many things. I can proof read on a Kindle - if we had a nice XML2EPUB tool then I wouldn't need to ever print. - Alan - On Thu, Mar 15, 2012 at 2:23 PM, Mary Barnes w= rote: > I still print somethings, in particular when doing more "official" type > reviews (e.g., WGLC, Review teams, etc.) as it is much easier to read a d= oc > and mark things up with a red pen and then type the email summarizing > things.=A0=A0I also will sometimes rethink some of my comments as I'm typ= ing. > =A0=A0I think my reviews are more thorough by doing it this way. =A0This = also > gives me portability that doesn't require electronics. =A0These docs are = great > to review while waiting at the DMV, doctors, carpool etc. =A0I=A0print 2 = pages > per sheet double sided so I'm wasting as little paper as possible. > > Mary. > > On Thu, Mar 15, 2012 at 11:18 AM, Paul Kyzivat > wrote: >> >> Alan, >> >> Thanks for the thorough review. >> >> Regarding tree saving - does anyone actually *print* these things? >> Pixels come cheaper than trees. :-) >> >> =A0 =A0 =A0 =A0Thanks, >> =A0 =A0 =A0 =A0Paul >> >> >> On 3/15/12 10:51 AM, Alan Johnston wrote: >>> >>> All, >>> >>> Here is my review of draft-ibc-sipcore-wip-websocket-01. =A0As Kevin ha= s >>> noted a number of grammar issues, I won't point any out right now. =A0I >>> would be happy to review the draft for this in the future if the >>> authors would like. >>> >>> I look forward to this work progressing in SIPCORE, as I think it is >>> important. >>> >>> - Alan - >>> >>> >>> Since this draft will update RFC 3261, this should be stated on the fir= st >>> page. >>> >>> The abstract could include a few more details, such as that a new Via >>> transport is defined, a new transport parameter for SIP/SIPS URIs, and >>> a new SIP NAPTR parameter defined. =A0It also could mention that this >>> work relates to the WebRTC effort. >>> >>> The introduction should mention that SIP already has defined >>> transports for UDP, TCP, and SCTP, and this draft extends RFC 3261 to >>> add WS and WSS transport. =A0The new SIP+D2W and SIPS+D2W NAPTRs should >>> also be mentioned here. =A0It would also be useful to refer to the >>> RTCWEB overview, explaining that initial applications are likely to be >>> SIP JavaScript UAs using the WebRTC model. =A0Noting that this >>> architecture has limitations that are discussed in this draft and put >>> new requirements on UAs and Proxies that support WebSocket transport >>> for SIP. >>> >>> To save some trees, please use the XML2RFC setting that doesn't start >>> each section at the start of a new page. ;-) >>> >>> Section 3, the first paragraph has a list of what the WebSocket >>> protocol defines - it would be clearer to make this a list as the >>> punctuation makes this a bit unclear. >>> >>> At the Start of Section 4, it is worth saying that this begins the >>> normative section of the document. >>> >>> In 5.1, mention that the ABNF being extended is from RFC 3261. >>> >>> Wasn't transport=3DTLS deprecated? =A0I know it is commonly used. >>> >>> In 5.2, again say the ABNF extends the SIP/SIPS ABNF from RFC 3261. >>> >>> The second paragraph of 5.3 appears to be non-normative explanation, >>> which is good. =A0However, it should be indented to make this clear. >>> >>> Section 6 needs a bit of work. =A0The reason for a MUST for Outbound is >>> not clearly explained, and implementors sometimes ignore MUSTs that >>> they don't understand. >>> >>> In Section 6, the reason why an invalid domain name is used should be >>> more carefully explained. >>> >>> In Section 6, 4th paragraph, should reference RFC 3515 >>> >>> In Section 6, 6th paragraph is indented as if it is explanation but >>> appears to have some normative text in it. >>> >>> Section 7, 2nd paragraph mentions a Websocket URI without domain. =A0Is >>> this really valid? =A0Or do you mean a Websocket URI without a valid >>> domain? >>> >>> In Section 8, is there a recommended registration interval? >>> >>> In Section 8.1, first paragraph. =A0Is this normal GRUU/Outbound >>> behavior? =A0If so, is it necessary to state it here in normative >>> language? =A0Perhaps instead a non-normative explanation of why this >>> behavior is critical for WS transport. >>> >>> Section 9.1, first paragraph has a "recommended" which I think should >>> be RECOMMENDED >>> >>> Section 9.1, the second paragraph has some explanation text that >>> should be indented. >>> >>> Section 10. =A0Why is the time out of scope? =A0Is it because we don't >>> have enough implementation experience? =A0Is it because of too many >>> different environments? =A0Are we sure that there will not be any bad >>> interactions between all this different keepalives at different >>> layers? >>> >>> Section 12.2 has some Contact URIs that span more than one line. =A0The >>> =A0might be needed. >>> _______________________________________________ >>> 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 ibc@aliax.net Mon Mar 19 14:03:26 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A432A21E8029 for ; Mon, 19 Mar 2012 14:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.051, 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 kJ6NW7VruoBf for ; Mon, 19 Mar 2012 14:03:25 -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 8E73B21E801C for ; Mon, 19 Mar 2012 14:03:25 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so8167729vcb.31 for ; Mon, 19 Mar 2012 14:03:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=qwzVmypZCmVYGWwYBsFPQasYDUva4LZOWPoYE9h9JX4=; b=H3FnkEzmI1DwMFGstrYCHi9jXarnU631B4sZlGaOoO7u3V6CbALc0hXKAaWN/dVP4O y3iTM7V7MO5qQn1f7NAT468tL6m29li/sg4xUfJn7lilEOH8Q/SQAb69SmQ2cOatiS6Z qqUCntXOZckU3TvS3Oxwt8Dq0XrPVnHMofPSFml/0Awfpt6VTjNXJRb4AhTbp3T9bs/w zJmj0er61Fzdk9pYg3zXZAj5YY7rdpoWAB4UQyAxq1LvJxstCOIT9VtMpZ3W3pUGfjXd lCMaOtYtWyCh4y8cI3C2+uFC2qgviNmafHpQIyfrIvMzQ/P1RYXlu2CEgnO4dM5aO41n kglA== Received: by 10.52.65.239 with SMTP id a15mr6339246vdt.51.1332191005002; Mon, 19 Mar 2012 14:03:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Mon, 19 Mar 2012 14:03:04 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4137D763@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05852C4137D763@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 19 Mar 2012 22:03:04 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlmeCW9y5CMq3dtgFfiNwIgFwTYPRrG/JSpoNjYQRYHP9V63GqLcFgH5nASlVAo5XLgLLRw Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" , SIPCORE Chairs Subject: Re: [sipcore] Call for Reviewers: SIP WebSocket Transport - Christer's Review X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Mar 2012 21:03:26 -0000 2012/3/13 Christer Holmberg : > Below are my comments on the SIP WebSocket (WS) transport draft. My comme= nts are mainly related to the mandated SIP extensions and the relaxed 3261 = procedures. > > I also include some editorial comments, eventhough I realize those are pr= obably not the main focus of this specific review. > > (Some of the comments I already gave on an earlie version of the draft.) > > Also, eventhough I have some issues, I want to clarify that I in general= DO support adopting this work :) Thanks a lot for your review Christer, we appreciate it. > GENERAL: > ----------- > > Q_GEN_1: I think it would be good to explicitly indicate that the = draft only deals with SIP signaling, and that media transport is outside th= e scope of the document, and is expected to be transported using already st= andardized mechanisms (or, mechanisms standardized elsewhere). Makes sense, we'll include a note clarifying this. > Section 1: > ------------ > > Q_1-1: Add an RFC 6455 reference to "WebSocket Sub-Protocol". Sure, it will be added. > Section 4: > ------------ > > Q_4-1: I would suggest to add two sub-sections, one which contai= ns the general description of the sub-protocol, and one which contains the = procedures. Good idea, it will be included in the next revision. > Section 5.3: > -------------- > > Q_5_3-1: What does the following text mean? > > "This requires the server transport to maintain an association > between server transactions and transport connections." > > Q_5_3-2: The text says: > > "The SIP server transport uses the value of the top Via header fie= ld > in order to determine where to send a response. If the "sent- > protocol" is "WS" or "WSS" the response MUST be sent using the > existing WebSocket connection to the source of the original reques= t," > > I would suggest to simply say that SIP responses MUST be sent usin= g the same WebSocket connection on which the associated request was receive= d. > > Q_5_3-3: The text says: > > "If that connection is no longer open, the server MUST > NOT attempt to open a WebSocket connection to the Via "sent- > by"/"received"/"rport". " > > I would suggest to simply say that the server MUST NOT attempt to = re-open a WebSocket connection. All the above are adaptations from RFC3261-Section18.2.2 in order to meet the requirements imposed by the websocket nature. We'll follow-up on this in a separate thread along with some discussion on outbound applicability and keepalive mechanisms. > Section 6: > ------------ > > Q_6-1: Regarding the MUST implement Outbound. > > The text says: > > "Therefore clients and servers implementing SIP over the WebSocket > transport MUST implement the Outbound mechanism [RFC5626], being = this > the most suitable solution for SIP clients behind Network Address > Translation (NAT) using reliable transports for contacting SIP > servers." > > Therefore why? Because they may not know the WS address they MUST impleme= nt Outbound? Since WS servers can only perform "passive opens", ie; only a WS client can actively initiate a WS connection, servers shall reuse client-initiated connections to transmit SIP messages. Please see separate thread on outbound applicability. > Also, unless you intend to explicitly forbid it, I guess a WS connection = could be established between two SIP proxies. And, as they don't register, = they can't use Outbound. Please see the separate thread on outbound applicability. > Q_6-3: Why is there a SHOULD to implement GRUU? If you want that, you ne= ed some justification, and say how it is specific to the WS transport. Assuming that a SIP WS client cannot listen for incoming WS connection, the only way it can receive incoming requests is on top of the WS connection it has previously opened. If Alice (SIP WS client) is in a call with Bob (SIP UDP/TCP client) and Bob sends a REFER to Carol (SIP UDP/TCP client) whose "Refer-To" header contains the Contact of Alice, Carol could only reach Alice if the given Refer-To URI is a GRUU URI (so the INVITE from Carol would reach Alice's registrar and would use the Outbound connection of Alice to arrive to her). Please see the separate thread on outbound applicability. > Section 8.1: > -------------- > > Q_8_1-1: If the client application wants to become reachable again= , I guess it MUST (the text says SHOULD) create a new WS connection, unless= it has created additional WS connections using Outbound. Ok. > Section 10: > ------------- > > Q_10-1: In section 8.1 you say that a client SHOULD re-establish = the WS connection if it goes down, but in section 10 you say that the decis= ion whether to maintain the WS connection is outside the scope of the docum= ent. OK, the exact text says "The decision for a WebSocket endpoint to maintain, or not, the connection over time is out of scope of this document". With this we wanted to describe that the WS client MAY use of the Ping/Pong keepalive mechanism defined for the WebSocket protocol (which of course works at WebSocket level). This is a MAY since it's expected that some WS implementations (i.e. web browsers) decide by themself whether to use WS Ping/Pong or not. This is not negotiable at WebSocket protocol level. Any peer (client and/or server) can decide to send WS Ping frames so the remote peer must reply with WS Pong frame. Also the application level could be not aware of it. For example a JavaScript application is not aware of the WebSocket Ping/Pong usage by the browser or by the server. It's like a TCP keepalive (a TCP packet with no application data, so it does not reach the application level). This will be also discussed in the separate thread. > Q_10-2: The text says "a SIP server implementing the WebSocket transport = MUST support the CRLF Keep-Alive Technique.". In that case I guess it SHOUL= D/MUST also support the negotiation mechanism, as described in RFC 6223 (ev= enthough CRLF keep-alives can be sent without explicit support indication f= rom the receiving server). Good point. > Section 13.3: > --------------- > > Q_13_3-1: Do we really want to relax the 3261 procedures regarding = "received"? In my opinion topology hiding can be done as an implementation = thing - we don't need to specify it. > > Q_13_3-2: I don't understand the text regarding not honoring the "r= port" parameter. I guess you mean to say that the port number is not added.= But, again, I am not sure we should specify such things. Yes, maybe it is much better just to remove such a section and let it up to the implementor. > Q_13_3-3: If you are updating RFC 3261, by relaxing the usage of re= ceived etc, I think there should be a "Updates to RFC 3261" section name. Sure, it's clear that we need to properly comment those aspects in a well defined "Updates to RFC 3261" section. Thanks again for your comments. We'll include them in the next revision of the draft. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Mar 19 15:03:13 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2459921F86F8 for ; Mon, 19 Mar 2012 15:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.728 X-Spam-Level: X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nX0JSg6G1e8f for ; Mon, 19 Mar 2012 15:03:12 -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 D371121F86D8 for ; Mon, 19 Mar 2012 15:03:11 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so8220595vcb.31 for ; Mon, 19 Mar 2012 15:03:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=OX/pUzRtMwhdCpgFPgimGY669tw3gGCKzi0v/TAp4vM=; b=DATvvQ1Srszn75Xpm+5hTsnG6QCnnbZML5UMsbP1KNcEeTKVtcSUnJtlMHL1G8HQqh J4AuPTnOIl5VcSAQa5ssvehzj53z/6sNn3zg7VHTra4XVb899dHPfnFiyx5p5lAsUeol KytU6Je70ODUukisIJZ7NlvvRDgWjMNpo/YWtkxJIiOLK1mT6XIQEEJkVXnqtNM2lNOH FibxeNtiS5vbl4lwAl4ymOX2uZT8KQUTMzA2P/vFGierGy7oHWeed13Hdig0uqM4eves 1JK//r3RGU4e5Xwuai3kbeTmnYV0TWGMmXAuyV5zS0LfYExZh5o/QI9qE7JHAaYa5zTq fqng== Received: by 10.52.90.111 with SMTP id bv15mr6466498vdb.34.1332194591304; Mon, 19 Mar 2012 15:03:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Mon, 19 Mar 2012 15:02:51 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Mon, 19 Mar 2012 23:02:51 +0100 Message-ID: To: Alan Johnston Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnbExrkpM4Wv12LLA16i4bi6nny0j+/AAu2UYK1VmYpnBaFbBD/j0F0g0OXPp8gDH2loA7l Cc: sipcore@ietf.org Subject: Re: [sipcore] Review of draft-ibc-sipcore-sip-websocket-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 22:03:13 -0000 2012/3/15 Alan Johnston : > All, > > Here is my review of draft-ibc-sipcore-wip-websocket-01. =C2=A0As Kevin h= as > noted a number of grammar issues, I won't point any out right now. =C2=A0= I > would be happy to review the draft for this in the future if the > authors would like. > > I look forward to this work progressing in SIPCORE, as I think it is impo= rtant. > > - Alan - Alan, thanks a lot for your review. Comments inline: > Since this draft will update RFC 3261, this should be stated on the first= page. > > The abstract could include a few more details, such as that a new Via > transport is defined, a new transport parameter for SIP/SIPS URIs, and > a new SIP NAPTR parameter defined. =C2=A0It also could mention that this > work relates to the WebRTC effort. We took a view to http://tools.ietf.org/html/rfc4168 (SCTP transport for SIP). Its Abstract does not enter in so many details. Maybe our Abstract would become to long if we add all the points you mean? Maybe it would better to mention those details in the Introduction section? However we plan to add a new section "Updates to RFC 3261" on the beginning of the document. Would this be ok in your opinion? About the WebRTC effort, the fact is that we try to make this new SIP transport independent to WebRTC. WebRTC defines media communication and does not talk about the in-the-wire signaling protocol (which it's not mandated/defined by WebRTC). It's true that one of the possible usages of SIP over WebSocket is in web applications so both SIP over WebSocket and WebRTC would work together. However there could exist, for example, an smartphone application (a SIP sothphone) running SIP over UDP/TCP/TLS and using the WebRTC stack provided by the smartphone's operating system. > The introduction should mention that SIP already has defined > transports for UDP, TCP, and SCTP, and this draft extends RFC 3261 to > add WS and WSS transport. Right, it will be added. >=C2=A0The new SIP+D2W and SIPS+D2W NAPTRs should also be mentioned here. Could it be in a separate "Updates to RFC 3261 section"? This has been already suggested by other review. >=C2=A0It would also be useful to refer to the > RTCWEB overview, explaining that initial applications are likely to be > SIP JavaScript UAs using the WebRTC model. =C2=A0Noting that this > architecture has limitations that are discussed in this draft and put > new requirements on UAs and Proxies that support WebSocket transport > for SIP. It will be mentioned. Anyhow, as said above, we tryed to separate this specification from the context of web applications and WebRTC since its scope could be wider. > To save some trees, please use the XML2RFC setting that doesn't start > each section at the start of a new page. ;-) I see there is discussion about it, we must re-read it :) > Section 3, the first paragraph has a list of what the WebSocket > protocol defines - it would be clearer to make this a list as the > punctuation makes this a bit unclear. Ok. > At the Start of Section 4, it is worth saying that this begins the > normative section of the document. Good point, will be added. > In 5.1, mention that the ABNF being extended is from RFC 3261. Ok. > Wasn't transport=3DTLS deprecated? =C2=A0I know it is commonly used. We just copy&pasted the text in RFC 3261 and added "ws" transport, in the same way RFC 4168 adds "sctp" and keep the original text in RFC 3261. Should we remove "tls" from the list of transports? > In 5.2, again say the ABNF extends the SIP/SIPS ABNF from RFC 3261. Ok. > The second paragraph of 5.3 appears to be non-normative explanation, > which is good. =C2=A0However, it should be indented to make this clear. Perfect, it will be modified. > Section 6 needs a bit of work. =C2=A0The reason for a MUST for Outbound i= s > not clearly explained, and implementors sometimes ignore MUSTs that > they don't understand. Yes, please let's discuss about this stuf in a separate thread we'll started covering this exact subject. > In Section 6, the reason why an invalid domain name is used should be > more carefully explained. Ok. The reason is that some WS SIP clients (i.e. JavaScript applications running in a web browsers) have no way to find out their local IP:port from which the WS connection has been established. So instead of making up a random IP:port we suggest to use an invalid domain name. Such a domain does not matter at all if the SIP client uses Outbound. However we've realized that this is up to the implementor so we'll remove that text and will keep it just in the example 1 (which talks about a specific implementation based on a web application in which the proposed solution could make sense). > In Section 6, 4th paragraph, should reference RFC 3515 True. However given the received feedback about that section, we plan to remove it. > In Section 6, 6th paragraph is indented as if it is explanation but > appears to have some normative text in it. Will be fixed. > Section 7, 2nd paragraph mentions a Websocket URI without domain. =C2=A0I= s > this really valid? =C2=A0Or do you mean a Websocket URI without a valid > domain? We mean that, in case the WS URI has an IP (rather than a domain) then NAPTR/SRV procedures make no sense so the application must resolve the destination address/port by following section 3 in RFC 6455 (The WebSocket Protocol). > In Section 8, is there a recommended registration interval? No, and we don't suggest to use the re-registration process as a keepalive mechanism. For that we suggest using the WebSocket Ping/pong mechanism or keepalive mechanisms defined for SIP protocol. > In Section 8.1, first paragraph. =C2=A0Is this normal GRUU/Outbound > behavior? =C2=A0If so, is it necessary to state it here in normative > language? =C2=A0Perhaps instead a non-normative explanation of why this > behavior is critical for WS transport. Yes, we just tryed to tell the same as stated by RFC 5626 (Outbound). We'll take a look again to it after the discussion in a new thread. > Section 9.1, first paragraph has a "recommended" which I think should > be RECOMMENDED Ok. > Section 9.1, the second paragraph has some explanation text that > should be indented. True, good point. > Section 10. =C2=A0Why is the time out of scope? =C2=A0Is it because we do= n't > have enough implementation experience? =C2=A0Is it because of too many > different environments? =C2=A0Are we sure that there will not be any bad > interactions between all this different keepalives at different > layers? There should be no bad interactions between the WebSocket and the SIP layers even if both make usage of their keepalive mechanism. We have realized that some web browsers have a hardcoded interval for WebSocket Ping/Pong keepalive mechanism, while some other web browsers do not use such a mechanism (so using SIP level keepalive would be needed). It could also be possible that the WebServer decides to use the WS Ping/Pong keepalive mechanism. Therefore there are different posibilities and we cannot mandate a single one (since the application cannot always control the keepalive mechanism at WebSocket transport, i.e. in web browsers). > Section 12.2 has some Contact URIs that span more than one line. =C2=A0Th= e > might be needed. Will be fixed. Thanks a lot for your review. The draft will be improved taking into account all your given points. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Mar 20 02:49:15 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E4021F8711 for ; Tue, 20 Mar 2012 02:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_57=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 YypFHFQCFiRs for ; Tue, 20 Mar 2012 02:49:14 -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 434FA21F8700 for ; Tue, 20 Mar 2012 02:49:14 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so8682317vcb.31 for ; Tue, 20 Mar 2012 02:49:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=1ldc4faEcwO07sW9QEUUx21ZZhdMJs6A/LLPRHDVnb0=; b=kJK3uNWkpM9Zjp4vFI/PmRffOxGLYhNUPhQsu+hE9878DD3CewFW1JNf7bqfSKXOb7 JApd8+a0eewRYJT6RSDXO3g/m/24nWiMzeaMg6c767t1k6g+sU7i+AnTf382nX2JMwPJ hAUaT44iqYFSxar3RPy1XSl/zMwQTusLM5YXgSh9za2sUwjlqQsyLZVlab4Ew7i9TZh1 mIPd2qLv9zdTbmFL+5l7AuIVKgkI75jRiIGD9VoEuBNvyeJPSKzxUipSgNdpDWec4JS6 KNa+fkd4ho5zx2QJo5lnr7ZXtx5LybHY7XE08OIs2KZwyfSsx8HvgcRSUOpj9uJlXQeM oqYA== Received: by 10.220.140.196 with SMTP id j4mr6996221vcu.22.1332236953662; Tue, 20 Mar 2012 02:49:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 20 Mar 2012 02:48:53 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 20 Mar 2012 10:48:53 +0100 Message-ID: To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkFM9ucIIxdtZhAuSuIVFvNpU+PUcoJ8WCWx9WgR3oAwnn5ldPct92OvCYU0POxRcTPcVVQ Subject: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Mar 2012 09:49:15 -0000 Hi all, Given the received feedback on draft-ibc-sipcore-sip-websocket-01 we would like to open a new thread to discuss some aspects of the draft as the Outbound requirement or the assumed network architecture. About Outbound: ------------------------- Currently the draft mandates Outbound (and also GRUU) assuming that the SIP WebSocket transport would be used just by SIP clients running in web browsers and desktop/smartphone applications. In this scenario (which we still expect would be the most extended) those clients do not listen for incoming WebSocket connection and, instead, they establish a WebSocket connection with the WS server and mantain it for bidirectional communication (this is due to WebSocket protocol design). This scenario is very similar to SIP TCP/TLS clients behind NAT which require Outbound support. Therefore we assumed that Outbound should be mandatory in order to overcome this limitation. However we've realized that, by doing that, we are dictaminating a specific network architecture, and this is not the goal of our draft. Here we're just defining a new transport for the SIP protocol. Therefore, if the WG agrees with that, we will remove the Outbound/GRUU requirement from the draft, and we will cover the case of SIP entities capable of initiating and receiving WebSocket connections. We will mention that those clients that cannot listen for incoming connection (i.e. web browsers, smartphone apps) need to use one of the existing SIP mechanisms to receive incoming requests over the WebSocket connection they have open previously (Outbound is of course the best candidate for those SIP endpoints). Other nodes (not final devices) like proxies or servers that can only initiate outgoing WebSocket connections should also make use of an existing mechanism in order to get the incoming requests over the connection they have open (which basically means Connection Reuse - RFC 5923). And other SIP nodes capable of initiating and receiving WS connections would need no addition (as they behave like a SIP TCP/SCTP node). About GRUU: -------------------- For those SIP endpoints which don't listen for incoming WebSocket connections, GRUU is required. The following example attemps to justify it: - Alice (WS SIP UA) is in a call with Bob (SIP UDP UA). - Bob sends a REFER to Carol (SIP UDP UA) with "Refer-To: ALICE_CONTACT_URI= ". - Carol sends an INVITE to ALICE_CONTACT_URI. The only way in which the INVITE can arrive to Alice is the case in which ALICE_CONTACT_URI is a GRUU URI, so the INVITE would reach Alice's inbound proxy/registrar and that would route the request to Alice using the existing WebSocket connection (of course there could be an Outbound Edge proxy between Alice and the registrar). About Keepalive: ------------------------- WebSocket transport defines a keepalive mechanism based on WebSocket Ping frames which must be replied by the remote peer with a Pong frame. This is not negotiable, any peer can send a WS Ping to the peer and the peer must reply to it with a Pong. In some WebSocket implementations (web browsers) the application level (JavaScript) has no way to determine whether its WebSocket stack is sending or receiving Ping frames from/to the WS server. So using SIP keepalive could be a good idea. If the WS SIP endpoint implements Outbound then it's done. If it is a different client type it could then implement RFC 6233 (Indication of Support for Keep-Alive). So it's important to note that the draft cannot mandate or prohibit a specific keepalive mechanism, given the fact that some existing WebSocket implementations (web browsers) already make usage of the WebSocket Ping/Pong mechanism and that is not modifiable by the application layer (JavaScript). Other kind of clients (apps running in SO desktops or smartphones, or SIP proxies/servers) could decide a single keepalive mechanism (if they need it). About domain "xxxxx.invalid" in Via and Contact: ---------------------------------------------------------------------- The application layer in some WebSocket implementations (JavaScript in web browsers) has no way to determine the local IP address and port from which the browser has established the WebSocket connection with the server. Therefore we suggested in the draft the usage of xxxxx.invalid domain names (as stated in RFC 2606) for Via and Contact headers. However we have reconsidered it and plan to remove it from the draft. About topology hiding (RFC 3261 relaxed): ------------------------------------------------------------- Version 01 of the draft relaxes the requirement in RFC 3261 section 18.2.1 about adding a Via ;received parameter in SIP responses when the Via sent-by does not match the source IP. This is because the WebSocket connection reuses existing HTTP infrastructure in which there could be certain number of HTTP proxies and/or TCP load balancers between the client and the WebSocket server, so the source IP the server would write into the Via "received" parameter would be the IP of the HTTP/TCP intermediary in front of it, and that could reveal sensitive information about the internal topology of the provider network to the WebSocket client. As suggested in a received review, we consider that this decision is up to the implementor and should not be covered by the draft itself. Best regards. --=20 I=C3=B1aki Baz Castillo From pravindran@sonusnet.com Tue Mar 20 05:00:41 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E0421F8652 for ; Tue, 20 Mar 2012 05:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 HajkwiHcTrxB for ; Tue, 20 Mar 2012 05:00:40 -0700 (PDT) Received: from na3sys010aog109.obsmtp.com (na3sys010aog109.obsmtp.com [74.125.245.86]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA1A21F8649 for ; Tue, 20 Mar 2012 05:00:40 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob109.postini.com ([74.125.244.12]) with SMTP ID DSNKT2hxZ/szJ/JbWg/XPLIvnSt1q9fKMmVy@postini.com; Tue, 20 Mar 2012 05:00:40 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 20 Mar 2012 08:00:49 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 20 Mar 2012 17:30:29 +0530 From: "Ravindran, Parthasarathi" To: 'Mary Barnes' Thread-Topic: Editorial comment on draft-barnes-sipcore-rfc4244bis-callflows-02 Thread-Index: Ac0GkRYBpmCR4DovTOGVWmjUJ2RAOA== Date: Tue, 20 Mar 2012 12:00:28 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E2011BE@inba-mail01.sonusnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.54.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Kuwabara, Yoshikazu" , "sipcore@ietf.org" Subject: [sipcore] Editorial comment on draft-barnes-sipcore-rfc4244bis-callflows-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 12:00:41 -0000 Mary, For History-info examples with reason header, the delimiter between hname a= nd hvalue is shown as escaped character (%3B) instead of "=3D". The exact A= BNF as per RFC 3261 is as follows: headers =3D "?" header *( "&" header ) header =3D hname "=3D" hvalue In sec 3.1, F4, F5, F6, F7, F8 messages has History-Info: ;\ index=3D1.1 Has to be changed as: History-Info: ;\ index=3D1.1 Similar usage is seen in Sec 3.3 of F4,F5,F6, F7 messages: History-Info: ;\ index=3D1.1;rc=3D1 History-Info: ;\ index=3D1.2.1;rc=3D1.2 has to be changed as: History-Info: ;\ index=3D1.1;rc=3D1 History-Info: ;\ index=3D1.2.1;rc=3D1.2 Could you please let me know your opinion about these editorial comments. Thanks Partha From pkyzivat@alum.mit.edu Tue Mar 20 06:47:06 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F43821F8682 for ; Tue, 20 Mar 2012 06:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_57=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 r013Aa-i8Agx for ; Tue, 20 Mar 2012 06:47:06 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id C22F621F867A for ; Tue, 20 Mar 2012 06:47:05 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta09.westchester.pa.mail.comcast.net with comcast id npcq1i00517dt5G59pn6Lq; Tue, 20 Mar 2012 13:47:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta13.westchester.pa.mail.comcast.net with comcast id npn51i00R07duvL3Zpn5js; Tue, 20 Mar 2012 13:47:06 +0000 Message-ID: <4F688A57.8010700@alum.mit.edu> Date: Tue, 20 Mar 2012 09:47:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Mar 2012 13:47:06 -0000 Iñaki, Can you give a plausible example when sip-websocket would be used but Outbound would not be needed? Also, for those things that you are deciding to remove because they can be left to the implementer, please consider retaining them as hints/examples, e.g. in a non-normative appendix. You have already thought these things through, and some implementers who need them may not. Thanks, Paul On 3/20/12 5:48 AM, Iñaki Baz Castillo wrote: > Hi all, > > Given the received feedback on draft-ibc-sipcore-sip-websocket-01 we > would like to open a new thread to discuss some aspects of the draft > as the Outbound requirement or the assumed network architecture. > > > > > About Outbound: > ------------------------- > > Currently the draft mandates Outbound (and also GRUU) assuming that > the SIP WebSocket transport would be used just by SIP clients running > in web browsers and desktop/smartphone applications. In this scenario > (which we still expect would be the most extended) those clients do > not listen for incoming WebSocket connection and, instead, they > establish a WebSocket connection with the WS server and mantain it for > bidirectional communication (this is due to WebSocket protocol > design). > > This scenario is very similar to SIP TCP/TLS clients behind NAT which > require Outbound support. Therefore we assumed that Outbound should be > mandatory in order to overcome this limitation. > > However we've realized that, by doing that, we are dictaminating a > specific network architecture, and this is not the goal of our draft. > Here we're just defining a new transport for the SIP protocol. > > Therefore, if the WG agrees with that, we will remove the > Outbound/GRUU requirement from the draft, and we will cover the case > of SIP entities capable of initiating and receiving WebSocket > connections. We will mention that those clients that cannot listen for > incoming connection (i.e. web browsers, smartphone apps) need to use > one of the existing SIP mechanisms to receive incoming requests over > the WebSocket connection they have open previously (Outbound is of > course the best candidate for those SIP endpoints). Other nodes (not > final devices) like proxies or servers that can only initiate outgoing > WebSocket connections should also make use of an existing mechanism in > order to get the incoming requests over the connection they have open > (which basically means Connection Reuse - RFC 5923). And other SIP > nodes capable of initiating and receiving WS connections would need no > addition (as they behave like a SIP TCP/SCTP node). > > > > > About GRUU: > -------------------- > > For those SIP endpoints which don't listen for incoming WebSocket > connections, GRUU is required. The following example attemps to > justify it: > > - Alice (WS SIP UA) is in a call with Bob (SIP UDP UA). > - Bob sends a REFER to Carol (SIP UDP UA) with "Refer-To: ALICE_CONTACT_URI". > - Carol sends an INVITE to ALICE_CONTACT_URI. > > The only way in which the INVITE can arrive to Alice is the case in > which ALICE_CONTACT_URI is a GRUU URI, so the INVITE would reach > Alice's inbound proxy/registrar and that would route the request to > Alice using the existing WebSocket connection (of course there could > be an Outbound Edge proxy between Alice and the registrar). > > > > > About Keepalive: > ------------------------- > > WebSocket transport defines a keepalive mechanism based on WebSocket > Ping frames which must be replied by the remote peer with a Pong > frame. This is not negotiable, any peer can send a WS Ping to the peer > and the peer must reply to it with a Pong. > > In some WebSocket implementations (web browsers) the application level > (JavaScript) has no way to determine whether its WebSocket stack is > sending or receiving Ping frames from/to the WS server. So using SIP > keepalive could be a good idea. If the WS SIP endpoint implements > Outbound then it's done. If it is a different client type it could > then implement RFC 6233 (Indication of Support for Keep-Alive). > > So it's important to note that the draft cannot mandate or prohibit a > specific keepalive mechanism, given the fact that some existing > WebSocket implementations (web browsers) already make usage of the > WebSocket Ping/Pong mechanism and that is not modifiable by the > application layer (JavaScript). Other kind of clients (apps running in > SO desktops or smartphones, or SIP proxies/servers) could decide a > single keepalive mechanism (if they need it). > > > > > About domain "xxxxx.invalid" in Via and Contact: > ---------------------------------------------------------------------- > > The application layer in some WebSocket implementations (JavaScript in > web browsers) has no way to determine the local IP address and port > from which the browser has established the WebSocket connection with > the server. Therefore we suggested in the draft the usage of > xxxxx.invalid domain names (as stated in RFC 2606) for Via and Contact > headers. However we have reconsidered it and plan to remove it from > the draft. > > > > > About topology hiding (RFC 3261 relaxed): > ------------------------------------------------------------- > > Version 01 of the draft relaxes the requirement in RFC 3261 section > 18.2.1 about adding a Via ;received parameter in SIP responses when > the Via sent-by does not match the source IP. This is because the > WebSocket connection reuses existing HTTP infrastructure in which > there could be certain number of HTTP proxies and/or TCP load > balancers between the client and the WebSocket server, so the source > IP the server would write into the Via "received" parameter would be > the IP of the HTTP/TCP intermediary in front of it, and that could > reveal sensitive information about the internal topology of the > provider network to the WebSocket client. > > As suggested in a received review, we consider that this decision is > up to the implementor and should not be covered by the draft itself. > > > > > Best regards. > > From christer.holmberg@ericsson.com Tue Mar 20 07:10:30 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F148121F86DC for ; Tue, 20 Mar 2012 07:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.968 X-Spam-Level: X-Spam-Status: No, score=-9.968 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2609eVT9+Xb0 for ; Tue, 20 Mar 2012 07:10:28 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2687821F8698 for ; Tue, 20 Mar 2012 07:10:22 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-10-4f688fcec85d Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 5B.26.27041.ECF886F4; Tue, 20 Mar 2012 15:10:22 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Tue, 20 Mar 2012 15:10:22 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Date: Tue, 20 Mar 2012 15:10:21 +0100 Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) Thread-Index: Ac0Gn/KCimd/lDWnSL+iumNKBpy88AAALD6w Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se> References: <4F688A57.8010700@alum.mit.edu> In-Reply-To: <4F688A57.8010700@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Mar 2012 14:10:30 -0000 SGksDQoNCj4gQ2FuIHlvdSBnaXZlIGEgcGxhdXNpYmxlIGV4YW1wbGUgd2hlbiBzaXAtd2Vic29j a2V0IHdvdWxkIGJlIHVzZWQgYnV0IE91dGJvdW5kIHdvdWxkIG5vdCBiZSBuZWVkZWQ/DQoNCkkg YW0gbm90IEnDsWFraSwgYnV0IHNpbmNlIEkgYW0gb25lIHdobyBoYXMgZXhwcmVzc2VkIGNvbmNl cm5zIGFib3V0IG1hbmRhdGluZyBPdXRib3VuZCwgSSBjYW4gZ2l2ZSBzb21lIGlucHV0IDopDQoN CihKdXN0IGZvciB0aGUgcmVjb3JkLCB0aG91Z2gsIG5vdGUgdGhhdCBJIGRvbid0IGhhdmUgYW55 dGhpbmcgYWdhaW5zdCBPdXRib3VuZCBhcyBzdWNoLiAgSSBqdXN0IHRoaW5rIGl0IGlzIG91dHNp ZGUgdGhlIHNjb3BlIG9mIHRoZSB0cmFuc3BvcnQgc3BlY2lmaWNhdGlvbiB0byBtYW5kYXRlIGl0 LikNCg0KSXQgaXMgdHJ1ZSB0aGF0IGl0J3MgdGhlIFdTIGNsaWVudCB0aGF0IG5lZWRzIHRvIG1h aW50YWluIHRoZSBXUyBjb25uZWN0aW9uLiBCdXQsIE91dGJvdW5kIGlzIG5vdCBuZWVkZWQgZm9y IHRoYXQuIElmIG5lZWRlZCwgdGhlIGNsaWVudCBjYW4gbmVnb3RpYXRlIGtlZXAtYWxpdmVzIHVz aW5nIFJGQyA2MjIzICh5ZXMsIHRoZSBSRkMgZG9lcyByZWZlciB0byBPdXRib3VuZCBmb3IgdGhl IGtlZXAtYWxpdmUgbWVjaGFuaXNtLCBidXQgdGhhdCdzIG9ubHkgb25lIHBhcnQgb2YgT3V0Ym91 bmQsIGFuZCA2MjIzIG1hbmRhdGUgc3VwcG9ydCBvZiB0aGF0KSwgdW5sZXNzIHNvbWUgbG93ZXIg bGF5ZXIgbWVjaGFuaXNtIGluZm9ybWluZyAgdGhlIGNsaWVudCB0aGF0IHRoZSBXUyBjb25uZWN0 aW9uIGhhcyBnb25lIGRvd24gaXMgc3VmZmljaWVudCBlbm91Z2guDQoNCldoYXQgT3V0Ym91bmQg Z2l2ZXMgeW91IGluIGFkZGl0aW9uIGlzIHRoZSBwb3NzaWJpbGl0eSB0byByZWdpc3RlciBtdWx0 aXBsZSByZWdpc3RyYXRpb24gZmxvd3MsIHNvIHlvdSBjYW4gc3dpdGNoIHRvIGFub3RoZXIgaWYg b25lIGdvZXMgZG93bi4gVGhhdCdzIGEgZ29vZCBmZWF0dXJlLCBidXQgbm90aGluZyBJIHRoaW5r IHdlIHNob3VsZCBtYW5kYXRlIChJIGFtIGZpbmUgYnkgbWVudGlvbmluZyBpdCBpbiB0aGUgZHJh ZnQsIGFuZCBzYXkgYSBmZXcgd29yZHMgYWJvdXQgd2h5IGl0IGNvdWxkIGJlIHVzZWZ1bCwgdGhv dWdoKS4NCg0KQWxzbywgSSBkb24ndCB0aGluayB3ZSBuZWVkIE91dGJvdW5kIGluIG9yZGVyIHRv IHNheSB0aGF0IHJlcXVlc3RzIGZyb20gdGhlIHNlcnZlciB0byB0aGUgY2xpZW50IHNoYWxsIHVz ZSBhbiBleGlzdGluZyBXUyBjb25uZWN0aW9uIGZyb20gdGhlIGNsaWVudC4gDQoNCkFsc28sIG5v dGUgdGhhdCwgYXMgZmFyIGFzIEkgcmVtZW1iZXIsIE91dGJvdW5kIHJlcXVpcmVzIGEgU0lQIHJl Z2lzdHJhdGlvbiwgc28gbWFuZGF0aW5nIGl0IHdvdWxkIGJhc2ljYWxseSBzYXkgdGhhdCB3ZSBw cmV2ZW50IFNJUCB1c2UtY2FzZXMgd2l0aG91dCByZWdpc3RyYXRpb25zLg0KDQpIYXZpbmcgc2Fp ZCBhbGwgdGhhdCwgbWF5YmUgdGhlcmUgd2lsbCBiZSBzcGVjaWZpYyBwYXJ0cyBvZiBPdXRib3Vu ZCB0aGF0IHdlIG5lZWQgdG8gbWFuZGF0ZSwgYnV0IHRoZW4gd2Ugc2hvdWxkIG1hbmRhdGUgdGhv c2Ugc3BlY2lmaWMgcGFydHMuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KDQoNCg0KDQpP biAzLzIwLzEyIDU6NDggQU0sIEnDsWFraSBCYXogQ2FzdGlsbG8gd3JvdGU6DQo+IEhpIGFsbCwN Cj4NCj4gR2l2ZW4gdGhlIHJlY2VpdmVkIGZlZWRiYWNrIG9uIGRyYWZ0LWliYy1zaXBjb3JlLXNp cC13ZWJzb2NrZXQtMDEgd2UgDQo+IHdvdWxkIGxpa2UgdG8gb3BlbiBhIG5ldyB0aHJlYWQgdG8g ZGlzY3VzcyBzb21lIGFzcGVjdHMgb2YgdGhlIGRyYWZ0IA0KPiBhcyB0aGUgT3V0Ym91bmQgcmVx dWlyZW1lbnQgb3IgdGhlIGFzc3VtZWQgbmV0d29yayBhcmNoaXRlY3R1cmUuDQo+DQo+DQo+DQo+ DQo+IEFib3V0IE91dGJvdW5kOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+IEN1 cnJlbnRseSB0aGUgZHJhZnQgbWFuZGF0ZXMgT3V0Ym91bmQgKGFuZCBhbHNvIEdSVVUpIGFzc3Vt aW5nIHRoYXQgDQo+IHRoZSBTSVAgV2ViU29ja2V0IHRyYW5zcG9ydCB3b3VsZCBiZSB1c2VkIGp1 c3QgYnkgU0lQIGNsaWVudHMgcnVubmluZyANCj4gaW4gd2ViIGJyb3dzZXJzIGFuZCBkZXNrdG9w L3NtYXJ0cGhvbmUgYXBwbGljYXRpb25zLiBJbiB0aGlzIHNjZW5hcmlvIA0KPiAod2hpY2ggd2Ug c3RpbGwgZXhwZWN0IHdvdWxkIGJlIHRoZSBtb3N0IGV4dGVuZGVkKSB0aG9zZSBjbGllbnRzIGRv IA0KPiBub3QgbGlzdGVuIGZvciBpbmNvbWluZyBXZWJTb2NrZXQgY29ubmVjdGlvbiBhbmQsIGlu c3RlYWQsIHRoZXkgDQo+IGVzdGFibGlzaCBhIFdlYlNvY2tldCBjb25uZWN0aW9uIHdpdGggdGhl IFdTIHNlcnZlciBhbmQgbWFudGFpbiBpdCBmb3IgDQo+IGJpZGlyZWN0aW9uYWwgY29tbXVuaWNh dGlvbiAodGhpcyBpcyBkdWUgdG8gV2ViU29ja2V0IHByb3RvY29sIA0KPiBkZXNpZ24pLg0KPg0K PiBUaGlzIHNjZW5hcmlvIGlzIHZlcnkgc2ltaWxhciB0byBTSVAgVENQL1RMUyBjbGllbnRzIGJl aGluZCBOQVQgd2hpY2ggDQo+IHJlcXVpcmUgT3V0Ym91bmQgc3VwcG9ydC4gVGhlcmVmb3JlIHdl IGFzc3VtZWQgdGhhdCBPdXRib3VuZCBzaG91bGQgYmUgDQo+IG1hbmRhdG9yeSBpbiBvcmRlciB0 byBvdmVyY29tZSB0aGlzIGxpbWl0YXRpb24uDQo+DQo+IEhvd2V2ZXIgd2UndmUgcmVhbGl6ZWQg dGhhdCwgYnkgZG9pbmcgdGhhdCwgd2UgYXJlIGRpY3RhbWluYXRpbmcgYSANCj4gc3BlY2lmaWMg bmV0d29yayBhcmNoaXRlY3R1cmUsIGFuZCB0aGlzIGlzIG5vdCB0aGUgZ29hbCBvZiBvdXIgZHJh ZnQuDQo+IEhlcmUgd2UncmUganVzdCBkZWZpbmluZyBhIG5ldyB0cmFuc3BvcnQgZm9yIHRoZSBT SVAgcHJvdG9jb2wuDQo+DQo+IFRoZXJlZm9yZSwgaWYgdGhlIFdHIGFncmVlcyB3aXRoIHRoYXQs IHdlIHdpbGwgcmVtb3ZlIHRoZSANCj4gT3V0Ym91bmQvR1JVVSByZXF1aXJlbWVudCBmcm9tIHRo ZSBkcmFmdCwgYW5kIHdlIHdpbGwgY292ZXIgdGhlIGNhc2UgDQo+IG9mIFNJUCBlbnRpdGllcyBj YXBhYmxlIG9mIGluaXRpYXRpbmcgYW5kIHJlY2VpdmluZyBXZWJTb2NrZXQgDQo+IGNvbm5lY3Rp b25zLiBXZSB3aWxsIG1lbnRpb24gdGhhdCB0aG9zZSBjbGllbnRzIHRoYXQgY2Fubm90IGxpc3Rl biBmb3IgDQo+IGluY29taW5nIGNvbm5lY3Rpb24gKGkuZS4gd2ViIGJyb3dzZXJzLCBzbWFydHBo b25lIGFwcHMpIG5lZWQgdG8gdXNlIA0KPiBvbmUgb2YgdGhlIGV4aXN0aW5nIFNJUCBtZWNoYW5p c21zIHRvIHJlY2VpdmUgaW5jb21pbmcgcmVxdWVzdHMgb3ZlciANCj4gdGhlIFdlYlNvY2tldCBj b25uZWN0aW9uIHRoZXkgaGF2ZSBvcGVuIHByZXZpb3VzbHkgKE91dGJvdW5kIGlzIG9mIA0KPiBj b3Vyc2UgdGhlIGJlc3QgY2FuZGlkYXRlIGZvciB0aG9zZSBTSVAgZW5kcG9pbnRzKS4gT3RoZXIg bm9kZXMgKG5vdCANCj4gZmluYWwgZGV2aWNlcykgbGlrZSBwcm94aWVzIG9yIHNlcnZlcnMgdGhh dCBjYW4gb25seSBpbml0aWF0ZSBvdXRnb2luZyANCj4gV2ViU29ja2V0IGNvbm5lY3Rpb25zIHNo b3VsZCBhbHNvIG1ha2UgdXNlIG9mIGFuIGV4aXN0aW5nIG1lY2hhbmlzbSBpbiANCj4gb3JkZXIg dG8gZ2V0IHRoZSBpbmNvbWluZyByZXF1ZXN0cyBvdmVyIHRoZSBjb25uZWN0aW9uIHRoZXkgaGF2 ZSBvcGVuIA0KPiAod2hpY2ggYmFzaWNhbGx5IG1lYW5zIENvbm5lY3Rpb24gUmV1c2UgLSBSRkMg NTkyMykuIEFuZCBvdGhlciBTSVAgDQo+IG5vZGVzIGNhcGFibGUgb2YgaW5pdGlhdGluZyBhbmQg cmVjZWl2aW5nIFdTIGNvbm5lY3Rpb25zIHdvdWxkIG5lZWQgbm8gDQo+IGFkZGl0aW9uIChhcyB0 aGV5IGJlaGF2ZSBsaWtlIGEgU0lQIFRDUC9TQ1RQIG5vZGUpLg0KPg0KPg0KPg0KPg0KPiBBYm91 dCBHUlVVOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPiBGb3IgdGhvc2UgU0lQIGVuZHBv aW50cyB3aGljaCBkb24ndCBsaXN0ZW4gZm9yIGluY29taW5nIFdlYlNvY2tldCANCj4gY29ubmVj dGlvbnMsIEdSVVUgaXMgcmVxdWlyZWQuIFRoZSBmb2xsb3dpbmcgZXhhbXBsZSBhdHRlbXBzIHRv IA0KPiBqdXN0aWZ5IGl0Og0KPg0KPiAtIEFsaWNlIChXUyBTSVAgVUEpIGlzIGluIGEgY2FsbCB3 aXRoIEJvYiAoU0lQIFVEUCBVQSkuDQo+IC0gQm9iIHNlbmRzIGEgUkVGRVIgdG8gQ2Fyb2wgKFNJ UCBVRFAgVUEpIHdpdGggIlJlZmVyLVRvOiBBTElDRV9DT05UQUNUX1VSSSIuDQo+IC0gQ2Fyb2wg c2VuZHMgYW4gSU5WSVRFIHRvIEFMSUNFX0NPTlRBQ1RfVVJJLg0KPg0KPiBUaGUgb25seSB3YXkg aW4gd2hpY2ggdGhlIElOVklURSBjYW4gYXJyaXZlIHRvIEFsaWNlIGlzIHRoZSBjYXNlIGluIA0K PiB3aGljaCBBTElDRV9DT05UQUNUX1VSSSBpcyBhIEdSVVUgVVJJLCBzbyB0aGUgSU5WSVRFIHdv dWxkIHJlYWNoIA0KPiBBbGljZSdzIGluYm91bmQgcHJveHkvcmVnaXN0cmFyIGFuZCB0aGF0IHdv dWxkIHJvdXRlIHRoZSByZXF1ZXN0IHRvIA0KPiBBbGljZSB1c2luZyB0aGUgZXhpc3RpbmcgV2Vi U29ja2V0IGNvbm5lY3Rpb24gKG9mIGNvdXJzZSB0aGVyZSBjb3VsZCANCj4gYmUgYW4gT3V0Ym91 bmQgRWRnZSBwcm94eSBiZXR3ZWVuIEFsaWNlIGFuZCB0aGUgcmVnaXN0cmFyKS4NCj4NCj4NCj4N Cj4NCj4gQWJvdXQgS2VlcGFsaXZlOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+ IFdlYlNvY2tldCB0cmFuc3BvcnQgZGVmaW5lcyBhIGtlZXBhbGl2ZSBtZWNoYW5pc20gYmFzZWQg b24gV2ViU29ja2V0IA0KPiBQaW5nIGZyYW1lcyB3aGljaCBtdXN0IGJlIHJlcGxpZWQgYnkgdGhl IHJlbW90ZSBwZWVyIHdpdGggYSBQb25nIA0KPiBmcmFtZS4gVGhpcyBpcyBub3QgbmVnb3RpYWJs ZSwgYW55IHBlZXIgY2FuIHNlbmQgYSBXUyBQaW5nIHRvIHRoZSBwZWVyIA0KPiBhbmQgdGhlIHBl ZXIgbXVzdCByZXBseSB0byBpdCB3aXRoIGEgUG9uZy4NCj4NCj4gSW4gc29tZSBXZWJTb2NrZXQg aW1wbGVtZW50YXRpb25zICh3ZWIgYnJvd3NlcnMpIHRoZSBhcHBsaWNhdGlvbiBsZXZlbA0KPiAo SmF2YVNjcmlwdCkgaGFzIG5vIHdheSB0byBkZXRlcm1pbmUgd2hldGhlciBpdHMgV2ViU29ja2V0 IHN0YWNrIGlzIA0KPiBzZW5kaW5nIG9yIHJlY2VpdmluZyBQaW5nIGZyYW1lcyBmcm9tL3RvIHRo ZSBXUyBzZXJ2ZXIuIFNvIHVzaW5nIFNJUCANCj4ga2VlcGFsaXZlIGNvdWxkIGJlIGEgZ29vZCBp ZGVhLiBJZiB0aGUgV1MgU0lQIGVuZHBvaW50IGltcGxlbWVudHMgDQo+IE91dGJvdW5kIHRoZW4g aXQncyBkb25lLiBJZiBpdCBpcyBhIGRpZmZlcmVudCBjbGllbnQgdHlwZSBpdCBjb3VsZCANCj4g dGhlbiBpbXBsZW1lbnQgUkZDIDYyMzMgKEluZGljYXRpb24gb2YgU3VwcG9ydCBmb3IgS2VlcC1B bGl2ZSkuDQo+DQo+IFNvIGl0J3MgaW1wb3J0YW50IHRvIG5vdGUgdGhhdCB0aGUgZHJhZnQgY2Fu bm90IG1hbmRhdGUgb3IgcHJvaGliaXQgYSANCj4gc3BlY2lmaWMga2VlcGFsaXZlIG1lY2hhbmlz bSwgZ2l2ZW4gdGhlIGZhY3QgdGhhdCBzb21lIGV4aXN0aW5nIA0KPiBXZWJTb2NrZXQgaW1wbGVt ZW50YXRpb25zICh3ZWIgYnJvd3NlcnMpIGFscmVhZHkgbWFrZSB1c2FnZSBvZiB0aGUgDQo+IFdl YlNvY2tldCBQaW5nL1BvbmcgbWVjaGFuaXNtIGFuZCB0aGF0IGlzIG5vdCBtb2RpZmlhYmxlIGJ5 IHRoZSANCj4gYXBwbGljYXRpb24gbGF5ZXIgKEphdmFTY3JpcHQpLiBPdGhlciBraW5kIG9mIGNs aWVudHMgKGFwcHMgcnVubmluZyBpbiANCj4gU08gZGVza3RvcHMgb3Igc21hcnRwaG9uZXMsIG9y IFNJUCBwcm94aWVzL3NlcnZlcnMpIGNvdWxkIGRlY2lkZSBhIA0KPiBzaW5nbGUga2VlcGFsaXZl IG1lY2hhbmlzbSAoaWYgdGhleSBuZWVkIGl0KS4NCj4NCj4NCj4NCj4NCj4gQWJvdXQgZG9tYWlu ICJ4eHh4eC5pbnZhbGlkIiBpbiBWaWEgYW5kIENvbnRhY3Q6DQo+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4N Cj4gVGhlIGFwcGxpY2F0aW9uIGxheWVyIGluIHNvbWUgV2ViU29ja2V0IGltcGxlbWVudGF0aW9u cyAoSmF2YVNjcmlwdCBpbiANCj4gd2ViIGJyb3dzZXJzKSBoYXMgbm8gd2F5IHRvIGRldGVybWlu ZSB0aGUgbG9jYWwgSVAgYWRkcmVzcyBhbmQgcG9ydCANCj4gZnJvbSB3aGljaCB0aGUgYnJvd3Nl ciBoYXMgZXN0YWJsaXNoZWQgdGhlIFdlYlNvY2tldCBjb25uZWN0aW9uIHdpdGggDQo+IHRoZSBz ZXJ2ZXIuIFRoZXJlZm9yZSB3ZSBzdWdnZXN0ZWQgaW4gdGhlIGRyYWZ0IHRoZSB1c2FnZSBvZiAN Cj4geHh4eHguaW52YWxpZCBkb21haW4gbmFtZXMgKGFzIHN0YXRlZCBpbiBSRkMgMjYwNikgZm9y IFZpYSBhbmQgQ29udGFjdCANCj4gaGVhZGVycy4gSG93ZXZlciB3ZSBoYXZlIHJlY29uc2lkZXJl ZCBpdCBhbmQgcGxhbiB0byByZW1vdmUgaXQgZnJvbSANCj4gdGhlIGRyYWZ0Lg0KPg0KPg0KPg0K Pg0KPiBBYm91dCB0b3BvbG9neSBoaWRpbmcgKFJGQyAzMjYxIHJlbGF4ZWQpOg0KPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ DQo+IFZlcnNpb24gMDEgb2YgdGhlIGRyYWZ0IHJlbGF4ZXMgdGhlIHJlcXVpcmVtZW50IGluIFJG QyAzMjYxIHNlY3Rpb24NCj4gMTguMi4xIGFib3V0IGFkZGluZyBhIFZpYSA7cmVjZWl2ZWQgcGFy YW1ldGVyIGluIFNJUCByZXNwb25zZXMgd2hlbiANCj4gdGhlIFZpYSBzZW50LWJ5IGRvZXMgbm90 IG1hdGNoIHRoZSBzb3VyY2UgSVAuIFRoaXMgaXMgYmVjYXVzZSB0aGUgDQo+IFdlYlNvY2tldCBj b25uZWN0aW9uIHJldXNlcyBleGlzdGluZyBIVFRQIGluZnJhc3RydWN0dXJlIGluIHdoaWNoIA0K PiB0aGVyZSBjb3VsZCBiZSBjZXJ0YWluIG51bWJlciBvZiBIVFRQIHByb3hpZXMgYW5kL29yIFRD UCBsb2FkIA0KPiBiYWxhbmNlcnMgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgV2ViU29ja2V0 IHNlcnZlciwgc28gdGhlIHNvdXJjZSANCj4gSVAgdGhlIHNlcnZlciB3b3VsZCB3cml0ZSBpbnRv IHRoZSBWaWEgInJlY2VpdmVkIiBwYXJhbWV0ZXIgd291bGQgYmUgDQo+IHRoZSBJUCBvZiB0aGUg SFRUUC9UQ1AgaW50ZXJtZWRpYXJ5IGluIGZyb250IG9mIGl0LCBhbmQgdGhhdCBjb3VsZCANCj4g cmV2ZWFsIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgaW50ZXJuYWwgdG9wb2xvZ3kg b2YgdGhlIA0KPiBwcm92aWRlciBuZXR3b3JrIHRvIHRoZSBXZWJTb2NrZXQgY2xpZW50Lg0KPg0K PiBBcyBzdWdnZXN0ZWQgaW4gYSByZWNlaXZlZCByZXZpZXcsIHdlIGNvbnNpZGVyIHRoYXQgdGhp cyBkZWNpc2lvbiBpcyANCj4gdXAgdG8gdGhlIGltcGxlbWVudG9yIGFuZCBzaG91bGQgbm90IGJl IGNvdmVyZWQgYnkgdGhlIGRyYWZ0IGl0c2VsZi4NCj4NCj4NCj4NCj4NCj4gQmVzdCByZWdhcmRz Lg0KPg0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K From ibc@aliax.net Tue Mar 20 07:33:55 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEBB21F8438 for ; Tue, 20 Mar 2012 07:33:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.605 X-Spam-Level: X-Spam-Status: No, score=-2.605 tagged_above=-999 required=5 tests=[AWL=0.072, 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 5xiNVLKko-bQ for ; Tue, 20 Mar 2012 07:33:55 -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 3094321F8442 for ; Tue, 20 Mar 2012 07:33:44 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so106321vcb.31 for ; Tue, 20 Mar 2012 07:33:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=uVBOd4F5EpK8bUQlk4+GTJqhgDz2pI1knfjOs39g+Uk=; b=hpz/zNCleu/sdDD+OSlxJIrrTw9Zkg3Ku9s4yTO8dFqSGCt2isj0ATozUALk+bwAT/ 56BXbwqn5qjE1wILuWWl+n6Sp1FVNinfGm/8w1L38S4bd7xDlZTBdPnHWP7wHFzUgP7Z 1l10RwPqdbmsftlzFJNNq/gFNz51rM2MCgzC6E4U+HBTnXCtcLCvCSc1xtbRDhvUDx97 BIr+iyA2Bn0iazfriHP41HFrso12NL8HCj/mYNkYo4+uKBdQq9pf3UH1vW/OhVwJSCbg p2sgUj08Ja5PtUJYBQwxKkKEZMojnjA5OqLYF4hev5p41a6dXiNgZ0sj9Bz4XTpjpHfE 9TFA== Received: by 10.220.140.196 with SMTP id j4mr52830vcu.22.1332254023356; Tue, 20 Mar 2012 07:33:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 20 Mar 2012 07:33:23 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se> References: <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 20 Mar 2012 15:33:23 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl9RyVhYXhI1GnHrLJ9Ela/6DGi/d0vYDsfe+ZCpzF5TUWeNpnSsZGDQl5GWpaMGZQPAqSF Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Mar 2012 14:33:55 -0000 2012/3/20 Christer Holmberg : > I am not I=C3=B1aki, but since I am one who has expressed concerns about = mandating Outbound, I can give some input :) > > (Just for the record, though, note that I don't have anything against Out= bound as such. =C2=A0I just think it is outside the scope of the transport = specification to mandate it.) > > It is true that it's the WS client that needs to maintain the WS connecti= on. But, Outbound is not needed for that. If needed, the client can negotia= te keep-alives using RFC 6223 (yes, the RFC does refer to Outbound for the = keep-alive mechanism, but that's only one part of Outbound, and 6223 mandat= e support of that), unless some lower layer mechanism informing =C2=A0the c= lient that the WS connection has gone down is sufficient enough. > > What Outbound gives you in addition is the possibility to register multip= le registration flows, so you can switch to another if one goes down. That'= s a good feature, but nothing I think we should mandate (I am fine by menti= oning it in the draft, and say a few words about why it could be useful, th= ough). > > Also, I don't think we need Outbound in order to say that requests from t= he server to the client shall use an existing WS connection from the client= . > > Also, note that, as far as I remember, Outbound requires a SIP registrati= on, so mandating it would basically say that we prevent SIP use-cases witho= ut registrations. > > Having said all that, maybe there will be specific parts of Outbound that= we need to mandate, but then we should mandate those specific parts. I cannot improve the reply from Christer :) Just some comments: > Also, I don't think we need Outbound in order to say that requests from t= he server to the client shall use an existing WS connection from the client= . If the WebSocket SIP entity (whatever) does not listen for incoming connections then it needs Outbound or Connection Reuse (RFC 5923). Those are the only two standarized ways in which incoming requests would reuse the connection open by the WebSocket client. In the case of UAs (SIP endpoints) Outbound seems the complete solution. In the case of proxies/B2BUAs, RFC 5923 seems the choice. > maybe there will be specific parts of Outbound that we need to mandate, b= ut then we should mandate those specific parts. IMHO there is no need to mandate neither some specific parts of Outbound spec. If for example a SIP proxy/server is capable of opening and also listening for WebSocket connections, then the WebSocket transport becomes similar to what SIP over TCP or STCP involves. There is no need to reuse the initial WS connection for requests in reverse order, but just let the peer to open a new WS connection with us (same as TCP/SCTP when Outbound or RFC 5923 are not used). --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Mar 20 07:37:47 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F8B21F8498 for ; Tue, 20 Mar 2012 07:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zCnbifvN284 for ; Tue, 20 Mar 2012 07:37:46 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D55821F846B for ; Tue, 20 Mar 2012 07:37:46 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so41621wgb.13 for ; Tue, 20 Mar 2012 07:37:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=3WbCvKN7siJNPKpwIyofK7bzy2vB6lkIEzf4nLFShAA=; b=iJdeHgJBtTHFiHToR9I/S6b0O3vC9fsid0yfRdR8ye8OXG3oFXfsmppQHqdIUjpal1 8FWHXn1SHyjUrmY7RM9hE9Vvm0e3h2HGZbMMNGOy+5b9WhB95h9aaMle5Kc5UbpWHaxg Sd397xOZD0PQfH63B3TwX6GPWKpmV2RXTcxerthjYsN+4pAlhNrL5ZLK9djVhiytXH3D jj9VYUWwP1EN+MKl4/ePKrisCG/34Iy5WOtWVi2UoLz5aJUJ7d6UHok+io7Mi9cFLz5j zzHk/hD0LhCswy5F+qRpDBad2svvChSefj2vY/+EnV0n1F/PTpbZxJnjSTTJ3fjqx6fV jQRQ== Received: by 10.52.65.239 with SMTP id a15mr45891vdt.51.1332254265094; Tue, 20 Mar 2012 07:37:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 20 Mar 2012 07:37:24 -0700 (PDT) In-Reply-To: <4F688A57.8010700@alum.mit.edu> References: <4F688A57.8010700@alum.mit.edu> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 20 Mar 2012 15:37:24 +0100 Message-ID: To: Paul Kyzivat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkCK5Jeo+28DFkjGHEsRzjmgCq55sNdwmQ+rocdwvVizYKsLN/vk55P2ChMX611XA8ESkDL Cc: sipcore@ietf.org Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Mar 2012 14:37:47 -0000 2012/3/20 Paul Kyzivat : > Also, for those things that you are deciding to remove because they can b= e > left to the implementer, please consider retaining them as hints/examples= , > e.g. in a non-normative appendix. You have already thought these things > through, and some implementers who need them may not. That's a very good idea Paul. We could name such an appendix "Guidelines for implementors" and cover all those specific cases and suggestions. We will add it in a new revision of the draft. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Tue Mar 20 07:42:27 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D1821F856A for ; Tue, 20 Mar 2012 07:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_57=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 hJwwCKvU-VDI for ; Tue, 20 Mar 2012 07:42:26 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by ietfa.amsl.com (Postfix) with ESMTP id 94A7221F8565 for ; Tue, 20 Mar 2012 07:42:26 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id nn4V1i0031ei1Bg54qiTCb; Tue, 20 Mar 2012 14:42:27 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta24.westchester.pa.mail.comcast.net with comcast id nqiS1i01907duvL3kqiSpo; Tue, 20 Mar 2012 14:42:27 +0000 Message-ID: <4F689750.3000301@alum.mit.edu> Date: Tue, 20 Mar 2012 10:42:24 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Mar 2012 14:42:27 -0000 [as individual] On 3/20/12 10:10 AM, Christer Holmberg wrote: > Hi, > >> Can you give a plausible example when sip-websocket would be used but Outbound would not be needed? > > I am not Iñaki, but since I am one who has expressed concerns about mandating Outbound, I can give some input :) > > (Just for the record, though, note that I don't have anything against Outbound as such. I just think it is outside the scope of the transport specification to mandate it.) > > It is true that it's the WS client that needs to maintain the WS connection. But, Outbound is not needed for that. If needed, the client can negotiate keep-alives using RFC 6223 (yes, the RFC does refer to Outbound for the keep-alive mechanism, but that's only one part of Outbound, and 6223 mandate support of that), unless some lower layer mechanism informing the client that the WS connection has gone down is sufficient enough. > > What Outbound gives you in addition is the possibility to register multiple registration flows, so you can switch to another if one goes down. That's a good feature, but nothing I think we should mandate (I am fine by mentioning it in the draft, and say a few words about why it could be useful, though). > > Also, I don't think we need Outbound in order to say that requests from the server to the client shall use an existing WS connection from the client. Under what circumstances do you think this is not required? What other mechanism can be used to securely enable connection reuse? In principle it can be done, but it will require some added normative language somewhere to enable it. > Also, note that, as far as I remember, Outbound requires a SIP registration, so mandating it would basically say that we prevent SIP use-cases without registrations. Note that without registration you don't have GRUU. Without GRUU, what does the UA use for a Contact address, and how could that be associated with the same contact? Or are you considering cases where no out of dialog messages are supported in the reverse direction? Maybe there are some interesting cases. That is why I was asking for plausible examples. > Having said all that, maybe there will be specific parts of Outbound that we need to mandate, but then we should mandate those specific parts. Maybe. Thanks, Paul > Regards, > > Christer > > > > > > > On 3/20/12 5:48 AM, Iñaki Baz Castillo wrote: >> Hi all, >> >> Given the received feedback on draft-ibc-sipcore-sip-websocket-01 we >> would like to open a new thread to discuss some aspects of the draft >> as the Outbound requirement or the assumed network architecture. >> >> >> >> >> About Outbound: >> ------------------------- >> >> Currently the draft mandates Outbound (and also GRUU) assuming that >> the SIP WebSocket transport would be used just by SIP clients running >> in web browsers and desktop/smartphone applications. In this scenario >> (which we still expect would be the most extended) those clients do >> not listen for incoming WebSocket connection and, instead, they >> establish a WebSocket connection with the WS server and mantain it for >> bidirectional communication (this is due to WebSocket protocol >> design). >> >> This scenario is very similar to SIP TCP/TLS clients behind NAT which >> require Outbound support. Therefore we assumed that Outbound should be >> mandatory in order to overcome this limitation. >> >> However we've realized that, by doing that, we are dictaminating a >> specific network architecture, and this is not the goal of our draft. >> Here we're just defining a new transport for the SIP protocol. >> >> Therefore, if the WG agrees with that, we will remove the >> Outbound/GRUU requirement from the draft, and we will cover the case >> of SIP entities capable of initiating and receiving WebSocket >> connections. We will mention that those clients that cannot listen for >> incoming connection (i.e. web browsers, smartphone apps) need to use >> one of the existing SIP mechanisms to receive incoming requests over >> the WebSocket connection they have open previously (Outbound is of >> course the best candidate for those SIP endpoints). Other nodes (not >> final devices) like proxies or servers that can only initiate outgoing >> WebSocket connections should also make use of an existing mechanism in >> order to get the incoming requests over the connection they have open >> (which basically means Connection Reuse - RFC 5923). And other SIP >> nodes capable of initiating and receiving WS connections would need no >> addition (as they behave like a SIP TCP/SCTP node). >> >> >> >> >> About GRUU: >> -------------------- >> >> For those SIP endpoints which don't listen for incoming WebSocket >> connections, GRUU is required. The following example attemps to >> justify it: >> >> - Alice (WS SIP UA) is in a call with Bob (SIP UDP UA). >> - Bob sends a REFER to Carol (SIP UDP UA) with "Refer-To: ALICE_CONTACT_URI". >> - Carol sends an INVITE to ALICE_CONTACT_URI. >> >> The only way in which the INVITE can arrive to Alice is the case in >> which ALICE_CONTACT_URI is a GRUU URI, so the INVITE would reach >> Alice's inbound proxy/registrar and that would route the request to >> Alice using the existing WebSocket connection (of course there could >> be an Outbound Edge proxy between Alice and the registrar). >> >> >> >> >> About Keepalive: >> ------------------------- >> >> WebSocket transport defines a keepalive mechanism based on WebSocket >> Ping frames which must be replied by the remote peer with a Pong >> frame. This is not negotiable, any peer can send a WS Ping to the peer >> and the peer must reply to it with a Pong. >> >> In some WebSocket implementations (web browsers) the application level >> (JavaScript) has no way to determine whether its WebSocket stack is >> sending or receiving Ping frames from/to the WS server. So using SIP >> keepalive could be a good idea. If the WS SIP endpoint implements >> Outbound then it's done. If it is a different client type it could >> then implement RFC 6233 (Indication of Support for Keep-Alive). >> >> So it's important to note that the draft cannot mandate or prohibit a >> specific keepalive mechanism, given the fact that some existing >> WebSocket implementations (web browsers) already make usage of the >> WebSocket Ping/Pong mechanism and that is not modifiable by the >> application layer (JavaScript). Other kind of clients (apps running in >> SO desktops or smartphones, or SIP proxies/servers) could decide a >> single keepalive mechanism (if they need it). >> >> >> >> >> About domain "xxxxx.invalid" in Via and Contact: >> ---------------------------------------------------------------------- >> >> The application layer in some WebSocket implementations (JavaScript in >> web browsers) has no way to determine the local IP address and port >> from which the browser has established the WebSocket connection with >> the server. Therefore we suggested in the draft the usage of >> xxxxx.invalid domain names (as stated in RFC 2606) for Via and Contact >> headers. However we have reconsidered it and plan to remove it from >> the draft. >> >> >> >> >> About topology hiding (RFC 3261 relaxed): >> ------------------------------------------------------------- >> >> Version 01 of the draft relaxes the requirement in RFC 3261 section >> 18.2.1 about adding a Via ;received parameter in SIP responses when >> the Via sent-by does not match the source IP. This is because the >> WebSocket connection reuses existing HTTP infrastructure in which >> there could be certain number of HTTP proxies and/or TCP load >> balancers between the client and the WebSocket server, so the source >> IP the server would write into the Via "received" parameter would be >> the IP of the HTTP/TCP intermediary in front of it, and that could >> reveal sensitive information about the internal topology of the >> provider network to the WebSocket client. >> >> As suggested in a received review, we consider that this decision is >> up to the implementor and should not be covered by the draft itself. >> >> >> >> >> Best regards. >> >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Tue Mar 20 07:53:31 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E305521F85D4 for ; Tue, 20 Mar 2012 07:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.118 X-Spam-Level: X-Spam-Status: No, score=-10.118 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7BvpEryGN5c3 for ; Tue, 20 Mar 2012 07:53:31 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0429321F85D2 for ; Tue, 20 Mar 2012 07:53:30 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-6b-4f6899e983f6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B8.9F.27041.9E9986F4; Tue, 20 Mar 2012 15:53:30 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 20 Mar 2012 15:53:29 +0100 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Tue, 20 Mar 2012 15:53:29 +0100 Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) Thread-Index: Ac0GpnPIAJRnldFXSiuK9jkZhHY5XgAAS4pA Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> References: <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Mar 2012 14:53:32 -0000 SGksDQoNCj4+IEFsc28sIEkgZG9uJ3QgdGhpbmsgd2UgbmVlZCBPdXRib3VuZCBpbiBvcmRlciB0 byBzYXkgdGhhdCByZXF1ZXN0cyBmcm9tIHRoZSBzZXJ2ZXIgdG8gdGhlIGNsaWVudCBzaGFsbCB1 c2UgYW4gZXhpc3RpbmcgV1MgY29ubmVjdGlvbiBmcm9tIHRoZSBjbGllbnQuDQo+DQo+IElmIHRo ZSBXZWJTb2NrZXQgU0lQIGVudGl0eSAod2hhdGV2ZXIpIGRvZXMgbm90IGxpc3RlbiBmb3IgaW5j b21pbmcgY29ubmVjdGlvbnMgdGhlbiBpdCBuZWVkcyBPdXRib3VuZCBvciBDb25uZWN0aW9uIFJl dXNlIChSRkMgNTkyMykuDQo+IFRob3NlIGFyZSB0aGUgb25seSB0d28gc3RhbmRhcml6ZWQgd2F5 cyBpbiB3aGljaCBpbmNvbWluZyByZXF1ZXN0cyB3b3VsZCByZXVzZSB0aGUgY29ubmVjdGlvbiBv cGVuIGJ5IHRoZSBXZWJTb2NrZXQgY2xpZW50LiBJbiB0aGUgY2FzZSBvZiBVQXMgKFNJUCBlbmRw b2ludHMpIE91dGJvdW5kIHNlZW1zIHRoZSBjb21wbGV0ZSBzb2x1dGlvbi4gSW4gdGhlIGNhc2Ug b2YgcHJveGllcy9CMkJVQXMsIFJGQyA1OTIzIHNlZW1zIA0KPiB0aGUgY2hvaWNlLg0KDQpXZSBh cmUgZGVmaW5pbmcgdGhlIFdTIHRyYW5zcG9ydCBmb3IgU0lQLiBDYW4ndCB3ZSBzaW1wbHkgc2F5 IHRoYXQsIGJ5IGRlZmF1bHQsIGEgc2VydmVyIHNoYWxsIHVzZSBhbiBleGlzdGluZyBXUyBjb25u ZWN0aW9uIHRvd2FyZHMgdGhlIGNsaWVudD8gTm8gbmVlZCBmb3IgYW55IGV4dGVuc2lvbnMgdG8g bmVnb3RpYXRlIGl0Lg0KDQpPUiwgaWYgd2Ugd2FudCB0byBiZSBhYmxlIHRvIGV4cGxpY2l0bHkg cmVxdWVzdCByZXZlcnNlIGNvbm5lY3Rpb24gcmUtdXNlLCB3ZSBtYW5kYXRlIHRoZSB1c2FnZSBv ZiBSRkMgNTkyMyAodW5sZXNzIE91dGJvdW5kIGlzIGVuYWJsZWQpLCBidXQgc2F5IHRoYXQgYSBz ZXJ2ZXIgbXVzdCBPTkxZIHVzZSBhbiBleGlzdGluZyBjb25uZWN0aW9uLg0KDQo+IG1heWJlIHRo ZXJlIHdpbGwgYmUgc3BlY2lmaWMgcGFydHMgb2YgT3V0Ym91bmQgdGhhdCB3ZSBuZWVkIHRvIG1h bmRhdGUsIGJ1dCB0aGVuIHdlIHNob3VsZCBtYW5kYXRlIHRob3NlIHNwZWNpZmljIHBhcnRzLg0K DQo+IElNSE8gdGhlcmUgaXMgbm8gbmVlZCB0byBtYW5kYXRlIG5laXRoZXIgc29tZSBzcGVjaWZp YyBwYXJ0cyBvZiBPdXRib3VuZCBzcGVjLiBJZiBmb3IgZXhhbXBsZSBhIFNJUCBwcm94eS9zZXJ2 ZXIgaXMgY2FwYWJsZSBvZiBvcGVuaW5nIGFuZCBhbHNvIGxpc3RlbmluZyBmb3IgV2ViU29ja2V0 IGNvbm5lY3Rpb25zLCB0aGVuIHRoZSBXZWJTb2NrZXQgdHJhbnNwb3J0IGJlY29tZXMgc2ltaWxh ciB0byB3aGF0IFNJUCBvdmVyIFRDUCANCj4gb3IgU1RDUCBpbnZvbHZlcy4gVGhlcmUgaXMgbm8g bmVlZCB0byByZXVzZSB0aGUgaW5pdGlhbCBXUyBjb25uZWN0aW9uIGZvciByZXF1ZXN0cyBpbiBy ZXZlcnNlIG9yZGVyLCBidXQganVzdCBsZXQgdGhlIHBlZXIgdG8gb3BlbiBhIG5ldyBXUyBjb25u ZWN0aW9uIHdpdGggdXMgKHNhbWUgYXMgVENQL1NDVFAgd2hlbiBPdXRib3VuZCBvciBSRkMgNTky MyBhcmUgbm90IHVzZWQpLg0KDQpTdXJlLiANCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K From ibc@aliax.net Tue Mar 20 08:00:09 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85B721F8598 for ; Tue, 20 Mar 2012 08:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.607 X-Spam-Level: X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=0.070, 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 xmP-cP8WI3N3 for ; Tue, 20 Mar 2012 08:00:08 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id A85E521F85C0 for ; Tue, 20 Mar 2012 08:00:07 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so4600965wib.1 for ; Tue, 20 Mar 2012 08:00:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=pZSt8N3nP/BiBBvb4Vu9sqPYTc4+oq+pZN591sHQlTY=; b=BLAzKLO2BcNyuGz5ppgazI0eEbLuNppmkDemP5C4zrX1uf0+sbwaLlI1IGE9b8Unb7 8ZsN7hoo0IJBlGfZaACitj4V9hfQGcaWieKtKOG+FjKU7cKwL/aF3DrW/VFkBk83snPf oGVNF7rYJmJE6bBwd/COFVccvwAdXqrsYGIjxozmbsNfFMr73YgGzYlhIOHe2QSml29g dStwM+r4hpG9zfAU1Dew9Fuvg4rzlKY2PkH4986OL+2UftLB7xQjEfFQn99yzL54O3jL cpHmPMtoYfq7aHn1XQ8WlCXWyMWEPPn/O9p9rbdp8+q6iNNdq8WiDkLNqRq71ycAN9Br KGog== Received: by 10.52.90.111 with SMTP id bv15mr93834vdb.34.1332255605331; Tue, 20 Mar 2012 08:00:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 20 Mar 2012 07:59:45 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> References: <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 20 Mar 2012 15:59:45 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlldUhbELzXUBy8PCClVE4JVXCcOPNwsGPzcnPlyfpGNd9Dt7LuzngRzStqrN2uF3nFf6l7 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Mar 2012 15:00:10 -0000 2012/3/20 Christer Holmberg : >> If the WebSocket SIP entity (whatever) does not listen for incoming conn= ections then it needs Outbound or Connection Reuse (RFC 5923). >> Those are the only two standarized ways in which incoming requests would= reuse the connection open by the WebSocket client. In the case of UAs (SIP= endpoints) Outbound seems the complete solution. In the case of proxies/B2= BUAs, RFC 5923 seems >> the choice. > > We are defining the WS transport for SIP. Can't we simply say that, by de= fault, a server shall use an existing WS connection towards the client? No = need for any extensions to negotiate it. > > OR, if we want to be able to explicitly request reverse connection re-use= , we mandate the usage of RFC 5923 (unless Outbound is enabled), but say th= at a server must ONLY use an existing connection. That makes sense (and makes life easier to implementors). But in order to clarify, when you say "a server must ONLY use an existing connection" you mean "for sending responses", am I right? --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Tue Mar 20 08:03:04 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0037721F85D8 for ; Tue, 20 Mar 2012 08:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.97 X-Spam-Level: X-Spam-Status: No, score=-9.97 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ap2PsaginIKR for ; Tue, 20 Mar 2012 08:03:02 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C25AC21F8510 for ; Tue, 20 Mar 2012 08:03:01 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-18-4f689c24970a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1A.AA.17856.42C986F4; Tue, 20 Mar 2012 16:03:00 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 20 Mar 2012 16:03:00 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 20 Mar 2012 16:02:59 +0100 Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) Thread-Index: Ac0Gp6u5j3+kIfErS8W/JV7gXDdkMQAAZlXQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C41456F53@ESESSCMS0356.eemea.ericsson.se> References: <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se> <4F689750.3000301@alum.mit.edu> In-Reply-To: <4F689750.3000301@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Mar 2012 15:03:04 -0000 SGksDQoNCj4+PiBDYW4geW91IGdpdmUgYSBwbGF1c2libGUgZXhhbXBsZSB3aGVuIHNpcC13ZWJz b2NrZXQgd291bGQgYmUgdXNlZCBidXQgT3V0Ym91bmQgd291bGQgbm90IGJlIG5lZWRlZD8NCj4+ DQo+PiBJIGFtIG5vdCBJw7Fha2ksIGJ1dCBzaW5jZSBJIGFtIG9uZSB3aG8gaGFzIGV4cHJlc3Nl ZCBjb25jZXJucyBhYm91dCANCj4+IG1hbmRhdGluZyBPdXRib3VuZCwgSSBjYW4gZ2l2ZSBzb21l IGlucHV0IDopDQo+Pg0KPj4gKEp1c3QgZm9yIHRoZSByZWNvcmQsIHRob3VnaCwgbm90ZSB0aGF0 IEkgZG9uJ3QgaGF2ZSBhbnl0aGluZyBhZ2FpbnN0IA0KPj4gT3V0Ym91bmQgYXMgc3VjaC4gIEkg anVzdCB0aGluayBpdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgDQo+PiB0cmFuc3BvcnQg c3BlY2lmaWNhdGlvbiB0byBtYW5kYXRlIGl0LikNCj4+DQo+PiBJdCBpcyB0cnVlIHRoYXQgaXQn cyB0aGUgV1MgY2xpZW50IHRoYXQgbmVlZHMgdG8gbWFpbnRhaW4gdGhlIFdTIGNvbm5lY3Rpb24u IEJ1dCwgT3V0Ym91bmQgaXMgbm90IG5lZWRlZCBmb3IgdGhhdC4gSWYgbmVlZGVkLCB0aGUgY2xp ZW50IGNhbiBuZWdvdGlhdGUga2VlcC1hbGl2ZXMgdXNpbmcgDQo+PiBSRkMgNjIyMyAoeWVzLCB0 aGUgUkZDIGRvZXMgcmVmZXIgdG8gT3V0Ym91bmQgZm9yIHRoZSBrZWVwLWFsaXZlIG1lY2hhbmlz bSwgYnV0IHRoYXQncyBvbmx5IG9uZSBwYXJ0IG9mIE91dGJvdW5kLCBhbmQgNjIyMyBtYW5kYXRl IHN1cHBvcnQgb2YgdGhhdCksIHVubGVzcyBzb21lIA0KPj4gbG93ZXIgbGF5ZXIgbWVjaGFuaXNt IGluZm9ybWluZyAgdGhlIGNsaWVudCB0aGF0IHRoZSBXUyBjb25uZWN0aW9uIGhhcyBnb25lIGRv d24gaXMgc3VmZmljaWVudCBlbm91Z2guDQo+DQo+PiBXaGF0IE91dGJvdW5kIGdpdmVzIHlvdSBp biBhZGRpdGlvbiBpcyB0aGUgcG9zc2liaWxpdHkgdG8gcmVnaXN0ZXIgbXVsdGlwbGUgcmVnaXN0 cmF0aW9uIGZsb3dzLCBzbyB5b3UgY2FuIHN3aXRjaCB0byBhbm90aGVyIGlmIG9uZSBnb2VzIGRv d24uIFRoYXQncyBhIGdvb2QgZmVhdHVyZSwgDQo+PiBidXQgbm90aGluZyBJIHRoaW5rIHdlIHNo b3VsZCBtYW5kYXRlIChJIGFtIGZpbmUgYnkgbWVudGlvbmluZyBpdCBpbiB0aGUgZHJhZnQsIGFu ZCBzYXkgYSBmZXcgd29yZHMgYWJvdXQgd2h5IGl0IGNvdWxkIGJlIHVzZWZ1bCwgdGhvdWdoKS4N Cj4+DQo+PiBBbHNvLCBJIGRvbid0IHRoaW5rIHdlIG5lZWQgT3V0Ym91bmQgaW4gb3JkZXIgdG8g c2F5IHRoYXQgcmVxdWVzdHMgZnJvbSB0aGUgc2VydmVyIHRvIHRoZSBjbGllbnQgc2hhbGwgdXNl IGFuIGV4aXN0aW5nIFdTIGNvbm5lY3Rpb24gZnJvbSB0aGUgY2xpZW50Lg0KPg0KPiBVbmRlciB3 aGF0IGNpcmN1bXN0YW5jZXMgZG8geW91IHRoaW5rIHRoaXMgaXMgbm90IHJlcXVpcmVkPw0KPiBX aGF0IG90aGVyIG1lY2hhbmlzbSBjYW4gYmUgdXNlZCB0byBzZWN1cmVseSBlbmFibGUgY29ubmVj dGlvbiByZXVzZT8NCg0KMS4gV2Ugc3BlY2lmeSB0aGF0IGl0J3MgYWx3YXlzIGRvbmU7IG9yDQoN CjIuIFdlIG1hbmRhdGUgc3VwcG9ydCBvZiBSRkMgNTkyMw0KDQooTm90ZSB0aGF0IE91dGJvdW5k IGFsc28gcmVxdWlyZXMgc3VwcG9ydCBieSB0aGUgU0lQIHJlZ2lzdHJhciwgd2hpY2ggaXMgb3V0 c2lkZSB0aGUgc2NvcGUgb2YgdGhlIHNwZWNpZmljYXRpb24gLXVubGVzcyBpdCBhbHNvIGhhcHBl bnMgdG8gYmUgdGhlIFdTIHNlcnZlcikNCg0KPiBJbiBwcmluY2lwbGUgaXQgY2FuIGJlIGRvbmUs IGJ1dCBpdCB3aWxsIHJlcXVpcmUgc29tZSBhZGRlZCBub3JtYXRpdmUgbGFuZ3VhZ2Ugc29tZXdo ZXJlIHRvIGVuYWJsZSBpdC4NCg0KZHJhZnQtaWJjLXNpcGNvcmUtc2lwLXdlYnNvY2tldCBpcyBh IGdvb2QgY2FuZGlkYXRlIGZvciBzdWNoIHRleHQgOikNCg0KDQo+PiBBbHNvLCBub3RlIHRoYXQs IGFzIGZhciBhcyBJIHJlbWVtYmVyLCBPdXRib3VuZCByZXF1aXJlcyBhIFNJUCByZWdpc3RyYXRp b24sIHNvIG1hbmRhdGluZyBpdCB3b3VsZCBiYXNpY2FsbHkgc2F5IHRoYXQgd2UgcHJldmVudCBT SVAgdXNlLWNhc2VzIHdpdGhvdXQgcmVnaXN0cmF0aW9ucy4NCj4NCj4gTm90ZSB0aGF0IHdpdGhv dXQgcmVnaXN0cmF0aW9uIHlvdSBkb24ndCBoYXZlIEdSVVUuDQoNCkNvcnJlY3QuIFNvLCB3ZSBu ZWVkIHRvIGZpZ3VyZSBvdXQgaWYgdGhpbmdzIHdvcmsgd2l0aG91dCBHUlVVLg0KDQo+IFdpdGhv dXQgR1JVVSwgd2hhdCBkb2VzIHRoZSBVQSB1c2UgZm9yIGEgQ29udGFjdCBhZGRyZXNzLCBhbmQg aG93IGNvdWxkIHRoYXQgYmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBzYW1lIGNvbnRhY3Q/DQo+DQo+ IE9yIGFyZSB5b3UgY29uc2lkZXJpbmcgY2FzZXMgd2hlcmUgbm8gb3V0IG9mIGRpYWxvZyBtZXNz YWdlcyBhcmUgc3VwcG9ydGVkIGluIHRoZSByZXZlcnNlIGRpcmVjdGlvbj8NCj4NCj4gTWF5YmUg dGhlcmUgYXJlIHNvbWUgaW50ZXJlc3RpbmcgY2FzZXMuIFRoYXQgaXMgd2h5IEkgd2FzIGFza2lu ZyBmb3IgcGxhdXNpYmxlIGV4YW1wbGVzLg0KDQpJIGFtIGFza2luZyBmb3IgdHJhbnNwb3J0IHNw ZWNpZmljIHJlYXNvbnMgdG8gbWFuZGF0ZSBHUlVVLiBNYXliZSB0aGVyZSBhcmUgc29tZSBTSVAg YXBwbGljYXRpb24gbGV2ZWwgdXNlLWNhc2VzIHRoYXQgZG9uJ3Qgd29yayB3aXRob3V0IEdSVVUs IGJ1dCB0aGF0IGNvdWxkIGJlIHRydWUgZm9yIGFueSB0cmFuc3BvcnQuDQoNCk1heWJlIHRoZXJl IGlzIGEgbmVlZCB0byBtYW5kYXRlIEdSVVUsIGJ1dCBJIGFsc28gd2FudCBtb3JlIGp1c3RpZmlj YXRpb24gOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg0KPiBPbiAzLzIwLzEyIDU6 NDggQU0sIEnDsWFraSBCYXogQ2FzdGlsbG8gd3JvdGU6DQo+PiBIaSBhbGwsDQo+Pg0KPj4gR2l2 ZW4gdGhlIHJlY2VpdmVkIGZlZWRiYWNrIG9uIGRyYWZ0LWliYy1zaXBjb3JlLXNpcC13ZWJzb2Nr ZXQtMDEgd2UgDQo+PiB3b3VsZCBsaWtlIHRvIG9wZW4gYSBuZXcgdGhyZWFkIHRvIGRpc2N1c3Mg c29tZSBhc3BlY3RzIG9mIHRoZSBkcmFmdCANCj4+IGFzIHRoZSBPdXRib3VuZCByZXF1aXJlbWVu dCBvciB0aGUgYXNzdW1lZCBuZXR3b3JrIGFyY2hpdGVjdHVyZS4NCj4+DQo+Pg0KPj4NCj4+DQo+ PiBBYm91dCBPdXRib3VuZDoNCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+PiBD dXJyZW50bHkgdGhlIGRyYWZ0IG1hbmRhdGVzIE91dGJvdW5kIChhbmQgYWxzbyBHUlVVKSBhc3N1 bWluZyB0aGF0IA0KPj4gdGhlIFNJUCBXZWJTb2NrZXQgdHJhbnNwb3J0IHdvdWxkIGJlIHVzZWQg anVzdCBieSBTSVAgY2xpZW50cyBydW5uaW5nIA0KPj4gaW4gd2ViIGJyb3dzZXJzIGFuZCBkZXNr dG9wL3NtYXJ0cGhvbmUgYXBwbGljYXRpb25zLiBJbiB0aGlzIHNjZW5hcmlvIA0KPj4gKHdoaWNo IHdlIHN0aWxsIGV4cGVjdCB3b3VsZCBiZSB0aGUgbW9zdCBleHRlbmRlZCkgdGhvc2UgY2xpZW50 cyBkbyANCj4+IG5vdCBsaXN0ZW4gZm9yIGluY29taW5nIFdlYlNvY2tldCBjb25uZWN0aW9uIGFu ZCwgaW5zdGVhZCwgdGhleSANCj4+IGVzdGFibGlzaCBhIFdlYlNvY2tldCBjb25uZWN0aW9uIHdp dGggdGhlIFdTIHNlcnZlciBhbmQgbWFudGFpbiBpdCANCj4+IGZvciBiaWRpcmVjdGlvbmFsIGNv bW11bmljYXRpb24gKHRoaXMgaXMgZHVlIHRvIFdlYlNvY2tldCBwcm90b2NvbCANCj4+IGRlc2ln bikuDQo+Pg0KPj4gVGhpcyBzY2VuYXJpbyBpcyB2ZXJ5IHNpbWlsYXIgdG8gU0lQIFRDUC9UTFMg Y2xpZW50cyBiZWhpbmQgTkFUIHdoaWNoIA0KPj4gcmVxdWlyZSBPdXRib3VuZCBzdXBwb3J0LiBU aGVyZWZvcmUgd2UgYXNzdW1lZCB0aGF0IE91dGJvdW5kIHNob3VsZCANCj4+IGJlIG1hbmRhdG9y eSBpbiBvcmRlciB0byBvdmVyY29tZSB0aGlzIGxpbWl0YXRpb24uDQo+Pg0KPj4gSG93ZXZlciB3 ZSd2ZSByZWFsaXplZCB0aGF0LCBieSBkb2luZyB0aGF0LCB3ZSBhcmUgZGljdGFtaW5hdGluZyBh IA0KPj4gc3BlY2lmaWMgbmV0d29yayBhcmNoaXRlY3R1cmUsIGFuZCB0aGlzIGlzIG5vdCB0aGUg Z29hbCBvZiBvdXIgZHJhZnQuDQo+PiBIZXJlIHdlJ3JlIGp1c3QgZGVmaW5pbmcgYSBuZXcgdHJh bnNwb3J0IGZvciB0aGUgU0lQIHByb3RvY29sLg0KPj4NCj4+IFRoZXJlZm9yZSwgaWYgdGhlIFdH IGFncmVlcyB3aXRoIHRoYXQsIHdlIHdpbGwgcmVtb3ZlIHRoZSANCj4+IE91dGJvdW5kL0dSVVUg cmVxdWlyZW1lbnQgZnJvbSB0aGUgZHJhZnQsIGFuZCB3ZSB3aWxsIGNvdmVyIHRoZSBjYXNlIA0K Pj4gb2YgU0lQIGVudGl0aWVzIGNhcGFibGUgb2YgaW5pdGlhdGluZyBhbmQgcmVjZWl2aW5nIFdl YlNvY2tldCANCj4+IGNvbm5lY3Rpb25zLiBXZSB3aWxsIG1lbnRpb24gdGhhdCB0aG9zZSBjbGll bnRzIHRoYXQgY2Fubm90IGxpc3RlbiANCj4+IGZvciBpbmNvbWluZyBjb25uZWN0aW9uIChpLmUu IHdlYiBicm93c2Vycywgc21hcnRwaG9uZSBhcHBzKSBuZWVkIHRvIA0KPj4gdXNlIG9uZSBvZiB0 aGUgZXhpc3RpbmcgU0lQIG1lY2hhbmlzbXMgdG8gcmVjZWl2ZSBpbmNvbWluZyByZXF1ZXN0cyAN Cj4+IG92ZXIgdGhlIFdlYlNvY2tldCBjb25uZWN0aW9uIHRoZXkgaGF2ZSBvcGVuIHByZXZpb3Vz bHkgKE91dGJvdW5kIGlzIA0KPj4gb2YgY291cnNlIHRoZSBiZXN0IGNhbmRpZGF0ZSBmb3IgdGhv c2UgU0lQIGVuZHBvaW50cykuIE90aGVyIG5vZGVzIA0KPj4gKG5vdCBmaW5hbCBkZXZpY2VzKSBs aWtlIHByb3hpZXMgb3Igc2VydmVycyB0aGF0IGNhbiBvbmx5IGluaXRpYXRlIA0KPj4gb3V0Z29p bmcgV2ViU29ja2V0IGNvbm5lY3Rpb25zIHNob3VsZCBhbHNvIG1ha2UgdXNlIG9mIGFuIGV4aXN0 aW5nIA0KPj4gbWVjaGFuaXNtIGluIG9yZGVyIHRvIGdldCB0aGUgaW5jb21pbmcgcmVxdWVzdHMg b3ZlciB0aGUgY29ubmVjdGlvbiANCj4+IHRoZXkgaGF2ZSBvcGVuICh3aGljaCBiYXNpY2FsbHkg bWVhbnMgQ29ubmVjdGlvbiBSZXVzZSAtIFJGQyA1OTIzKS4gDQo+PiBBbmQgb3RoZXIgU0lQIG5v ZGVzIGNhcGFibGUgb2YgaW5pdGlhdGluZyBhbmQgcmVjZWl2aW5nIFdTIA0KPj4gY29ubmVjdGlv bnMgd291bGQgbmVlZCBubyBhZGRpdGlvbiAoYXMgdGhleSBiZWhhdmUgbGlrZSBhIFNJUCBUQ1Av U0NUUCBub2RlKS4NCj4+DQo+Pg0KPj4NCj4+DQo+PiBBYm91dCBHUlVVOg0KPj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4+DQo+PiBGb3IgdGhvc2UgU0lQIGVuZHBvaW50cyB3aGljaCBkb24ndCBs aXN0ZW4gZm9yIGluY29taW5nIFdlYlNvY2tldCANCj4+IGNvbm5lY3Rpb25zLCBHUlVVIGlzIHJl cXVpcmVkLiBUaGUgZm9sbG93aW5nIGV4YW1wbGUgYXR0ZW1wcyB0byANCj4+IGp1c3RpZnkgaXQ6 DQo+Pg0KPj4gLSBBbGljZSAoV1MgU0lQIFVBKSBpcyBpbiBhIGNhbGwgd2l0aCBCb2IgKFNJUCBV RFAgVUEpLg0KPj4gLSBCb2Igc2VuZHMgYSBSRUZFUiB0byBDYXJvbCAoU0lQIFVEUCBVQSkgd2l0 aCAiUmVmZXItVG86IEFMSUNFX0NPTlRBQ1RfVVJJIi4NCj4+IC0gQ2Fyb2wgc2VuZHMgYW4gSU5W SVRFIHRvIEFMSUNFX0NPTlRBQ1RfVVJJLg0KPj4NCj4+IFRoZSBvbmx5IHdheSBpbiB3aGljaCB0 aGUgSU5WSVRFIGNhbiBhcnJpdmUgdG8gQWxpY2UgaXMgdGhlIGNhc2UgaW4gDQo+PiB3aGljaCBB TElDRV9DT05UQUNUX1VSSSBpcyBhIEdSVVUgVVJJLCBzbyB0aGUgSU5WSVRFIHdvdWxkIHJlYWNo IA0KPj4gQWxpY2UncyBpbmJvdW5kIHByb3h5L3JlZ2lzdHJhciBhbmQgdGhhdCB3b3VsZCByb3V0 ZSB0aGUgcmVxdWVzdCB0byANCj4+IEFsaWNlIHVzaW5nIHRoZSBleGlzdGluZyBXZWJTb2NrZXQg Y29ubmVjdGlvbiAob2YgY291cnNlIHRoZXJlIGNvdWxkIA0KPj4gYmUgYW4gT3V0Ym91bmQgRWRn ZSBwcm94eSBiZXR3ZWVuIEFsaWNlIGFuZCB0aGUgcmVnaXN0cmFyKS4NCj4+DQo+Pg0KPj4NCj4+ DQo+PiBBYm91dCBLZWVwYWxpdmU6DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pg0K Pj4gV2ViU29ja2V0IHRyYW5zcG9ydCBkZWZpbmVzIGEga2VlcGFsaXZlIG1lY2hhbmlzbSBiYXNl ZCBvbiBXZWJTb2NrZXQgDQo+PiBQaW5nIGZyYW1lcyB3aGljaCBtdXN0IGJlIHJlcGxpZWQgYnkg dGhlIHJlbW90ZSBwZWVyIHdpdGggYSBQb25nIA0KPj4gZnJhbWUuIFRoaXMgaXMgbm90IG5lZ290 aWFibGUsIGFueSBwZWVyIGNhbiBzZW5kIGEgV1MgUGluZyB0byB0aGUgDQo+PiBwZWVyIGFuZCB0 aGUgcGVlciBtdXN0IHJlcGx5IHRvIGl0IHdpdGggYSBQb25nLg0KPj4NCj4+IEluIHNvbWUgV2Vi U29ja2V0IGltcGxlbWVudGF0aW9ucyAod2ViIGJyb3dzZXJzKSB0aGUgYXBwbGljYXRpb24gDQo+ PiBsZXZlbA0KPj4gKEphdmFTY3JpcHQpIGhhcyBubyB3YXkgdG8gZGV0ZXJtaW5lIHdoZXRoZXIg aXRzIFdlYlNvY2tldCBzdGFjayBpcyANCj4+IHNlbmRpbmcgb3IgcmVjZWl2aW5nIFBpbmcgZnJh bWVzIGZyb20vdG8gdGhlIFdTIHNlcnZlci4gU28gdXNpbmcgU0lQIA0KPj4ga2VlcGFsaXZlIGNv dWxkIGJlIGEgZ29vZCBpZGVhLiBJZiB0aGUgV1MgU0lQIGVuZHBvaW50IGltcGxlbWVudHMgDQo+ PiBPdXRib3VuZCB0aGVuIGl0J3MgZG9uZS4gSWYgaXQgaXMgYSBkaWZmZXJlbnQgY2xpZW50IHR5 cGUgaXQgY291bGQgDQo+PiB0aGVuIGltcGxlbWVudCBSRkMgNjIzMyAoSW5kaWNhdGlvbiBvZiBT dXBwb3J0IGZvciBLZWVwLUFsaXZlKS4NCj4+DQo+PiBTbyBpdCdzIGltcG9ydGFudCB0byBub3Rl IHRoYXQgdGhlIGRyYWZ0IGNhbm5vdCBtYW5kYXRlIG9yIHByb2hpYml0IGEgDQo+PiBzcGVjaWZp YyBrZWVwYWxpdmUgbWVjaGFuaXNtLCBnaXZlbiB0aGUgZmFjdCB0aGF0IHNvbWUgZXhpc3Rpbmcg DQo+PiBXZWJTb2NrZXQgaW1wbGVtZW50YXRpb25zICh3ZWIgYnJvd3NlcnMpIGFscmVhZHkgbWFr ZSB1c2FnZSBvZiB0aGUgDQo+PiBXZWJTb2NrZXQgUGluZy9Qb25nIG1lY2hhbmlzbSBhbmQgdGhh dCBpcyBub3QgbW9kaWZpYWJsZSBieSB0aGUgDQo+PiBhcHBsaWNhdGlvbiBsYXllciAoSmF2YVNj cmlwdCkuIE90aGVyIGtpbmQgb2YgY2xpZW50cyAoYXBwcyBydW5uaW5nIA0KPj4gaW4gU08gZGVz a3RvcHMgb3Igc21hcnRwaG9uZXMsIG9yIFNJUCBwcm94aWVzL3NlcnZlcnMpIGNvdWxkIGRlY2lk ZSBhIA0KPj4gc2luZ2xlIGtlZXBhbGl2ZSBtZWNoYW5pc20gKGlmIHRoZXkgbmVlZCBpdCkuDQo+ Pg0KPj4NCj4+DQo+Pg0KPj4gQWJvdXQgZG9tYWluICJ4eHh4eC5pbnZhbGlkIiBpbiBWaWEgYW5k IENvbnRhY3Q6DQo+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IC0NCj4+DQo+PiBUaGUgYXBwbGljYXRpb24g bGF5ZXIgaW4gc29tZSBXZWJTb2NrZXQgaW1wbGVtZW50YXRpb25zIChKYXZhU2NyaXB0IA0KPj4g aW4gd2ViIGJyb3dzZXJzKSBoYXMgbm8gd2F5IHRvIGRldGVybWluZSB0aGUgbG9jYWwgSVAgYWRk cmVzcyBhbmQgDQo+PiBwb3J0IGZyb20gd2hpY2ggdGhlIGJyb3dzZXIgaGFzIGVzdGFibGlzaGVk IHRoZSBXZWJTb2NrZXQgY29ubmVjdGlvbiANCj4+IHdpdGggdGhlIHNlcnZlci4gVGhlcmVmb3Jl IHdlIHN1Z2dlc3RlZCBpbiB0aGUgZHJhZnQgdGhlIHVzYWdlIG9mIA0KPj4geHh4eHguaW52YWxp ZCBkb21haW4gbmFtZXMgKGFzIHN0YXRlZCBpbiBSRkMgMjYwNikgZm9yIFZpYSBhbmQgDQo+PiBD b250YWN0IGhlYWRlcnMuIEhvd2V2ZXIgd2UgaGF2ZSByZWNvbnNpZGVyZWQgaXQgYW5kIHBsYW4g dG8gcmVtb3ZlIA0KPj4gaXQgZnJvbSB0aGUgZHJhZnQuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4gQWJv dXQgdG9wb2xvZ3kgaGlkaW5nIChSRkMgMzI2MSByZWxheGVkKToNCj4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+DQo+PiBW ZXJzaW9uIDAxIG9mIHRoZSBkcmFmdCByZWxheGVzIHRoZSByZXF1aXJlbWVudCBpbiBSRkMgMzI2 MSBzZWN0aW9uDQo+PiAxOC4yLjEgYWJvdXQgYWRkaW5nIGEgVmlhIDtyZWNlaXZlZCBwYXJhbWV0 ZXIgaW4gU0lQIHJlc3BvbnNlcyB3aGVuIA0KPj4gdGhlIFZpYSBzZW50LWJ5IGRvZXMgbm90IG1h dGNoIHRoZSBzb3VyY2UgSVAuIFRoaXMgaXMgYmVjYXVzZSB0aGUgDQo+PiBXZWJTb2NrZXQgY29u bmVjdGlvbiByZXVzZXMgZXhpc3RpbmcgSFRUUCBpbmZyYXN0cnVjdHVyZSBpbiB3aGljaCANCj4+ IHRoZXJlIGNvdWxkIGJlIGNlcnRhaW4gbnVtYmVyIG9mIEhUVFAgcHJveGllcyBhbmQvb3IgVENQ IGxvYWQgDQo+PiBiYWxhbmNlcnMgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgV2ViU29ja2V0 IHNlcnZlciwgc28gdGhlIHNvdXJjZSANCj4+IElQIHRoZSBzZXJ2ZXIgd291bGQgd3JpdGUgaW50 byB0aGUgVmlhICJyZWNlaXZlZCIgcGFyYW1ldGVyIHdvdWxkIGJlIA0KPj4gdGhlIElQIG9mIHRo ZSBIVFRQL1RDUCBpbnRlcm1lZGlhcnkgaW4gZnJvbnQgb2YgaXQsIGFuZCB0aGF0IGNvdWxkIA0K Pj4gcmV2ZWFsIHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUgaW50ZXJuYWwgdG9wb2xv Z3kgb2YgdGhlIA0KPj4gcHJvdmlkZXIgbmV0d29yayB0byB0aGUgV2ViU29ja2V0IGNsaWVudC4N Cj4+DQo+PiBBcyBzdWdnZXN0ZWQgaW4gYSByZWNlaXZlZCByZXZpZXcsIHdlIGNvbnNpZGVyIHRo YXQgdGhpcyBkZWNpc2lvbiBpcyANCj4+IHVwIHRvIHRoZSBpbXBsZW1lbnRvciBhbmQgc2hvdWxk IG5vdCBiZSBjb3ZlcmVkIGJ5IHRoZSBkcmFmdCBpdHNlbGYuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4g QmVzdCByZWdhcmRzLg0KPj4NCj4+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+IHNpcGNvcmVAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoN Cg== From christer.holmberg@ericsson.com Tue Mar 20 08:07:55 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB73821F8466 for ; Tue, 20 Mar 2012 08:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.12 X-Spam-Level: X-Spam-Status: No, score=-10.12 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-uONh6pbMdY for ; Tue, 20 Mar 2012 08:07:55 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id C4FF921F8450 for ; Tue, 20 Mar 2012 08:07:54 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-f4-4f689d495027 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1A.82.27041.94D986F4; Tue, 20 Mar 2012 16:07:53 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Tue, 20 Mar 2012 16:07:53 +0100 From: Christer Holmberg To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Tue, 20 Mar 2012 16:07:53 +0100 Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) Thread-Index: Ac0GqiNQGhy7zFUWTRefJCa9W8yacwAAKrOQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C41456F5C@ESESSCMS0356.eemea.ericsson.se> References: <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Mar 2012 15:07:56 -0000 SGksDQoNCj4+PiBJZiB0aGUgV2ViU29ja2V0IFNJUCBlbnRpdHkgKHdoYXRldmVyKSBkb2VzIG5v dCBsaXN0ZW4gZm9yIGluY29taW5nIGNvbm5lY3Rpb25zIHRoZW4gaXQgbmVlZHMgT3V0Ym91bmQg b3IgQ29ubmVjdGlvbiBSZXVzZSAoUkZDIDU5MjMpLg0KPj4+IFRob3NlIGFyZSB0aGUgb25seSB0 d28gc3RhbmRhcml6ZWQgd2F5cyBpbiB3aGljaCBpbmNvbWluZyByZXF1ZXN0cyANCj4+PiB3b3Vs ZCByZXVzZSB0aGUgY29ubmVjdGlvbiBvcGVuIGJ5IHRoZSBXZWJTb2NrZXQgY2xpZW50LiBJbiB0 aGUgY2FzZSBvZiBVQXMgKFNJUCBlbmRwb2ludHMpIE91dGJvdW5kIHNlZW1zIHRoZSBjb21wbGV0 ZSBzb2x1dGlvbi4gSW4gdGhlIGNhc2Ugb2YgcHJveGllcy9CMkJVQXMsIFJGQyA1OTIzIHNlZW1z IHRoZSBjaG9pY2UuDQo+Pg0KPj4gV2UgYXJlIGRlZmluaW5nIHRoZSBXUyB0cmFuc3BvcnQgZm9y IFNJUC4gQ2FuJ3Qgd2Ugc2ltcGx5IHNheSB0aGF0LCBieSBkZWZhdWx0LCBhIHNlcnZlciBzaGFs bCB1c2UgYW4gZXhpc3RpbmcgV1MgY29ubmVjdGlvbiB0b3dhcmRzIHRoZSBjbGllbnQ/IE5vIG5l ZWQgZm9yIGFueSBleHRlbnNpb25zIHRvIG5lZ290aWF0ZSBpdC4NCj4+DQo+PiBPUiwgaWYgd2Ug d2FudCB0byBiZSBhYmxlIHRvIGV4cGxpY2l0bHkgcmVxdWVzdCByZXZlcnNlIGNvbm5lY3Rpb24g cmUtdXNlLCB3ZSBtYW5kYXRlIHRoZSB1c2FnZSBvZiBSRkMgNTkyMyAodW5sZXNzIE91dGJvdW5k IGlzIGVuYWJsZWQpLCBidXQgc2F5IHRoYXQgYSBzZXJ2ZXIgbXVzdCBPTkxZIHVzZSBhbiBleGlz dGluZyBjb25uZWN0aW9uLg0KPg0KPiBUaGF0IG1ha2VzIHNlbnNlIChhbmQgbWFrZXMgbGlmZSBl YXNpZXIgdG8gaW1wbGVtZW50b3JzKS4gQnV0IGluIG9yZGVyIHRvIGNsYXJpZnksIHdoZW4geW91 IHNheSAiYSBzZXJ2ZXIgbXVzdCBPTkxZIHVzZSBhbiBleGlzdGluZyBjb25uZWN0aW9uIiB5b3Ug bWVhbiAiZm9yIHNlbmRpbmcgcmVzcG9uc2VzIiwgYW0gSSByaWdodD8NCg0KTm8sIEkgYWxzbyBt ZWFuIHNlbmRpbmcgcmVxdWVzdHMgaW4gdGhlIHJldmVyc2Ugb3JkZXIuDQoNCkJ1dCwgaWYgdGhl cmUgYXJlIGNhc2VzIHdoZXJlIHRoYXQgcmUtdXNlIGlzIG5vdCBuZWVkZWQsIHRoZW4gaXQgY2Fu J3QgYmUgZGVmYXVsdCBiZWhhdmlvci4gVGhlbiB3ZSBjb3VsZCB1c2UgUkZDIDU5MjMgdG8gZXhw bGljaXRseSByZXF1ZXN0IGl0Lg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQo= From iesg-secretary@ietf.org Tue Mar 20 09:30:16 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9706021F86DD; Tue, 20 Mar 2012 09:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mvYBFtCgrYU; Tue, 20 Mar 2012 09:30:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B2621F8698; Tue, 20 Mar 2012 09:30:15 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120320163015.26278.63277.idtracker@ietfa.amsl.com> Date: Tue, 20 Mar 2012 09:30:15 -0700 Cc: sipcore@ietf.org Subject: [sipcore] Last Call: (SIP-Specific Event Notification) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 16:30:16 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'SIP-Specific Event Notification' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-04-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. This document represents a backwards-compatible improvement on the original mechanism described by RFC 3265, taking into account several years of implementation experience. Accordingly, this document obsoletes RFC 3265. This document also updates RFC 4660 slightly to accommodate some small changes to the mechanism that were discussed in that document. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc3265bis/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sipcore-rfc3265bis/ballot/ No IPR declarations have been submitted directly on this I-D. From ibc@aliax.net Tue Mar 20 09:37:44 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216FE21F8702 for ; Tue, 20 Mar 2012 09:37:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.608 X-Spam-Level: X-Spam-Status: No, score=-2.608 tagged_above=-999 required=5 tests=[AWL=0.069, 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 tpc5MDp9Ew6s for ; Tue, 20 Mar 2012 09:37:43 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3DA21F8701 for ; Tue, 20 Mar 2012 09:37:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so104370vbb.31 for ; Tue, 20 Mar 2012 09:37:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=FHFboDRyS2btMEjwXE66796KvzcHdzSoF81qLJBTecw=; b=lnLy/e7Q/NdHsouJWJ1EfNHTaP3XoJwZexoG/FhZdYp+H0zeC/RB2pefpyMrslynxI 2Uut1nU95yivtfu9J0/fhxH997YfYNKmgAK9AOb82DL/U/KNN0mV8LJW01AlEnELE2nf Tu2l8SZVE/1S8FmdUhb7teKlpBcve8vDKy42eZRa0OM2q20eVUTvLwpobve+3nABanCi 3OQVB2P2vKqO6ciWGxQhWh9v/U149isa21EjOuhhcYsRxB/OGrf4nKOFdQ/cTz5iSru8 qRaUmDuC++CSPUVQGVSCPEQIEk8lp5Wst1v01KgoX1IbEqrQrRFGkKSUGjYF/YVeMch/ Kmqg== Received: by 10.220.140.196 with SMTP id j4mr279720vcu.22.1332261462568; Tue, 20 Mar 2012 09:37:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Tue, 20 Mar 2012 09:37:22 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C41456F5C@ESESSCMS0356.eemea.ericsson.se> References: <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C41456F5C@ESESSCMS0356.eemea.ericsson.se> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 20 Mar 2012 17:37:22 +0100 Message-ID: To: Christer Holmberg Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnAKzJ3Fxl3VowCE+3+DmC8z3jHmhd2vS69rL/aS6q+ZHhHquGNMwQE7DQxjkHByNlFkQY4 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Mar 2012 16:37:44 -0000 2012/3/20 Christer Holmberg : >> That makes sense (and makes life easier to implementors). But in order t= o clarify, when you say "a server must ONLY use an existing connection" you= mean "for sending responses", am I right? > > No, I also mean sending requests in the reverse order. > But, if there are cases where that re-use is not needed, then it can't be= default behavior. I don't think it's easy to specify that. The draft should then include some "version" of RFC 5923 integrated with it (so it would become really long). Also note that... > Then we could use RFC 5923 to explicitly request it. ...RFC 5923 just covers secure connections (TLS), so in this case WSS connections. Please let me know if the following proposal could get some consensus: SIP WS entities that can only initiate outgoing connections ---------------------------------------------------------------------------= ------------------------ These can be SIP UA's (i.e. JavaScript apps running in a web browser, smartphone apps) or SIP proxies/servers. In the case of SIP UA's, implementing Outbound is the easiest and most complete solution (connection reusing for incoming requests, keepalive, registration failover, valid for WS and WSS over TLS). Implementing GRUU would also be valuable and required for receiving an INVITE generated upon a REFER containing the Contact URI of a SIP WS UA in the "Refer-To" header (see the previous Alice/Bob/Carol REFER example in a previous mail). In case of SIP proxies/servers, Outbound is not an option and those SIP entities should implement RFC 5923 "Connection Reuse" and, optionally, RFC 6233 "Indication of Support for Keep-Alive"). Note however that RFC 5923 requires secure connections (so just WSS =3D WS over TLS) and a certificate presented by the connection initiator. SIP WS entities that can initiate outgoing connections and listening for incoming connections ---------------------------------------------------------------------------= ------------------------ These can be SIP proxies/servers o custom SIP UA's (with an own WebSocket stack that behaves as client and server). These entities could not require to reuse the initial connection for incoming requests (for example in a proxy-proxy communication in the public Internet or same network). They could implement RFC 6233 or could prefer to make usage of WebSocket Ping/Pong Keep-Alive mechanism in case they need it. Those SIP entities don't need changes to RFC 3261 neither implementing other RFC's for connection reusing. About sending responses --------------------------------------- Given the fact that *most* of the SIP WS clients will not listen for incoming connection, section RFC 3261 18.2.2 "Sending Responses" could be relaxed for WS servers: responses can only be sent over the existing connection as the draft already states: http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01#section-5.3 --=20 I=C3=B1aki Baz Castillo From pkyzivat@alum.mit.edu Tue Mar 20 10:04:57 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF6A21F8598 for ; Tue, 20 Mar 2012 10:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 c8TkeeI9s1Lt for ; Tue, 20 Mar 2012 10:04:57 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id BC7ED21F8592 for ; Tue, 20 Mar 2012 10:04:56 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta13.westchester.pa.mail.comcast.net with comcast id nsyx1i0061vXlb85Dt4xDK; Tue, 20 Mar 2012 17:04:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id nt4w1i00J07duvL3dt4wBB; Tue, 20 Mar 2012 17:04:56 +0000 Message-ID: <4F68B8B6.7070505@alum.mit.edu> Date: Tue, 20 Mar 2012 13:04:54 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: SIPCORE References: <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Mar 2012 17:04:57 -0000 [as individual] On 3/20/12 10:53 AM, Christer Holmberg wrote: > Hi, > >>> Also, I don't think we need Outbound in order to say that requests from the server to the client shall use an existing WS connection from the client. >> >> If the WebSocket SIP entity (whatever) does not listen for incoming connections then it needs Outbound or Connection Reuse (RFC 5923). >> Those are the only two standarized ways in which incoming requests would reuse the connection open by the WebSocket client. In the case of UAs (SIP endpoints) Outbound seems the complete solution. In the case of proxies/B2BUAs, RFC 5923 seems >> the choice. > > We are defining the WS transport for SIP. Can't we simply say that, by default, a server shall use an existing WS connection towards the client? No need for any extensions to negotiate it. No. You are ignoring all the issues that came up in work on outbound and connection-reuse. > OR, if we want to be able to explicitly request reverse connection re-use, we mandate the usage of RFC 5923 (unless Outbound is enabled), but say that a server must ONLY use an existing connection. IIRC, 5923 only allows reuse of connections when the server has received a certificate from the client. Most clients using this draft won't have client certificates. In the case of outbound, the client has registered and so proved entitled to receive outbound requests to the AOR or associated GRUU. Thanks, Paul >> maybe there will be specific parts of Outbound that we need to mandate, but then we should mandate those specific parts. > >> IMHO there is no need to mandate neither some specific parts of Outbound spec. If for example a SIP proxy/server is capable of opening and also listening for WebSocket connections, then the WebSocket transport becomes similar to what SIP over TCP >> or STCP involves. There is no need to reuse the initial WS connection for requests in reverse order, but just let the peer to open a new WS connection with us (same as TCP/SCTP when Outbound or RFC 5923 are not used). > > Sure. > > Regards, > > Christer > From salvatore.loreto@ericsson.com Tue Mar 20 14:32:10 2012 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A6A21F8686 for ; Tue, 20 Mar 2012 14:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.03 X-Spam-Level: X-Spam-Status: No, score=-110.03 tagged_above=-999 required=5 tests=[AWL=0.568, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlYwVW1llxoi for ; Tue, 20 Mar 2012 14:32:09 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id DF7DB21F8684 for ; Tue, 20 Mar 2012 14:32:08 -0700 (PDT) X-AuditID: c1b4fb3d-b7c6fae0000045c0-ad-4f68f7570788 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D5.76.17856.757F86F4; Tue, 20 Mar 2012 22:32:07 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Tue, 20 Mar 2012 22:32:06 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B32E122ED for ; Tue, 20 Mar 2012 23:32:06 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B90D45266D for ; Tue, 20 Mar 2012 23:32:06 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 21DA05228D for ; Tue, 20 Mar 2012 23:32:06 +0200 (EET) Message-ID: <4F68F755.8030001@ericsson.com> Date: Tue, 20 Mar 2012 22:32:05 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020705060304010301090109" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Review draft-ibc-sipcore-sip-websocket-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 21:32:10 -0000 --------------020705060304010301090109 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi there, here my preliminary review. I will avoid all the stuff already listed by Alan and Kevin reviews. I do think this draft is really important, so I look forward to this work progressing. best regards Salvatore -- Salvatore Loreto, PhD www.sloreto.com ---review--- Section 3 second paragraph: -it would be worth to clarify that the handshake is based on an HTTP Upgrade request transported in a GET method so to make clear that the handshake upgrades the connection from HTTP to WebSocket/Sub-Protocol Section 4 this section does not say anything for wss:// (i.e. encrypted connection). Reading the section I got the wrong impression that the SIP subprotocol will run always on a unencrypted connection. Section 5.2 you have forgotten to list the "wss" Section 6 I don't get the need for Outbound ... to be clear the Keep-alive technique defined in Outbound, (however I see the need for the rest of things defined in that RFC) We are talking of a WebSocket client that will contact a WebSocket server and in the Web architecture the server is always available on a public IP... Are you trying to define here some extension the the WebSocket protocol as such or what? In the new HyBi charter there is a work item about Timeout-handling capabilities that should be help you Anyway it would be good if you define the scenario that need the Outbound within a WebSocket client using a Sip subprotocol btw I have to confess I haven't had the time to catch up on the other mail thread discussing this point Section 7 the section mandate the usage RFC3263, however it does not say anything how the WebSocket client will also at the same time stay compliant to the same-origin policy Section 8 Based on local policy, this might occur once the JavaScript SIP application has been downloaded from the web server, or when the SIP user using the web browser application registers itself to a SIP registrar (assuming that SIP requests cannot be sent or received before then). it is not clear from the above paragraph, but also the registration will happen over a WebSocket connection, isn't it? 9.1. SIP Proxy Considerations When a SIP proxy bridges WebSocket and any other SIP transport (including WebSocket transport) it MUST perform Loose Routing as specified in [RFC3261 ]. it is not clear to me how a SIP proxy can bridge a WebSocket request: WebSocket connection go on to of an Upgraded HTTP connection between the WebSocket client and the WebSocket client... this connection can eventually pass through a HTTP Proxy but for sure not a SIP proxy 10. Connection Keep Alive it would be worth to eventually reuse the mechanism the HyBi wg is suppose to standardize to do Keep-Alive... more The client application MAY also use Network Address Translation (NAT) keep-alive mechanisms defined for the SIP protocol, such as the CRLF Keep-Alive Technique mechanism described in[RFC5626] section 3.5.1 . as stated above I doubt that can be done by a WebSocket client. --------------020705060304010301090109 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi there,

here my preliminary review.
I will avoid all the stuff already listed by Alan and Kevin reviews.

I do think this draft is really important, so I look forward to this work progressing.

best regards
Salvatore
-- 
Salvatore Loreto, PhD
www.sloreto.com


---review---

Section 3

second paragraph:
-it would be worth to clarify that the handshake is based on
an HTTP Upgrade request transported in a GET method so to make clear
that the handshake upgrades the connection from HTTP to WebSocket/Sub-Protocol

Section 4

this section does not say anything for wss:// (i.e. encrypted connection).
Reading the section I got the wrong impression that the SIP subprotocol will run always
on a unencrypted connection.

Section 5.2

you have forgotten to list the "wss"

Section 6

I don't get the need for Outbound ... to be clear the Keep-alive technique defined in Outbound,
(however I see the need for the rest of things defined in that RFC)
We are talking of a WebSocket client that will contact a WebSocket server
and in the Web architecture the server is always available on a public IP...
Are you trying to define here some extension the the WebSocket protocol as such
or what?
In the new HyBi charter there is a work item about
Timeout-handling capabilities
that should be help you

Anyway it would be good if you define the scenario that need the Outbound within
a WebSocket client using a Sip subprotocol

btw I have to confess I haven't had the time to catch up on the other mail thread
discussing this point

Section 7

the section mandate the usage RFC3263, however it does not say anything how the WebSocket client
will also at the same time stay compliant to the same-origin policy


Section 8

      Based on local policy, this might occur once the JavaScript SIP
      application has been downloaded from the web server, or when the
      SIP user using the web browser application registers itself to a
      SIP registrar (assuming that SIP requests cannot be sent or
      received before then).

it is not clear from the above paragraph, but also the registration will
happen over a WebSocket connection, isn't it?

9.1. SIP Proxy Considerations

   When a SIP proxy bridges WebSocket and any other SIP transport
   (including WebSocket transport) it MUST perform Loose Routing as
   specified in [RFC3261].

it is not clear to me how a SIP proxy can bridge a WebSocket request:
WebSocket connection go on to of an Upgraded HTTP connection
between the WebSocket client and the WebSocket client...
this connection can eventually pass through a HTTP Proxy but for sure
not a SIP proxy


10. Connection Keep Alive

it would be worth to eventually reuse the mechanism the HyBi wg is suppose
to standardize to do Keep-Alive...

more

   The client application MAY also use Network Address Translation (NAT)
   keep-alive mechanisms defined for the SIP protocol, such as the CRLF
   Keep-Alive Technique mechanism described in [RFC5626] section 3.5.1.



    as stated above I doubt that can be done by a WebSocket client.

    

    

    

  


--------------020705060304010301090109--

From christer.holmberg@ericsson.com  Tue Mar 20 23:43:39 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F49F21E802D for ; Tue, 20 Mar 2012 23:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.272
X-Spam-Level: 
X-Spam-Status: No, score=-10.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaEP9k7T+wc2 for ; Tue, 20 Mar 2012 23:43:37 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4C49C21E8018 for ; Tue, 20 Mar 2012 23:43:36 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-ef-4f697897f8e5
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CB.AC.17856.798796F4; Wed, 21 Mar 2012 07:43:35 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 21 Mar 2012 07:43:29 +0100
From: Christer Holmberg 
To: Paul Kyzivat , SIPCORE 
Date: Wed, 21 Mar 2012 07:43:28 +0100
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
Thread-Index: Ac0Gu5PulztimAnnS2q6GglYlDjhVQAcDaIg
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu>
In-Reply-To: <4F68B8B6.7070505@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 21 Mar 2012 06:43:39 -0000

SGksDQoNCj4+Pj4gQWxzbywgSSBkb24ndCB0aGluayB3ZSBuZWVkIE91dGJvdW5kIGluIG9yZGVy
IHRvIHNheSB0aGF0IHJlcXVlc3RzIGZyb20gdGhlIHNlcnZlciB0byB0aGUgY2xpZW50IHNoYWxs
IHVzZSBhbiBleGlzdGluZyBXUyBjb25uZWN0aW9uIGZyb20gdGhlIGNsaWVudC4NCj4+Pg0KPj4+
IElmIHRoZSBXZWJTb2NrZXQgU0lQIGVudGl0eSAod2hhdGV2ZXIpIGRvZXMgbm90IGxpc3RlbiBm
b3IgaW5jb21pbmcgY29ubmVjdGlvbnMgdGhlbiBpdCBuZWVkcyBPdXRib3VuZCBvciBDb25uZWN0
aW9uIFJldXNlIChSRkMgNTkyMykuDQo+Pj4gVGhvc2UgYXJlIHRoZSBvbmx5IHR3byBzdGFuZGFy
aXplZCB3YXlzIGluIHdoaWNoIGluY29taW5nIHJlcXVlc3RzIA0KPj4+IHdvdWxkIHJldXNlIHRo
ZSBjb25uZWN0aW9uIG9wZW4gYnkgdGhlIFdlYlNvY2tldCBjbGllbnQuIEluIHRoZSBjYXNlIG9m
IFVBcyAoU0lQIGVuZHBvaW50cykgT3V0Ym91bmQgc2VlbXMgdGhlIGNvbXBsZXRlIHNvbHV0aW9u
LiBJbiB0aGUgY2FzZSBvZiBwcm94aWVzL0IyQlVBcywgUkZDIDU5MjMgDQo+Pj4gc2VlbXMgdGhl
IGNob2ljZS4NCj4+DQo+PiBXZSBhcmUgZGVmaW5pbmcgdGhlIFdTIHRyYW5zcG9ydCBmb3IgU0lQ
LiBDYW4ndCB3ZSBzaW1wbHkgc2F5IHRoYXQsIGJ5IGRlZmF1bHQsIGEgc2VydmVyIHNoYWxsIHVz
ZSBhbiBleGlzdGluZyBXUyBjb25uZWN0aW9uIHRvd2FyZHMgdGhlIGNsaWVudD8gTm8gbmVlZCBm
b3IgYW55IGV4dGVuc2lvbnMgdG8gbmVnb3RpYXRlIA0KPj4gaXQuDQo+DQo+IE5vLiBZb3UgYXJl
IGlnbm9yaW5nIGFsbCB0aGUgaXNzdWVzIHRoYXQgY2FtZSB1cCBpbiB3b3JrIG9uIG91dGJvdW5k
IGFuZCBjb25uZWN0aW9uLXJldXNlLg0KDQpQcm9iYWJseSA6KQ0KDQo+PiBPUiwgaWYgd2Ugd2Fu
dCB0byBiZSBhYmxlIHRvIGV4cGxpY2l0bHkgcmVxdWVzdCByZXZlcnNlIGNvbm5lY3Rpb24gcmUt
dXNlLCB3ZSBtYW5kYXRlIHRoZSB1c2FnZSBvZiBSRkMgNTkyMyAodW5sZXNzIE91dGJvdW5kIGlz
IGVuYWJsZWQpLCBidXQgc2F5IHRoYXQgYSBzZXJ2ZXIgbXVzdCBPTkxZIHVzZSBhbiANCj4+IGV4
aXN0aW5nIGNvbm5lY3Rpb24uDQo+DQo+IElJUkMsIDU5MjMgb25seSBhbGxvd3MgcmV1c2Ugb2Yg
Y29ubmVjdGlvbnMgd2hlbiB0aGUgc2VydmVyIGhhcyByZWNlaXZlZCBhIGNlcnRpZmljYXRlIGZy
b20gdGhlIGNsaWVudC4gTW9zdCBjbGllbnRzIHVzaW5nIHRoaXMgZHJhZnQgd29uJ3QgaGF2ZSBj
bGllbnQgY2VydGlmaWNhdGVzLg0KDQpUcnVlLg0KDQo+IEluIHRoZSBjYXNlIG9mIG91dGJvdW5k
LCB0aGUgY2xpZW50IGhhcyByZWdpc3RlcmVkIGFuZCBzbyBwcm92ZWQgZW50aXRsZWQgdG8gcmVj
ZWl2ZSBvdXRib3VuZCByZXF1ZXN0cyB0byB0aGUgQU9SIG9yIGFzc29jaWF0ZWQgR1JVVS4NCg0K
T2ssIHNvIHdlIG5lZWQgdG8gdGhpbmsgYWJvdXQgd2hldGhlciByZWdpc3RyYXRpb24gaXMgcmVx
dWlyZWQgZnJvbSBhIHNlY3VyaXR5IHBlcnNwZWN0aXZlLiBCdXQsIG5vdCB0YWtpbmcgY29ubmVj
dGlvbiByZS11c2UgaW50byBjb25zaWRlcmF0aW9uLCBhIG5vcm1hbCAobm9uLW9iKSByZWdpc3Ry
YXRpb24gaXMgZW5vdWdoIHRvIGVuc3VyZSB0aGUgY2xpZW50IGlzIGVudGl0bGVkIHRvIHJlY2Vp
dmUgcmVxdWVzdHMsIHJpZ2h0Pw0KDQpBbmQsIGZyb20gYSBjbGllbnQgcGVyc3BlY3RpdmUsIHVu
bGVzcyBhIGNsaWVudCBpcyB3aWxsaW5nIHRvIHJlY2VpdmUgcmVxdWVzdHMgb24gdGhlIFdTIGNv
bm5lY3Rpb24gaXQgc2hvdWxkbid0IGVzdGFibGlzaCB0aGUgV1MgY29ubmVjdGlvbiBpbiB0aGUg
Zmlyc3QgcGxhY2UuDQoNCkFuZCwgYWdhaW4sIHdpdGggT3V0Ym91bmQgd2Ugd291bGQgbmVlZCB0
byBkZWNpZGUgd2hldGhlciB3ZSBhcmUgd2lsbGluZyB0byBhY2NlcHQgYSByZXN0cmljdGlvbiBz
YXlpbmcgdGhhdCBXUyBTSVAgb25seSB3b3JrcyB3aGVuIHRoZSByZWdpc3RyYXIgc3VwcG9ydCBP
dXRib3VuZC4gTWF5YmUgaXQncyBub3QgYSByZWFsLWxpZmUgcHJvYmxlbSwgaW4gd2hpY2ggY2Fz
ZSBpdCB3b3VsZCBub3QgYmUgYW4gaXNzdWUgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K
DQoNCg0KDQo+PiBtYXliZSB0aGVyZSB3aWxsIGJlIHNwZWNpZmljIHBhcnRzIG9mIE91dGJvdW5k
IHRoYXQgd2UgbmVlZCB0byBtYW5kYXRlLCBidXQgdGhlbiB3ZSBzaG91bGQgbWFuZGF0ZSB0aG9z
ZSBzcGVjaWZpYyBwYXJ0cy4NCj4NCj4+IElNSE8gdGhlcmUgaXMgbm8gbmVlZCB0byBtYW5kYXRl
IG5laXRoZXIgc29tZSBzcGVjaWZpYyBwYXJ0cyBvZiANCj4+IE91dGJvdW5kIHNwZWMuIElmIGZv
ciBleGFtcGxlIGEgU0lQIHByb3h5L3NlcnZlciBpcyBjYXBhYmxlIG9mIG9wZW5pbmcgYW5kIGFs
c28gbGlzdGVuaW5nIGZvciBXZWJTb2NrZXQgY29ubmVjdGlvbnMsIHRoZW4gdGhlIFdlYlNvY2tl
dCB0cmFuc3BvcnQgYmVjb21lcyBzaW1pbGFyIHRvIHdoYXQgU0lQIG92ZXIgVENQIG9yIFNUQ1Ag
aW52b2x2ZXMuIFRoZXJlIGlzIG5vIG5lZWQgdG8gcmV1c2UgdGhlIGluaXRpYWwgV1MgY29ubmVj
dGlvbiBmb3IgcmVxdWVzdHMgaW4gcmV2ZXJzZSBvcmRlciwgYnV0IGp1c3QgbGV0IHRoZSBwZWVy
IHRvIG9wZW4gYSBuZXcgV1MgY29ubmVjdGlvbiB3aXRoIHVzIChzYW1lIGFzIFRDUC9TQ1RQIHdo
ZW4gT3V0Ym91bmQgb3IgUkZDIDU5MjMgYXJlIG5vdCB1c2VkKS4NCj4NCj4gU3VyZS4NCj4NCj4g
UmVnYXJkcywNCj4NCj4gQ2hyaXN0ZXINCj4NCg0K

From ibc@aliax.net  Wed Mar 21 05:02:14 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07E3C21F8603 for ; Wed, 21 Mar 2012 05:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level: 
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=0.068,  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 9Fon4GQ-pNla for ; Wed, 21 Mar 2012 05:02:13 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 987E121F860F for ; Wed, 21 Mar 2012 05:02:12 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so1128496vcb.31 for ; Wed, 21 Mar 2012 05:02:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=dMqJ1RTldpYcK+nvxMpEZ9hZJeAIvnBdy7YvhDypMeg=; b=lJmPpIYG72eFaGW16dtgOBAEsTiSOzuXbiEM0Qpkd0vVPmMKxL/LjIt3v0yE2d3v6p ktSwut0u4OO1OPTaNjLYCyylDl3Q0HPk4qfZ07pfMbUc2BN/qa92WwfcT3bQ/4TlBsZV jchzC5KRQDMvuFOkeUuVwYpIywrMOIAihBauWcyN2pPJoA55Q6Dpfe7nEPvv4aN+lNso SuwcphQbKEaRZvV1lTvfIRw+w3rQUB/hUYo2TM6fAvNdkwlDeN/KE/iVpY8CgjGysMa8 PKilIPJ8536+r9KDYwaQxjQXsLWc1tPhi4g3ZEdNtpSv/mkI+tq3QQ6rAn+ecKOieB2X 4TMg==
Received: by 10.52.27.1 with SMTP id p1mr1684421vdg.17.1332331331788; Wed, 21 Mar 2012 05:02:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Wed, 21 Mar 2012 05:01:51 -0700 (PDT)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Wed, 21 Mar 2012 13:01:51 +0100
Message-ID: 
To: Christer Holmberg 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmbzWoPkD/DEcdifzDpnt+fNFbk8qvb1jDeo3bD0gE3Nfuve+M/d8bQyl8sKfGhbeNyW08v
Cc: SIPCORE 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 21 Mar 2012 12:02:14 -0000

2012/3/21 Christer Holmberg :
>> In the case of outbound, the client has registered and so proved entitle=
d to receive outbound requests to the AOR or associated GRUU.
>
> Ok, so we need to think about whether registration is required from a sec=
urity perspective. But, not taking connection re-use into consideration, a =
normal (non-ob) registration is enough to ensure the client is entitled to =
receive requests, right?

To summarize: for a WS SIP client to register and receive incoming
requests, one of the following scenarios is required:

1) The client uses Outbound (and also the proxy) so we are done.

2) The client uses Connection-Reuse (so it must use secure WebSocket
wss:// and present a valid certificate to the server).

3) The client is capable of, not just initiating WS outgoing
connections, but also listening for incoming WS connections. So when
the proxy/registrar needs to send a request to the client it would
open (or reuse if already open) a WS connection to the address
indicated in the Contact of the REGISTER request.

We'll cover all the cases in the draft (since it's supposed to define
just a transport for SIP rather than enter into architecture details),
but obviously case 1 will be the true *usecase* in real life within
next years.




> And, again, with Outbound we would need to decide whether we are willing =
to accept a restriction saying that WS SIP only works when the registrar su=
pport Outbound.

In the following scenario:

  WS client ------ Outbound EDGE Proxy ------ Registrar

if the Registrar does not support Outbound but does support Path
(added to the REGISTER by the Outbound proxy) then incoming calls will
work (some Outbound features are lost of course). The Registrar would
add a Route header to incoming request for the client AoR and such a
Route would be a mirror of the Path previously added by the Outbound
proxy, which contains the Outbound connection identifier in the URI
username (so the Outbound proxy can reuse the existing WS connection
to route such a request to the client).

This is the *exact* scenario we have working in a real deployment for
demo/testing purposes. Please see slide #8 in:

  http://sip-on-the-web.aliax.net/


Regards.



--=20
I=C3=B1aki Baz Castillo


From christer.holmberg@ericsson.com  Wed Mar 21 05:15:53 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE1621F86DF for ; Wed, 21 Mar 2012 05:15:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.133
X-Spam-Level: 
X-Spam-Status: No, score=-10.133 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LsmGlgUwBcH for ; Wed, 21 Mar 2012 05:15:53 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BFDE021F86A1 for ; Wed, 21 Mar 2012 05:15:52 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-9d-4f69c677f3da
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DA.21.27041.776C96F4; Wed, 21 Mar 2012 13:15:51 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 21 Mar 2012 13:15:51 +0100
From: Christer Holmberg 
To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= 
Date: Wed, 21 Mar 2012 13:15:50 +0100
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
Thread-Index: Ac0HWnOcvnAVPP0eTX22NjWPoqwm6AAALmrw
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: SIPCORE 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 21 Mar 2012 12:15:53 -0000

SGksDQoNCj4+PiBJbiB0aGUgY2FzZSBvZiBvdXRib3VuZCwgdGhlIGNsaWVudCBoYXMgcmVnaXN0
ZXJlZCBhbmQgc28gcHJvdmVkIGVudGl0bGVkIHRvIHJlY2VpdmUgb3V0Ym91bmQgcmVxdWVzdHMg
dG8gdGhlIEFPUiBvciBhc3NvY2lhdGVkIEdSVVUuDQo+Pg0KPj4gT2ssIHNvIHdlIG5lZWQgdG8g
dGhpbmsgYWJvdXQgd2hldGhlciByZWdpc3RyYXRpb24gaXMgcmVxdWlyZWQgZnJvbSBhIHNlY3Vy
aXR5IHBlcnNwZWN0aXZlLiBCdXQsIG5vdCB0YWtpbmcgY29ubmVjdGlvbiByZS11c2UgaW50byBj
b25zaWRlcmF0aW9uLCBhIG5vcm1hbCAobm9uLW9iKSByZWdpc3RyYXRpb24gaXMgZW5vdWdoIHRv
IGVuc3VyZSB0aGUgY2xpZW50IGlzIGVudGl0bGVkIHRvIHJlY2VpdmUgcmVxdWVzdHMsIHJpZ2h0
Pw0KPg0KPiBUbyBzdW1tYXJpemU6IGZvciBhIFdTIFNJUCBjbGllbnQgdG8gcmVnaXN0ZXIgYW5k
IHJlY2VpdmUgaW5jb21pbmcgcmVxdWVzdHMsIG9uZSBvZiB0aGUgZm9sbG93aW5nIHNjZW5hcmlv
cyBpcyByZXF1aXJlZDoNCj4NCj4gMSkgVGhlIGNsaWVudCB1c2VzIE91dGJvdW5kIChhbmQgYWxz
byB0aGUgcHJveHkpIHNvIHdlIGFyZSBkb25lLg0KPg0KPiAyKSBUaGUgY2xpZW50IHVzZXMgQ29u
bmVjdGlvbi1SZXVzZSAoc28gaXQgbXVzdCB1c2Ugc2VjdXJlIFdlYlNvY2tldCB3c3M6Ly8gYW5k
IHByZXNlbnQgYSB2YWxpZCBjZXJ0aWZpY2F0ZSB0byB0aGUgc2VydmVyKS4NCj4NCj4gMykgVGhl
IGNsaWVudCBpcyBjYXBhYmxlIG9mLCBub3QganVzdCBpbml0aWF0aW5nIFdTIG91dGdvaW5nIGNv
bm5lY3Rpb25zLCBidXQgYWxzbyBsaXN0ZW5pbmcgZm9yIGluY29taW5nIFdTIGNvbm5lY3Rpb25z
LiBTbyB3aGVuIHRoZSBwcm94eS9yZWdpc3RyYXIgbmVlZHMgdG8gc2VuZCBhIHJlcXVlc3QgdG8g
dGhlIGNsaWVudCBpdCB3b3VsZCBvcGVuIChvciByZXVzZSBpZiBhbHJlYWR5IG9wZW4pIGEgV1Mg
Y29ubmVjdGlvbiB0byB0aGUgDQo+IGFkZHJlc3MgaW5kaWNhdGVkIGluIHRoZSBDb250YWN0IG9m
IHRoZSBSRUdJU1RFUiByZXF1ZXN0Lg0KDQpJIHN0aWxsIHRoaW5rIG9uZSBhbHRlcm5hdGl2ZSAo
NCksIGFzc3VtaW5nIHdlIGNhbiBhZGRyZXNzIHBvc3NpYmxlIHJlbGF0ZWQgc2VjdXJpdHkgaXNz
dWVzLCBjb3VsZCBiZSB0aGF0IHRoZSBjbGllbnQgYnkgZGVmYXVsdCBtdXN0IGJlIGFibGUgdG8g
cmVjZWl2ZSBpbmNvbWluZyByZXF1ZXN0cyBvbiB0aGUgb3V0Z29pbmcgV1MgY29ubmVjdGlvbiAt
IGF0IGxlYXN0IGlmIHRoZSBjbGllbnQgaGFzIHJlZ2lzdGVyZWQgKGZvciBzZWN1cml0eSByZWFz
b25zKS4gSW4gdGhhdCBjYXNlIG91dGJvdW5kIG1heSBub3QgYmUgbmVlZGVkLg0KDQo+IFdlJ2xs
IGNvdmVyIGFsbCB0aGUgY2FzZXMgaW4gdGhlIGRyYWZ0IChzaW5jZSBpdCdzIHN1cHBvc2VkIHRv
IGRlZmluZSBqdXN0IGEgdHJhbnNwb3J0IGZvciBTSVAgcmF0aGVyIHRoYW4gZW50ZXIgaW50byBh
cmNoaXRlY3R1cmUgZGV0YWlscyksIGJ1dCBvYnZpb3VzbHkgY2FzZSAxIHdpbGwgYmUgdGhlIHRy
dWUgKnVzZWNhc2UqIGluIHJlYWwgbGlmZSB3aXRoaW4gbmV4dCB5ZWFycy4NCg0KTWF5YmUgOikN
Cg0KDQo+PiBBbmQsIGFnYWluLCB3aXRoIE91dGJvdW5kIHdlIHdvdWxkIG5lZWQgdG8gZGVjaWRl
IHdoZXRoZXIgd2UgYXJlIHdpbGxpbmcgdG8gYWNjZXB0IGEgcmVzdHJpY3Rpb24gc2F5aW5nIHRo
YXQgV1MgU0lQIG9ubHkgd29ya3Mgd2hlbiB0aGUgcmVnaXN0cmFyIHN1cHBvcnQgT3V0Ym91bmQu
DQo+DQo+IEluIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW86DQo+DQo+ICBXUyBjbGllbnQgLS0tLS0t
IE91dGJvdW5kIEVER0UgUHJveHkgLS0tLS0tIFJlZ2lzdHJhcg0KPg0KPiBpZiB0aGUgUmVnaXN0
cmFyIGRvZXMgbm90IHN1cHBvcnQgT3V0Ym91bmQgYnV0IGRvZXMgc3VwcG9ydCBQYXRoIChhZGRl
ZCB0byB0aGUgUkVHSVNURVIgYnkgdGhlIE91dGJvdW5kIHByb3h5KSB0aGVuIGluY29taW5nIGNh
bGxzIHdpbGwgd29yayAoc29tZSBPdXRib3VuZCBmZWF0dXJlcyBhcmUgbG9zdCBvZiBjb3Vyc2Up
LiBUaGUgUmVnaXN0cmFyIHdvdWxkIGFkZCBhIFJvdXRlIGhlYWRlciB0byBpbmNvbWluZyByZXF1
ZXN0IA0KPiBmb3IgdGhlIGNsaWVudCBBb1IgYW5kIHN1Y2ggYSBSb3V0ZSB3b3VsZCBiZSBhIG1p
cnJvciBvZiB0aGUgUGF0aCBwcmV2aW91c2x5IGFkZGVkIGJ5IHRoZSBPdXRib3VuZCBwcm94eSwg
d2hpY2ggY29udGFpbnMgdGhlIE91dGJvdW5kIGNvbm5lY3Rpb24gaWRlbnRpZmllciBpbiB0aGUg
VVJJIHVzZXJuYW1lIChzbyB0aGUgT3V0Ym91bmQgcHJveHkgY2FuIHJldXNlIHRoZSBleGlzdGlu
ZyBXUyBjb25uZWN0aW9uIHRvIHJvdXRlIA0KPiBzdWNoIGEgcmVxdWVzdCB0byB0aGUgY2xpZW50
KS4NCj4NCj4gVGhpcyBpcyB0aGUgKmV4YWN0KiBzY2VuYXJpbyB3ZSBoYXZlIHdvcmtpbmcgaW4g
YSByZWFsIGRlcGxveW1lbnQgZm9yIGRlbW8vdGVzdGluZyBwdXJwb3Nlcy4gUGxlYXNlIHNlZSBz
bGlkZSAjOCBpbjoNCj4NCj4gIGh0dHA6Ly9zaXAtb24tdGhlLXdlYi5hbGlheC5uZXQvDQoNCkkn
bGwgaGF2ZSBhIGxvb2sgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K

From ibc@aliax.net  Wed Mar 21 05:37:44 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CE821F85A1 for ; Wed, 21 Mar 2012 05:37:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level: 
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=0.067,  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 HFgsXCjo26gG for ; Wed, 21 Mar 2012 05:37:44 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C95E121F859F for ; Wed, 21 Mar 2012 05:37:43 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so513883vbb.31 for ; Wed, 21 Mar 2012 05:37:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=EOGUgQBoQicJ0IL+P+1tMGU9SDW7jPU/dCE6yEeSb54=; b=hRBaA2lTgO9WcmCOPGJUAkA5iUXYiAQQKytjdKegKLQEr81Bydb4PugxxmuGbm4g7f o//r4vXU+/hrlHvpkabEijFtUkanU593kJvaNf0gR2x28mH41A23cxh4/P1hIDWw3jo6 bKvsWzKcUfVi8GRN2JApQlxxN7wV3tbaohb8cbfBg7hxhOi7ebgIuVagaiyy72husWEr MkLbRt3ojauY1Z6wyTt4AGPZYcUN/J5VwWLauzf6Dhm635FRKfKtfuorXOQsQSXZpo6E T6pCZ7AZcHJgD1WylGmIJlbcaR3J3hYTteoOfq11+DXjhBSh3JDkMmcEXBcmkB35K+4V DgjQ==
Received: by 10.52.27.1 with SMTP id p1mr1738810vdg.17.1332333463356; Wed, 21 Mar 2012 05:37:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Wed, 21 Mar 2012 05:37:23 -0700 (PDT)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Wed, 21 Mar 2012 13:37:23 +0100
Message-ID: 
To: Christer Holmberg 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQn5fdnAKw656CK+nZUfhh0mYCwWqz1hdjkQszVqW+niemha8RoIQp1D478Wah/bzxbpNKIr
Cc: SIPCORE 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 21 Mar 2012 12:37:44 -0000

2012/3/21 Christer Holmberg :
>> 3) The client is capable of, not just initiating WS outgoing connections=
, but also listening for incoming WS connections. So when the proxy/registr=
ar needs to send a request to the client it would open (or reuse if already=
 open) a WS connection to the
>> address indicated in the Contact of the REGISTER request.
>
> I still think one alternative (4), assuming we can address possible relat=
ed security issues, could be that the client by default must be able to rec=
eive incoming requests on the outgoing WS connection - at least if the clie=
nt has registered (for security reasons). In that case outbound may not be =
needed.

Christer, IMHO you are re-defining Outbound but without calling it "Outboun=
d" :)

What is the problem with Outbound? It's easy to implement and it just
works. Why to duplicate all the Outbound work for a new transport
instead of just suggesting the usage of Outbound for specific
usecases?

For a proxy to route an incoming request over an established incoming
connection, the request must contain some "identifier" that allows the
proxy to get the associated TCP/SCTP/WS connection and reuse it. So
defining some kind of "identifier" would be required, and that's
exactly what RFC 5626 (Outbound) does by adding such an identifier in
the Record-Route/Path URI and getting it from the Route URI in
subsequent requests. :)


Maybe I miss something, but I think SIP already defines the specs for
these scenarios to work regardless the used transport.

Best regards.



--=20
I=C3=B1aki Baz Castillo


From ibc@aliax.net  Wed Mar 21 05:55:48 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3921C21F85A1 for ; Wed, 21 Mar 2012 05:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level: 
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[AWL=0.066,  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 QyZQk1IFhGJf for ; Wed, 21 Mar 2012 05:55:47 -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 7A7FE21F8597 for ; Wed, 21 Mar 2012 05:55:47 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so1185256vcb.31 for ; Wed, 21 Mar 2012 05:55:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=1eOv/el3wlx1MsN6T94dQuN98JI2JziHd2H+TRc+NHY=; b=GprZJYYn+oYjX7KI/bNRiQeNAHpmZ2Gm4t/25crV1+Pi0xjOp/9eLQWZCDAI2eBoc7 QAQ4IKugPTvmcYQ2AffGVtoJE5qlNKCgwnBDlAh03c26wJgRL3kOmP0GIg/uup9xHcEl hSB3LwDKzQP7t8J09S9fy2Q1eK8+Lkt5/V/m2a4A0fXc0JztxmNNcG6/TNdpFaObWnV7 vxieIaN9d7pHd2ljYUq3oX0RMvmG2Vj1qvScI0ruY8f/cBOuxsTcD/Al83JpMraVxgnl 6pYL5e4W32Tt/9Eoke5LhICUBnEmSDU93imUBgZCRWBIhYDuzN6A9zr0pJ3ifsuRihoI +Ovw==
Received: by 10.220.157.7 with SMTP id z7mr2045571vcw.2.1332334546988; Wed, 21 Mar 2012 05:55:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Wed, 21 Mar 2012 05:55:26 -0700 (PDT)
In-Reply-To: 
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se> 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Wed, 21 Mar 2012 13:55:26 +0100
Message-ID: 
To: Christer Holmberg 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmWYCMmgNCESv7lZ06p8uYFEYAWcYYLA62V6zg4xtl2jGq+gVmvNMi75YjADzs/jurlDhw0
Cc: SIPCORE 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 21 Mar 2012 12:55:48 -0000

2012/3/21 I=C3=B1aki Baz Castillo :
>> I still think one alternative (4), assuming we can address possible rela=
ted security issues, could be that the client by default must be able to re=
ceive incoming requests on the outgoing WS connection - at least if the cli=
ent has registered (for security reasons). In that case outbound may not be=
 needed.

Sorry, I didn't properly understand your suggestion.

IMHO what you suggest is Connection Reuse but without security issues.
Then I wonder how such security issues could exist for TCP but not for
WebSocket. Given the work in RFC 5923 I expect that will be very
difficult to justify.

Regards.

--=20
I=C3=B1aki Baz Castillo


From pkyzivat@alum.mit.edu  Wed Mar 21 06:33:41 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301CA21F865B for ; Wed, 21 Mar 2012 06:33:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level: 
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040,  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 mjLsk1EnPHy3 for ; Wed, 21 Mar 2012 06:33:40 -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 6124621F865A for ; Wed, 21 Mar 2012 06:33:40 -0700 (PDT)
Received: from omta19.westchester.pa.mail.comcast.net ([76.96.62.98]) by qmta14.westchester.pa.mail.comcast.net with comcast id oBHg1i00427AodY5EDZgxk; Wed, 21 Mar 2012 13:33:40 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta19.westchester.pa.mail.comcast.net with comcast id oDZg1i00H07duvL3fDZg9w; Wed, 21 Mar 2012 13:33:40 +0000
Message-ID: <4F69D8B2.7080805@alum.mit.edu>
Date: Wed, 21 Mar 2012 09:33:38 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Christer Holmberg 
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: SIPCORE 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 21 Mar 2012 13:33:41 -0000

On 3/21/12 2:43 AM, Christer Holmberg wrote:
> Hi,
>
>>>>> Also, I don't think we need Outbound in order to say that requests from the server to the client shall use an existing WS connection from the client.
>>>>
>>>> If the WebSocket SIP entity (whatever) does not listen for incoming connections then it needs Outbound or Connection Reuse (RFC 5923).
>>>> Those are the only two standarized ways in which incoming requests
>>>> would reuse the connection open by the WebSocket client. In the case of UAs (SIP endpoints) Outbound seems the complete solution. In the case of proxies/B2BUAs, RFC 5923
>>>> seems the choice.
>>>
>>> We are defining the WS transport for SIP. Can't we simply say that, by default, a server shall use an existing WS connection towards the client? No need for any extensions to negotiate
>>> it.
>>
>> No. You are ignoring all the issues that came up in work on outbound and connection-reuse.
>
> Probably :)
>
>>> OR, if we want to be able to explicitly request reverse connection re-use, we mandate the usage of RFC 5923 (unless Outbound is enabled), but say that a server must ONLY use an
>>> existing connection.
>>
>> IIRC, 5923 only allows reuse of connections when the server has received a certificate from the client. Most clients using this draft won't have client certificates.
>
> True.
>
>> In the case of outbound, the client has registered and so proved entitled to receive outbound requests to the AOR or associated GRUU.
>
> Ok, so we need to think about whether registration is required from a security perspective. But, not taking connection re-use into consideration, a normal (non-ob) registration is enough to ensure the client is entitled to receive requests, right?

The registration entitles the client to receive requests at the contact 
address registered. But its up to the registrar/proxy forwarding the 
requests to select a trusted path to that address. Typically that means 
a connection initiated toward that contact address. It takes something 
extra (e.g. outbound / connection-reuse) for that server to believe that 
a connection established to it is appropriate.

> And, from a client perspective, unless a client is willing to receive requests on the WS connection it shouldn't establish the WS connection in the first place.

The problem isn't at the client end. The problem is whether the server 
is willing to use the WS connection - that it is a suitable alias.

	Thanks,
	Paul

> And, again, with Outbound we would need to decide whether we are willing to accept a restriction saying that WS SIP only works when the registrar support Outbound. Maybe it's not a real-life problem, in which case it would not be an issue :)
>
> Regards,
>
> Christer
>
>
>
>
>
>>> maybe there will be specific parts of Outbound that we need to mandate, but then we should mandate those specific parts.
>>
>>> IMHO there is no need to mandate neither some specific parts of
>>> Outbound spec. If for example a SIP proxy/server is capable of opening and also listening for WebSocket connections, then the WebSocket transport becomes similar to what SIP over TCP or STCP involves. There is no need to reuse the initial WS connection for requests in reverse order, but just let the peer to open a new WS connection with us (same as TCP/SCTP when Outbound or RFC 5923 are not used).
>>
>> Sure.
>>
>> Regards,
>>
>> Christer
>>
>


From christer.holmberg@ericsson.com  Wed Mar 21 06:47:06 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935A221F860F for ; Wed, 21 Mar 2012 06:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.285
X-Spam-Level: 
X-Spam-Status: No, score=-10.285 tagged_above=-999 required=5 tests=[AWL=0.314, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3lHsrD1JFJT for ; Wed, 21 Mar 2012 06:47:06 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id B6A4A21F8607 for ; Wed, 21 Mar 2012 06:47:05 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-24-4f69dbd831ca
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 04.6A.17856.8DBD96F4; Wed, 21 Mar 2012 14:47:04 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 21 Mar 2012 14:47:03 +0100
From: Christer Holmberg 
To: Paul Kyzivat 
Date: Wed, 21 Mar 2012 14:47:03 +0100
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
Thread-Index: Ac0HZzqre+KXD/+LRReKI7PtMr7R7QAAICpg
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C414574F7@ESESSCMS0356.eemea.ericsson.se>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se> <4F69D8B2.7080805@alum.mit.edu>
In-Reply-To: <4F69D8B2.7080805@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: SIPCORE 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 21 Mar 2012 13:47:06 -0000

SGksDQoNCj4+Pj4+PiBBbHNvLCBJIGRvbid0IHRoaW5rIHdlIG5lZWQgT3V0Ym91bmQgaW4gb3Jk
ZXIgdG8gc2F5IHRoYXQgcmVxdWVzdHMgZnJvbSB0aGUgc2VydmVyIHRvIHRoZSBjbGllbnQgc2hh
bGwgdXNlIGFuIGV4aXN0aW5nIFdTIGNvbm5lY3Rpb24gZnJvbSB0aGUgY2xpZW50Lg0KPj4+Pj4N
Cj4+Pj4+IElmIHRoZSBXZWJTb2NrZXQgU0lQIGVudGl0eSAod2hhdGV2ZXIpIGRvZXMgbm90IGxp
c3RlbiBmb3IgaW5jb21pbmcgY29ubmVjdGlvbnMgdGhlbiBpdCBuZWVkcyBPdXRib3VuZCBvciBD
b25uZWN0aW9uIFJldXNlIChSRkMgNTkyMykuDQo+Pj4+PiBUaG9zZSBhcmUgdGhlIG9ubHkgdHdv
IHN0YW5kYXJpemVkIHdheXMgaW4gd2hpY2ggaW5jb21pbmcgcmVxdWVzdHMgDQo+Pj4+PiB3b3Vs
ZCByZXVzZSB0aGUgY29ubmVjdGlvbiBvcGVuIGJ5IHRoZSBXZWJTb2NrZXQgY2xpZW50LiBJbiB0
aGUgDQo+Pj4+PiBjYXNlIG9mIFVBcyAoU0lQIGVuZHBvaW50cykgT3V0Ym91bmQgc2VlbXMgdGhl
IGNvbXBsZXRlIHNvbHV0aW9uLiBJbiB0aGUgY2FzZSBvZiBwcm94aWVzL0IyQlVBcywgUkZDIDU5
MjMgc2VlbXMgdGhlIGNob2ljZS4NCj4+Pj4NCj4+Pj4gV2UgYXJlIGRlZmluaW5nIHRoZSBXUyB0
cmFuc3BvcnQgZm9yIFNJUC4gQ2FuJ3Qgd2Ugc2ltcGx5IHNheSB0aGF0LCANCj4+Pj4gYnkgZGVm
YXVsdCwgYSBzZXJ2ZXIgc2hhbGwgdXNlIGFuIGV4aXN0aW5nIFdTIGNvbm5lY3Rpb24gdG93YXJk
cyB0aGUgY2xpZW50PyBObyBuZWVkIGZvciBhbnkgZXh0ZW5zaW9ucyB0byBuZWdvdGlhdGUgaXQu
DQo+Pj4NCj4+PiBOby4gWW91IGFyZSBpZ25vcmluZyBhbGwgdGhlIGlzc3VlcyB0aGF0IGNhbWUg
dXAgaW4gd29yayBvbiBvdXRib3VuZCBhbmQgY29ubmVjdGlvbi1yZXVzZS4NCj4+DQo+PiBQcm9i
YWJseSA6KQ0KPj4NCj4+Pj4gT1IsIGlmIHdlIHdhbnQgdG8gYmUgYWJsZSB0byBleHBsaWNpdGx5
IHJlcXVlc3QgcmV2ZXJzZSBjb25uZWN0aW9uIA0KPj4+PiByZS11c2UsIHdlIG1hbmRhdGUgdGhl
IHVzYWdlIG9mIFJGQyA1OTIzICh1bmxlc3MgT3V0Ym91bmQgaXMgZW5hYmxlZCksIGJ1dCBzYXkg
dGhhdCBhIHNlcnZlciBtdXN0IE9OTFkgdXNlIGFuIGV4aXN0aW5nIGNvbm5lY3Rpb24uDQo+Pj4N
Cj4+PiBJSVJDLCA1OTIzIG9ubHkgYWxsb3dzIHJldXNlIG9mIGNvbm5lY3Rpb25zIHdoZW4gdGhl
IHNlcnZlciBoYXMgcmVjZWl2ZWQgYSBjZXJ0aWZpY2F0ZSBmcm9tIHRoZSBjbGllbnQuIE1vc3Qg
Y2xpZW50cyB1c2luZyB0aGlzIGRyYWZ0IHdvbid0IGhhdmUgY2xpZW50IGNlcnRpZmljYXRlcy4N
Cj4+DQo+PiBUcnVlLg0KPj4NCj4+PiBJbiB0aGUgY2FzZSBvZiBvdXRib3VuZCwgdGhlIGNsaWVu
dCBoYXMgcmVnaXN0ZXJlZCBhbmQgc28gcHJvdmVkIGVudGl0bGVkIHRvIHJlY2VpdmUgb3V0Ym91
bmQgcmVxdWVzdHMgdG8gdGhlIEFPUiBvciBhc3NvY2lhdGVkIEdSVVUuDQo+Pg0KPj4gT2ssIHNv
IHdlIG5lZWQgdG8gdGhpbmsgYWJvdXQgd2hldGhlciByZWdpc3RyYXRpb24gaXMgcmVxdWlyZWQg
ZnJvbSBhIHNlY3VyaXR5IHBlcnNwZWN0aXZlLiBCdXQsIG5vdCB0YWtpbmcgY29ubmVjdGlvbiBy
ZS11c2UgaW50byBjb25zaWRlcmF0aW9uLCBhIG5vcm1hbCAobm9uLW9iKSByZWdpc3RyYXRpb24g
aXMgZW5vdWdoIHRvIGVuc3VyZSB0aGUgY2xpZW50IGlzIGVudGl0bGVkIHRvIHJlY2VpdmUgcmVx
dWVzdHMsIHJpZ2h0Pw0KPg0KPiBUaGUgcmVnaXN0cmF0aW9uIGVudGl0bGVzIHRoZSBjbGllbnQg
dG8gcmVjZWl2ZSByZXF1ZXN0cyBhdCB0aGUgY29udGFjdCBhZGRyZXNzIHJlZ2lzdGVyZWQuIEJ1
dCBpdHMgdXAgdG8gdGhlIHJlZ2lzdHJhci9wcm94eSBmb3J3YXJkaW5nIHRoZSByZXF1ZXN0cyB0
byBzZWxlY3QgYSB0cnVzdGVkIHBhdGggdG8gdGhhdCBhZGRyZXNzLiBUeXBpY2FsbHkgdGhhdCBt
ZWFucyBhIGNvbm5lY3Rpb24gaW5pdGlhdGVkIHRvd2FyZCB0aGF0IGNvbnRhY3QgDQo+IGFkZHJl
c3MuIEl0IHRha2VzIHNvbWV0aGluZyBleHRyYSAoZS5nLiBvdXRib3VuZCAvIGNvbm5lY3Rpb24t
cmV1c2UpIGZvciB0aGF0IHNlcnZlciB0byBiZWxpZXZlIHRoYXQgYSBjb25uZWN0aW9uIGVzdGFi
bGlzaGVkIHRvIGl0IGlzIGFwcHJvcHJpYXRlLg0KPg0KPj4gQW5kLCBmcm9tIGEgY2xpZW50IHBl
cnNwZWN0aXZlLCB1bmxlc3MgYSBjbGllbnQgaXMgd2lsbGluZyB0byByZWNlaXZlIHJlcXVlc3Rz
IG9uIHRoZSBXUyBjb25uZWN0aW9uIGl0IHNob3VsZG4ndCBlc3RhYmxpc2ggdGhlIFdTIGNvbm5l
Y3Rpb24gaW4gdGhlIGZpcnN0IHBsYWNlLg0KPg0KPiBUaGUgcHJvYmxlbSBpc24ndCBhdCB0aGUg
Y2xpZW50IGVuZC4gVGhlIHByb2JsZW0gaXMgd2hldGhlciB0aGUgc2VydmVyIGlzIHdpbGxpbmcg
dG8gdXNlIHRoZSBXUyBjb25uZWN0aW9uIC0gdGhhdCBpdCBpcyBhIHN1aXRhYmxlIGFsaWFzLg0K
DQpUcnVlLiBCdXQsIGFzc3VtaW5nIGl0IHdvdWxkIGJlIGFsbG93ZWQgdG8gcmUtdXNlIGEgKnJl
Z2lzdGVyZWQqIFdTIGNvbm5lY3Rpb24gYnkgZGVmYXVsdCwgZG9lcyBvdXRib3VuZCBicmluZyBh
bnl0aGluZyBleHRyYSBhcyBmYXIgYXMgdGhlIGNvbm5lY3Rpb24gdmVyaWZpY2F0aW9uIGlzIGNv
bmNlcm5lZD8NCg0KQmVjYXVzZSwgSSBhc3N1bWUgd2Ugd291bGQgc3RpbGwgYWxsb3cgdGhlIGVk
Z2UgcHJveHkgdG8gcmUtdXNlIHRoZSBXUyBjb25uZWN0aW9uIGV2ZW4gaWYgdGhlIHJlZ2lzdHJh
ciBkb2VzIE5PVCBzdXBwb3J0IE91dGJvdW5kIC0gYXMgbG9uZyBhcyB0aGUgcmVnaXN0cmF0aW9u
IGFzIHN1Y2ggc3VjY2VlZHMuIE9yPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K

From christer.holmberg@ericsson.com  Wed Mar 21 06:51:40 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B44C521F86AA for ; Wed, 21 Mar 2012 06:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.138
X-Spam-Level: 
X-Spam-Status: No, score=-10.138 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyyfY1ujKXlt for ; Wed, 21 Mar 2012 06:51:40 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id F0F9421F865B for ; Wed, 21 Mar 2012 06:51:39 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-47-4f69dcea4c64
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D0.5B.17856.AECD96F4; Wed, 21 Mar 2012 14:51:39 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 21 Mar 2012 14:51:38 +0100
From: Christer Holmberg 
To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= 
Date: Wed, 21 Mar 2012 14:51:38 +0100
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
Thread-Index: Ac0HYfADykEeucHDQAabZzGLVRWNAQAB13Ug
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: SIPCORE 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 21 Mar 2012 13:51:40 -0000

SGksDQoNCj4+IEkgc3RpbGwgdGhpbmsgb25lIGFsdGVybmF0aXZlICg0KSwgYXNzdW1pbmcgd2Ug
Y2FuIGFkZHJlc3MgcG9zc2libGUgcmVsYXRlZCBzZWN1cml0eSBpc3N1ZXMsIGNvdWxkIGJlIHRo
YXQgdGhlIGNsaWVudCBieSBkZWZhdWx0IG11c3QgYmUgYWJsZSB0byByZWNlaXZlIGluY29taW5n
IHJlcXVlc3RzIA0KPj4gb24gdGhlIG91dGdvaW5nIFdTIGNvbm5lY3Rpb24gLSBhdCBsZWFzdCBp
ZiB0aGUgY2xpZW50IGhhcyByZWdpc3RlcmVkIChmb3Igc2VjdXJpdHkgPj4gcmVhc29ucykuIElu
IHRoYXQgY2FzZSBvdXRib3VuZCBtYXkgbm90IGJlIG5lZWRlZC4NCj4NCj4gU29ycnksIEkgZGlk
bid0IHByb3Blcmx5IHVuZGVyc3RhbmQgeW91ciBzdWdnZXN0aW9uLg0KPg0KPiBJTUhPIHdoYXQg
eW91IHN1Z2dlc3QgaXMgQ29ubmVjdGlvbiBSZXVzZSBidXQgd2l0aG91dCBzZWN1cml0eSBpc3N1
ZXMuDQo+IFRoZW4gSSB3b25kZXIgaG93IHN1Y2ggc2VjdXJpdHkgaXNzdWVzIGNvdWxkIGV4aXN0
IGZvciBUQ1AgYnV0IG5vdCBmb3IgV2ViU29ja2V0LiBHaXZlbiB0aGUgd29yayBpbiBSRkMgNTky
MyBJIGV4cGVjdCB0aGF0IHdpbGwgYmUgdmVyeSBkaWZmaWN1bHQgdG8ganVzdGlmeS4NCg0KV2Ug
RE8gaGF2ZSB0byBkZWFsIHdpdGggdGhlIHNlY3VyaXR5IGlzc3VlcywgYW5kIGJlY2F1c2Ugb2Yg
dGhhdCB3ZSBtYXkgaGF2ZSB0byBtYW5kYXRlIFNJUCByZWdpc3RyYXRpb25zLg0KDQpCdXQsIGlm
IHdlIG1hbmRhdGUgU0lQIHJlZ2lzdHJhdGlvbnMsIGFuZCBhbGxvdyBjb25uZWN0aW9uIHJlLXVz
ZSBhcyBkZWZhdWx0IChhc3N1bWluZyB0aGUgY2xpZW50IGhhcyByZWdpc3RlcmVkKSwgZG9lcyBP
dXRib3VuZCBicmluZyBhbnl0aGluZyBleHRyYSBmcm9tIGEgc2VjdXJpdHkgcGVyc3BlY3RpdmU/
DQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg==

From ibc@aliax.net  Wed Mar 21 07:06:10 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538FB21F860D for ; Wed, 21 Mar 2012 07:06:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.612
X-Spam-Level: 
X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[AWL=0.065,  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 9+nLBJlP5hDJ for ; Wed, 21 Mar 2012 07:06:09 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 92CC221F85E5 for ; Wed, 21 Mar 2012 07:06:09 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so1270599vcb.31 for ; Wed, 21 Mar 2012 07:06:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=AYsbKB1+KoVB4xpFVizHGQv1YHS+vrwdo3TkB7+ERDQ=; b=Iel/9DBQMjNH/go2jbSOENX1I62wy3uag6jQEcFssRe0ogUj1Yv01utzJfa+Lkchrm sn01AAhyEU5RR/0hgwUygEsVHXGkpc7WsenEXVABJ/HC8toovoGqR+ZXLvisFGBEfHDo 2tTlekJueu7+XbR0ESGYhHcE7DbnBPsl2MAJ3/VE3P/BMFgHnKOKqb7GJpOwZr+uwnal GbmAvq4I6r1RrwTjPduovW4Gr7GhbzDIYV+AxmCmvryI4jxYiTz/eqnOun27rVcY7KW7 w3b1ffOAwvdHOD0A7jphTl3vs+VBJlTUaxt+3g3Mf094OCu6MNyHSEc/d57cpvp5ldLP uOnQ==
Received: by 10.220.140.196 with SMTP id j4mr2155790vcu.22.1332338769077; Wed, 21 Mar 2012 07:06:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Wed, 21 Mar 2012 07:05:48 -0700 (PDT)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Wed, 21 Mar 2012 15:05:48 +0100
Message-ID: 
To: Christer Holmberg 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkPpHiTiAkWGlhiDk44O+/pS0/PQz2bn09CWccWFFq5hBovDX5vfU2CSlvRV4Xf5s7jxNrA
Cc: SIPCORE 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 21 Mar 2012 14:06:10 -0000

2012/3/21 Christer Holmberg :
> But, if we mandate SIP registrations, and allow connection re-use as defa=
ult (assuming the client has registered), does Outbound bring anything extr=
a from a security perspective?

I would like to give a different perspective (not so related to
security) to this topic. Let's suppose:

- A SIP TCP client behind NAT.
- A SIP WebSocket client (behind NAT or not).

Both are "endpoints" / "end users", not a proxy, server or b2bua.

In both cases, these clients cannot receive incoming connections from
the proxy/registrar. Therefore they open a connection with the
proxy/registrar and, in some way, incoming requests need to be routed
over that connection. So:

1) The solution for the SIP TCP case is to implement Outbound.
2) Outbound also solves the SIP WebSocket case.

Then, why should we define a new and different solution for the SIP
WebSocket case?
And, if we define such a new solution, why not to extend it also to
TCP transport (with no TLS)?

Regards.


--=20
I=C3=B1aki Baz Castillo


From christer.holmberg@ericsson.com  Wed Mar 21 07:23:30 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A9721F86F9 for ; Wed, 21 Mar 2012 07:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.14
X-Spam-Level: 
X-Spam-Status: No, score=-10.14 tagged_above=-999 required=5 tests=[AWL=0.159,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-m07Nn8hAiz for ; Wed, 21 Mar 2012 07:23:30 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A6DC321F86F6 for ; Wed, 21 Mar 2012 07:23:29 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-63-4f69e46058e2
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4C.6B.27041.064E96F4; Wed, 21 Mar 2012 15:23:28 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Wed, 21 Mar 2012 15:23:28 +0100
From: Christer Holmberg 
To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= 
Date: Wed, 21 Mar 2012 15:23:27 +0100
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
Thread-Index: Ac0Ha8SWQGP4i/7vRs+8Wf6MgUfN5gAALEZg
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C41457561@ESESSCMS0356.eemea.ericsson.se>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: SIPCORE 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 21 Mar 2012 14:23:30 -0000

SGksDQoNCj4+IEJ1dCwgaWYgd2UgbWFuZGF0ZSBTSVAgcmVnaXN0cmF0aW9ucywgYW5kIGFsbG93
IGNvbm5lY3Rpb24gcmUtdXNlIGFzIGRlZmF1bHQgKGFzc3VtaW5nIHRoZSBjbGllbnQgaGFzIHJl
Z2lzdGVyZWQpLCBkb2VzIE91dGJvdW5kIGJyaW5nIGFueXRoaW5nIGV4dHJhIGZyb20gYSBzZWN1
cml0eSBwZXJzcGVjdGl2ZT8NCj4NCj4gSSB3b3VsZCBsaWtlIHRvIGdpdmUgYSBkaWZmZXJlbnQg
cGVyc3BlY3RpdmUgKG5vdCBzbyByZWxhdGVkIHRvIHNlY3VyaXR5KSB0byB0aGlzIHRvcGljLiBM
ZXQncyBzdXBwb3NlOg0KPg0KPiAtIEEgU0lQIFRDUCBjbGllbnQgYmVoaW5kIE5BVC4NCj4gLSBB
IFNJUCBXZWJTb2NrZXQgY2xpZW50IChiZWhpbmQgTkFUIG9yIG5vdCkuDQo+DQo+IEJvdGggYXJl
ICJlbmRwb2ludHMiIC8gImVuZCB1c2VycyIsIG5vdCBhIHByb3h5LCBzZXJ2ZXIgb3IgYjJidWEu
DQo+DQo+IEluIGJvdGggY2FzZXMsIHRoZXNlIGNsaWVudHMgY2Fubm90IHJlY2VpdmUgaW5jb21p
bmcgY29ubmVjdGlvbnMgZnJvbSB0aGUgcHJveHkvcmVnaXN0cmFyLiBUaGVyZWZvcmUgdGhleSBv
cGVuIGEgY29ubmVjdGlvbiB3aXRoIHRoZSBwcm94eS9yZWdpc3RyYXIgYW5kLCBpbiBzb21lIHdh
eSwgaW5jb21pbmcgcmVxdWVzdHMgbmVlZCB0byBiZSByb3V0ZWQgb3ZlciB0aGF0IGNvbm5lY3Rp
b24uIFNvOg0KPg0KPiAxKSBUaGUgc29sdXRpb24gZm9yIHRoZSBTSVAgVENQIGNhc2UgaXMgdG8g
aW1wbGVtZW50IE91dGJvdW5kLg0KPiAyKSBPdXRib3VuZCBhbHNvIHNvbHZlcyB0aGUgU0lQIFdl
YlNvY2tldCBjYXNlLg0KPg0KPiBUaGVuLCB3aHkgc2hvdWxkIHdlIGRlZmluZSBhIG5ldyBhbmQg
ZGlmZmVyZW50IHNvbHV0aW9uIGZvciB0aGUgU0lQIFdlYlNvY2tldCBjYXNlPw0KPiBBbmQsIGlm
IHdlIGRlZmluZSBzdWNoIGEgbmV3IHNvbHV0aW9uLCB3aHkgbm90IHRvIGV4dGVuZCBpdCBhbHNv
IHRvIFRDUCB0cmFuc3BvcnQgKHdpdGggbm8gVExTKT8NCg0KQmVjYXVzZSwgIGZvciBUQ1AvVExT
IHRoZXJlIGFyZSBtYW55IGNhc2VzIHdoZXJlIHlvdSBtYXkgbm90IHdhbnQvbmVlZCBjb25uZWN0
aW9uIHJlLXVzZS4gSSBhbSBzdGlsbCBxdWVzdGlvbmluZyB3aGV0aGVyIHRoZXJlIHdpbGwgYmUg
YSBzaW1pbGFyIGNhc2VzIGZvciBTSVAgV1MuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg==

From pravindran@sonusnet.com  Wed Mar 21 07:33:57 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93EF921F8501 for ; Wed, 21 Mar 2012 07:33:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.408
X-Spam-Level: 
X-Spam-Status: No, score=-6.408 tagged_above=-999 required=5 tests=[AWL=-0.109, 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 c1WJTAGtbHUP for ; Wed, 21 Mar 2012 07:33:56 -0700 (PDT)
Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3F96E21F84FF for ; Wed, 21 Mar 2012 07:33:56 -0700 (PDT)
Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKT2nm07EEOrYVTlgjWpANcZNefYyX31uC@postini.com; Wed, 21 Mar 2012 07:33:56 PDT
Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 21 Mar 2012 10:34:10 -0400
Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Wed, 21 Mar 2012 20:03:51 +0530
From: "Ravindran, Parthasarathi" 
To: Christer Holmberg , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
Thread-Index: AQHNBp/0VSI3yg3CHUWTRsteJDbZlZZy3OuAgAAGcICAAAWdgIAAJLgAgADktACAAFj1gIAAA+gAgAAGBYCAAAUMAIAAD7MAgAAD9gCAAATugIAAXsAA
Date: Wed, 21 Mar 2012 14:33:50 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E206DF7@inba-mail01.sonusnet.com>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457561@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C41457561@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.70.54.61]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: SIPCORE 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 21 Mar 2012 14:33:57 -0000

Hi Christer,

I think in the same line wherein connection-reuse or outbound is not requir=
ed in WS as well. WS should not be much different from SIP TCP connection.

Thanks
Partha

>-----Original Message-----
>From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
>Behalf Of Christer Holmberg
>Sent: Wednesday, March 21, 2012 7:53 PM
>To: I=F1aki Baz Castillo
>Cc: SIPCORE
>Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-
>websocket (Outbound and more)
>
>Hi,
>
>>> But, if we mandate SIP registrations, and allow connection re-use as
>default (assuming the client has registered), does Outbound bring
>anything extra from a security perspective?
>>
>> I would like to give a different perspective (not so related to
>security) to this topic. Let's suppose:
>>
>> - A SIP TCP client behind NAT.
>> - A SIP WebSocket client (behind NAT or not).
>>
>> Both are "endpoints" / "end users", not a proxy, server or b2bua.
>>
>> In both cases, these clients cannot receive incoming connections from
>the proxy/registrar. Therefore they open a connection with the
>proxy/registrar and, in some way, incoming requests need to be routed
>over that connection. So:
>>
>> 1) The solution for the SIP TCP case is to implement Outbound.
>> 2) Outbound also solves the SIP WebSocket case.
>>
>> Then, why should we define a new and different solution for the SIP
>WebSocket case?
>> And, if we define such a new solution, why not to extend it also to
>TCP transport (with no TLS)?
>
>Because,  for TCP/TLS there are many cases where you may not want/need
>connection re-use. I am still questioning whether there will be a
>similar cases for SIP WS.
>
>Regards,
>
>Christer
>
>_______________________________________________
>sipcore mailing list
>sipcore@ietf.org
>https://www.ietf.org/mailman/listinfo/sipcore

From christer.holmberg@ericsson.com  Wed Mar 21 13:26:04 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907F121F8595 for ; Wed, 21 Mar 2012 13:26:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.142
X-Spam-Level: 
X-Spam-Status: No, score=-10.142 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KorUyaX4g-ju for ; Wed, 21 Mar 2012 13:26:04 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id CE7FB21F85B5 for ; Wed, 21 Mar 2012 13:26:03 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-36-4f6a395ab2ef
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B7.B9.27041.A593A6F4; Wed, 21 Mar 2012 21:26:02 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 21 Mar 2012 21:26:02 +0100
From: Christer Holmberg 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , "SIPCORE (Session Initiation Protocol Core) WG" 
Date: Wed, 21 Mar 2012 21:26:01 +0100
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
Thread-Index: AQHNB6DVppijaua0gEWtu8Q+f3rWrg==
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Mar 2012 20:26:04 -0000

Hi,

Some thoughts about GRUU.

> About GRUU:
> --------------------
>
> For those SIP endpoints which don't listen for incoming WebSocket
> connections, GRUU is required. The following example attemps to
> justify it:
>
> - Alice (WS SIP UA) is in a call with Bob (SIP UDP UA).
> - Bob sends a REFER to Carol (SIP UDP UA) with "Refer-To: ALICE_CONTACT_U=
RI".
> - Carol sends an INVITE to ALICE_CONTACT_URI.
>
> The only way in which the INVITE can arrive to Alice is the case in
> which ALICE_CONTACT_URI is a GRUU URI, so the INVITE would reach
> Alice's inbound proxy/registrar and that would route the request to
> Alice using the existing WebSocket connection (of course there could
> be an Outbound Edge proxy between Alice and the registrar).

So, that is the classical transfer use-case, for which GRUU was more or les=
s originally defined, right?

But, that applies also to other transports, so is there some SIP WS specifi=
c reason why we would generally mandate GRUU?=20

When Alice registers her contact, no matter whether it's a GRUU or not, the=
 WS server will need to maintain a mapping between the registered contact a=
nd the associated WS connection, in order to route incoming calls towards A=
lice.

And, as for outbound, keep in mind that the registrar may not support GRUU =
:)

Regards,

Christer=

From ibc@aliax.net  Wed Mar 21 14:01:55 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7B521E811E for ; Wed, 21 Mar 2012 14:01:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.613
X-Spam-Level: 
X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[AWL=0.064,  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 j2Z1QCO-y4AX for ; Wed, 21 Mar 2012 14:01:55 -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 0BB8421E811D for ; Wed, 21 Mar 2012 14:01:54 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so1719563vcb.31 for ; Wed, 21 Mar 2012 14:01:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=wlpqcU9qYrpLftgMeXfsPy+Uvl66Zn+y/meWw6eh2gE=; b=GKnZKT1VrdSJ+aXKn8cWKrMjtExTEQodlkiFI7nw7c9iiQxAINwisOWwhJbuE/ftbq /cgLKVHqWUWELdQq68kHC+CGDx+60sIEJhgnquUKEUgtwdESLmgwF1QcFgTVZft6DdLP Qr7dgSXr8qYrFFcwXAO2KppcR68nBnU1i83nreSte8hkjSpFxQQ+6051BIbDVM5aO38I 9PRcs5T7/swQ8mV9tHaaG3zhtGGJHnD//yfuKbWjOnjPSEeD2xDl7wYcP8YJiZVpLIiU tgntucxxmiUYGmkOVEJM1WTv5XaQz/O1mWkqqE1uel4HO4U7QtdVGBNid1+E2v6r9qWZ As9g==
Received: by 10.52.90.111 with SMTP id bv15mr2438566vdb.34.1332363714582; Wed, 21 Mar 2012 14:01:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Wed, 21 Mar 2012 14:01:34 -0700 (PDT)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Wed, 21 Mar 2012 22:01:34 +0100
Message-ID: 
To: Christer Holmberg 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQl9idkN36c8Z3ijwWbpZgxXJ3ovJez+Tf80W0nOT4NIhvhj2ZZkbStG3Psd2GVV/1aXSPP7
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Mar 2012 21:01:55 -0000

2012/3/21 Christer Holmberg :
> So, that is the classical transfer use-case, for which GRUU was more or l=
ess originally defined, right?
>
> But, that applies also to other transports, so is there some SIP WS speci=
fic reason why we would generally mandate GRUU?
>
> When Alice registers her contact, no matter whether it's a GRUU or not, t=
he WS server will need to maintain a mapping between the registered contact=
 and the associated WS connection, in order to route incoming calls towards=
 Alice.
>
> And, as for outbound, keep in mind that the registrar may not support GRU=
U :)

Right. The fact is that we don't want to mandate GRUU (not at least in
the last proposal suggested in the mail you reply to). We just suggest
that for common scenarios in which Outbound is required, GRUU is also
required (but as you say, this is the exact case as for a SIP TCP
client behind NAT).

In both cases (a SIP TCP client behind NAT or common SIP WS client)
the same Outbound/GRUU requirements are needed, so we consider that
this is not something to be mandated by the draft (it could be
explained in an "Implementation Guidelines" Appendix however).


Regards.

--=20
I=C3=B1aki Baz Castillo


From pkyzivat@alum.mit.edu  Wed Mar 21 14:02:34 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46A421E8128 for ; Wed, 21 Mar 2012 14:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.559
X-Spam-Level: 
X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040,  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 gKp8XadG15tp for ; Wed, 21 Mar 2012 14:02:34 -0700 (PDT)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id D21B921E8122 for ; Wed, 21 Mar 2012 14:02:33 -0700 (PDT)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by QMTA11.westchester.pa.mail.comcast.net with comcast id oLLr1i0011swQuc5BM2a7L; Wed, 21 Mar 2012 21:02:34 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta15.westchester.pa.mail.comcast.net with comcast id oM2Z1i03A07duvL3bM2ZW8; Wed, 21 Mar 2012 21:02:34 +0000
Message-ID: <4F6A41EB.4020001@alum.mit.edu>
Date: Wed, 21 Mar 2012 17:02:35 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Christer Holmberg 
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se> <4F69D8B2.7080805@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414574F7@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C414574F7@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: SIPCORE 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 21 Mar 2012 21:02:34 -0000

On 3/21/12 9:47 AM, Christer Holmberg wrote:

>> The problem isn't at the client end. The problem is whether the server is willing to use the WS connection - that it is a suitable alias.
>
> True. But, assuming it would be allowed to re-use a *registered* WS connection by default, does outbound bring anything extra as far as the connection verification is concerned?
>
> Because, I assume we would still allow the edge proxy to re-use the WS connection even if the registrar does NOT support Outbound - as long as the registration as such succeeds. Or?

I don't want to misrepresent things here. I *think* there were more 
subtleties to it than that. I sent a query to Cullen, Vijay, and Brett, 
who are authors on outbound and connect-reuse, in hopes that one of them 
can dredge up more of those subtleties.

	Thanks,
	Paul

From salvatore.loreto@ericsson.com  Wed Mar 21 14:21:00 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FD021F866D for ; Wed, 21 Mar 2012 14:21:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.042
X-Spam-Level: 
X-Spam-Status: No, score=-110.042 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkVWlRLnzxQJ for ; Wed, 21 Mar 2012 14:20:59 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 221AD21F8770 for ; Wed, 21 Mar 2012 14:20:57 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-e2-4f6a46385837
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 7A.B3.17856.8364A6F4; Wed, 21 Mar 2012 22:20:57 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Wed, 21 Mar 2012 22:20:56 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 9ED562321	for ; Wed, 21 Mar 2012 23:20:56 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 98DFB523FD	for ; Wed, 21 Mar 2012 23:20:56 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 51FD451D16	for ; Wed, 21 Mar 2012 23:20:56 +0200 (EET)
Message-ID: <4F6A4637.5000407@ericsson.com>
Date: Wed, 21 Mar 2012 23:20:55 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: sipcore@ietf.org
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 21 Mar 2012 21:21:00 -0000

I think all the confusion in this discussion come from the fact that we 
do not use the right terminology

in the WebSocket scenario, connection re-usage for new incoming request 
is not a possibility/improvements
it is the only way for a WebSocket Server to contact a WS-Client

that because a WebSocket client is only a client (i.e. it can not behave 
also as a server listening on a specific port)

and btw a WebSocket Client can only communicate with a 
WebServer/WebSocketServer




On 3/21/12 4:05 PM, Iñaki Baz Castillo wrote:
> 2012/3/21 Christer Holmberg:
>> But, if we mandate SIP registrations, and allow connection re-use as default (assuming the client has registered), does Outbound bring anything extra from a security perspective?
> I would like to give a different perspective (not so related to
> security) to this topic. Let's suppose:
>
> - A SIP TCP client behind NAT.
> - A SIP WebSocket client (behind NAT or not).
>
> Both are "endpoints" / "end users", not a proxy, server or b2bua.
>
> In both cases, these clients cannot receive incoming connections from
> the proxy/registrar. Therefore they open a connection with the
> proxy/registrar and, in some way, incoming requests need to be routed
> over that connection. So:
>
> 1) The solution for the SIP TCP case is to implement Outbound.
> 2) Outbound also solves the SIP WebSocket case.
>
> Then, why should we define a new and different solution for the SIP
> WebSocket case?
> And, if we define such a new solution, why not to extend it also to
> TCP transport (with no TLS)?
>
> Regards.
>
>


From ibc@aliax.net  Wed Mar 21 14:32:38 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2583F21F851D for ; Wed, 21 Mar 2012 14:32:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.614
X-Spam-Level: 
X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=0.063,  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 eYDbpX9z+p19 for ; Wed, 21 Mar 2012 14:32:37 -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 7037421F8514 for ; Wed, 21 Mar 2012 14:32:37 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so1744268vcb.31 for ; Wed, 21 Mar 2012 14:32:36 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=foOusBfGBp7PfhAeBT4SzGEYRxZyahTaNRvDxEMV68o=; b=lZrtrbAnGmFpMm4/M5YFP0gipcVFpjGscs/Z225AmfKJpP6FQgZpyZ394m2sP08K/v 2lgFHSJnVN08lHG41qRhqQO3mGKgLJYRq+YiPMAafBAYAPKHMfm46356OWkcZxOfGj7J +4DQnEdO/bZ5vNmKIWZQ3IhFpvoJ7du/d67GwvSrxiaSWaRigjoZjSb9zIphgfcALO8W ZVr50/XyuIctSc7ar+yj6O4Z+9YYm9oI+4jXlZTRTkMpzhm/ynAkRgLbLrjMbMuIx9Hz if8mGGM2i7GV97ZuxuT/zYlAoyCrn+S1w2bNTxC9JkjFCT/K5ZqplX1br/YHpWb8Sucg y+rg==
Received: by 10.52.65.239 with SMTP id a15mr2454098vdt.51.1332365555985; Wed, 21 Mar 2012 14:32:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Wed, 21 Mar 2012 14:32:14 -0700 (PDT)
In-Reply-To: <4F6A4637.5000407@ericsson.com>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Wed, 21 Mar 2012 22:32:14 +0100
Message-ID: 
To: Salvatore Loreto 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkLWxzKzuPncXpfGKapnx9ODZRD+HX8GkIOs5CsyA15TcNn7cmBwI8FYowZZNT4Sy/d0s01
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 21 Mar 2012 21:32:38 -0000

2012/3/21 Salvatore Loreto :
> I think all the confusion in this discussion come from the fact that we d=
o
> not use the right terminology
>
> in the WebSocket scenario, connection re-usage for new incoming request i=
s
> not a possibility/improvements
> it is the only way for a WebSocket Server to contact a WS-Client
>
> that because a WebSocket client is only a client (i.e. it can not behave
> also as a server listening on a specific port)
>
> and btw a WebSocket Client can only communicate with a
> WebServer/WebSocketServer

Hi Salvatore.

What you say indeed makes sense given the current WebSocket
implementations (clients and servers), but IMHO we cannot define a new
SIP transport assuming that there will never be a SIP entity capable
of listening for WS incoming connections and also opening outgoing WS
connections.

Please check the second section in this mail that I sent previously,
in which I talk about that hypothetical case:

  http://www.ietf.org/mail-archive/web/sipcore/current/msg04629.html

Probably nobody will implement that but, IMHO, from the point of view
of the transport specification it must considered.


Regards.

--=20
I=C3=B1aki Baz Castillo


From adam@nostrum.com  Wed Mar 21 14:48:09 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA5C21E8098 for ; Wed, 21 Mar 2012 14:48:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.525
X-Spam-Level: 
X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.075, 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 v91EJ0ieysnB for ; Wed, 21 Mar 2012 14:48:09 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id D245321E80EA for ; Wed, 21 Mar 2012 14:48:08 -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 q2LLm3I4098383 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 21 Mar 2012 16:48:04 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4F6A4C93.2080504@nostrum.com>
Date: Wed, 21 Mar 2012 16:48:03 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Christer Holmberg 
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
Cc: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , SIPCORE 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 21 Mar 2012 21:48:09 -0000

[as an individual]

On 3/21/12 8:51 AM, Christer Holmberg wrote:
> But, if we mandate SIP registrations, and allow connection re-use as default...

It's nonsense to think that web browsers will have a client cert to 
present. Connection re-use is a non-starter.

If you want something that looks like connection re-use, but with 
authentication appropriate for clients, we've done that. It's called 
Outbound.

/a

From christer.holmberg@ericsson.com  Thu Mar 22 01:02:11 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBEA21F862A for ; Thu, 22 Mar 2012 01:02:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.293
X-Spam-Level: 
X-Spam-Status: No, score=-10.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JC4KszW3OLRR for ; Thu, 22 Mar 2012 01:02: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 795EB21F8629 for ; Thu, 22 Mar 2012 01:02:10 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-81-4f6adc81b24e
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 69.65.27041.18CDA6F4; Thu, 22 Mar 2012 09:02:09 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 22 Mar 2012 09:02:09 +0100
From: Christer Holmberg 
To: 'Adam Roach' 
Date: Thu, 22 Mar 2012 09:02:08 +0100
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
Thread-Index: Ac0HrE3CHWD9uzVZQpKYztXaT4LbIwAVT+8g
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C41326392@ESESSCMS0356.eemea.ericsson.se>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se> <4F6A4C93.2080504@nostrum.com>
In-Reply-To: <4F6A4C93.2080504@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , SIPCORE 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 08:02:11 -0000

Hi,=20

>> But, if we mandate SIP registrations, and allow connection re-use as def=
ault...
>
> It's nonsense to think that web browsers will have a client cert to prese=
nt. Connection re-use is a non-starter.

I agree. I am not talking about RFC 5923.

> If you want something that looks like connection re-use, but with authent=
ication appropriate for clients, we've done that. It's called Outbound.

My suggestion is that, if the registration succeeds (no matter whether Outb=
ound is used or not), it would be allowed to re-use the SIP WS connection a=
ssociated with the registration.

>From an authentication perspective, what does Outbound provide that a norma=
l registration doesn't?

And, if the registrar doesn't support Outbound, will connection re-use betw=
een the client and edge proxy still be allowed?


Regards,

Christer

From christer.holmberg@ericsson.com  Thu Mar 22 01:06:35 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A40C21F858E for ; Thu, 22 Mar 2012 01:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.297
X-Spam-Level: 
X-Spam-Status: No, score=-10.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPEstHzO3leE for ; Thu, 22 Mar 2012 01:06:34 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5A421F860B for ; Thu, 22 Mar 2012 01:06:33 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-e4-4f6add893330
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 14.66.27041.98DDA6F4; Thu, 22 Mar 2012 09:06:33 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 22 Mar 2012 09:06:33 +0100
From: Christer Holmberg 
To: 'Paul Kyzivat' 
Date: Thu, 22 Mar 2012 09:06:31 +0100
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
Thread-Index: Ac0HpfASuPbUUCemROiHn9bApcNh2gAXEIaw
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C41326393@ESESSCMS0356.eemea.ericsson.se>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se> <4F69D8B2.7080805@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414574F7@ESESSCMS0356.eemea.ericsson.se> <4F6A41EB.4020001@alum.mit.edu>
In-Reply-To: <4F6A41EB.4020001@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 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 08:06:35 -0000

Hi,=20

>>> The problem isn't at the client end. The problem is whether the server =
is willing to use the WS connection - that it is a suitable alias.
>>
>> True. But, assuming it would be allowed to re-use a *registered* WS conn=
ection by default, does outbound bring anything extra as far as the connect=
ion verification is concerned?
>>
>> Because, I assume we would still allow the edge proxy to re-use the WS c=
onnection even if the registrar does NOT support Outbound - as long as the =
registration as such succeeds. Or?
>
> I don't want to misrepresent things here. I *think* there were more subtl=
eties to it than that. I sent a query to Cullen, Vijay, and Brett, who are =
authors on=20
> outbound and connect-reuse, in hopes that one of them can dredge up more =
of those subtleties.

Good :)

Again, I have nothing against Outbound, and if we figure out it's needed I =
have no issues with that.

Regards,

Christer


From brett@broadsoft.com  Thu Mar 22 04:28:00 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFFD221F867D for ; Thu, 22 Mar 2012 04:27:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RK8UE9gwLir for ; Thu, 22 Mar 2012 04:27:59 -0700 (PDT)
Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.201]) by ietfa.amsl.com (Postfix) with ESMTP id 3D61D21F8675 for ; Thu, 22 Mar 2012 04:27:58 -0700 (PDT)
Received: from casumhub01.citservers.local (172.16.98.57) by FW01.citservers.local (172.16.98.3) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 22 Mar 2012 04:29:27 -0700
Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Thu, 22 Mar 2012 04:29:24 -0700
From: Brett Tate 
To: Paul Kyzivat , SIPCORE 
Date: Thu, 22 Mar 2012 04:27:47 -0700
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
Thread-Index: Ac0HpjFajY05OzonSoiVwhUFHxI8XwAdSg5Q
Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C1DF8AB62@EXMBXCLUS01.citservers.local>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se> <4F69D8B2.7080805@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414574F7@ESESSCMS0356.eemea.ericsson.se> <4F6A41EB.4020001@alum.mit.edu>
In-Reply-To: <4F6A41EB.4020001@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 11:28:00 -0000

Unfortunately I have not followed the thread or read the websocket draft cl=
ose enough to comment upon the potential applicability for websocket.  Howe=
ver, the following RFC 5923 applicability statement snippet highlights a ma=
in distinction between RFC 5923 and RFC 5626; reuse assumes that either end=
 can initiate the connection.  Similarly because of the certificate require=
ments, the RFC 5923 section 9 security considerations may also be relevant.


3.  Applicability Statement

   The applicability of the mechanism described in this document is for
   two adjacent SIP entities to reuse connections when they are agnostic
   about the direction of the connection, i.e., either end can initiate
   the connection.  SIP entities that can only open a connection in a
   specific direction -- perhaps because of Network Address Translation
   (NAT) and firewalls -- reuse their connections using the mechanism
   described in the outbound document [RFC5626].

> -----Original Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
> Behalf Of Paul Kyzivat
> Sent: Wednesday, March 21, 2012 5:03 PM
> To: Christer Holmberg
> Cc: SIPCORE
> Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-
> websocket (Outbound and more)
>=20
> On 3/21/12 9:47 AM, Christer Holmberg wrote:
>=20
> >> The problem isn't at the client end. The problem is whether the
> server is willing to use the WS connection - that it is a suitable
> alias.
> >
> > True. But, assuming it would be allowed to re-use a *registered* WS
> connection by default, does outbound bring anything extra as far as the
> connection verification is concerned?
> >
> > Because, I assume we would still allow the edge proxy to re-use the
> WS connection even if the registrar does NOT support Outbound - as long
> as the registration as such succeeds. Or?
>=20
> I don't want to misrepresent things here. I *think* there were more
> subtleties to it than that. I sent a query to Cullen, Vijay, and Brett,
> who are authors on outbound and connect-reuse, in hopes that one of
> them
> can dredge up more of those subtleties.
>=20
> 	Thanks,
> 	Paul
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore

From ibc@aliax.net  Thu Mar 22 04:52:41 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F57821F86E4 for ; Thu, 22 Mar 2012 04:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.615
X-Spam-Level: 
X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=0.062,  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 g3n8TAp0l2vf for ; Thu, 22 Mar 2012 04:52:40 -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 0B1CB21F86DC for ; Thu, 22 Mar 2012 04:52:39 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so2298615vcb.31 for ; Thu, 22 Mar 2012 04:52:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=/CYX2Z+2O8lBHRQOahrie1loZpkTNgADHROm97FJX0o=; b=bHXOqktR9i+u8/s70ZJPASTt3fKiMfXgUfBMRV8a/i7Aw1Ysjpn7am0WwoAH0hIaW9 hrVYVxui79oEM3770xyr+aSW3r1yAeRFXaZsqytxK/8N7m12o077F4Vt6qrfdpq5SFRw DulwfXj+rHLErbtDtK4S71ioMf7BlmrfVHZYbyMWnlBA5doOH/mfRFIqmDRrA+QZuYaO SejM0L0391+C/uQIuzs2Y30XSA8QUxaqIAUwB80GKlwiy+1C85eSMbEhR4YihCaCfzTL shAyZb5LCg9I5FXt+PsndXKV/LLaID/RE/wjmyScJKAwPj/nNajiJV1i6f07sTtH3cVi 9RFw==
Received: by 10.52.24.49 with SMTP id r17mr774486vdf.51.1332417159564; Thu, 22 Mar 2012 04:52:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Thu, 22 Mar 2012 04:52:19 -0700 (PDT)
In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C1DF8AB62@EXMBXCLUS01.citservers.local>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se> <4F69D8B2.7080805@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414574F7@ESESSCMS0356.eemea.ericsson.se> <4F6A41EB.4020001@alum.mit.edu> <7FF1E5E16911C54BB2D57D4C4A2ED35A0C1DF8AB62@EXMBXCLUS01.citservers.local>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 22 Mar 2012 12:52:19 +0100
Message-ID: 
To: Brett Tate 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkoSjgZ/uOFL9yKFfAB/sF7U52QlkhFvKjfIxAmM7jN27mdqHIcFBqjdNMCHDYZA3p6IrHB
Cc: SIPCORE 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 11:52:41 -0000

2012/3/22 Brett Tate :
> Unfortunately I have not followed the thread or read the websocket draft =
close enough to comment upon the potential applicability for websocket. =C2=
=A0However, the following RFC 5923 applicability statement snippet highligh=
ts a main distinction between RFC 5923 and RFC 5626; reuse assumes that eit=
her end can initiate the connection. =C2=A0Similarly because of the certifi=
cate requirements, the RFC 5923 section 9 security considerations may also =
be relevant.
>
>
> 3. =C2=A0Applicability Statement
>
> =C2=A0 The applicability of the mechanism described in this document is f=
or
> =C2=A0 two adjacent SIP entities to reuse connections when they are agnos=
tic
> =C2=A0 about the direction of the connection, i.e., either end can initia=
te
> =C2=A0 the connection. =C2=A0SIP entities that can only open a connection=
 in a
> =C2=A0 specific direction -- perhaps because of Network Address Translati=
on
> =C2=A0 (NAT) and firewalls -- reuse their connections using the mechanism
> =C2=A0 described in the outbound document [RFC5626].


Thanks Brett. IMHO it's clear that the SIP webSocket most extended
case will be that in which clients connect from a web browser or some
client application whose WebSocket stack can only initiate outgoing
connections. This is not a proxy-to-proxy topology in which Connection
Reuse is useful for saving time and resources when TLS is used. So
IMHO RFC 5626 (Outbound) is the proper solution here.

Regards.

--=20
I=C3=B1aki Baz Castillo


From salvatore.loreto@ericsson.com  Thu Mar 22 05:01:38 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48C121F8565 for ; Thu, 22 Mar 2012 05:01:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.902
X-Spam-Level: 
X-Spam-Status: No, score=-109.902 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYYU5-V+tNqW for ; Thu, 22 Mar 2012 05:01:38 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 022A821F8539 for ; Thu, 22 Mar 2012 05:01:37 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-0d-4f6b14a0aa8c
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 1E.F2.17856.0A41B6F4; Thu, 22 Mar 2012 13:01:36 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Thu, 22 Mar 2012 13:01:36 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id C66852321; Thu, 22 Mar 2012 14:01:35 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D1AEA52414; Thu, 22 Mar 2012 14:01:35 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 62E4D523EE; Thu, 22 Mar 2012 14:01:35 +0200 (EET)
Message-ID: <4F6B149E.60403@ericsson.com>
Date: Thu, 22 Mar 2012 13:01:34 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= 
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Cc: "sipcore@ietf.org" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 12:01:39 -0000

On 3/21/12 10:32 PM, Iñaki Baz Castillo wrote:
> 2012/3/21 Salvatore Loreto:
>> I think all the confusion in this discussion come from the fact that we do
>> not use the right terminology
>>
>> in the WebSocket scenario, connection re-usage for new incoming request is
>> not a possibility/improvements
>> it is the only way for a WebSocket Server to contact a WS-Client
>>
>> that because a WebSocket client is only a client (i.e. it can not behave
>> also as a server listening on a specific port)
>>
>> and btw a WebSocket Client can only communicate with a
>> WebServer/WebSocketServer
> Hi Salvatore.
>
> What you say indeed makes sense given the current WebSocket
> implementations (clients and servers), but IMHO we cannot define a new
> SIP transport assuming that there will never be a SIP entity capable
> of listening for WS incoming connections and also opening outgoing WS
> connections.
here where I get lost...
WebSocket is not a Transport Protocol even if some people claim it can
be seen as a transport layer.
I think the draft should define the usage of SIP on top o WebSocket
or to be more precise it should define SIP as a WebSocket Subprotocols.

To be clear,
I think that some re-usage of things already standardized (e.g. some part of
Outbound) make a lot of sense... while defining SIP as WebSocket 
Subprotocols,
but we need to have clear in mind which is the scenario and the limitation

>
> Please check the second section in this mail that I sent previously,
> in which I talk about that hypothetical case:
that are hypothetical and  contradict architectural assumptions and 
standards :-)

Salvatore

>
>    http://www.ietf.org/mail-archive/web/sipcore/current/msg04629.html
>
> Probably nobody will implement that but, IMHO, from the point of view
> of the transport specification it must considered.
>
>
> Regards.
>



From ibc@aliax.net  Thu Mar 22 05:35:14 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F216321F86F7 for ; Thu, 22 Mar 2012 05:35:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.616
X-Spam-Level: 
X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=0.061,  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 RXyt8S2a7khn for ; Thu, 22 Mar 2012 05:35:13 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F01021F86F3 for ; Thu, 22 Mar 2012 05:35:12 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so2332980vcb.31 for ; Thu, 22 Mar 2012 05:35:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=AdGel+tKV9MT5gKMMIwfAMbDL3RoYMnKZfCcCX1umhg=; b=AHBUli2MNzezexvsG+MCggVMXBIPGNDFTwlRGrWz9rFeENFFLl/PtXIw+zFxJQjqsX LMDJKXdnjlk+OX5UL6H1M2f4ZaixRID0wSskPbYSfe1OJcV+6hhz+hKsM190KkgD+FQ1 IezjKDpEmOVzGLdLdQvqWLP3hyru2oKjm56R4YSo+SbdgOPe7bKhHMsFwIJGuoOilMOX i2VGpu8s11UZ5yJh2OA2u7lzOv1SBEf+mdBuILHMc6Zzctx6GXbaFCBXVQd1NboDLyx+ 3YBSntGkNi/VpgSwhpGTcV/KfLOX2TOlKv+szHmgttzzb6ytozmLUZuLJPBAZuydmgf4 Zzcw==
Received: by 10.52.90.111 with SMTP id bv15mr3478511vdb.34.1332419712487; Thu, 22 Mar 2012 05:35:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Thu, 22 Mar 2012 05:34:52 -0700 (PDT)
In-Reply-To: <4F6B149E.60403@ericsson.com>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 22 Mar 2012 13:34:52 +0100
Message-ID: 
To: Salvatore Loreto 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkzbjuIrAUXht7B1Q1VbbP+aX2R3MTodknrgLavjpymUEJL+7bpG4kHTF2gv9QVXmYsr68k
Cc: "sipcore@ietf.org" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 12:35:14 -0000

2012/3/22 Salvatore Loreto :
>> Please check the second section in this mail that I sent previously,
>> in which I talk about that hypothetical case:
>
> that are hypothetical and =C2=A0contradict architectural assumptions and
> standards :-)

Hi Salvatore. I know it's a very hypothetical case but, why should we
not consider the scenario in which a SIP proxy P1 opens a WebSocket
connection to SIP proxy P2, and P2 also opens a WebSocket connection
to P1?

Note however that our first approach (current 01 draft) assumes what
you say: a WS client can only open outgoing connections and a WS
server can only listen for incoming connections. In that case Outbound
(for end users) or Connection Reuse (for proxy-proxy) is required.

But we were encouraged to consider the hypothetical case in which a
SIP entity is capable of initiating and accepting WS connections
(which technically is feasible and does not break any protocol or
specification IMHO).

So I would like to ask to the SIPCORE WG: should the draft consider
that hypothetical case? or shoult it assume that there could exist SIP
entities capable of initiating and receiving WS connections?

Regards.

--=20
I=C3=B1aki Baz Castillo


From christer.holmberg@ericsson.com  Thu Mar 22 05:49:41 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8AC21F86FA for ; Thu, 22 Mar 2012 05:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.15
X-Spam-Level: 
X-Spam-Status: No, score=-10.15 tagged_above=-999 required=5 tests=[AWL=0.149,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pt-7uYm3RIAP for ; Thu, 22 Mar 2012 05:49:40 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 93E6A21F86F3 for ; Thu, 22 Mar 2012 05:49:40 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-64-4f6b1fe315e5
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 35.E7.27041.3EF1B6F4; Thu, 22 Mar 2012 13:49:39 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Thu, 22 Mar 2012 13:49:39 +0100
From: Christer Holmberg 
To: =?iso-8859-1?Q?=27I=F1aki_Baz_Castillo=27?= , Salvatore Loreto 
Date: Thu, 22 Mar 2012 13:49:38 +0100
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
Thread-Index: Ac0IKDy9exj7VJvNQHmUVQilFqRLTgAAUk6g
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C413263A3@ESESSCMS0356.eemea.ericsson.se>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "sipcore@ietf.org" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 12:49:41 -0000

Hi,=20

>>> Please check the second section in this mail that I sent previously,=20
>>> in which I talk about that hypothetical case:
>>
>> that are hypothetical and =A0contradict architectural assumptions and=20
>> standards :-)
>
> Hi Salvatore. I know it's a very hypothetical case but, why should we not=
 consider the scenario in which a SIP proxy P1 opens a WebSocket connection=
 to SIP proxy P2, and P2 also opens a WebSocket connection to P1?

I don't really see such use-case.

And, *if* we would mandate Outbound and/or GRUU, I am not sure it would eve=
n work, as proxies don't register.

> Note however that our first approach (current 01 draft) assumes what you =
say: a WS client can only open outgoing connections and a WS server can onl=
y listen for incoming connections. In that case Outbound (for end users) or=
=20
> Connection Reuse (for proxy-proxy) is required.
>
> But we were encouraged to consider the hypothetical case in which a SIP e=
ntity is capable of initiating and accepting WS connections (which technica=
lly is feasible and does not break any protocol or specification IMHO).
>
> So I would like to ask to the SIPCORE WG: should the draft consider that =
hypothetical case? or shoult it assume that there could exist SIP entities =
capable of initiating and receiving WS connections?

My vote would be that we don't consider that.=20

And, IF someone wants to do it, I don't think there is anything preventing =
them from doing so. It could simply be seen as two separate client-to-serve=
r connections, and I don't think we need to write anything about it.

Regards,

Christer


From christer.holmberg@ericsson.com  Thu Mar 22 05:52:05 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0565821F8682 for ; Thu, 22 Mar 2012 05:52:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.151
X-Spam-Level: 
X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jhylvm2KbDux for ; Thu, 22 Mar 2012 05:52:04 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 44F2621F8671 for ; Thu, 22 Mar 2012 05:52:04 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-f9-4f6b20738e8d
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id DE.EC.17856.3702B6F4; Thu, 22 Mar 2012 13:52:03 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 22 Mar 2012 13:52:02 +0100
From: Christer Holmberg 
To: Christer Holmberg , =?iso-8859-1?Q?=27I=F1aki_Baz_Castillo=27?= , Salvatore Loreto 
Date: Thu, 22 Mar 2012 13:52:02 +0100
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
Thread-Index: Ac0IKDy9exj7VJvNQHmUVQilFqRLTgAAUk6gAAAxd9A=
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C413263A4@ESESSCMS0356.eemea.ericsson.se>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com>  <7F2072F1E0DE894DA4B517B93C6A05852C413263A3@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C413263A3@ESESSCMS0356.eemea.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "sipcore@ietf.org" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 12:52:05 -0000

Hi,=20

>>>> Please check the second section in this mail that I sent previously,=20
>>>> in which I talk about that hypothetical case:
>>>
>>> that are hypothetical and =A0contradict architectural assumptions and=20
>>> standards :-)
>>
>> Hi Salvatore. I know it's a very hypothetical case but, why should we no=
t consider the scenario in which a SIP proxy P1 opens a WebSocket connectio=
n to SIP proxy P2, and P2 also opens a WebSocket connection to P1?
>
> I don't really see such use-case.
>
> And, *if* we would mandate Outbound and/or GRUU, I am not sure it would e=
ven work, as proxies don't register.

Correction: in this case connection re-use would of course not be used.

Regards,

Christer


From pkyzivat@alum.mit.edu  Thu Mar 22 06:44:41 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEDA721F867C for ; Thu, 22 Mar 2012 06:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level: 
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039,  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 h1BF-IWbcrzD for ; Thu, 22 Mar 2012 06:44:41 -0700 (PDT)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [76.96.59.211]) by ietfa.amsl.com (Postfix) with ESMTP id 2921E21F862A for ; Thu, 22 Mar 2012 06:44:40 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by QMTA11.westchester.pa.mail.comcast.net with comcast id odUm1i0050vyq2s5Bdkhuk; Thu, 22 Mar 2012 13:44:41 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta05.westchester.pa.mail.comcast.net with comcast id odkh1i00e07duvL3Rdkhlg; Thu, 22 Mar 2012 13:44:41 +0000
Message-ID: <4F6B2CC7.1040506@alum.mit.edu>
Date: Thu, 22 Mar 2012 09:44:39 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: sipcore@ietf.org
References:   <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 13:44:41 -0000

On 3/22/12 8:34 AM, Iñaki Baz Castillo wrote:
> 2012/3/22 Salvatore Loreto:
>>> Please check the second section in this mail that I sent previously,
>>> in which I talk about that hypothetical case:
>>
>> that are hypothetical and  contradict architectural assumptions and
>> standards :-)
>
> Hi Salvatore. I know it's a very hypothetical case but, why should we
> not consider the scenario in which a SIP proxy P1 opens a WebSocket
> connection to SIP proxy P2, and P2 also opens a WebSocket connection
> to P1?
>
> Note however that our first approach (current 01 draft) assumes what
> you say: a WS client can only open outgoing connections and a WS
> server can only listen for incoming connections. In that case Outbound
> (for end users) or Connection Reuse (for proxy-proxy) is required.
>
> But we were encouraged to consider the hypothetical case in which a
> SIP entity is capable of initiating and accepting WS connections
> (which technically is feasible and does not break any protocol or
> specification IMHO).
>
> So I would like to ask to the SIPCORE WG: should the draft consider
> that hypothetical case? or shoult it assume that there could exist SIP
> entities capable of initiating and receiving WS connections?

I'm generally a believer in generality and completeness, which inclines 
me to support considering this.

BUT, before going far down that track I would like to have a good 
understanding of what that means, the implications and limitations, etc. 
And whether there is enough interest in pursuing it.

I guess you what you are thinking for this case is that in this new case 
connection-reuse would be used instead of outbound? That would imply:
- the originating and *knows* it should follow the connection reuse
   strategy rather than the outbound strategy. Specifically, it
   doesn't register.

- the originating end has a client certificate

	Thanks,
	Paul

From ibc@aliax.net  Thu Mar 22 07:21:54 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B668C21F860B for ; Thu, 22 Mar 2012 07:21:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.617
X-Spam-Level: 
X-Spam-Status: No, score=-2.617 tagged_above=-999 required=5 tests=[AWL=0.060,  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 DeJEUhirqIVt for ; Thu, 22 Mar 2012 07:21:53 -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 9422D21F8602 for ; Thu, 22 Mar 2012 07:21:53 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so2454407vcb.31 for ; Thu, 22 Mar 2012 07:21:53 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=dfOe3iC3OIQvm/GeKpoAuKIkTEMud0wjdHspLDqME7U=; b=iQscXbOnM4RJ1mZ2SY4ca0eCLwO0BD21FRH60H8T99hNylNUAyOFAMMXV9jmNtTsOK uuqBCit+/IFVorIls9Vw9cOuUAvhJy0DyBnA4vP1hEOHh2DC6r6EBwyR7GgQMbF+CQqv D/WVgarH2JEPDmhEJ2agyeWMKjSiYebgkZMdO36jZNfNulY5fu096WLN9W18VsdIwa8l z5g5AXcofei+X2MsnDcQx7nWmsYF05e0z7E7NXk/0ogfWI2en/RzmgljZOjk935Eupbh cQuGxZU1pdIVWrABH71OQWMe1D+yOWsqjK2pziSSeDx51eO4SBuWMKAkpxIcP8NmTRKr yTEw==
Received: by 10.52.27.1 with SMTP id p1mr3695949vdg.17.1332426112916; Thu, 22 Mar 2012 07:21:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Thu, 22 Mar 2012 07:21:32 -0700 (PDT)
In-Reply-To: <4F6B2CC7.1040506@alum.mit.edu>
References:   <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com>  <4F6B2CC7.1040506@alum.mit.edu>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 22 Mar 2012 15:21:32 +0100
Message-ID: 
To: Paul Kyzivat 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlzkXVPjELGEuqB8yPDmuzcz7ZUlmPg9E5IMk5k24h3Ra+mZ7PczyIZGSN4xAriSYZZu6ZN
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 14:21:54 -0000

2012/3/22 Paul Kyzivat :
>> So I would like to ask to the SIPCORE WG: should the draft consider
>> that hypothetical case? or shoult it assume that there could exist SIP
>> entities capable of initiating and receiving WS connections?
>
>
> I'm generally a believer in generality and completeness, which inclines m=
e
> to support considering this.
>
> BUT, before going far down that track I would like to have a good
> understanding of what that means, the implications and limitations, etc. =
And
> whether there is enough interest in pursuing it.
>
> I guess you what you are thinking for this case is that in this new case
> connection-reuse would be used instead of outbound? That would imply:
> - the originating and *knows* it should follow the connection reuse
> =C2=A0strategy rather than the outbound strategy. Specifically, it
> =C2=A0doesn't register.
>
> - the originating end has a client certificate

Hi Paul,

In the example P1-P2 I meant that there is no need for connection
reuse if P1 can, not just initiate an outgoing WS connection to P2,
but also listen for an incoming WS connection from P2 (for incoming
requests).

IMHO all the cases are covered in a mail I sent yesterday, let me
paste it here please:



SIP WS entities that can only initiate outgoing connections:
---------------------------------------------------------------------------=
------------------------

These can be SIP UA's (i.e. JavaScript apps running in a web browser,
smartphone apps) or SIP proxies/servers.

In the case of SIP UA's, implementing Outbound is the easiest and most
complete solution (connection reusing for incoming requests,
keepalive, registration failover, valid for WS and WSS over TLS).
Implementing GRUU would also be valuable and required for receiving an
INVITE generated upon a REFER containing the Contact URI of a SIP WS
UA in the "Refer-To" header (see the previous Alice/Bob/Carol REFER
example in a previous mail).

In case of SIP proxies/servers, Outbound is not an option and those
SIP entities should implement RFC 5923 "Connection Reuse" and,
optionally, RFC 6233 "Indication of Support for Keep-Alive"). Note
however that RFC 5923 requires secure connections (so just WSS =3D WS
over TLS) and a certificate presented by the connection initiator.



SIP WS entities that can initiate outgoing connections and also listen
for incoming connections:
---------------------------------------------------------------------------=
------------------------

These can be SIP proxies/servers o custom SIP UA's (with an own
WebSocket stack that behaves as client and server).

These entities could not require to reuse the initial connection for
incoming requests (for example in a proxy-proxy communication in the
public Internet or same network). They could implement RFC 6233 or
could prefer to make usage of WebSocket Ping/Pong Keep-Alive mechanism
in case they need it (or any future WS keepalive mechanism to be defined).

Those SIP entities don't need changes to RFC 3261 neither implementing
other RFC's for connection reusing. The don't need reusing the connection.




--=20
I=C3=B1aki Baz Castillo


From ibc@aliax.net  Thu Mar 22 07:47:58 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5E521F852D for ; Thu, 22 Mar 2012 07:47:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.618
X-Spam-Level: 
X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=0.059,  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 Qha3Qyb3OSLQ for ; Thu, 22 Mar 2012 07:47:58 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id EB19421F852E for ; Thu, 22 Mar 2012 07:47:57 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so1197578vbb.31 for ; Thu, 22 Mar 2012 07:47:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=n1Au7wriiiqJTzA9ptSAeaX+vzqFKIZXtSa3Q+M5iNE=; b=fi8pLipQbddE1nce5rg5yLbeSEqIf1RFp15a/+Lz+DHtRBathPBiKEOESQPUObr6D0 s/IHmMbZsOMfga0VMomqsNNBHmTEKj43IEyZmt9nD8zjqMT9l1NLNEM53sL4hXU1BKs1 zNBN9/ciUks5dghWHFvVnYi5x548WQ1eALHG6wTgQw3k3kV/+1/jzHR2yzduxZDgrS4o +/N5rx/sm0krA4mdVJXMBBbqTL81pb3VLFutMKzIRa5urRyeAYNdZcJMvs9jWVLqhXmk HyAabImto4+9xWSU27xLntBLTV4sUk9HRWL6eS3bunOAdbStuqjBgQYUdcnI6K3eAH5b RP2g==
Received: by 10.52.90.111 with SMTP id bv15mr3652283vdb.34.1332427677408; Thu, 22 Mar 2012 07:47:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Thu, 22 Mar 2012 07:47:37 -0700 (PDT)
In-Reply-To: <4F6B149E.60403@ericsson.com>
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 22 Mar 2012 15:47:37 +0100
Message-ID: 
To: Salvatore Loreto 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQk2h3WpqXlFa/DoydxciRT9Pv19I9tzfOCandczCCC28dAOmQDmcoJm91l3BbnBaMOZAmsm
Cc: "sipcore@ietf.org" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 14:47:58 -0000

2012/3/22 Salvatore Loreto :
> here where I get lost...
> WebSocket is not a Transport Protocol even if some people claim it can
> be seen as a transport layer.
> I think the draft should define the usage of SIP on top o WebSocket
> or to be more precise it should define SIP as a WebSocket Subprotocols.

Hi Salvatore.

>From the point of view of the SIP stack, the draft defines a complete
SIP transport as any of the existing ones (UDP, TCP, SCTP...). This
new SIP transport (rather than a transport protocol) involves, indeed,
an extra layer which is a WebSocket connection and a WS SubProtocol
(sip), so WS handshake is required as in any WebSocket usage.

But from the point of view of a SIP stack, the WebSocket SIP
SubProtocol (as defined in the draft) becomes another SIP transport.
IMHO there are no differences.

Also note that SIP protocol does not define "clients" and "servers",
so the fact that WebSocket talks about clients and servers should not
affect to the application layer on top of it (SIP in this case). Being
strict, a SIP entity could include a WS client and a WS server within
its network stack, and that would be perfectly valid from the point of
view of the SIP protocol.


Best regards.



--=20
I=C3=B1aki Baz Castillo


From kpfleming@digium.com  Thu Mar 22 08:02:00 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5C421F860B for ; Thu, 22 Mar 2012 08:02:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.561
X-Spam-Level: 
X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 R-TbqrKL8x5K for ; Thu, 22 Mar 2012 08:01:59 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4018821F8546 for ; Thu, 22 Mar 2012 08:01:59 -0700 (PDT)
Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SAjWY-0006Ai-4E for sipcore@ietf.org; Thu, 22 Mar 2012 10:01:58 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 1D8C2D8014 for ; Thu, 22 Mar 2012 10:01:58 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-wSQ++H5gC9 for ; Thu, 22 Mar 2012 10:01:57 -0500 (CDT)
Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 6AAFBD8011 for ; Thu, 22 Mar 2012 10:01:57 -0500 (CDT)
Message-ID: <4F6B3EE5.8000602@digium.com>
Date: Thu, 22 Mar 2012 10:01:57 -0500
From: "Kevin P. Fleming" 
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: sipcore@ietf.org
References:  <4F68F755.8030001@ericsson.com>
In-Reply-To: <4F68F755.8030001@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 15:02:00 -0000

On 03/20/2012 04:32 PM, Salvatore Loreto wrote:

> 9.1. SIP Proxy Considerations
>
>     When a SIP proxy bridges WebSocket and any other SIP transport
>     (including WebSocket transport) it MUST perform Loose Routing as
>     specified in [RFC3261  ].
>
>
> it is not clear to me how a SIP proxy can bridge a WebSocket request:
> WebSocket connection go on to of an Upgraded HTTP connection
> between the WebSocket client and the WebSocket client...
> this connection can eventually pass through a HTTP Proxy but for sure
> not a SIP proxy

This would actually be fairly trivial to achieve. Imagine an HTTP server 
that proxies requests for a specific URI over to a SIP proxy that 
implements SIP/UDP, SIP/TCP, SIP/TLS and SIP/WebSocket. The SIP proxy 
would then be the server-side endpoint of the WebSocket connection 
(which passes transparently through the HTTP server), and could treat 
incoming SIP requests and responses over that connection the same as it 
would treat them over any other transport. If a SIP INVITE request 
arrived over the WebSocket connection, the proxy would then forward it 
onwards over a suitable transport based on the Request-URI in the 
request itself.

Does that make more sense?

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

From adam@nostrum.com  Thu Mar 22 08:23:38 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD8D821F866E for ; Thu, 22 Mar 2012 08:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.367
X-Spam-Level: 
X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[AWL=0.233, 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 j+vx8-uTwTW5 for ; Thu, 22 Mar 2012 08:23:38 -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 0DA7421F8664 for ; Thu, 22 Mar 2012 08:23:37 -0700 (PDT)
Received: from hydra-en0.roach.at (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q2MFNZ8R073291 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 22 Mar 2012 10:23:36 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4F6B43F7.2080301@nostrum.com>
Date: Thu, 22 Mar 2012 10:23:35 -0500
From: Adam Roach 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Paul Kyzivat 
References:   <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com>  <4F6B2CC7.1040506@alum.mit.! edu>
In-Reply-To: <4F6B2CC7.1040506@alum.mit.edu>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 15:23:38 -0000

[as an individual]

On 3/22/12 08:44, Mar 22, Paul Kyzivat wrote:
> On 3/22/12 8:34 AM, Iñaki Baz Castillo wrote:
>>
>> So I would like to ask to the SIPCORE WG: should the draft consider
>> that hypothetical case? or shoult it assume that there could exist SIP
>> entities capable of initiating and receiving WS connections?
>
> I'm generally a believer in generality and completeness, which 
> inclines me to support considering this.
>
> BUT, before going far down that track I would like to have a good 
> understanding of what that means, the implications and limitations, 
> etc. And whether there is enough interest in pursuing it.

I think what I'd prefer to see is that the current work does nothing to 
preclude the definition of such a set of behaviors in the future, but 
that we don't necessarily spend any work on it right now. It does seem 
highly theoretical (I can't imagine why a proxy-to-proxy link would use 
websockets instead of TCP), and it nearly doubles the complexity of what 
we would need to consider and define. But I do understand the desire for 
(and frequently advocate for) allowing behaviors for unforeseen 
circumstances -- that's where innovation is born.

So, for the current work, I believe it would make sense to define the 
behavior for a WS transport between a UA (one that cannot listen for 
connections) and its first hop into the network. It would probably be 
worth explicitly calling out in the document that we don't currently 
define behavior for inter-intermediary websockets connections or for 
clients with the ability to listen for inbound connections, but that 
future documents may choose to do so.

/a

From ibc@aliax.net  Thu Mar 22 08:26:43 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B69D21F8585 for ; Thu, 22 Mar 2012 08:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level: 
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=0.058,  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 2u25sZg9hE5r for ; Thu, 22 Mar 2012 08:26:42 -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 3CAF121F85EC for ; Thu, 22 Mar 2012 08:26:42 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so2534174vcb.31 for ; Thu, 22 Mar 2012 08:26:41 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=YnCKzB9jtHRXW9wdFJ4/OgNxTukAIa2OcBZoIThrCh4=; b=lXdiTEPIf2zHZcoJrPhkCDdscI9vafTHuc7rPZaVMEgWyr+B5T6IY6zd80yYZs3E4D 8lae+EeNNIKNfMl84jPFd6sIOaw0qNa2wSDA2GPZAOkXMGkO7t1yG6nAQSd8rZEogF/J /NG7jxXsrQf7FK/Vp+cI79kgh/kWMKtb/ufzyLxguD++KJaQNUcBaGO6KmaJ49SuVO// 4hRG+vOCK4IvUaDnbCJrFrzdrwnlDrMIgIXH86QjpA1one2uQ5W61+nOF+62yDsiZ3fH 9JhataCgovh3pc6aGau+F97Mq0tNO7i40SHJxgEYHcj4MuiVBEtIQUQUEFL8f9qdqQWl vVIw==
Received: by 10.52.27.1 with SMTP id p1mr3785920vdg.17.1332430001638; Thu, 22 Mar 2012 08:26:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Thu, 22 Mar 2012 08:26:21 -0700 (PDT)
In-Reply-To: <4F6B3EE5.8000602@digium.com>
References:  <4F68F755.8030001@ericsson.com> <4F6B3EE5.8000602@digium.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 22 Mar 2012 16:26:21 +0100
Message-ID: 
To: "Kevin P. Fleming" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlC4NqbDXgwFRm6xZk6oQa8hCVq02264L3Rr9znFAHQv5tSkpBIwDLifxIsW7Y4GUH32OLa
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 15:26:43 -0000

2012/3/22 Kevin P. Fleming :
> This would actually be fairly trivial to achieve. Imagine an HTTP server
> that proxies requests for a specific URI over to a SIP proxy that impleme=
nts
> SIP/UDP, SIP/TCP, SIP/TLS and SIP/WebSocket. The SIP proxy would then be =
the
> server-side endpoint of the WebSocket connection (which passes transparen=
tly
> through the HTTP server), and could treat incoming SIP requests and
> responses over that connection the same as it would treat them over any
> other transport. If a SIP INVITE request arrived over the WebSocket
> connection, the proxy would then forward it onwards over a suitable
> transport based on the Request-URI in the request itself.
>
> Does that make more sense?

Hi Kevin, I hope it does make sense since we have it implemented,
tested and running :)

  http://sip-on-the-web.aliax.net/
  http://www.youtube.com/watch?v=3DqfFlK1KyF6Q

The SIP proxy in the presentation/video is a pure SIP proxy behaving
as an Outbound Edge proxy. It has a WebSocket server stack in which it
accepts WS connections from WS clients to talk the "SIP WebSocket
SubProtocol" defined in the draft. Any SIP request received from those
connections is treated as a normal SIP request which, in this case,
comes via a SIP WebSocket transport. This is 100% transparent to the
SIP stack of the proxy which routes the SIP request normally depending
on the Route or Request-URI value.

Regards.

--=20
I=C3=B1aki Baz Castillo


From pkyzivat@alum.mit.edu  Thu Mar 22 08:27:34 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6C621F8504 for ; Thu, 22 Mar 2012 08:27:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level: 
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039,  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 OfIc0IzUBy+V for ; Thu, 22 Mar 2012 08:27:34 -0700 (PDT)
Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [76.96.62.96]) by ietfa.amsl.com (Postfix) with ESMTP id C56E421F854B for ; Thu, 22 Mar 2012 08:27:33 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta09.westchester.pa.mail.comcast.net with comcast id ofA31i0030bG4ec59fTaun; Thu, 22 Mar 2012 15:27:34 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta03.westchester.pa.mail.comcast.net with comcast id ofTZ1i02E07duvL3PfTa5C; Thu, 22 Mar 2012 15:27:34 +0000
Message-ID: <4F6B44E3.2080907@alum.mit.edu>
Date: Thu, 22 Mar 2012 11:27:31 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Adam Roach 
References:  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com>  <4F6B2CC7.1040506@alum.mit.! edu> <4F6B43F7.2080301@nostrum.com>
In-Reply-To: <4F6B43F7.2080301@nostrum.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 15:27:34 -0000

WFM

On 3/22/12 11:23 AM, Adam Roach wrote:
> [as an individual]
>
> On 3/22/12 08:44, Mar 22, Paul Kyzivat wrote:
>> On 3/22/12 8:34 AM, Iñaki Baz Castillo wrote:
>>>
>>> So I would like to ask to the SIPCORE WG: should the draft consider
>>> that hypothetical case? or shoult it assume that there could exist SIP
>>> entities capable of initiating and receiving WS connections?
>>
>> I'm generally a believer in generality and completeness, which
>> inclines me to support considering this.
>>
>> BUT, before going far down that track I would like to have a good
>> understanding of what that means, the implications and limitations,
>> etc. And whether there is enough interest in pursuing it.
>
> I think what I'd prefer to see is that the current work does nothing to
> preclude the definition of such a set of behaviors in the future, but
> that we don't necessarily spend any work on it right now. It does seem
> highly theoretical (I can't imagine why a proxy-to-proxy link would use
> websockets instead of TCP), and it nearly doubles the complexity of what
> we would need to consider and define. But I do understand the desire for
> (and frequently advocate for) allowing behaviors for unforeseen
> circumstances -- that's where innovation is born.
>
> So, for the current work, I believe it would make sense to define the
> behavior for a WS transport between a UA (one that cannot listen for
> connections) and its first hop into the network. It would probably be
> worth explicitly calling out in the document that we don't currently
> define behavior for inter-intermediary websockets connections or for
> clients with the ability to listen for inbound connections, but that
> future documents may choose to do so.
>
> /a
>


From ibc@aliax.net  Thu Mar 22 09:15:25 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA61221F8638 for ; Thu, 22 Mar 2012 09:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUViPP2zvQNF for ; Thu, 22 Mar 2012 09:15:25 -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 413F021F85ED for ; Thu, 22 Mar 2012 09:15:25 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so2590048vcb.31 for ; Thu, 22 Mar 2012 09:15:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ZCJzXbDm8WzeOjkzhXEYMwUU/2Upr9CnpuaimIofaw8=; b=UlUDoOUBbyLrOH0PRKZNvUfmZQ9pd5T7BMfeZ3ugiCdIvx/DLKDBQfz043OBqQzpQe dbAXSJoPcrQihSmQPhGgxUw68CTvItU4sSibQyt2OXzxfauKt7GQvxytO+vUXQLYnEBU cAd4fWaEdcvbMhNvFJaQFe0s7nZlTDH/Z7RKpuH8yVfaJvpnqDbYulSjK/j7hN/RSkVr RI7/eu3O5HE90g8iaOYP0+7EdBBh787LlvGCxaBQVKw2TQk6rm3VV93rGI6GRDb0ySux 4+oZ8puxOXn9T+WHUscAo2VKbAHBpU3fqSCgR9ZyQgA+utvtB4p/aMZ9G3cYpj0NzhSj 7qRw==
Received: by 10.220.140.196 with SMTP id j4mr4469517vcu.22.1332432924599; Thu, 22 Mar 2012 09:15:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Thu, 22 Mar 2012 09:15:04 -0700 (PDT)
In-Reply-To: <4F6B43F7.2080301@nostrum.com>
References:   <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com>  <4F6B2CC7.1040506@alum.mit.edu> <4F6B43F7.2080301@nostrum.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 22 Mar 2012 17:15:04 +0100
Message-ID: 
To: Adam Roach 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkZY5QVV+sicDlpBgC0MCvSBbOSLonOw1QSTqdyF9a5V9mYDSsKC0mbLQtNiZsfmbwdIPEA
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 16:15:26 -0000

2012/3/22 Adam Roach :
> I think what I'd prefer to see is that the current work does nothing to
> preclude the definition of such a set of behaviors in the future, but tha=
t
> we don't necessarily spend any work on it right now. It does seem highly
> theoretical (I can't imagine why a proxy-to-proxy link would use websocke=
ts
> instead of TCP), and it nearly doubles the complexity of what we would ne=
ed
> to consider and define. But I do understand the desire for (and frequentl=
y
> advocate for) allowing behaviors for unforeseen circumstances -- that's
> where innovation is born.
>
> So, for the current work, I believe it would make sense to define the
> behavior for a WS transport between a UA (one that cannot listen for
> connections) and its first hop into the network. It would probably be wor=
th
> explicitly calling out in the document that we don't currently define
> behavior for inter-intermediary websockets connections or for clients wit=
h
> the ability to listen for inbound connections, but that future documents =
may
> choose to do so.

Thanks Adam, IMHO your proposal makes lot of sense.

Therefore let me make this proposal for the draft:

The draft could contains two sections:


1) Outbound Clients

To be clear: web browsers and client applications (desktop,
smartphones) running a WS client stack. These are end users so MUST
register.

- Those clients MUST implement Outbound and GRUU.

- The first hop (WS) they connect to MUST also implement Outbound (it
can be a EDGE proxy or a registrar).

- In case there is an Outbound EDGE proxy between the UA and the
registrar, should the registrar implement Outbound? IMHO it does not
need but then it would loose some cool RFC 5626 features, but if the
registrar honors the Path header then incoming requests (initial or
in-dialog) would be properly routed through the Outbound EDGE proxy to
the UA. This is a question non related to SIP WebSocket: Should the
registrar implement Outbound? and GRUU? should we mandate both
features for the registrar in this draft? IMHO not since it's an
Outbound topic already covered in RFC 5626.


2) Non Outbound Clients

SIP WebSocket entities that do not register (proxies/servers/b2buas)
and initiate outgoing WS connections to other SIP entities. They MAY
also implement a WS server. If not, they need to implement Connection
Reuse so must use secure WebSocket and present a TLS certificate to
the peer they connect to (if not, they are not able to receive
incoming requests from that peer).

And we leave this section open for future standarization.



Does it make sense?

Thanks a lot.


--=20
I=C3=B1aki Baz Castillo


From christer.holmberg@ericsson.com  Thu Mar 22 09:54:54 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1525021F85B6 for ; Thu, 22 Mar 2012 09:54:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.303
X-Spam-Level: 
X-Spam-Status: No, score=-10.303 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m0D6mLsCPFpe for ; Thu, 22 Mar 2012 09:54:53 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 39EC821F8559 for ; Thu, 22 Mar 2012 09:54:53 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-77-4f6b595c390d
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 34.17.17856.C595B6F4; Thu, 22 Mar 2012 17:54:52 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Thu, 22 Mar 2012 17:54:51 +0100
From: Christer Holmberg 
To: Paul Kyzivat , Adam Roach 
Date: Thu, 22 Mar 2012 17:54:38 +0100
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
Thread-Index: Ac0IQFA+LgexAg/BQYaCuT7lzjwR8AADCecI
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C411A5652@ESESSCMS0356.eemea.ericsson.se>
References:  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com>  <4F6B2CC7.1040506@alum.mit.! edu> <4F6B43F7.2080301@nostrum.com>,<4F6B44E3.2080907@alum.mit.edu>
In-Reply-To: <4F6B44E3.2080907@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "sipcore@ietf.org" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 16:54:54 -0000

Thumb up.

________________________________________
From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Paul=
 Kyzivat [pkyzivat@alum.mit.edu]
Sent: Thursday, March 22, 2012 5:27 PM
To: Adam Roach
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websock=
et (Outbound and more)

WFM

On 3/22/12 11:23 AM, Adam Roach wrote:
> [as an individual]
>
> On 3/22/12 08:44, Mar 22, Paul Kyzivat wrote:
>> On 3/22/12 8:34 AM, I=F1aki Baz Castillo wrote:
>>>
>>> So I would like to ask to the SIPCORE WG: should the draft consider
>>> that hypothetical case? or shoult it assume that there could exist SIP
>>> entities capable of initiating and receiving WS connections?
>>
>> I'm generally a believer in generality and completeness, which
>> inclines me to support considering this.
>>
>> BUT, before going far down that track I would like to have a good
>> understanding of what that means, the implications and limitations,
>> etc. And whether there is enough interest in pursuing it.
>
> I think what I'd prefer to see is that the current work does nothing to
> preclude the definition of such a set of behaviors in the future, but
> that we don't necessarily spend any work on it right now. It does seem
> highly theoretical (I can't imagine why a proxy-to-proxy link would use
> websockets instead of TCP), and it nearly doubles the complexity of what
> we would need to consider and define. But I do understand the desire for
> (and frequently advocate for) allowing behaviors for unforeseen
> circumstances -- that's where innovation is born.
>
> So, for the current work, I believe it would make sense to define the
> behavior for a WS transport between a UA (one that cannot listen for
> connections) and its first hop into the network. It would probably be
> worth explicitly calling out in the document that we don't currently
> define behavior for inter-intermediary websockets connections or for
> clients with the ability to listen for inbound connections, but that
> future documents may choose to do so.
>
> /a
>

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

From pravindran@sonusnet.com  Thu Mar 22 10:30:02 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CD221F8577 for ; Thu, 22 Mar 2012 10:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.957
X-Spam-Level: 
X-Spam-Status: No, score=-4.957 tagged_above=-999 required=5 tests=[AWL=1.642,  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 UgYX0Za93mlQ for ; Thu, 22 Mar 2012 10:30:02 -0700 (PDT)
Received: from na3sys010aog104.obsmtp.com (na3sys010aog104.obsmtp.com [74.125.245.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB2021F852E for ; Thu, 22 Mar 2012 10:30:01 -0700 (PDT)
Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob104.postini.com ([74.125.244.12]) with SMTP ID DSNKT2thmGZoqTTF5ZukbABw7RhBToQDQRY9@postini.com; Thu, 22 Mar 2012 10:30:01 PDT
Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Thu, 22 Mar 2012 13:30:15 -0400
Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Thu, 22 Mar 2012 22:59:54 +0530
From: "Ravindran, Parthasarathi" 
To: Paul Kyzivat , Adam Roach 
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
Thread-Index: AQHNBp/0VSI3yg3CHUWTRsteJDbZlZZy3OuAgAAGcICAAAWdgIAAJLgAgADktACAAFj1gIAAA+gAgAAGBYCAAAUMAIAAD7MAgAAD9gCAAHmSgIAAAykAgADy5ACAAAlNAIAAE4CAgAAbpICAAAEZgIAAeu/Q
Date: Thu, 22 Mar 2012 17:30:11 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E21E71F@inba-mail01.sonusnet.com>
References:  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com>  <4F6B2CC7.1040506@alum.mit.! edu> <4F6B43F7.2080301@nostrum.com> <4F6B44E3.2080907@alum.mit.edu>
In-Reply-To: <4F6B44E3.2080907@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [121.242.142.186]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "sipcore@ietf.org" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 17:30:02 -0000

SSBhZ3JlZSB3aXRoIEFkYW0gc3RhdGVtZW50IG9mIHVzaW5nIHdlYnNvY2tldCBiZXR3ZWVuIHR3
byBTSVAgc2VydmVycyBpcyBub3Qgc28gY29tcHVsc2l2ZSBhdCB0aGlzIG1vbWVudC4NCg0KQXMg
bG9uZyBhcyB0aGUgZm9sbG93aW5nIHRvcG9sb2dpZXMgYXJlIHN1cHBvcnRlZCBieSBTSVAgb3Zl
ciB3ZWJzb2NrZXQsIEknbSBmaW5lDQoNCjEpIFNJUCBVQS0tLS0tU0lQIFVBDQoyKSBTSVAgVUEt
LS0tLVNJUCBCMkJVQS0tLS1TSVAgVUENCjMpIFNJUCBVQS0tLS0tU0lQIHByb3h5DQoNClRoYW5r
cw0KUGFydGhhDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IHNpcGNvcmUt
Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj5C
ZWhhbGYgT2YgUGF1bCBLeXppdmF0DQo+U2VudDogVGh1cnNkYXksIE1hcmNoIDIyLCAyMDEyIDg6
NTggUE0NCj5UbzogQWRhbSBSb2FjaA0KPkNjOiBzaXBjb3JlQGlldGYub3JnDQo+U3ViamVjdDog
UmU6IFtzaXBjb3JlXSBTb21lIGNvbnNpZGVyYXRpb25zIG9uIGRyYWZ0LWliYy1zaXBjb3JlLXNp
cC0NCj53ZWJzb2NrZXQgKE91dGJvdW5kIGFuZCBtb3JlKQ0KPg0KPldGTQ0KPg0KPk9uIDMvMjIv
MTIgMTE6MjMgQU0sIEFkYW0gUm9hY2ggd3JvdGU6DQo+PiBbYXMgYW4gaW5kaXZpZHVhbF0NCj4+
DQo+PiBPbiAzLzIyLzEyIDA4OjQ0LCBNYXIgMjIsIFBhdWwgS3l6aXZhdCB3cm90ZToNCj4+PiBP
biAzLzIyLzEyIDg6MzQgQU0sIEnDsWFraSBCYXogQ2FzdGlsbG8gd3JvdGU6DQo+Pj4+DQo+Pj4+
IFNvIEkgd291bGQgbGlrZSB0byBhc2sgdG8gdGhlIFNJUENPUkUgV0c6IHNob3VsZCB0aGUgZHJh
ZnQgY29uc2lkZXINCj4+Pj4gdGhhdCBoeXBvdGhldGljYWwgY2FzZT8gb3Igc2hvdWx0IGl0IGFz
c3VtZSB0aGF0IHRoZXJlIGNvdWxkIGV4aXN0DQo+Pj4+IFNJUCBlbnRpdGllcyBjYXBhYmxlIG9m
IGluaXRpYXRpbmcgYW5kIHJlY2VpdmluZyBXUyBjb25uZWN0aW9ucz8NCj4+Pg0KPj4+IEknbSBn
ZW5lcmFsbHkgYSBiZWxpZXZlciBpbiBnZW5lcmFsaXR5IGFuZCBjb21wbGV0ZW5lc3MsIHdoaWNo
DQo+Pj4gaW5jbGluZXMgbWUgdG8gc3VwcG9ydCBjb25zaWRlcmluZyB0aGlzLg0KPj4+DQo+Pj4g
QlVULCBiZWZvcmUgZ29pbmcgZmFyIGRvd24gdGhhdCB0cmFjayBJIHdvdWxkIGxpa2UgdG8gaGF2
ZSBhIGdvb2QNCj4+PiB1bmRlcnN0YW5kaW5nIG9mIHdoYXQgdGhhdCBtZWFucywgdGhlIGltcGxp
Y2F0aW9ucyBhbmQgbGltaXRhdGlvbnMsDQo+Pj4gZXRjLiBBbmQgd2hldGhlciB0aGVyZSBpcyBl
bm91Z2ggaW50ZXJlc3QgaW4gcHVyc3VpbmcgaXQuDQo+Pg0KPj4gSSB0aGluayB3aGF0IEknZCBw
cmVmZXIgdG8gc2VlIGlzIHRoYXQgdGhlIGN1cnJlbnQgd29yayBkb2VzIG5vdGhpbmcNCj4+IHRv
IHByZWNsdWRlIHRoZSBkZWZpbml0aW9uIG9mIHN1Y2ggYSBzZXQgb2YgYmVoYXZpb3JzIGluIHRo
ZSBmdXR1cmUsDQo+PiBidXQgdGhhdCB3ZSBkb24ndCBuZWNlc3NhcmlseSBzcGVuZCBhbnkgd29y
ayBvbiBpdCByaWdodCBub3cuIEl0IGRvZXMNCj4+IHNlZW0gaGlnaGx5IHRoZW9yZXRpY2FsIChJ
IGNhbid0IGltYWdpbmUgd2h5IGEgcHJveHktdG8tcHJveHkgbGluaw0KPj4gd291bGQgdXNlIHdl
YnNvY2tldHMgaW5zdGVhZCBvZiBUQ1ApLCBhbmQgaXQgbmVhcmx5IGRvdWJsZXMgdGhlDQo+PiBj
b21wbGV4aXR5IG9mIHdoYXQgd2Ugd291bGQgbmVlZCB0byBjb25zaWRlciBhbmQgZGVmaW5lLiBC
dXQgSSBkbw0KPj4gdW5kZXJzdGFuZCB0aGUgZGVzaXJlIGZvciAoYW5kIGZyZXF1ZW50bHkgYWR2
b2NhdGUgZm9yKSBhbGxvd2luZw0KPj4gYmVoYXZpb3JzIGZvciB1bmZvcmVzZWVuIGNpcmN1bXN0
YW5jZXMgLS0gdGhhdCdzIHdoZXJlIGlubm92YXRpb24gaXMNCj5ib3JuLg0KPj4NCj4+IFNvLCBm
b3IgdGhlIGN1cnJlbnQgd29yaywgSSBiZWxpZXZlIGl0IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gZGVm
aW5lIHRoZQ0KPj4gYmVoYXZpb3IgZm9yIGEgV1MgdHJhbnNwb3J0IGJldHdlZW4gYSBVQSAob25l
IHRoYXQgY2Fubm90IGxpc3RlbiBmb3INCj4+IGNvbm5lY3Rpb25zKSBhbmQgaXRzIGZpcnN0IGhv
cCBpbnRvIHRoZSBuZXR3b3JrLiBJdCB3b3VsZCBwcm9iYWJseSBiZQ0KPj4gd29ydGggZXhwbGlj
aXRseSBjYWxsaW5nIG91dCBpbiB0aGUgZG9jdW1lbnQgdGhhdCB3ZSBkb24ndCBjdXJyZW50bHkN
Cj4+IGRlZmluZSBiZWhhdmlvciBmb3IgaW50ZXItaW50ZXJtZWRpYXJ5IHdlYnNvY2tldHMgY29u
bmVjdGlvbnMgb3IgZm9yDQo+PiBjbGllbnRzIHdpdGggdGhlIGFiaWxpdHkgdG8gbGlzdGVuIGZv
ciBpbmJvdW5kIGNvbm5lY3Rpb25zLCBidXQgdGhhdA0KPj4gZnV0dXJlIGRvY3VtZW50cyBtYXkg
Y2hvb3NlIHRvIGRvIHNvLg0KPj4NCj4+IC9hDQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2lwY29yZSBtYWlsaW5nIGxpc3QNCj5zaXBj
b3JlQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj
b3JlDQo=

From salvatore.loreto@ericsson.com  Thu Mar 22 10:53:21 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9D221F8630 for ; Thu, 22 Mar 2012 10:53:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.059
X-Spam-Level: 
X-Spam-Status: No, score=-110.059 tagged_above=-999 required=5 tests=[AWL=0.540, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IMPPyBuNNbk for ; Thu, 22 Mar 2012 10:53: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 B6A5E21F862A for ; Thu, 22 Mar 2012 10:53:20 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-3b-4f6b670fce4c
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C1.9A.27041.F076B6F4; Thu, 22 Mar 2012 18:53:19 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Thu, 22 Mar 2012 18:53:19 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 274B62321	for ; Thu, 22 Mar 2012 19:53:19 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1000452414	for ; Thu, 22 Mar 2012 19:53:19 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B31DC523EE	for ; Thu, 22 Mar 2012 19:53:18 +0200 (EET)
Message-ID: <4F6B670D.1030309@ericsson.com>
Date: Thu, 22 Mar 2012 18:53:17 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: sipcore@ietf.org
References:  <4F68F755.8030001@ericsson.com> <4F6B3EE5.8000602@digium.com>
In-Reply-To: <4F6B3EE5.8000602@digium.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 17:53:22 -0000

On 3/22/12 4:01 PM, Kevin P. Fleming wrote:
> On 03/20/2012 04:32 PM, Salvatore Loreto wrote:
>
>> 9.1. SIP Proxy Considerations
>>
>>      When a SIP proxy bridges WebSocket and any other SIP transport
>>      (including WebSocket transport) it MUST perform Loose Routing as
>>      specified in [RFC3261].
>>
>>
>> it is not clear to me how a SIP proxy can bridge a WebSocket request:
>> WebSocket connection go on to of an Upgraded HTTP connection
>> between the WebSocket client and the WebSocket client...
>> this connection can eventually pass through a HTTP Proxy but for sure
>> not a SIP proxy
> This would actually be fairly trivial to achieve. Imagine an HTTP server
> that proxies requests for a specific URI over to a SIP proxy that
> implements SIP/UDP, SIP/TCP, SIP/TLS and SIP/WebSocket.
you are touching exactly my point... is not a SIP proxy that bridges 
WebSocket
(as the paragraph above try to explain)
but it is an HTTP server (or to be more precise the application on top 
of a WebSocket Server)
  that proxies requests for a specific URI over a SIP proxy.
I wanted to make clear it...
because again it seems to me that in this discussion some time we are 
confusing
what does the WebSocket Server and what instead does a SiP proxy
>   The SIP proxy
> would then be the server-side endpoint of the WebSocket connection
> (which passes transparently through the HTTP server), and could treat
> incoming SIP requests and responses over that connection the same as it
> would treat them over any other transport. If a SIP INVITE request
> arrived over the WebSocket connection, the proxy would then forward it
> onwards over a suitable transport based on the Request-URI in the
> request itself.
>
> Does that make more sense?
It make sense to me, and it is as I actually think it should work...
but it is not what I get when I read the paragraph above and the draft


Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com


From salvatore.loreto@ericsson.com  Thu Mar 22 10:59:47 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4B021E8011 for ; Thu, 22 Mar 2012 10:59:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.919
X-Spam-Level: 
X-Spam-Status: No, score=-109.919 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OuVvNH60n4i for ; Thu, 22 Mar 2012 10:59:47 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 2568921E800F for ; Thu, 22 Mar 2012 10:59:46 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-92-4f6b689268a9
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 88.2B.27041.2986B6F4; Thu, 22 Mar 2012 18:59:46 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.213.0; Thu, 22 Mar 2012 18:59:45 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id C3E782321; Thu, 22 Mar 2012 19:59:45 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AE4C952414; Thu, 22 Mar 2012 19:59:45 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 43DE7523EE; Thu, 22 Mar 2012 19:59:42 +0200 (EET)
Message-ID: <4F6B688D.6020201@ericsson.com>
Date: Thu, 22 Mar 2012 18:59:41 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= 
References:   <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Cc: "sipcore@ietf.org" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 17:59:48 -0000

On 3/22/12 1:34 PM, Iñaki Baz Castillo wrote:
> 2012/3/22 Salvatore Loreto:
>>> Please check the second section in this mail that I sent previously,
>>> in which I talk about that hypothetical case:
>> that are hypothetical and  contradict architectural assumptions and
>> standards :-)
> Hi Salvatore. I know it's a very hypothetical case but, why should we
> not consider the scenario in which a SIP proxy P1 opens a WebSocket
> connection to SIP proxy P2, and P2 also opens a WebSocket connection
> to P1?
I am not saying we should not, I am saying that I would love you to explicit
what is the architecture you have in mind
>
> Note however that our first approach (current 01 draft) assumes what
> you say: a WS client can only open outgoing connections and a WS
> server can only listen for incoming connections. In that case Outbound
> (for end users)
I agree...
> or Connection Reuse (for proxy-proxy) is required.
I didn't remember the 01 explicit also this particular case... my bad!
>
> But we were encouraged to consider the hypothetical case in which a
> SIP entity is capable of initiating and accepting WS connections
> (which technically is feasible and does not break any protocol or
> specification IMHO).
once we design the use case/scenario and the architectural scenario
we can discuss it much better and not just speculating
>
> So I would like to ask to the SIPCORE WG: should the draft consider
> that hypothetical case? or shoult it assume that there could exist SIP
> entities capable of initiating and receiving WS connections?
I am always open to new innovative ideas... with the above caveat

Salvatore
>
> Regards.
>


-- 
Salvatore Loreto, PhD
www.sloreto.com


From ibc@aliax.net  Thu Mar 22 11:04:52 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B13F21E802C for ; Thu, 22 Mar 2012 11:04:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=0.056,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zDoKKB9ctlB for ; Thu, 22 Mar 2012 11:04:51 -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 03DD921F850F for ; Thu, 22 Mar 2012 11:04:50 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so2714412vcb.31 for ; Thu, 22 Mar 2012 11:04:50 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=1+AEap+FWu7jyqT7gCfKAv3eaG3V2yuusW9sz5lD0rY=; b=LqJGdyBUrWPvnmDz+knzMXERjqshY/SAtTFCjSp9ungSWga0wcdj2ty5IXLHYd2/EH GeW94tgA2x/Yq/EdNwLxuM7IKdDHxrlVhrkAbYnJts0CnkrGRHqirAVXi5ftuhGoiXpM sEQjEBk/soJ+jS1yvsVlrM0y4EmlNFTGE44iwssvi3TPzFAQEqQhcXrqaOqwFrUwn9Ky NQKdesPszqZVbLCaZfjdcYK+44quBqI3x9NX4EalYMofIh2OoCj7D4GZ13lRz6utrYcI RmcHoShyPA1tYRajzBZm1B7BUNTW5EK/mXhffksvwIRaaNaqb6241RWVCmE2LL4ooJqH Zi7w==
Received: by 10.220.140.196 with SMTP id j4mr4643992vcu.22.1332439490198; Thu, 22 Mar 2012 11:04:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Thu, 22 Mar 2012 11:04:30 -0700 (PDT)
In-Reply-To: <4F6B670D.1030309@ericsson.com>
References:  <4F68F755.8030001@ericsson.com> <4F6B3EE5.8000602@digium.com> <4F6B670D.1030309@ericsson.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 22 Mar 2012 19:04:30 +0100
Message-ID: 
To: Salvatore Loreto 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkNDcwkhVT1jk0fw7iGwf0bBq1SPZZgjbCL1ugjRNJ4/6ZEXjazcBxpr4r/lgoV9qx4+4G2
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 18:04:52 -0000

2012/3/22 Salvatore Loreto :
>> This would actually be fairly trivial to achieve. Imagine an HTTP server
>> that proxies requests for a specific URI over to a SIP proxy that
>> implements SIP/UDP, SIP/TCP, SIP/TLS and SIP/WebSocket.
>
> you are touching exactly my point... is not a SIP proxy that bridges
> WebSocket
> (as the paragraph above try to explain)
> but it is an HTTP server (or to be more precise the application on top of=
 a
> WebSocket Server)
> =C2=A0that proxies requests for a specific URI over a SIP proxy.
> I wanted to make clear it...
> because again it seems to me that in this discussion some time we are
> confusing
> what does the WebSocket Server and what instead does a SiP proxy

Hi Salvarote, as said before the draft defines a SIP transport,
regardless it's a network transport or not.

There is no need at all for having a separate HTTP/WebSocket server
that proxies requests over a real SIP proxy. Indeed, what we are
defining here is that a SIP proxy or server could also implement a
WebSocket server interface for accepting WS connections. When a WS
message arrives to the server, it extracts its contain (a SIP message)
in the same way it extracts it from a TCP packet or an UDP datagram or
a TLS-over-TCP session.  No difference from the SIP layer's point of
view.

Please check my previous response to Kevin in this thread and take a look t=
o:

 http://sip-on-the-web.aliax.net/
 http://www.youtube.com/watch?v=3DqfFlK1KyF6Q

That is a SIP proxy, not a WS server +  SIP proxy   :)

Regards.


--=20
I=C3=B1aki Baz Castillo


From salvatore.loreto@ericsson.com  Thu Mar 22 11:27:20 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AEE21F85C6 for ; Thu, 22 Mar 2012 11:27:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.926
X-Spam-Level: 
X-Spam-Status: No, score=-109.926 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWAHFG6yoVaV for ; Thu, 22 Mar 2012 11:27:20 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id DE37021F85D3 for ; Thu, 22 Mar 2012 11:27:19 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-5d-4f6b6f069274
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9E.CD.27041.60F6B6F4; Thu, 22 Mar 2012 19:27:19 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Thu, 22 Mar 2012 19:27:18 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 83A152321; Thu, 22 Mar 2012 20:27:18 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6B71C52414; Thu, 22 Mar 2012 20:27:18 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id F3E44523EE; Thu, 22 Mar 2012 20:27:17 +0200 (EET)
Message-ID: <4F6B6F05.2000903@ericsson.com>
Date: Thu, 22 Mar 2012 19:27:17 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= 
References:  <4F68F755.8030001@ericsson.com> <4F6B3EE5.8000602@digium.com> <4F6B670D.1030309@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Cc: "sipcore@ietf.org" 
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 18:27:21 -0000

On 3/22/12 7:04 PM, Iñaki Baz Castillo wrote:
> 2012/3/22 Salvatore Loreto:
>>> This would actually be fairly trivial to achieve. Imagine an HTTP server
>>> that proxies requests for a specific URI over to a SIP proxy that
>>> implements SIP/UDP, SIP/TCP, SIP/TLS and SIP/WebSocket.
>> you are touching exactly my point... is not a SIP proxy that bridges
>> WebSocket
>> (as the paragraph above try to explain)
>> but it is an HTTP server (or to be more precise the application on top of a
>> WebSocket Server)
>>   that proxies requests for a specific URI over a SIP proxy.
>> I wanted to make clear it...
>> because again it seems to me that in this discussion some time we are
>> confusing
>> what does the WebSocket Server and what instead does a SiP proxy
> Hi Salvarote, as said before the draft defines a SIP transport,
> regardless it's a network transport or not.
>
> There is no need at all for having a separate HTTP/WebSocket server
> that proxies requests over a real SIP proxy. Indeed, what we are
> defining here is that a SIP proxy or server could also implement a
> WebSocket server interface for accepting WS connections.
you used the "implement" verb, and indeed yours it is an implementation
solution... that I think could be reasonable but needs to be explained 
much better
in the draft

is the WebSocket server interface (you describe) also listening on the 
ports 5060/5061 ?

cheers
Salvatore
>   When a WS
> message arrives to the server, it extracts its contain (a SIP message)
> in the same way it extracts it from a TCP packet or an UDP datagram or
> a TLS-over-TCP session.  No difference from the SIP layer's point of
> view.
>
> Please check my previous response to Kevin in this thread and take a look to:
>
>   http://sip-on-the-web.aliax.net/
>   http://www.youtube.com/watch?v=qfFlK1KyF6Q
>
> That is a SIP proxy, not a WS server +  SIP proxy   :)
>
> Regards.
>
>


-- 
Salvatore Loreto, PhD
www.sloreto.com


From kpfleming@digium.com  Thu Mar 22 11:35:59 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800FD21F8592 for ; Thu, 22 Mar 2012 11:35:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.063
X-Spam-Level: 
X-Spam-Status: No, score=-106.063 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, J_BACKHAIR_23=1, 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 2Ngrf4cD7c95 for ; Thu, 22 Mar 2012 11:35:58 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id AF5FE21F85D3 for ; Thu, 22 Mar 2012 11:35:58 -0700 (PDT)
Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SAmre-0001Fl-A6 for sipcore@ietf.org; Thu, 22 Mar 2012 13:35:58 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 4C421D8012 for ; Thu, 22 Mar 2012 13:35:58 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTpojRBBvXyl for ; Thu, 22 Mar 2012 13:35:57 -0500 (CDT)
Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 91958D8002 for ; Thu, 22 Mar 2012 13:35:57 -0500 (CDT)
Message-ID: <4F6B710D.2070302@digium.com>
Date: Thu, 22 Mar 2012 13:35:57 -0500
From: "Kevin P. Fleming" 
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: sipcore@ietf.org
References:  <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com>  <4F6B2CC7.1040506@alum.mit.! edu> <4F6B43F7.2080301@nostrum.com> <4F6B44E3.2080907@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E21E71F@inba-mail01.sonusnet.com>
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E21E71F@inba-mail01.sonusnet.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 18:35:59 -0000

On 03/22/2012 12:30 PM, Ravindran, Parthasarathi wrote:
> I agree with Adam statement of using websocket between two SIP servers is not so compulsive at this moment.

There is no such thing as a 'SIP server'. There are SIP UAs, SIP 
proxies, SIP registrars, SIP redirectors, etc. Their behaviors are quite 
different, and cannot be lumped together. If we don't use RFC-defined 
terminology, the discussion gets confused (as this one has).

> As long as the following topologies are supported by SIP over websocket, I'm fine
>
> 1) SIP UA-----SIP UA
> 2) SIP UA-----SIP B2BUA----SIP UA

Cases 1 and 2 are identical. Case 2 is just two SIP UA<->SIP UA links 
connected by a (potentially non-SIP) link. The transport used for the 
first link is irrelevant to the second link.

> 3) SIP UA-----SIP proxy

This case is the reason for the discussion related to Outbound, 
connection-reuse, etc. If a SIP UA uses a WebSocket connection to 
deliver a request containing a Contact header to a SIP proxy, then 
presumably the proxy will be forwarding that request to some other SIP 
network element (since that is what proxies do). The contents of the 
Contact header *must* be usable by that receiving network element for it 
to be able to communicate with the sending SIP UA, unless the proxy has 
forced itself to be in the path of all communications between them.

What Inaki has been saying all along is that if this use-case is to be 
expected to work, then the fact that WebSocket is in use between the SIP 
UA and the SIP proxy is *relevant* to the communications with downstream 
network elements; if the SIP headers are not constructed properly, 
communication will be broken (to various degrees). This is *identical* 
to the case where a SIP UA uses TCP behind a NAT, or TLS, to communicate 
with its proxy, because in those cases the SIP UA *also* cannot receive 
incoming connections, and communication with it must occur over the 
connection it opened to the SIP proxy.

There will most definitely be use cases for WebSocket connections 
between SIP UAs (with no proxy in the middle). We are already working on 
adding WebSocket support to Asterisk, which is a B2BUA, and so we don't 
really have to worry about the SIP UAs that connect to Asterisk 
requesting GRUUs when they register, because we don't publish their 
Contact URIs anywhere at all. We *do* need to be concerned about 
connection-reuse and/or Outbound, because we can very nearly guarantee 
that we won't be able to open a WebSocket connection back to them for 
sending responses or additional requests.

Unless I'm missing something, the use of WebSocket between two SIP UAs 
is actually simpler than between a SIP UA and a SIP proxy, because there 
is no need for GRUUs at all. I'd be happy to help ensure that this draft 
provides guidance/mechanisms/etc. on how to ensure that WebSocket can be 
used between two SIP UAs.

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

From kpfleming@digium.com  Thu Mar 22 11:43:16 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0FD21F85A4 for ; Thu, 22 Mar 2012 11:43:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.545
X-Spam-Level: 
X-Spam-Status: No, score=-106.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 AZKzSSK4dT92 for ; Thu, 22 Mar 2012 11:43:15 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4D69F21F85AA for ; Thu, 22 Mar 2012 11:43:15 -0700 (PDT)
Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SAmyf-0001Ma-1u for sipcore@ietf.org; Thu, 22 Mar 2012 13:43:13 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 0CF87D8012 for ; Thu, 22 Mar 2012 13:43:13 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1JUedM3LZst for ; Thu, 22 Mar 2012 13:43:12 -0500 (CDT)
Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 64DA3D8002 for ; Thu, 22 Mar 2012 13:43:12 -0500 (CDT)
Message-ID: <4F6B72C0.8090306@digium.com>
Date: Thu, 22 Mar 2012 13:43:12 -0500
From: "Kevin P. Fleming" 
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: sipcore@ietf.org
References:  <4F68F755.8030001@ericsson.com> <4F6B3EE5.8000602@digium.com> <4F6B670D.1030309@ericsson.com>
In-Reply-To: <4F6B670D.1030309@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 18:43:16 -0000

On 03/22/2012 12:53 PM, Salvatore Loreto wrote:
> On 3/22/12 4:01 PM, Kevin P. Fleming wrote:
>> On 03/20/2012 04:32 PM, Salvatore Loreto wrote:
>>
>>> 9.1. SIP Proxy Considerations
>>>
>>> When a SIP proxy bridges WebSocket and any other SIP transport
>>> (including WebSocket transport) it MUST perform Loose Routing as
>>> specified in [RFC3261].
>>>
>>>
>>> it is not clear to me how a SIP proxy can bridge a WebSocket request:
>>> WebSocket connection go on to of an Upgraded HTTP connection
>>> between the WebSocket client and the WebSocket client...
>>> this connection can eventually pass through a HTTP Proxy but for sure
>>> not a SIP proxy
>> This would actually be fairly trivial to achieve. Imagine an HTTP server
>> that proxies requests for a specific URI over to a SIP proxy that
>> implements SIP/UDP, SIP/TCP, SIP/TLS and SIP/WebSocket.
> you are touching exactly my point... is not a SIP proxy that bridges
> WebSocket
> (as the paragraph above try to explain)
> but it is an HTTP server (or to be more precise the application on top
> of a WebSocket Server)
> that proxies requests for a specific URI over a SIP proxy.
> I wanted to make clear it...
> because again it seems to me that in this discussion some time we are
> confusing
> what does the WebSocket Server and what instead does a SiP proxy

I don't see the confusion, but if we can improve the language, that's 
certainly helpful.

I guess the primary point here is that WebSocket, from the point of a 
SIP UA or proxy, is *just* a transport, no different in concept from 
UDP, TCP, TCP/TLS, UDP/DTLS, SCTP, etc. The SIP UA's (or proxy's) 
behavior does not fundamentally change due to the use of WebSocket 
(although obviously there are some differences between transports which 
guarantee in-order delivery of messages and those that do not).

In the context of RFC 3261, a SIP proxy handles 
routing/forward/forking/etc. of SIP requests and responses, irrespective 
of how those requests/response are transported.

In the use-case we are talking about, the HTTP server does not even need 
to be aware of the WebSocket sub-protocol in use *at all*. It would 
proxy the initial GET request to whatever destination its administrator 
has told it to send it to, and if the connection is established, it 
would pass WebSocket frames (messages) back and forth between the 
connections (ideally, it would just bridge the TCP packets). Whether the 
WebSocket client (that made the initial connection) and the WebSocket 
server (that accepted the proxied connection) are speaking chat, SIP, 
XMPP or anything else does not matter at all.

If the WebSocket server that accepted the connection for sub-protocol 
'sip' is in fact a proxy, not a UA, then it will do what SIP proxies do. 
It will accept SIP messages and proxy them, taking into account the 
specifics of the transport protocols in use when necessary.

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

From ibc@aliax.net  Thu Mar 22 13:22:18 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343B721F857D for ; Thu, 22 Mar 2012 13:22:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=0.056,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKNkk7z2y9XF for ; Thu, 22 Mar 2012 13:22:17 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 45C8221F8568 for ; Thu, 22 Mar 2012 13:22:17 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so1398187vbb.31 for ; Thu, 22 Mar 2012 13:22:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=0O9I36NuEwOv94XUNCDcNotMTSLKS2GPwcQeJp4j8/I=; b=CWRXf6qSVCHNm6S7jPa5tB/cdnBIfUSuOBitj5zbPPyj9Bt7Dmp/z8AcT6zrD3jlZn zD78qgUuljwued8C6evQK+vo4yrbtBfZ68kO1TCI0YTGbeZ+wpbeuG9tAtyr8Hm5eDxX 9Qp/EaUV6ucZH63gQ24/h8FFWDsBgMdJVk1JPqeutGwOcXe4sNEnatVyXmg7y524Hneu 77o7ahFEypZWRpT2Qm0gzfdXzQzaouirI+ECJ06fA/SdJ0csUd0B8ImTRID90MZa3Qe5 xkvDY2nuHF5jAsBVpzYBXYkgc9Wu3Ui8Lz3TgxVf7ZVxxj4E//pTNL6goO9ZKCtoajsc JByA==
Received: by 10.52.90.111 with SMTP id bv15mr4085199vdb.34.1332447736722; Thu, 22 Mar 2012 13:22:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Thu, 22 Mar 2012 13:21:56 -0700 (PDT)
In-Reply-To: <4F6B6F05.2000903@ericsson.com>
References:  <4F68F755.8030001@ericsson.com> <4F6B3EE5.8000602@digium.com> <4F6B670D.1030309@ericsson.com>  <4F6B6F05.2000903@ericsson.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 22 Mar 2012 21:21:56 +0100
Message-ID: 
To: Salvatore Loreto 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnCjbOvuCMZ07CaQKMqUzXlKfAThbZ3nzSWsRN0LXO12c5wSpAMJIRQ6w5W6tbrlF9QCVck
Cc: "sipcore@ietf.org" 
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 20:22:18 -0000

2012/3/22 Salvatore Loreto :
>> There is no need at all for having a separate HTTP/WebSocket server
>> that proxies requests over a real SIP proxy. Indeed, what we are
>> defining here is that a SIP proxy or server could also implement a
>> WebSocket server interface for accepting WS connections.
>
> you used the "implement" verb, and indeed yours it is an implementation
> solution... that I think could be reasonable but needs to be explained mu=
ch
> better in the draft

I now understand your point. Ok, it will be properly explained in a
new version of the draft.



> is the WebSocket server interface (you describe) also listening on the po=
rts
> 5060/5061 ?

No. The SIP proxy is listening in ports 5060/5061 for SIP over
UDP/TCP/TLS. SIP over WS is on port 10080 and SIP over WSS on port
10443.


Regards.


--=20
I=C3=B1aki Baz Castillo


From ibc@aliax.net  Thu Mar 22 13:23:29 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2949D21F857D for ; Thu, 22 Mar 2012 13:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.622
X-Spam-Level: 
X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=0.055,  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 xnseAp7F0GfP for ; Thu, 22 Mar 2012 13:23:28 -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 A7AB421F8568 for ; Thu, 22 Mar 2012 13:23:28 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so2843929vcb.31 for ; Thu, 22 Mar 2012 13:23:28 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=qrE5SD4F6Zlt3jtMZYhLneHmi1kRufv0U3MRMoJzXXs=; b=Adio7KvwqyYTxT5rx5Q4WI2OuIAsE1zneW8P1PyfokZxWPvFOKJc0ViVjIPfCiBd1O NFVh7zNdZtMnwxBNVFa/yu40kuwshpc1ImrIvSRbeGApLze9f1gcVEIa2zwzj70ayGRx Jd6CCMlcL6qcx5TaU94Aogho1ALLs5X+2kKl4I9a889s69OhiZpK/ToobTBm2eqtzm5C hQmQgs66X1Ugq6csnOqF+nMhQpZqV6bgM/fANn1fFUs3H6Yl9YBbDpESwm+XiAiDKdw6 h2SQ7U1wgCyLdQlIdxYh1tQAFZaBIXAwEDreO5J+uHFJLMaSy6FJd9lRmFg7fDQz8Usv o7mg==
Received: by 10.220.140.196 with SMTP id j4mr4847622vcu.22.1332447808198; Thu, 22 Mar 2012 13:23:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Thu, 22 Mar 2012 13:23:08 -0700 (PDT)
In-Reply-To: <4F6B72C0.8090306@digium.com>
References:  <4F68F755.8030001@ericsson.com> <4F6B3EE5.8000602@digium.com> <4F6B670D.1030309@ericsson.com> <4F6B72C0.8090306@digium.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 22 Mar 2012 21:23:08 +0100
Message-ID: 
To: "Kevin P. Fleming" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnkfbHwm5PAQgVsnzihIf51fXC/10q7tRhPVCj/Pu1q5HWdauo5SU9ZOLAHvVQRmMQKZbWp
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 20:23:29 -0000

2012/3/22 Kevin P. Fleming :
> If the WebSocket server that accepted the connection for sub-protocol 'si=
p'
> is in fact a proxy, not a UA, then it will do what SIP proxies do. It wil=
l
> accept SIP messages and proxy them, taking into account the specifics of =
the
> transport protocols in use when necessary.

That's exactly the point :)

--=20
I=C3=B1aki Baz Castillo


From ibc@aliax.net  Thu Mar 22 13:34:49 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5C521F8510 for ; Thu, 22 Mar 2012 13:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.623
X-Spam-Level: 
X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=0.054,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02BsXvF6EtYJ for ; Thu, 22 Mar 2012 13:34:48 -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 6B25321F84DD for ; Thu, 22 Mar 2012 13:34:48 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so2852322vcb.31 for ; Thu, 22 Mar 2012 13:34:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=fIMqurj2DkML0HJfYlUJM8mb2D+qCLK7QLobMbhJAmU=; b=axH3QQ8oiDArKZMNpOu00t6arhL/vAfl/Zx+W5rpqCIL1zDrGi5SgZFHcqxlNw8ANe XbtfmvxfOPQMY8Xe3zyfPeEMUfJGmeq+1HgqFMM9nwgsoYXymCGZwJMvvLstarul6jNq UYra8bKTtQzURSItbhNUO/qyHVNb2unKCK+bOzuzyR01gI6hr67rLhwWUF7Fs0CYahf9 BG1P74ZaKu3cecmHQdKaqUyGpEsKV9elLYFr2PIPRbY/hhotR8z9Jl4+rcJQR9RczLk3 FnBHlcFaF/zriQWtLJcd0T91XYaShUQYS0D9pDvxKc1PsR1huwicLSVuiFAsV3HSvBFa 7myw==
Received: by 10.220.152.205 with SMTP id h13mr4864855vcw.12.1332448487821; Thu, 22 Mar 2012 13:34:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Thu, 22 Mar 2012 13:34:27 -0700 (PDT)
In-Reply-To: <4F6B710D.2070302@digium.com>
References:  <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com>  <4F6B43F7.2080301@nostrum.com> <4F6B44E3.2080907@alum.mit.edu> <387F9047F55E8C42850AD6B3A7A03C6C0E21E71F@inba-mail01.sonusnet.com> <4F6B710D.2070302@digium.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 22 Mar 2012 21:34:27 +0100
Message-ID: 
To: "Kevin P. Fleming" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlSLNxBrgwR3SFAHCLRjYgUu0YAl44QhrR5N3yz05ZTO1AyAGt59rUpqSB/VolfHL8Ub1tb
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 22 Mar 2012 20:34:49 -0000

2012/3/22 Kevin P. Fleming :
>> 3) SIP UA-----SIP proxy
>
>
> This case is the reason for the discussion related to Outbound,
> connection-reuse, etc. If a SIP UA uses a WebSocket connection to deliver=
 a
> request containing a Contact header to a SIP proxy, then presumably the
> proxy will be forwarding that request to some other SIP network element
> (since that is what proxies do). The contents of the Contact header *must=
*
> be usable by that receiving network element for it to be able to communic=
ate
> with the sending SIP UA, unless the proxy has forced itself to be in the
> path of all communications between them.

The Contact is tytpically needed for a proxy to route an in-dialog
request to the final user (connected directly to the proxy), but
Outbound RFC 5626 changes it by including the client connection
identifier within the Record-Route header, so it does not matter
whether the client inserted a Contact header with a private address
(so not reachable by the proxy if Outbound is not used).





> Unless I'm missing something, the use of WebSocket between two SIP UAs is
> actually simpler than between a SIP UA and a SIP proxy, because there is =
no
> need for GRUUs at all. I'd be happy to help ensure that this draft provid=
es
> guidance/mechanisms/etc. on how to ensure that WebSocket can be used betw=
een
> two SIP UAs.

In fact, RFC 5626 does not mandate the presence of an EDGE proxy
between the UA and the registrar. It also covers the case in which the
UA directly connects to the registrar. If the registrar is a b2bua
(i.e. Asterisk) rather than a proxy, then there is not Record-Route so
neither an Outbound connection identifier in the SIP messages.

Since B2BUA's are "not defined" they can associate the connection with
its UA in any way. Such an information can be added to the dialog data
and/or to the location database (location of user with AoR XXXXX is
associated to some file descriptor).

So being honest IMHO the draft does not need to cover the scenario in
which a WS client connects to a B2BUA which also acts as a registrar.
IMHO such an scenario is already covered in RFC 5626 and it's exactly
the same as in case the client connects via SIP TCP. I could be wrong
of course.


Regards.



--=20
I=C3=B1aki Baz Castillo


From pkyzivat@alum.mit.edu  Thu Mar 22 13:56:40 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A47B21F8528 for ; Thu, 22 Mar 2012 13:56:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level: 
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039,  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 7BuJbNsVraTw for ; Thu, 22 Mar 2012 13:56:39 -0700 (PDT)
Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [76.96.62.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD2021F851B for ; Thu, 22 Mar 2012 13:56:39 -0700 (PDT)
Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta07.westchester.pa.mail.comcast.net with comcast id okXc1i0021vXlb857kwgFc; Thu, 22 Mar 2012 20:56:40 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id okwf1i00o07duvL3dkwfux; Thu, 22 Mar 2012 20:56:40 +0000
Message-ID: <4F6B9206.2050304@alum.mit.edu>
Date: Thu, 22 Mar 2012 16:56:38 -0400
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: sipcore@ietf.org
References:  <4F68F755.8030001@ericsson.com> <4F6B3EE5.8000602@digium.com> <4F6B670D.1030309@ericsson.com>  <4F6B6F05.2000903@ericsson.com> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 20:56:40 -0000

On 3/22/12 4:21 PM, Iñaki Baz Castillo wrote:

>> is the WebSocket server interface (you describe) also listening on the ports
>> 5060/5061 ?
>
> No. The SIP proxy is listening in ports 5060/5061 for SIP over
> UDP/TCP/TLS. SIP over WS is on port 10080 and SIP over WSS on port
> 10443.

Umm - according to the IANA port number registry, 10080 is assigned to 
"amanda" and 10443 isn't assigned.

You may be using those numbers in your implementation, but you ought not 
be using one assigned to something else, and you certainly should't 
publish one that isn't assigned.

	Thanks,
	Paul

From ibc@aliax.net  Thu Mar 22 14:03:23 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C64E21F84D6 for ; Thu, 22 Mar 2012 14:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.624
X-Spam-Level: 
X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.053,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNsX5qzQeUTZ for ; Thu, 22 Mar 2012 14:03:22 -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 10F6121F84D5 for ; Thu, 22 Mar 2012 14:03:14 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so2873643vcb.31 for ; Thu, 22 Mar 2012 14:03:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=tRPLcM7eiS57HOAZT6d99ZpBzDk44WIXazM3gaa3oq4=; b=hVP/KWWFDCk7zw7EmIDSqnnRO+EFZ/GWIkwRWKHUqVtoEdDN3NhmG2S5B/sS1HXvuB kqz7YKrgFOOgi7hR74xDxQL0A+MdCSb4huPyHHuQqCgfPkpzPERWU+1Y2PtbqdBPxe9e 8QZnfflutZ7OagjrDgFNyZBgmnnKgt5Uiajn7aFmg6t1ECYs5YfAheueInMckzYvMGO8 8i8mExLZcbzRi8Wz8xVhVrXGHKb7H1jQJUI623XWocyJW5A97QgacZ1JRGUwjKcPyZNi vkle7KZJISQnwoj48tgPK1jU40GZynwZQXKuZUEQKfddYgi6YtjbYQkTBZuVz7j9PFXV xFuQ==
Received: by 10.52.90.111 with SMTP id bv15mr4130499vdb.34.1332450194116; Thu, 22 Mar 2012 14:03:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Thu, 22 Mar 2012 14:02:54 -0700 (PDT)
In-Reply-To: <4F6B9206.2050304@alum.mit.edu>
References:  <4F68F755.8030001@ericsson.com> <4F6B3EE5.8000602@digium.com> <4F6B670D.1030309@ericsson.com>  <4F6B6F05.2000903@ericsson.com>  <4F6B9206.2050304@alum.mit.edu>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 22 Mar 2012 22:02:54 +0100
Message-ID: 
To: Paul Kyzivat 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQluuW6majo6ikMIbiL/geBN1IUpvSzfhlb9kJEAtBoNf6roClVp9prPtf/AbNdzl77HmdCM
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 21:03:23 -0000

2012/3/22 Paul Kyzivat :
>> The SIP proxy is listening in ports 5060/5061 for SIP over
>> UDP/TCP/TLS. SIP over WS is on port 10080 and SIP over WSS on port
>> 10443.
>
>
> Umm - according to the IANA port number registry, 10080 is assigned to
> "amanda" and 10443 isn't assigned.
>
> You may be using those numbers in your implementation, but you ought not =
be
> using one assigned to something else, and you certainly should't publish =
one
> that isn't assigned.

Thanks, it's just a test server so not a big problem yet :)

One question coming to my mind:

Given this SIP URI and assuming that domain.com has no SRV records:

  sip:domain.com;transport=3Dws

Which port should be the default for the WS transport? 5060 (so
conflict with SIP TCP)? or 80 (so the associated WebSocket URI would
become ws://domain.com)?

Regards.


--=20
I=C3=B1aki Baz Castillo


From kpfleming@digium.com  Thu Mar 22 14:42:30 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C6121E803D for ; Thu, 22 Mar 2012 14:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.539
X-Spam-Level: 
X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 OqRRXNxjzR8k for ; Thu, 22 Mar 2012 14:42:29 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 4B36121E802D for ; Thu, 22 Mar 2012 14:42:29 -0700 (PDT)
Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SApm8-0004bS-Uq for sipcore@ietf.org; Thu, 22 Mar 2012 16:42:28 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id EBB82D8012 for ; Thu, 22 Mar 2012 16:42:28 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX5DsgK+WUvt for ; Thu, 22 Mar 2012 16:42:28 -0500 (CDT)
Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 8EF0CD8011 for ; Thu, 22 Mar 2012 16:42:28 -0500 (CDT)
Message-ID: <4F6B9CC4.7000208@digium.com>
Date: Thu, 22 Mar 2012 16:42:28 -0500
From: "Kevin P. Fleming" 
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: sipcore@ietf.org
References:  <4F68F755.8030001@ericsson.com> <4F6B3EE5.8000602@digium.com> <4F6B670D.1030309@ericsson.com>  <4F6B6F05.2000903@ericsson.com>  <4F6B9206.2050304@alum.mit.edu> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 21:42:30 -0000

On 03/22/2012 04:02 PM, I=F1aki Baz Castillo wrote:
> 2012/3/22 Paul Kyzivat:
>>> The SIP proxy is listening in ports 5060/5061 for SIP over
>>> UDP/TCP/TLS. SIP over WS is on port 10080 and SIP over WSS on port
>>> 10443.
>>
>>
>> Umm - according to the IANA port number registry, 10080 is assigned to
>> "amanda" and 10443 isn't assigned.
>>
>> You may be using those numbers in your implementation, but you ought n=
ot be
>> using one assigned to something else, and you certainly should't publi=
sh one
>> that isn't assigned.
>
> Thanks, it's just a test server so not a big problem yet :)
>
> One question coming to my mind:
>
> Given this SIP URI and assuming that domain.com has no SRV records:
>
>    sip:domain.com;transport=3Dws
>
> Which port should be the default for the WS transport? 5060 (so
> conflict with SIP TCP)? or 80 (so the associated WebSocket URI would
> become ws://domain.com)?

Since WebSocket is specified to operate over HTTP, I would expect port=20
80 to be the default for that URI. Port 443 would be the default for a=20
secure WebSocket SIP URI.

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

From salvatore.loreto@ericsson.com  Thu Mar 22 14:45:51 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD2D21F84D5 for ; Thu, 22 Mar 2012 14:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.083
X-Spam-Level: 
X-Spam-Status: No, score=-110.083 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0u6i1xc8nEnn for ; Thu, 22 Mar 2012 14:45:51 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BB07421F84C5 for ; Thu, 22 Mar 2012 14:45:50 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-4d-4f6b9d8dba89
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E0.BF.27041.D8D9B6F4; Thu, 22 Mar 2012 22:45:49 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Thu, 22 Mar 2012 22:45:49 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 0CD402321	for ; Thu, 22 Mar 2012 23:45:49 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 161FB52414	for ; Thu, 22 Mar 2012 23:45:49 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AB12B523EE	for ; Thu, 22 Mar 2012 23:45:48 +0200 (EET)
Message-ID: <4F6B9D88.5060804@ericsson.com>
Date: Thu, 22 Mar 2012 22:45:44 +0100
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: sipcore@ietf.org
References:  <4F68F755.8030001@ericsson.com> <4F6B3EE5.8000602@digium.com> <4F6B670D.1030309@ericsson.com>  <4F6B6F05.2000903@ericsson.com>  <4F6B9206.2050304@alum.mit.edu>  <4F6B9CC4.7000208@digium.com>
In-Reply-To: <4F6B9CC4.7000208@digium.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 21:45:51 -0000

On 3/22/12 10:42 PM, Kevin P. Fleming wrote:
> On 03/22/2012 04:02 PM, I�aki Baz Castillo wrote:
>> 2012/3/22 Paul Kyzivat:
>>>> The SIP proxy is listening in ports 5060/5061 for SIP over
>>>> UDP/TCP/TLS. SIP over WS is on port 10080 and SIP over WSS on port
>>>> 10443.
>>>
>>> Umm - according to the IANA port number registry, 10080 is assigned to
>>> "amanda" and 10443 isn't assigned.
>>>
>>> You may be using those numbers in your implementation, but you ought not be
>>> using one assigned to something else, and you certainly should't publish one
>>> that isn't assigned.
>> Thanks, it's just a test server so not a big problem yet :)
>>
>> One question coming to my mind:
>>
>> Given this SIP URI and assuming that domain.com has no SRV records:
>>
>>     sip:domain.com;transport=ws
>>
>> Which port should be the default for the WS transport? 5060 (so
>> conflict with SIP TCP)? or 80 (so the associated WebSocket URI would
>> become ws://domain.com)?
> Since WebSocket is specified to operate over HTTP, I would expect port
> 80 to be the default for that URI. Port 443 would be the default for a
> secure WebSocket SIP URI.
>
that was also my expectation ...

From ibc@aliax.net  Thu Mar 22 14:59:15 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B9021F8565 for ; Thu, 22 Mar 2012 14:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.624
X-Spam-Level: 
X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=0.053,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9mEqLLUetHr for ; Thu, 22 Mar 2012 14:59: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 3971821F84F6 for ; Thu, 22 Mar 2012 14:59:15 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so2909429vcb.31 for ; Thu, 22 Mar 2012 14:59:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=8+YGWfTUW5lnXniHKhYt4GZkXnBGZuQaqFHdr6QxAZc=; b=m3PMNte/9WBbCn3qCj9rJ+QRw5zuh5KA7DeaW8ZyDyERyT0Y3vksijIm8HxgJ50zpi xG2NpRWzpRj1nHBHOQ1y1ygo6hg+zXbbtc/jIoRyIkTOdfMknNtKng9rggIJN5rDzgDy JK1MJ+9FPYH9vqend1mNCSo2EJ+Nwst7U5GshJ39M1JE5jM+pmU0QKAmmgeJpTf9gSb/ 285N3rftQHs5qMQ9FyK/slso8q3Bn5LuFirDAvfAoXaTDd+pcAJX5cFZf0qFT7J1Z9kv 2qxouNUpkKl5//KjQwH2/cD/tYJ0bygi+QGDHfrk1n+4Dz98u9P7uBSwRsKDsV4hKYWn /DMA==
Received: by 10.52.24.49 with SMTP id r17mr1528865vdf.51.1332453554516; Thu, 22 Mar 2012 14:59:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Thu, 22 Mar 2012 14:58:54 -0700 (PDT)
In-Reply-To: <4F6B9D88.5060804@ericsson.com>
References:  <4F68F755.8030001@ericsson.com> <4F6B3EE5.8000602@digium.com> <4F6B670D.1030309@ericsson.com>  <4F6B6F05.2000903@ericsson.com>  <4F6B9206.2050304@alum.mit.edu>  <4F6B9CC4.7000208@digium.com> <4F6B9D88.5060804@ericsson.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Thu, 22 Mar 2012 22:58:54 +0100
Message-ID: 
To: Salvatore Loreto ,  "Kevin P. Fleming" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnyp5JLKkGMLfLNXqaWeLzOic9GAvl1+6HdRMJI0NfFLlFkikOgSW8J4crIKEwiiMxmp3Tw
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Mar 2012 21:59:15 -0000

2012/3/22 Salvatore Loreto :
>>> Given this SIP URI and assuming that domain.com has no SRV records:
>>>
>>> =C2=A0 =C2=A0sip:domain.com;transport=3Dws
>>>
>>> Which port should be the default for the WS transport? 5060 (so
>>> conflict with SIP TCP)? or 80 (so the associated WebSocket URI would
>>> become ws://domain.com)?
>>
>> Since WebSocket is specified to operate over HTTP, I would expect port
>> 80 to be the default for that URI. Port 443 would be the default for a
>> secure WebSocket SIP URI.
>>
> that was also my expectation ...

Then the draft should state, in the section "7. Locating a SIP Server":

-----------
In the abscense of SRV records or an explicit port in a SIP URI with
;transport=3Dws, the default port to be contacted is 80 in case of sip
schema and 443 in case of sips schema.
-----------

Is it ok? If so it will be added to the next version.

Thanks a lot.
--=20
I=C3=B1aki Baz Castillo


From victor.pascual.avila@gmail.com  Fri Mar 23 02:47:28 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D5B21F84BF for ; Fri, 23 Mar 2012 02:47:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPsuPFZSD46m for ; Fri, 23 Mar 2012 02:47:27 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 70C4621F84C8 for ; Fri, 23 Mar 2012 02:47:27 -0700 (PDT)
Received: by iazz13 with SMTP id z13so5189453iaz.31 for ; Fri, 23 Mar 2012 02:47:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=3Jg4qC0soSO1/6swFiUXN2tUctHU2eJ4oF2cHFJCvmU=; b=Ybq0Dlubf+5Lg2OiT8lwcqZcFK6B8nNf9kE1BoVDH+iSkze5kvOZjaxhM1fdTmZ8wV jrVCRDvP/KKtzUgZ5lnqs5YD5XbmkElLg9MuVy6EncB7lm+Oz5+zbxiSsa/fk0hwsbpd AR5apH9Fodwcjg/44OfC8WYJEF2Dz/5uMOKlNNP5gHuKdXH5n4wxXskFB1yT+4RMtwR+ W6gS2rT8JHuYC/VfZobtJLM98tUeL8QHluog7y2aQ7u8eaPKJBpOJn7BQYUsMnoUmuzx wbAvqCi38ZS0/KmOqCn7mFJZhEzZuvCD2scxKInl9pJFv5YKNRB4//3yl2PHvOeJTPBH mOOQ==
MIME-Version: 1.0
Received: by 10.50.170.97 with SMTP id al1mr1410587igc.33.1332496047114; Fri, 23 Mar 2012 02:47:27 -0700 (PDT)
Received: by 10.231.196.72 with HTTP; Fri, 23 Mar 2012 02:47:27 -0700 (PDT)
In-Reply-To: <4F6B9CC4.7000208@digium.com>
References:  <4F68F755.8030001@ericsson.com> <4F6B3EE5.8000602@digium.com> <4F6B670D.1030309@ericsson.com>  <4F6B6F05.2000903@ericsson.com>  <4F6B9206.2050304@alum.mit.edu>  <4F6B9CC4.7000208@digium.com>
Date: Fri, 23 Mar 2012 10:47:27 +0100
Message-ID: 
From: Victor Pascual Avila 
To: "Kevin P. Fleming" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Mar 2012 09:47:28 -0000

On Thu, Mar 22, 2012 at 10:42 PM, Kevin P. Fleming  w=
rote:
> On 03/22/2012 04:02 PM, I=C3=B1aki Baz Castillo wrote:
>> Given this SIP URI and assuming that domain.com has no SRV records:
>>
>> =C2=A0 sip:domain.com;transport=3Dws
>>
>> Which port should be the default for the WS transport? 5060 (so
>> conflict with SIP TCP)? or 80 (so the associated WebSocket URI would
>> become ws://domain.com)?
>
>
> Since WebSocket is specified to operate over HTTP, I would expect port 80=
 to
> be the default for that URI. Port 443 would be the default for a secure
> WebSocket SIP URI.

I agree

-Victor

From pravindran@sonusnet.com  Fri Mar 23 03:05:24 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B62421F84F8 for ; Fri, 23 Mar 2012 03:05:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.016
X-Spam-Level: 
X-Spam-Status: No, score=-5.016 tagged_above=-999 required=5 tests=[AWL=1.583,  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 1H6OEyWl0Jn5 for ; Fri, 23 Mar 2012 03:05:20 -0700 (PDT)
Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with ESMTP id 16B4A21F8510 for ; Fri, 23 Mar 2012 03:05:11 -0700 (PDT)
Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKT2xK1mK1DcZ64QCWtrsArKzZXDFBQLoF@postini.com; Fri, 23 Mar 2012 03:05:20 PDT
Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 23 Mar 2012 06:05:26 -0400
Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Fri, 23 Mar 2012 15:35:05 +0530
From: "Ravindran, Parthasarathi" 
To: Victor Pascual Avila , "Kevin P. Fleming" 
Thread-Topic: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
Thread-Index: AQHNBuDrRK8e8RDK4k+85FBdyPDqKZZ2D36AgAAv3oCAAAMjAIAABl2AgAAgCQCAAAmyAIAAAcAAgAALDgCAAMqPgIAAX8gA
Date: Fri, 23 Mar 2012 10:05:23 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E21F959@inba-mail01.sonusnet.com>
References:  <4F68F755.8030001@ericsson.com> <4F6B3EE5.8000602@digium.com> <4F6B670D.1030309@ericsson.com>  <4F6B6F05.2000903@ericsson.com>  <4F6B9206.2050304@alum.mit.edu>  <4F6B9CC4.7000208@digium.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [121.242.142.186]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "sipcore@ietf.org" 
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Mar 2012 10:05:24 -0000

SU1PLCBVc2luZyBwb3J0IDgwLzQ0MyBhcyBkZWZhdWx0IHBvcnQgaXMgb25lIG9mIHRoZSBtYWlu
IHVzZWNhc2UgZm9yIHVzaW5nIHdlYnNvY2tldC4gU28sIEkgcHJlZmVyIDgwLzQ0My4NCg0KPi0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3Jn
IFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPkJlaGFsZiBPZiBWaWN0b3Ig
UGFzY3VhbCBBdmlsYQ0KPlNlbnQ6IEZyaWRheSwgTWFyY2ggMjMsIDIwMTIgMzoxNyBQTQ0KPlRv
OiBLZXZpbiBQLiBGbGVtaW5nDQo+Q2M6IHNpcGNvcmVAaWV0Zi5vcmcNCj5TdWJqZWN0OiBSZTog
W3NpcGNvcmVdIFJldmlldyBkcmFmdC1pYmMtc2lwY29yZS1zaXAtd2Vic29ja2V0LTAxDQo+DQo+
T24gVGh1LCBNYXIgMjIsIDIwMTIgYXQgMTA6NDIgUE0sIEtldmluIFAuIEZsZW1pbmcNCj48a3Bm
bGVtaW5nQGRpZ2l1bS5jb20+IHdyb3RlOg0KPj4gT24gMDMvMjIvMjAxMiAwNDowMiBQTSwgScOx
YWtpIEJheiBDYXN0aWxsbyB3cm90ZToNCj4+PiBHaXZlbiB0aGlzIFNJUCBVUkkgYW5kIGFzc3Vt
aW5nIHRoYXQgZG9tYWluLmNvbSBoYXMgbm8gU1JWIHJlY29yZHM6DQo+Pj4NCj4+PiDCoCBzaXA6
ZG9tYWluLmNvbTt0cmFuc3BvcnQ9d3MNCj4+Pg0KPj4+IFdoaWNoIHBvcnQgc2hvdWxkIGJlIHRo
ZSBkZWZhdWx0IGZvciB0aGUgV1MgdHJhbnNwb3J0PyA1MDYwIChzbw0KPj4+IGNvbmZsaWN0IHdp
dGggU0lQIFRDUCk/IG9yIDgwIChzbyB0aGUgYXNzb2NpYXRlZCBXZWJTb2NrZXQgVVJJIHdvdWxk
DQo+Pj4gYmVjb21lIHdzOi8vZG9tYWluLmNvbSk/DQo+Pg0KPj4NCj4+IFNpbmNlIFdlYlNvY2tl
dCBpcyBzcGVjaWZpZWQgdG8gb3BlcmF0ZSBvdmVyIEhUVFAsIEkgd291bGQgZXhwZWN0IHBvcnQN
Cj4+IDgwIHRvIGJlIHRoZSBkZWZhdWx0IGZvciB0aGF0IFVSSS4gUG9ydCA0NDMgd291bGQgYmUg
dGhlIGRlZmF1bHQgZm9yIGENCj4+IHNlY3VyZSBXZWJTb2NrZXQgU0lQIFVSSS4NCj4NCj5JIGFn
cmVlDQo+DQo+LVZpY3Rvcg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+c2lwY29yZSBtYWlsaW5nIGxpc3QNCj5zaXBjb3JlQGlldGYub3JnDQo+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo=

From christer.holmberg@ericsson.com  Fri Mar 23 06:27:40 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0EBB21F84A7 for ; Fri, 23 Mar 2012 06:27:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.156
X-Spam-Level: 
X-Spam-Status: No, score=-10.156 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OtJysRVtl-uI for ; Fri, 23 Mar 2012 06:27:40 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 15F7D21F84A6 for ; Fri, 23 Mar 2012 06:27:39 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-84-4f6c7a4a29dc
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 35.55.17856.A4A7C6F4; Fri, 23 Mar 2012 14:27:39 +0100 (CET)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.237]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Fri, 23 Mar 2012 14:27:38 +0100
From: Christer Holmberg 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Adam Roach 
Date: Fri, 23 Mar 2012 14:22:40 +0100
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
Thread-Index: Ac0IRv8cHuOoHII+RrmWZtCaYEba+gAsQaX8
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C411A5655@ESESSCMS0356.eemea.ericsson.se>
References:   <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com>  <4F6B2CC7.1040506@alum.mit.edu> <4F6B43F7.2080301@nostrum.com>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "sipcore@ietf.org" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 23 Mar 2012 13:27:40 -0000

Hi,

>Thanks Adam, IMHO your proposal makes lot of sense.
>
>Therefore let me make this proposal for the draft:
>
>The draft could contains two sections:
>
>
>1) Outbound Clients
>
>To be clear: web browsers and client applications (desktop,
>smartphones) running a WS client stack. These are end users so MUST
>register.
>
>- Those clients MUST implement Outbound and GRUU.

Note that I also sent some thoughts about mandating GRUU.

>- The first hop (WS) they connect to MUST also implement Outbound (it
>can be a EDGE proxy or a registrar).
>
>- In case there is an Outbound EDGE proxy between the UA and the
>registrar, should the registrar implement Outbound? IMHO it does not
>need but then it would loose some cool RFC 5626 features, but if the
>registrar honors the Path header then incoming requests (initial or
>in-dialog) would be properly routed through the Outbound EDGE proxy to
>the UA. This is a question non related to SIP WebSocket: Should the
>registrar implement Outbound? and GRUU? should we mandate both
>features for the registrar in this draft? IMHO not since it's an
>Outbound topic already covered in RFC 5626.

Again, since the registrar may not be using the SIP WS transport, it's outs=
ide the scope of the document.

But, we can (and probably should) of course say that unless the registrar s=
upports this-and-that SIP extension, things won't work.

Regards,

Christer=

From ibc@aliax.net  Fri Mar 23 06:49:39 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E8221F858E for ; Fri, 23 Mar 2012 06:49:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.625
X-Spam-Level: 
X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqgGVXalR4pn for ; Fri, 23 Mar 2012 06:49:38 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C9A3021F8463 for ; Fri, 23 Mar 2012 06:49:38 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so3400135vcb.31 for ; Fri, 23 Mar 2012 06:49:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=5ilt8N2ies8ppDlk7JVG/3modgH/ofRUtBY2opgPmCk=; b=OcuGb3FlWh8+/jYRGc8QN9mW3WNgkURn9RRqzl+1pE8yJ3WYgB4BLwtWAB5o4qUvyn F9qTSNslFXCSy+y4XDcqDnuA3Vou2EUKWwCWem0RZYwpMZmBvdUMay/qba6R1TCdrMio SHhwMoPyDIxwAzKvdMTxPxSFA8Y2pmi5CXcHhAig+uTVRoTmUIY7FlKhiR9MvT7O+WJ+ 2H7vd4xps0afyVZGod84dmg9uy054F11InLMhiJ6YjYb7acI/pkLOAwRUppqNIRQ4Xxi NWMeACIbXY5HGm0Hjqn9BQHVXaEzUW5WtQ/qLH1tSHJ6x5D6/WVZhvbDds44YJ5U2IJD Ui2Q==
Received: by 10.52.90.111 with SMTP id bv15mr5099267vdb.34.1332510577540; Fri, 23 Mar 2012 06:49:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Fri, 23 Mar 2012 06:49:15 -0700 (PDT)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C411A5655@ESESSCMS0356.eemea.ericsson.se>
References:   <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com>  <4F6B2CC7.1040506@alum.mit.edu> <4F6B43F7.2080301@nostrum.com>  <7F2072F1E0DE894DA4B517B93C6A05852C411A5655@ESESSCMS0356.eemea.ericsson.se>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Fri, 23 Mar 2012 14:49:15 +0100
Message-ID: 
To: Christer Holmberg 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQm69FJI2IDL1aCYnNkQrA0Kef1pxXVSMMO3EDeUSiVthIdgXk/CTEKTLAyW0nRFt+ddLwjl
Cc: "sipcore@ietf.org" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 23 Mar 2012 13:49:39 -0000

2012/3/23 Christer Holmberg :
> Note that I also sent some thoughts about mandating GRUU.
> [...]
> Again, since the registrar may not be using the SIP WS transport, it's ou=
tside the scope of the document.
>
> But, we can (and probably should) of course say that unless the registrar=
 supports this-and-that SIP extension, things won't work.

Right. Note that the draft is supposed to define a new SIP transport.
It can, of course, describe which other specifications are required in
certain scenarios in order things to work. The GRUU issue you describe
also applies to a SIP TCP/TLS client behind NAT using Outbound, it's
not a new issue/limitation.

So IMHO there is some consensus that the draft needs to cover the
Outbound/GRUU case in a separate section, a section describing which
requirements are needed for a common WS SIP client to properly work
along with the requirements needed in its proxy/registrar.

Regards.

--=20
I=C3=B1aki Baz Castillo


From ibc@aliax.net  Sat Mar 24 07:55:31 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7E321F86C4 for ; Sat, 24 Mar 2012 07:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.626
X-Spam-Level: 
X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.051,  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 eXxjzTtrEUgN for ; Sat, 24 Mar 2012 07:55:31 -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 CCB2321F86C2 for ; Sat, 24 Mar 2012 07:55:30 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so4216669vcb.31 for ; Sat, 24 Mar 2012 07:55:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ry/YogPmTDmrl2y0q8f57EtzTy9OUj9yDFF5Zpiconk=; b=dLAg58bVoIFCT9DexmhADOy/jLJmDuL/tCxSo9FZ3j8M3ChHxiQRNA+TY4oqXmAoiv N6Zsre5QXTHq+n1WyXweInLKjFIzfalEb7mYiaK1zOZnCHl7YkF66gEXD2HdcGq4a2bl TBrh/bERICnj4DPic/VgWp8O8S9gHZAJ16sCe/guhJhzBj15O+8tx2/FaEr1SDlU91x0 dwL09pduDmVtlOSXHoI4Y6Jhk7MMCr5ujQ6QoA9nVUSMo1NL4KPvTHDoyJs85Li1Z8TL +8bcuQWU5oU06MfgV/iFAe7Ny6iokcxrk3xBdSTPGuYcH5nejhnBxFoUN6sXM/jnARjf JfxQ==
Received: by 10.52.24.49 with SMTP id r17mr4101687vdf.51.1332600930169; Sat, 24 Mar 2012 07:55:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Sat, 24 Mar 2012 07:55:09 -0700 (PDT)
In-Reply-To: <4F68F755.8030001@ericsson.com>
References:  <4F68F755.8030001@ericsson.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Sat, 24 Mar 2012 15:55:09 +0100
Message-ID: 
To: Salvatore Loreto 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlhm8RFtruiAxNG7bmbKyJgo+mCexAqkQiOtD3omai4FjxZBRCGFWEGkdCKQDa5D2i8QE79
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Mar 2012 14:55:31 -0000

Salvatore Loreto  said:
> Hi there,
>
> here my preliminary review.
> I will avoid all the stuff already listed by Alan and Kevin reviews.
>
> I do think this draft is really important, so I look forward to this work
> progressing.


Thank a lot you for your review Salvatore.

Some of the aspects you comment (mainly those related to Outbound and
keepalive) have been already covered in other threads so we'll focus
in other topics of your review:




> ---review---
>
> Section 3
>
> second paragraph:
> -it would be worth to clarify that the handshake is based on
> an HTTP Upgrade request transported in a GET method so to make clear
> that the handshake upgrades the connection from HTTP to
> WebSocket/Sub-Protocol

Section 3 already says that the Websocket connection handshake is
based on HTTP GET request. Saying that the handshake upgrades the
conection from HTTP to WebSocket could be clarifying. Good point.



> Section 4
>
> this section does not say anything for wss:// (i.e. encrypted connection)=
.
> Reading the section I got the wrong impression that the SIP subprotocol w=
ill
> run always on a unencrypted connection.

Section 4 just defines a new WebSocket Subprotocol Identifier which is
'sip' regardless the connection being used in the handshake is HTTP or
HTTPS (HTTP-over-TLS). Maybe we could mention in section 3 the fact
that the WebSocket handshake can be carried on top of HTTP or HTTPS?




> Section 5.2
>
> you have forgotten to list the "wss"

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

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




> Section 6
>
> I don't get the need for Outbound ... to be clear the Keep-alive techniqu=
e defined in Outbound, (however I see the need for the rest of things defin=
ed in that RFC)
> We are talking of a WebSocket client that will contact a WebSocket server=
 and in the Web architecture the server is always available on a public IP.=
..
> Are you trying to define here some extension to the WebSocket protocol as=
 such or what?
> In the new HyBi charter there is a work item about
>
> Timeout-handling capabilities
>
> that should be help you

The "need" for Keep-alive technique defined in Outbound (note that
it's not a MUST in the new proposal) is due the fact that in some
WebSocket implementations (i.e. web browsers) the application layer
(JavaScript) has no control over the WebSocket Ping/Pong mechanism. In
fact, sobre browsers send periodic WS Ping frames once the connection
is done, but maybe some others do not. So the application layer has no
way to know whether its WebSocket stack is mantaining the connection
open by sending WS Ping, neither it knows whether the WS server is
sending WS Ping frames to the client. Therefore, the application layer
(JavaScript) MAY decide to perform SIP keep-alive techniques. For
that, the JavaScript application would send to the server periodic
WebSocket messages containing double CRLF (SIP TCP keepalive) and the
server would reply a WebSocket message containing a single CRLF.

Of course, in case "Timeout-handling capabilities" in WebSocket allows
the application layer to control the keepalive, then the application
could choose to use it.




> Section 7
>
> the section mandate the usage RFC3263, however it does not say anything h=
ow the WebSocket client will also at the same time stay compliant to the sa=
me-origin policy

We assume that the Origin policy is out of the scope of this
specification since it basically involves web scenarios and we propose
a non specific scope for the SIP WebSocket transport. Maybe that could
make sense within a "Guidelines" Appendix? Note however that the HTTP
origin policy is just valid for web browsers.




> Section 8
>
>       Based on local policy, this might occur once the JavaScript SIP
>       application has been downloaded from the web server, or when the
>       SIP user using the web browser application registers itself to a
>       SIP registrar (assuming that SIP requests cannot be sent or
>       received before then).
>
>
> it is not clear from the above paragraph, but also the registration will
> happen over a WebSocket connection, isn't it?

Yes, the text you mention will be improved. We just attempt to state
that the WebSocket connection must be done before the SIP usage.




> 9.1. SIP Proxy Considerations
>
>    When a SIP proxy bridges WebSocket and any other SIP transport
>    (including WebSocket transport) it MUST perform Loose Routing as
>    specified in [RFC3261].
>
>
> it is not clear to me how a SIP proxy can bridge a WebSocket request:
> WebSocket connection go on to of an Upgraded HTTP connection
> between the WebSocket client and the WebSocket client...
> this connection can eventually pass through a HTTP Proxy but for sure
> not a SIP proxy

Maybe the text is not clear enough. It does not mean "bridging a
WebSocket handshake and any other SIP transport", it wants to mean
"bridging *SIP* WebSocket *transport* and any other SIP transport".
Would this correction make it easier to understand? As said in other
mail, the SIP proxy/server would include a WebSocket server interface
within its SIP stack, in the same way it has an UDP/TCP/TLS-TCP/SCTP
interface.




> 10. Connection Keep Alive
>
> it would be worth to eventually reuse the mechanism the HyBi wg is suppos=
e
> to standardize to do Keep-Alive...

Sure but we understand that such a new mechanism is not a standard
yet, am I wrong? What about if we mention that the WS SIP client could
use any keep-alive mechanism defined (or to be defined) for the
WebSocket protocol?




> more
>
>    The client application MAY also use Network Address Translation (NAT)
>    keep-alive mechanisms defined for the SIP protocol, such as the CRLF
>    Keep-Alive Technique mechanism described in [RFC5626] section=C2=A03.5=
.1.
>
> as stated above I doubt that can be done by a WebSocket client.

We mean that it can be done by the application layer (i.e.
JavaScript). This would just involve sending a WebSocket message
containing a double CRLF and receiving, from the SIP proxy/server, a
WebSocket message containing a single CRLF.



Really thanks a lot for your input.


--=20
I=C3=B1aki Baz Castillo


From HKaplan@acmepacket.com  Sun Mar 25 02:18:48 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77FF21F8458 for ; Sun, 25 Mar 2012 02:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.512
X-Spam-Level: 
X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087,  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 sVSjr84eIr92 for ; Sun, 25 Mar 2012 02:18:48 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id A943421F8453 for ; Sun, 25 Mar 2012 02:18:47 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 25 Mar 2012 05:18:45 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Sun, 25 Mar 2012 05:18:45 -0400
From: Hadriel Kaplan 
To: Adam Roach 
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
Thread-Index: AQHNCmhHWS60Xsq9LE23pof42tzzJg==
Date: Sun, 25 Mar 2012 09:18:44 +0000
Message-ID: <4C77AE98-1166-429E-8F6C-09A2F4774CB4@acmepacket.com>
References:   <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41457411@ESESSCMS0356.eemea.ericsson.se>   <7F2072F1E0DE894DA4B517B93C6A05852C41457505@ESESSCMS0356.eemea.ericsson.se>  <4F6A4637.5000407@ericsson.com>  <4F6B149E.60403@ericsson.com>  <4F6B2CC7.1040506@alum.mit.! edu> <4F6B43F7.2080301@nostrum.com>
In-Reply-To: <4F6B43F7.2080301@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <61419732D4378543A073FD791E5ABBD6@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 25 Mar 2012 09:18:48 -0000

On Mar 22, 2012, at 11:23 AM, Adam Roach wrote:

> [as an individual]
>=20
> On 3/22/12 08:44, Mar 22, Paul Kyzivat wrote:
>> On 3/22/12 8:34 AM, I=F1aki Baz Castillo wrote:
>>>=20
>>> So I would like to ask to the SIPCORE WG: should the draft consider
>>> that hypothetical case? or shoult it assume that there could exist SIP
>>> entities capable of initiating and receiving WS connections?
>>=20
>> I'm generally a believer in generality and completeness, which inclines =
me to support considering this.
>>=20
>> BUT, before going far down that track I would like to have a good unders=
tanding of what that means, the implications and limitations, etc. And whet=
her there is enough interest in pursuing it.
>=20
> I think what I'd prefer to see is that the current work does nothing to p=
reclude the definition of such a set of behaviors in the future, but that w=
e don't necessarily spend any work on it right now. It does seem highly the=
oretical (I can't imagine why a proxy-to-proxy link would use websockets in=
stead of TCP), and it nearly doubles the complexity of what we would need t=
o consider and define. But I do understand the desire for (and frequently a=
dvocate for) allowing behaviors for unforeseen circumstances -- that's wher=
e innovation is born.
>=20
> So, for the current work, I believe it would make sense to define the beh=
avior for a WS transport between a UA (one that cannot listen for connectio=
ns) and its first hop into the network. It would probably be worth explicit=
ly calling out in the document that we don't currently define behavior for =
inter-intermediary websockets connections or for clients with the ability t=
o listen for inbound connections, but that future documents may choose to d=
o so.

Yeah I think this proxy-proxy thing is my fault, as I commented in an early=
 review of the older original draft that websocket was just a new transport=
 so why was it specific to the system-type, and that instead it shouldn't p=
reclude proxy-proxy/whatever, even if no one ever used it that way.  At the=
 time I didn't think about the complexities this would introduce, and it's =
definitely such a non-use-case it should be ignored for now and instead be =
specific to the SIP role.=20

-hadriel


From HKaplan@acmepacket.com  Sun Mar 25 02:55:24 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C27A21F8568 for ; Sun, 25 Mar 2012 02:55:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.365
X-Spam-Level: 
X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 R3AxGotwDpY0 for ; Sun, 25 Mar 2012 02:55:23 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA8221F8566 for ; Sun, 25 Mar 2012 02:55:23 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 25 Mar 2012 05:55:22 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Sun, 25 Mar 2012 05:55:22 -0400
From: Hadriel Kaplan 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
Thread-Index: AQHNCm1kXneVMmmKf0md0IxQDIG00Q==
Date: Sun, 25 Mar 2012 09:55:21 +0000
Message-ID: <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 09:55:24 -0000

On Mar 21, 2012, at 5:01 PM, I=F1aki Baz Castillo wrote:

> 2012/3/21 Christer Holmberg :
>> So, that is the classical transfer use-case, for which GRUU was more or =
less originally defined, right?
>>=20
>> But, that applies also to other transports, so is there some SIP WS spec=
ific reason why we would generally mandate GRUU?
>>=20
>> When Alice registers her contact, no matter whether it's a GRUU or not, =
the WS server will need to maintain a mapping between the registered contac=
t and the associated WS connection, in order to route incoming calls toward=
s Alice.
>>=20
>> And, as for outbound, keep in mind that the registrar may not support GR=
UU :)
>=20
> Right. The fact is that we don't want to mandate GRUU (not at least in
> the last proposal suggested in the mail you reply to). We just suggest
> that for common scenarios in which Outbound is required, GRUU is also
> required (but as you say, this is the exact case as for a SIP TCP
> client behind NAT).
> In both cases (a SIP TCP client behind NAT or common SIP WS client)
> the same Outbound/GRUU requirements are needed, so we consider that
> this is not something to be mandated by the draft (it could be
> explained in an "Implementation Guidelines" Appendix however).

I don't follow how you got to the conclusion that if Outbound is required, =
GRUU is required.
GRUU is not necessary for Outbound to work, nor is it required by the Outbo=
und RFC as far as I know.  Nor does it appear a websocket connection would =
require GRUU.

Just to be clear, when I say "GRUU" I mean a Globally Routable UA URI, per =
RFC 5627.  As far as I can tell, there are surprisingly few domains that tr=
uly support a Globally Routable UA URI, no matter what syntax tokens they u=
se in a Contact URI.

-hadriel


From HKaplan@acmepacket.com  Sun Mar 25 02:57:50 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D1021F858A for ; Sun, 25 Mar 2012 02:57:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level: 
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086,  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 lABvXYC5S07u for ; Sun, 25 Mar 2012 02:57:50 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4D621F8581 for ; Sun, 25 Mar 2012 02:57:50 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 25 Mar 2012 05:57:49 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Sun, 25 Mar 2012 05:57:49 -0400
From: Hadriel Kaplan 
To: "Kevin P. Fleming" 
Thread-Topic: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
Thread-Index: AQHNCm27UG4D8PpPYUasf8g2JST+Ew==
Date: Sun, 25 Mar 2012 09:57:48 +0000
Message-ID: 
References:  <4F68F755.8030001@ericsson.com> <4F6B3EE5.8000602@digium.com> <4F6B670D.1030309@ericsson.com>  <4F6B6F05.2000903@ericsson.com>  <4F6B9206.2050304@alum.mit.edu>  <4F6B9CC4.7000208@digium.com>
In-Reply-To: <4F6B9CC4.7000208@digium.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <9500FA1A3AD6D5409FEB86274C6C2958@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" 
Subject: Re: [sipcore] Review draft-ibc-sipcore-sip-websocket-01
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 09:57:50 -0000

On Mar 22, 2012, at 5:42 PM, Kevin P. Fleming wrote:

> Since WebSocket is specified to operate over HTTP, I would expect port 80=
 to be the default for that URI. Port 443 would be the default for a secure=
 WebSocket SIP URI.

Indubitably.

-hadriel


From ibc@aliax.net  Sun Mar 25 05:15:27 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADA821F8484 for ; Sun, 25 Mar 2012 05:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.626
X-Spam-Level: 
X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=0.051,  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 XVCEVJh818Xj for ; Sun, 25 Mar 2012 05:15: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 B65E721F8483 for ; Sun, 25 Mar 2012 05:15:26 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so4549883vcb.31 for ; Sun, 25 Mar 2012 05:15:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=5snwF5IIECe1Hyu35QlhS9CYnpGpLavpzqsSULcrPXo=; b=CuMRXkh7yZIPkS50v3awSCfwOYI/MP7w2Wl7piQtWzLhKkbNHB0jRutO91WfOSmlCk KeKwnjiYFstLGWGG3fYXNqtqunjnknLe7KcDy8vlV2lb0azgyYsFUST6ppALUTRrRD+A byDxftGOXdMc1bRXIGxml7Vdz0Y2OLljnz0oo4t0+Fqa3pgrBC+mUUEL7WHiH4HcTOq9 qm0jcnx7qDB8w0+Nki9lD3uxq3bklBprdfLYSlWeJPhIQwaAYNoRMk673HvV7J4puFQV qAnsXaG2WahlhNTfhba1EVLRFYJiC6O43Du1gAIRwoknUXcvXmDEMiZgUVcuzApcDzQu d/uA==
Received: by 10.220.157.7 with SMTP id z7mr3639492vcw.2.1332677726222; Sun, 25 Mar 2012 05:15:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Sun, 25 Mar 2012 05:15:05 -0700 (PDT)
In-Reply-To: <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Sun, 25 Mar 2012 14:15:05 +0200
Message-ID: 
To: Hadriel Kaplan 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmPFDCy5KTSBgGNJGBFVxT/6IWeXxEO9WxwuCmUFfqh/ZjIUuTWMHZVQdtZIeg1+ZqlrDK1
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 12:15:27 -0000

2012/3/25 Hadriel Kaplan :
> I don't follow how you got to the conclusion that if Outbound is required=
, GRUU is required.
> GRUU is not necessary for Outbound to work, nor is it required by the Out=
bound RFC as far as I know. =C2=A0Nor does it appear a websocket connection=
 would require GRUU.

Hi Hadriel, an already given example:

- Alice (WS SIP UA) is in a call with Bob (SIP UDP UA).
- Bob sends a REFER to Carol (SIP UDP UA) with "Refer-To: ALICE_CONTACT_URI=
".
- Carol sends an INVITE to ALICE_CONTACT_URI.

The only way in which the INVITE can arrive to Alice is the case in
which ALICE_CONTACT_URI is a GRUU URI, so the INVITE would reach
Alice's inbound proxy/registrar and that would route the request to
Alice using the existing WebSocket connection (of course there could
be an Outbound Edge proxy between Alice and the registrar).


So, if Alice (and its registrar) does not implement GRUU then the
above scenario would fail. However please note that the above example
is exactly the SAME as in the case of Alice being a SIP TCP client
behind NAT.

The draft will not mandate GRUU but will suggest its implementation
(otherwise common scenarios as the above won't work).


Regards.


--=20
I=C3=B1aki Baz Castillo


From HKaplan@acmepacket.com  Sun Mar 25 07:51:36 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6446921F84E4 for ; Sun, 25 Mar 2012 07:51:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.365
X-Spam-Level: 
X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=-0.066, 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 Sn2Cl3IB16pg for ; Sun, 25 Mar 2012 07:51:36 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id C0ECA21F84D9 for ; Sun, 25 Mar 2012 07:51:35 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 25 Mar 2012 10:51:22 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Sun, 25 Mar 2012 10:51:22 -0400
From: Hadriel Kaplan 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
Thread-Index: AQHNCpa+QuM0Qz8BoUOs48H5NdsyGg==
Date: Sun, 25 Mar 2012 14:51:22 +0000
Message-ID: <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 14:51:36 -0000

On Mar 25, 2012, at 8:15 AM, I=F1aki Baz Castillo wrote:

> 2012/3/25 Hadriel Kaplan :
>> I don't follow how you got to the conclusion that if Outbound is require=
d, GRUU is required.
>> GRUU is not necessary for Outbound to work, nor is it required by the Ou=
tbound RFC as far as I know.  Nor does it appear a websocket connection wou=
ld require GRUU.
>=20
> Hi Hadriel, an already given example:
>=20
> - Alice (WS SIP UA) is in a call with Bob (SIP UDP UA).
> - Bob sends a REFER to Carol (SIP UDP UA) with "Refer-To: ALICE_CONTACT_U=
RI".
> - Carol sends an INVITE to ALICE_CONTACT_URI.
> The only way in which the INVITE can arrive to Alice is the case in
> which ALICE_CONTACT_URI is a GRUU URI, so the INVITE would reach
> Alice's inbound proxy/registrar and that would route the request to
> Alice using the existing WebSocket connection (of course there could
> be an Outbound Edge proxy between Alice and the registrar).
> So, if Alice (and its registrar) does not implement GRUU then the
> above scenario would fail. However please note that the above example
> is exactly the SAME as in the case of Alice being a SIP TCP client
> behind NAT.
> The draft will not mandate GRUU but will suggest its implementation
> (otherwise common scenarios as the above won't work).

Sorry I should have been clearer... yes I know what GRUU is typically propo=
sed to be used for. :)
But it's simply not the case that you need GRUU to accomplish the above.  T=
he proof for that is the world today: few domains use real GRUUs, yet call =
transfers work all the time.

But again, I'm talking about a real GRUU.  A real GRUU is something that is=
 globally routable, meaning that in theory if anyone on the Internet got it=
 they could resolve a path to reach its represented contact instance.  What=
 many people do today instead is use a contact for Alice that is routable w=
ithin certain contexts/domains/paths.  Some times they encode such contacts=
 syntactically to appear to be GRUUs, even though they really aren't, but s=
ometimes they just encode them as contacts.  Either way, it generally works=
. (not always, mind you, but enough for the common use-cases)

-hadriel


From ibc@aliax.net  Sun Mar 25 08:06:47 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CAF21F84E2 for ; Sun, 25 Mar 2012 08:06:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.627
X-Spam-Level: 
X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhVQlju7Q8s2 for ; Sun, 25 Mar 2012 08:06:47 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC8021F84DD for ; Sun, 25 Mar 2012 08:06:46 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so2548980vbb.31 for ; Sun, 25 Mar 2012 08:06:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=au85xh8WqlINecxIl3QT3GGwHxA0LnjdZh/To0IK7WU=; b=Jp1bVjutFIr3S0hZ7eFFR7oVYfWiipiVbNV1d/5CoOxVQcTgfPulnkV5OKrU4LzQrp 4hKTEt3srmcwySAGp884L5SGnv9N08WqY75U3Xvba8Ow2mQrrjznwuftM0QfbRruKITH RUGQXmtrdD1ckc0jOKo3N/EUSSolA7TArr1jLo6caWlmdYkZaFRRmW9mvVsTASV0V9eW Qwt7A4ibTzltznV9InxaJnxWnTjhTtMuCczwKBl4sgCvmGL6jVm4y+9geXhWRKYlqjvt ypR+HXAKZ90C8CHKADWW6llfTFwG579dxAe8OuIVMadcQPeYwJmzyiLoJdO28ufYqn5Y lZnA==
Received: by 10.52.27.1 with SMTP id p1mr8184747vdg.17.1332688006126; Sun, 25 Mar 2012 08:06:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Sun, 25 Mar 2012 08:06:26 -0700 (PDT)
In-Reply-To: <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Sun, 25 Mar 2012 17:06:26 +0200
Message-ID: 
To: Hadriel Kaplan 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQndoh13ONOKn3K7Z1Qc1H5HkKns0ZXQy3xoHJXGypdhHqR1ODrsaQszFE2ii7T1qmnWfhfQ
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 15:06:47 -0000

2012/3/25 Hadriel Kaplan :
> Sorry I should have been clearer... yes I know what GRUU is typically pro=
posed to be used for. :)
> But it's simply not the case that you need GRUU to accomplish the above. =
=C2=A0The proof for that is the world today: few domains use real GRUUs, ye=
t call transfers work all the time.
>
> But again, I'm talking about a real GRUU. =C2=A0A real GRUU is something =
that is globally routable, meaning that in theory if anyone on the Internet=
 got it they could resolve a path to reach its represented contact instance=
. =C2=A0What many people do today instead is use a contact for Alice that i=
s routable within certain contexts/domains/paths. =C2=A0Some times they enc=
ode such contacts syntactically to appear to be GRUUs, even though they rea=
lly aren't, but sometimes they just encode them as contacts. =C2=A0Either w=
ay, it generally works. (not always, mind you, but enough for the common us=
e-cases)

Hi Hadriel.

Both Outbound and GRUU are specs from 2009, many years after real SIP
TCP behind NAT exist, and of course vendors have made their own NAT
solution/workarounds during those years. But AFAIK we cannot /
should-not make a new spec assuming those workarounds, not when we
already have RFC 5626 and 5627 to cover those cases.

Regards.

--=20
I=C3=B1aki Baz Castillo


From christer.holmberg@ericsson.com  Sun Mar 25 08:47:32 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2FE421F84F4 for ; Sun, 25 Mar 2012 08:47:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.157
X-Spam-Level: 
X-Spam-Status: No, score=-10.157 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kMdaFSIBgSK for ; Sun, 25 Mar 2012 08:47:31 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id C2B2721F84E6 for ; Sun, 25 Mar 2012 08:47:30 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-b3-4f6f3e110817
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 33.8F.17856.11E3F6F4; Sun, 25 Mar 2012 17:47:29 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 25 Mar 2012 17:47:28 +0200
From: Christer Holmberg 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= , Hadriel Kaplan 
Date: Sun, 25 Mar 2012 17:43:10 +0200
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
Thread-Index: Ac0KgPZIjovQbRJdRQ2RXi/lJs2TGQAHQU7Y
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C428E2F48@ESESSCMS0356.eemea.ericsson.se>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 15:47:32 -0000

Hi,

>> I don't follow how you got to the conclusion that if Outbound is require=
d, GRUU is required.
>> GRUU is not necessary for Outbound to work, nor is it required by the Ou=
tbound RFC as far as I know.  Nor does it appear a websocket connection wou=
ld require GRUU.
>
>Hi Hadriel, an already given example:
>
>- Alice (WS SIP UA) is in a call with Bob (SIP UDP UA).
>- Bob sends a REFER to Carol (SIP UDP UA) with "Refer-To: ALICE_CONTACT_UR=
I".
>- Carol sends an INVITE to ALICE_CONTACT_URI.
>
>The only way in which the INVITE can arrive to Alice is the case in
>which ALICE_CONTACT_URI is a GRUU URI, so the INVITE would reach
>Alice's inbound proxy/registrar and that would route the request to
>Alice using the existing WebSocket connection (of course there could
>be an Outbound Edge proxy between Alice and the registrar).

I don't think that is true.

The edge proxy needs to associated Alice's registered contact with the WS c=
onnection, but that contact doesn't have to be a GRUU.

>So, if Alice (and its registrar) does not implement GRUU then the
>above scenario would fail. However please note that the above example
>is exactly the SAME as in the case of Alice being a SIP TCP client
>behind NAT.

Exactly.

>The draft will not mandate GRUU but will suggest its implementation
>(otherwise common scenarios as the above won't work).

I don't think it should suggest that. The GRUU RFC should (and does so) spe=
cify why GRUU is needed.

Regards,

Christer=

From ibc@aliax.net  Sun Mar 25 08:56:20 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF5B21F84F0 for ; Sun, 25 Mar 2012 08:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.328
X-Spam-Level: 
X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=-0.251, 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 0lR4Cj-BMs4r for ; Sun, 25 Mar 2012 08:56:19 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9440121F84E7 for ; Sun, 25 Mar 2012 08:56:19 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so2562077vbb.31 for ; Sun, 25 Mar 2012 08:56:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=mQo8reoJxvHG2PASO0p+PPDiPNYH7MfVYg0wkfltXbM=; b=FnQeJOJ5cOq0mFHKK5Vc0rL1CJrX2IQRXKqM/Y4Ao/TgC1wjEBKftA5OzFoBDwzqKK atG3UIkaxKR42+c3fNqqghzB3VoeJv2ivtZ3dGZudsbeuVqPRiR0IGWFi4aTXMCzkJFN SAOvXvI4QZ5wQAwU/MDigw4JK8fJrg0cqgwbfMqRFqnrSgoYj5LqpRoUCLTGxIcDJg0Z qaZ6zcYxW41kA7qUFOAEyXuj51cNDo/vTUP4dfHdrcAhihDQIYJ40ZpMbh8gYPbVV3/p gVICo/KRpzYEiUPZOmFyuqzIssZvCM4aI7BFpWLhCkot6DxoblcEM1hBjSXNtGrdmQG5 PkqA==
Received: by 10.52.90.111 with SMTP id bv15mr8071685vdb.34.1332690978973; Sun, 25 Mar 2012 08:56:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Sun, 25 Mar 2012 08:55:58 -0700 (PDT)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C428E2F48@ESESSCMS0356.eemea.ericsson.se>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F48@ESESSCMS0356.eemea.ericsson.se>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Sun, 25 Mar 2012 17:55:58 +0200
Message-ID: 
To: Christer Holmberg 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQntnf4box1uhkXCJY7ZddIeWTcbzYZt4D+kXDmkmWVqG0BJizMnj3wqabfNww3bnHkUOduD
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 15:56:20 -0000

2012/3/25 Christer Holmberg :
>>Hi Hadriel, an already given example:
>>
>>- Alice (WS SIP UA) is in a call with Bob (SIP UDP UA).
>>- Bob sends a REFER to Carol (SIP UDP UA) with "Refer-To: ALICE_CONTACT_U=
RI".
>>- Carol sends an INVITE to ALICE_CONTACT_URI.
>>
>>The only way in which the INVITE can arrive to Alice is the case in
>>which ALICE_CONTACT_URI is a GRUU URI, so the INVITE would reach
>>Alice's inbound proxy/registrar and that would route the request to
>>Alice using the existing WebSocket connection (of course there could
>>be an Outbound Edge proxy between Alice and the registrar).
>
> I don't think that is true.

And what is supposed to set as "routable Contact" a JavaScript
application which is not capable of knowing neither its private/public
IP:port from which the WS connection is established?


> The edge proxy needs to associated Alice's registered contact with the WS=
 connection, but that contact doesn't have to be a GRUU.

IMHO you are defining a behavior that is not define anywhere, in any RFC.

Please review the example above in which Carol receives the REFER from
Bob (with "Refer-To: ALICE_CONTACT") and has to send an INVITE to that
URI ALICE_CONTACT. If such a URI is createdt by the WS SIP client then
the INVITE won't arrive. The Outbound proxy should NOT alter such a
Contact URI. Therefore the only way for that INVITE to arrive is when
it's a GRUU URI, so the INVITE arrives to the registrar of Alice's
domain and the registrar routes it throught the Outbound proxy (with a
Route header containing the Outbound id added in the Path header
during Alice's registration).



>>The draft will not mandate GRUU but will suggest its implementation
>>(otherwise common scenarios as the above won't work).
>
> I don't think it should suggest that. The GRUU RFC should (and does so) s=
pecify why GRUU is needed.

And the above usecase is an example, am I wrong? If not please explain
how to make the above scenario to work without Contact mangling in an
intermediary proxy/registrar.


Regards.


--=20
I=C3=B1aki Baz Castillo


From christer.holmberg@ericsson.com  Sun Mar 25 09:13:36 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDD821F84D9 for ; Sun, 25 Mar 2012 09:13:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.158
X-Spam-Level: 
X-Spam-Status: No, score=-10.158 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3TrnsP2f-Wq for ; Sun, 25 Mar 2012 09:13:36 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id BAC5621F844F for ; Sun, 25 Mar 2012 09:13:35 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-45-4f6f442eae89
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 90.01.17856.E244F6F4; Sun, 25 Mar 2012 18:13:34 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sun, 25 Mar 2012 18:13:34 +0200
From: Christer Holmberg 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
Date: Sun, 25 Mar 2012 18:13:34 +0200
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
Thread-Index: Ac0Kn9JIN9shXCxNTli7nSPYhaI5igAATRHR
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4A@ESESSCMS0356.eemea.ericsson.se>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F48@ESESSCMS0356.eemea.ericsson.se>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 16:13:36 -0000

Hi,

>>>- Alice (WS SIP UA) is in a call with Bob (SIP UDP UA).
>>>- Bob sends a REFER to Carol (SIP UDP UA) with "Refer-To: ALICE_CONTACT_=
URI".
>>>- Carol sends an INVITE to ALICE_CONTACT_URI.
>>>
>>>The only way in which the INVITE can arrive to Alice is the case in
>>>which ALICE_CONTACT_URI is a GRUU URI, so the INVITE would reach
>>>Alice's inbound proxy/registrar and that would route the request to
>>>Alice using the existing WebSocket connection (of course there could
>>>be an Outbound Edge proxy between Alice and the registrar).
>>
>> I don't think that is true.
>
>And what is supposed to set as "routable Contact" a JavaScript
>application which is not capable of knowing neither its private/public
>IP:port from which the WS connection is established?

The only way anyone is going to reach Alice is by using the WS connection t=
hat Alice has established (based on the assumption that Alice is a WS clien=
t, and does not listen for incomming WS connections).

>> The edge proxy needs to associated Alice's registered contact with the W=
S connection, but that contact doesn't have to be a GRUU.
>
>IMHO you are defining a behavior that is not define anywhere, in any RFC.

Again, even if Alice registers a GRUU, Alice can only be reached using the =
WS connection. So, the edge proxy needs to associate the WS connection with=
 the registered contact.

So, the INVITE from Carol needs to reach the edge proxy, which forwards it =
on the WS connection to Alice.=20

Right?





> Please review the example above in which Carol receives the REFER from
> Bob (with "Refer-To: ALICE_CONTACT") and has to send an INVITE to that
> URI ALICE_CONTACT. If such a URI is createdt by the WS SIP client then
> the INVITE won't arrive. The Outbound proxy should NOT alter such a
> Contact URI.=20

I have not said that the proxy would alter/modify the contact.=20

I have only said that it needs to remember which WS connection the contact =
is associated with.

> Therefore the only way for that INVITE to arrive is when
> it's a GRUU URI, so the INVITE arrives to the registrar of Alice's
> domain and the registrar routes it throught the Outbound proxy (with a
> Route header containing the Outbound id added in the Path header
> during Alice's registration).

When the INVITE reaches Alice's registrar, the proxy needs to forward it to=
 the edge proxy, which then forwards it to Alice. The R-URI contains the re=
gistered contact of Alice, which the edge proxy uses to find the WS conntac=
t to Alice - no matter if the contact is a GRUU or not.



>>>The draft will not mandate GRUU but will suggest its implementation
>>>(otherwise common scenarios as the above won't work).
>>
>> I don't think it should suggest that. The GRUU RFC should (and does so) =
specify why GRUU is needed.
>
> And the above usecase is an example, am I wrong? If not please explain
> how to make the above scenario to work without Contact mangling in an
> intermediary proxy/registrar.

I've tried to explain :)

I guess a whiteboard would help in this discussion... :)


Regards,

Christer=

From ibc@aliax.net  Sun Mar 25 09:23:46 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 907B521F8417 for ; Sun, 25 Mar 2012 09:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.625
X-Spam-Level: 
X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZCJRl4lpmqF for ; Sun, 25 Mar 2012 09:23:46 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D4DC221F845C for ; Sun, 25 Mar 2012 09:23:45 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so2569329vbb.31 for ; Sun, 25 Mar 2012 09:23:45 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=PflAsKPJqBuJNXowMH1qTIdEActbWaqlSjsdnKZwt5o=; b=pc82F+6taAYc9zEaGvYRWbhZGB2xm8Ka+73s35WUfIS6aCgtGHFRUkR6nj3JYD60PL +vs2Uk8Qrr+lt5e+pIxqv1GtTWIuCGvHn2q/Fpd1xzFk/e3C0ANj1tZruvUmwjrE/Okh OFnHWye4bdMwr8IiSmw3o3Vz6/jnjv4dTQAtiaZ1Bg9oFctjUciZUDEEpBrXAnA8325E 5EKYD8dc94S7+AdJ2y8r9AAIr+1qwbWfDRba5oGBEH6lWtnZaGl2B13prdNtTkc78OPt b9VZnbN/L9Dva3tw3bf8zhBh5hc4YiikvjMOa7th77U3o75qwzSB0kT9VFpWJT92OL3o F2Cw==
Received: by 10.52.27.1 with SMTP id p1mr8259009vdg.17.1332692625338; Sun, 25 Mar 2012 09:23:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Sun, 25 Mar 2012 09:23:25 -0700 (PDT)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4A@ESESSCMS0356.eemea.ericsson.se>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F48@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4A@ESESSCMS0356.eemea.ericsson.se>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Sun, 25 Mar 2012 18:23:25 +0200
Message-ID: 
To: Christer Holmberg 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQmqJuavyHAhylZB8Wh/u6JCpOxzkj7HN7GZm1z9uDAFZc9598iHKtmS1VVVNNXLiXuW5uqy
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 16:23:46 -0000

Hi Christer, first of all I would like to make clear that we leave
GRUU out of the scope of the draft. :)

Comments inline:


2012/3/25 Christer Holmberg :
>>And what is supposed to set as "routable Contact" a JavaScript
>>application which is not capable of knowing neither its private/public
>>IP:port from which the WS connection is established?
>
> The only way anyone is going to reach Alice is by using the WS connection=
 that Alice has established (based on the assumption that Alice is a WS cli=
ent, and does not listen for incomming WS connections).

Right, but I repeat: if the WS client is a web browser, then it does
not know its local IP and port from which it has established the WS
connection, so that URI is "useless". If your suggestion means that
the outbound proxy "maps" such a Contact to the real location of the
WS client, then that is not defined in any RFC, instead that would be
a proprietary solution.




>>> The edge proxy needs to associated Alice's registered contact with the =
WS connection, but that contact doesn't have to be a GRUU.
>>
>>IMHO you are defining a behavior that is not define anywhere, in any RFC.
>
> Again, even if Alice registers a GRUU, Alice can only be reached using th=
e WS connection. So, the edge proxy needs to associate the WS connection wi=
th the registered contact.

See above.





>> Please review the example above in which Carol receives the REFER from
>> Bob (with "Refer-To: ALICE_CONTACT") and has to send an INVITE to that
>> URI ALICE_CONTACT. If such a URI is createdt by the WS SIP client then
>> the INVITE won't arrive. The Outbound proxy should NOT alter such a
>> Contact URI.
>
> I have not said that the proxy would alter/modify the contact.
>
> I have only said that it needs to remember which WS connection the contac=
t is associated with.

Again see above comment :)



>> Therefore the only way for that INVITE to arrive is when
>> it's a GRUU URI, so the INVITE arrives to the registrar of Alice's
>> domain and the registrar routes it throught the Outbound proxy (with a
>> Route header containing the Outbound id added in the Path header
>> during Alice's registration).
>
> When the INVITE reaches Alice's registrar, the proxy needs to forward it =
to the edge proxy, which then forwards it to Alice. The R-URI contains the =
registered contact of Alice, which the edge proxy uses to find the WS connt=
act to Alice - no matter if the contact is a GRUU or not.

And that's not true. If we assume Outbound (and hope we do) the
Contact does NOT matter at all:

- When the WS client registers, the Outbound proxy adds a "Path:
" and such an URI is stored by the
registrar.

- When an INVITE for the AoR (or GRUU URI) of the WS client arrives to
the registrar, the registrar adds a "Route:
" to the INVITE and routes it to
PROXY_IP_PORT (the Outbound proxy).

- Then the Outbound proxy gets the OUTBOUND_ID from the Route and
routes the INVITE through the connection associated to that
OUTBOUND_ID.

This is how Outbound works. I insist: the Contact URI added by the
Outbound client does NOT matter at all. This is clearly specified in
RFC 5626 and I've implemented it ;)



Regards.


--=20
I=C3=B1aki Baz Castillo


From christer.holmberg@ericsson.com  Sun Mar 25 09:50:15 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB83921F84E2 for ; Sun, 25 Mar 2012 09:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.16
X-Spam-Level: 
X-Spam-Status: No, score=-10.16 tagged_above=-999 required=5 tests=[AWL=0.139,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQ8mMB3t5VJz for ; Sun, 25 Mar 2012 09:50:15 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id AC14421F84D9 for ; Sun, 25 Mar 2012 09:50:14 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-0b-4f6f4cc54578
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EA.4B.27041.5CC4F6F4; Sun, 25 Mar 2012 18:50:13 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0247.eemea.ericsson.se ([153.88.115.93]) with mapi; Sun, 25 Mar 2012 18:50:12 +0200
From: Christer Holmberg 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
Date: Sun, 25 Mar 2012 18:50:11 +0200
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
Thread-Index: Ac0Ko6es3F57hSnnRni/fd2p5JwcbgAAo9+s
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4B@ESESSCMS0356.eemea.ericsson.se>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F48@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4A@ESESSCMS0356.eemea.ericsson.se>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 16:50:15 -0000

Hi,

> Hi Christer, first of all I would like to make clear that we leave
> GRUU out of the scope of the draft. :)

Good :)

>>>And what is supposed to set as "routable Contact" a JavaScript
>>>application which is not capable of knowing neither its private/public
>>>IP:port from which the WS connection is established?
>>
>> The only way anyone is going to reach Alice is by using the WS connectio=
n that Alice has established (based on the assumption that Alice is a WS cl=
ient, and does not listen for incomming WS connections).
>
> Right, but I repeat: if the WS client is a web browser, then it does
> not know its local IP and port from which it has established the WS
> connection, so that URI is "useless". If your suggestion means that
> the outbound proxy "maps" such a Contact to the real location of the
> WS client, then that is not defined in any RFC, instead that would be
> a proprietary solution.

The edge proxy would have to do the mapping *even* if Alice registers a GRU=
U, because when the INVITE comes the edge proxy needs to know to which WS c=
onnection the R-URI points to.

(Of course, as described below, if outbound is used, the contact/WS mapping=
 is not needed)

>>> Therefore the only way for that INVITE to arrive is when
>>> it's a GRUU URI, so the INVITE arrives to the registrar of Alice's
>>> domain and the registrar routes it throught the Outbound proxy (with a
>>> Route header containing the Outbound id added in the Path header
>>> during Alice's registration).
>>
>> When the INVITE reaches Alice's registrar, the proxy needs to forward it=
 to the edge proxy, which then forwards it to Alice. The R-URI contains the
>> registered contact of Alice, which the edge proxy uses to find the WS co=
nntact to Alice - no matter if the contact is a GRUU or not.
>And that's not true. If we assume Outbound (and hope we do) the
>Contact does NOT matter at all:



>This is how Outbound works. I insist: the Contact URI added by the
>Outbound client does NOT matter at all. This is clearly specified in
>RFC 5626 and I've implemented it ;)

Correct - even less reason to mandate GRUU :)

Of course, when Carol sends the INVITE, using Alice's contact, the R-URI/co=
ntact has to be such that it reaches Alice's registrar in the first place. =
And, if Alice has registered multiple devices, associated with the same AOR=
, a GRUU may be needed to distinguish the correct one. BUT, again, that is =
not WebSocket specific, and is not needed in order to make SIP WebSocket tr=
ansport as such to work. It may be needed to make certain SIP use-cases to =
work, but that is outside the scope of the transport spec :)


Regards,

Christer=

From ibc@aliax.net  Sun Mar 25 12:28:47 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21ADD21F843E for ; Sun, 25 Mar 2012 12:28:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.625
X-Spam-Level: 
X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=0.052,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmGW7dUiv3ly for ; Sun, 25 Mar 2012 12:28:46 -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 6D70721E800C for ; Sun, 25 Mar 2012 12:28:46 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so4687083vcb.31 for ; Sun, 25 Mar 2012 12:28:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=WL5IoxZPNywjjeXP6PuGmeXFpbF/qhGL+rfyKV93GQc=; b=GwtHOlrB9c/To3yNeqw5GbYwvnFGtDixlPKddJ128nW29BZ73oByPfyTmTXyN86rI+ OrDZ15Q0h/hBtxRmDDoF7HPr4a8Paiic6MpOoR3G0k2EK2vk03oP96WMbr7s7ELIUOxr b5eauqbxfsbeDaYxLnKEzuJz5O4gd7AwDvInFo76H6saQxabCTAvgmJLjjj0HGE7ZiFH dDUoLDsSdyjYez4YCiwbNiEKnISziO+/uezz3FxyMPh1U5bFHBL2bMwxnjemH9yrNHmT 6+1gShEcdtt51wRYu94bod+zyMdu5p4T+2FYSnOqesT4umOtzlSkFo8aq7y+aL4SuJuC ZBVg==
Received: by 10.220.152.205 with SMTP id h13mr4177761vcw.12.1332703725856; Sun, 25 Mar 2012 12:28:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Sun, 25 Mar 2012 12:28:25 -0700 (PDT)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4B@ESESSCMS0356.eemea.ericsson.se>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F48@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4A@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4B@ESESSCMS0356.eemea.ericsson.se>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Sun, 25 Mar 2012 21:28:25 +0200
Message-ID: 
To: Christer Holmberg 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkGUBVse5GRo2dx7hYIhebiTnWGIElGIx8mbRZcvS+eJE7Q4f+IQ2ZdseIFC4vt2kUK10KN
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 19:28:47 -0000

2012/3/25 Christer Holmberg :
>> Right, but I repeat: if the WS client is a web browser, then it does
>> not know its local IP and port from which it has established the WS
>> connection, so that URI is "useless". If your suggestion means that
>> the outbound proxy "maps" such a Contact to the real location of the
>> WS client, then that is not defined in any RFC, instead that would be
>> a proprietary solution.
>
> The edge proxy would have to do the mapping *even* if Alice registers a G=
RUU, because when the INVITE comes the edge proxy needs to know to which WS=
 connection the R-URI points to.

No, that's not true. The RURI (i.e. in case of a SIP TCP client
registered behind NAT) contains something like
"sip:alice@192.168.200.123:5060;transport=3Dtcp". The proxy, following
*RFC 3261* should first check whether it already exists a TCP
connection opened (*from the proxy*) to that address
192.168.200.123:5060. If not (and it's *not*) the proxy should try to
open a new TCP connection to that addres (which obviously will fail
since it's a private address not reachable from the proxy).

That is what RFC 3261 states, and there is NO other spec saying the
opposite (could you find it otherwise?). This is, no RFC states that a
proxy/server maps a private address to the real public source address
from which the connection is made. There is the reason why Outbound
was born, and Outbound (as said before) does not use the Contact URI,
but instead the URI username portion of the Route header to identify
the Outbound connection.

Again, if you can find any RFC stating the opposite please tell it to
me (regardless I do know that 99% of PBX's, proxies, SBC's and
registrars make use of some *proprietary* mechanism to reuse the
client connection for inbound requests, due the fact that Outbound was
born in 2009).



> (Of course, as described below, if outbound is used, the contact/WS mappi=
ng is not needed)

If Outbound is not used, then things CANNOT work (unless you violate RFC 32=
61).




> Of course, when Carol sends the INVITE, using Alice's contact, the R-URI/=
contact has to be such that it reaches Alice's registrar in the first place=
. And, if Alice has registered multiple devices, associated with the same A=
OR, a GRUU may be needed to distinguish the correct one. BUT, again, that i=
s not WebSocket specific, and is not needed in order to make SIP WebSocket =
transport as such to work. It may be needed to make certain SIP use-cases t=
o work, but that is outside the scope of the transport spec :)

Sure, the GRUU topic is out of the scope of the SIP WebSocket
transport, since this transport adds or requires nothing new. The
behaviour is the same as in the case of a SIP TCP/TLS client behind
NAT (which cannot receive incoming connections so Outbound is the only
RFC based way to go).


Regards.


--=20
I=C3=B1aki Baz Castillo


From shida@ntt-at.com  Sun Mar 25 13:36:42 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8976B21E801A for ; Sun, 25 Mar 2012 13:36:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level: 
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEPn4TC54vNA for ; Sun, 25 Mar 2012 13:36:42 -0700 (PDT)
Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id F041E21E800C for ; Sun, 25 Mar 2012 13:36:41 -0700 (PDT)
Received: from [83.202.95.194] (port=52760 helo=[172.16.255.253]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SBuAs-0001cO-8e; Sun, 25 Mar 2012 15:36:28 -0500
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: Shida Schubert 
In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E2011BE@inba-mail01.sonusnet.com>
Date: Sun, 25 Mar 2012 22:36:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D3191A2-18C1-4076-8587-ECB10568B344@ntt-at.com>
References: <387F9047F55E8C42850AD6B3A7A03C6C0E2011BE@inba-mail01.sonusnet.com>
To: "Ravindran, Parthasarathi" 
X-Mailer: Apple Mail (2.1257)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator465.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ntt-at.com
X-BWhitelist: no
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: atuileries-153-1-64-194.w83-202.abo.wanadoo.fr ([172.16.255.253]) [83.202.95.194]:52760
X-Source-Auth: shida@agnada.com
X-Email-Count: 1
X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t
Cc: "Kuwabara, Yoshikazu" , "sipcore@ietf.org" 
Subject: Re: [sipcore] Editorial comment on draft-barnes-sipcore-rfc4244bis-callflows-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 20:36:42 -0000

 These are errors and we are aware of them and they have=20
been addressed in the version I have in hand. I just haven't=20
got around to submit the revised draft I have in hand..=20

 Many thanks for pointing it out, never the less.

 Regards
  Shida

On Mar 20, 2012, at 1:00 PM, Ravindran, Parthasarathi wrote:

> Mary,
>=20
> For History-info examples with reason header, the delimiter between =
hname and hvalue is shown as escaped character (%3B) instead of "=3D". =
The exact ABNF as per RFC 3261 is as follows:
>=20
> headers         =3D  "?" header *( "&" header )
> header          =3D  hname "=3D" hvalue
>=20
> In sec 3.1, F4, F5, F6, F7, F8 messages has
>=20
> History-Info: ;\
>                  index=3D1.1
> Has to be changed as:
> History-Info: ;\
>                  index=3D1.1
>=20
> Similar usage is seen in Sec 3.3 of F4,F5,F6, F7 messages:
>=20
> History-Info: ;\
>                      index=3D1.1;rc=3D1
> History-Info: ;\
>                      index=3D1.2.1;rc=3D1.2
>=20
> has to be changed as:
>=20
> History-Info: ;\
>                      index=3D1.1;rc=3D1
> History-Info: ;\
>                      index=3D1.2.1;rc=3D1.2
>=20
> Could you please let me know your opinion about these editorial =
comments.
>=20
> Thanks
> Partha
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore


From christer.holmberg@ericsson.com  Sun Mar 25 14:00:48 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2721721E801A for ; Sun, 25 Mar 2012 14:00:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.164
X-Spam-Level: 
X-Spam-Status: No, score=-10.164 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kX2GQh3ecsa for ; Sun, 25 Mar 2012 14:00:47 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 520E621E800C for ; Sun, 25 Mar 2012 14:00:46 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-af-4f6f877d0a3b
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id BC.61.17856.D778F6F4; Sun, 25 Mar 2012 23:00:46 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sun, 25 Mar 2012 23:00:45 +0200
From: Christer Holmberg 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
Date: Sun, 25 Mar 2012 23:00:44 +0200
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
Thread-Index: Ac0KvX9/Rb/dtGuMScypv44f2ytnTAACSW4Z
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4E@ESESSCMS0356.eemea.ericsson.se>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F48@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4A@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4B@ESESSCMS0356.eemea.ericsson.se>, 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 21:00:48 -0000

Hi,

>>> Right, but I repeat: if the WS client is a web browser, then it does
>>> not know its local IP and port from which it has established the WS
>>> connection, so that URI is "useless". If your suggestion means that
>>> the outbound proxy "maps" such a Contact to the real location of the
>>> WS client, then that is not defined in any RFC, instead that would be
>>> a proprietary solution.
>>
>> The edge proxy would have to do the mapping *even* if Alice registers a =
GRUU, because when the INVITE comes the edge proxy needs to know to which W=
S connection the R-URI points to.
>
> No, that's not true. The RURI (i.e. in case of a SIP TCP client
> registered behind NAT) contains something like
> "sip:alice@192.168.200.123:5060;transport=3Dtcp". The proxy, following
> *RFC 3261* should first check whether it already exists a TCP
> connection opened (*from the proxy*) to that address
> 192.168.200.123:5060. If not (and it's *not*) the proxy should try to
> open a new TCP connection to that addres (which obviously will fail
> since it's a private address not reachable from the proxy).
>
> That is what RFC 3261 states, and there is NO other spec saying the
> opposite (could you find it otherwise?).

There are some security mechanisms where you route traffic over existing IP=
Sec tunnels, but other than that I am not aware of anything.


> This is, no RFC states that a proxy/server maps a private address to the =
real public source address
> from which the connection is made. There is the reason why Outbound was b=
orn, and Outbound=20
> (as said before) does not use the Contact URI, but instead the URI userna=
me portion of the Route=20
> header to identify the Outbound connection.
>
> Again, if you can find any RFC stating the opposite please tell it to
> me (regardless I do know that 99% of PBX's, proxies, SBC's and
> registrars make use of some *proprietary* mechanism to reuse the
> client connection for inbound requests, due the fact that Outbound was
> born in 2009).
>
>> (Of course, as described below, if outbound is used, the contact/WS mapp=
ing is not needed)
>
> If Outbound is not used, then things CANNOT work (unless you violate RFC =
3261).

My idea was that we would specify this behavior for SIP WebSocket transport=
.

If we can NOT do that (e.g. because it would be considered to violate RFC 3=
261, or whatever reason), the client is behind a NAT and/or the client does=
 not know it's local address, then maybe  one has to use Outbound...

Regards,

Christer=

From saul@ag-projects.com  Sun Mar 25 14:44:02 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4290E21F842F for ; Sun, 25 Mar 2012 14:44:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.642
X-Spam-Level: 
X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[AWL=0.046,  BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dpr3Nf+DDqsw for ; Sun, 25 Mar 2012 14:44:01 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 611E721F8419 for ; Sun, 25 Mar 2012 14:44:00 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id EE6C8B01A2; Sun, 25 Mar 2012 23:43:58 +0200 (CEST)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 2B214B0181; Sun, 25 Mar 2012 23:43:44 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
In-Reply-To: <3EEB7D30-C856-48FB-A8B8-1CC8BC717EE8@ag-projects.com>
Date: Sun, 25 Mar 2012 23:43:43 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <4F5A7326.3030001@nostrum.com> <4F5A8086.7020704@digium.com> <3EEB7D30-C856-48FB-A8B8-1CC8BC717EE8@ag-projects.com>
To: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
X-Mailer: Apple Mail (2.1084)
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Call for Reviewers: SIP WebSocket Transport
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 21:44:02 -0000

Hi,

Unfortunately I could not review this on time, so by the time I checked =
everything was already on the table, so there is nothing I can add that =
wouldn't sound redundant :-S


Regards,

On Mar 12, 2012, at 3:08 PM, Sa=FAl Ibarra Corretg=E9 wrote:

>=20
> On Mar 9, 2012, at 11:13 PM, Kevin P. Fleming wrote:
>=20
>> On 03/09/2012 03:16 PM, Adam Roach - SIPCORE Chair wrote:
>>> [as chair]
>>>=20
>>> I've seen a lot of statements of support for the concept of using
>>> websockets as a transport for SIP. However, if we're going to have =
this
>>> work move forward, we'll need more in the way of technical =
discussion on
>>> the solution. (All I've seen so far is a discussion around the role =
of
>>> outbound, and I'm not sure that conversation has resolved far enough =
to
>>> call consensus).
>>>=20
>>> To that end, I'd like to solicit a small handful of dedicated =
reviewers
>>> to go over the current proposal:
>>>=20
>>> http://tools.ietf.org/html/draft-ibc-sipcore-sip-websocket-01
>>>=20
>>> Reviewers would be expected to read the draft carefully, and provide
>>> comments to the SIPCORE list. In order for us to have something to =
talk
>>> about in Paris, I would request that such reviews be posted to the =
list
>>> no later than Friday of next week (March 16th).
>>>=20
>>> Please inform the chairs (by replying to this message) if you would =
be
>>> willing to perform such a review.
>>>=20
>>> Unless we see additional traffic on the mailing list on this topic, =
I
>>> don't believe we'll have any basis for talking about it at the =
upcoming
>>> face-to-face meeting.
>>=20
>> I'll review it this weekend.
>>=20
>=20
> Me too.
>=20
>=20
> Regards,
>=20
> --
> Sa=FAl Ibarra Corretg=E9
> AG Projects
>=20
>=20
>=20
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From HKaplan@acmepacket.com  Sun Mar 25 14:55:25 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F9B21E800F for ; Sun, 25 Mar 2012 14:55:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.763
X-Spam-Level: 
X-Spam-Status: No, score=-1.763 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_44=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 QBj1hl4fkbGU for ; Sun, 25 Mar 2012 14:55:24 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 261E121E800C for ; Sun, 25 Mar 2012 14:55:24 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 25 Mar 2012 17:55:21 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Sun, 25 Mar 2012 17:55:21 -0400
From: Hadriel Kaplan 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
Thread-Index: AQHNCtH4N11NWOaOiEWyGzBc0c8M2g==
Date: Sun, 25 Mar 2012 21:55:19 +0000
Message-ID: <27989CCB-1685-47AF-8362-D12BF641FB46@acmepacket.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F48@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4A@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4B@ESESSCMS0356.eemea.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <4E06E8733CCEF140AD28EF8875982C40@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 21:55:25 -0000

On Mar 25, 2012, at 3:28 PM, I=F1aki Baz Castillo wrote:

> No, that's not true. The RURI (i.e. in case of a SIP TCP client
> registered behind NAT) contains something like
> "sip:alice@192.168.200.123:5060;transport=3Dtcp". The proxy, following
> *RFC 3261* should first check whether it already exists a TCP
> connection opened (*from the proxy*) to that address
> 192.168.200.123:5060. If not (and it's *not*) the proxy should try to
> open a new TCP connection to that addres (which obviously will fail
> since it's a private address not reachable from the proxy).

Theoretically, RFC 3581 section 9 described that a UA can learn its addr:po=
rt from the returned Via in the REGISTER response, and Register another Con=
tact using the public IP:port.  I don't know of any UA's that do that, but =
it is in an RFC.  Of course the RFC doesn't explain to the proxy to re-use =
the same connection put in the Registered Contact, but clearly that's the o=
nly way it could work.

I don't really know why one would need an RFC to state the obvious, but if =
you really want one to... maybe we can just get an errata on 3261 by arguin=
g it's a bug in RFC 3261 - a security bug.  The proxy/registrar can authent=
icate requests coming from a client UA, but the Proxy can't authenticate th=
at a new TCP connection it opens to a Registered UA really belongs to that =
registered UA process when the proxy actually gets around to opening one an=
d sending a SIP request down it.  It's far safer to send new requests for t=
he registered contact down the existing connection that the contact used fo=
r registration, assuming the register was authenticated. (If it's not a thi=
rd party registration, etc.)

So there you go Inaki: you have a new action item to submit an errata reque=
st on RFC 3261. :)


> That is what RFC 3261 states, and there is NO other spec saying the
> opposite (could you find it otherwise?). This is, no RFC states that a
> proxy/server maps a private address to the real public source address
> from which the connection is made. There is the reason why Outbound
> was born, and Outbound (as said before) does not use the Contact URI,
> but instead the URI username portion of the Route header to identify
> the Outbound connection.
> Again, if you can find any RFC stating the opposite please tell it to
> me (regardless I do know that 99% of PBX's, proxies, SBC's and
> registrars make use of some *proprietary* mechanism to reuse the
> client connection for inbound requests, due the fact that Outbound was
> born in 2009).

I would be surprised if it was 99% - I would expect it's more like 100.00%.
;)

-hadriel


From ibc@aliax.net  Sun Mar 25 15:02:12 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF7221F843C for ; Sun, 25 Mar 2012 15:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.026
X-Spam-Level: 
X-Spam-Status: No, score=-2.026 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, J_CHICKENPOX_44=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 gV7SGGKf5Coq for ; Sun, 25 Mar 2012 15:02:11 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9196821F8438 for ; Sun, 25 Mar 2012 15:02:11 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so4734819vcb.31 for ; Sun, 25 Mar 2012 15:02:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=y4JiBBcUJHaacUx4O7qf4jC0xaL3E/sTHr4FFq00YMA=; b=F1CY/rOrFC3SkpbDgXaRRD/C1dYBOGaqHmyY7HEOjoHB1MYUAS7/8kC1XfYPmrpL/B DiEaQUmjKIfuV++lTdJLFXBTTp0LvOf0GZZ9AOA37IN/PQ10eMZ33m+iw+ilkBn898Eq U2YtxFeEfe/+BY4CBbwYK5cY4JQZdB9bauQ+zlFp68quui4L+K0tW/TD9LjvF8HoJjjA MV9mFbnRd4GhVD6JIxJaDeqQolKXbMyS/yYuYrYf02imZMyMy6Xy6waJuxrA6h3IaUmR OcxFWdw3B1pRsXprXL0pOAezPeiFAZKQQWK6TYQuJTFF0U9lvekrRUytx+d4rbnxC1K6 u0uA==
Received: by 10.220.140.196 with SMTP id j4mr9990416vcu.22.1332712930967; Sun, 25 Mar 2012 15:02:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Sun, 25 Mar 2012 15:01:50 -0700 (PDT)
In-Reply-To: <27989CCB-1685-47AF-8362-D12BF641FB46@acmepacket.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F48@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4A@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4B@ESESSCMS0356.eemea.ericsson.se>  <27989CCB-1685-47AF-8362-D12BF641FB46@acmepacket.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 26 Mar 2012 00:01:50 +0200
Message-ID: 
To: Hadriel Kaplan 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlZBtlVSmanOCF5/1f/LW0bFzvZ9iqye2NkNjR3XBKE3/Mou6POx/TAvWz1ozMnkzXBu3MJ
Cc: "SIPCORE \(Session Initiation Protocol Core\) WG" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Mar 2012 22:02:12 -0000

2012/3/25 Hadriel Kaplan :
> Theoretically, RFC 3581 section 9 described that a UA can learn its addr:=
port from the returned Via in the REGISTER response, and Register another C=
ontact using the public IP:port. =C2=A0I don't know of any UA's that do tha=
t, but it is in an RFC. =C2=A0Of course the RFC doesn't explain to the prox=
y to re-use the same connection put in the Registered Contact, but clearly =
that's the only way it could work.
>
> I don't really know why one would need an RFC to state the obvious, but i=
f you really want one to... maybe we can just get an errata on 3261 by argu=
ing it's a bug in RFC 3261 - a security bug. =C2=A0The proxy/registrar can =
authenticate requests coming from a client UA, but the Proxy can't authenti=
cate that a new TCP connection it opens to a Registered UA really belongs t=
o that registered UA process when the proxy actually gets around to opening=
 one and sending a SIP request down it. =C2=A0It's far safer to send new re=
quests for the registered contact down the existing connection that the con=
tact used for registration, assuming the register was authenticated. (If it=
's not a third party registration, etc.)

I understand your point. Probably SIP should be defined in that way
from the beginning (rather than require extensions for so common
scenarios to work). But the fact is that, as you said, a registrar
trusts the Contact in the REGISTER without "validating" it (as you say
it's difficult to validate it taking into account that it allows 3rd
party registration). Also note that a REGISTER can contain multiple
bindings so...



>> Again, if you can find any RFC stating the opposite please tell it to
>> me (regardless I do know that 99% of PBX's, proxies, SBC's and
>> registrars make use of some *proprietary* mechanism to reuse the
>> client connection for inbound requests, due the fact that Outbound was
>> born in 2009).
>
> I would be surprised if it was 99% - I would expect it's more like 100.00=
%.
> ;)

No, it's between 99% and 99.99%, but not 100%  ;)


--=20
I=C3=B1aki Baz Castillo


From pkyzivat@alum.mit.edu  Sun Mar 25 23:45:00 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0CE21E8082 for ; Sun, 25 Mar 2012 23:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.534
X-Spam-Level: 
X-Spam-Status: No, score=-1.534 tagged_above=-999 required=5 tests=[AWL=-0.135, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, J_CHICKENPOX_44=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 zPgiNc+d3Bg6 for ; Sun, 25 Mar 2012 23:44:59 -0700 (PDT)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1145D21F8496 for ; Sun, 25 Mar 2012 23:44:47 -0700 (PDT)
Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta13.westchester.pa.mail.comcast.net with comcast id q6kJ1i0061swQuc5D6kogh; Mon, 26 Mar 2012 06:44:48 +0000
Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta15.westchester.pa.mail.comcast.net with comcast id q6ke1i00F5EhBnE3b6khLH; Mon, 26 Mar 2012 06:44:46 +0000
Message-ID: <4F701059.6040802@alum.mit.edu>
Date: Mon, 26 Mar 2012 08:44:41 +0200
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: sipcore@ietf.org
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F48@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4A@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C428E2F4B@ESESSCMS0356.eemea.ericsson.se>  <27989CCB-1685-47AF-8362-D12BF641FB46@acmepacket.com>
In-Reply-To: <27989CCB-1685-47AF-8362-D12BF641FB46@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 06:45:00 -0000

[as individual, for now]

Just stating that there are proprietary solutions to this problem isn't 
sufficient. ISTM that what you are really proposing is more of a rfc5626bis.

	Thanks,
	Paul

On 3/25/12 11:55 PM, Hadriel Kaplan wrote:
>
> On Mar 25, 2012, at 3:28 PM, I�aki Baz Castillo wrote:
>
>> No, that's not true. The RURI (i.e. in case of a SIP TCP client
>> registered behind NAT) contains something like
>> "sip:alice@192.168.200.123:5060;transport=tcp". The proxy, following
>> *RFC 3261* should first check whether it already exists a TCP
>> connection opened (*from the proxy*) to that address
>> 192.168.200.123:5060. If not (and it's *not*) the proxy should try to
>> open a new TCP connection to that addres (which obviously will fail
>> since it's a private address not reachable from the proxy).
>
> Theoretically, RFC 3581 section 9 described that a UA can learn its addr:port from the returned Via in the REGISTER response, and Register another Contact using the public IP:port.  I don't know of any UA's that do that, but it is in an RFC.  Of course the RFC doesn't explain to the proxy to re-use the same connection put in the Registered Contact, but clearly that's the only way it could work.
>
> I don't really know why one would need an RFC to state the obvious, but if you really want one to... maybe we can just get an errata on 3261 by arguing it's a bug in RFC 3261 - a security bug.  The proxy/registrar can authenticate requests coming from a client UA, but the Proxy can't authenticate that a new TCP connection it opens to a Registered UA really belongs to that registered UA process when the proxy actually gets around to opening one and sending a SIP request down it.  It's far safer to send new requests for the registered contact down the existing connection that the contact used for registration, assuming the register was authenticated. (If it's not a third party registration, etc.)
>
> So there you go Inaki: you have a new action item to submit an errata request on RFC 3261. :)
>
>
>> That is what RFC 3261 states, and there is NO other spec saying the
>> opposite (could you find it otherwise?). This is, no RFC states that a
>> proxy/server maps a private address to the real public source address
>> from which the connection is made. There is the reason why Outbound
>> was born, and Outbound (as said before) does not use the Contact URI,
>> but instead the URI username portion of the Route header to identify
>> the Outbound connection.
>> Again, if you can find any RFC stating the opposite please tell it to
>> me (regardless I do know that 99% of PBX's, proxies, SBC's and
>> registrars make use of some *proprietary* mechanism to reuse the
>> client connection for inbound requests, due the fact that Outbound was
>> born in 2009).
>
> I would be surprised if it was 99% - I would expect it's more like 100.00%.
> ;)
>
> -hadriel
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>


From pravindran@sonusnet.com  Mon Mar 26 00:45:38 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A3E21F8567 for ; Mon, 26 Mar 2012 00:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.086
X-Spam-Level: 
X-Spam-Status: No, score=-5.086 tagged_above=-999 required=5 tests=[AWL=1.513,  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 04jCUeYkIFnU for ; Mon, 26 Mar 2012 00:45:36 -0700 (PDT)
Received: from na3sys010aog110.obsmtp.com (na3sys010aog110.obsmtp.com [74.125.245.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6E97121F8578 for ; Mon, 26 Mar 2012 00:45:35 -0700 (PDT)
Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob110.postini.com ([74.125.244.12]) with SMTP ID DSNKT3AenlmliGI5COVemhDVqnTsn6cplSbz@postini.com; Mon, 26 Mar 2012 00:45:35 PDT
Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 26 Mar 2012 03:45:52 -0400
Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Mon, 26 Mar 2012 13:15:28 +0530
From: "Ravindran, Parthasarathi" 
To: Shida Schubert 
Thread-Topic: [sipcore] Editorial comment on draft-barnes-sipcore-rfc4244bis-callflows-02
Thread-Index: AQHNCsb82xqPot6gn0mV7G4rpbhzVJZ8MkFw
Date: Mon, 26 Mar 2012 07:45:48 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E220074@inba-mail01.sonusnet.com>
References: <387F9047F55E8C42850AD6B3A7A03C6C0E2011BE@inba-mail01.sonusnet.com> <7D3191A2-18C1-4076-8587-ECB10568B344@ntt-at.com>
In-Reply-To: <7D3191A2-18C1-4076-8587-ECB10568B344@ntt-at.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [121.242.142.186]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "Kuwabara, Yoshikazu" , "sipcore@ietf.org" 
Subject: Re: [sipcore] Editorial comment on draft-barnes-sipcore-rfc4244bis-callflows-02
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 07:45:38 -0000

Shida,

Thanks for the information & closure.

Thanks
Partha

>-----Original Message-----
>From: Shida Schubert [mailto:shida@ntt-at.com]
>Sent: Monday, March 26, 2012 2:06 AM
>To: Ravindran, Parthasarathi
>Cc: 'Mary Barnes'; Kuwabara, Yoshikazu; sipcore@ietf.org
>Subject: Re: [sipcore] Editorial comment on draft-barnes-sipcore-
>rfc4244bis-callflows-02
>
>
> These are errors and we are aware of them and they have been addressed
>in the version I have in hand. I just haven't got around to submit the
>revised draft I have in hand..
>
> Many thanks for pointing it out, never the less.
>
> Regards
>  Shida
>
>On Mar 20, 2012, at 1:00 PM, Ravindran, Parthasarathi wrote:
>
>> Mary,
>>
>> For History-info examples with reason header, the delimiter between
>hname and hvalue is shown as escaped character (%3B) instead of "=3D". The
>exact ABNF as per RFC 3261 is as follows:
>>
>> headers         =3D  "?" header *( "&" header )
>> header          =3D  hname "=3D" hvalue
>>
>> In sec 3.1, F4, F5, F6, F7, F8 messages has
>>
>> History-Info: ;\
>>                  index=3D1.1
>> Has to be changed as:
>> History-Info: ;\
>>                  index=3D1.1
>>
>> Similar usage is seen in Sec 3.3 of F4,F5,F6, F7 messages:
>>
>> History-Info: ;\
>>                      index=3D1.1;rc=3D1
>> History-Info: ;\
>>                      index=3D1.2.1;rc=3D1.2
>>
>> has to be changed as:
>>
>> History-Info: ;\
>>                      index=3D1.1;rc=3D1
>> History-Info: ;\
>>                      index=3D1.2.1;rc=3D1.2
>>
>> Could you please let me know your opinion about these editorial
>comments.
>>
>> Thanks
>> Partha
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore


From kpfleming@digium.com  Mon Mar 26 05:25:13 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A74A21F8726 for ; Mon, 26 Mar 2012 05:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.524
X-Spam-Level: 
X-Spam-Status: No, score=-106.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 Ji2Zk528uiKt for ; Mon, 26 Mar 2012 05:25:12 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 87CB021F8608 for ; Mon, 26 Mar 2012 05:25:12 -0700 (PDT)
Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SC8z1-0003Mv-SO for sipcore@ietf.org; Mon, 26 Mar 2012 07:25:11 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id DEC1FD8012 for ; Mon, 26 Mar 2012 07:25:11 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7LOBjXohPtj for ; Mon, 26 Mar 2012 07:25:11 -0500 (CDT)
Received: from [192.168.1.10] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 2D036D8011 for ; Mon, 26 Mar 2012 07:25:11 -0500 (CDT)
Message-ID: <4F706026.4090105@digium.com>
Date: Mon, 26 Mar 2012 07:25:10 -0500
From: "Kevin P. Fleming" 
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: sipcore@ietf.org
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com>
In-Reply-To: <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 12:25:13 -0000

On 03/25/2012 09:51 AM, Hadriel Kaplan wrote:
>
> On Mar 25, 2012, at 8:15 AM, I=F1aki Baz Castillo wrote:
>
>> 2012/3/25 Hadriel Kaplan:
>>> I don't follow how you got to the conclusion that if Outbound is requ=
ired, GRUU is required.
>>> GRUU is not necessary for Outbound to work, nor is it required by the=
 Outbound RFC as far as I know.  Nor does it appear a websocket connectio=
n would require GRUU.
>>
>> Hi Hadriel, an already given example:
>>
>> - Alice (WS SIP UA) is in a call with Bob (SIP UDP UA).
>> - Bob sends a REFER to Carol (SIP UDP UA) with "Refer-To: ALICE_CONTAC=
T_URI".
>> - Carol sends an INVITE to ALICE_CONTACT_URI.
>> The only way in which the INVITE can arrive to Alice is the case in
>> which ALICE_CONTACT_URI is a GRUU URI, so the INVITE would reach
>> Alice's inbound proxy/registrar and that would route the request to
>> Alice using the existing WebSocket connection (of course there could
>> be an Outbound Edge proxy between Alice and the registrar).
>> So, if Alice (and its registrar) does not implement GRUU then the
>> above scenario would fail. However please note that the above example
>> is exactly the SAME as in the case of Alice being a SIP TCP client
>> behind NAT.
>> The draft will not mandate GRUU but will suggest its implementation
>> (otherwise common scenarios as the above won't work).
>
> Sorry I should have been clearer... yes I know what GRUU is typically p=
roposed to be used for. :)
> But it's simply not the case that you need GRUU to accomplish the above=
.  The proof for that is the world today: few domains use real GRUUs, yet=
 call transfers work all the time.
>
> But again, I'm talking about a real GRUU.  A real GRUU is something tha=
t is globally routable, meaning that in theory if anyone on the Internet =
got it they could resolve a path to reach its represented contact instanc=
e.  What many people do today instead is use a contact for Alice that is =
routable within certain contexts/domains/paths.  Some times they encode s=
uch contacts syntactically to appear to be GRUUs, even though they really=
 aren't, but sometimes they just encode them as contacts.  Either way, it=
 generally works. (not always, mind you, but enough for the common use-ca=
ses)

I see we've essentially reached consensus on another fork of this=20
thread, but I'll make one additional point that I think might be useful.

For *some* use cases, SIP endpoints using TCP or TLS run into this same=20
issue (primarily when they are behind NATs). The IETF has documented a=20
solution for this, which may or may not be what the implementations that=20
Hadriel is referring to have employed.

For nearly *all* WebSocket use cases (that we've agreed to address with=20
this draft), SIP endpoints will have this issue. Since the WebSocket=20
transport is being documented *after* the creation of the solution=20
(GRUU), it seems reasonable to me for the WebSocket transport document=20
to refer to that solution as the preferred mechanism. It shouldn't be=20
mandated, but preferring it seems practical and useful.

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

From ibc@aliax.net  Mon Mar 26 05:50:42 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AAA221F8698 for ; Mon, 26 Mar 2012 05:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level: 
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=0.058,  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 i1PrRURb21WG for ; Mon, 26 Mar 2012 05:50:41 -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 262B921F84D8 for ; Mon, 26 Mar 2012 05:50:40 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so5166001vcb.31 for ; Mon, 26 Mar 2012 05:50:39 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=DcVXZiUzycrA0zxH/fJU4xsXzeRKNOa2Jd2CKCk7SpI=; b=Y8VeDoDUi4MBW6tf87ieROxnk/LTJuzqgLPT2dH1fpxC4F4/D9fsZB4G11oHLYKOML nXr57kUeAu8Cn9eu47vRBTzznWigelgjG756yLSKDCbZ2oIgQn2AdLWI0okI+iFWoVM2 XNjiCKoVTwKeiH7M44WTTOSCIQaOKAQ5Tn2o2kNFyuPfK9wQq3m0pfQcMdaJioTp0Kpy jljp1FltZrAP8jj+lfNfNr0SdP9qaxkjnF8q+xE7LdojErzgjSLhtkjtMen7Li18tJBs 2hTlMKr3LLALFOrdJbLdurPvzSuDcG30H20wOFNeymvN4ffh/WNnpVbsQTBVS98ERShN O+yA==
Received: by 10.52.27.1 with SMTP id p1mr9492148vdg.17.1332766239541; Mon, 26 Mar 2012 05:50:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Mon, 26 Mar 2012 05:50:19 -0700 (PDT)
In-Reply-To: <4F706026.4090105@digium.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com> <4F706026.4090105@digium.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 26 Mar 2012 14:50:19 +0200
Message-ID: 
To: "Kevin P. Fleming" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlIAicpiuMFhD2M6K7R+mce2i+IyflDClblbLnVOq04g/P2q9pE5QpR2KVRyBedYfrR/SHD
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 12:50:42 -0000

2012/3/26 Kevin P. Fleming :
> For *some* use cases, SIP endpoints using TCP or TLS run into this same
> issue (primarily when they are behind NATs). The IETF has documented a
> solution for this, which may or may not be what the implementations that
> Hadriel is referring to have employed.
>
> For nearly *all* WebSocket use cases (that we've agreed to address with t=
his
> draft), SIP endpoints will have this issue. Since the WebSocket transport=
 is
> being documented *after* the creation of the solution (GRUU), it seems
> reasonable to me for the WebSocket transport document to refer to that
> solution as the preferred mechanism. It shouldn't be mandated, but
> preferring it seems practical and useful.

I agree. And the same could be said for Outbund, agree?

If it's preferred, the draft could not mandate (MUST) Outbound for
those common scenarios (a SIP WS client is like a SIP TCP UA behind
NAT), but instead add a "Guidelines" Appendix suggesting the usage of
Outbound (and GRUU) for those cases.

We have no special interest in mandating Outbound or GRUU, but both
are IETF specifications solving the problems with those kind of
scenarios, so IMHO they should be mentioned in the draft. And IMHO
this is much better than assuming proprietary NAT-fixing solutions,
regardless they exist in 99% of server implementations.

Regards.


--=20
I=C3=B1aki Baz Castillo


From kpfleming@digium.com  Mon Mar 26 05:58:22 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD08021F85B4 for ; Mon, 26 Mar 2012 05:58:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.903
X-Spam-Level: 
X-Spam-Status: No, score=-105.903 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugcVIX3HXYk9 for ; Mon, 26 Mar 2012 05:58:20 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2716721F8572 for ; Mon, 26 Mar 2012 05:58:17 -0700 (PDT)
Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SC9V2-0003f7-PK for sipcore@ietf.org; Mon, 26 Mar 2012 07:58:16 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id C4D75D8012 for ; Mon, 26 Mar 2012 07:58:16 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmPD+gTRusSp for ; Mon, 26 Mar 2012 07:58:16 -0500 (CDT)
Received: from [192.168.1.10] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 48CF8D8011 for ; Mon, 26 Mar 2012 07:58:16 -0500 (CDT)
Message-ID: <4F7067E7.7070703@digium.com>
Date: Mon, 26 Mar 2012 07:58:15 -0500
From: "Kevin P. Fleming" 
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
CC: sipcore@ietf.org
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com> <4F706026.4090105@digium.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 12:58:22 -0000

On 03/26/2012 07:50 AM, I=F1aki Baz Castillo wrote:
> 2012/3/26 Kevin P. Fleming:
>> For *some* use cases, SIP endpoints using TCP or TLS run into this sam=
e
>> issue (primarily when they are behind NATs). The IETF has documented a
>> solution for this, which may or may not be what the implementations th=
at
>> Hadriel is referring to have employed.
>>
>> For nearly *all* WebSocket use cases (that we've agreed to address wit=
h this
>> draft), SIP endpoints will have this issue. Since the WebSocket transp=
ort is
>> being documented *after* the creation of the solution (GRUU), it seems
>> reasonable to me for the WebSocket transport document to refer to that
>> solution as the preferred mechanism. It shouldn't be mandated, but
>> preferring it seems practical and useful.
>
> I agree. And the same could be said for Outbund, agree?
>
> If it's preferred, the draft could not mandate (MUST) Outbound for
> those common scenarios (a SIP WS client is like a SIP TCP UA behind
> NAT), but instead add a "Guidelines" Appendix suggesting the usage of
> Outbound (and GRUU) for those cases.
>
> We have no special interest in mandating Outbound or GRUU, but both
> are IETF specifications solving the problems with those kind of
> scenarios, so IMHO they should be mentioned in the draft. And IMHO
> this is much better than assuming proprietary NAT-fixing solutions,
> regardless they exist in 99% of server implementations.

Yes, agreed 100%. In fact, because I suspect that a significant=20
percentage of application developers deploying SIP over WebSocket will=20
not be SIP 'gurus', providing such guidance will be very beneficial.

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

From victor.pascual.avila@gmail.com  Mon Mar 26 06:19:54 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E4B21E80A4 for ; Mon, 26 Mar 2012 06:19:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj4vW2RA9h93 for ; Mon, 26 Mar 2012 06:19:54 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id B1EF921E80AB for ; Mon, 26 Mar 2012 06:19:53 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so4174349ghb.31 for ; Mon, 26 Mar 2012 06:19:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=7fopewfK8NTK5LxqB3ihb225EWjgEBs4vv2n/TNr00A=; b=akbpE8JWsIoVjyjcYBbG2vT5E3bf+KVmXbltg0+LyVQe49mW6VmgihUdK9gBAItfl9 sMk25NIYlMx9MG6c4fkzyONA0bH/qZjA2eQVMz0w/XXKjFLCwtn6C+5tTuym6VvpMLHX KISRCYjc5OkqCCHbXaP06G14LKHBFojEq0nv8EtVn0cBS6W+Ygwh6NnICMI4rhmCOpDl vggyIJk/3Sf83hI7038gHVfDHgq/QH+jF24nV3HCWZy2DZex0l7lcDR0g6zdj0S3yoQ3 Hepxjk6nxjPYDkqJqtp2GRRDbxQMaryyx1fPNXUCXlOfcTVCMOnJe37gzManB1YbkY3Y XfNg==
MIME-Version: 1.0
Received: by 10.50.170.97 with SMTP id al1mr5548550igc.33.1332767992761; Mon, 26 Mar 2012 06:19:52 -0700 (PDT)
Received: by 10.231.196.72 with HTTP; Mon, 26 Mar 2012 06:19:52 -0700 (PDT)
In-Reply-To: <4F7067E7.7070703@digium.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com> <4F706026.4090105@digium.com>  <4F7067E7.7070703@digium.com>
Date: Mon, 26 Mar 2012 15:19:52 +0200
Message-ID: 
From: Victor Pascual Avila 
To: sipcore@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 13:19:54 -0000

> On 03/26/2012 07:50 AM, I=C3=B1aki Baz Castillo wrote:
>> If it's preferred, the draft could not mandate (MUST) Outbound for
>> those common scenarios (a SIP WS client is like a SIP TCP UA behind
>> NAT), but instead add a "Guidelines" Appendix suggesting the usage of
>> Outbound (and GRUU) for those cases.

So the next revision of the draft will not include any normative
language on Outbound/GRUU (these problems are not new/specific to the
WS transport) but will refer to them in a new (and non-normative)
guidelines section. Would that work for everyone?

Cheers,
-Victor

From saul@ag-projects.com  Mon Mar 26 06:43:48 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D2521F85D2 for ; Mon, 26 Mar 2012 06:43:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.645
X-Spam-Level: 
X-Spam-Status: No, score=-1.645 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iP1yWTSlVpyp for ; Mon, 26 Mar 2012 06:43:47 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 96DF821F85AF for ; Mon, 26 Mar 2012 06:43:47 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 9D819B01A5; Mon, 26 Mar 2012 15:43:45 +0200 (CEST)
Received: from imac.saghul.lan (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 116EEB0181; Mon, 26 Mar 2012 15:43:45 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= 
In-Reply-To: 
Date: Mon, 26 Mar 2012 15:43:44 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com> <4F706026.4090105@digium.com>  <4F7067E7.7070703@digium.com> 
To: Victor Pascual Avila 
X-Mailer: Apple Mail (2.1084)
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 13:43:48 -0000

On Mar 26, 2012, at 3:19 PM, Victor Pascual Avila wrote:

>> On 03/26/2012 07:50 AM, I=F1aki Baz Castillo wrote:
>>> If it's preferred, the draft could not mandate (MUST) Outbound for
>>> those common scenarios (a SIP WS client is like a SIP TCP UA behind
>>> NAT), but instead add a "Guidelines" Appendix suggesting the usage =
of
>>> Outbound (and GRUU) for those cases.
>=20
> So the next revision of the draft will not include any normative
> language on Outbound/GRUU (these problems are not new/specific to the
> WS transport) but will refer to them in a new (and non-normative)
> guidelines section. Would that work for everyone?
>=20

WFM.

--
Sa=FAl Ibarra Corretg=E9
AG Projects




From HKaplan@acmepacket.com  Mon Mar 26 13:46:05 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61C8421E811A for ; Mon, 26 Mar 2012 13:46:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.472
X-Spam-Level: 
X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127,  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 YTbYmm0nDbhP for ; Mon, 26 Mar 2012 13:46:04 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id B9E6A21E8101 for ; Mon, 26 Mar 2012 13:46:04 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 26 Mar 2012 16:46:02 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Mon, 26 Mar 2012 16:46:02 -0400
From: Hadriel Kaplan 
To: "Kevin P. Fleming" 
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
Thread-Index: AQHNC5F03Op0mPUHEUm6MXt7UpmyXA==
Date: Mon, 26 Mar 2012 20:46:01 +0000
Message-ID: 
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com> <4F706026.4090105@digium.com>
In-Reply-To: <4F706026.4090105@digium.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <9463C7454B265941BD118B5B6EAB5050@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 20:46:05 -0000

On Mar 26, 2012, at 2:25 PM, Kevin P. Fleming wrote:

> For nearly *all* WebSocket use cases (that we've agreed to address with t=
his draft), SIP endpoints will have this issue. Since the WebSocket transpo=
rt is being documented *after* the creation of the solution (GRUU), it seem=
s reasonable to me for the WebSocket transport document to refer to that so=
lution as the preferred mechanism. It shouldn't be mandated, but preferring=
 it seems practical and useful.

I would agree, if it weren't for that I wrote a draft of problems with usin=
g GRUUs.  :)

See here:
http://tools.ietf.org/html/draft-kaplan-dispatch-gruu-problematic-00

And before Paul says anything, the draft is NOT blaming GRUUs.  It's not th=
eir fault the Internet is a nasty place. ;)

-hadriel


From kpfleming@digium.com  Mon Mar 26 13:48:14 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1036921E8107 for ; Mon, 26 Mar 2012 13:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.543
X-Spam-Level: 
X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 uvWBQdPQyO9j for ; Mon, 26 Mar 2012 13:48:13 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id A5AAB21E8020 for ; Mon, 26 Mar 2012 13:48:01 -0700 (PDT)
Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SCGpc-0003R0-JL; Mon, 26 Mar 2012 15:48:00 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 8B2F6D8012; Mon, 26 Mar 2012 15:48:00 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzcM2UgIcwPO; Mon, 26 Mar 2012 15:48:00 -0500 (CDT)
Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 305C0D8011; Mon, 26 Mar 2012 15:48:00 -0500 (CDT)
Message-ID: <4F70D5FF.4080705@digium.com>
Date: Mon, 26 Mar 2012 15:47:59 -0500
From: "Kevin P. Fleming" 
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: Hadriel Kaplan 
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com> <4F706026.4090105@digium.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 20:48:14 -0000

On 03/26/2012 03:46 PM, Hadriel Kaplan wrote:
>
> On Mar 26, 2012, at 2:25 PM, Kevin P. Fleming wrote:
>
>> For nearly *all* WebSocket use cases (that we've agreed to address with this draft), SIP endpoints will have this issue. Since the WebSocket transport is being documented *after* the creation of the solution (GRUU), it seems reasonable to me for the WebSocket transport document to refer to that solution as the preferred mechanism. It shouldn't be mandated, but preferring it seems practical and useful.
>
> I would agree, if it weren't for that I wrote a draft of problems with using GRUUs.  :)
>
> See here:
> http://tools.ietf.org/html/draft-kaplan-dispatch-gruu-problematic-00

Yes, I still have that draft in my ever-growing reading list too. I 
should read it while traveling this week!

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

From ibc@aliax.net  Mon Mar 26 14:14:15 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9272021F84F9 for ; Mon, 26 Mar 2012 14:14:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=0.057,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqLx1Aoes0By for ; Mon, 26 Mar 2012 14:14:11 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B72C821F84F8 for ; Mon, 26 Mar 2012 14:14:11 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so3408514vbb.31 for ; Mon, 26 Mar 2012 14:14:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=xY4Gkk1KnjY55M5uwnLHjVSO/d5ROc/mNmWZ2gsAdz0=; b=ec7RvhaVOihb/+/mGKaMRH8Oke28zoVpIuRd6ImvGMptzmp7IuJx0DrIuPc1S5d7Tg 1xfcB51Ky+tp05JHw7qdgLZiuWYRmHY27O5p9aoqHXX2b7g/lstpqpBls5IovW9m5hfm xm/eoqbTd5GRsOMurICnYyjlQGcfKia7PmlWEidRKfqN2adE/+UVKOrPbLlf+EAe5MNL 6LIefYpYW+STQxjeNmPMpY0yJVfahUQ/YBRQywCTgF5Iyu0o0MHd4C78SWcqL4Y5pyfY 8XliwVD4tfblEBuOMHmi6+4krUbocGbva1jNy7JPUk7zq9HPTwTEFRvhIvFHlz9DJStB C3CQ==
Received: by 10.52.90.111 with SMTP id bv15mr10055283vdb.34.1332796451230; Mon, 26 Mar 2012 14:14:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Mon, 26 Mar 2012 14:13:51 -0700 (PDT)
In-Reply-To: 
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com> <4F706026.4090105@digium.com> 
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 26 Mar 2012 23:13:51 +0200
Message-ID: 
To: Hadriel Kaplan 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQkW/Z2uMpYhrkD39IOsOM6Zie2FyXADD2qpJNde3F11rVlgjvTnUjCi8VYxF4nNQ6XoUgt2
Cc: "" , "Kevin P. Fleming" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 21:14:16 -0000

2012/3/26 Hadriel Kaplan :
> I would agree, if it weren't for that I wrote a draft of problems with us=
ing GRUUs. =C2=A0:)
>
> See here:
> http://tools.ietf.org/html/draft-kaplan-dispatch-gruu-problematic-00

The word "B2BUA" appears 44 times... and what is an SBC?  :)

BTW, I expect that GRUU is supposed to work in the same scenarios as
Outbound, and those scenarios work much better if the registrar
becomes a node in the path of created dialogs.



--=20
I=C3=B1aki Baz Castillo


From ibc@aliax.net  Mon Mar 26 14:35:34 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9D221F8513 for ; Mon, 26 Mar 2012 14:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=0.056,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTrfElRPsZRf for ; Mon, 26 Mar 2012 14:35:34 -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 AA7F021F8427 for ; Mon, 26 Mar 2012 14:35:33 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so5642019vcb.31 for ; Mon, 26 Mar 2012 14:35:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=ta9YUYnha/k+8TWpFWWUsyghj9ylTPHIASPi/x4x7N4=; b=alublNo4KIG8O9tgo4o9SlaX5pCprRZZ5jZMkWxmHvfpqDCfhcPcKxMTaztPQWDbqV dX4NFc4CdnPQH0hiuBaWuLhfUkHGb4KmLqY0gBCrHmpfgAKJhMN1Qd8VcVU/wrd6hcNX +JFGlnhdQUGnh6CTd2Ad+Hby3KS/6e0trtXVWPBsQ/T3c442JQClv1rTq92GB0GbgHLi rFBUPHR8HyHaPpmuAwkKVFlq260PQ2IahhdFEVbNJqFWHc7cgPz4l7KVez14mY6l3bxe g4slfFS+IiHVMNkEQpehLtOFUkXUHaMWWGJQ9U/i7aJFlD3425IfmStUIYpq77C9oZD3 tr3g==
Received: by 10.52.27.1 with SMTP id p1mr10280655vdg.17.1332797733087; Mon, 26 Mar 2012 14:35:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Mon, 26 Mar 2012 14:35:12 -0700 (PDT)
In-Reply-To: 
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com> <4F706026.4090105@digium.com>  
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 26 Mar 2012 23:35:12 +0200
Message-ID: 
To: Hadriel Kaplan 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQki6wvmvkF/hnM26UcCbYKiQrlmnRhqRsJlsmLMMMClO/LrfVt84Pp3o5JCkJkqsquLQ1XZ
Cc: "" , "Kevin P. Fleming" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 21:35:34 -0000

2012/3/26 I=C3=B1aki Baz Castillo :
>> See here:
>> http://tools.ietf.org/html/draft-kaplan-dispatch-gruu-problematic-00
>
> The word "B2BUA" appears 44 times...

"Proxy" appears 27.... XD

--=20
I=C3=B1aki Baz Castillo


From HKaplan@acmepacket.com  Mon Mar 26 14:37:43 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED57621F85D7 for ; Mon, 26 Mar 2012 14:37:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.325
X-Spam-Level: 
X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 wMzzDc5wDjHJ for ; Mon, 26 Mar 2012 14:37:43 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5101C21F8550 for ; Mon, 26 Mar 2012 14:37:43 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 26 Mar 2012 17:37:37 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Mon, 26 Mar 2012 17:37:37 -0400
From: Hadriel Kaplan 
To: =?Windows-1252?Q?I=F1aki_Baz_Castillo?= 
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
Thread-Index: AQHNC5ipcY4rCp8L/0ijJoFAlor73A==
Date: Mon, 26 Mar 2012 21:37:36 +0000
Message-ID: 
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com> <4F706026.4090105@digium.com>  
In-Reply-To: 
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="Windows-1252"
Content-ID: <13D7310E3BBBEA4BAC23BFB6A302CE36@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" , "Kevin P. Fleming" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 21:37:44 -0000

On Mar 26, 2012, at 11:13 PM, I=F1aki Baz Castillo wrote:

> 2012/3/26 Hadriel Kaplan :
>> I would agree, if it weren't for that I wrote a draft of problems with u=
sing GRUUs.  :)
>>=20
>> See here:
>> http://tools.ietf.org/html/draft-kaplan-dispatch-gruu-problematic-00
>=20
> The word "B2BUA" appears 44 times=85

Hey I can't help it if B2BUAs are popular. ;)
(and by "B2BUA" I don't mean just SBCs - I mean PBXs, App-Servers, etc.)


> and what is an SBC?  :)

The thing defined in RFC 5853, of course.  What, you wouldn't think I would=
 use some undefined term would you?

-hadriel


From HKaplan@acmepacket.com  Mon Mar 26 14:39:48 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC14A21F8607 for ; Mon, 26 Mar 2012 14:39:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.325
X-Spam-Level: 
X-Spam-Status: No, score=-2.325 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 9BYv7iTsdIUc for ; Mon, 26 Mar 2012 14:39:48 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4831621F85D7 for ; Mon, 26 Mar 2012 14:39:48 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 26 Mar 2012 17:39:46 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Mon, 26 Mar 2012 17:39:47 -0400
From: Hadriel Kaplan 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
Thread-Index: AQHNC5j2cY4rCp8L/0ijJoFAlor73A==
Date: Mon, 26 Mar 2012 21:39:46 +0000
Message-ID: 
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com> <4F706026.4090105@digium.com>   
In-Reply-To: 
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="iso-8859-1"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" , "Kevin P. Fleming" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 21:39:48 -0000

On Mar 26, 2012, at 11:35 PM, I=F1aki Baz Castillo wrote:

> 2012/3/26 I=F1aki Baz Castillo :
>>> See here:
>>> http://tools.ietf.org/html/draft-kaplan-dispatch-gruu-problematic-00
>>=20
>> The word "B2BUA" appears 44 times...
>=20
> "Proxy" appears 27.... XD

Huh.  They're not that popular.  I'll try to remove some occurrences of tha=
t if I submit a next rev.

BTW, it's probably 45 times for B2BUA, since I had a typo and used "B2UA" s=
omewhere.

-hadriel


From ibc@aliax.net  Mon Mar 26 14:45:05 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3978A21F8623 for ; Mon, 26 Mar 2012 14:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=0.056,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5Y7aogBNNV2 for ; Mon, 26 Mar 2012 14:45:04 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA5621F854F for ; Mon, 26 Mar 2012 14:45:04 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so3427593vbb.31 for ; Mon, 26 Mar 2012 14:45:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=yn/56nuuD73twRhzJwO+xgw/Tzof2bwzgA/WPyc9wAw=; b=al4vGaYp4Akk08OyaItwjyZLxNS+oatHsNoGBszwdMGdddZNTph6q54J7Baz38Ue7O AYy7Lt0gVN6ThyKK/U+7dXSv5gXDGUN/wDEIVg4zocm9OJcjpT4PoIvqJWvawpi8kXqW DuMd+zbIehhkQNiTb39PrA4axws+ShM4MJf479uhF652W1SxzbJiIgqsGU2pOOLn8dlz c+YOIiyJ50WgtvilDgHHx67hFdZKz+pMCcsUtAg+MpIX1IDkrhHvWZ2mUvFn/+F7lYV+ 4Lx2jA2wozhBzHFTFnPmzlqPTvBFY6MuhI8VO3WWr1VJ9+DU+DtWm5Tqu/7IIcvsMBUi 2sCw==
Received: by 10.220.140.196 with SMTP id j4mr12001212vcu.22.1332798304122; Mon, 26 Mar 2012 14:45:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Mon, 26 Mar 2012 14:44:43 -0700 (PDT)
In-Reply-To: 
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com> <4F706026.4090105@digium.com>    
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Mon, 26 Mar 2012 23:44:43 +0200
Message-ID: 
To: Hadriel Kaplan 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQn4mo3ODVzYfz5NeniP7cKUe5jsyM4jxdbFS7MOBxCwPKMQ8UVYxx9yz5yPZyh/s9FU97jc
Cc: "" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Mar 2012 21:45:05 -0000

2012/3/26 Hadriel Kaplan :
>>> The word "B2BUA" appears 44 times...
>>
>> "Proxy" appears 27.... XD
>
> Huh. =C2=A0They're not that popular. =C2=A0I'll try to remove some occurr=
ences of that if I submit a next rev.

What about draft-kaplan-sipcore-deprecating-proxies-in-sip-architectures-00=
 ?
It could contain some figure with title "The SBC Trapezoid". :)

--=20
I=C3=B1aki Baz Castillo


From vkg@bell-labs.com  Mon Mar 26 15:22:50 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24F7521E8012 for ; Mon, 26 Mar 2012 15:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.885
X-Spam-Level: 
X-Spam-Status: No, score=-106.885 tagged_above=-999 required=5 tests=[AWL=-0.286, 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 dZzhua4RUj77 for ; Mon, 26 Mar 2012 15:22:49 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 0669B21E801F for ; Mon, 26 Mar 2012 15:22:48 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id q2QMMlsr014643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 26 Mar 2012 17:22:47 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q2QMMkRs013901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 26 Mar 2012 17:22:47 -0500
Received: from shoonya.ih.lucent.com (vkg.lra.lucent.com [135.244.192.74]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q2QMMknv008201 for ; Mon, 26 Mar 2012 17:22:46 -0500 (CDT)
Message-ID: <4F70ED57.7070405@bell-labs.com>
Date: Mon, 26 Mar 2012 17:27:35 -0500
From: "Vijay K. Gurbani" 
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.1) Gecko/20120209 Thunderbird/10.0.1
MIME-Version: 1.0
To: sipcore@ietf.org
References:  <4F688A57.8010700@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C41456EBF@ESESSCMS0356.eemea.ericsson.se>  <7F2072F1E0DE894DA4B517B93C6A05852C41456F36@ESESSCMS0356.eemea.ericsson.se> <4F68B8B6.7070505@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414570DB@ESESSCMS0356.eemea.ericsson.se> <4F69D8B2.7080805@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852C414574F7@ESESSCMS0356.eemea.ericsson.se> <4F6A41EB.4020001@alum.mit.edu>
In-Reply-To: <4F6A41EB.4020001@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 26 Mar 2012 22:22:50 -0000

On 03/21/2012 04:02 PM, Paul Kyzivat wrote:
> I don't want to misrepresent things here. I *think* there were more
> subtleties to it than that. I sent a query to Cullen, Vijay, and Brett,
> who are authors on outbound and connect-reuse, in hopes that one of them
> can dredge up more of those subtleties.

Sorry to tune in late to the party, but trying to close the loop.

With respect to whether a websocket server can rfc5923 (connect-reuse)
to reuse the same websocket connection to send requests in the opposite
direction --- that is, requests from the server destined to the client
--- I believe the answer is no.  Connect-reuse as described in rfc5923
is defined between two proxies and not a proxy and an UA.

There were reasons why we went with this model.  Trying to remember from
memory (the early work on this happened in the 2003-2005 timeframe),
these were:

1) When a client used standard TCP (i.e., no TLS) to contact a proxy, it
  is implicitly trusting the authenticity of the server.  The server
  could engage in a HTTP Digest to preserve some modicum of security;
  however, even after HTTP Digest, the client has authenticated to the
  server, but the server has not authenticated to the client.

  Connect-reuse over such a medium could imply that some rogue server
  can now send  requests to the user agent over the opened connection.

2) At the time work on connect-reuse was progressing, work on
  outbound was getting started.  While outbound suffers from the same
  problem of not knowing the authenticity of the registrar/proxy unless
  TLS was used, it was felt that outbound provided a more complete
  solution with additional properties of multiple flows for redundancy,
  etc. that were viewed as being advantageous.

(2) ensured that the work on outbound would become the de-facto
means to reuse connections opened by the user agent for requests
initiated by servers, while (1) went on to become the means whereby two
proxies with appropriate X.509 certificates using TLS could reuse
connections for requests in the opposite directions.

With websockets in the mix, the need for authenticating the server
is a bit less severe if we assume that the browser used https:// to
download the calling service which is now using websockets to open up a
connection to the same origin.  Since the origin was presumably
authenticated through normal TLS certificate checks earlier, confidence
runs higher that the server is trusted and therefore, should be able
to send a request back to the client.  Now whether or not Inaki's
websocket for SIP draft should allow this is another matter altogether.

Thanks,

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

From wwwrun@rfc-editor.org  Mon Mar 26 11:12:04 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137F221F8735 for ; Mon, 26 Mar 2012 11:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.452
X-Spam-Level: 
X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMNWID08C0gF for ; Mon, 26 Mar 2012 11:12:03 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 28BAB21F8734 for ; Mon, 26 Mar 2012 11:11:58 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 1F879B1E003; Mon, 26 Mar 2012 11:10:40 -0700 (PDT)
To: christer.holmberg@ericsson.com, eburger@standardstrack.com, hkaplan@acmepacket.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, adam@nostrum.com, pkyzivat@alum.mit.edu
From: RFC Errata System 
Message-Id: <20120326181040.1F879B1E003@rfc-editor.org>
Date: Mon, 26 Mar 2012 11:10:40 -0700 (PDT)
X-Mailman-Approved-At: Mon, 26 Mar 2012 15:59:10 -0700
Cc: dworley@avaya.com, sipcore@ietf.org, rfc-editor@rfc-editor.org
Subject: [sipcore] [Technical Errata Reported] RFC6086 (3167)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.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, 26 Mar 2012 18:12:04 -0000

The following errata report has been submitted for RFC6086,
"Session Initiation Protocol (SIP) INFO Method and Package Framework".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6086&eid=3167

--------------------------------------
Type: Technical
Reported by: Dale Worley 

Section: 12.2.2

Original Text
-------------
12.2.2.1.  Non-Info Package Body Part

   INFO sip:alice@pc33.example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
   To: Alice ;tag=1234567
   From: Bob ;tag=abcdefg
   Call-Id: a84b4c76e66710@pc33.example.com
   CSeq: 314400 INFO
   Info-Package: foo
   Content-Type: multipart/mixed;boundary="theboundary"
   Content-Length: ...

   --theboundary
   Content-Type: application/mumble
   ...

   

   --theboundary
   Content-Type: application/foo-x
   Content-Disposition: Info-Package
>>>Content-length: 59

   I am a foo-x message type, and I belong to Info Package foo
   --theboundary--

12.2.2.2.  Info Package with Multiple Body Parts inside Multipart Body
           Part

   INFO sip:alice@pc33.example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
   To: Alice ;tag=1234567
   From: Bob ;tag=abcdefg
   Call-Id: a84b4c76e66710@pc33.example.com
   CSeq: 314423 INFO
   Info-Package: foo
   Content-Type: multipart/mixed;boundary="theboundary"
   Content-Disposition: Info-Package
   Content-Length: ...

   --theboundary
   Content-Type: application/foo-x
>>>Content-length: 59

   I am a foo-x message type, and I belong to Info Package foo

   

   --theboundary
   Content-Type: application/foo-y
>>>Content-length: 59

   I am a foo-y message type, and I belong to Info Package foo
   --theboundary--

12.2.2.3.  Info Package with Single Body Part inside Multipart Body Part

   INFO sip:alice@pc33.example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
   To: Alice ;tag=1234567
   From: Bob ;tag=abcdefg
   Call-Id: a84b4c76e66710@pc33.example.com
   CSeq: 314423 INFO
   Info-Package: foo
   Content-Type: multipart/mixed;boundary="theboundary"
   Content-Disposition: Info-Package
   Content-Length: ...

   --theboundary
   Content-Type: application/foo-x
   Content-Disposition: icon
>>>Content-length: 59

   I am a foo-x message type, and I belong to Info Package foo
   --theboundary--


Corrected Text
--------------
12.2.2.1.  Non-Info Package Body Part

   INFO sip:alice@pc33.example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
   To: Alice ;tag=1234567
   From: Bob ;tag=abcdefg
   Call-Id: a84b4c76e66710@pc33.example.com
   CSeq: 314400 INFO
   Info-Package: foo
   Content-Type: multipart/mixed;boundary="theboundary"
   Content-Length: ...

   --theboundary
   Content-Type: application/mumble
   ...

   

   --theboundary
   Content-Type: application/foo-x
   Content-Disposition: Info-Package

   I am a foo-x message type, and I belong to Info Package foo
   --theboundary--

12.2.2.2.  Info Package with Multiple Body Parts inside Multipart Body
           Part

   INFO sip:alice@pc33.example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
   To: Alice ;tag=1234567
   From: Bob ;tag=abcdefg
   Call-Id: a84b4c76e66710@pc33.example.com
   CSeq: 314423 INFO
   Info-Package: foo
   Content-Type: multipart/mixed;boundary="theboundary"
   Content-Disposition: Info-Package
   Content-Length: ...

   --theboundary
   Content-Type: application/foo-x

   I am a foo-x message type, and I belong to Info Package foo

   

   --theboundary
   Content-Type: application/foo-y

   I am a foo-y message type, and I belong to Info Package foo
   --theboundary--

12.2.2.3.  Info Package with Single Body Part inside Multipart Body Part

   INFO sip:alice@pc33.example.com SIP/2.0
   Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
   To: Alice ;tag=1234567
   From: Bob ;tag=abcdefg
   Call-Id: a84b4c76e66710@pc33.example.com
   CSeq: 314423 INFO
   Info-Package: foo
   Content-Type: multipart/mixed;boundary="theboundary"
   Content-Disposition: Info-Package
   Content-Length: ...

   --theboundary
   Content-Type: application/foo-x
   Content-Disposition: icon

   I am a foo-x message type, and I belong to Info Package foo
   --theboundary--


Notes
-----
In four locations (in three examples), a Content-Length header is shown for a multipart body-part.  But comparing with RFC 1521 section 7.2, Content-Length has no defined meaning within MIME, and it appears that any appearance in a body-part header must be ignored.  Thus, these headers are meaningless, and the authors would probably not have included them if they had researched the subject.

(Bruno Chatras discovered this discrepancy.)

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6086 (draft-ietf-sipcore-info-events-10)
--------------------------------------
Title               : Session Initiation Protocol (SIP) INFO Method and Package Framework
Publication Date    : January 2011
Author(s)           : C. Holmberg, E. Burger, H. Kaplan
Category            : PROPOSED STANDARD
Source              : Session Initiation Protocol Core
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG

From HKaplan@acmepacket.com  Tue Mar 27 00:44:40 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AF221F87C3 for ; Tue, 27 Mar 2012 00:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.324
X-Spam-Level: 
X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 8RF0iDaOw3hS for ; Tue, 27 Mar 2012 00:44:39 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD4921F87BD for ; Tue, 27 Mar 2012 00:44:39 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 27 Mar 2012 03:44:37 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.170]) by Mail2.acmepacket.com ([169.254.2.166]) with mapi id 14.02.0283.003; Tue, 27 Mar 2012 03:44:37 -0400
From: Hadriel Kaplan 
To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= 
Thread-Topic: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
Thread-Index: AQHNC+11qjhxJ3+te0OTvQXyMkc0ow==
Date: Tue, 27 Mar 2012 07:44:36 +0000
Message-ID: <00CE0351-5679-4353-8255-29AA1DE09FAE@acmepacket.com>
References: <7F2072F1E0DE894DA4B517B93C6A05852C411A564C@ESESSCMS0356.eemea.ericsson.se>  <1C4D8A4A-AB13-414A-A51A-7AB2741FEAC6@acmepacket.com>  <1A49ACE6-804A-480B-ABFE-EC2C88DF1D97@acmepacket.com> <4F706026.4090105@digium.com>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <578506A1980F494CB156D91E4A13083B@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" 
Subject: Re: [sipcore] Some considerations on draft-ibc-sipcore-sip-websocket (Outbound and more) - GRUU
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Mar 2012 07:44:40 -0000

On Mar 26, 2012, at 11:44 PM, I=F1aki Baz Castillo wrote:

> 2012/3/26 Hadriel Kaplan :
>>>> The word "B2BUA" appears 44 times...
>>>=20
>>> "Proxy" appears 27.... XD
>>=20
>> Huh.  They're not that popular.  I'll try to remove some occurrences of =
that if I submit a next rev.
>=20
> What about draft-kaplan-sipcore-deprecating-proxies-in-sip-architectures-=
00 ?
> It could contain some figure with title "The SBC Trapezoid". :)

Already done:=20
http://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt

-hadriel


From internet-drafts@ietf.org  Tue Mar 27 04:47:25 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93C2221F89A3; Tue, 27 Mar 2012 04:47:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJP1K9-O8uEL; Tue, 27 Mar 2012 04:47:25 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0374D21F8988; Tue, 27 Mar 2012 04:47:25 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.00
Message-ID: <20120327114725.23007.86347.idtracker@ietfa.amsl.com>
Date: Tue, 27 Mar 2012 04:47:25 -0700
Cc: sipcore@ietf.org
Subject: [sipcore] I-D Action: draft-ietf-sipcore-rfc4244bis-07.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Mar 2012 11:47:25 -0000

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

	Title           : An Extension to the Session Initiation Protocol (SIP) fo=
r Request History Information
	Author(s)       : Mary Barnes
                          Francois Audet
                          Shida Schubert
                          Detecon International Gmbh
                          Christer Holmberg
	Filename        : draft-ietf-sipcore-rfc4244bis-07.txt
	Pages           : 65
	Date            : 2012-03-27

   This document defines a standard mechanism for capturing the history
   information associated with a Session Initiation Protocol (SIP)
   request.  This capability enables many enhanced services by providing
   the information as to how and why a SIP request arrives at a specific
   application or user.  This document defines an optional SIP header
   field, History-Info, for capturing the history information in
   requests.  The document also defines SIP header field parameters for
   the History-Info and Contact header fields to tag the method by which
   the target of a request is determined.  In addition, this
   specification defines a value for the Privacy header field specific
   to the History-Info header field.  This document obsoletes RFC 4244.


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

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

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


From adam@nostrum.com  Wed Mar 28 02:26:22 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3D0821E809E for ; Wed, 28 Mar 2012 02:26:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.231
X-Spam-Level: 
X-Spam-Status: No, score=-102.231 tagged_above=-999 required=5 tests=[AWL=0.369, 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 UriTf11r6mxQ for ; Wed, 28 Mar 2012 02:26:21 -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 A293221F8976 for ; Wed, 28 Mar 2012 02:26:20 -0700 (PDT)
Received: from dhcp-1418.meeting.ietf.org (dhcp-1418.meeting.ietf.org [130.129.20.24]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q2S9QI63098079 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 28 Mar 2012 04:26:19 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4F72D93A.8040501@nostrum.com>
Date: Wed, 28 Mar 2012 11:26:18 +0200
From: Adam Roach - SIPCORE Chair 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "SIPCORE (Session Initiation Protocol Core) WG" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 130.129.20.24 is authenticated by a trusted mechanism)
Subject: [sipcore] Confirming Consensus: WebSockets
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, 28 Mar 2012 09:26:22 -0000

[as chair]

During the face-to-face meeting yesterday, the chairs asked for a feel 
of the room to gauge support for working on the WebSockets transport for 
SIP. Consensus among those present was strongly in favor.

Based on this impression, the SIPCORE chairs plan to take the following 
actions unless objections are raised on this email list prior to Friday, 
April 6th:

- We will add a new milestone to our charter: "WebSockets SIP
   Transport to IESG (PS)"

- We will adopt draft-ibc-sipcore-sip-websocket-01 as the basis
   for fulfilling the new milestone, and request that the authors
   submit a new version with a filename reflecting this adoption.

Thank you.

/a

From adam@nostrum.com  Wed Mar 28 04:29:48 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5184921F88A8 for ; Wed, 28 Mar 2012 04:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.305
X-Spam-Level: 
X-Spam-Status: No, score=-102.305 tagged_above=-999 required=5 tests=[AWL=0.295, 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 VNGq37zGfssS for ; Wed, 28 Mar 2012 04:29:47 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9E22221F889F for ; Wed, 28 Mar 2012 04:29:47 -0700 (PDT)
Received: from dhcp-1418.meeting.ietf.org (dhcp-1418.meeting.ietf.org [130.129.20.24]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q2SBTjoY021241 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 28 Mar 2012 06:29:47 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4F72F629.9020902@nostrum.com>
Date: Wed, 28 Mar 2012 13:29:45 +0200
From: Adam Roach - SIPCORE Chair 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "SIPCORE (Session Initiation Protocol Core) WG" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 130.129.20.24 is authenticated by a trusted mechanism)
Subject: [sipcore] Minutes for IETF 83
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, 28 Mar 2012 11:29:48 -0000

I have posted a preliminary version of the minutes for yesterday's 
meeting on the IETF website:

http://www.ietf.org/proceedings/83/minutes/minutes-83-sipcore.html

Any comments or corrections should be sent to 
. Thank you.

/a

From kpfleming@digium.com  Wed Mar 28 05:33:40 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76B4621E8195 for ; Wed, 28 Mar 2012 05:33:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.4
X-Spam-Level: 
X-Spam-Status: No, score=-106.4 tagged_above=-999 required=5 tests=[AWL=0.199,  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 AyS2JDVZ4O49 for ; Wed, 28 Mar 2012 05:33:33 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id CF99921E8093 for ; Wed, 28 Mar 2012 05:33:32 -0700 (PDT)
Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SCs4B-0000xF-HJ for sipcore@ietf.org; Wed, 28 Mar 2012 07:33:31 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 84DA0D8013 for ; Wed, 28 Mar 2012 07:33:31 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikEOwb8Bx5Zl for ; Wed, 28 Mar 2012 07:33:31 -0500 (CDT)
Received: from [192.168.1.10] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id E67FED8011 for ; Wed, 28 Mar 2012 07:33:30 -0500 (CDT)
Message-ID: <4F730519.6040802@digium.com>
Date: Wed, 28 Mar 2012 07:33:29 -0500
From: "Kevin P. Fleming" 
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: sipcore@ietf.org
References: <4F72D93A.8040501@nostrum.com>
In-Reply-To: <4F72D93A.8040501@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [sipcore] Confirming Consensus: WebSockets
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 12:33:40 -0000

On 03/28/2012 04:26 AM, Adam Roach - SIPCORE Chair wrote:
> [as chair]
>
> During the face-to-face meeting yesterday, the chairs asked for a feel
> of the room to gauge support for working on the WebSockets transport for
> SIP. Consensus among those present was strongly in favor.
>
> Based on this impression, the SIPCORE chairs plan to take the following
> actions unless objections are raised on this email list prior to Friday,
> April 6th:
>
> - We will add a new milestone to our charter: "WebSockets SIP
> Transport to IESG (PS)"
>
> - We will adopt draft-ibc-sipcore-sip-websocket-01 as the basis
> for fulfilling the new milestone, and request that the authors
> submit a new version with a filename reflecting this adoption.

Should this wait until -02, with the portions that caused controversy 
moved to non-normative?

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

From christer.holmberg@ericsson.com  Wed Mar 28 05:37:17 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3361E21F8718 for ; Wed, 28 Mar 2012 05:37:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.14
X-Spam-Level: 
X-Spam-Status: No, score=-8.14 tagged_above=-999 required=5 tests=[AWL=-1.891,  BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5+Uj2HzO-d1 for ; Wed, 28 Mar 2012 05:37:15 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9BB21F8551 for ; Wed, 28 Mar 2012 05:37:14 -0700 (PDT)
X-AuditID: c1b4fb2d-b7b76ae0000063d8-20-4f7305f82b13
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9A.A4.25560.9F5037F4; Wed, 28 Mar 2012 14:37:13 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Wed, 28 Mar 2012 14:37:13 +0200
From: Christer Holmberg 
To: "'Kevin P. Fleming'" , "sipcore@ietf.org" 
Date: Wed, 28 Mar 2012 14:37:12 +0200
Thread-Topic: [sipcore] Confirming Consensus: WebSockets
Thread-Index: Ac0M3wN3v6QUgCHgQLCHEcm0ET9FKgAADWdg
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C429F5D81@ESESSCMS0356.eemea.ericsson.se>
References: <4F72D93A.8040501@nostrum.com> <4F730519.6040802@digium.com>
In-Reply-To: <4F730519.6040802@digium.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [sipcore] Confirming Consensus: WebSockets
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 12:37:17 -0000

Hi,

There was no agreement regarding GRUU, but as far as I know we decided not =
to mandate Outbound, but rather go for Option 2. Unless I'm wrong, I guess =
it would be good to mention that in the minutes.

Regards,

Christer=20

-----Original Message-----
From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf =
Of Kevin P. Fleming
Sent: 28. maaliskuuta 2012 15:33
To: sipcore@ietf.org
Subject: Re: [sipcore] Confirming Consensus: WebSockets

On 03/28/2012 04:26 AM, Adam Roach - SIPCORE Chair wrote:
> [as chair]
>
> During the face-to-face meeting yesterday, the chairs asked for a feel=20
> of the room to gauge support for working on the WebSockets transport=20
> for SIP. Consensus among those present was strongly in favor.
>
> Based on this impression, the SIPCORE chairs plan to take the=20
> following actions unless objections are raised on this email list=20
> prior to Friday, April 6th:
>
> - We will add a new milestone to our charter: "WebSockets SIP=20
> Transport to IESG (PS)"
>
> - We will adopt draft-ibc-sipcore-sip-websocket-01 as the basis for=20
> fulfilling the new milestone, and request that the authors submit a=20
> new version with a filename reflecting this adoption.

Should this wait until -02, with the portions that caused controversy moved=
 to non-normative?

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming@digium.com | SIP: kpfleming@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at www.dig=
ium.com & www.asterisk.org _______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

From ibc@aliax.net  Wed Mar 28 05:38:55 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DF6E21E81D6 for ; Wed, 28 Mar 2012 05:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.622
X-Spam-Level: 
X-Spam-Status: No, score=-2.622 tagged_above=-999 required=5 tests=[AWL=0.055,  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 exrp98PeAD09 for ; Wed, 28 Mar 2012 05:38:51 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C1E6021E81D4 for ; Wed, 28 Mar 2012 05:38:49 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so750814vbb.31 for ; Wed, 28 Mar 2012 05:38:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=MP/P4im+tBtMa6V+fl45yWrvI7HHIaGNNbPjRkMDCGI=; b=Xmb4c5PVjQtTrlLGBgX48poF1Fas372Lq3FF5NnxdnlfJXYmvgGz3MHU9jyQIH6U9i EpifTXI88WCXDcu2KDcPXbnuH2xzesrj88v/Ssbiyf0XKXL2zuSoDLAWh5Oyr0GSzDoc PmXwmDFVhzHi/XY5kLdAcFPPF/s3crr9Xz5RR5emu5ITV5lsx6UG4ljRR8zfb5PsHHos 4ABH3V2UaS/SW9QzdS7NYoOYnSQeiDLJD4dNUNV7IDM2s4JNTESY9ENVFtRLVJJNAsh2 IdRitY66MRJ0vHuEkY0EniYd6cXjoZjIfZcaoRMYOymCZasJuwjoiXG8ZKLR7tchPGYd oJ9A==
Received: by 10.220.152.205 with SMTP id h13mr9712779vcw.12.1332938329291; Wed, 28 Mar 2012 05:38:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.170.165 with HTTP; Wed, 28 Mar 2012 05:38:29 -0700 (PDT)
In-Reply-To: <4F730519.6040802@digium.com>
References: <4F72D93A.8040501@nostrum.com> <4F730519.6040802@digium.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= 
Date: Wed, 28 Mar 2012 14:38:29 +0200
Message-ID: 
To: "Kevin P. Fleming" 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQky3OJmbKjRMF8bBv2PSQfJn3JG0cDAftT8gjJinecaSgRdUcCLo4BmCNIZqMBFIBZs2svp
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Confirming Consensus: WebSockets
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 12:38:55 -0000

2012/3/28 Kevin P. Fleming :
> On 03/28/2012 04:26 AM, Adam Roach - SIPCORE Chair wrote:
>>
>> [as chair]
>>
>> During the face-to-face meeting yesterday, the chairs asked for a feel
>> of the room to gauge support for working on the WebSockets transport for
>> SIP. Consensus among those present was strongly in favor.
>>
>> Based on this impression, the SIPCORE chairs plan to take the following
>> actions unless objections are raised on this email list prior to Friday,
>> April 6th:
>>
>> - We will add a new milestone to our charter: "WebSockets SIP
>> Transport to IESG (PS)"
>>
>> - We will adopt draft-ibc-sipcore-sip-websocket-01 as the basis
>> for fulfilling the new milestone, and request that the authors
>> submit a new version with a filename reflecting this adoption.
>
>
> Should this wait until -02, with the portions that caused controversy mov=
ed
> to non-normative?

The new version of the draft will address the topics discussed in the
IETF meeting. I expect that this new version should be renamed to
draft-sipcore-sip-websocket-00 and submitted to the IETF.

Please correct me if I'm wrong.

Thanks a lot.

--=20
I=C3=B1aki Baz Castillo


From kpfleming@digium.com  Wed Mar 28 05:46:34 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A4821E8200 for ; Wed, 28 Mar 2012 05:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.44
X-Spam-Level: 
X-Spam-Status: No, score=-106.44 tagged_above=-999 required=5 tests=[AWL=0.159, 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 hbZeL-ueUsfQ for ; Wed, 28 Mar 2012 05:46:34 -0700 (PDT)
Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by ietfa.amsl.com (Postfix) with ESMTP id D658721E81FD for ; Wed, 28 Mar 2012 05:46:33 -0700 (PDT)
Received: from [10.24.55.203] (helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1SCsGn-00013k-JP for sipcore@ietf.org; Wed, 28 Mar 2012 07:46:33 -0500
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 97780D8013 for ; Wed, 28 Mar 2012 07:46:33 -0500 (CDT)
Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unjImAfdOq6B for ; Wed, 28 Mar 2012 07:46:33 -0500 (CDT)
Received: from [192.168.1.10] (173-18-150-64.client.mchsi.com [173.18.150.64]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 198C5D8002 for ; Wed, 28 Mar 2012 07:46:33 -0500 (CDT)
Message-ID: <4F730828.5040100@digium.com>
Date: Wed, 28 Mar 2012 07:46:32 -0500
From: "Kevin P. Fleming" 
Organization: Digium, Inc.
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120310 Thunderbird/11.0
MIME-Version: 1.0
To: sipcore@ietf.org
References: <4F72D93A.8040501@nostrum.com> <4F730519.6040802@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C429F5D81@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C429F5D81@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [sipcore] Confirming Consensus: WebSockets
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 12:46:35 -0000

On 03/28/2012 07:37 AM, Christer Holmberg wrote:

> There was no agreement regarding GRUU, but as far as I know we decided not to mandate Outbound, but rather go for Option 2. Unless I'm wrong, I guess it would be good to mention that in the minutes.

Given the general direction of the conversation, I'd expect there would 
be consensus that it's acceptable to mention the usage of GRUU in the 
document as a mechanism that may be employed under some circumstances 
(again, in the new 'informative' section). I could be wrong though, some 
people really don't like GRUU much :-)

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

From christer.holmberg@ericsson.com  Wed Mar 28 05:56:46 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4598021E820F for ; Wed, 28 Mar 2012 05:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.123
X-Spam-Level: 
X-Spam-Status: No, score=-8.123 tagged_above=-999 required=5 tests=[AWL=-1.874, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0X+bS3VDpb5b for ; Wed, 28 Mar 2012 05:56:45 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 713CB21E81DE for ; Wed, 28 Mar 2012 05:56:45 -0700 (PDT)
X-AuditID: c1b4fb2d-b7b76ae0000063d8-08-4f730a8c226f
Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0237"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0237", Issuer "esessmw0237" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 08.49.25560.C8A037F4; Wed, 28 Mar 2012 14:56:44 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.177]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 28 Mar 2012 14:56:43 +0200
From: Christer Holmberg 
To: "'Kevin P. Fleming'" , "sipcore@ietf.org" 
Date: Wed, 28 Mar 2012 14:56:43 +0200
Thread-Topic: [sipcore] Confirming Consensus: WebSockets
Thread-Index: Ac0M4NKJDZKsd6mHRKqJs7+YC/oeRgAAO5Kg
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C429F5D83@ESESSCMS0356.eemea.ericsson.se>
References: <4F72D93A.8040501@nostrum.com> <4F730519.6040802@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C429F5D81@ESESSCMS0356.eemea.ericsson.se> <4F730828.5040100@digium.com>
In-Reply-To: <4F730828.5040100@digium.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [sipcore] Confirming Consensus: WebSockets
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 12:56:46 -0000

Hi,=20

>> There was no agreement regarding GRUU, but as far as I know we decided n=
ot to mandate Outbound, but rather go for Option 2. Unless I'm wrong, I gue=
ss it would be good to mention that in the minutes.
>
> Given the general direction of the conversation, I'd expect there would b=
e consensus that it's acceptable to mention the usage of GRUU in the docume=
nt as a mechanism that may be employed under some circumstances (again, in =
the new=20
> 'informative' section). I could be wrong though, some people really don't=
 like GRUU much :-)

I went to the microphone, to verify that we had made no decision regarding =
GRUU :)

Regards,

Christer

From HKaplan@acmepacket.com  Wed Mar 28 07:54:22 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA99F21F87C7 for ; Wed, 28 Mar 2012 07:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.489
X-Spam-Level: 
X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110,  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 TZ8caNO68ifG for ; Wed, 28 Mar 2012 07:54:21 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id AFAC821F87BE for ; Wed, 28 Mar 2012 07:54:19 -0700 (PDT)
Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 28 Mar 2012 10:54:15 -0400
Received: from MAIL2.acmepacket.com ([169.254.2.197]) by Mail1.acmepacket.com ([169.254.1.170]) with mapi id 14.02.0283.003; Wed, 28 Mar 2012 10:54:14 -0400
From: Hadriel Kaplan 
To: "Kevin P. Fleming" 
Thread-Topic: [sipcore] Confirming Consensus: WebSockets
Thread-Index: AQHNDPKjVMywf8mTqEmUU1YEVEs5jQ==
Date: Wed, 28 Mar 2012 14:54:13 +0000
Message-ID: <3EB12CE3-EBDE-49B0-8ECC-9A0A54CDBD2F@acmepacket.com>
References: <4F72D93A.8040501@nostrum.com> <4F730519.6040802@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C429F5D81@ESESSCMS0356.eemea.ericsson.se> <4F730828.5040100@digium.com>
In-Reply-To: <4F730828.5040100@digium.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4E86FEDD0DC1584398213EAC07CB3E94@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" 
Subject: Re: [sipcore] Confirming Consensus: WebSockets
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Mar 2012 14:54:22 -0000

On Mar 28, 2012, at 2:46 PM, Kevin P. Fleming wrote:

> Given the general direction of the conversation, I'd expect there would b=
e consensus that it's acceptable to mention the usage of GRUU in the docume=
nt as a mechanism that may be employed under some circumstances (again, in =
the new 'informative' section). I could be wrong though, some people really=
 don't like GRUU much :-)

You just *know* I'm going to respond to that, right?  :)

It's not that I don't like GRUU - it's actually a very nice concept.  The p=
roblem is people think it will *work*, and that it's going to magically mak=
e things work.  It absolutely would work, I think, if (1) all SIP domains f=
ollowed an email policy model, and if (2) SIP were universally interoperabl=
e up and down the stack (ie at all layers), and if (3) SIP was the only pro=
tocol used on the path between any two parties.  But we know not all of tho=
se are the case, and arguably none are the case.

I'm planning to submit a straw-man draft for a possible solution, for next =
IETF.  I have the acronym, so now I'm just trying to figure out what the ac=
ronym stands for, which is really the hard part of any draft. :)

-hadriel


From pkyzivat@alum.mit.edu  Thu Mar 29 05:08:48 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2120521F89B8 for ; Thu, 29 Mar 2012 05:08:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.854
X-Spam-Level: 
X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bzq9uZ9qN8mI for ; Thu, 29 Mar 2012 05:08:46 -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 C098921F8A3C for ; Thu, 29 Mar 2012 05:08:45 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta03.westchester.pa.mail.comcast.net with comcast id rPwU1i0020vyq2s53Q8lbl; Thu, 29 Mar 2012 12:08:45 +0000
Received: from dhcp-16f3.meeting.ietf.org ([130.129.22.243]) by omta05.westchester.pa.mail.comcast.net with comcast id rQ8d1i00A5EhBnE3RQ8fm5; Thu, 29 Mar 2012 12:08:43 +0000
Message-ID: <4F737AEC.9050204@alum.mit.edu>
Date: Wed, 28 Mar 2012 22:56:12 +0200
From: Paul Kyzivat 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0
MIME-Version: 1.0
To: sipcore@ietf.org
References: <4F72D93A.8040501@nostrum.com> <4F730519.6040802@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C429F5D81@ESESSCMS0356.eemea.ericsson.se> <4F730828.5040100@digium.com> <3EB12CE3-EBDE-49B0-8ECC-9A0A54CDBD2F@acmepacket.com>
In-Reply-To: <3EB12CE3-EBDE-49B0-8ECC-9A0A54CDBD2F@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [sipcore] Confirming Consensus: WebSockets
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 12:08:48 -0000

Hadriel,

Please correct me if I'm wrong, but I *think* what you are trying to say 
is that out of dialog requests to the contact address from a dialog will 
mostly never work, unless somebody puts the phone-number-style URI in 
the contact address, or if the contact is one that was substituted by 
the last SBC.

I would think, *if they wanted to*, SBCs could make whatever 
substitution is necessary to make a gruu that they receive in a contact 
address be usable on the other side. This would be in their traditional 
role of fixing all the interop problems of the networks they connect.

	Thanks,
	Paul

On 3/28/12 4:54 PM, Hadriel Kaplan wrote:
>
> On Mar 28, 2012, at 2:46 PM, Kevin P. Fleming wrote:
>
>> Given the general direction of the conversation, I'd expect there would be consensus that it's acceptable to mention the usage of GRUU in the document as a mechanism that may be employed under some circumstances (again, in the new 'informative' section). I could be wrong though, some people really don't like GRUU much :-)
>
> You just *know* I'm going to respond to that, right?  :)
>
> It's not that I don't like GRUU - it's actually a very nice concept.  The problem is people think it will *work*, and that it's going to magically make things work.  It absolutely would work, I think, if (1) all SIP domains followed an email policy model, and if (2) SIP were universally interoperable up and down the stack (ie at all layers), and if (3) SIP was the only protocol used on the path between any two parties.  But we know not all of those are the case, and arguably none are the case.
>
> I'm planning to submit a straw-man draft for a possible solution, for next IETF.  I have the acronym, so now I'm just trying to figure out what the acronym stands for, which is really the hard part of any draft. :)
>
> -hadriel
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>


From HKaplan@acmepacket.com  Thu Mar 29 10:40:38 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAFE21F8755 for ; Thu, 29 Mar 2012 10:40:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.504
X-Spam-Level: 
X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095,  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 9KTxp2eG8HDy for ; Thu, 29 Mar 2012 10:40:38 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 4F94121F8753 for ; Thu, 29 Mar 2012 10:40:38 -0700 (PDT)
Received: from MAIL1.acmepacket.com (10.0.0.21) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Mar 2012 13:40:34 -0400
Received: from MAIL2.acmepacket.com ([169.254.2.64]) by Mail1.acmepacket.com ([169.254.1.130]) with mapi id 14.02.0283.003; Thu, 29 Mar 2012 13:40:34 -0400
From: Hadriel Kaplan 
To: Paul Kyzivat 
Thread-Topic: [sipcore] Confirming Consensus: WebSockets
Thread-Index: AQHNDdMLp1f83uovi0CgVNQIVlHnkA==
Date: Thu, 29 Mar 2012 17:40:33 +0000
Message-ID: 
References: <4F72D93A.8040501@nostrum.com> <4F730519.6040802@digium.com> <7F2072F1E0DE894DA4B517B93C6A05852C429F5D81@ESESSCMS0356.eemea.ericsson.se> <4F730828.5040100@digium.com> <3EB12CE3-EBDE-49B0-8ECC-9A0A54CDBD2F@acmepacket.com> <4F737AEC.9050204@alum.mit.edu>
In-Reply-To: <4F737AEC.9050204@alum.mit.edu>
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: <57A5FDB14DC5394C8CC6591B24D88FDD@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "" 
Subject: Re: [sipcore] Confirming Consensus: WebSockets
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Mar 2012 17:40:39 -0000

On Mar 28, 2012, at 10:56 PM, Paul Kyzivat wrote:

> Please correct me if I'm wrong, but I *think* what you are trying to say =
is that out of dialog requests to the contact address from a dialog will mo=
stly never work, unless somebody puts the phone-number-style URI in the con=
tact address, or if the contact is one that was substituted by the last SBC=
.

I'm not quite sure what *you're* saying, so I can't tell if it's what I'm a=
lso trying to say. :)


> I would think, *if they wanted to*, SBCs could make whatever substitution=
 is necessary to make a gruu that they receive in a contact address be usab=
le on the other side. This would be in their traditional role of fixing all=
 the interop problems of the networks they connect.


Sort of.  There are some folks in the IETF who don't want the SBCs to chang=
e them at all if they're GRUUs.  And there are also other SDOs/groups that =
seem to think they will be getting GRUUs, that they MUST get GRUUs, and tha=
t it will somehow make things magically work.=20

-hadriel


From nataraju.sip@gmail.com  Sat Mar 31 12:58:39 2012
Return-Path: 
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BC421F86C6 for ; Sat, 31 Mar 2012 12:58:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.714
X-Spam-Level: 
X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4ubpuUgK1IT for ; Sat, 31 Mar 2012 12:58:39 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id EBD9A21F861B for ; Sat, 31 Mar 2012 12:58:38 -0700 (PDT)
Received: by lagj5 with SMTP id j5so2239708lag.31 for ; Sat, 31 Mar 2012 12:58:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=48v/egmOO8sDyW8H8Emp+Wkk+JgUedNyeGtG8+U3/1Y=; b=T5BBNk08Plme7ZV7bS/DRmQjF/y5GSH0y/jf83jFZuntkVT1AEAn8QZBfw4dMqozoM RgaPZkSUcP68J3Dl6EC+IcQRIUUxzjyimV+wLtUBGVRcEUcc4PV9dOl31WNPyoYouAGo aS0MTyo2kJIe5zVG9rX3c8675nxTny1V/D8UhD7haDQlM+oJhXhBy71OKbWj2grk2Jru qBuRTGvEfhzy5nglF/vpC55J4NHOKDEyV6Wt/bpojVLClbFzArax/OMNAvQGAghtt5uP ScCGB1a/8BTkgFdfyRb160ptHv5a5P8zqsdu6CLy1nRq8HByYV6uuEozZUVnZPr0dSrn jX6A==
MIME-Version: 1.0
Received: by 10.152.145.131 with SMTP id su3mr3267461lab.46.1333223917894; Sat, 31 Mar 2012 12:58:37 -0700 (PDT)
Received: by 10.112.103.103 with HTTP; Sat, 31 Mar 2012 12:58:37 -0700 (PDT)
Date: Sun, 1 Apr 2012 01:28:37 +0530
Message-ID: 
From: "Nataraju A.B" 
To: jdrosen@jdrosen.net
Content-Type: multipart/alternative; boundary=e89a8f234ab5083c3304bc8f629f
Cc: sipcore@ietf.org
Subject: [sipcore] Editorial (minor) comment on RFC 5627
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group  
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 31 Mar 2012 19:58:39 -0000

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

Hi All,


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


4.4.  Using One's Own GRUUs

    ....A UA compliant to this specification SHOULD use one of its
GRUUs as its remote target. This includes..

   . . . .

   o  a 2xx response to NOTIFY
   o  the UPDATE request   o  a 2xx response to *NOTIFY*


The last point must have been mentioned as

   o  a 2xx response to **UPDATE**


Thanks,
Nataraju A.B.

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


Hi All,

I feel following is an editorial comment on the RFC 562=
7...



    ....A UA compliant to this specification =
SHOULD use one of its GRUUs as its remote target.=A0This includes..<=
/pre>

   . . . . 
   o  a 2xx response to NOTIFY
   o  the UPDATE request
   o  a 2xx response to *NOTIFY*


The last point must have been mentioned =
as
   o  a 2xx respons=
e to *UPDATE*


Thanks,
=
Nataraju A.B.=







--e89a8f234ab5083c3304bc8f629f--